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 <[email protected]>
SUSE Labs, CR
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.