Re: lseek on /proc/kmsg

From: linux-os
Date: Tue Mar 22 2005 - 16:46:41 EST


On Tue, 22 Mar 2005, Jan Engelhardt wrote:

Gawd, you are a hacker. I already have to suck on pipes
because I can't seek them. Now, I can't even seek a
file-system???!!

Here goodie goodie...

diff -pdru linux-2.6.11.4/fs/proc/kmsg.c linux-2.6.11-AS9/fs/proc/kmsg.c
--- linux-2.6.11.4/fs/proc/kmsg.c 2005-03-21 20:14:58.000000000 +0100
+++ linux-2.6.11-AS9/fs/proc/kmsg.c 2005-03-22 21:28:40.000000000 +0100
@@ -46,10 +46,15 @@ static unsigned int kmsg_poll(struct fil
return 0;
}

+static loff_t kmsg_seek(struct file *filp, loff_t offset, int origin) {
+ if(origin != 2 /* SEEK_END */ || offset < 0) { return -ESPIPE; }
+ return do_syslog(5, NULL, 0);
+}

struct file_operations proc_kmsg_operations = {
.read = kmsg_read,
.poll = kmsg_poll,
.open = kmsg_open,
.release = kmsg_release,
+ .llseek = kmsg_seek,
};


Works so far that do_syslog is called with the correct parameters --
however, that does not work. (Did I discover a bug?)

# rcsyslog stop; # so that kmsg is not slurped by someone else
# perl -le 'open X,"</proc/kmsg";seek X,0,2;print read X,$b,3'

the perl command should block, because with the seek(), we've just emptied the
syslog ring buffer. Obviously, it does not, and read() succeeds - prints 3.
Any hints on what's wrong here?


Sure, read() needs to be modified to respect the file-position
set by kmsg_seek(). I don't think you can get away with the
call back into do_syslog.

In other words we shouldn't move a user-mode hack into the
kernel.


Jan Engelhardt
--


Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/