Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable,, but OK after explicit stat
Hi, On 03/21/2012 06:39 PM, Jonathan Nieder wrote: Rik Theys wrote: Can this commit be backported to the 3.2 kernel in sid? It applies and I have tested it in the past against the 3.2.4 kernel. Just for the record: we are talking about v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing open, 2012-01-07 It looks safe to me, too. It is too large to follow the rules of Greg's 3.2.y-stable kernel to the letter, but I think we should apply it. It seems the patch still has not made it into the sid kernel. Any reason this patch hasn't been cherry picked yet? For 2.6.32.y-longterm, I would be happier with a more minimal patch. Where can one find more information about the rpciod hang described in the commit message to 80e52aced138b (NFSv4: Don't do idmapper upcalls for asynchronous RPC calls, 2009-08-09)? Maybe there is some alternative fix to that. I would also be very much interested to hear how well the following series against 2.6.32.y does: v2.6.33-rc1~54^2~7 rpc: add a new priority in RPC task, 2009-12-14 v2.6.33-rc1~54^2~5 nfs: make recovery state manager operations privileged, 2009-12-14 v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing open, 2012-01-07 I've been running a patched squeeze kernel with those patches applied for about two weeks now and it fixes the bug. I have not seen any regressions in other nfs functionality using these patches. It would be great to have this fixed in squeeze if not considered too intrusive. But I would definitely like to see these patches land in the sid/wheezy kernel, so Wheezy will not have this bug. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable,, but OK after explicit stat
fixed-upstream 659111 fixed 659111 linux-2.6/3.3~rc6-1~experimental.1 quit Hi, The commit that fixes this bug is now part of the upstream 3.3 kernel. I verified it on the 3.3-rc6 kernel from experimental. Can this commit be backported to the 3.2 kernel in sid? It applies and I have tested it in the past against the 3.2.4 kernel. I agree that fixing it in squeeze might be a stretch, but it would be nice to have it in Wheezy. Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable,, but OK after explicit stat
Rik Theys wrote: Can this commit be backported to the 3.2 kernel in sid? It applies and I have tested it in the past against the 3.2.4 kernel. Just for the record: we are talking about v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing open, 2012-01-07 It looks safe to me, too. It is too large to follow the rules of Greg's 3.2.y-stable kernel to the letter, but I think we should apply it. For 2.6.32.y-longterm, I would be happier with a more minimal patch. Where can one find more information about the rpciod hang described in the commit message to 80e52aced138b (NFSv4: Don't do idmapper upcalls for asynchronous RPC calls, 2009-08-09)? Maybe there is some alternative fix to that. I would also be very much interested to hear how well the following series against 2.6.32.y does: v2.6.33-rc1~54^2~7 rpc: add a new priority in RPC task, 2009-12-14 v2.6.33-rc1~54^2~5 nfs: make recovery state manager operations privileged, 2009-12-14 v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing open, 2012-01-07 Backported patches are at http://bugs.debian.org/659111#50. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable,, but OK after explicit stat
Hi, On Wed, 21 Mar 2012, Jonathan Nieder wrote: Rik Theys wrote: Can this commit be backported to the 3.2 kernel in sid? It applies and I have tested it in the past against the 3.2.4 kernel. I would also be very much interested to hear how well the following series against 2.6.32.y does: v2.6.33-rc1~54^2~7 rpc: add a new priority in RPC task, 2009-12-14 v2.6.33-rc1~54^2~5 nfs: make recovery state manager operations privileged, 2009-12-14 v3.3-rc1~116^2~1 NFSv4: Save the owner/group name string when doing open, 2012-01-07 I believe I compiled a kernel with those patches before and I believe they indeed fixed the bug. I didn't stress test other NFS functionality on that kernel to see if anything else broke. I believe a squeeze kernel security update is pending and I hope it will release before Friday noon. If that is the case I can push this update during my maintenance window this weekend. I will apply the patches on top of that security update and run in on one of my client machines. Or can I pull the squeeze-security tree from a public repo? Regards, Rik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable,, but OK after explicit stat
Rik Theys wrote: I believe a squeeze kernel security update is pending and I hope it will release before Friday noon. If that is the case I can push this update during my maintenance window this weekend. I will apply the patches on top of that security update and run in on one of my client machines. Sounds great. Many thanks. Or can I pull the squeeze-security tree from a public repo? svn://svn.debian.org/svn/kernel/dists/squeeze-security/linux-2.6/ Ciao, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659111: [2.6.31 - 2.6.32 regression] Files on NFS4 become unwritable, but OK after explicit stat
forwarded 659111 http://thread.gmane.org/gmane.linux.nfs/45995/focus=47436 quit Jonathan Nieder wrote: I suspect the patch is too big for the upstream stable series[*], but it should be safe to apply to sid, unless someone comes up with something more minimal to replace it. Requested help upstream, since I'd like to see this fix in 2.6.32.y. It should be possible to split the fix into more easily digestible pieces for -stable if necessary. Thanks again for a pleasant report. Sincerely, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
