Re: Swapoff w/regular file causes Oops

[Steve G <linux_4ever@yahoo.com>]

>Well, I had this problem when using RH8, but using kernel
>2.4.20-8 from RH9.

OK, I've investigated this further. It seems that all Red
Hat 2.4.18 kernels are immune to the swapoff problem. All
2.4.20 kernels (include the brand new one) have this bug. I
don't think anyone has tried the program I sent since it
would have caused an Oops and you'd see what I mean. I
don't think this is a Red Hat problem either, I think this
is generic to recent kernels.

Looking at the source for 2.4.20 kernel mm/swapfile.c
sys_swapoff function, the bug goes like this...swapoff
checks permissions, this is OK, it then gets the nameidata
entry for the filename, it checks to see if the file is on
the swap list, but its not (remember mkswap was never
called). err is set to -EINVAL and it jumps to out_dput
line 792. The kernel is unlocked and path_release() is
called (fs/namei.c line 253).

path_release() will unmount the entry and this is where the
Oops occurs. It was never mounted. It is simply a regular
file. It seems like there should be some check if err ==
-EINVAL that the file is in fact mounted. Looking at
__mntput (which is an inline function & maybe that's why
its not in the Oops call stack), it implicitly trusts that
the mnt parameter is not NULL & is valid. dput() at least
checks for NULL and does nothing.

I'm not too familiar with the kernel internals, but maybe
someone else can take what I've said and figure out the
right fix.

Best Regards,
-Steve Grubb


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com