1. 07 12月, 2010 5 次提交
    • O
      ARM: tegra: fix regression from addruart rewrite · da8f2e24
      Olof Johansson 提交于
      Commit 0ea12930 ("arm: return both physical and virtual addresses
      from addruart") took out the test for MMU on/off but didn't switch the
      ldr instructions to no longer be conditionals based on said test.
      
      Fix that.
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Acked-by: NColin Cross <ccross@android.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      da8f2e24
    • L
      Merge branch 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6 · 7787d2c2
      Linus Torvalds 提交于
      * 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6:
        PM / Hibernate: Fix memory corruption related to swap
        PM / Hibernate: Use async I/O when reading compressed hibernation image
      7787d2c2
    • R
      PM / Hibernate: Fix memory corruption related to swap · c9e664f1
      Rafael J. Wysocki 提交于
      There is a problem that swap pages allocated before the creation of
      a hibernation image can be released and used for storing the contents
      of different memory pages while the image is being saved.  Since the
      kernel stored in the image doesn't know of that, it causes memory
      corruption to occur after resume from hibernation, especially on
      systems with relatively small RAM that need to swap often.
      
      This issue can be addressed by keeping the GFP_IOFS bits clear
      in gfp_allowed_mask during the entire hibernation, including the
      saving of the image, until the system is finally turned off or
      the hibernation is aborted.  Unfortunately, for this purpose
      it's necessary to rework the way in which the hibernate and
      suspend code manipulates gfp_allowed_mask.
      
      This change is based on an earlier patch from Hugh Dickins.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: NOndrej Zary <linux@rainbow-software.org>
      Acked-by: NHugh Dickins <hughd@google.com>
      Reviewed-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: stable@kernel.org
      c9e664f1
    • L
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · 60658f8a
      Linus Torvalds 提交于
      * master.kernel.org:/home/rmk/linux-2.6-arm:
        ARM: 6524/1: GIC irq desciptor bug fix
        ARM: 6523/1: iop: ensure sched_clock() is notrace
        ARM: 6456/1: Fix for building DEBUG with sa11xx_base.c as a module.
        ARM: 6519/1: kuser: Fix incorrect cmpxchg syscall in kuser helpers
        ARM: 6505/1: kprobes: Don't HAVE_KPROBES when CONFIG_THUMB2_KERNEL is selected
        ARM: 6508/1: vexpress: Correct data alignment in headsmp.S for CONFIG_THUMB2_KERNEL
        ARM: 6507/1: RealView: Correct data alignment in headsmp.S for CONFIG_THUMB2_KERNEL
        ARM: 6504/1: Thumb-2: Fix long-distance conditional branches in head.S for Thumb-2.
        ARM: 6503/1: Thumb-2: Restore sensible zImage header layout for CONFIG_THUMB2_KERNEL
        ARM: 6502/1: Thumb-2: Fix CONFIG_THUMB2_KERNEL breakage in compressed/head.S
        ARM: 6501/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in mm/proc-v7.S
        ARM: 6500/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in kernel/head.S
        ARM: 6499/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in bootp/init.S
        ARM: 6498/1: vfp: Correct data alignment for CONFIG_THUMB2_KERNEL
        ARM: 6497/1: kexec: Correct data alignment for CONFIG_THUMB2_KERNEL
        ARM: 6496/1: GIC: Do not try to register more then NR_IRQS interrupts
        ARM: cns3xxx: Fix build with CONFIG_PCI=y
      60658f8a
    • B
      PM / Hibernate: Use async I/O when reading compressed hibernation image · 9f339caf
      Bojan Smojver 提交于
      This is a fix for reading LZO compressed image using async I/O.
      Essentially, instead of having just one page into which we keep
      reading blocks from swap, we allocate enough of them to cover the
      largest compressed size and then let block I/O pick them all up. Once
      we have them all (and here we wait), we decompress them, as usual.
      Obviously, the very first block we still pick up synchronously,
      because we need to know the size of the lot before we pick up the
      rest.
      
      Also fixed the copyright line, which I've forgotten before.
      Signed-off-by: NBojan Smojver <bojan@rexursive.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      9f339caf
  2. 06 12月, 2010 6 次提交
  3. 05 12月, 2010 4 次提交
    • G
      parisc: Fix GSC PS/2 driver name for keyboard and mouse · 7bfbeae9
      Guy Martin 提交于
      Fix kernel warnings caused by the driver name of GSC PS/2 containing '/'.
      
      The following warnings are observed on a K410 system :
      
      [   10.700000] name 'GSC PS/2 keyboard'
      [   10.732000] ------------[ cut here ]------------
      [   10.772000] WARNING: at fs/proc/generic.c:323
      [   10.828000] Modules linked in:
      [   10.916000]
      [   10.916000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      [   10.936000] PSW: 00000000000001000000000000001111 Not tainted
      [   10.992000] r00-03  0004000f 104fe3e0 10201ea0 00000000
      [   11.060000] r04-07  4fc405c8 00000006 4fc405c8 4fc40694
      [   11.124000] r08-11  4fc40708 10438aa0 00000001 1043bfc8
      [   11.184000] r12-15  104ff2a0 104ff2a0 4fc38634 104ff2a0
      [   11.248000] r16-19  f0001570 10479af0 f000006c 1044fe50
      [   11.308000] r20-23  00000000 00000028 104cd858 00000000
      [   11.372000] r24-27  ffffffff 0000000e 1044fe10 1043bbe0
      [   11.436000] r28-31  0000002b 00000078 4fc40800 0000000d
      [   11.496000] sr00-03  00000000 00000000 00000000 00000000
      [   11.560000] sr04-07  00000000 00000000 00000000 00000000
      [   11.624000]
      [   11.688000] IASQ: 00000000 00000000 IAOQ: 10201ea0 10201ea4
      [   11.704000]  IIR: 03ffe01f    ISR: 00000000  IOR: 0000000d
      [   11.772000]  CPU:        0   CR30: 4fc40000 CR31: f01043b0
      [   11.836000]  ORIG_R28: 4fc40940
      [   11.904000]  IAOQ[0]: __xlate_proc_name+0x90/0xd0
      [   11.940000]  IAOQ[1]: __xlate_proc_name+0x94/0xd0
      [   11.996000]  RP(r2): __xlate_proc_name+0x90/0xd0
      [   12.052000] Backtrace:
      [   12.108000]  [<10257790>] vsnprintf+0x290/0x4f4
      [   12.136000]
      [   12.188000] ---[ end trace 91bf6ece17e322dd ]---
      [   12.208000] serio: GSC PS/2 keyboard port at 0x0001c000 irq 19 @ 10:12:7
      [   12.264000] name 'GSC PS/2 mouse'
      [   12.344000] ------------[ cut here ]------------
      [   12.384000] WARNING: at fs/proc/generic.c:323
      [   12.436000] Modules linked in:
      [   12.524000]
      [   12.528000]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      [   12.544000] PSW: 00000000000001000000000000001111 Tainted: G        W
      [   12.600000] r00-03  0004000f 104fe3e0 10201ea0 00000000
      [   12.680000] r04-07  4fc405c8 00000006 4fc405c8 4fc40694
      [   12.740000] r08-11  4fc40708 10438aa0 00000001 1043bfc8
      [   12.804000] r12-15  104ff2a0 104ff2a0 4fc38634 104ff2a0
      [   12.868000] r16-19  f0001570 10479af0 f000006c 1044fe50
      [   12.928000] r20-23  00000000 00000025 104cd858 00000000
      [   12.992000] r24-27  ffffffff 0000000e 1044fe10 1043bbe0
      [   13.056000] r28-31  00000028 00000078 4fc40800 0000000d
      [   13.116000] sr00-03  00000000 00000000 00000000 00000000
      [   13.180000] sr04-07  00000000 00000000 00000000 00000000
      [   13.244000]
      [   13.308000] IASQ: 00000000 00000000 IAOQ: 10201ea0 10201ea4
      [   13.324000]  IIR: 03ffe01f    ISR: 00000000  IOR: 0000000d
      [   13.392000]  CPU:        0   CR30: 4fc40000 CR31: f01043b0
      [   13.456000]  ORIG_R28: 4fc40940
      [   13.524000]  IAOQ[0]: __xlate_proc_name+0x90/0xd0
      [   13.560000]  IAOQ[1]: __xlate_proc_name+0x94/0xd0
      [   13.616000]  RP(r2): __xlate_proc_name+0x90/0xd0
      [   13.672000] Backtrace:
      [   13.728000]  [<10257790>] vsnprintf+0x290/0x4f4
      [   13.756000]
      [   13.808000] ---[ end trace 91bf6ece17e322de ]---
      [   13.828000] serio: GSC PS/2 mouse port at 0x00020100 irq 19 @ 10:12:8
      Signed-off-by: NGuy Martin <gmsoft@tuxicoman.be>
      Acked-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      7bfbeae9
    • G
      parisc: KittyHawk LCD fix · 79a04296
      Guy Martin 提交于
      K class aka KittyHawk don't have LED support on their LCD. Installing
      HP-UX confirmed this. The current led_wq fills the LCD with black
      characters each time it runs.
      
      The patch prevents the led_wq workqueue and its proc entry to be
      created for KittyHawk machines.
      
      It also increase min_cmd_delay as currently, one character out of two
      is lost when a string is sent to the LCD.
      Signed-off-by: NGuy Martin <gmsoft@tuxicoman.be>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.c>
      79a04296
    • J
      parisc: convert the rest of the irq handlers to simple/percpu · 51890613
      James Bottomley 提交于
      The generic conversion eliminates the spurious no_ack and no_end
      routines, converts all the cascaded handlers to handle_simple_irq() and
      makes iosapic use a modified handle_percpu_irq() to become the same as
      the CPU irq's.  This isn't an essential change, but it eliminates the
      mask/unmask overhead of handle_level_irq().
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      Tested-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      51890613
    • J
      parisc: fix dino/gsc interrupts · d16cd297
      James Bottomley 提交于
      The essential problem we're currently having is that dino (and gsc) is a
      cascaded CPU interrupt.  Under the old __do_IRQ() handler, our CPU
      interrupts basically did an ack followed by an end.  In the new scheme,
      we replaced them with level handlers which do a mask, an ack and then an
      unmask (but no end).  Instead, with the renaming of end to eoi, we
      actually want to call the percpu flow handlers, because they actually
      have all the characteristics we want.
      
      This patch does the conversion and gets my C360 booting again.
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
      d16cd297
  4. 04 12月, 2010 11 次提交
  5. 03 12月, 2010 14 次提交
    • A
      UBI: fix corrupted PEB detection for NOR flash · 7ac760c2
      Artem Bityutskiy 提交于
      My new shiny code for corrupted PEB detection has NOR specific bug.
      We tread PEB as corrupted and preserve it, if
      
      1. EC header is OK.
      2. VID header is corrupted.
      3. data area is not "all 0xFFs"
      
      In case of NOR we have 'nor_erase_prepare()' quirk, which invalidates
      the headers before erasing the PEB. And we invalidate first the VID
      header, and then the EC header. So if a power cut happens after we have
      invalidated the VID header, but before we have invalidated the EC
      header, we end up with a PEB which satisfies the above 3 conditions,
      and the scanning code will treat it as corrupted, and will print
      scary warnings, wrongly.
      
      This patch fixes the issue by firt invalidating the EC header, then
      invalidating the VID header. In case of power cut inbetween, we still
      just lose the EC header, and UBI can deal with this situation gracefully.
      
      Thanks to Anatolij Gustschin <agust@denx.de> for tracking this down.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Reported-by: NAnatolij Gustschin <agust@denx.de>
      Tested-by: NAnatolij Gustschin <agust@denx.de>
      7ac760c2
    • P
      Merge branch 'sh/urgent' into sh-fixes-for-linus · a9fc7492
      Paul Mundt 提交于
      a9fc7492
    • N
      sh: se/7724: Remove FSI/B of GPIO init code · c44352c5
      Nobuhiro Iwamatsu 提交于
      se7724 board does not have FSI/B.
      Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      c44352c5
    • N
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid · 59e57c62
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
        HID: length resolution should be reported units/mm
        HID: add support for F430 Force Feedback Wheel
        HID: egalax: Use kzalloc
        HID: Remove KERN_DEBUG from dbg_hid use
      
      Manually fixed trivial conflict in drivers/hid/hid-input.c (due to
      removal of KERN_DEBUG from dbg_hid use clashing with new keycode
      interface switch)
      59e57c62
    • J
      xen: allocate irq descs on any NUMA node · 29dcbc5c
      Jeremy Fitzhardinge 提交于
      Allocate irq descs on any NUMA node (we don't care) rather than
      specifically node 0, which may not exist.
      
      (At the moment NUMA is meaningless within a domain, so any info
      the kernel has is just from an SRAT table we haven't suppressed/disabled.)
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      29dcbc5c
    • J
      xen: prevent crashes with non-HIGHMEM 32-bit kernels with largeish memory · 2a4c92fa
      Jeremy Fitzhardinge 提交于
      If this is a non-HIGHMEM 32-bit kernel, then the page structures only go
      up to the limit of addressable memory, even if more memory is physically
      present.  Don't try to add that extra memory to the balloon.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      2a4c92fa
    • N
      do_exit(): make sure that we run with get_fs() == USER_DS · 33dd94ae
      Nelson Elhage 提交于
      If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not
      otherwise reset before do_exit().  do_exit may later (via mm_release in
      fork.c) do a put_user to a user-controlled address, potentially allowing
      a user to leverage an oops into a controlled write into kernel memory.
      
      This is only triggerable in the presence of another bug, but this
      potentially turns a lot of DoS bugs into privilege escalations, so it's
      worth fixing.  I have proof-of-concept code which uses this bug along
      with CVE-2010-3849 to write a zero to an arbitrary kernel address, so
      I've tested that this is not theoretical.
      
      A more logical place to put this fix might be when we know an oops has
      occurred, before we call do_exit(), but that would involve changing
      every architecture, in multiple places.
      
      Let's just stick it in do_exit instead.
      
      [akpm@linux-foundation.org: update code comment]
      Signed-off-by: NNelson Elhage <nelhage@ksplice.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      33dd94ae
    • K
      ksm: annotate ksm_thread_mutex is no deadlock source · a0b0f58c
      KOSAKI Motohiro 提交于
      commit 62b61f61 ("ksm: memory hotremove migration only") caused the
      following new lockdep warning.
      
        =======================================================
        [ INFO: possible circular locking dependency detected ]
        -------------------------------------------------------
        bash/1621 is trying to acquire lock:
         ((memory_chain).rwsem){.+.+.+}, at: [<ffffffff81079339>]
        __blocking_notifier_call_chain+0x69/0xc0
      
        but task is already holding lock:
         (ksm_thread_mutex){+.+.+.}, at: [<ffffffff8113a3aa>]
        ksm_memory_callback+0x3a/0xc0
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #1 (ksm_thread_mutex){+.+.+.}:
             [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
             [<ffffffff81505d74>] __mutex_lock_common+0x44/0x3f0
             [<ffffffff81506228>] mutex_lock_nested+0x48/0x60
             [<ffffffff8113a3aa>] ksm_memory_callback+0x3a/0xc0
             [<ffffffff8150c21c>] notifier_call_chain+0x8c/0xe0
             [<ffffffff8107934e>] __blocking_notifier_call_chain+0x7e/0xc0
             [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
             [<ffffffff813afbfb>] memory_notify+0x1b/0x20
             [<ffffffff81141b7c>] remove_memory+0x1cc/0x5f0
             [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
             [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
             [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
             [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
             [<ffffffff8114f398>] vfs_write+0xc8/0x190
             [<ffffffff8114fc14>] sys_write+0x54/0x90
             [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b
      
        -> #0 ((memory_chain).rwsem){.+.+.+}:
             [<ffffffff8108b5ba>] __lock_acquire+0x155a/0x1600
             [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
             [<ffffffff81506601>] down_read+0x51/0xa0
             [<ffffffff81079339>] __blocking_notifier_call_chain+0x69/0xc0
             [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
             [<ffffffff813afbfb>] memory_notify+0x1b/0x20
             [<ffffffff81141f1e>] remove_memory+0x56e/0x5f0
             [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
             [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
             [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
             [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
             [<ffffffff8114f398>] vfs_write+0xc8/0x190
             [<ffffffff8114fc14>] sys_write+0x54/0x90
             [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b
      
      But it's a false positive.  Both memory_chain.rwsem and ksm_thread_mutex
      have an outer lock (mem_hotplug_mutex).  So they cannot deadlock.
      
      Thus, This patch annotate ksm_thread_mutex is not deadlock source.
      
      [akpm@linux-foundation.org: update comment, from Hugh]
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Acked-by: NHugh Dickins <hughd@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a0b0f58c
    • K
      mem-hotplug: introduce {un}lock_memory_hotplug() · 20d6c96b
      KOSAKI Motohiro 提交于
      Presently hwpoison is using lock_system_sleep() to prevent a race with
      memory hotplug.  However lock_system_sleep() is a no-op if
      CONFIG_HIBERNATION=n.  Therefore we need a new lock.
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Suggested-by: NHugh Dickins <hughd@google.com>
      Acked-by: NHugh Dickins <hughd@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20d6c96b
    • A
      Documentation/filesystems/vfs.txt: fix ->repeasepage() description · 4fe65cab
      Andrew Morton 提交于
      ->releasepage() does not remove the page from the mapping.
      Acked-by: NNeil Brown <neilb@suse.de>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4fe65cab
    • J
      vmalloc: eagerly clear ptes on vunmap · 64141da5
      Jeremy Fitzhardinge 提交于
      On stock 2.6.37-rc4, running:
      
        # mount lilith:/export /mnt/lilith
        # find  /mnt/lilith/ -type f -print0 | xargs -0 file
      
      crashes the machine fairly quickly under Xen.  Often it results in oops
      messages, but the couple of times I tried just now, it just hung quietly
      and made Xen print some rude messages:
      
          (XEN) mm.c:2389:d80 Bad type (saw 7400000000000001 != exp
          3000000000000000) for mfn 1d7058 (pfn 18fa7)
          (XEN) mm.c:964:d80 Attempt to create linear p.t. with write perms
          (XEN) mm.c:2389:d80 Bad type (saw 7400000000000010 != exp
          1000000000000000) for mfn 1d2e04 (pfn 1d1fb)
          (XEN) mm.c:2965:d80 Error while pinning mfn 1d2e04
      
      Which means the domain tried to map a pagetable page RW, which would
      allow it to map arbitrary memory, so Xen stopped it.  This is because
      vm_unmap_ram() left some pages mapped in the vmalloc area after NFS had
      finished with them, and those pages got recycled as pagetable pages
      while still having these RW aliases.
      
      Removing those mappings immediately removes the Xen-visible aliases, and
      so it has no problem with those pages being reused as pagetable pages.
      Deferring the TLB flush doesn't upset Xen because it can flush the TLB
      itself as needed to maintain its invariants.
      
      When unmapping a region in the vmalloc space, clear the ptes
      immediately.  There's no point in deferring this because there's no
      amortization benefit.
      
      The TLBs are left dirty, and they are flushed lazily to amortize the
      cost of the IPIs.
      
      This specific motivation for this patch is an oops-causing regression
      since 2.6.36 when using NFS under Xen, triggered by the NFS client's use
      of vm_map_ram() introduced in 56e4ebf8 ("NFS: readdir with vmapped
      pages") .  XFS also uses vm_map_ram() and could cause similar problems.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Bryan Schumaker <bjschuma@netapp.com>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Alex Elder <aelder@sgi.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      64141da5
    • A
      cs5535-gpio: apply CS5536 errata workaround for GPIOs · 853ff883
      Andres Salomon 提交于
      The AMD Geode CS5536 Companion Device Silicon Revision B1 Specification
      Update mentions the follow as issue #36:
      
       "Atomic write transactions to the atomic GPIO High Bank Feature Bit
        registers should only affect the bits selected [...]"
      
       "after Suspend, an atomic write transaction [...] will clear all
        non-selected bits of the accessed register."
      
      In other words, writing to the high bank for a single GPIO bit will
      clear every other GPIO bit (but only sometimes after a suspend).
      
      The workaround described is obvious and simple; do a read-modify-write.
      This patch does that, and documents why we're doing it.
      Signed-off-by: NAndres Salomon <dilinger@queued.net>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      853ff883
    • F
      reiserfs: don't acquire lock recursively in reiserfs_acl_chmod · 238af875
      Frederic Weisbecker 提交于
      reiserfs_acl_chmod() can be called by reiserfs_set_attr() and then take
      the reiserfs lock a second time.  Thereafter it may call journal_begin()
      that definitely requires the lock not to be nested in order to release
      it before taking the journal mutex because the reiserfs lock depends on
      the journal mutex already.
      
      So, aviod nesting the lock in reiserfs_acl_chmod().
      Reported-by: NPawel Zawora <pzawora@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Tested-by: NPawel Zawora <pzawora@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: <stable@kernel.org>		[2.6.32.x+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      238af875