linux-kernel - Re: [PATCH vfs 2/2] {block|char}_dev: remove inode->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: <20141120141942.GD14877@htj.dyndns.org>
Date:	Thu, 20 Nov 2014 09:19:42 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Boaz Harrosh <boaz@...xistor.com>
Cc:	Jens Axboe <axboe@...nel.dk>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH vfs 2/2] {block|char}_dev: remove inode->i_devices

On Thu, Nov 20, 2014 at 04:14:29PM +0200, Boaz Harrosh wrote:
> On 11/20/2014 03:11 PM, Tejun Heo wrote:
> > Hello, Boaz.
> > 
> <>
> > W/ preloading, one way to do it is,
> > 
> > 	if (preload())
> > 		handle -ENOMEM;
> > 	lock;
> > 	error = insert();
> > 	if (error)
> > 		handle error which can't be -ENOMEM;
> > 	unlock;
> > 	preload_end();
> > 
> 
> I like this one, cause of the place I come from. Where
> in a cluster you want the local fails as early as possible
> before you start to commit remotely, and need to undo on
> errors.
> 
> And I can see the real flow of things
> 
> > Another way is
> > 
> > 	preload();	// can't fail
> > 	lock;
> > 	error = insert();
> > 	if (error)
> > 		handle error;'
> > 	unlock;
> > 	preload_end();
> > 
> > Both ways have pros and cons.  The latter seems to lead to simpler
> > code in general.  Not always, but the overall.
> > 
> 
> I still like the over all simplicity of the above pattern to
> this behind the seen complexity hidden away under the carpet.

Maybe the right thing to do is allowing both.  It really depends on
the use cases.  For a lot of cases, the error handling and unrolling
are necessary anyway so the deferred preload failure doesn't add any
complexity but there are cases where the insertion can be guaranteed
to succeed.  The only change necessary is making preload return
-ENOMEM which can be ignored by the caller anyway.  The caller can
either ignore and handle the deferred failure later or handle it and
know that later insertion won't fail with -ENOMEM.

Anyways, let's see how minimal linked list implementation works out.

Thanks.

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