On Thu, Mar 17 2016, William Dauchy wrote:
> Hi Bruce,
>
> Thank your for your reply.
>
> On Wed, Mar 16, 2016 at 4:05 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>> Why is that?
>
> It's indeed not really based on actual proof but based on the experience we had.
> Faced several bugs, and it appears we had less issues by backporting a
> few commits; e.g related to races, leaks, performances regressions. We
> did not spent enough time on it to actually show this commit was
> actually fixing an issue hit.
>
>> Do you have a list?
>
> I am currently trying to switch from v3.14 to v4.1 (nfs client). So
> even know it is off topic, those I have in mind:
> 0d2a970 SUNRPC: Fix a backchannel race
> 6851447 SUNRPC: Fix a backchannel deadlock
> 0993920 SUNRPC: Prevent SYN+SYNACK+RST storms
> 03c78827 SUNRPC: Fix races between socket connection and destroy code
> a41cbe8 Failing to send a CLOSE if file is opened WRONLY and server
> reboots on a 4.x mount
> 39d0d3b NFS: Fix a tracepoint NULL-pointer dereference
> 5e99b53 nfs4: reset states to use open_stateid when returning
> delegation voluntarily
> e92c1e0 NFSv4: Fix a nograce recovery hang
> 6b55970 nfs: Fix a memory leak when meeting an unsupported state protect
Commit: 7632e465feb1 ("dcache: use IS_ROOT to decide where dentry is hashed")
is my most recent complaint - it really should have been tagged for
-stable. It is now in 3.12-stable, over 2 years later :-(
NeilBrown
>
> I am probably wrong on most of them but we had better stability after
> applying them and I probably forgot some.
>
>> I don't expect *proof*, necessarily, but some sort of argument would be
>> helpful.
>
> In my environment, if I hit this race, it is not acceptable to not
> being able to unmount the filesystem.
>
> Thanks,
> --
> William
Attachment:
signature.asc
Description: PGP signature
