linux-ext4 - Re: Ping.

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] [day] [month] [year] [list]

Date:	Sat, 15 May 2010 10:34:41 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	Christoph Hellwig <hch@...radead.org>, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, tytso@....edu, adilger@....com,
	jack@...e.cz, david@...morbit.com, xemul@...nvz.org
Subject: Re: Ping.

On Thu, Apr 15, 2010 at 03:30:58PM +0400, Dmitry Monakhov wrote:

> > As long as you still have the awkward ifdefs and different semantics for
> About ifdefs style:
> How can i avoid CONFIG_PROJECT_ID without bloating inode size?
> embedded people will kill me for this.
> I just act similar quota code, or you want protect prjid logic 
> via quota config option?
> I don't remember, are we already talk about this?
> If so please remind me your vision.

You have way more ifdefs than just that.

E.g. struct iattr ones are pure junk; it's not kept around for long
time.  Moreover, since ATTR_... is not userland-reachable, you can
bloody well #define ATTR_PRJID to 0 and get rid of more ifdefs.
Ifdefs due to accesses to i_prjid can be reduced to just two inlined
helpers (get_prjid/set_prjid) and there you go...

As for the ->i_prjid itself, I'd buy ifdef there, but _not_ in that
place within structure.  You are shoving it between two pointers;
think of alignment.

As for the isolation...  Why do we care about link/rename at all?
All stuff with the same project ID gets counted together, wherever
in the tree it might be.  It's not as if we'd been scanning a subtree
and calculate the sum over it, after all.  So what is the problem?
Some bastard DoSing you by creating links from places you can't write
to?  Then you want as much isolation as possible anyway, TYVM, and
bind-as-link-barrier is entirely appropriate there.

> > "isolation" vs "not"  there's still a NACK from me.  But in the end Al
> > will have to decide if he wants to take your patches or not.

I want details on use cases and semantics for isolation stuff; as it is,
it looks rather odd.  Why move towards "neutral" part of the tree is
allowed and links over there are not, for example?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html