On Sat, 20 Jan 2007, Franck Bui-Huu wrote:
> On 1/19/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> That said, it's really confusing to pass a virtual address as an
> offset because:
>
>(a) mmap() has always worked with offset not addresses;
mmap maps some offset down a backing object to so
On 1/19/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Apology surely accepted, it's a confusing area (inevitably: in a driver
for mem, the distinction between addresses and offsets become blurred).
But please note, the worst of it was, that your patch comment gave no
hint that you were knowingly
> But personally I'd prefer it to remain.
Similar. I also got some tools who use it to read kernel variables
and doing the V->P conversion in user space would be tedious
and unreliable (e.g. for vmalloc)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Fri, 19 Jan 2007, Arjan van de Ven wrote:
> On Fri, 2007-01-19 at 17:12 +, Hugh Dickins wrote:
> > Though so long as /dev/mem support remains, /dev/kmem might as well?
>
> they're not the same; for a long time, /dev/mem on actual memory
> returned zeros... so you couldn't use it for rootkit
On Fri, 2007-01-19 at 17:12 +, Hugh Dickins wrote:
> On Fri, 19 Jan 2007, Arjan van de Ven wrote:
> > On Fri, 2007-01-19 at 16:33 +, Hugh Dickins wrote:
> > > Though I do wonder whether
> > > it was safe to change its behaviour at that stage: more evidence that
> > > few have actually been
On Fri, 19 Jan 2007, Arjan van de Ven wrote:
> On Fri, 2007-01-19 at 16:33 +, Hugh Dickins wrote:
> > Though I do wonder whether
> > it was safe to change its behaviour at that stage: more evidence that
> > few have actually been using mmap of /dev/kmem.
>
> ... and maybe we should just kill
On Fri, 19 Jan 2007, Franck Bui-Huu wrote:
> Hugh Dickins wrote:
> >
> > Please revert the offending patch below, and then maybe Franck
> > can come up with a patch which preserves the original behaviour
> > on architectures which used to work (e.g. i386), while fixing
> > it for those architecture
On Fri, 2007-01-19 at 16:33 +, Hugh Dickins wrote:
> Though I do wonder whether
> it was safe to change its behaviour at that stage: more evidence that
> few have actually been using mmap of /dev/kmem.
... and maybe we should just kill /dev/kmem entirely... it seems mostly
used by rootkits bu
On Fri, 19 Jan 2007, Nadia Derbey wrote:
> Hugh Dickins wrote:
> >
> > Sigh, you're right, 2.6.19 messed that up completely.
> > No, you never had to subtract PAGE_OFFSET from that address
> > in the past, and you shouldn't have to do so now.
Whoops, I should never have said "never". Checking fu
Hi,
Hugh Dickins wrote:
On Thu, 18 Jan 2007, Nadia Derbey wrote:
Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
I get an EIO error on a 2.6.20-rc4.
This is something that used to work on older kernels.
Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering wh
Hugh Dickins wrote:
On Thu, 18 Jan 2007, Nadia Derbey wrote:
Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
I get an EIO error on a 2.6.20-rc4.
This is something that used to work on older kernels.
Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering whethe
Hugh Dickins wrote:
On Thu, 18 Jan 2007, Nadia Derbey wrote:
Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
I get an EIO error on a 2.6.20-rc4.
This is something that used to work on older kernels.
Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering whethe
On Thu, 18 Jan 2007, Nadia Derbey wrote:
>
> Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
> I get an EIO error on a 2.6.20-rc4.
> This is something that used to work on older kernels.
>
> Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering whether
> pfn is
Hi there,
Trying to mmap /dev/kmem with an offset I take from /boot/System.map, I
get an EIO error on a 2.6.20-rc4.
This is something that used to work on older kernels.
Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering
whether pfn is correctly computed there: shouldn't we ha
14 matches
Mail list logo
