linux-kernel - Re: lseek() on debugfs entries in 2.6.37

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Mar 2011 15:36:42 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Alexey Mikhailov <karma@...ois.botik.ru>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: lseek() on debugfs entries in 2.6.37

On Tue, Mar 15, 2011 at 03:54:14PM +0300, Alexey Mikhailov wrote:
> Hello!
> 
> I use simple debugfs entries for user-space <-> kernel-space
> interaction. Basically I read unsigned integers from debugfs
> files like this:

What debugfs file? Is this something you created?

> 
>    ...
>    char buf[64];
>    lseek(timesync_fd, 0, SEEK_SET);
>    read(timesync_fd, buf, sizeof(buf));
>    ...
> 
> It works perfectly with 2.6.32 kernel. But with 2.6.37 kernel,
> lseek() fails with errno=29(Illegal seek). So second read()
> call just fails or returns garbage. Can someone please shed
> some light on it?
> 

There's been a lot of clean ups in the debugfs to patch lseek in files
that just didn't support it. Could be one of the files that got the
clean up. The lseek may have failed silently before, but now it
produceses an error.

-- Steve

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