linux-kernel - Re: [PATCH 1/6 v7] vfs: add i

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=dyEoBVAPLMfuG4_jVencSW00PeE3_z+APsL=t@mail.gmail.com>
Date:	Tue, 22 Mar 2011 11:37:06 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	apw@...onical.com, nbd@...nwrt.org, neilb@...e.de
Subject: Re: [PATCH 1/6 v7] vfs: add i_op->open()

On Tue, Mar 22, 2011 at 11:12 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
>>
>> Why don't you just pass in the filp to the ->open routine, and drop
>> that "flags" argument. Maybe other filesystems want to use ->open, but
>> don't want to put_filp() on the filp we already allocated, only to
>> allocate a new one?
>
> Maybe, although I don't see the reason to do that.  Why keep the
> original one?  It doesn't contain any information besides the flags
> and the dentry/vfsmount.

Umm? Because that way you can avoid allocating a new one?

So let's turn your questions on its head: why do you insist on
free'ing the old one, WHEN YOU KNOW THAT THE ->open ROUTINE NEEDS TO
ALLOCATE A NEW ONE?

Sure, in _your_ case, you'll get a new filp because you're going to do
a whole new open of a lower-level filesystem, but if the ->open
routine is all about just your case, then I don't want it as a VFS
layer operation. So for your filesystem, you will always discard the
old one as useless. But that's purely an implementation detail for
you. It has nothing to do with the VFS interfaces.

So why do that idiotic free, only to force the callee to then
re-allocate a new "struct file"?

                           Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/