29 Jan, 2008

1 commit

  • Current code could cause a bug in symbol_put_addr() if an arch used
    kmalloc module text: we might think the symbol belongs to the core
    kernel.

    The downside is that this might make backtraces through (discarded)
    init functions harder to read on some archs, but we already have that
    issue for modules and noone has complained.

    Signed-off-by: Rusty Russell

    Rusty Russell
     

16 May, 2006

1 commit

  • Even since a previous patch:

    Fix race between CONFIG_DEBUG_SLABALLOC and modules
    Sun, 27 Jun 2004 17:55:19 +0000 (17:55 +0000)
    http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=92b3db26d31cf21b70e3c1eadc56c179506d8fbe

    The function symbol_put_addr() will deadlock the kernel.

    symbol_put_addr() would acquire modlist_lock, then while holding the lock call
    two functions kernel_text_address() and module_text_address() which also try
    to acquire the same lock. This deadlocks the kernel of course.

    This patch changes symbol_put_addr() to not acquire the modlist_lock, it
    doesn't need it since it never looks at the module list directly. Also, it
    now uses core_kernel_text() instead of kernel_text_address(). The latter has
    an additional check for addr inside a module, but we don't need to do that
    since we call module_text_address() (the same function kernel_text_address
    uses) ourselves.

    Signed-off-by: Trent Piepho
    Cc: Zwane Mwaikambo
    Acked-by: Rusty Russell
    Cc: Johannes Stezenbach
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trent Piepho
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds