09 Oct, 2013

1 commit

  • As discussed in [1], exchange f_mapping->host with file_inode(). This
    is a bug, but happens to be non-manifest in this case.

    [1] http://lkml.kernel.org/r/20131007190357.GA13318@ZenIV.linux.org.uk

    Signed-off-by: Andre Richter
    Link: http://lkml.kernel.org/r/1381224142-3267-1-git-send-email-andre.o.richter@gmail.com
    Signed-off-by: H. Peter Anvin

    Andre Richter
     

15 Jul, 2013

1 commit

  • The __cpuinit type of throwaway sections might have made sense
    some time ago when RAM was more constrained, but now the savings
    do not offset the cost and complications. For example, the fix in
    commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
    is a good example of the nasty type of bugs that can be created
    with improper use of the various __init prefixes.

    After a discussion on LKML[1] it was decided that cpuinit should go
    the way of devinit and be phased out. Once all the users are gone,
    we can then finally remove the macros themselves from linux/init.h.

    Note that some harmless section mismatch warnings may result, since
    notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
    are flagged as __cpuinit -- so if we remove the __cpuinit from
    arch specific callers, we will also get section mismatch warnings.
    As an intermediate step, we intend to turn the linux/init.h cpuinit
    content into no-ops as early as possible, since that will get rid
    of these warnings. In any case, they are temporary and harmless.

    This removes all the arch/x86 uses of the __cpuinit macros from
    all C files. x86 only had the one __CPUINIT used in assembly files,
    and it wasn't paired off with a .previous or a __FINIT, so we can
    delete it directly w/o any corresponding additional change there.

    [1] https://lkml.org/lkml/2013/5/20/589

    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc: x86@kernel.org
    Acked-by: Ingo Molnar
    Acked-by: Thomas Gleixner
    Acked-by: H. Peter Anvin
    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

28 Feb, 2013

1 commit


25 Jan, 2013

1 commit

  • At the moment the MSR driver only relies upon file system
    checks. This means that anything as root with any capability set
    can write to MSRs. Historically that wasn't very interesting but
    on modern processors the MSRs are such that writing to them
    provides several ways to execute arbitary code in kernel space.
    Sample code and documentation on doing this is circulating and
    MSR attacks are used on Windows 64bit rootkits already.

    In the Linux case you still need to be able to open the device
    file so the impact is fairly limited and reduces the security of
    some capability and security model based systems down towards
    that of a generic "root owns the box" setup.

    Therefore they should require CAP_SYS_RAWIO to prevent an
    elevation of capabilities. The impact of this is fairly minimal
    on most setups because they don't have heavy use of
    capabilities. Those using SELinux, SMACK or AppArmor rules might
    want to consider if their rulesets on the MSR driver could be
    tighter.

    Signed-off-by: Alan Cox
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Peter Zijlstra
    Cc: Horses
    Signed-off-by: Ingo Molnar

    Alan Cox
     

23 Sep, 2012

1 commit

  • If arch/x86/kernel/msr.c is a module, a CPU might offline or online
    between the for_each_online_cpu(i) loop and the call to
    register_hotcpu_notifier in msr_init or the call to
    unregister_hotcpu_notifier in msr_exit. The potential races can lead
    to leaks/duplicates, attempts to destroy non-existant devices, or
    random pointer dereferences.

    For example, in msr_init if:

    for_each_online_cpu(i) {
    err = msr_device_create(i);
    if (err != 0)
    goto out_class;
    }

    Signed-off-by: Paul E. McKenney

    Silas Boyd-Wickizer
     

29 Mar, 2012

1 commit


04 Jan, 2012

1 commit


18 Nov, 2010

1 commit


28 May, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

27 Jan, 2010

1 commit


16 Dec, 2009

1 commit

  • register_chrdev() hardcodes registering 256 minors, presumably to
    avoid breaking old drivers. However, we need to register enough
    minors so that we have all possible CPUs.

    checkpatch warns on this patch, but the patch is correct: NR_CPUS here
    is a static *upper bound* on the *maximum CPU index* (not *number of
    CPUs!*) and that is what we want.

    Reported-and-tested-by: Russ Anderson
    Cc: Tejun Heo
    Cc: Alan Cox
    Cc: Takashi Iwai
    Cc: Alexander Viro
    Signed-off-by: H. Peter Anvin
    LKML-Reference:

    H. Peter Anvin
     

15 Dec, 2009

1 commit

  • The MSR driver would compute the values for cpu and c at declaration,
    and then again in the body of the function. This isn't merely
    redundant, but unsafe, since cpu might not refer to a valid CPU at
    that point.

    Remove the unnecessary and dangerous references in the declarations.
    This code now matches the equivalent code in the CPUID driver.

    Signed-off-by: H. Peter Anvin

    H. Peter Anvin
     

06 Dec, 2009

1 commit


08 Oct, 2009

1 commit

  • Remove the big kernel lock from msr_open() as it doesn't protect
    anything there.

    The only racy event that can happen here is a concurrent cpu shutdown.

    So let's look at what could be racy during/after the above event:

    - The cpu_online() check is racy, but the bkl doesn't help about
    that anyway it disables preemption but we may be chcking another
    cpu than the current one.
    Also the cpu can still become offlined between open and read calls.

    - The cpu_data(cpu) returns a safe pointer too. It won't be released on
    cpu offlining. But some fields can be changed from
    arch/x86/kernel/smpboot.c:remove_siblinginfo() :

    - phys_proc_id
    - cpu_core_id

    Those are not read from msr_open(). What we are checking is the
    x86_capability that is left untouched on offlining.

    So this removal looks safe.

    Signed-off-by: Frederic Weisbecker
    Cc: John Kacur
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Sven-Thorsten Dietrich
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Frederic Weisbecker
     

20 Sep, 2009

1 commit

  • This allows subsytems to provide devtmpfs with non-default permissions
    for the device node. Instead of the default mode of 0600, null, zero,
    random, urandom, full, tty, ptmx now have a mode of 0666, which allows
    non-privileged processes to access standard device nodes in case no
    other userspace process applies the expected permissions.

    This also fixes a wrong assignment in pktcdvd and a checkpatch.pl complain.

    Signed-off-by: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Kay Sievers
     

01 Sep, 2009

2 commits


16 Jun, 2009

1 commit


12 Jan, 2009

1 commit


04 Jan, 2009

1 commit

  • Impact: Reduce future system panics due to cpumask operations using NR_CPUS

    Insure that code does not look at bits >= nr_cpu_ids as when cpumasks are
    allocated based on nr_cpu_ids, these extra bits will not be defined.

    Also some other minor updates:

    * change in to use cpu accessor function set_cpu_present() instead of
    directly accessing cpu_present_map w/cpu_clear() [arch/x86/kernel/reboot.c]

    * use cpumask_of() instead of &cpumask_of_cpu() [arch/x86/kernel/reboot.c]

    * optimize some cpu_mask_to_apicid_and functions.

    Signed-off-by: Mike Travis
    Acked-by: Rusty Russell
    Signed-off-by: Ingo Molnar

    Mike Travis
     

17 Oct, 2008

1 commit


26 Aug, 2008

2 commits


15 Aug, 2008

1 commit


22 Jul, 2008

1 commit


19 May, 2008

1 commit


20 Apr, 2008

1 commit

  • After 2.6.24 there was a plan to make the PM core acquire all device
    semaphores during a suspend/hibernation to protect itself from
    concurrent operations involving device objects. That proved to be
    too heavy-handed and we found a better way to achieve the goal, but
    before it happened, we had introduced the functions
    device_pm_schedule_removal() and destroy_suspended_device() to allow
    drivers to "safely" destroy a suspended device and we had adapted some
    drivers to use them. Now that these functions are no longer necessary,
    it seems reasonable to remove them and modify their users to use the
    normal device unregistration instead.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Signed-off-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     

17 Apr, 2008

1 commit

  • Before:
    total: 2 errors, 0 warnings, 231 lines checked
    After:
    total: 0 errors, 0 warnings, 231 lines checked

    No code changed:

    arch/x86/kernel/msr.o:

    text data bss dec hex filename
    1199 12 4 1215 4bf msr.o.before
    1199 12 4 1215 4bf msr.o.after

    md5:
    604be0d07d829bc52a9346babd084bdc msr.o.before.asm
    604be0d07d829bc52a9346babd084bdc msr.o.after.asm

    Signed-off-by: Paolo Ciarrocchi
    Signed-off-by: Ingo Molnar

    Paolo Ciarrocchi
     

04 Feb, 2008

1 commit


02 Feb, 2008

1 commit

  • Fix the following warnings:
    WARNING: arch/x86/kernel/built-in.o(.exit.text+0xf8): Section mismatch in reference from the function msr_exit() to the variable .cpuinit.data:msr_class_cpu_notifier
    WARNING: arch/x86/kernel/built-in.o(.exit.text+0x158): Section mismatch in reference from the function cpuid_exit() to the variable .cpuinit.data:cpuid_class_cpu_notifier
    WARNING: arch/x86/kernel/built-in.o(.exit.text+0x171): Section mismatch in reference from the function microcode_exit() to the variable .cpuinit.data:mc_cpu_notifier

    In all three cases there were a function annotated __exit
    that referenced a variable annotated __cpuinitdata.

    The fix was to replace the annotation of the notifier
    with __refdata to tell modpost that the reference to
    a _cpuinit function in the notifier are OK.
    The unregister call that references the notifier
    variable will simple delete the function pointer
    so there is no problem ignoring the reference.

    Note: This looks like another case where __cpuinit
    has been used as replacement for proper use
    of CONFIG_HOTPLUG_CPU to decide what code are used for
    HOTPLUG_CPU.

    Signed-off-by: Sam Ravnborg
    Cc: "H. Peter Anvin"
    Signed-off-by: Ingo Molnar

    Sam Ravnborg
     

25 Jan, 2008

1 commit

  • This patch reorganizes the way suspend and resume notifications are
    sent to drivers. The major changes are that now the PM core acquires
    every device semaphore before calling the methods, and calls to
    device_add() during suspends will fail, while calls to device_del()
    during suspends will block.

    It also provides a way to safely remove a suspended device with the
    help of the PM core, by using the device_pm_schedule_removal() callback
    introduced specifically for this purpose, and updates two drivers (msr
    and cpuid) that need to use it.

    Signed-off-by: Alan Stern
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     

20 Oct, 2007

1 commit

  • cpu_data is currently an array defined using NR_CPUS. This means that
    we overallocate since we will rarely really use maximum configured cpus.
    When NR_CPU count is raised to 4096 the size of cpu_data becomes
    3,145,728 bytes.

    These changes were adopted from the sparc64 (and ia64) code. An
    additional field was added to cpuinfo_x86 to be a non-ambiguous cpu
    index. This corresponds to the index into a cpumask_t as well as the
    per_cpu index. It's used in various places like show_cpuinfo().

    cpu_data is defined to be the boot_cpu_data structure for the NON-SMP
    case.

    Signed-off-by: Mike Travis
    Acked-by: Christoph Lameter
    Cc: Andi Kleen
    Cc: James Bottomley
    Cc: Dmitry Torokhov
    Cc: "Antonino A. Daplas"
    Cc: Mark M. Hoffman
    Signed-off-by: Andrew Morton
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Mike Travis
     

19 Oct, 2007

2 commits

  • msr_class_cpu_callback() can be marked __cpuinit, being the notifier callback
    for a __cpuinitdata notifier_block. So can be marked msr_device_create() too,
    called only from the newly-__cpuinit msr_class_cpu_callback() or from
    __init-marked msr_init().

    Signed-off-by: Satyam Sharma
    Cc: Andi Kleen
    Acked-by: H. Peter Anvin
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Satyam Sharma
     
  • Do msr_device_create() in CPU_UP_PREPARE instead of CPU_ONLINE.

    Cc: "H. Peter Anvin"
    Signed-off-by: Akinobu Mita
    Cc: Gautham R Shenoy
    Cc: Oleg Nesterov
    Cc: Andi Kleen
    Cc: Jan Beulich
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

18 Oct, 2007

1 commit

  • msr_class_cpu_callback() can be marked __cpuinit, being the notifier
    callback for a __cpuinitdata notifier_block. So can be marked
    msr_device_create() too, called only from the newly-__cpuinit
    msr_class_cpu_callback() or from __init-marked msr_init().

    [ tglx: arch/x86 adaptation ]

    Signed-off-by: Satyam Sharma
    Signed-off-by: Andi Kleen
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Satyam Sharma
     

14 Oct, 2007

1 commit

  • Since the x86 merge, lots of files that referenced their own filenames
    are no longer correct. Rather than keep them up to date, just delete
    them, as they add no real value.

    Additionally:
    - fix up comment formatting in scx200_32.c
    - Remove a credit from myself in setup_64.c from a time when we had no SCM
    - remove longwinded history from tsc_32.c which can be figured out from
    git.

    Signed-off-by: Dave Jones
    Signed-off-by: Linus Torvalds

    Dave Jones
     

11 Oct, 2007

1 commit