On Thu, 2005-08-18 at 16:07 +0200, Arjan van de Ven wrote:
> > Whilst there's no normal legitimite usage for it, it is useful for
> > debugging.
> > One thing I often do is create a circular log buffer, then fish it back
> > out by mmaping /dev/mem or /dev/kmem, and going by system.map offsets.
> Whilst there's no normal legitimite usage for it, it is useful for debugging.
> One thing I often do is create a circular log buffer, then fish it back
> out by mmaping /dev/mem or /dev/kmem, and going by system.map offsets.
> No, nobody could claim it was clean or elegant, but it *is* useful.
--Arjan van de Ven <[EMAIL PROTECTED]> wrote (on Saturday, August 13, 2005
18:50:10 +0200):
> On Fri, 2005-08-12 at 09:35 -0700, Linus Torvalds wrote:
>>
>> On Thu, 11 Aug 2005, Steven Rostedt wrote:
>> >
>> > Found the problem. It is a bug with mmap_kmem. The order of checks is
>> > wrong,
--Arjan van de Ven [EMAIL PROTECTED] wrote (on Saturday, August 13, 2005
18:50:10 +0200):
On Fri, 2005-08-12 at 09:35 -0700, Linus Torvalds wrote:
On Thu, 11 Aug 2005, Steven Rostedt wrote:
Found the problem. It is a bug with mmap_kmem. The order of checks is
wrong, so here's the
Whilst there's no normal legitimite usage for it, it is useful for debugging.
One thing I often do is create a circular log buffer, then fish it back
out by mmaping /dev/mem or /dev/kmem, and going by system.map offsets.
No, nobody could claim it was clean or elegant, but it *is* useful.
On Thu, 2005-08-18 at 16:07 +0200, Arjan van de Ven wrote:
Whilst there's no normal legitimite usage for it, it is useful for
debugging.
One thing I often do is create a circular log buffer, then fish it back
out by mmaping /dev/mem or /dev/kmem, and going by system.map offsets.
No,
On Wed, 2005-08-17 at 00:33 +0100, Alan Cox wrote:
>
> If you use /dev/mem you should know what you are doing. Even with
> "checks" dd if=/dev/zero of=/dev/mem will do bad things. Trapping
> obviously bad cases is fine, but complete sanity checking may actually
> be counter productive.
>
On Maw, 2005-08-16 at 17:12 -0500, Greg Edwards wrote:
> mmap_mem suffers from a lack of proper checks as well. For example, on
> Altix page 0 of each node is reserved for prom and a read or write to it
> will cause an MCA. mmaping /dev/mem with offset 0 will nicely explode.
> Would adding a
On Sat, Aug 13, 2005 at 08:18:07PM +0200, Arjan van de Ven wrote:
| On Sat, 2005-08-13 at 10:37 -0700, Linus Torvalds wrote:
| > Actually, the more I looked at that mmap_kmem() function, the less I liked
| > it. Let's get that sucker fixed better first. It's still not wonderful,
| > but at
On Sat, Aug 13, 2005 at 08:18:07PM +0200, Arjan van de Ven wrote:
| On Sat, 2005-08-13 at 10:37 -0700, Linus Torvalds wrote:
| Actually, the more I looked at that mmap_kmem() function, the less I liked
| it. Let's get that sucker fixed better first. It's still not wonderful,
| but at least
On Maw, 2005-08-16 at 17:12 -0500, Greg Edwards wrote:
mmap_mem suffers from a lack of proper checks as well. For example, on
Altix page 0 of each node is reserved for prom and a read or write to it
will cause an MCA. mmaping /dev/mem with offset 0 will nicely explode.
Would adding a
On Wed, 2005-08-17 at 00:33 +0100, Alan Cox wrote:
If you use /dev/mem you should know what you are doing. Even with
checks dd if=/dev/zero of=/dev/mem will do bad things. Trapping
obviously bad cases is fine, but complete sanity checking may actually
be counter productive.
Sometimes dd
On Mon, 15 Aug 2005, Steven Rostedt wrote:
> On Mon, 2005-08-15 at 21:16 -0400, Steven Rostedt wrote:
>
> > Sorry for the late reply, my wife's Grandmother just passed away a few
> > days ago (at 98 years old) and if I went within 6 feet of the computer
> > she would have killed me!
>
> Just
On Mon, 2005-08-15 at 21:16 -0400, Steven Rostedt wrote:
> Sorry for the late reply, my wife's Grandmother just passed away a few
> days ago (at 98 years old) and if I went within 6 feet of the computer
> she would have killed me!
Just to clearify, "she" as in my wife would have killed me. Not
On Sat, 2005-08-13 at 10:37 -0700, Linus Torvalds wrote:
>
> On Sat, 13 Aug 2005, Arjan van de Ven wrote:
> >
> > attached is the same patch but now with Steven's change made as well
>
> Actually, the more I looked at that mmap_kmem() function, the less I liked
> it. Let's get that sucker
On Mon, 15 Aug 2005, Olaf Hering wrote:
>
> ARCH=um doesnt like your version, but mine.
Yours is broken. As is arch-um.
The fix would _seem_ to be something like the appended. Can you verify?
Linus
diff --git a/include/asm-um/page.h b/include/asm-um/page.h
---
On Mon, Aug 15, Jeff Dike wrote:
> On Mon, Aug 15, 2005 at 09:33:07PM +0200, Olaf Hering wrote:
> > ARCH=um doesnt like your version, but mine.
> >
> > drivers/char/mem.c:267: error: invalid operands to binary <<
> >
> > pfn = (__pa((u64)vma->vm_pgoff) << PAGE_SHIFT) >> PAGE_SHIFT;
>
On Mon, Aug 15, 2005 at 09:33:07PM +0200, Olaf Hering wrote:
> ARCH=um doesnt like your version, but mine.
>
> drivers/char/mem.c:267: error: invalid operands to binary <<
>
> pfn = (__pa((u64)vma->vm_pgoff) << PAGE_SHIFT) >> PAGE_SHIFT;
My page.h was missing some parens. Try the patch
On Sat, Aug 13, 2005 at 10:37:03AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 13 Aug 2005, Arjan van de Ven wrote:
> >
> > attached is the same patch but now with Steven's change made as well
>
> Actually, the more I looked at that mmap_kmem() function, the less I liked
> it. Let's get that
On Sat, Aug 13, 2005 at 10:37:03AM -0700, Linus Torvalds wrote:
On Sat, 13 Aug 2005, Arjan van de Ven wrote:
attached is the same patch but now with Steven's change made as well
Actually, the more I looked at that mmap_kmem() function, the less I liked
it. Let's get that sucker
On Mon, Aug 15, 2005 at 09:33:07PM +0200, Olaf Hering wrote:
ARCH=um doesnt like your version, but mine.
drivers/char/mem.c:267: error: invalid operands to binary
pfn = (__pa((u64)vma-vm_pgoff) PAGE_SHIFT) PAGE_SHIFT;
My page.h was missing some parens. Try the patch below.
On Mon, Aug 15, Jeff Dike wrote:
On Mon, Aug 15, 2005 at 09:33:07PM +0200, Olaf Hering wrote:
ARCH=um doesnt like your version, but mine.
drivers/char/mem.c:267: error: invalid operands to binary
pfn = (__pa((u64)vma-vm_pgoff) PAGE_SHIFT) PAGE_SHIFT;
My page.h was
On Mon, 15 Aug 2005, Olaf Hering wrote:
ARCH=um doesnt like your version, but mine.
Yours is broken. As is arch-um.
The fix would _seem_ to be something like the appended. Can you verify?
Linus
diff --git a/include/asm-um/page.h b/include/asm-um/page.h
---
On Sat, 2005-08-13 at 10:37 -0700, Linus Torvalds wrote:
On Sat, 13 Aug 2005, Arjan van de Ven wrote:
attached is the same patch but now with Steven's change made as well
Actually, the more I looked at that mmap_kmem() function, the less I liked
it. Let's get that sucker fixed better
On Mon, 2005-08-15 at 21:16 -0400, Steven Rostedt wrote:
Sorry for the late reply, my wife's Grandmother just passed away a few
days ago (at 98 years old) and if I went within 6 feet of the computer
she would have killed me!
Just to clearify, she as in my wife would have killed me. Not her
On Mon, 15 Aug 2005, Steven Rostedt wrote:
On Mon, 2005-08-15 at 21:16 -0400, Steven Rostedt wrote:
Sorry for the late reply, my wife's Grandmother just passed away a few
days ago (at 98 years old) and if I went within 6 feet of the computer
she would have killed me!
Just to
On Sat, 2005-08-13 at 10:37 -0700, Linus Torvalds wrote:
>
> On Sat, 13 Aug 2005, Arjan van de Ven wrote:
> >
> > attached is the same patch but now with Steven's change made as well
>
> Actually, the more I looked at that mmap_kmem() function, the less I liked
> it. Let's get that sucker
On Sat, 13 Aug 2005, Arjan van de Ven wrote:
>
> attached is the same patch but now with Steven's change made as well
Actually, the more I looked at that mmap_kmem() function, the less I liked
it. Let's get that sucker fixed better first. It's still not wonderful,
but at least now it tries
> I believe rootkit detectors, as well as some versions of ps (wchan
> field) use kmem.
ps doesn't use kmem, and besides, in 2.6 we export that directly in
proc. poking in /dev/mem or /dev/kmem is NOT something you "just do".
THere are lots of pitfalls, things like PCI space, memory sizes/holes,
On Sat, 2005-08-13 at 09:56 -0700, Linus Torvalds wrote:
>
> On Sat, 13 Aug 2005, Arjan van de Ven wrote:
> > >
> > > So I'd be perfectly happy to fix this, but I'd be even happier if we made
> > > the whole kmem thing a config variable (maybe even default it to "off").
> >
> > attached is a
On 8/13/05, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-08-12 at 09:35 -0700, Linus Torvalds wrote:
> >
> > On Thu, 11 Aug 2005, Steven Rostedt wrote:
> > >
> > > Found the problem. It is a bug with mmap_kmem. The order of checks is
> > > wrong, so here's the patch. Attached is a
On Sat, 13 Aug 2005, Arjan van de Ven wrote:
> >
> > So I'd be perfectly happy to fix this, but I'd be even happier if we made
> > the whole kmem thing a config variable (maybe even default it to "off").
>
> attached is a simple patch that does exactly this...
Well, you should have fixed the
On Fri, 2005-08-12 at 09:35 -0700, Linus Torvalds wrote:
>
> On Thu, 11 Aug 2005, Steven Rostedt wrote:
> >
> > Found the problem. It is a bug with mmap_kmem. The order of checks is
> > wrong, so here's the patch. Attached is a little program that reads the
> > System map looking for the
> Perfect! So it should be under CONFIG_DEBUG_KERNEL and default to off.
>
> So you can still debug and we raise the bar higher for rootkits,
> if they are the only other user.
>
> Too simple?
If you wanted to recompile your kernel to debug you could as well
add printks. But the whole point of
Hi Andi,
On Friday 12 August 2005 18:54, Andi Kleen wrote:
> Acessing vmalloc in /dev/mem would be pretty awkward. Yes it doesn't
> also work in mmap of /dev/kmem, but at least in read/write.
> There are quite a lot of scripts that use it for kernel debugging
> like dumping variables. And for
Hi Andi,
On Friday 12 August 2005 18:54, Andi Kleen wrote:
Acessing vmalloc in /dev/mem would be pretty awkward. Yes it doesn't
also work in mmap of /dev/kmem, but at least in read/write.
There are quite a lot of scripts that use it for kernel debugging
like dumping variables. And for that
Perfect! So it should be under CONFIG_DEBUG_KERNEL and default to off.
So you can still debug and we raise the bar higher for rootkits,
if they are the only other user.
Too simple?
If you wanted to recompile your kernel to debug you could as well
add printks. But the whole point of kmem
On Fri, 2005-08-12 at 09:35 -0700, Linus Torvalds wrote:
On Thu, 11 Aug 2005, Steven Rostedt wrote:
Found the problem. It is a bug with mmap_kmem. The order of checks is
wrong, so here's the patch. Attached is a little program that reads the
System map looking for the variable
On Sat, 13 Aug 2005, Arjan van de Ven wrote:
So I'd be perfectly happy to fix this, but I'd be even happier if we made
the whole kmem thing a config variable (maybe even default it to off).
attached is a simple patch that does exactly this...
Well, you should have fixed the bug that
On 8/13/05, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2005-08-12 at 09:35 -0700, Linus Torvalds wrote:
On Thu, 11 Aug 2005, Steven Rostedt wrote:
Found the problem. It is a bug with mmap_kmem. The order of checks is
wrong, so here's the patch. Attached is a little program
On Sat, 2005-08-13 at 09:56 -0700, Linus Torvalds wrote:
On Sat, 13 Aug 2005, Arjan van de Ven wrote:
So I'd be perfectly happy to fix this, but I'd be even happier if we made
the whole kmem thing a config variable (maybe even default it to off).
attached is a simple patch that
I believe rootkit detectors, as well as some versions of ps (wchan
field) use kmem.
ps doesn't use kmem, and besides, in 2.6 we export that directly in
proc. poking in /dev/mem or /dev/kmem is NOT something you just do.
THere are lots of pitfalls, things like PCI space, memory sizes/holes,
On Sat, 13 Aug 2005, Arjan van de Ven wrote:
attached is the same patch but now with Steven's change made as well
Actually, the more I looked at that mmap_kmem() function, the less I liked
it. Let's get that sucker fixed better first. It's still not wonderful,
but at least now it tries to
On Sat, 2005-08-13 at 10:37 -0700, Linus Torvalds wrote:
On Sat, 13 Aug 2005, Arjan van de Ven wrote:
attached is the same patch but now with Steven's change made as well
Actually, the more I looked at that mmap_kmem() function, the less I liked
it. Let's get that sucker fixed better
On Fri, Aug 12, 2005 at 07:56:26PM +0200, Arjan van de Ven wrote:
> On Fri, 2005-08-12 at 18:54 +0200, Andi Kleen wrote:
> > Linus Torvalds <[EMAIL PROTECTED]> writes:
> > >
> > > I'm actually more inclined to try to deprecate /dev/kmem.. I don't think
> > > anybody has ever really used it
On Fri, 2005-08-12 at 18:54 +0200, Andi Kleen wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
> > I'm actually more inclined to try to deprecate /dev/kmem.. I don't think
> > anybody has ever really used it except for some rootkits.
>
> I don't think that's true.
got any examples ?
>
On Fri, 12 Aug 2005, Arjan van de Ven wrote:
> > Again, I'm asking to have it turned into a config option. Even default to
> > off. I understand that /dev/kmem shouldn't be in a production machine.
> > There's no reason for it. But it is nice to have when debugging the
> > kernel. I'll make the
On Fri, 2005-08-12 at 13:07 -0400, Steven Rostedt wrote:
>
> On Fri, 12 Aug 2005, Dave Jones wrote:
> >
> > The above patches were in -mm for a while, though they didn't
> > have a config option, they just 'did it', and some of the
> > changes were a bit unclean, but I can polish that up if
On Fri, 12 Aug 2005, Dave Jones wrote:
>
> The above patches were in -mm for a while, though they didn't
> have a config option, they just 'did it', and some of the
> changes were a bit unclean, but I can polish that up if you're
> interested.
Again, I'm asking to have it turned into a config
On Fri, 12 Aug 2005, Linus Torvalds wrote:
>
> I'm actually more inclined to try to deprecate /dev/kmem.. I don't think
> anybody has ever really used it except for some rootkits. It only exists
> in the first place because it's historical.
>
> We do need to support /dev/mem for X, but even that
On Fri, Aug 12, 2005 at 09:35:03AM -0700, Linus Torvalds wrote:
> On Thu, 11 Aug 2005, Steven Rostedt wrote:
> >
> > Found the problem. It is a bug with mmap_kmem. The order of checks is
> > wrong, so here's the patch. Attached is a little program that reads the
> > System map looking
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> I'm actually more inclined to try to deprecate /dev/kmem.. I don't think
> anybody has ever really used it except for some rootkits.
I don't think that's true.
> So I'd be perfectly happy to fix this, but I'd be even happier if we made
> the
On Thu, 11 Aug 2005, Steven Rostedt wrote:
>
> Found the problem. It is a bug with mmap_kmem. The order of checks is
> wrong, so here's the patch. Attached is a little program that reads the
> System map looking for the variable modprobe_path. If it finds it, then
> it opens /dev/kmem for
On Thu, 11 Aug 2005, Steven Rostedt wrote:
>
> Found the problem. It is a bug with mmap_kmem. The order of checks is
> wrong, so here's the patch.
> - if (!pfn_valid(vma->vm_pgoff))
> - return -EIO;
> val = (u64)vma->vm_pgoff << PAGE_SHIFT;
> vma->vm_pgoff =
On Thu, 11 Aug 2005, Steven Rostedt wrote:
Found the problem. It is a bug with mmap_kmem. The order of checks is
wrong, so here's the patch.
- if (!pfn_valid(vma-vm_pgoff))
- return -EIO;
val = (u64)vma-vm_pgoff PAGE_SHIFT;
vma-vm_pgoff = __pa(val)
On Thu, 11 Aug 2005, Steven Rostedt wrote:
Found the problem. It is a bug with mmap_kmem. The order of checks is
wrong, so here's the patch. Attached is a little program that reads the
System map looking for the variable modprobe_path. If it finds it, then
it opens /dev/kmem for read
Linus Torvalds [EMAIL PROTECTED] writes:
I'm actually more inclined to try to deprecate /dev/kmem.. I don't think
anybody has ever really used it except for some rootkits.
I don't think that's true.
So I'd be perfectly happy to fix this, but I'd be even happier if we made
the whole
On Fri, Aug 12, 2005 at 09:35:03AM -0700, Linus Torvalds wrote:
On Thu, 11 Aug 2005, Steven Rostedt wrote:
Found the problem. It is a bug with mmap_kmem. The order of checks is
wrong, so here's the patch. Attached is a little program that reads the
System map looking for the
On Fri, 12 Aug 2005, Linus Torvalds wrote:
I'm actually more inclined to try to deprecate /dev/kmem.. I don't think
anybody has ever really used it except for some rootkits. It only exists
in the first place because it's historical.
We do need to support /dev/mem for X, but even that might
On Fri, 12 Aug 2005, Dave Jones wrote:
The above patches were in -mm for a while, though they didn't
have a config option, they just 'did it', and some of the
changes were a bit unclean, but I can polish that up if you're
interested.
Again, I'm asking to have it turned into a config
On Fri, 2005-08-12 at 13:07 -0400, Steven Rostedt wrote:
On Fri, 12 Aug 2005, Dave Jones wrote:
The above patches were in -mm for a while, though they didn't
have a config option, they just 'did it', and some of the
changes were a bit unclean, but I can polish that up if you're
On Fri, 12 Aug 2005, Arjan van de Ven wrote:
Again, I'm asking to have it turned into a config option. Even default to
off. I understand that /dev/kmem shouldn't be in a production machine.
There's no reason for it. But it is nice to have when debugging the
kernel. I'll make the changes
On Fri, 2005-08-12 at 18:54 +0200, Andi Kleen wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I'm actually more inclined to try to deprecate /dev/kmem.. I don't think
anybody has ever really used it except for some rootkits.
I don't think that's true.
got any examples ?
So I'd
On Fri, Aug 12, 2005 at 07:56:26PM +0200, Arjan van de Ven wrote:
On Fri, 2005-08-12 at 18:54 +0200, Andi Kleen wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I'm actually more inclined to try to deprecate /dev/kmem.. I don't think
anybody has ever really used it except for some
On Thu, 2005-08-11 at 17:36 -0400, Steven Rostedt wrote:
> OK, I thought I use to know this. But what is the difference
> between /dev/kmem and /dev/mem. I thought that with /dev/kmem you could
> use the actual kernel addresses to read from.
>
> For example, if I wanted to read the current
On Thu, 2005-08-11 at 17:36 -0400, Steven Rostedt wrote:
OK, I thought I use to know this. But what is the difference
between /dev/kmem and /dev/mem. I thought that with /dev/kmem you could
use the actual kernel addresses to read from.
For example, if I wanted to read the current variable
66 matches
Mail list logo
