linux-kernel - Re: [PATCH 3/3] Add a pair of system calls to make extended file stats available [ver #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: <201006301444.11194.arnd@arndb.de>
Date:	Wed, 30 Jun 2010 14:44:10 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	David Howells <dhowells@...hat.com>
Cc:	viro@...iv.linux.org.uk, smfrench@...il.com, jlayton@...hat.com,
	mcao@...ibm.com, aneesh.kumar@...ux.vnet.ibm.com,
	linux-cifs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, samba-technical@...ts.samba.org,
	sjayaraman@...e.de, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 3/3] Add a pair of system calls to make extended file stats available [ver #2]

On Wednesday 30 June 2010, David Howells wrote:
> Arnd Bergmann <arnd@...db.de> wrote:
> 
> > Given a 64 bit flag word, you can start using bits for the version from
> > the top and bits from the bottom for fields:
> 
> I suppose.  It's cleaner, though, to keep them separate.

Yes, but it's a tradeoff. If separating them means you have to add
another structure, I'd prefer having just a flags word with different
kinds of bits. In particular since I don't think we actually need
to worry about wildly different layouts. If struct oldstat had
come with an extensibility concept like what you propose here, we
would not have needed newstat, stat64 and xstat.

> > Alternatively, you can also make it a 64 bit argument everywhere, which has
> > some other small disadvantages.
> 
> No, you can't.  32-bit systems can only pass 32-bit arguments.  If you're
> suggesting passing a pointer to a 64-bit argument instead, how's that any
> different from my suggestion of a separate parameter block?

I was thinking of splitting the 64 bit argument into two registers on
32 bit systems, like we do with other 64 bit input arguments (e.g. loff_t).
While there is not much of a difference, I'd always prefer passing
input arguments by register to a memory location when possible.

> > The idea of a syscall API with multiple fixed-length and variable-length
> > fields in the same structure scares me. If you want to go this far,
> > it may be better to base the interface on netlink and allow querying
> > multiple files at once.
> 
> Urgh.  Netlink is way too much overhead and even scarier.  That's pretty much
> a guarantee that people won't use it.  It also has to work if CONFIG_NET=n.

Exactly. Just resist the urge to add complexity bordering what we already
have in netlink.

	Arnd
--
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/