lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 11 Jun 2012 10:20:16 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Jörg Platte <jplatte@...sa.net>
Cc:	bfields <bfields@...ldses.org>,
	"Myklebust, Trond" <Trond.Myklebust@...app.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	Hans de Bruin <jmdebruin@...net.nl>
Subject: Re: Kernel 3.4.X NFS server regression

On Mon, 11 Jun 2012 15:25:55 +0200
Jörg Platte <jplatte@...sa.net> wrote:

> Am 11.06.2012 um 15:13 schrieb Jeff Layton <jlayton@...hat.com>:
> 
> > 
> > Ahh, I think I see the bug. From rpc_timeout_upcall_queue:
> > 
> > -----------------------[snip]--------------------------
> >        dentry = dget(pipe->dentry);
> >        spin_unlock(&pipe->lock);
> >        if (dentry) {
> >                rpc_purge_list(&RPC_I(dentry->d_inode)->waitq,
> >                               &free_list, destroy_msg, -ETIMEDOUT);
> >                dput(dentry);
> >        }
> > -----------------------[snip]--------------------------
> > 
> > ...when there is no dentry (as there wouldn't be when rpc_pipefs isn't
> > mounted), then the rpc_purge_list won't run. FWIW, you'd probably see
> > similar problems if you attempted a sec=krb5 mount without having
> > rpc_pipefs mounted.
> > 
> > I'm still looking at the code to see what the right fix is. For now,
> > making sure you have a /var/lib/nfs/v4recoverydir is probably the
> > easiest workaround.
> > 
> > -- 
> > Jeff Layton <jlayton@...hat.com>
> 
> On my computer that shows the bug there is indeed no v4recovery directory. There is one on the other machine that does not show this bug. I'll test the latest kernel with this directory created  today afternoon. 
> 
> Thank you for the analysis!
> 

No problem. One possibility for the difference is that rpc_pipefs is
mounted on the machine that doesn't show the problem, but isn't mouted
on the machine that does.

-- 
Jeff Layton <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ