Re: [PATCH v3 10/12] ima: defer calling __fput()
[Posted March 28, 2012 by jake]
| From: |
| Al Viro <viro-AT-ZenIV.linux.org.uk> |
| To: |
| Mimi Zohar <zohar-AT-linux.vnet.ibm.com> |
| Subject: |
| Re: [PATCH v3 10/12] ima: defer calling __fput() |
| Date: |
| Thu, 22 Mar 2012 14:22:12 +0000 |
| Message-ID: |
| <20120322142212.GV6589@ZenIV.linux.org.uk> |
| Cc: |
| linux-security-module-AT-vger.kernel.org,
linux-kernel-AT-vger.kernel.org, linux-fsdevel-AT-vger.kernel.org,
David Safford <safford-AT-linux.vnet.ibm.com>,
Dmitry Kasatkin <dmitry.kasatkin-AT-intel.com>,
Matt Helsley <matt.helsley-AT-gmail.com>,
Mimi Zohar <zohar-AT-us.ibm.com> |
| Archive‑link: | |
Article |
On Wed, Mar 21, 2012 at 02:54:15PM -0400, Mimi Zohar wrote:
> If a file is closed before it is munmapped, __fput() is called with
> the mmap_sem taken. With IMA-appraisal enabled, this results in an
> mmap_sem/i_mutex lockdep. ima_defer_fput() increments the f_count
> to defer __fput() being called until after the mmap_sem is released.
NAK. It's far too heavy-weight for what's a very common path. Worse,
it causes different locking conditions on IMA and non-IMA kernels and makes
bugs harder to spot. Rejected with extreme prejudice; please, fix your
locking instead.
BTW, you've missed several other places in mm/* doing fput(), so it wouldn't
be enough to paper over your problem anyway.
Final fput() *can* happen under mmap_sem. Period.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
