> On Jul 18, 2020, at 11:55 AM, Chuck Lever wrote:
>
>
>
>> On Jul 17, 2020, at 3:46 PM, Pierre Sauter wrote:
>>
>> Am Freitag, 17. Juli 2020, 19:56:09 CEST schrieb Kai-Heng Feng:
Pierre, thanks for confirming!
Kai-Heng suspected an upstream stable commit that is missing in
> On Jul 17, 2020, at 3:46 PM, Pierre Sauter wrote:
>
> Am Freitag, 17. Juli 2020, 19:56:09 CEST schrieb Kai-Heng Feng:
>>> Pierre, thanks for confirming!
>>>
>>> Kai-Heng suspected an upstream stable commit that is missing in 5.4.0-40,
>>> but I don't have any good suggestions.
>>
>> Well,
Am Freitag, 17. Juli 2020, 19:56:09 CEST schrieb Kai-Heng Feng:
> > Pierre, thanks for confirming!
> >
> > Kai-Heng suspected an upstream stable commit that is missing in 5.4.0-40,
> > but I don't have any good suggestions.
>
> Well, Ubuntu's 5.4 kernel is based on upstream stable v5.4, so I aske
> On Jul 18, 2020, at 01:34, Chuck Lever wrote:
>
>
>
>> On Jul 17, 2020, at 1:29 PM, Pierre Sauter wrote:
>>
>> Hi Chuck,
>>
>> Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever:
>>> So this makes me think there's a possibility you are not using upstream
>>> stable kernels.
> On Jul 17, 2020, at 1:29 PM, Pierre Sauter wrote:
>
> Hi Chuck,
>
> Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever:
>> So this makes me think there's a possibility you are not using upstream
>> stable kernels. I can't help if I don't know what source code and commit
>> stre
Hi Chuck,
Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever:
> So this makes me think there's a possibility you are not using upstream
> stable kernels. I can't help if I don't know what source code and commit
> stream you are using. It also makes me question the bisect result.
Yes
Hi Pierre-
> On Jul 16, 2020, at 2:40 PM, Pierre Sauter wrote:
>
> Hi,
>
> Am 2020-07-15 20:54, schrieb Chuck Lever:
>> v5.4.40 does not have 31c9590ae468 and friends, but the claim is this
>> one crashes?
>
> To my knowledge 31c9590ae468 and friends are in v5.4.40.
Those upstream commits wer
Hi,
Am 2020-07-15 20:54, schrieb Chuck Lever:
> v5.4.40 does not have 31c9590ae468 and friends, but the claim is this
> one crashes?
To my knowledge 31c9590ae468 and friends are in v5.4.40.
> And v5.4.51 has those three and 89a3c9f5b9f0, which Pierre claims fixes
> the problem for him; but anoth
> On Jul 15, 2020, at 11:14 AM, Chuck Lever wrote:
>
>
>
>> On Jul 15, 2020, at 11:08 AM, Kai-Heng Feng
>> wrote:
>>
>>> On Jul 15, 2020, at 23:02, Chuck Lever wrote:
>>>
On Jul 15, 2020, at 10:48 AM, Kai-Heng Feng
wrote:
Hi,
Multiple users reported NFS
> On Jul 15, 2020, at 11:08 AM, Kai-Heng Feng
> wrote:
>
>> On Jul 15, 2020, at 23:02, Chuck Lever wrote:
>>
>>> On Jul 15, 2020, at 10:48 AM, Kai-Heng Feng
>>> wrote:
>>>
>>> Hi,
>>>
>>> Multiple users reported NFS causes NULL pointer dereference [1] on Ubuntu,
>>> due to commit "SUNR
> On Jul 15, 2020, at 23:02, Chuck Lever wrote:
>
>
>
>> On Jul 15, 2020, at 10:48 AM, Kai-Heng Feng
>> wrote:
>>
>> Hi,
>>
>> Multiple users reported NFS causes NULL pointer dereference [1] on Ubuntu,
>> due to commit "SUNRPC: Add "@len" parameter to gss_unwrap()" and commit
>> "SUNRP
> On Jul 15, 2020, at 10:48 AM, Kai-Heng Feng
> wrote:
>
> Hi,
>
> Multiple users reported NFS causes NULL pointer dereference [1] on Ubuntu,
> due to commit "SUNRPC: Add "@len" parameter to gss_unwrap()" and commit
> "SUNRPC: Fix GSS privacy computation of auth->au_ralign".
>
> The same
Hi,
Multiple users reported NFS causes NULL pointer dereference [1] on Ubuntu, due
to commit "SUNRPC: Add "@len" parameter to gss_unwrap()" and commit "SUNRPC:
Fix GSS privacy computation of auth->au_ralign".
The same issue happens on upstream stable 5.4.y branch.
The mainline kernel doesn't ha
13 matches
Mail list logo
