1. 20 8月, 2013 1 次提交
  2. 14 8月, 2013 6 次提交
    • R
      Merge branch 'security-fixes' into fixes · 2a282247
      Russell King 提交于
      2a282247
    • S
      ARM: 7807/1: kexec: validate CPU hotplug support · 2103f6cb
      Stephen Warren 提交于
      Architectures should fully validate whether kexec is possible as part of
      machine_kexec_prepare(), so that user-space's kexec_load() operation can
      report any problems. Performing validation in machine_kexec() itself is
      too late, since it is not allowed to return.
      
      Prior to this patch, ARM's machine_kexec() was testing after-the-fact
      whether machine_kexec_prepare() was able to disable all but one CPU.
      Instead, modify machine_kexec_prepare() to validate all conditions
      necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
      succeeded, yet disabling the CPUs didn't actually work.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2103f6cb
    • W
      ARM: 7812/1: rwlocks: retry trylock operation if strex fails on free lock · 00efaa02
      Will Deacon 提交于
      Commit 15e7e5c1 ("ARM: 7749/1: spinlock: retry trylock operation if
      strex fails on free lock") modifying our arch_spin_trylock to retry the
      acquisition if the lock appeared uncontended, but the strex failed.
      
      This patch does the same for rwlocks, which were missed by the original
      patch.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      00efaa02
    • W
      ARM: 7811/1: locks: use early clobber in arch_spin_trylock · afa31d8e
      Will Deacon 提交于
      The res variable is written before we've finished with the input
      operands (namely the lock address), so ensure that we mark it as `early
      clobber' to avoid unintended register sharing.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      afa31d8e
    • S
      ARM: 7810/1: perf: Fix array out of bounds access in armpmu_map_hw_event() · d9f96635
      Stephen Boyd 提交于
      Vince Weaver reports an oops in the ARM perf event code while
      running his perf_fuzzer tool on a pandaboard running v3.11-rc4.
      
      Unable to handle kernel paging request at virtual address 73fd14cc
      pgd = eca6c000
      [73fd14cc] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP ARM
      Modules linked in: snd_soc_omap_hdmi omapdss snd_soc_omap_abe_twl6040 snd_soc_twl6040 snd_soc_omap snd_soc_omap_hdmi_card snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd_pcm snd_page_alloc snd_timer snd soundcore
      CPU: 1 PID: 2790 Comm: perf_fuzzer Not tainted 3.11.0-rc4 #6
      task: eddcab80 ti: ed892000 task.ti: ed892000
      PC is at armpmu_map_event+0x20/0x88
      LR is at armpmu_event_init+0x38/0x280
      pc : [<c001c3e4>]    lr : [<c001c17c>]    psr: 60000013
      sp : ed893e40  ip : ecececec  fp : edfaec00
      r10: 00000000  r9 : 00000000  r8 : ed8c3ac0
      r7 : ed8c3b5c  r6 : edfaec00  r5 : 00000000  r4 : 00000000
      r3 : 000000ff  r2 : c0496144  r1 : c049611c  r0 : edfaec00
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c5387d  Table: aca6c04a  DAC: 00000015
      Process perf_fuzzer (pid: 2790, stack limit = 0xed892240)
      Stack: (0xed893e40 to 0xed894000)
      3e40: 00000800 c001c17c 00000002 c008a748 00000001 00000000 00000000 c00bf078
      3e60: 00000000 edfaee50 00000000 00000000 00000000 edfaec00 ed8c3ac0 edfaec00
      3e80: 00000000 c073ffac ed893f20 c00bf180 00000001 00000000 c00bf078 ed893f20
      3ea0: 00000000 ed8c3ac0 00000000 00000000 00000000 c0cb0818 eddcab80 c00bf440
      3ec0: ed893f20 00000000 eddcab80 eca76800 00000000 eca76800 00000000 00000000
      3ee0: 00000000 ec984c80 eddcab80 c00bfe68 00000000 00000000 00000000 00000080
      3f00: 00000000 ed892000 00000000 ed892030 00000004 ecc7e3c8 ecc7e3c8 00000000
      3f20: 00000000 00000048 ecececec 00000000 00000000 00000000 00000000 00000000
      3f40: 00000000 00000000 00297810 00000000 00000000 00000000 00000000 00000000
      3f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      3f80: 00000002 00000002 000103a4 00000002 0000016c c00128e8 ed892000 00000000
      3fa0: 00090998 c0012700 00000002 000103a4 00090ab8 00000000 00000000 0000000f
      3fc0: 00000002 000103a4 00000002 0000016c 00090ab0 00090ab8 000107a0 00090998
      3fe0: bed92be0 bed92bd0 0000b785 b6e8f6d0 40000010 00090ab8 00000000 00000000
      [<c001c3e4>] (armpmu_map_event+0x20/0x88) from [<c001c17c>] (armpmu_event_init+0x38/0x280)
      [<c001c17c>] (armpmu_event_init+0x38/0x280) from [<c00bf180>] (perf_init_event+0x108/0x180)
      [<c00bf180>] (perf_init_event+0x108/0x180) from [<c00bf440>] (perf_event_alloc+0x248/0x40c)
      [<c00bf440>] (perf_event_alloc+0x248/0x40c) from [<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc)
      [<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc) from [<c0012700>] (ret_fast_syscall+0x0/0x48)
      Code: 0a000005 e3540004 0a000016 e3540000 (0791010c)
      
      This is because event->attr.config in armpmu_event_init()
      contains a very large number copied directly from userspace and
      is never checked against the size of the array indexed in
      armpmu_map_hw_event(). Fix the problem by checking the value of
      config before indexing the array and rejecting invalid config
      values.
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Tested-by: NVince Weaver <vincent.weaver@maine.edu>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d9f96635
    • W
      ARM: 7809/1: perf: fix event validation for software group leaders · c95eb318
      Will Deacon 提交于
      It is possible to construct an event group with a software event as a
      group leader and then subsequently add a hardware event to the group.
      This results in the event group being validated by adding all members
      of the group to a fake PMU and attempting to allocate each event on
      their respective PMU.
      
      Unfortunately, for software events wthout a corresponding arm_pmu, this
      results in a kernel crash attempting to dereference the ->get_event_idx
      function pointer.
      
      This patch fixes the problem by checking explicitly for software events
      and ignoring those in event validation (since they can always be
      scheduled). We will probably want to revisit this for 3.12, since the
      validation checks don't appear to work correctly when dealing with
      multiple hardware PMUs anyway.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Tested-by: NVince Weaver <vincent.weaver@maine.edu>
      Tested-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c95eb318
  3. 08 8月, 2013 1 次提交
    • R
      ARM: Fix FIQ code on VIVT CPUs · 2ba85e7a
      Russell King 提交于
      Aaro Koskinen reports the following oops:
      Installing fiq handler from c001b110, length 0x164
      Unable to handle kernel paging request at virtual address ffff1224
      pgd = c0004000
      [ffff1224] *pgd=00000000, *pte=11fff0cb, *ppte=11fff00a
      ...
      [<c0013154>] (set_fiq_handler+0x0/0x6c) from [<c0365d38>] (ams_delta_init_fiq+0xa8/0x160)
       r6:00000164 r5:c001b110 r4:00000000 r3:fefecb4c
      [<c0365c90>] (ams_delta_init_fiq+0x0/0x160) from [<c0365b14>] (ams_delta_init+0xd4/0x114)
       r6:00000000 r5:fffece10 r4:c037a9e0
      [<c0365a40>] (ams_delta_init+0x0/0x114) from [<c03613b4>] (customize_machine+0x24/0x30)
      
      This is because the vectors page is now write-protected, and to change
      code in there we must write to its original alias.  Make that change,
      and adjust the cache flushing such that the code will become visible
      to the instruction stream on VIVT CPUs.
      Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2ba85e7a
  4. 07 8月, 2013 2 次提交
  5. 03 8月, 2013 3 次提交
  6. 02 8月, 2013 1 次提交
  7. 01 8月, 2013 10 次提交
  8. 31 7月, 2013 2 次提交
  9. 27 7月, 2013 1 次提交
  10. 26 7月, 2013 4 次提交
    • W
      ARM: 7791/1: a.out: remove partial a.out support · acfdd4b1
      Will Deacon 提交于
      a.out support on ARM requires that argc, argv and envp are passed in
      r0-r2 respectively, which requires hacking load_aout_binary to
      prevent argc being clobbered by the return code. Whilst mainline kernels
      do set the registers up in start_thread, the aout loader has never
      carried the hack in mainline.
      
      Initialising the registers in this way actually goes against the libc
      expectations for ELF binaries, where argc, argv and envp are passed on
      the stack, with r0 being used to hold a pointer to an exit function for
      cleaning up after the dynamic linker if required. If the pointer is
      NULL, then it is ignored. When execing an ELF binary, Linux currently
      zeroes r0, then sets it to argc and then finally clobbers it with the
      return value of the execve syscall, so we actually end up with:
      
      	r0 = 0
      	stack[0] = argc
      	r1 = stack[1] = argv
      	r2 = stack[2] = envp
      
      libc treats r1 and r2 as undefined. The clobbering of r0 by sys_execve
      works for user-spawned threads, but when executing an ELF binary from a
      kernel thread (via call_usermodehelper), the execve is performed on the
      ret_from_fork path, which restores r0 from the saved pt_regs, resulting
      in argc being presented to the C library. This has horrible consequences
      when the application exits, since we have an exit function registered
      using argc, resulting in a jump to hyperspace.
      
      This patch solves the problem by removing the partial a.out support from
      arch/arm/ altogether.
      
      Cc: <stable@vger.kernel.org>
      Cc: Ashish Sangwan <ashishsangwan2@gmail.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      acfdd4b1
    • C
      ARM: 7790/1: Fix deferred mm switch on VIVT processors · bdae73cd
      Catalin Marinas 提交于
      As of commit b9d4d42a (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
      pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
      finish_arch_post_lock_switch() function to avoid whole cache flushing
      with interrupts disabled. The need for deferred mm switch is stored as a
      thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
      have another thread switch before finish_arch_post_lock_switch(). If the
      new thread has the same mm as the previous 'next' thread, the scheduler
      will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
      the new thread.
      
      This patch moves the switch pending flag to the mm_context_t structure
      since this is specific to the mm rather than thread.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Tested-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Cc: <stable@vger.kernel.org> # 3.5+
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bdae73cd
    • F
      ARM: 7789/1: Do not run dummy_flush_tlb_a15_erratum() on non-Cortex-A15 · 1f49856b
      Fabio Estevam 提交于
      Commit 93dc6887 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)) causes the following undefined instruction error on a mx53 (Cortex-A8):
      
      Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
      CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
      task: df46cc00 ti: df48e000 task.ti: df48e000
      PC is at check_and_switch_context+0x17c/0x4d0
      LR is at check_and_switch_context+0xdc/0x4d0
      
      This problem happens because check_and_switch_context() calls dummy_flush_tlb_a15_erratum() without checking if we are really running on a Cortex-A15 or not.
      
      To avoid this issue, only call dummy_flush_tlb_a15_erratum() inside
      check_and_switch_context() if erratum_a15_798181() returns true, which means that we are really running on a Cortex-A15.
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1f49856b
    • M
      ARM: 7787/1: virt: ensure visibility of __boot_cpu_mode · 8fbac214
      Mark Rutland 提交于
      Secondary CPUs write to __boot_cpu_mode with caches disabled, and thus a
      cached value of __boot_cpu_mode may be incoherent with that in memory.
      This could lead to a failure to detect mismatched boot modes.
      
      This patch adds flushing to ensure that writes by secondaries to
      __boot_cpu_mode are made visible before we test against it.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NDave Martin <Dave.Martin@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Christoffer Dall <cdall@cs.columbia.edu>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8fbac214
  11. 22 7月, 2013 7 次提交
    • T
      ARM: 7788/1: elf: fix lpae hwcap feature reporting in proc/cpuinfo · ab8d46c0
      Tetsuyuki Kobayashi 提交于
      Commit a469abd0 ("ARM: elf: add new hwcap for identifying atomic
      ldrd/strd instructions") added a new hwcap to identify LPAE on CPUs
      which support it. Whilst the hwcap data is correct, the string reported
      in /proc/cpuinfo actually matches on HWCAP_VFPD32, which was missing
      an entry in the string table.
      
      This patch fixes this problem by adding a "vfpd32" string at the correct
      offset, preventing us from falsely advertising LPAE on CPUs which do not
      support it.
      
      [will: added commit message]
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Tested-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NTetsuyuki Kobayashi <koba@kmckk.co.jp>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ab8d46c0
    • M
      ARM: 7786/1: hyp: fix macro parameterisation · b60d5db6
      Mark Rutland 提交于
      Currently, compare_cpu_mode_with_primary uses a mixture of macro
      arguments and hardcoded registers, and does so incorrectly, as it
      stores (__boot_cpu_mode_offset | BOOT_CPU_MODE_MISMATCH) to
      (__boot_cpu_mode + &__boot_cpu_mode_offset), which could corrupt an
      arbitrary portion of memory.
      
      This patch fixes up compare_cpu_mode_with_primary to use the macro
      arguments, correctly updating __boot_cpu_mode.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NDave Martin <Dave.Martin@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Christoffer Dall <cdall@cs.columbia.edu>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b60d5db6
    • R
      ARM: 7785/1: mm: restrict early_alloc to section-aligned memory · c65b7e98
      Russell King 提交于
      When map_lowmem() runs, and processes a memory bank whose start or end
      is not section-aligned, memory must be allocated to store the 2nd-level
      page tables. Those allocations are made by calling memblock_alloc().
      
      At this point, the only memory that is free *and* mapped is memory which
      has already been mapped by map_lowmem() itself. For this reason, we must
      calculate the first point at which map_lowmem() will need to allocate
      memory, and set the memblock allocation limit to a lower address, so that
      memblock_alloc() is guaranteed to return memory that is already mapped.
      
      This patch enhances sanity_check_meminfo() to calculate that memory
      address, and pass it to memblock_set_current_limit(), rather than just
      assuming the limit is arm_lowmem_limit.
      
      The algorithm applied is:
      
      * Default memblock_limit to arm_lowmem_limit in the absence of any other
        limit; arm_lowmem_limit is the highest memory that is mapped by
        map_lowmem().
      
      * While walking the list of memblocks, if the start of a block is not
        aligned, 2nd-level page tables will need to be allocated to map the
        first few pages of the block. Hence, the memblock_limit must be before
        the start of the block.
      
      * Similarly, if the end of any block is not aligned, 2nd-level page
        tables will need to be allocated to map the last few pages of the
        block. Hence, the memblock_limit must point at the end of the block,
        rounded down to section-alignment.
      
      * The memory blocks are assumed to be sorted in address order, so the
        first unaligned block start or end is used to set the limit.
      
      With this algorithm, the start or end of almost any bank can be non-
      section-aligned. The only exception is that the start of bank 0 must
      be section-aligned, since otherwise memory would need to be allocated
      when mapping the start of bank 0, which occurs before any free memory
      is mapped.
      
      [swarren, wrote commit description, rewrote calculation of memblock_limit]
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c65b7e98
    • W
      ARM: 7784/1: mm: ensure SMP alternates assemble to exactly 4 bytes with Thumb-2 · bf3f0f33
      Will Deacon 提交于
      Commit ae8a8b95 ("ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE
      and use ALT_SMP instead") added early function returns for page table
      cache flushing operations on ARMv7 SMP CPUs.
      
      Unfortunately, when targetting Thumb-2, these `mov pc, lr' sequences
      assemble to 2 bytes which can lead to corruption of the instruction
      stream after code patching.
      
      This patch fixes the alternates to use wide (32-bit) instructions for
      Thumb-2, therefore ensuring that the patching code works correctly.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bf3f0f33
    • R
      ARM: document DEBUG_UNCOMPRESS Kconfig option · b6992fa9
      Russell King 提交于
      This non-user visible option lacked any kind of documentation.  This
      is quite common for non-user visible options; certian people can't
      understand the point of documenting such options with help text.
      
      However, here we have a case in point: developers don't understand the
      option either, as they were thinking that when the option is not set,
      the decompressor should produce no output what so ever.  This is
      incorrect, as the purpose of this option is to control whether a
      multiplatform kernel uses the kernel debugging macros to produce
      output or not.
      
      So let's document this via help rather than commentry to prevent others
      falling into this misunderstanding.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b6992fa9
    • L
      Linux 3.11-rc2 · 3b2f64d0
      Linus Torvalds 提交于
      3b2f64d0
    • L
      Merge tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · ea45ea70
      Linus Torvalds 提交于
      Pull ACPI video support fixes from Rafael Wysocki:
       "I'm sending a separate pull request for this as it may be somewhat
        controversial.  The breakage addressed here is not really new and the
        fixes may not satisfy all users of the affected systems, but we've had
        so much back and forth dance in this area over the last several weeks
        that I think it's time to actually make some progress.
      
        The source of the problem is that about a year ago we started to tell
        BIOSes that we're compatible with Windows 8, which we really need to
        do, because some systems shipping with Windows 8 are tested with it
        and nothing else, so if we tell their BIOSes that we aren't compatible
        with Windows 8, we expose our users to untested BIOS/AML code paths.
      
        However, as it turns out, some Windows 8-specific AML code paths are
        not tested either, because Windows 8 actually doesn't use the ACPI
        methods containing them, so if we declare Windows 8 compatibility and
        attempt to use those ACPI methods, things break.  That occurs mostly
        in the backlight support area where in particular the _BCM and _BQC
        methods are plain unusable on some systems if the OS declares Windows
        8 compatibility.
      
        [ The additional twist is that they actually become usable if the OS
          says it is not compatible with Windows 8, but that may cause
          problems to show up elsewhere ]
      
        Investigation carried out by Matthew Garrett indicates that what
        Windows 8 does about backlight is to leave backlight control up to
        individual graphics drivers.  At least there's evidence that it does
        that if the Intel graphics driver is used, so we've decided to follow
        Windows 8 in that respect and allow i915 to control backlight (Daniel
        likes that part).
      
        The first commit from Aaron Lu makes ACPICA export the variable from
        which we can infer whether or not the BIOS believes that we are
        compatible with Windows 8.
      
        The second commit from Matthew Garrett prepares the ACPI video driver
        by making it initialize the ACPI backlight even if it is not going to
        be used afterward (that is needed for backlight control to work on
        Thinkpads).
      
        The third commit implements the actual workaround making i915 take
        over backlight control if the firmware thinks it's dealing with
        Windows 8 and is based on the work of multiple developers, including
        Matthew Garrett, Chun-Yi Lee, Seth Forshee, and Aaron Lu.
      
        The final commit from Aaron Lu makes us follow Windows 8 by informing
        the firmware through the _DOS method that it should not carry out
        automatic brightness changes, so that brightness can be controlled by
        GUI.
      
        Hopefully, this approach will allow us to avoid using blacklists of
        systems that should not declare Windows 8 compatibility just to avoid
        backlight control problems in the future.
      
         - Change from Aaron Lu makes ACPICA export a variable which can be
           used by driver code to determine whether or not the BIOS believes
           that we are compatible with Windows 8.
      
         - Change from Matthew Garrett makes the ACPI video driver initialize
           the ACPI backlight even if it is not going to be used afterward
           (that is needed for backlight control to work on Thinkpads).
      
         - Fix from Rafael J Wysocki implements Windows 8 backlight support
           workaround making i915 take over bakclight control if the firmware
           thinks it's dealing with Windows 8.  Based on the work of multiple
           developers including Matthew Garrett, Chun-Yi Lee, Seth Forshee,
           and Aaron Lu.
      
         - Fix from Aaron Lu makes the kernel follow Windows 8 by informing
           the firmware through the _DOS method that it should not carry out
           automatic brightness changes, so that brightness can be controlled
           by GUI"
      
      * tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        ACPI / video: no automatic brightness changes by win8-compatible firmware
        ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
        ACPI / video: Always call acpi_video_init_brightness() on init
        ACPICA: expose OSI version
      ea45ea70
  12. 21 7月, 2013 2 次提交
    • L
      Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 90db76e8
      Linus Torvalds 提交于
      Pull ext[34] tmpfile bugfix from Ted Ts'o:
       "Fix regression caused by commit af51a2ac which added ->tmpfile()
        support (along with a similar fix for ext3)"
      
      * tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext3: fix a BUG when opening a file with O_TMPFILE flag
        ext4: fix a BUG when opening a file with O_TMPFILE flag
      90db76e8
    • Z
      ext3: fix a BUG when opening a file with O_TMPFILE flag · dda5690d
      Zheng Liu 提交于
      When we try to open a file with O_TMPFILE flag, we will trigger a bug.
      The root cause is that in ext4_orphan_add() we check ->i_nlink == 0 and
      this check always fails because we set ->i_nlink = 1 in
      inode_init_always().  We can use the following program to trigger it:
      
      int main(int argc, char *argv[])
      {
      	int fd;
      
      	fd = open(argv[1], O_TMPFILE, 0666);
      	if (fd < 0) {
      		perror("open ");
      		return -1;
      	}
      	close(fd);
      	return 0;
      }
      
      The oops message looks like this:
      
      kernel: kernel BUG at fs/ext3/namei.c:1992!
      kernel: invalid opcode: 0000 [#1] SMP
      kernel: Modules linked in: ext4 jbd2 crc16 cpufreq_ondemand ipv6 dm_mirror dm_region_hash dm_log dm_mod parport_pc parport serio_raw sg dcdbas pcspkr i2c_i801 ehci_pci ehci_hcd button acpi_cpufreq mperf e1000e ptp pps_core ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core ext3 jbd sd_mod ahci libahci libata scsi_mod uhci_hcd
      kernel: CPU: 0 PID: 2882 Comm: tst_tmpfile Not tainted 3.11.0-rc1+ #4
      kernel: Hardware name: Dell Inc. OptiPlex 780 /0V4W66, BIOS A05 08/11/2010
      kernel: task: ffff880112d30050 ti: ffff8801124d4000 task.ti: ffff8801124d4000
      kernel: RIP: 0010:[<ffffffffa00db5ae>] [<ffffffffa00db5ae>] ext3_orphan_add+0x6a/0x1eb [ext3]
      kernel: RSP: 0018:ffff8801124d5cc8  EFLAGS: 00010202
      kernel: RAX: 0000000000000000 RBX: ffff880111510128 RCX: ffff8801114683a0
      kernel: RDX: 0000000000000000 RSI: ffff880111510128 RDI: ffff88010fcf65a8
      kernel: RBP: ffff8801124d5d18 R08: 0080000000000000 R09: ffffffffa00d3b7f
      kernel: R10: ffff8801114683a0 R11: ffff8801032a2558 R12: 0000000000000000
      kernel: R13: ffff88010fcf6800 R14: ffff8801032a2558 R15: ffff8801115100d8
      kernel: FS:  00007f5d172b5700(0000) GS:ffff880117c00000(0000) knlGS:0000000000000000
      kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      kernel: CR2: 00007f5d16df15d0 CR3: 0000000110b1d000 CR4: 00000000000407f0
      kernel: Stack:
      kernel: 000000000000000c ffff8801048a7dc8 ffff8801114685a8 ffffffffa00b80d7
      kernel: ffff8801124d5e38 ffff8801032a2558 ffff88010ce24d68 0000000000000000
      kernel: ffff88011146b300 ffff8801124d5d44 ffff8801124d5d78 ffffffffa00db7e1
      kernel: Call Trace:
      kernel: [<ffffffffa00b80d7>] ? journal_start+0x8c/0xbd [jbd]
      kernel: [<ffffffffa00db7e1>] ext3_tmpfile+0xb2/0x13b [ext3]
      kernel: [<ffffffff821076f8>] path_openat+0x11f/0x5e7
      kernel: [<ffffffff821c86b4>] ? list_del+0x11/0x30
      kernel: [<ffffffff82065fa2>] ?  __dequeue_entity+0x33/0x38
      kernel: [<ffffffff82107cd5>] do_filp_open+0x3f/0x8d
      kernel: [<ffffffff82112532>] ? __alloc_fd+0x50/0x102
      kernel: [<ffffffff820f9296>] do_sys_open+0x13b/0x1cd
      kernel: [<ffffffff820f935c>] SyS_open+0x1e/0x20
      kernel: [<ffffffff82398c02>] system_call_fastpath+0x16/0x1b
      kernel: Code: 39 c7 0f 85 67 01 00 00 0f b7 03 25 00 f0 00 00 3d 00 40 00 00 74 18 3d 00 80 00 00 74 11 3d 00 a0 00 00 74 0a 83 7b 48 00 74 04 <0f> 0b eb fe 49 8b 85 50 03 00 00 4c 89 f6 48 c7 c7 c0 99 0e a0
      kernel: RIP  [<ffffffffa00db5ae>] ext3_orphan_add+0x6a/0x1eb [ext3]
      kernel: RSP <ffff8801124d5cc8>
      
      Here we couldn't call clear_nlink() directly because in d_tmpfile() we
      will call inode_dec_link_count() to decrease ->i_nlink.  So this commit
      tries to call d_tmpfile() before ext4_orphan_add() to fix this problem.
      Signed-off-by: NZheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      dda5690d