1. 17 10月, 2014 6 次提交
  2. 30 9月, 2014 3 次提交
    • J
      ARM: 8179/1: kprobes-test: Fix compile error "bad immediate value for offset" · ad684dce
      Jon Medhurst 提交于
      When compiling kprobes-test-arm.c the following error has been observed
      
      /tmp/ccoT403o.s:21439: Error: bad immediate value for offset (4168)
      
      This is caused by the compiler spilling it's literal pool too far away
      from the site which is trying to reference it with a PC relative load.
      This arises because the compiler is underestimating the size of the
      inline assembler code present, which apparently it approximates as 4
      bytes per line or instruction.
      
      We fix this problem by moving the operations which generate more than
      4 bytes out of the text section. Specifically, moving the .ascii
      directives to the .rodata section.
      Signed-off-by: NJon Medhurst <tixy@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ad684dce
    • N
      ARM: 8178/1: fix set_tls for !CONFIG_KUSER_HELPERS · 9cc6d9e5
      Nathan Lynch 提交于
      Joachim Eastwood reports that commit fbfb872f "ARM: 8148/1: flush
      TLS and thumbee register state during exec" causes a boot-time crash
      on a Cortex-M4 nommu system:
      
      Freeing unused kernel memory: 68K (281e5000 - 281f6000)
      Unhandled exception: IPSR = 00000005 LR = fffffff1
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
      task: 29834000 ti: 29832000 task.ti: 29832000
      PC is at flush_thread+0x2e/0x40
      LR is at flush_thread+0x21/0x40
      pc : [<2800954a>] lr : [<2800953d>] psr: 4100000b
      sp : 29833d60 ip : 00000000 fp : 00000001
      r10: 00003cf8 r9 : 29b1f000 r8 : 00000000
      r7 : 29b0bc00 r6 : 29834000 r5 : 29832000 r4 : 29832000
      r3 : ffff0ff0 r2 : 29832000 r1 : 00000000 r0 : 282121f0
      xPSR: 4100000b
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
      [<2800afa5>] (unwind_backtrace) from [<2800a327>] (show_stack+0xb/0xc)
      [<2800a327>] (show_stack) from [<2800a963>] (__invalid_entry+0x4b/0x4c)
      
      The problem is that set_tls is attempting to clear the TLS location in
      the kernel-user helper page, which isn't set up on V7M.
      
      Fix this by guarding the write to the kuser helper page with
      a CONFIG_KUSER_HELPERS ifdef.
      
      Fixes: fbfb872f ARM: 8148/1: flush TLS and thumbee register state during exec
      Reported-by: NJoachim Eastwood <manabian@gmail.com>
      Tested-by: NJoachim Eastwood <manabian@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9cc6d9e5
    • K
      ARM: 8177/1: cacheflush: Fix v7_exit_coherency_flush exynos build breakage on ARMv6 · ebc77251
      Krzysztof Kozlowski 提交于
      This fixes build breakage of platsmp.c if ARMv6 was chosen for compile
      time options (e.g. by building allmodconfig):
      
      $ make allmodconfig
      $ make
        CC      arch/arm/mach-exynos/platsmp.o
      /tmp/ccdQM0Eg.s: Assembler messages:
      /tmp/ccdQM0Eg.s:432: Error: selected processor does not support ARM mode `isb '
      /tmp/ccdQM0Eg.s:437: Error: selected processor does not support ARM mode `isb '
      /tmp/ccdQM0Eg.s:438: Error: selected processor does not support ARM mode `dsb '
      make[1]: *** [arch/arm/mach-exynos/platsmp.o] Error 1
      
      The error was introduced in commit "ARM: EXYNOS: Move code from
      hotplug.c to platsmp.c".  Previously code using
      v7_exit_coherency_flush() macro was built with '-march=armv7-a' flag but
      this flag dissapeared during the movement.
      
      Fix this by annotating the v7_exit_coherency_flush() asm code with
      armv7-a architecture.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reported-by: NMark Brown <broonie@kernel.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ebc77251
  3. 26 9月, 2014 2 次提交
  4. 25 9月, 2014 13 次提交
  5. 24 9月, 2014 6 次提交
    • M
      crypto: aesni - disable "by8" AVX CTR optimization · 7da4b29d
      Mathias Krause 提交于
      The "by8" implementation introduced in commit 22cddcc7 ("crypto: aes
      - AES CTR x86_64 "by8" AVX optimization") is failing crypto tests as it
      handles counter block overflows differently. It only accounts the right
      most 32 bit as a counter -- not the whole block as all other
      implementations do. This makes it fail the cryptomgr test #4 that
      specifically tests this corner case.
      
      As we're quite late in the release cycle, just disable the "by8" variant
      for now.
      Reported-by: NRomain Francoise <romain@orebokech.com>
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Cc: Chandramouli Narayanan <mouli@linux.intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7da4b29d
    • W
      sched: Fix unreleased llc_shared_mask bit during CPU hotplug · 03bd4e1f
      Wanpeng Li 提交于
      The following bug can be triggered by hot adding and removing a large number of
      xen domain0's vcpus repeatedly:
      
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group
      	PGD 5a9d5067 PUD 13067 PMD 0
      	Oops: 0000 [#3] SMP
      	[...]
      	Call Trace:
      	load_balance
      	? _raw_spin_unlock_irqrestore
      	idle_balance
      	__schedule
      	schedule
      	schedule_timeout
      	? lock_timer_base
      	schedule_timeout_uninterruptible
      	msleep
      	lock_device_hotplug_sysfs
      	online_store
      	dev_attr_store
      	sysfs_write_file
      	vfs_write
      	SyS_write
      	system_call_fastpath
      
      Last level cache shared mask is built during CPU up and the
      build_sched_domain() routine takes advantage of it to setup
      the sched domain CPU topology.
      
      However, llc_shared_mask is not released during CPU disable,
      which leads to an invalid sched domainCPU topology.
      
      This patch fix it by releasing the llc_shared_mask correctly
      during CPU disable.
      
      Yasuaki also reported that this can happen on real hardware:
      
        https://lkml.org/lkml/2014/7/22/1018
      
      His case is here:
      
      	==
      	Here is an example on my system.
      	My system has 4 sockets and each socket has 15 cores and HT is
      	enabled. In this case, each core of sockes is numbered as
      	follows:
      
      		 | CPU#
      	Socket#0 | 0-14 , 60-74
      	Socket#1 | 15-29, 75-89
      	Socket#2 | 30-44, 90-104
      	Socket#3 | 45-59, 105-119
      
      	Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000.
      
      	It means that last level cache of Socket#2 is shared with
      	CPU#30-44 and 90-104.
      
      	When hot-removing socket#2 and #3, each core of sockets is
      	numbered as follows:
      
      		 | CPU#
      	Socket#0 | 0-14 , 60-74
      	Socket#1 | 15-29, 75-89
      
      	But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30
      	remains having 0x3fff80000001fffc0000000.
      
      	After that, when hot-adding socket#2 and #3, each core of
      	sockets is numbered as follows:
      
      		 | CPU#
      	Socket#0 | 0-14 , 60-74
      	Socket#1 | 15-29, 75-89
      	Socket#2 | 30-59
      	Socket#3 | 90-119
      
      	Then llc_shared_mask of CPU#30 becomes
      	0x3fff8000fffffffc0000000. It means that last level cache of
      	Socket#2 is shared with CPU#30-59 and 90-104. So the mask has
      	the wrong value.
      Signed-off-by: NWanpeng Li <wanpeng.li@linux.intel.com>
      Tested-by: NLinn Crosetto <linn@hp.com>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NToshi Kani <toshi.kani@hp.com>
      Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: <stable@vger.kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1411547885-48165-1-git-send-email-wanpeng.li@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      03bd4e1f
    • M
      x86/efi: Delete misleading efi_printk() error message · 56394ab8
      Matt Fleming 提交于
      A number of people are reporting seeing the "setup_efi_pci() failed!"
      error message in what used to be a quiet boot,
      
        https://bugzilla.kernel.org/show_bug.cgi?id=81891
      
      The message isn't all that helpful because setup_efi_pci() can return a
      non-success error code for a variety of reasons, not all of them fatal.
      
      Let's drop the return code from setup_efi_pci*() altogether, since
      there's no way to process it in any meaningful way outside of the inner
      __setup_efi_pci*() functions.
      Reported-by: NDarren Hart <dvhart@linux.intel.com>
      Reported-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Cc: Ulf Winkelvos <ulf@winkelvos.de>
      Cc: Andre Müller <andre.muller@web.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      56394ab8
    • M
      Revert "efi/x86: efistub: Move shared dependencies to <asm/efi.h>" · 84be8805
      Matt Fleming 提交于
      This reverts commit f23cf8bd ("efi/x86: efistub: Move shared
      dependencies to <asm/efi.h>") as well as the x86 parts of commit
      f4f75ad5 ("efi: efistub: Convert into static library").
      
      The road leading to these two reverts is long and winding.
      
      The above two commits were merged during the v3.17 merge window and
      turned the common EFI boot stub code into a static library. This
      necessitated making some symbols global in the x86 boot stub which
      introduced new entries into the early boot GOT.
      
      The problem was that we weren't fixing up the newly created GOT entries
      before invoking the EFI boot stub, which sometimes resulted in hangs or
      resets. This failure was reported by Maarten on his Macbook pro.
      
      The proposed fix was commit 9cb0e394 ("x86/efi: Fixup GOT in all
      boot code paths"). However, that caused issues for Linus when booting
      his Sony Vaio Pro 11. It was subsequently reverted in commit
      f3670394.
      
      So that leaves us back with Maarten's Macbook pro not booting.
      
      At this stage in the release cycle the least risky option is to revert
      the x86 EFI boot stub to the pre-merge window code structure where we
      explicitly #include efi-stub-helper.c instead of linking with the static
      library. The arm64 code remains unaffected.
      
      We can take another swing at the x86 parts for v3.18.
      
      Conflicts:
      	arch/x86/include/asm/efi.h
      Tested-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Tested-by: Leif Lindholm <leif.lindholm@linaro.org> [arm64]
      Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      84be8805
    • J
      parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds · d26a7730
      John David Anglin 提交于
      In spite of what the GCC manual says, the -mfast-indirect-calls has
      never been supported in the 64-bit parisc compiler. Indirect calls have
      always been done using function descriptors irrespective of the
      -mfast-indirect-calls option.
      
      Recently, it was noticed that a function descriptor was always requested
      when the -mfast-indirect-calls option was specified. This caused
      problems when the option was used in  application code and doesn't make
      any sense because the whole point of the option is to avoid using a
      function descriptor for indirect calls.
      
      Fixing this broke 64-bit kernel builds.
      
      I will fix GCC but for now we need the attached change. This results in
      the same kernel code as before.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org  # v3.0+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      d26a7730
    • T
      [IA64] refresh arch/ia64/configs/* using "make savedefconfig" · e8ee39e2
      Tony Luck 提交于
      Prompted by a change to drivers/scsi/Kconfig which used to do a
      "select NET" but now does a "depends on NET". This meant that some
      configurations ended up without CONFIG_NET=y
      
      Signed-off-by Tony Luck <tony.luck@intel.com>
      e8ee39e2
  6. 23 9月, 2014 2 次提交
  7. 22 9月, 2014 1 次提交
  8. 20 9月, 2014 1 次提交
    • A
      sparc: bpf_jit: fix support for ldx/stx mem and SKF_AD_VLAN_TAG · f6f2332d
      Alexei Starovoitov 提交于
      fix several issues in sparc BPF JIT compiler.
      
      ldx/stx related:
      . classic BPF instructions that access mem[] slots were not setting
        SEEN_MEM flag, so stack wasn't allocated. Fix that by advertising
        correct flags
      
      . LDX/STX instructions were missing SEEN_XREG, so register value
        could have leaked to user space. Fix it.
      
      . since stack for mem[] slots is allocated with 'sub %sp' instead
        of 'save %sp', use %sp as base register instead of %fp.
      
      . ldx mem[0] means first slot in classic BPF which should have
        -4 offset instead of 0.
      
      . sparc64 needs 2047 stack bias as per ABI to access stack
      
      . emit_stmem() was using LD32I macro instead of ST32I
      
      SKF_AD_VLAN_TAG* related:
      . SKF_AD_VLAN_TAG_PRESENT must return 1 or 0 instead of '> 0' or 0
        as per classic BPF de facto standard
      
      . SKF_AD_VLAN_TAG needs to mask the field correctly
      
      Fixes: 2809a208 ("net: filter: Just In Time compiler for sparc")
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6f2332d
  9. 19 9月, 2014 1 次提交
  10. 17 9月, 2014 3 次提交
    • M
      MIPS: SmartMIPS: Disable assembler warnings · dab1b445
      Markos Chandras 提交于
      The kernel code overrides the default ISA as passed by the compiler
      in quite a few places. This has unfortunate side effects when smartmips
      is enabled leading to hundreds of warnings during build such as:
      
      {standard input}: Assembler messages:
      {standard input}:411: Warning: the `smartmips' extension requires MIPS32
      revision 1 or greater
      {standard input}: Assembler messages:
      {standard input}:43: Warning: the 64-bit MIPS architecture does not support the
      `smartmips' extension
      [...]
      
      Until the kernel code is fixed properly (if possible), disable all the
      assembler warning messages to make the build logs readable again.
      This has no runtime side effects but it makes it easier to spot
      more critical warnings and problems during build.
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/7356/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      dab1b445
    • T
      ARM: OMAP3: Fix I/O chain clock line assertion timed out error · 7db143b8
      Tony Lindgren 提交于
      We are getting "PRM: I/O chain clock line assertion timed out" errors
      on early omaps for device tree based booting. This is because we are
      unconditionally calling reconfigure_io_chain while legacy booting
      has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c.
      
      For device tree based booting, we are calling reconfigure_io_chain
      unconditionally from pinctrl framework. So we need to add a check for
      omap3_has_io_chain_ctrl() to avoid the errors for trying to access
      a register that does not exist.
      
      For es3.0, the documentation in "4.11.2 Device Off-Mode Configuration"
      just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in
      documentation for "4.11.2.2 I/O Wake-Up Mechanism" that describes the
      PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get
      added until in es3.1 probaly to fix issues with flakey wake-up events.
      
      We are doing proper checks for ST_IO_CHAIN already in id.c and with
      omap3_has_io_chain_ctrl(). For more information, see also commit
      b02b9172 ("ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock
      control detection").
      
      Let's fix the issue by selecting the right function during init for
      reconfigure_io_chain depending on the omap revision. For es3.0 and
      earlier we need to just toggle EN_IO. By doing this, we can move the
      check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code
      in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain.
      
      Thanks to Paul Walmsley and Nishanth Menon for help with debugging the
      issue.
      
      Fixes: 30a69ef7 ("ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap")
      Cc: Kevin Hilman <khilman@kernel.org>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Reviewed-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7db143b8
    • B
      vgaarb: Don't default exclusively to first video device with mem+io · 86fd887b
      Bruno Prémont 提交于
      Commit 20cde694 ("x86, ia64: Move EFI_FB vga_default_device()
      initialization to pci_vga_fixup()") moved boot video device detection from
      efifb to x86 and ia64 pci/fixup.c.
      
      For dual-GPU Apple computers above change represents a regression as code
      in efifb did forcefully override vga_default_device while the merge did not
      (vgaarb happens prior to PCI fixup).
      
      To improve on initial device selection by vgaarb (it cannot know if PCI
      device not behind bridges see/decode legacy VGA I/O or not), move the
      screen_info based check from pci_video_fixup() to vgaarb's init function and
      use it to refine/override decision taken while adding the individual PCI
      VGA devices.  This way PCI fixup has no reason to adjust vga_default_device
      anymore but can depend on its value for flagging shadowed VBIOS.
      
      This has the nice benefit of removing duplicated code but does introduce a
      #if defined() block in vgaarb.  Not all architectures have screen_info and
      would cause compile to fail without it.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461Reported-and-Tested-By: NAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Matthew Garrett <matthew.garrett@nebula.com>
      CC: stable@vger.kernel.org # v3.5+
      86fd887b
  11. 16 9月, 2014 2 次提交
    • S
      ARM: 8149/1: perf: Don't sleep while atomic when enabling per-cpu interrupts · 505013bc
      Stephen Boyd 提交于
      Rob Clark reports a sleeping while atomic bug when using perf.
      
      BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:583
      in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
      ------------[ cut here ]------------
      WARNING: CPU: 2 PID: 4828 at ../kernel/locking/mutex.c:479 mutex_lock_nested+0x3a0/0x3e8()
      DEBUG_LOCKS_WARN_ON(in_interrupt())
      Modules linked in:
      CPU: 2 PID: 4828 Comm: Xorg.bin Tainted: G        W      3.17.0-rc3-00234-gd535c45-dirty #819
      [<c0216690>] (unwind_backtrace) from [<c0212174>] (show_stack+0x10/0x14)
      [<c0212174>] (show_stack) from [<c0867cc0>] (dump_stack+0x98/0xb8)
      [<c0867cc0>] (dump_stack) from [<c02492a4>] (warn_slowpath_common+0x70/0x8c)
      [<c02492a4>] (warn_slowpath_common) from [<c02492f0>] (warn_slowpath_fmt+0x30/0x40)
      [<c02492f0>] (warn_slowpath_fmt) from [<c086a3f8>] (mutex_lock_nested+0x3a0/0x3e8)
      [<c086a3f8>] (mutex_lock_nested) from [<c0294d08>] (irq_find_host+0x20/0x9c)
      [<c0294d08>] (irq_find_host) from [<c0769d50>] (of_irq_get+0x28/0x48)
      [<c0769d50>] (of_irq_get) from [<c057d104>] (platform_get_irq+0x1c/0x8c)
      [<c057d104>] (platform_get_irq) from [<c021a06c>] (cpu_pmu_enable_percpu_irq+0x14/0x38)
      [<c021a06c>] (cpu_pmu_enable_percpu_irq) from [<c02b1634>] (flush_smp_call_function_queue+0x88/0x178)
      [<c02b1634>] (flush_smp_call_function_queue) from [<c0214dc0>] (handle_IPI+0x88/0x160)
      [<c0214dc0>] (handle_IPI) from [<c0208930>] (gic_handle_irq+0x64/0x68)
      [<c0208930>] (gic_handle_irq) from [<c0212d04>] (__irq_svc+0x44/0x5c)
      Exception stack(0xe63ddea0 to 0xe63ddee8)
      dea0: 00000001 00000001 00000000 c2f3b200 c16db380 c032d4a0 e63ddf40 60010013
      dec0: 00000000 001fbfd4 00000100 00000000 00000001 e63ddee8 c0284770 c02a2e30
      dee0: 20010013 ffffffff
      [<c0212d04>] (__irq_svc) from [<c02a2e30>] (ktime_get_ts64+0x1c8/0x200)
      [<c02a2e30>] (ktime_get_ts64) from [<c032d4a0>] (poll_select_set_timeout+0x60/0xa8)
      [<c032d4a0>] (poll_select_set_timeout) from [<c032df64>] (SyS_select+0xa8/0x118)
      [<c032df64>] (SyS_select) from [<c020e8e0>] (ret_fast_syscall+0x0/0x48)
      ---[ end trace 0bb583b46342da6f ]---
      INFO: lockdep is turned off.
      
      We don't really need to get the platform irq again when we're
      enabling or disabling the per-cpu irq. Furthermore, we don't
      really need to set and clear bits in the active_irqs bitmask
      because that's only used in the non-percpu irq case to figure out
      when the last CPU PMU has been disabled. Just pass the irq
      directly to the enable/disable functions to clean all this up.
      This should be slightly more efficient and also fix the
      scheduling while atomic bug.
      
      Fixes: bbd64559 "ARM: perf: support percpu irqs for the CPU PMU"
      Reported-by: NRob Clark <robdclark@gmail.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      505013bc
    • N
      ARM: 8148/1: flush TLS and thumbee register state during exec · fbfb872f
      Nathan Lynch 提交于
      The TPIDRURO and TPIDRURW registers need to be flushed during exec;
      otherwise TLS information is potentially leaked.  TPIDRURO in
      particular needs careful treatment.  Since flush_thread basically
      needs the same code used to set the TLS in arm_syscall, pull that into
      a common set_tls helper in tls.h and use it in both places.
      
      Similarly, TEEHBR needs to be cleared during exec as well.  Clearing
      its save slot in thread_info isn't right as there is no guarantee
      that a thread switch will occur before the new program runs.  Just
      setting the register directly is sufficient.
      Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fbfb872f
新手
引导
客服 返回
顶部