Re: [RFC 1/2] mm: additional page lock debugging

[Peter Zijlstra]

On Tue, Dec 31, 2013 at 11:42:04AM -0500, Sasha Levin wrote:
> On 12/31/2013 11:26 AM, Peter Zijlstra wrote:
> >On Mon, Dec 30, 2013 at 10:22:02PM -0500, Sasha Levin wrote:
> >
> >>I really want to use lockdep here, but I'm not really sure how to handle locks which live
> >>for a rather long while instead of being locked and unlocked in the same function like
> >>most of the rest of the kernel. (Cc Ingo, PeterZ).
> >
> >Uh what? Lockdep doesn't care about which function locks and unlocks a
> >particular lock. Nor does it care how long its held for.
> 
> Sorry, I messed up trying to explain that.
> 
> There are several places in the code which lock a large amount of pages, something like:
> 
> 	for (i = 0; i < (1 << order); i++)
> 		lock_page(&pages[i]);
> 
> 
> This triggers two problems:
> 
>  - lockdep complains about deadlock since we try to lock another page while one is already
> locked. I can clear that by allowing page locks to nest within each other, but that seems
> wrong and we'll miss actual deadlock cases.

Right,.. I think we can cobble something together like requiring we
always lock pages in pfn order or somesuch.

>  - We may leave back to userspace with pages still locked. This is valid behaviour but lockdep
> doesn't like that.

Where do we actually do this? BTW its not only lockdep not liking that,
Linus was actually a big fan of that check.

ISTR there being some filesystem freezer issues with that too, where the
freeze ioctl would return to userspace with 'locks' held and that's
cobbled around (or maybe gone by now -- who knows).

My initial guess would be that this is AIO/DIO again, those two seem to
be responsible for the majority of ugly around there.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/