linux-kernel - Re: [PATCH] sony_pi: Remove the BKL from sonypi_misc

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]

Message-ID: <20091025073027.GA1226@infradead.org>
Date:	Sun, 25 Oct 2009 03:30:27 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Arnd Bergmann <arndbergmann@...glemail.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	John Kacur <jkacur@...hat.com>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sony_pi: Remove the BKL from sonypi_misc_open

On Thu, Oct 22, 2009 at 03:50:04PM +0200, Arnd Bergmann wrote:
> Is it safe to assume that file_operations without a read() or write()
> method also don't need llseek?

There are two reasons why a driver could need llseek:

 (a) it uses the file position somewhere.  Normally that's just in
     read/write, but I wouldn't be surprised if there are drivers using
     the file position somewhere in weird ioctls.
 (b) because broken userland assumes they can seek on the file
     descriptor.  For example some versions of tar expect lseek to work
     on tape devices despite them not actually using the file position
     anywere.

So the answer to your above questions is: most likely yes, but and audit
for a) should be performed.  We can't do much about (b) except for trial
and error.  Unless there are very important applications expecting to be
able to seek I think returning the correct error is more important than
having zero change in behaviour.

> Testing for S_IFREG will not work well for debugfs, which is probably
> a large number of the cases that do not want an llseek method.

Yes.  S_IFREG should be done last, and probably the real filesystem
should be converted to always have a llseek method before tackling the
mess in the synthetic filesystems.

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