[BUG] Alpha (EV56), lseek64, and /dev/kmem

[BUG] Alpha (EV56), lseek64, and /dev/kmem

[Kelledin]

I just found that on my Alpha box, lseek64() has a bit of 
difficulty seeking through /dev/kmem to extremely high 
values--specifically, any value >=0x8000000000000000 (the 64th 
bit set).  Whenever it's supposed to seek to (and return) such a 
value, lseek64() returns -1 instead and sets errno to a 
seemingly random garbage value.  Userspace has no real choice 
except to interpret this as an error.

So far it's doing this on both xfs and ext2/3, so I'm betting 
it's fs-independent.  I suppose it could be the kmem driver 
itself deciding to be quirky?  I have no way of knowing if 
lseek64() will stumble like this on a real file, as I'd probably 
need more drive space than God to test that!

This wouldn't be a problem, except for stuff like klogd that 
seeks through /dev/kmem to discover module symbols.  This little 
quirk tends to make klogd segfault, it seems. :(

In case it matters:

Kernel:		2.4.21+SGI XFS 1.3.0
gcc:		3.2.3
glibc:		2.3.2
binutils:	2.14
modutils:	2.4.25
sysklogd:	1.4.1
distro:		generic from-scratch build

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"

Re: [BUG] Alpha (EV56), lseek64, and /dev/kmem

[Måns Rullgård]

Kelledin <kelledin+LKML@skarpsey.dyndns.org> writes:

> I just found that on my Alpha box, lseek64() has a bit of 
> difficulty seeking through /dev/kmem to extremely high 
> values--specifically, any value >=0x8000000000000000 (the 64th 
> bit set).  Whenever it's supposed to seek to (and return) such a 
> value, lseek64() returns -1 instead and sets errno to a 
> seemingly random garbage value.  Userspace has no real choice 
> except to interpret this as an error.
>
> So far it's doing this on both xfs and ext2/3, so I'm betting 

/dev/kmem hasn't anything to do with filesystems, right?

> it's fs-independent.  I suppose it could be the kmem driver 
> itself deciding to be quirky?  I have no way of knowing if 
> lseek64() will stumble like this on a real file, as I'd probably 
> need more drive space than God to test that!

You could create a sparse file, but I don't think any filesystem
support that big files.

-- 
Måns Rullgård
mru@users.sf.net

Re: [BUG] Alpha (EV56), lseek64, and /dev/kmem

[Kelledin]

On Friday 03 October 2003 08:08 pm, Måns Rullgård wrote:
> /dev/kmem hasn't anything to do with filesystems, right?

I suspected as much.

After a bit of consideration and some poking around the kernel 
source, I'm guessing the vfs layer interprets any negative value 
from an llseek vfsop as an error condition (even if it's just a 
very large 64-bit offset).  Obviously this wouldn't be a problem 
for most stuff--as you say, I doubt any fs (virtual or 
non-virtual) was intended to support such large files.  This 
situation with /dev/kmem on 64-bit machines is just an 
exceptional (and exceptionally annoying) corner case.

So far I see three possibilities:

1) fix the VFS layer so it accepts certain very large 64-bit 
quantities as valid quantities.  This would probably be a 
significant kernel rework...and I hate that, especially on an 
already-released stable branch (i.e. 2.4) or a branch very close 
to pre-release (i.e. 2.5/2.6).  I'd say save this for 2.7 and 
take care of it then.

2) migrate klogd to use query_module() rather than stepping 
through /dev/kmem.  query_module() should provide everything 
that klogd normally pokes around /dev/kmem for.  Does it rely 
indirectly on being able to step through kmem?  I hope not...

3) switch to a system/kernel logger that already supports 
query_module().  is there such a beast?  is there, perhaps, a 
patch for the de facto sysklogd?

Who maintains sysklogd-1.4.1, anyways?  It seems to be a fairly 
antiquated hunk of junk...

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"

[PATCH] sysklogd: use up-to-date query_module() routine

[Kelledin]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Friday 03 October 2003 08:36 pm, Kelledin wrote:
> 2) migrate klogd to use query_module() rather than stepping
> through /dev/kmem.  query_module() should provide everything
> that klogd normally pokes around /dev/kmem for.  Does it rely
> indirectly on being able to step through kmem?  I hope not...

Well, I settled on this option, and I've got something that seems 
to work.  The kmem walker hack is no longer needed, the llseek() 
VFS limitations are now a pretty moot point, and an 
obsolete/dangerous syscall got nudged further towards oblivion.

(Oh, and klogd no longer segv's on my EV56 box, which was really 
the point of this exercise to begin with. ;)

I've attached the patch below in case anyone is interested; I 
also sent it off to the sysklogd maintainers (finally found 
them).  Testing and constructive criticism is encouraged.

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"

[-- Attachment #2: sysklogd-1.4.1-querymodules.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 3142 bytes --]