Skip to content

cloud-kernel
cloud-kernel

bug2833 / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

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

切换分支/标签
  1. 14 3月, 2013 16 次提交
  3. 13 3月, 2013 13 次提交
  5. 12 3月, 2013 11 次提交
    • A
      vfs: fix pipe counter breakage · a930d879
      由 Al Viro 提交于 
      If you open a pipe for neither read nor write, the pipe code will not
add any usage counters to the pipe, causing the 'struct pipe_inode_info"
to be potentially released early.

That doesn't normally matter, since you cannot actually use the pipe,
but the pipe release code - particularly fasync handling - still expects
the actual pipe infrastructure to all be there.  And rather than adding
NULL pointer checks, let's just disallow this case, the same way we
already do for the named pipe ("fifo") case.

This is ancient going back to pre-2.4 days, and until trinity, nobody
naver noticed.
Reported-by: NDave Jones <davej@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a930d879
    • A
      ARM: spear3xx: Use correct pl080 header file · 27f423fe
      由 Arnd Bergmann 提交于 
      The definitions have move around recently, causing build errors
in spear3xx for all configurations:

spear3xx.c:47:5: error: 'PL080_BSIZE_16' undeclared here (not in a function)
spear3xx.c:47:23: error: 'PL080_CONTROL_SB_SIZE_SHIFT' undeclared here (not in a function)
spear3xx.c:48:22: error: 'PL080_CONTROL_DB_SIZE_SHIFT' undeclared here (not in a function)
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Alessandro Rubini <rubini@gnudd.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
      27f423fe
    • D
      keys: fix race with concurrent install_user_keyrings() · 0da9dfdd
      由 David Howells 提交于 
      This fixes CVE-2013-1792.

There is a race in install_user_keyrings() that can cause a NULL pointer
dereference when called concurrently for the same user if the uid and
uid-session keyrings are not yet created.  It might be possible for an
unprivileged user to trigger this by calling keyctl() from userspace in
parallel immediately after logging in.

Assume that we have two threads both executing lookup_user_key(), both
looking for KEY_SPEC_USER_SESSION_KEYRING.

	THREAD A			THREAD B
	===============================	===============================
					==>call install_user_keyrings();
	if (!cred->user->session_keyring)
	==>call install_user_keyrings()
					...
					user->uid_keyring = uid_keyring;
	if (user->uid_keyring)
		return 0;
	<==
	key = cred->user->session_keyring [== NULL]
					user->session_keyring = session_keyring;
	atomic_inc(&key->usage); [oops]

At the point thread A dereferences cred->user->session_keyring, thread B
hasn't updated user->session_keyring yet, but thread A assumes it is
populated because install_user_keyrings() returned ok.

The race window is really small but can be exploited if, for example,
thread B is interrupted or preempted after initializing uid_keyring, but
before doing setting session_keyring.

This couldn't be reproduced on a stock kernel.  However, after placing
systemtap probe on 'user->session_keyring = session_keyring;' that
introduced some delay, the kernel could be crashed reliably.

Fix this by checking both pointers before deciding whether to return.
Alternatively, the test could be done away with entirely as it is checked
inside the mutex - but since the mutex is global, that may not be the best
way.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Reported-by: NMateusz Guzik <mguzik@redhat.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      0da9dfdd
    • S
      libceph: fix decoding of pgids · d6c0dd6b
      由 Sage Weil 提交于 
      In 4f6a7e5e we effectively dropped support
for the legacy encoding for the OSDMap and incremental.  However, we didn't
fix the decoding for the pgid.
Signed-off-by: NSage Weil <sage@inktank.com>
Reviewed-by: NYehuda Sadeh <yehuda@inktank.com>
      d6c0dd6b
    • P
      Arm: socfpga: pl330: Add #dma-cells for generic dma binding support · 0d8abbfd
      由 Padmavathi Venna 提交于 
      This patch adds #dma-cells property to PL330 DMA controller nodes for
supporting generic dma dt bindings on SOCFPGA platform. #dma-channels
and #dma-requests are not required now but added in advance.
Signed-off-by: NPadmavathi Venna <padma.v@samsung.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      0d8abbfd
    • A
      Merge tag 'mvebu_fixes_for_v3.9' of git://git.infradead.org/users/jcooper/linux into fixes · 75461523
      由 Arnd Bergmann 提交于 
      mvebu fixes for v3.9 from Jason Cooper <jason@lakedaemon.net>:

The first four patches:

  89c58c19 rtc: rtc-mv: Add support for clk to avoid lockups
  de88747f gpio: mvebu: Add clk support to prevent lockup
  7bf5b408 ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
  93fff4ce ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency

are Cc'd to stable since they were held over from the previous merge window.

The rest are a small collection of fixes and a couple of devicetree conversion
catchups.

* tag 'mvebu_fixes_for_v3.9' of git://git.infradead.org/users/jcooper/linux:
  arm: mach-orion5x: fix typo in compatible string of a .dts file
  arm: mvebu: fix address-cells in mpic DT node
  arm: plat-orion: fix address decoding when > 4GB is used
  arm: mvebu: Reduce reg-io-width with UARTs
  ARM: Dove: add RTC device node
  arm: mvebu: enable the USB ports on Armada 370 Reference Design board
  ARM: dove: drop "select COMMON_CLK_DOVE"
  rtc: rtc-mv: Add support for clk to avoid lockups
  gpio: mvebu: Add clk support to prevent lockup
  ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
  ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      75461523
    • A
      Merge tag 'imx-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes · 769aca03
      由 Arnd Bergmann 提交于 
      From Shawn Guo <shawn.guo@linaro.org>:

The 2nd take of imx fixes for 3.9:
 - Fix pll1_sys clk initial status
 - Fix a typo in imx DEBUG_LL Kconfig

* tag 'imx-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6:
  ARM: imx: fix typo "DEBUG_IMX50_IMX53_UART"
  ARM: imx: pll1_sys should be an initial on clk
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      769aca03
    • A
      Merge tag 'mxs-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes · fc77b0e9
      由 Arnd Bergmann 提交于 
      From Shawn Guo <shawn.guo@linaro.org>:

The 2nd mxs fixes for 3.9:
 - Fix an error caused by incorrect conflict resolution when
   applying the patch

* tag 'mxs-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6:
  ARM: mxs: cfa10049: Fix fb initialisation function
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      fc77b0e9
    • M
      ARM: multiplatform: Sort the max gpio numbers. · 2a6ad871
      由 Maxime Ripard 提交于 
      When building a multiplatform kernel, we could end up with a smaller
number of GPIOs than the one required by the platform the kernel was
running on.

Sort the max GPIO number by descending order so that we always take the
highest number required.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2a6ad871
    • L
      xen/acpi: remove redundant acpi/acpi_drivers.h include · d2e0bca3
      由 Liu Jinsong 提交于 
      It's redundant since linux/acpi.h has include it when CONFIG_ACPI enabled,
and when CONFIG_ACPI disabled it will trigger compiling warning

In file included from drivers/xen/xen-stub.c:28:0:
include/acpi/acpi_drivers.h:103:31:
warning: 'struct acpi_device' declared inside parameter list [enabled by default]
include/acpi/acpi_drivers.h:103:31:
warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/acpi/acpi_drivers.h:107:43:
warning: 'struct acpi_pci_root' declared inside parameter list [enabled by default]
Reported-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      d2e0bca3
    • I
      xen: arm: mandate EABI and use generic atomic operations. · 85323a99
      由 Ian Campbell 提交于 
      Rob Herring has observed that c81611c4 "xen: event channel arrays are
xen_ulong_t and not unsigned long" introduced a compile failure when building
without CONFIG_AEABI:

/tmp/ccJaIZOW.s: Assembler messages:
/tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'

Will Deacon pointed out that this is because OABI does not require even base
registers for 64-bit values. We can avoid this by simply using the existing
atomic64_xchg operation and the same containerof trick as used by the cmpxchg
macros. However since this code is used on memory which is shared with the
hypervisor we require proper atomic instructions and cannot use the generic
atomic64 callbacks (which are based on spinlocks), therefore add a dependency
on !GENERIC_ATOMIC64. Since we already depend on !CPU_V6 there isn't much
downside to this.

While thinking about this we also observed that OABI has different struct
alignment requirements to EABI, which is a problem for hypercall argument
structs which are shared with the hypervisor and which must be in EABI layout.
Since I don't expect people to want to run OABI kernels on Xen depend on
CONFIG_AEABI explicitly too (although it also happens to be enforced by the
!GENERIC_ATOMIC64 requirement too).
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robherring2@gmail.com>
Acked-by: NStefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      85323a99