Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 5月, 2014 14 次提交
  3. 17 5月, 2014 1 次提交
    • M
      arm64: fix pud_huge() for 2-level pagetables · 4797ec2d
      由 Mark Salter 提交于 
      The following happens when trying to run a kvm guest on a kernel
configured for 64k pages. This doesn't happen with 4k pages:

  BUG: failure at include/linux/mm.h:297/put_page_testzero()!
  Kernel panic - not syncing: BUG!
  CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF            3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
  Call trace:
  [<fffffe0000096034>] dump_backtrace+0x0/0x16c
  [<fffffe00000961b4>] show_stack+0x14/0x1c
  [<fffffe000066e648>] dump_stack+0x84/0xb0
  [<fffffe0000668678>] panic+0xf4/0x220
  [<fffffe000018ec78>] free_reserved_area+0x0/0x110
  [<fffffe000018edd8>] free_pages+0x50/0x88
  [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
  [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
  [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
  [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c
  [<fffffe00001edc1c>] __fput+0xb0/0x288
  [<fffffe00001ede4c>] ____fput+0xc/0x14
  [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c
  [<fffffe0000095c14>] do_notify_resume+0x54/0x58

In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
on the stage2 pgd which leads to the BUG in put_page_testzero(). This
happens because a pud_huge() test in unmap_range() returns true when it
should always be false with 2-level pages tables used by 64k pages.
This patch removes support for huge puds if 2-level pagetables are
being used.
Signed-off-by: NMark Salter <msalter@redhat.com>
[catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check]
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: <stable@vger.kernel.org> # v3.11+
      4797ec2d
  5. 16 5月, 2014 2 次提交
    • J
      parisc: Improve LWS-CAS performance · c776cd89
      由 John David Anglin 提交于 
      The attached change significantly improves the performance of the LWS-CAS code
in syscall.S.
This allows a number of packages to build (e.g., zeromq3, gtest and libxs)
that previously failed because slow LWS-CAS performance under contention. In
particular, interrupts taken while the lock was taken degraded performance
significantly.

The change does the following:

1) Disables interrupts around the CAS operation, and
2) Changes the loads and stores to use the ordered completer, "o", on
PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is
accepted on both PA 1.X and 2.0.

The use of ordered loads and stores probably makes no difference on all
existing hardware, but it seemed pedantically correct. In particular, the CAS
operation must complete before LDCW lock is released. As written before, a
processor could reorder the operations.

I don't believe the period interrupts are disabled is long enough to
significantly increase interrupt latency. For example, the TLB insert code is
longer. Worst case is a memory fault in the CAS operation.
Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # 3.13+
Signed-off-by: NHelge Deller <deller@gmx.de>
      c776cd89
    • H
      parisc: ratelimit userspace segfault printing · fef47e2a
      由 Helge Deller 提交于 
      Ratelimit printing of userspace segfaults and make it runtime
configurable via the /proc/sys/debug/exception-trace variable. This
should resolve syslog from growing way too fast and thus prevents
possible system service attacks.
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 3.13+
      fef47e2a
  7. 15 5月, 2014 10 次提交
    • V
      drm/i915: Increase WM memory latency values on SNB · e95a2f75
      由 Ville Syrjälä 提交于 
      On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.

In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.

Increase the WM memory latency values to at least 1.2 usec on SNB.
Hopefully this won't have a significant effect on power consumption.

v2: Increase the latency values regardless of the pixel clock

Cc: Robert N <crshman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254Tested-by: NRobert Navarro <crshman@gmail.com>
Tested-by: NVitaly Minko <vitaly.minko@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      e95a2f75
    • A
      drm/i915: restore backlight precision when converting from ACPI · 721e82c0
      由 Aaron Lu 提交于 
      When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.

To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491Reported-by: NNico Schottelius <nico-bugzilla.kernel.org@schottelius.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      721e82c0
    • C
      drm/i915: Use the first mode if there is no preferred mode in the EDID · afba0b5a
      由 Chris Wilson 提交于 
      This matches the algorithm used by earlier kernels when selecting the
mode for the fbcon. And only if there is no modes at all, do we fall
back to using the BIOS configuration. Seamless transition is still
preserved (from the BIOS configuration to ours) so long as the BIOS has
also chosen what we hope is the native configuration.
Reported-by: NKnut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NKnut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[Jani: applied Chris' "Please imagine that I wrote this correctly."]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      afba0b5a
    • J
      drm/i915/dp: force eDP lane count to max available lanes on BDW · f4cdbc21
      由 Jani Nikula 提交于 
      There are certain BDW high res eDP machines that regressed due to

commit 38aecea0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Mar 3 11:18:10 2014 +0100

    drm/i915: reverse dp link param selection, prefer fast over wide again

The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at
2.7 Gbps on the affected machines. Link training succeeded for both, but
the screen remained blank with the former config. Further investigation
showed that 4 lanes at 5.4 Gbps worked also.

The root cause for the blank screen using 2 lanes remains unknown, but
apparently the driver for a certain other operating system by default
uses the max available lanes. Follow suit on Broadwell eDP, for at least
until we figure out what is going on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      f4cdbc21
    • L
      x86-64, modify_ldt: Make support for 16-bit segments a runtime option · fa81511b
      由 Linus Torvalds 提交于 
      Checkin:

b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

disabled 16-bit segments on 64-bit kernels due to an information
leak.  However, it does seem that people are genuinely using Wine to
run old 16-bit Windows programs on Linux.

A proper fix for this ("espfix64") is coming in the upcoming merge
window, but as a temporary fix, create a sysctl to allow the
administrator to re-enable support for 16-bit segments.

It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do

   echo 1 > /proc/sys/abi/ldt16

as root (add it to your startup scripts), and you should be ok.

The sysctl table is only added if you have COMPAT support enabled on
x86-64, but I assume anybody who runs old windows binaries very much
does that ;)
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
Cc: <stable@vger.kernel.org>
      fa81511b
    • J
      asm-generic: remove _STK_LIM_MAX · ffe6902b
      由 James Hogan 提交于 
      _STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from
an arch's include/uapi/asm-generic/resource.h file, but is no longer
used since both parisc and metag removed the override. Therefore remove
it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY
directly in include/asm-generic/resource.h.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Cc: John David Anglin <dave.anglin@bell.net>
      ffe6902b
    • J
      metag: Remove _STK_LIM_MAX override · c70458f5
      由 James Hogan 提交于 
      Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to
256MB, apparently in an attempt to prevent setup_arg_pages's
STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is
far too large for Meta's limited virtual address space and hits a BUG_ON
(stack_top is usually 0x3ffff000).

However the commit "metag: Reduce maximum stack size to 256MB" reduces
the absolute stack size limit to a safe value for metag. This allows the
default _STK_LIM_MAX override to be removed, bringing the default
behaviour in line with all other architectures. Parisc in particular
recently removed their override of _STK_LIMT_MAX in commit e0d8898d
(parisc: remove _STK_LIM_MAX override) since it subtly affects stack
allocation semantics in userland. Meta's uapi/asm/resource.h can now be
removed and switch to using generic-y.
Suggested-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>
      c70458f5
    • H
      parisc,metag: Do not hardcode maximum userspace stack size · 042d27ac
      由 Helge Deller 提交于 
      This patch affects only architectures where the stack grows upwards
(currently parisc and metag only). On those do not hardcode the maximum
initial stack size to 1GB for 32-bit processes, but make it configurable
via a config option.

The main problem with the hardcoded stack size is, that we have two
memory regions which grow upwards: stack and heap. To keep most of the
memory available for heap in a flexmap memory layout, it makes no sense
to hard allocate up to 1GB of the memory for stack which can't be used
as heap then.

This patch makes the stack size for 32-bit processes configurable and
uses 80MB as default value which has been in use during the last few
years on parisc and which hasn't showed any problems yet.
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>
      042d27ac
    • J
      metag: Reduce maximum stack size to 256MB · d71f290b
      由 James Hogan 提交于 
      Specify the maximum stack size for arches where the stack grows upward
(parisc and metag) in asm/processor.h rather than hard coding in
fs/exec.c so that metag can specify a smaller value of 256MB rather than
1GB.

This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased
beyond a safe value by root. E.g. when starting a process after running
"ulimit -H -s unlimited" it will then attempt to use a stack size of the
maximum 1GB which is far too big for metag's limited user virtual
address space (stack_top is usually 0x3ffff000):

BUG: failure at fs/exec.c:589/shift_arg_pages()!
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Helge Deller <deller@gmx.de>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # only needed for >= v3.9 (arch/metag)
      d71f290b
    • M
      metag: fix memory barriers · 2425ce84
      由 Mikulas Patocka 提交于 
      Volatile access doesn't really imply the compiler barrier. Volatile access
is only ordered with respect to other volatile accesses, it isn't ordered
with respect to general memory accesses. Gcc may reorder memory accesses
around volatile access, as we can see in this simple example (if we
compile it with optimization, both increments of *b will be collapsed to
just one):

void fn(volatile int *a, long *b)
{
	(*b)++;
	*a = 10;
	(*b)++;
}

Consequently, we need the compiler barrier after a write to the volatile
variable, to make sure that the compiler doesn't reorder the volatile
write with something else.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Acked-by: NPeter Zijlstra <peterz@infradead.org>
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      2425ce84
  9. 14 5月, 2014 2 次提交
  11. 13 5月, 2014 9 次提交
    • L
      Merge tag 'locks-v3.15-4' of git://git.samba.org/jlayton/linux · 14186fea
      由 Linus Torvalds 提交于 
      Pull file locking fix from Jeff Layton:
 "Fix for regression in handling of F_GETLK commands"

* tag 'locks-v3.15-4' of git://git.samba.org/jlayton/linux:
  locks: only validate the lock vs. f_mode in F_SETLK codepaths
      14186fea
    • L
      Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging · 77d92784
      由 Linus Torvalds 提交于 
      Pull hwmon fixes from Guenter Roeck:
 "Fix resource leak as well as broken store function in emc1403 driver,
  and add support for additional chip revisions"

* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (emc1403) Support full range of known chip revision numbers
  hwmon: (emc1403) Fix resource leak on module unload
  hwmon: (emc1403) fix inverted store_hyst()
      77d92784
    • L
      Merge branch 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu · 68cb363a
      由 Linus Torvalds 提交于 
      Pull a percpu fix from Tejun Heo:
 "Fix for a percpu allocator bug where it could try to kfree() a memory
  region allocated using vmalloc().  The bug has been there for years
  now and is unlikely to have ever triggered given the size of struct
  pcpu_chunk.  It's still theoretically possible and the fix is simple
  and safe enough, so the patch is marked with -stable"

* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
  percpu: make pcpu_alloc_chunk() use pcpu_mem_free() instead of kfree()
      68cb363a
    • L
      Merge branch 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq · efb2b1d5
      由 Linus Torvalds 提交于 
      Pull workqueue fixes from Tejun Heo:
 "Fixes for two bugs in workqueue.

  One is exiting with internal mutex held in a failure path of
  wq_update_unbound_numa().  The other is a subtle and unlikely
  use-after-possible-last-put in the rescuer logic.  Both have been
  around for quite some time now and are unlikely to have triggered
  noticeably often.  All patches are marked for -stable backport"

* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  workqueue: fix a possible race condition between rescuer and pwq-release
  workqueue: make rescuer_thread() empty wq->maydays list before exiting
  workqueue: fix bugs in wq_update_unbound_numa() failure path
      efb2b1d5
    • L
      Merge branch 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup · 26a41cd1
      由 Linus Torvalds 提交于 
      Pull cgroup fixes from Tejun Heo:
 "During recent restructuring, device_cgroup unified config input check
  and enforcement logic; unfortunately, it turned out to share too much.
  Aristeu's patches fix the breakage and marked for -stable backport.

  The other two patches are fallouts from kernfs conversion.  The blkcg
  change is temporary and will go away once kernfs internal locking gets
  simplified (patches pending)"

* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  blkcg: use trylock on blkcg_pol_mutex in blkcg_reset_stats()
  device_cgroup: check if exception removal is allowed
  device_cgroup: fix the comment format for recently added functions
  device_cgroup: rework device access check and exception checking
  cgroup: fix the retry path of cgroup_mount()
      26a41cd1
    • L
      Merge tag 'stable/for-linus-3.15-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip · 619b5891
      由 Linus Torvalds 提交于 
      Pull xen bug fixes from David Vrabel:
 - Fix arm64 crash on boot.
 - Quiet a noisy arm build warning (virt_to_pfn() redefined).

* tag 'stable/for-linus-3.15-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  arm64: introduce virt_to_pfn
  xen/events/fifo: correctly align bitops
  arm/xen: Remove definiition of virt_to_pfn in asm/xen/page.h
      619b5891
    • L
      Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6 · 19726630
      由 Linus Torvalds 提交于 
      Pull cifs fix from Steve French:
 "Small cifs fix for metadata caching"

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: fix actimeo=0 corner case when cifs_i->time == jiffies
      19726630
    • L
      Merge tag 'md/3.15-fixes' of git://neil.brown.name/md · 2ddb5998
      由 Linus Torvalds 提交于 
      Pull md bugfixes from Neil Brown:
 "Two bugfixes for md in 3.15

  Both tagged for -stable"

* tag 'md/3.15-fixes' of git://neil.brown.name/md:
  md: avoid possible spinning md thread at shutdown.
  md/raid10: call wait_barrier() for each request submitted.
      2ddb5998
    • L
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 200d963b
      由 Linus Torvalds 提交于 
      Pull ARM SoC fixes from Olof Johansson:
 "Seems like we've had more fixes than usual this release cycle, but
  there's nothing in particular that we're doing differently.  Perhaps
  it's just one of those cycles where more people are finding more
  regressions (and/or that the latency of when people actually test
  what's been in the tree for a while is catching up so that we get the
  bug reports now).

  The bigger changes here are are for TI and Marvell platforms:
   * Timing changes for GPMC (generic localbus) on OMAP causing some
     largeish DTS deltas.
   * Fixes to window allocation on PCI for mvebu touching drivers/
     stuff.  Patches have acks from subsystem maintainers where needed.
   * A fix from Thomas for a botched DT conversion in drivers/edma.

  There's a handful of other fixes for the above platforms as well as
  sunxi, at91, i.MX.  I also included a MAINTAINER update for Broadcom,
  and a trivial move of a binding doc.

  I know you said you'd be offline this week, but I might as well post
  it for when you return.  :)"

I'm not quite offline yet.  Doing a few pulls in the last hour before my
internet goes away..

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
  MAINTAINERS: update Broadcom ARM tree location and add an SoC family
  ARM: dts: i.MX53: Fix ipu register space size
  ARM: dts: kirkwood: fix mislocated pcie-controller nodes
  ARM: sunxi: Enable GMAC in sunxi_defconfig
  ARM: common: edma: Fix xbar mapping
  ARM: sun7i: Fix i2c4 base address
  ARM: Kirkwood: T5325: Fix double probe of Codec
  ARM: mvebu: enable the SATA interface on Armada 375 DB
  ARM: mvebu: specify I2C bus frequency on Armada 370 DB
  ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces
  ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree
  ARM: mvebu: fix NOR bus-width in Armada XP DB Device Tree
  ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree
  ARM: dts: AM3517: Disable absent IPs inherited from OMAP3
  ARM: dts: OMAP2: Fix interrupts for OMAP2420 mailbox
  ARM: dts: OMAP5: Add mailbox dt node to fix boot warning
  ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
  ARM: dts: am437x-gp-evm: Do not reset gpio5
  ARM: dts: omap3-igep0020: use SMSC9221 timings
  PCI: mvebu: split PCIe BARs into multiple MBus windows when needed
  ...
      200d963b
  13. 12 5月, 2014 2 次提交