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

[Sasha Levin]

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

Sorry, I went ahead to dig into mm/lockdep based on your comments and noticed I forgot to reply
to this mail.

Getting them to lock in pfn order seems to be a bit of a mess since we need to keep the free
lists sorted. I didn't find a nice way of doing it without having to do insertion sort which slows
everything down.

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

Indeed, the block layer has multiple "violations". In the AIO case, we lock pages in one task
and leave back to userspace, and those pages get unlocked by a completion thread which runs at
some point later.

Right now I gave up on getting lockdep fully integrated in, and am trying to fix as many of these 
issues as possible by detecting trivial cases and fixing those. I feel that adding lockdep in at
this point is way more complex than what we need done. We don't really need lockdep to detect pretty
trivial cases of double locking on the very same lock...

When we got rid of everything we can easily spot, lockdep should move in to detect anything more
complex.

Thanks,
Sasha

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