1. 12 5月, 2012 4 次提交
    • L
      Merge branch '3.4-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending · 04e53358
      Linus Torvalds 提交于
      Pull target fix from Nicholas Bellinger:
       "This patch removes some incorrect legacy code to free se_lun_acl
        memory in the NodeACL release path that could potentially trigger an
        OOPS during shutdown once dynamic -> explicit initiator NodeACL
        conversion has occurred.
      
        That said, we've been able to trigger an OOPS in v4.0 code for this
        special case when the associated MappedLUNs had not also been made
        explicit based on active TPG LUN layout during the conversion, so it
        really makes senses to go ahead and drop this extra cruft to avoid any
        possible issues here.
      
        This ends up only effecting iscsi-target module code (it's the only
        user) and is CC'ed to stable."
      
      * '3.4-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
        target: Drop incorrect se_lun_acl release for dynamic -> explict ACL conversion
      04e53358
    • N
      target: Drop incorrect se_lun_acl release for dynamic -> explict ACL conversion · cfebf8f4
      Nicholas Bellinger 提交于
      This patch removes some potentially problematic legacy code within
      core_clear_initiator_node_from_tpg() that was originally intended to
      release left over se_lun_acl setup during dynamic NodeACL+MappedLUN
      generate when running with TPG demo-mode operation.
      
      Since we now only ever expect to allocate and release se_lun_acl from
      within target_core_fabric_configfs.c:target_fabric_make_mappedlun() and
      target_fabric_drop_mappedlun() context respectively, this code for
      demo-mode release is incorrect and needs to be removed.
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      cfebf8f4
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu · 4e25651b
      Linus Torvalds 提交于
      Pull a m68knommu fix from Greg Ungerer:
       "It contains a single fix for including the ColdFire QSPI interface
        setup code when enabled as a module.  This was broken in the
        consolidation of the ColdFire SoC device tables in the 3.4 merge
        window."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
        m68knommu: enable qspi support when SPI_COLDFIRE_QSPI = m
      4e25651b
    • H
      mm: raise MemFree by reverting percpu_pagelist_fraction to 0 · 1b76b02f
      Hugh Dickins 提交于
      Why is there less MemFree than there used to be?  It perturbed a test,
      so I've just been bisecting linux-next, and now find the offender went
      upstream yesterday.
      
      Commit 93278814 "mm: fix division by 0 in percpu_pagelist_fraction()"
      mistakenly initialized percpu_pagelist_fraction to the sysctl's minimum 8,
      which leaves 1/8th of memory on percpu lists (on each cpu??); but most of
      us expect it to be left unset at 0 (and it's not then used as a divisor).
      
        MemTotal: 8061476kB  8061476kB  8061476kB  8061476kB  8061476kB  8061476kB
        Repetitive test with percpu_pagelist_fraction 8:
        MemFree:  6948420kB  6237172kB  6949696kB  6840692kB  6949048kB  6862984kB
        Same test with percpu_pagelist_fraction back to 0:
        MemFree:  7945000kB  7944908kB  7948568kB  7949060kB  7948796kB  7948812kB
      Signed-off-by: NHugh Dickins <hughd@google.com>
      [ We really should fix the crazy sysctl interface too, but that's a
        separate thing - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1b76b02f
  2. 11 5月, 2012 21 次提交
  3. 10 5月, 2012 9 次提交
  4. 09 5月, 2012 6 次提交
    • E
      ARM: OMAP: igep0020: fix smsc911x dummy regulator id · 1a21932e
      Enrico Butera 提交于
      id 0 is already used and causes errors at boot:
      
      WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0x9c/0xac()
      sysfs: cannot create duplicate filename '/devices/platform/reg-fixed-voltage.0'
      
      Fix it by using the next available one (id=1).
      
      This was caused by 5b3689f4 (ARM: OMAP2+: smsc911x: Add fixed
      board regulators) that did not account for some regulators
      already being used.
      Signed-off-by: NEnrico Butera <ebutera@users.berlios.de>
      [tony@atomide.com: updated comments for regression causing commit]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1a21932e
    • L
      regmap: fix possible memory corruption in regmap_bulk_read() · 6560ffd1
      Laxman Dewangan 提交于
      The function regmap_bulk_read() calls the regmap_read() for
      each register if set of register has volatile and cache is
      enabled. In this case, last few register read makes the memory
      corruption if the register size is not the size of unsigned int.
      The regam_read() takes argument as unsigned int for returning
      value and it update the value as
      	*val = map->format.parse_val(map->work_buf);
      This causes complete 4 bytes (size of unsigned int) to get written.
      Now if client pass the memory pointer for value which is equal to the
      required size of register count in regmap_bulk_read() then last few
      register read actually update the memory beyond passed pointer size.
      
      Avoid this by using local variable for read and then do memcpy()
      for actual byte copy to passed pointer based on register size.
      
      I allocated one pointer ptr and take first 16 bytes dump of that
      pointer then call regmap_bulk_read() with pointer which is just
      on top of this allocated pointer and register count of 128. Here
      register size is 1 byte.
      The memory trace of last 5 register read are as follows:
      
      [    5.438589] regmap_bulk_read after regamp_read() for register 122
      [    5.447421] 0xef993c20 0xef993c00 0x00000000 0x00000001
      [    5.467535] regmap_bulk_read after regamp_read() for register 123
      [    5.476374] 0xef993c20 0xef993c00 0x00000000 0x00000001
      [    5.496425] regmap_bulk_read after regamp_read() for register 124
      [    5.505260] 0xef993c20 0xef993c00 0x00000000 0x00000001
      [    5.525372] regmap_bulk_read after regamp_read() for register 125
      [    5.534205] 0xef993c00 0xef993c00 0x00000000 0x00000001
      [    5.554258] regmap_bulk_read after regamp_read() for register 126
      [    5.563100] 0xef990000 0xef993c00 0x00000000 0x00000001
      [    5.554258] regmap_bulk_read after regamp_read() for register 127
      [    5.587108] 0xef000000 0xef993c00 0x00000000 0x00000001
      
      Here it is observed that the memory content at first word started changing
      on last 3 regmap_read() and so corruption happened.
      Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      6560ffd1
    • T
      Merge tag 'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus · 9ea3356d
      Takashi Iwai 提交于
      ASoC: Build fix for SH in 3.4
      
      An API update which wasn't sufficiently thorough in updating the tree...
      9ea3356d
    • G
      ASoC: sh: fix migor.c compilation · c8587193
      Guennadi Liakhovetski 提交于
      Fix a recent compilation breakage, caused by a change in SH clock API.
      Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      c8587193
    • A
      KVM: ia64: fix build due to typo · 331b646d
      Avi Kivity 提交于
      s/kcm/kvm/.
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      331b646d
    • D
      ALSA: HDA: Lessen CPU usage when waiting for chip to respond · 32cf4023
      David Henningsson 提交于
      When an IRQ for some reason gets lost, we wait up to a second using
      udelay, which is CPU intensive. This patch improves the situation by
      waiting about 30 ms in the CPU intensive mode, then stepping down to
      using msleep(2) instead. In essence, we trade some granularity in
      exchange for less CPU consumption when the waiting time is a bit longer.
      
      As a result, PulseAudio should no longer be killed by the kernel
      for taking up to much RT-prio CPU time. At least not for *this* reason.
      Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
      Tested-by: NArun Raghavan <arun.raghavan@collabora.co.uk>
      Cc: <stable@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      32cf4023