linux-kernel - Re: [PATCH v2] seq_file: copy as much as possible to user buffer in seq

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: <4256c3d6-5769-444a-84d5-3b416015bc34@web.de>
Date: Fri, 20 Dec 2024 15:34:12 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: David Wang <00107082@....com>, linux-fsdevel@...r.kernel.org,
 Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
 Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH v2] seq_file: copy as much as possible to user buffer in
 seq_read()

> seq_read() yields at most seq_file->size bytes to userspace, …

                                                    user space?


…
> 	$ strace -T -e read cat /proc/interrupts  > /dev/null
…
> 	 45 read(3, "", 131072)                     = 0 <0.000010>
> On a system with hundreds of cpus, it would need …

                               CPUs?


Is it a bit nicer to separate test output and subsequent comments by blank lines?


…
> Fill up user buffer as much as possible in seq_read(), extra read
> calls can be avoided with a larger user buffer, and 2%~10% performance
> improvement would be observed:
Will it help to split such a paragraph into three sentences
(on separate lines)?

Regards,
Markus