linux-kernel - Re: [PATCH 00/21] vfs: atomic open v6 (part 2)

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: <877gvdho6h.fsf@tucsk.pomaz.szeredi.hu>
Date:	Mon, 11 Jun 2012 17:18:46 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	hch@...radead.org, torvalds@...ux-foundation.org,
	dhowells@...hat.com
Subject: Re: [PATCH 00/21] vfs: atomic open v6 (part 2)

Al Viro <viro@...IV.linux.org.uk> writes:

>
> I'm more or less OK with that; one major exception is your struct opendata.
> I think it needs to go.  Really.  You are using it to store three references -
> file, vfsmount and dentry.

That's not the real purpose.  We can store those in struct file, I can
see that.

The real reason I went with a separate and opaque type there is that
that thing is simply not an open file.  If it was a struct file and the
filesystem would do an fput() on it by accident it would lead to really
ugly problems, and the complier would have no chance at detecting it.

If it's a separate type (and it can have just that struct file embedded
into it) then such mistakes are instantly detected by the compiler

So I really don't see the downsides of having a new type for that.

Thanks,
Miklos
--
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/