linux-kernel - Re: [PATCH 1/2] BKL: Remove BKL from default

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:	Thu, 19 Nov 2009 10:13:30 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Oliver Neukum <oliver@...kum.org>, Jan Blunck <jblunck@...e.de>,
	linux-fsdevel@...r.kernel.org,
	Linux-Kernel Mailinglist <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, jkacur@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>,
	Arnd Bergmann <arnd@...db.de>,
	Christoph Hellwig <hch@...radead.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 1/2] BKL: Remove BKL from default_llseek()

> That was implicit in my question: Are there any seekable devices where
> bytes read != offset delta, and if yes, is that correct behaviour, a
> bug, or a silly interface that should go away?

It's neither a bug nor silly, although some of our users of it are a bit
strange.

Consider a block based device. It makes complete sense then that a short
read (eg user space passing a small buffer) causes the seek position to
move on one block. Ditto a block based system with EOF markers might do
that (eg some tape systems).

In the weirdness (but API) category we have things like the MSR driver
which returns an entire MSR for each byte offset.

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