Bug 154639 - (IT_71391) kernel thread current->mm dereference in grab_swap_token causes oops
kernel thread current->mm dereference in grab_swap_token causes oops
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Rik van Riel
Brian Brock
Depends On:
Blocks: 231639
  Show dependency treegraph
Reported: 2005-04-13 05:08 EDT by Keith Holder
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-08 11:14:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Keith Holder 2005-04-13 05:08:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0

Description of problem:
Veritas has a kernel thread that performs asynchronous direct i/o on behalf of user programs. When the i/o data is available the kernel thread calls get_user_pages(), to make sure the user pages are present before moving the
data into user buffers. A side effect of that is, if the user program happens to be paged out, we end up in grab_swap_token, with current->mm set to NULL. Unfortunately the code dereferences current->mm without checking whether it is NULL.

stack functions back trace :-


A suitable fix would be to add the following to start of grab_swap_token()

if (!current->mm)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install veritas software stack onto system
2. Run Veritas' Oracle Data Manager stress suite

Actual Results:  After several hours and under heavy stress the system oops in grab_swap_token()

Expected Results:  Function should just return if current->mm is NULL *or* allow an mm_sruct pointer
to be passed in as an argument. However, it still needs to check for mm_struct
pointer being NULL.

Additional info:
Comment 1 Rik van Riel 2005-04-13 08:55:14 EDT
I'll submit a (trivial) patch for the RHEL4 kernel to ignore a current->mm of NULL.

Btw, note that for most kernel threads current->mm tends to be &init_mm...
Comment 2 Rik van Riel 2005-04-13 10:24:16 EDT
Btw, have you verified that adding the check really fixes the issue, or does the
kernel simply crash elsewhere?  I am not 100% sure that running any task with a
NULL ->mm is valid...
Comment 3 Keith Holder 2005-04-14 06:44:42 EDT
When calling daemonize() to create a kernel thread, it calls exit_mm().
This sets tsk->mm to NULL and the thread/process runs with a 'lazy_tlb'.
Also, I thought all kernel threads didn't have an address space, hence mm
is supposed to be NULL.
Comment 4 Rik van Riel 2005-04-14 06:54:12 EDT
You're right.  Hmmm, I could've sworn they got moved to &init_mm.

Anyway, the patch has been submitted for inclusion into RHEL4 yesterday, and got
approved. Thank you for alerting us to this bug.
Comment 14 Keith Holder 2005-05-09 09:43:59 EDT
I have run a Veritas specific stress test (odmstress) non-stop for over 100 
hours with this patch fix (U1-kernel-2.6.9-6.43) and the testing was successful.
Comment 15 Tim Powers 2005-06-08 11:14:08 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.