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?"

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