Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 15 May 2012 11:41:03 -0700 | Subject | Re: [PATCH] vfs: fix IMA lockdep circular locking dependency |
| |
On Tue, May 15, 2012 at 10:19 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > - move the whole call to security_file_mmap() to outside the > mmap_sem, and test the *suggested* address (which is not the same as > the final address)
Actually, I think I have a simpler approach.
We already actually have two *different* security_file_mmap() calls: it's just that currently the difference is shown by the last argument to the function ("addr_only").
Which is totally static by call-site.
And the ones that have addr_only set are all inside the mmap_sem region.
So here's my new suggestion, which avoids the semantic changes: let's just split that "security_file_mmap()" call into two. One that checks the file, and one that checks the address.
And we'll continue to check the address within the mmap_sem region, but nobody will care, because that one doesn't need any other locking.
So we'll just split the file check - along with the ima_file_mmap() - into the "security_mmap_file()" function (no "addr_only" argument), and move that outside the lock.
And then the address-only check (let's call it "security_mmap_addr()") we leave at the place we *currently* do our security_file_mmap() check, along with (obviously) the calls that currently have "addr_only=1" and only give the address anyway).
That cleans up the whole nasty piece of crap calling convention too, getting rid of idiotic unreadable code like
ret = security_file_mmap(NULL, 0, 0, 0, new_addr, 1);
and replacing it with
ret = security_mmap_addr(new_addr);
which actually shows what it is doing.
Hmm? That looks like a fairly mechanical conversion, and we could start with Mimi's patch that already splits it up that way (except it calls "security_mmap_file()" ima_file_mmap() and doesn't call the LSM function pointer there)
Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |