Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 1月, 2017 1 次提交
    • A
      ALSA: hda/ca0132 - fix possible NULL pointer use · 46a049da
      由 Arnd Bergmann 提交于 
      gcc-7 caught what it considers a NULL pointer dereference:

sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop':
sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null expected [-Werror=nonnull]

This is plausible from looking at the function, as we compare 'reply'
to NULL earlier in it. I have not tried to analyze if there are constraints
that make it impossible to hit the bug, but adding another NULL check in
the end kills the warning and makes the function more robust.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      46a049da
  3. 05 1月, 2017 8 次提交
  5. 04 1月, 2017 2 次提交
    • T
      ALSA: hda - Fix deadlock of controller device lock at unbinding · ab949d51
      由 Takashi Iwai 提交于 
      Imre Deak reported a deadlock of HD-audio driver at unbinding while
it's still in probing.  Since we probe the codecs asynchronously in a
work, the codec driver probe may still be kicked off while the
controller itself is being unbound.  And, azx_remove() tries to
process all pending tasks via cancel_work_sync() for fixing the other
races (see commit [0b8c8219: ALSA: hda - Cancel probe work instead
of flush at remove]), now we may meet a bizarre deadlock:

Unbind snd_hda_intel via sysfs:
  device_release_driver() ->
    device_lock(snd_hda_intel) ->
      azx_remove() ->
        cancel_work_sync(azx_probe_work)

azx_probe_work():
  codec driver probe() ->
     __driver_attach() ->
       device_lock(snd_hda_intel)

This deadlock is caused by the fact that both device_release_driver()
and driver_probe_device() take both the device and its parent locks at
the same time.  The codec device sets the controller device as its
parent, and this lock is taken before the probe() callback is called,
while the controller remove() callback gets called also with the same
lock.

In this patch, as an ugly workaround, we unlock the controller device
temporarily during cancel_work_sync() call.  The race against another
bind call should be still suppressed by the parent's device lock.
Reported-by: NImre Deak <imre.deak@intel.com>
Fixes: 0b8c8219 ("ALSA: hda - Cancel probe work instead of flush at remove")
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ab949d51
    • K
      ALSA: hda/realtek - Add new codec ID ALC299 · 28f1f9b2
      由 Kailang Yang 提交于 
      ALC299 was similar as ALC225.
Add headset support for ALC299.
ALC3271 was for Dell rename.
Signed-off-by: NKailang Yang <kailang@realtek.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      28f1f9b2
  7. 03 1月, 2017 6 次提交
    • T
      Merge branch 'for-linus' into for-next · 337ccfce
      由 Takashi Iwai 提交于
      337ccfce
    • T
      ALSA: dice: ensure transmission speed for transmitted packets · b0e159fe
      由 Takashi Sakamoto 提交于 
      As of kernel 4.10, ALSA dice driver is expected to be used in default
speed. In most cases, it's S400. While, IEEE 1394 specification describes
the other speed such as S800.

According to 'TCD30XX User Guide', its link layer controller supports
several transmission speed up to S800[0]. In Dice software interface,
transmission speed in output direction can be configured by asynchronous
transaction to 'TX_SPEED' offset in its address space. S800 may be
available.

This commit improves configuration of transmission unit before starting
packet streaming for this purpose. The value of 'max_speed' in 'fw_device'
data structure has available maximum speed decided in bus arbitration,
thus it's within capacity of the unit.

[0] TCD3xx User Guide - TCAT 1394 LLC, Revision 0.9.0-41360 (TC Applied Technologies, May 6 2015)
http://www.tctechnologies.tc/index.php/support/support-hardware/dice-iii-detailed-documentationSigned-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b0e159fe
    • T
      ALSA: firewire-lib: change structure member with proper type · 6b7e95d1
      由 Takashi Sakamoto 提交于 
      The 'amdtp_stream' structure is initialized by a call of
'amdtp_stream_init()'. Although a parameter of this function is for bit
flags of packet attributes, its type is enumerator.

This commit changes the type so that it's proper for a bit flags.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6b7e95d1
    • T
      ALSA: firewire-tascam: Fix to handle error from initialization of stream data · 6a2a2f45
      由 Takashi Sakamoto 提交于 
      This module has a bug not to return error code in a case that data
structure for transmitted packets fails to be initialized.

This commit fixes the bug.

Fixes: 35efa5c4 ("ALSA: firewire-tascam: add streaming functionality")
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6a2a2f45
    • T
      ALSA: fireworks: fix asymmetric API call at unit removal · e2eb31d7
      由 Takashi Sakamoto 提交于 
      ALSA fireworks driver has a bug not to call an API to destroy
'cmp_connection' structure for input direction. Currently this causes no
issues because it just destroys 'mutex' structure, while it's better to
fix it for future work.

Fix: d23c2cc4 ("ALSA: fireworks/bebob/dice/oxfw: allow stream destructor after releasing runtime")
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e2eb31d7
    • T
      ALSA: oxfw: add support for Mackie Onyx 1640i · 03abd33a
      由 Takashi Sakamoto 提交于 
      As of kernel 4.10,  ALSA OXFW driver has no entry for Onyx 1640i produced
by Mackie (Loud Technologies). This commit supplement it.

I note that there're two models produced by Mackie (Loud Technologies),
which have the same name 'Onyx 1640i'. The former model based on OXFW970,
the latter model based on Dice. This is probably due to low quality of
communication of OXFW series.

Additionally, the tester reports his or her experiences to get unexpected
result at higher sampling transmission frequency as 88.2/96.0 kHz. We
didn't have further investigation yet[0].

$ ./linux-firewire-utils/src/crpp < config_rom
               ROM header and bus information block
               -----------------------------------------------------------------
400  042525ce  bus_info_length 4, crc_length 37, crc 9678
404  31333934  bus_name "1394"
408  20ff5003  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 5 (64)
40c  000ff205  company_id 000ff2     |
410  00000fcf  device_id 0500000fcf  | EUI-64 000ff20500000fcf

               root directory
               -----------------------------------------------------------------
414  0006c1b7  directory_length 6, crc 49591
418  03000ff2  vendor
41c  8100000a  --> descriptor leaf at 444
420  17001640  model
424  81000011  --> descriptor leaf at 468
428  0c0083c0  node capabilities per IEEE 1394
42c  d1000001  --> unit directory at 430

               unit directory at 430
               -----------------------------------------------------------------
430  00040b97  directory_length 4, crc 2967
434  1200a02d  specifier id: 1394 TA
438  13010001  version: AV/C
43c  17001640  model
440  81000010  --> descriptor leaf at 480

               descriptor leaf at 444
               -----------------------------------------------------------------
444  0008a886  leaf_length 8, crc 43142
448  00000000  textual descriptor
44c  00000000  minimal ASCII
450  4c6f7564  "Loud"
454  20546563  " Tec"
458  686e6f6c  "hnol"
45c  6f676965  "ogie"
460  7320496e  "s In"
464  632e0000  "c."

               descriptor leaf at 468
               -----------------------------------------------------------------
468  00059fcf  leaf_length 5, crc 40911
46c  00000000  textual descriptor
470  00000000  minimal ASCII
474  4f6e7978  "Onyx"
478  20313634  " 164"
47c  30690000  "0i"

               descriptor leaf at 480
               -----------------------------------------------------------------
480  00059fcf  leaf_length 5, crc 40911
484  00000000  textual descriptor
488  00000000  minimal ASCII
48c  4f6e7978  "Onyx"
490  20313634  " 164"
494  30690000  "0i"

[0]: [FFADO-user] Mackie 1640i issues (finer details)
https://sourceforge.net/p/ffado/mailman/message/35229260/Tested-by: NSeth O'Bannion <saobannion@gmail.com>
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      03abd33a
  9. 02 1月, 2017 2 次提交
    • L
      Linux 4.10-rc2 · 0c744ea4
      由 Linus Torvalds 提交于
      0c744ea4
    • L
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · 4759d386
      由 Linus Torvalds 提交于 
      Pull DAX updates from Dan Williams:
 "The completion of Jan's DAX work for 4.10.

  As I mentioned in the libnvdimm-for-4.10 pull request, these are some
  final fixes for the DAX dirty-cacheline-tracking invalidation work
  that was merged through the -mm, ext4, and xfs trees in -rc1. These
  patches were prepared prior to the merge window, but we waited for
  4.10-rc1 to have a stable merge base after all the prerequisites were
  merged.

  Quoting Jan on the overall changes in these patches:

     "So I'd like all these 6 patches to go for rc2. The first three
      patches fix invalidation of exceptional DAX entries (a bug which
      is there for a long time) - without these patches data loss can
      occur on power failure even though user called fsync(2). The other
      three patches change locking of DAX faults so that ->iomap_begin()
      is called in a more relaxed locking context and we are safe to
      start a transaction there for ext4"

  These have received a build success notification from the kbuild
  robot, and pass the latest libnvdimm unit tests. There have not been
  any -next releases since -rc1, so they have not appeared there"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  ext4: Simplify DAX fault path
  dax: Call ->iomap_begin without entry lock during dax fault
  dax: Finish fault completely when loading holes
  dax: Avoid page invalidation races and unnecessary radix tree traversals
  mm: Invalidate DAX radix tree entries only if appropriate
  ext2: Return BH_New buffers for zeroed blocks
      4759d386
  11. 31 12月, 2016 2 次提交
  13. 30 12月, 2016 2 次提交
    • O
      mm/filemap: fix parameters to test_bit() · 98473f9f
      由 Olof Johansson 提交于 
       mm/filemap.c: In function 'clear_bit_unlock_is_negative_byte':
  mm/filemap.c:933:9: error: too few arguments to function 'test_bit'
    return test_bit(PG_waiters);
         ^~~~~~~~

Fixes: b91e1302 ('mm: optimize PageWaiters bit use for unlock_page()')
Signed-off-by: NOlof Johansson <olof@lixom.net>
Brown-paper-bag-by: NLinus Torvalds <dummy@duh.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      98473f9f
    • L
      mm: optimize PageWaiters bit use for unlock_page() · b91e1302
      由 Linus Torvalds 提交于 
      In commit 62906027 ("mm: add PageWaiters indicating tasks are
waiting for a page bit") Nick Piggin made our page locking no longer
unconditionally touch the hashed page waitqueue, which not only helps
performance in general, but is particularly helpful on NUMA machines
where the hashed wait queues can bounce around a lot.

However, the "clear lock bit atomically and then test the waiters bit"
sequence turns out to be much more expensive than it needs to be,
because you get a nasty stall when trying to access the same word that
just got updated atomically.

On architectures where locking is done with LL/SC, this would be trivial
to fix with a new primitive that clears one bit and tests another
atomically, but that ends up not working on x86, where the only atomic
operations that return the result end up being cmpxchg and xadd.  The
atomic bit operations return the old value of the same bit we changed,
not the value of an unrelated bit.

On x86, we could put the lock bit in the high bit of the byte, and use
"xadd" with that bit (where the overflow ends up not touching other
bits), and look at the other bits of the result.  However, an even
simpler model is to just use a regular atomic "and" to clear the lock
bit, and then the sign bit in eflags will indicate the resulting state
of the unrelated bit #7.

So by moving the PageWaiters bit up to bit #7, we can atomically clear
the lock bit and test the waiters bit on x86 too.  And architectures
with LL/SC (which is all the usual RISC suspects), the particular bit
doesn't matter, so they are fine with this approach too.

This avoids the extra access to the same atomic word, and thus avoids
the costly stall at page unlock time.

The only downside is that the interface ends up being a bit odd and
specialized: clear a bit in a byte, and test the sign bit.  Nick doesn't
love the resulting name of the new primitive, but I'd rather make the
name be descriptive and very clear about the limitation imposed by
trying to work across all relevant architectures than make it be some
generic thing that doesn't make the odd semantics explicit.

So this introduces the new architecture primitive

    clear_bit_unlock_is_negative_byte();

and adds the trivial implementation for x86.  We have a generic
non-optimized fallback (that just does a "clear_bit()"+"test_bit(7)"
combination) which can be overridden by any architecture that can do
better.  According to Nick, Power has the same hickup x86 has, for
example, but some other architectures may not even care.

All these optimizations mean that my page locking stress-test (which is
just executing a lot of small short-lived shell scripts: "make test" in
the git source tree) no longer makes our page locking look horribly bad.
Before all these optimizations, just the unlock_page() costs were just
over 3% of all CPU overhead on "make test".  After this, it's down to
0.66%, so just a quarter of the cost it used to be.

(The difference on NUMA is bigger, but there this micro-optimization is
likely less noticeable, since the big issue on NUMA was not the accesses
to 'struct page', but the waitqueue accesses that were already removed
by Nick's earlier commit).
Acked-by: NNick Piggin <npiggin@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Bob Peterson <rpeterso@redhat.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Andrew Lutomirski <luto@kernel.org>
Cc: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b91e1302
  15. 28 12月, 2016 16 次提交
  17. 27 12月, 2016 1 次提交
    • L
      crypto: testmgr - Use heap buffer for acomp test input · 02608e02
      由 Laura Abbott 提交于 
      Christopher Covington reported a crash on aarch64 on recent Fedora
kernels:

kernel BUG at ./include/linux/scatterlist.h:140!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc8 #162
Hardware name: linux,dummy-virt (DT)
task: ffff80007c650080 task.stack: ffff800008910000
PC is at sg_init_one+0xa0/0xb8
LR is at sg_init_one+0x24/0xb8
...
[<ffff000008398db8>] sg_init_one+0xa0/0xb8
[<ffff000008350a44>] test_acomp+0x10c/0x438
[<ffff000008350e20>] alg_test_comp+0xb0/0x118
[<ffff00000834f28c>] alg_test+0x17c/0x2f0
[<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
[<ffff0000080dac70>] kthread+0xf8/0x128
[<ffff000008082ec0>] ret_from_fork+0x10/0x50

The test vectors used for input are part of the kernel image. These
inputs are passed as a buffer to sg_init_one which eventually blows up
with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
false for the kernel image since virt_to_page will not return the
correct page. Fix this by copying the input vectors to heap buffer
before setting up the scatterlist.
Reported-by: NChristopher Covington <cov@codeaurora.org>
Fixes: d7db7a88 ("crypto: acomp - update testmgr with support for acomp")
Signed-off-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      02608e02