linux-kernel - Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

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]

Message-ID: <20130305183941.19ff39ce@tlielax.poochiereds.net>
Date:	Tue, 5 Mar 2013 18:39:41 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	"Myklebust, Trond" <Trond.Myklebust@...app.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mandeep Singh Baines <msb@...omium.org>,
	Ming Lei <ming.lei@...onical.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!

On Tue, 5 Mar 2013 11:09:23 -0800
Tejun Heo <tj@...nel.org> wrote:

> Hello, Jeff.
> 
> On Tue, Mar 05, 2013 at 02:03:12PM -0500, Jeff Layton wrote:
> > Sounds intriguing...
> > 
> > I'm not sure what this really means for something like NFS though. How
> > would you envision this working when we have long running syscalls that
> > might sit waiting in the kernel indefinitely?
> 
> I think it is the same problem as being able to handle SIGKILL in
> responsive manner.  It could be tricky to implement for nfs but it at
> least doesn't have to solve the problem twice.
> 
> > Here's my blue-sky, poorly-thought-out idea...
> > 
> > We could add a signal (e.g. SIGFREEZE) that allows the sleeps in
> > NFS/RPC layer to be interrupted. Those would return back toward
> > userland with a particular type of error (sort of like ERESTARTSYS).
> > 
> > Before returning from the kernel though, we could freeze the process.
> > When it wakes up, then we could go back down and retry the call again
> > (much like an ERESTARTSYS kind of thing).
> > 
> > The tricky part here is that we'd need to distinguish between the case
> > where we caught SIGFREEZE before sending an RPC vs. after. If we sent
> > the call before freezing, then we don't want to resend it again. It
> > might be a non-idempotent operation.
> 
> So, yeah, you are thinking pretty much the same as I'm.
> 
> > Sounds horrific to code up though... :)
> 
> I don't know the details of nfs but those events could essentially be
> signaling that the system is gonna lose power.  I think it would be a
> good idea to solve it.
> 
> Thanks.
> 

It would be...

So, I briefly considered a similar approach when I was working on the
retry-on-ESTALE error patches. It occurred to me that it was somewhat
similar to the ERESTARTSYS case, so handling it at a higher level than
in the syscall handlers themselves might make sense...

Al was in the middle of his signal handling/execve rework though and I
ran the idea past him. He pointedly told me that I was crazy for even
considering it. This is rather non-trivial to handle since it means
mucking around in a bunch of arch-specific code and dealing with all of
the weirdo corner cases.

Anyone up for working out how to handle a freeze event on a process
that already has a pending signal, while it's being ptraced? It's
probably best to chat with Al (cc'ed here) before you embark on this
plan since he was just in that code recently.

In any case, maybe there's also some code consolidation opportunity
here too. I suspect at least some of this logic is in arch-specific
code when it really needn't be....

-- 
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/