From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [RFC] readdir mess Date: Tue, 12 Aug 2008 13:02:59 -0700 (PDT) Message-ID: References: <20080812062241.GQ28946@ZenIV.linux.org.uk> <87ej4u9nf5.fsf@devron.myhome.or.jp> <20080812181057.GR28946@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: OGAWA Hirofumi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Al Viro Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:37402 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751951AbYHLUDd (ORCPT ); Tue, 12 Aug 2008 16:03:33 -0400 In-Reply-To: <20080812181057.GR28946@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 12 Aug 2008, Al Viro wrote: > > Doesn't work well for readdir(2)... Sure it does. > > error = vfs_readdir(file, filldir, &buf); > > lastdirent = buf.previous; > > if (lastdirent) { > > error = count - buf.count; > > if (put_user(file->f_pos, &lastdirent->d_off)) > > error = -EFAULT; > > } > > fput(file); > > return error; > > > > and we wouldn't need any other logic at all. > > you've just lost e.g. -EIO for getdents(). No I've not. If we returned a partial result, we _should_ return a partial result. And if we got EIO on the first entry, we should return EIO. The _current_ code is crap. It sometimes returns the error (if the ->readdir() function returned error), and sometimes returns the partial result (if the "buf.error" was set). > Frankly, I'd rather keep ->readdir() instances simpler. There are far > more of those, for one thing. As it is, we only have "stop"/"continue" > ->readdir() has to care about... Keeping them simple (and not changing them - always returning zero is what the _original_ readdir() thing did!) is why the current situation exists. So if we keep it that way, then we really *KEEP* it that way. Don't go around changing any of the existing rules. Just make sure that the callbacks keep on always returning negative or zero (and never positive). Linus