From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12066 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general,gmane.linux.kernel,gmane.linux.file-systems,gmane.linux.kernel.api Subject: Re: [(resend)] seq_file: reset iterator to first record for zero offset Date: Wed, 8 Nov 2017 14:10:05 +0100 Message-ID: <20171108131005.GA15263@port70.net> References: <20161219113800.GE27207@veci.piliscsaba.szeredi.hu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1510146640 23118 195.159.176.226 (8 Nov 2017 13:10:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Nov 2017 13:10:40 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) Cc: Al Viro , Tomasz Majchrzak , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, musl@lists.openwall.com, Rich Felker To: Miklos Szeredi Original-X-From: musl-return-12082-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 08 14:10:32 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eCQ7k-0005eU-2M for gllmg-musl@m.gmane.org; Wed, 08 Nov 2017 14:10:32 +0100 Original-Received: (qmail 25970 invoked by uid 550); 8 Nov 2017 13:10:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 25787 invoked from network); 8 Nov 2017 13:10:17 -0000 Mail-Followup-To: Miklos Szeredi , Al Viro , Tomasz Majchrzak , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, musl@lists.openwall.com, Rich Felker Content-Disposition: inline In-Reply-To: <20161219113800.GE27207@veci.piliscsaba.szeredi.hu> Xref: news.gmane.org gmane.linux.lib.musl.general:12066 gmane.linux.kernel:2612203 gmane.linux.file-systems:128808 gmane.linux.kernel.api:25532 Archived-At: * Miklos Szeredi [2016-12-19 12:38:00 +0100]: > Al, > > Can you please take (or NACK) this patch please? > > Thanks, > Miklos > --- > From: Tomasz Majchrzak > Date: Tue, 29 Nov 2016 15:18:20 +0100 > > If kernfs file is empty on a first read, successive read operations > using the same file descriptor will return no data, even when data is > available. Default kernfs 'seq_next' implementation advances iterator > position even when next object is not there. Kernfs 'seq_start' for > following requests will not return iterator as position is already on > the second object. > > This defect doesn't allow to monitor badblocks sysfs files from MD raid. > They are initially empty but if data appears at some stage, userspace is > not able to read it. > > Signed-off-by: Tomasz Majchrzak > Signed-off-by: Miklos Szeredi > --- this patch broke userspace abi: commit e522751d605d99a81508e58390a8f51ee96fb662 Author: Tomasz Majchrzak AuthorDate: 2016-11-29 15:18:20 +0100 Commit: Al Viro CommitDate: 2016-12-22 23:03:06 -0500 seq_file: reset iterator to first record for zero offset reported in may at: https://bugzilla.kernel.org/show_bug.cgi?id=195697 read(fd,buf,0) on sysfs/procfs changes the behaviour of the next read: the next read reads the first line twice. same issue with readv() with a 0 length buffer. test code: #include #include #include int main(int argc, char* argv[]) { char buf1[512] = {0}; char buf2[512] = {0}; int fd; fd = open("/proc/mounts", O_RDONLY); if (read(fd, buf1, 0) < 0) return 1; if (read(fd, buf1, 512) < 0) return 1; lseek(fd, 0, SEEK_SET); if (read(fd, buf2, 512) < 0) return 1; // buf1 should be the same as buf2, // the first 512 bytes of /proc/mounts buf1[511]=buf2[511]='\n'; write(1, "# buf1:\n", 8); write(1, buf1, 512); // prints the first line twice write(1, "# buf2:\n", 8); write(1, buf2, 512); return memcmp(buf1, buf2, 512) != 0; } stdio in musl libc can use readv with 0 length buffer in some cases, and various tools use stdio to read these synthetic filesystems so this is observable regression between linux v4.9 and v4.10 (i think musl can avoid the 0 length buffer in stdio, but the linux behaviour is still incorrect. in general readv/writev could have more posix conform behaviour on sysfs/procfs, currently they don't behave as atomic fs operations which is surprising: writev with several buffers behaves as if several independent write syscalls were made instead of one, which can cause issues when users do 'echo 12 >/proc/foo' and writev is used in the stdio implementation) > fs/seq_file.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > --- a/fs/seq_file.c > +++ b/fs/seq_file.c > @@ -190,6 +190,13 @@ ssize_t seq_read(struct file *file, char > */ > m->version = file->f_version; > > + /* > + * if request is to read from zero offset, reset iterator to first > + * record as it might have been already advanced by previous requests > + */ > + if (*ppos == 0) > + m->index = 0; > + > /* Don't assume *ppos is where we left it */ > if (unlikely(*ppos != m->read_pos)) { > while ((err = traverse(m, *ppos)) == -EAGAIN)