On Sat, Dec 02, 2023 at 01:34:32PM -0800, Kees Cook wrote:
> On Sat, Dec 02, 2023 at 09:28:46PM +, Al Viro wrote:
> > On Sat, Dec 02, 2023 at 01:22:13PM -0800, Kees Cook wrote:
> > > Allow __free(iput) markings for easier cleanup on inode allocations.
> >
> > NAK. That's a bloody awful idea f
On Sat, Dec 02, 2023 at 09:42:12PM +, Al Viro wrote:
> I'll poke around and see what I can suggest; said that, one thing I have
> spotted there on the quick look is that you are exposing hashed dentry
> associated
> with your inode before you set its ->i_private.
... and on the second look,
On Sat, Dec 02, 2023 at 01:34:32PM -0800, Kees Cook wrote:
> On Sat, Dec 02, 2023 at 09:28:46PM +, Al Viro wrote:
> > On Sat, Dec 02, 2023 at 01:22:13PM -0800, Kees Cook wrote:
> > > Allow __free(iput) markings for easier cleanup on inode allocations.
> >
> > NAK. That's a bloody awful idea f
On Sat, Dec 02, 2023 at 09:28:46PM +, Al Viro wrote:
> On Sat, Dec 02, 2023 at 01:22:13PM -0800, Kees Cook wrote:
> > Allow __free(iput) markings for easier cleanup on inode allocations.
>
> NAK. That's a bloody awful idea for that particular data type, since
> 1) ERR_PTR(...) is not un
On Sat, Dec 02, 2023 at 01:22:13PM -0800, Kees Cook wrote:
> Allow __free(iput) markings for easier cleanup on inode allocations.
NAK. That's a bloody awful idea for that particular data type, since
1) ERR_PTR(...) is not uncommon and passing it to iput() is a bug.
2) the common p
Allow __free(iput) markings for easier cleanup on inode allocations.
Cc: Christian Brauner
Cc: Peter Zijlstra (Intel)
Cc: Alexander Viro
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Kees Cook
---
include/linux/fs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/fs.h b
