Mateusz Guzik wrote:
>I reproduced the panic, things work for me with the patch below.
>However, there may be more to it so I'm going to ask Rick to weigh in.
>but short version is that length returned by nfsrv_parsename is off by
>one compared to copyinstr.
Yes, it appears that, now, ni_pathlen in
Yes, this works for me too. I first tried reverting
d81aefa8b7dd8cbeffeda541fca9962802404983, but this looked a bit more
sane. :)
-Dimitry
> On 31 May 2021, at 17:03, Mateusz Guzik wrote:
>
> I reproduced the panic, things work for me with the patch below.
> However, there may be more to it so
Mateusz Guzik wrote:
>On 5/31/21, Mateusz Guzik wrote:
>> It's probably my commit d81aefa8b7dd8cbeffeda541fca9962802404983 ,
>> I'll look at this later.
>
>Well let me rephrase. While the panic was added in said commit, I
>suspect the bug is on nfs side -- it has its own namei variant which I
>sus
I reproduced the panic, things work for me with the patch below.
However, there may be more to it so I'm going to ask Rick to weigh in.
but short version is that length returned by nfsrv_parsename is off by
one compared to copyinstr.
diff --git a/sys/fs/nfsserver/nfs_nfsdsubs.c b/sys/fs/nfsserver/
On 5/31/21, Mateusz Guzik wrote:
> It's probably my commit d81aefa8b7dd8cbeffeda541fca9962802404983 ,
> I'll look at this later.
Well let me rephrase. While the panic was added in said commit, I
suspect the bug is on nfs side -- it has its own namei variant which I
suspect is managing ni_pathlen
It's probably my commit d81aefa8b7dd8cbeffeda541fca9962802404983 ,
I'll look at this later.
On 5/31/21, Dimitry Andric wrote:
> Hi,
>
> I recently upgraded a -CURRENT NFS server from 2021-05-12 to today
> (2021-05-31), and when the first NFS client attempted to connect, I got this
> panic:
>
> pa
