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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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


Thanks,
Sasha

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]