On Thu, 2012-04-19 at 14:48 +0100, Luis Henriques wrote: > On Thu, Apr 19, 2012 at 10:30:25AM +0100, Luis Henriques wrote: > > On Wed, Apr 18, 2012 at 01:36:52PM -0400, Trond Myklebust wrote: > > > The first patch addresses the Oops. > > > The second will hopefully address the looping. > > > > > > Trond Myklebust (2): > > > NFSv4: Ensure that the LOCK code sets exception->inode > > > NFSv4: Ensure that we check lock exclusive/shared type against open > > > modes > > > > > > fs/nfs/nfs4proc.c | 23 +++++++++++++++++++++-- > > > 1 files changed, 21 insertions(+), 2 deletions(-) > > > > > > -- > > > 1.7.7.6 > > > > > Just to let you know we do have a few successful tests on these patches. > > You can check the details here: > > > > http://bugs.launchpad.net/bugs/974664 > > > > Although I haven't tested the patches myself, fell free to add a Tested-by > > to these patches. > > There's something else a forgot to mention, which is the fact that the bug > reports were for kernel 3.2.14. So you may want to update the > "Cc: stable@xxxxxxxxxxxxxxx" on commit 487790f27df9bb27d3400486bd021dd59edc7589 > to include at least this version. Yep. I also saw that there is a need for it in 3.0.27, so I'll just remove that >= 3.3.1... > There are two another patches we have applied that are present in mainline > but haven't made its way into stable: > - 14977489ffdb80d4caf5a184ba41b23b02fbacd9 > - 96dcadc2fdd111dca90d559f189a30c65394451a I don't plan on sending these 2 commits to stable unless we see some specific problems that need to be corrected. I understand that seeing a NFS4ERR_OPENMODE at the wrong time could theoretically cause an Oops without the 1497748 commit, but broken servers can wreak all sorts of havoc anyway. There isn't much you can do to protect against them. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
