Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  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
  3. 11 5月, 2012 21 次提交
  5. 10 5月, 2012 9 次提交
  7. 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