Mapping a memory address to all the processes using it

Mapping a memory address to all the processes using it

[Sandeep K Chaudhary]

Hi guys,

I am working on a hack which requires me to find all the processes
using a particular memory address. Lets say I get an MCE error
containing a memory address. I want to use this address to find all
the processes that might access it, and kill them before they do.
Please let me know if this is possible using some already implemented
routine.

I can think of a brute force method of looping though all the
processes and looking at the VMAs they are using to see if there is a
match for the address I have. But I want to do better than this brute
force method. Please let me know if this is possible.

Also, while looking for the same in Kernel tree, I found that it is
easy to do the reverse mapping i.e. finding the memory addresses a
process is using given the process, but this doesn't help with what I
intend to do.

Thanks and regards,
Sandeep.

Mapping a memory address to all the processes using it

[Valdis.Kletnieks at vt.edu]

On Wed, 26 Feb 2014 14:52:09 -0800, Sandeep K Chaudhary said:

> I am working on a hack which requires me to find all the processes
> using a particular memory address. Lets say I get an MCE error
> containing a memory address. I want to use this address to find all
> the processes that might access it, and kill them before they do.
> Please let me know if this is possible using some already implemented
> routine.

You mean like this in-tree code?

config MEMORY_FAILURE
        depends on MMU
        depends on ARCH_SUPPORTS_MEMORY_FAILURE
        bool "Enable recovery from hardware memory errors"
        select MEMORY_ISOLATION
        help
          Enables code to recover from some memory failures on systems
          with MCA recovery. This allows a system to continue running
          even when some of its memory has uncorrected errors. This requires
          special hardware support and typically ECC memory.

Oh, and if you want to test your code, there's this one:

config HWPOISON_INJECT
        tristate "HWPoison pages injector"
        depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
        select PROC_PAGE_MONITOR


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140226/d6a7552f/attachment-0001.bin 

Mapping a memory address to all the processes using it

[Sandeep K Chaudhary]

> You mean like this in-tree code?
>
> config MEMORY_FAILURE
>         depends on MMU
>         depends on ARCH_SUPPORTS_MEMORY_FAILURE
>         bool "Enable recovery from hardware memory errors"
>         select MEMORY_ISOLATION
>         help
>           Enables code to recover from some memory failures on systems
>           with MCA recovery. This allows a system to continue running
>           even when some of its memory has uncorrected errors. This requires
>           special hardware support and typically ECC memory.

Well, yeah. My case is also related to uncorrected errors and ECC
memory. I want to improve the handler that is invoked for
uncorrectable ECC errors. Once this sort of error occurs, it gives the
address where the error happened. And if we can identify the processes
involved with that memory, the handler can just kill them rather than
panicking the kernel.

I don't really know how the above in-tree code will be helpful in my
case. Can you please explain it a little to me?

-- 
Thanks and regards,
Sandeep K Chaudhary.

Mapping a memory address to all the processes using it

[Valdis.Kletnieks at vt.edu]

On Wed, 26 Feb 2014 17:19:49 -0800, Sandeep K Chaudhary said:
> > You mean like this in-tree code?
> >
> > config MEMORY_FAILURE
> >         depends on MMU
> >         depends on ARCH_SUPPORTS_MEMORY_FAILURE
> >         bool "Enable recovery from hardware memory errors"
> >         select MEMORY_ISOLATION
> >         help
> >           Enables code to recover from some memory failures on systems
> >           with MCA recovery. This allows a system to continue running
> >           even when some of its memory has uncorrected errors. This require
s
> >           special hardware support and typically ECC memory.
>
> Well, yeah. My case is also related to uncorrected errors and ECC
> memory. I want to improve the handler that is invoked for
> uncorrectable ECC errors. Once this sort of error occurs, it gives the
> address where the error happened. And if we can identify the processes
> involved with that memory, the handler can just kill them rather than
> panicking the kernel.
>
> I don't really know how the above in-tree code will be helpful in my
> case. Can you please explain it a little to me?

I'll let Andi Kleen do that...

commit 6a46079cf57a7f7758e8b926980a4f852f89b34d
Author: Andi Kleen <andi@firstfloor.org>
Date:   Wed Sep 16 11:50:15 2009 +0200

    HWPOISON: The high level memory error handler in the VM v7

    Add the high level memory handler that poisons pages
    that got corrupted by hardware (typically by a two bit flip in a DIMM
    or a cache) on the Linux level. The goal is to prevent everyone
    from accessing these pages in the future.

    This done at the VM level by marking a page hwpoisoned
    and doing the appropriate action based on the type of page
    it is.

    The code that does this is portable and lives in mm/memory-failure.c

    To quote the overview comment:

    High level machine check handler. Handles pages reported by the
    hardware as being corrupted usually due to a 2bit ECC memory or cache
    failure.

    This focuses on pages detected as corrupted in the background.
    When the current CPU tries to consume corruption the currently
    running process can just be killed directly instead. This implies
    that if the error cannot be handled for some reason it's safe to
    just ignore it because no corruption has been consumed yet. Instead
    when that happens another machine check will happen.

    Handles page cache pages in various states. The tricky part
    here is that we can access any page asynchronous to other VM
    users, because memory failures could happen anytime and anywhere,
    possibly violating some of their assumptions. This is why this code
    has to be extremely careful. Generally it tries to use normal locking
    rules, as in get the standard locks, even if that means the
    error handling takes potentially a long time.

    Some of the operations here are somewhat inefficient and have non
    linear algorithmic complexity, because the data structures have not
    been optimized for this case. This is in particular the case
    for the mapping from a vma to a process. Since this case is expected
    to be rare we hope we can get away with this.

    There are in principle two strategies to kill processes on poison:
    - just unmap the data and wait for an actual reference before
    killing
    - kill as soon as corruption is detected.
    Both have advantages and disadvantages and should be used
    in different situations. Right now both are implemented and can
    be switched with a new sysctl vm.memory_failure_early_kill
    The default is early kill.

    The patch does some rmap data structure walking on its own to collect
    processes to kill. This is unusual because normally all rmap data structure
    knowledge is in rmap.c only. I put it here for now to keep
    everything together and rmap knowledge has been seeping out anyways

    Includes contributions from Johannes Weiner, Chris Mason, Fengguang Wu,
    Nick Piggin (who did a lot of great work) and others.

    Cc: npiggin at suse.de
    Cc: riel at redhat.com
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Acked-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140226/81cbe523/attachment.bin 

Mapping a memory address to all the processes using it

[Sandeep K Chaudhary]

This is exactly the kind of information I was looking for. Thank you
so much, Valdis !