Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

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

切换分支/标签
  1. 29 6月, 2017 1 次提交
  3. 28 6月, 2017 2 次提交
    • L
      ACPI: EC: Fix EC command visibility for dynamic debug · 4625d752
      由 Lv Zheng 提交于 
      acpi_ec_cmd_string() currently is only enabled for "DEBUG" macro, but users
trend to use CONFIG_DYNAMIC_DEBUG and enable ec.c pr_debug() print-outs by
"dyndbg='file ec.c +p'". In this use case, all command names are turned
into UNDEF and the log is confusing. This affects bugzilla triage work.

This patch fixes this issue by enabling acpi_ec_cmd_string() for
CONFIG_DYNAMIC_DEBUG.
Tested-by: NWang Wendy <wendy.wang@intel.com>
Tested-by: NFeng Chenzhou <chenzhoux.feng@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4625d752
    • L
      ACPI: EC: Fix an EC event IRQ storming issue · 1ab69f27
      由 Lv Zheng 提交于 
      The EC event IRQ (SCI_EVT) can only be handled by submitting QR_EC. As the
EC driver handles SCI_EVT in a workqueue, after SCI_EVT is flagged and
before QR_EC is submitted, there is a period risking IRQ storming. EC IRQ
must be masked for this period but linux EC driver never does so.

No end user notices the IRQ storming and no developer fixes this known
issue because:

 1. The EC IRQ is always edge triggered GPE, and
 2. The kernel can execute no-op EC IRQ handler very fast.

For edge-triggered EC GPE platforms, it is only reported of post-resume EC
event lost issues, there won't be an IRQ storming. For level triggered EC
GPE platforms, fortunately the kernel is always fast enough to execute such
a no-op EC IRQ handler so that the IRQ handler won't be accumulated to
starve the task contexts, causing a real IRQ storming.

But the IRQ storming actually can still happen when:

 1. The EC IRQ performs like level triggered GPE, and
 2. The kernel EC debugging log is turned on but the console is slow enough.

There are more and more platforms using EC GPE as wake GPE where the EC GPE
is likely designed as level triggered. Then when EC debugging log is
enabled, the EC IRQ handler is no longer a no-op but dumps IRQ status to
the consoles. If the consoles are slow enough, the EC IRQs can arrive much
faster than executing the handler. Finally the accumulated EC event IRQ
handlers starve the task contexts, causing the IRQ storming to occur, and
the kernel hangs can be observed during boot/resume.

This patch fixes this issue by masking EC IRQ for this period:

 1. Begins when there is an SCI_EVT IRQ pending, and
 2. Ends when there is a QR_EC completed (SCI_EVT acknowledged).
Tested-by: NWang Wendy <wendy.wang@intel.com>
Tested-by: NFeng Chenzhou <chenzhoux.feng@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1ab69f27
  5. 26 6月, 2017 7 次提交
  7. 25 6月, 2017 1 次提交
  9. 24 6月, 2017 21 次提交
  11. 23 6月, 2017 8 次提交
    • I
      Merge tag 'perf-urgent-for-mingo-4.12-20170622' of... · 977282ed
      由 Ingo Molnar 提交于 
      Merge tag 'perf-urgent-for-mingo-4.12-20170622' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

Pull 'perf probe' fix from Arnaldo Carvalho de Melo:

 - Do not double the offset of inline expansions when using
   'perf probe' on inlined functions (Björn Töpel)
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
      977282ed
    • A
      Input: synaptics-rmi4 - only read the F54 query registers which are used · 97689352
      由 Andrew Duggan 提交于 
      The F54 driver is currently only using the first 6 bytes of F54 so there is
no need to read all 27 bytes. Some Dell systems (Dell XP13 9333 and
similar) have an issue with the touchpad or I2C bus when reading reports
larger then 16 bytes. Reads larger then 16 bytes are reported in two HID
reports. Something about the back to back reports seems to cause the next
read to report incorrect data. This results in F30 failing to load and the
click button failing to work.

Previous issues with the I2C controller or touchpad were addressed in:
commit 5b65c2a0 ("HID: rmi: check sanity of the incoming report")

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=195949Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NNick Dyer <nick@shmanahar.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      97689352
    • N
      powerpc/64: Initialise thread_info for emergency stacks · 34f19ff1
      由 Nicholas Piggin 提交于 
      Emergency stacks have their thread_info mostly uninitialised, which in
particular means garbage preempt_count values.

Emergency stack code runs with interrupts disabled entirely, and is
used very rarely, so this has been unnoticed so far. It was found by a
proposed new powerpc watchdog that takes a soft-NMI directly from the
masked_interrupt handler and using the emergency stack. That crashed
at BUG_ON(in_nmi()) in nmi_enter(). preempt_count()s were found to be
garbage.

To fix this, zero the entire THREAD_SIZE allocation, and initialize
the thread_info.

Cc: stable@vger.kernel.org
Reported-by: NAbdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
[mpe: Move it all into setup_64.c, use a function not a macro. Fix
      crashes on Cell by setting preempt_count to 0 not HARDIRQ_OFFSET]
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      34f19ff1
    • D
      Merge tag 'drm-misc-fixes-2017-06-22' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes · 33ce7563
      由 Dave Airlie 提交于 
      UAPI Changes:
- drm: Fix regression in GETCONNECTOR ioctl returning stale properties (Daniel)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>

* tag 'drm-misc-fixes-2017-06-22' of git://anongit.freedesktop.org/git/drm-misc:
  drm: Fix GETCONNECTOR regression
      33ce7563
    • R
      kconfig: fix sparse warnings in nconfig · ad818106
      由 Randy Dunlap 提交于 
      Fix sparse warnings in scripts/kconfig/nconf* ('make nconfig'):

../scripts/kconfig/nconf.c:1071:32: warning: Using plain integer as NULL pointer
../scripts/kconfig/nconf.c:1238:30: warning: Using plain integer as NULL pointer
../scripts/kconfig/nconf.c:511:51: warning: Using plain integer as NULL pointer
../scripts/kconfig/nconf.c:1460:6: warning: symbol 'setup_windows' was not declared. Should it be static?
../scripts/kconfig/nconf.c:274:12: warning: symbol 'current_instructions' was not declared. Should it be static?
../scripts/kconfig/nconf.c:308:22: warning: symbol 'function_keys' was not declared. Should it be static?
../scripts/kconfig/nconf.gui.c:132:17: warning: non-ANSI function declaration of function 'set_colors'
../scripts/kconfig/nconf.gui.c:195:24: warning: Using plain integer as NULL pointer

nconf.gui.o before/after files are the same.
nconf.o before/after files are the same until the 'static' function
declarations are added.
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      ad818106
    • B
      perf probe: Fix probe definition for inlined functions · 7598f8bc
      由 Björn Töpel 提交于 
      In commit 613f050d ("perf probe: Fix to probe on gcc generated
functions in modules"), the offset from symbol is, incorrectly, added
to the trace point address. This leads to incorrect probe trace points
for inlined functions and when using relative line number on symbols.

Prior this patch:
  $ perf probe -m nf_nat -D in_range
  p:probe/in_range nf_nat:in_range.isra.9+0
  $ perf probe -m i40e -D i40e_clean_rx_irq
  p:probe/i40e_clean_rx_irq i40e:i40e_napi_poll+2212
  $ perf probe -m i40e -D i40e_clean_rx_irq:16
  p:probe/i40e_clean_rx_irq i40e:i40e_lan_xmit_frame+626

After:
  $ perf probe -m nf_nat -D in_range
  p:probe/in_range nf_nat:in_range.isra.9+0
  $ perf probe -m i40e -D i40e_clean_rx_irq
  p:probe/i40e_clean_rx_irq i40e:i40e_napi_poll+1106
  $ perf probe -m i40e -D i40e_clean_rx_irq:16
  p:probe/i40e_clean_rx_irq i40e:i40e_napi_poll+2665

Committer testing:

Using 'pfunct', a tool found in the 'dwarves' package [1], one can ask what are
the functions that while not being explicitely marked as inline, were inlined
by the compiler:

  # pfunct --cc_inlined /lib/modules/4.12.0-rc4+/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko | head
  __ew32
  e1000_regdump
  e1000e_dump_ps_pages
  e1000_desc_unused
  e1000e_systim_to_hwtstamp
  e1000e_rx_hwtstamp
  e1000e_update_rdt_wa
  e1000e_update_tdt_wa
  e1000_put_txbuf
  e1000_consume_page

Then ask 'perf probe' to produce the kprobe_tracer probe definitions for two of
them:

  # perf probe -m e1000e -D e1000e_rx_hwtstamp
  p:probe/e1000e_rx_hwtstamp e1000e:e1000_receive_skb+74

  # perf probe -m e1000e -D e1000_consume_page
  p:probe/e1000_consume_page e1000e:e1000_clean_jumbo_rx_irq+876
  p:probe/e1000_consume_page_1 e1000e:e1000_clean_jumbo_rx_irq+1506
  p:probe/e1000_consume_page_2 e1000e:e1000_clean_rx_irq_ps+1074

Now lets concentrate on the 'e1000_consume_page' one, that was inlined twice in
e1000_clean_jumbo_rx_irq(), lets see what readelf says about the DWARF tags for
that function:

  $ readelf -wi /lib/modules/4.12.0-rc4+/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
  <SNIP>
  <1><13e27b>: Abbrev Number: 121 (DW_TAG_subprogram)
    <13e27c>   DW_AT_name        : (indirect string, offset: 0xa8945): e1000_clean_jumbo_rx_irq
    <13e287>   DW_AT_low_pc      : 0x17a30
  <3><13e6ef>: Abbrev Number: 119 (DW_TAG_inlined_subroutine)
    <13e6f0>   DW_AT_abstract_origin: <0x13ed2c>
    <13e6f4>   DW_AT_low_pc      : 0x17be6
  <SNIP>
  <1><13ed2c>: Abbrev Number: 142 (DW_TAG_subprogram)
     <13ed2e>   DW_AT_name        : (indirect string, offset: 0xa54c3): e1000_consume_page

So, the first time in e1000_clean_jumbo_rx_irq() where e1000_consume_page() is
inlined is at PC 0x17be6, which subtracted from e1000_clean_jumbo_rx_irq()'s
address, gives us the offset we should use in the probe definition:

  0x17be6 - 0x17a30 = 438

but above we have 876, which is twice as much.

Lets see the second inline expansion of e1000_consume_page() in
e1000_clean_jumbo_rx_irq():

  <3><13e86e>: Abbrev Number: 119 (DW_TAG_inlined_subroutine)
    <13e86f>   DW_AT_abstract_origin: <0x13ed2c>
    <13e873>   DW_AT_low_pc      : 0x17d21

  0x17d21 - 0x17a30 = 753

So we where adding it at twice the offset from the containing function as we
should.

And then after this patch:

  # perf probe -m e1000e -D e1000e_rx_hwtstamp
  p:probe/e1000e_rx_hwtstamp e1000e:e1000_receive_skb+37

  # perf probe -m e1000e -D e1000_consume_page
  p:probe/e1000_consume_page e1000e:e1000_clean_jumbo_rx_irq+438
  p:probe/e1000_consume_page_1 e1000e:e1000_clean_jumbo_rx_irq+753
  p:probe/e1000_consume_page_2 e1000e:e1000_clean_jumbo_rx_irq+1353
  #

Which matches the two first expansions and shows that because we were
doubling the offset it would spill over the next function:

  readelf -sw /lib/modules/4.12.0-rc4+/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
   673: 0000000000017a30  1626 FUNC    LOCAL  DEFAULT    2 e1000_clean_jumbo_rx_irq
   674: 0000000000018090  2013 FUNC    LOCAL  DEFAULT    2 e1000_clean_rx_irq_ps

This is the 3rd inline expansion of e1000_consume_page() in
e1000_clean_jumbo_rx_irq():

   <3><13ec77>: Abbrev Number: 119 (DW_TAG_inlined_subroutine)
    <13ec78>   DW_AT_abstract_origin: <0x13ed2c>
    <13ec7c>   DW_AT_low_pc      : 0x17f79

  0x17f79 - 0x17a30 = 1353

 So:

   0x17a30 + 2 * 1353 = 0x184c2

  And:

   0x184c2 - 0x18090 = 1074

Which explains the bogus third expansion for e1000_consume_page() to end up at:

   p:probe/e1000_consume_page_2 e1000e:e1000_clean_rx_irq_ps+1074

All fixed now :-)

[1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/Signed-off-by: NBjörn Töpel <bjorn.topel@intel.com>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: NMagnus Karlsson <magnus.karlsson@intel.com>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 613f050d ("perf probe: Fix to probe on gcc generated functions in modules")
Link: http://lkml.kernel.org/r/20170621164134.5701-1-bjorn.topel@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7598f8bc
    • L
      Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 · a38371cb
      由 Linus Torvalds 提交于 
      Pull cifs fixes from Steve French:
 "Various small fixes for stable"

* 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
  CIFS: Fix some return values in case of error in 'crypt_message'
  cifs: remove redundant return in cifs_creation_time_get
  CIFS: Improve readdir verbosity
  CIFS: check if pages is null rather than bv for a failed allocation
  CIFS: Set ->should_dirty in cifs_user_readv()
      a38371cb
    • L
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 3f7ba7e1
      由 Linus Torvalds 提交于 
      Pull KVM fixes from Radim Krčmář:
 "MIPS:
   - Fix build with KVM, DYNAMIC_DEBUG and JUMP_LABEL.

  PPC:
   - Fix host crashes/hangs on POWER9.
   - Properly restore userspace state after KVM_RUN ioctl.

  s390:
   - Fix address translation in odd-ball cases (real-space designation
     ASCEs).

  x86:
   - Fix privilege escalation in 64-bit Windows guests

  All patches are for stable and the x86 also has a CVE"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: fix singlestepping over syscall
  KVM: s390: gaccess: fix real-space designation asce handling for gmap shadows
  KVM: MIPS: Fix maybe-uninitialized build failure
  KVM: PPC: Book3S HV: Ignore timebase offset on POWER9 DD1
  KVM: PPC: Book3S HV: Save/restore host values of debug registers
  KVM: PPC: Book3S HV: Preserve userspace HTM state properly
  KVM: PPC: Book3S HV: Restore critical SPRs to host values on guest exit
  KVM: PPC: Book3S HV: Context-switch EBB registers properly
  KVM: PPC: Book3S HV: Cope with host using large decrementer mode
      3f7ba7e1