BUG: User triggerable kernel panic in 4.8 (possibly 4.9)

BUG: User triggerable kernel panic in 4.8 (possibly 4.9)

[Darren Austin]

[ Please CC me with any replies as I will be leaving the list shortly ]

Hi,
  I'm not sure if this is the best place to report an issue i've discovered 
with the kernel and the 'fsc' mount option - please let me know if there is 
some other mailing list or person I should be notifying about this.

The bug appears (at least for me) when using an NFS server, and a client 
which mounts an export from that server with the 'fsc' option (whether or 
not the fscache daemon is running or not).  It also seems easiest to trigger 
using the 'nano' editor, but other commands will trigger it randomly.

I've tested this bug on the Ubuntu 1610 kernel (4.8.0) and with the 4.8.2 
kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/.  The latter 
purports to be a kernel built from the unmodified kernel source, and simply 
packaged in a .deb, so this isn't a Ubuntu kernel problem.  Unless the 
problem has been corrected in the 4.9 series, I suspect the bug may also 
persist there - i've not had the opportunity to check 4.9.x kernels as yet.

I can repeatidly reproduce this bug on my system, so it's definitely not a 
one off - it causes a kernel panic and complete lock-up every time.

The NFS share I tested with is exported with options: 
  rw,async,insecure,insecure_locks,no_root_squash,anongid=99,anonuid=99,no_subtree_check
(but the export options don't seem to matter to trigger the  bug)
and mounted on the client with options:
  vers=4,hard,intr,acl,rw,fsc
via the Linux automounter (but the issue persists on mounts from fstab or 
when mounted manually).

To reproduce the bug is quite simple...
1) Set up the server export and client mount as detailed above.
2) From the console (or in a terminal; but I only tested this once) in the 
directory where you've mounted the NFS share, run:
  nano testfile.txt
and add write some text to the file.
2) Save the file and exit (Ctl+X is how I did it).
3) When back at the prompt, immediately hit the up arrow on the keyboard (to
load the last typed command into the buffer) and hit enter.
4) Watch as the pretty text of the panic scrolls by :)

With the help of people on the nano-dev mailing list, I figured out that 
it's the 'fsc' option which causes the panic - repeated tests without that 
option active do not trigger it.  However, this is /not/ a nano specific bug 
- it can be triggered by any command used on the mount.  And besides, nano 
shouldn't be able to take down the system :)

If any further information is required, please don't hesitate to reply.

Darren.

Re: BUG: User triggerable kernel panic in 4.8 (possibly 4.9)

[Jan Kara]

Hello,

Thanks for report. I suspect this bug got lost in the noise of
linux-kernel. Adding more relevant lists and people to CC.

								Honza

On Thu 20-10-16 15:24:37, Darren Austin wrote:
> [ Please CC me with any replies as I will be leaving the list shortly ]
> 
> Hi,
>   I'm not sure if this is the best place to report an issue i've discovered 
> with the kernel and the 'fsc' mount option - please let me know if there is 
> some other mailing list or person I should be notifying about this.
> 
> The bug appears (at least for me) when using an NFS server, and a client 
> which mounts an export from that server with the 'fsc' option (whether or 
> not the fscache daemon is running or not).  It also seems easiest to trigger 
> using the 'nano' editor, but other commands will trigger it randomly.
> 
> I've tested this bug on the Ubuntu 1610 kernel (4.8.0) and with the 4.8.2 
> kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/.  The latter 
> purports to be a kernel built from the unmodified kernel source, and simply 
> packaged in a .deb, so this isn't a Ubuntu kernel problem.  Unless the 
> problem has been corrected in the 4.9 series, I suspect the bug may also 
> persist there - i've not had the opportunity to check 4.9.x kernels as yet.
> 
> I can repeatidly reproduce this bug on my system, so it's definitely not a 
> one off - it causes a kernel panic and complete lock-up every time.
> 
> The NFS share I tested with is exported with options: 
>   rw,async,insecure,insecure_locks,no_root_squash,anongid=99,anonuid=99,no_subtree_check
> (but the export options don't seem to matter to trigger the  bug)
> and mounted on the client with options:
>   vers=4,hard,intr,acl,rw,fsc
> via the Linux automounter (but the issue persists on mounts from fstab or 
> when mounted manually).
> 
> To reproduce the bug is quite simple...
> 1) Set up the server export and client mount as detailed above.
> 2) From the console (or in a terminal; but I only tested this once) in the 
> directory where you've mounted the NFS share, run:
>   nano testfile.txt
> and add write some text to the file.
> 2) Save the file and exit (Ctl+X is how I did it).
> 3) When back at the prompt, immediately hit the up arrow on the keyboard (to
> load the last typed command into the buffer) and hit enter.
> 4) Watch as the pretty text of the panic scrolls by :)
> 
> With the help of people on the nano-dev mailing list, I figured out that 
> it's the 'fsc' option which causes the panic - repeated tests without that 
> option active do not trigger it.  However, this is /not/ a nano specific bug 
> - it can be triggered by any command used on the mount.  And besides, nano 
> shouldn't be able to take down the system :)
> 
> If any further information is required, please don't hesitate to reply.
> 
> Darren.
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: BUG: User triggerable kernel panic in 4.8 (possibly 4.9)

[Anna Schumaker]

Hi Darren,

On 11/29/2016 03:40 AM, Jan Kara wrote:
> Hello,
> 
> Thanks for report. I suspect this bug got lost in the noise of
> linux-kernel. Adding more relevant lists and people to CC.
> 
> 								Honza
> 
> On Thu 20-10-16 15:24:37, Darren Austin wrote:
>> [ Please CC me with any replies as I will be leaving the list shortly ]
>>
>> Hi,
>>   I'm not sure if this is the best place to report an issue i've discovered 
>> with the kernel and the 'fsc' mount option - please let me know if there is 
>> some other mailing list or person I should be notifying about this.
>>
>> The bug appears (at least for me) when using an NFS server, and a client 
>> which mounts an export from that server with the 'fsc' option (whether or 
>> not the fscache daemon is running or not).  It also seems easiest to trigger 
>> using the 'nano' editor, but other commands will trigger it randomly.
>>
>> I've tested this bug on the Ubuntu 1610 kernel (4.8.0) and with the 4.8.2 
>> kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/.  The latter 
>> purports to be a kernel built from the unmodified kernel source, and simply 
>> packaged in a .deb, so this isn't a Ubuntu kernel problem.  Unless the 
>> problem has been corrected in the 4.9 series, I suspect the bug may also 
>> persist there - i've not had the opportunity to check 4.9.x kernels as yet.
>>
>> I can repeatidly reproduce this bug on my system, so it's definitely not a 
>> one off - it causes a kernel panic and complete lock-up every time.
>>
>> The NFS share I tested with is exported with options: 
>>   rw,async,insecure,insecure_locks,no_root_squash,anongid=99,anonuid=99,no_subtree_check
>> (but the export options don't seem to matter to trigger the  bug)
>> and mounted on the client with options:
>>   vers=4,hard,intr,acl,rw,fsc
>> via the Linux automounter (but the issue persists on mounts from fstab or 
>> when mounted manually).
>>
>> To reproduce the bug is quite simple...
>> 1) Set up the server export and client mount as detailed above.
>> 2) From the console (or in a terminal; but I only tested this once) in the 
>> directory where you've mounted the NFS share, run:
>>   nano testfile.txt
>> and add write some text to the file.
>> 2) Save the file and exit (Ctl+X is how I did it).
>> 3) When back at the prompt, immediately hit the up arrow on the keyboard (to
>> load the last typed command into the buffer) and hit enter.
>> 4) Watch as the pretty text of the panic scrolls by :)

I've got through these steps a couple of times, and I'm unable to reproduce this (using 4.8.11).  Can you send the stack trace of the panic so we can work from that?

Thanks,
Anna

>>
>> With the help of people on the nano-dev mailing list, I figured out that 
>> it's the 'fsc' option which causes the panic - repeated tests without that 
>> option active do not trigger it.  However, this is /not/ a nano specific bug 
>> - it can be triggered by any command used on the mount.  And besides, nano 
>> shouldn't be able to take down the system :)
>>
>> If any further information is required, please don't hesitate to reply.
>>
>> Darren.