1. 25 3月, 2014 1 次提交
  2. 19 3月, 2014 1 次提交
  3. 13 3月, 2014 1 次提交
    • J
      ASoC: tlv320aic31xx: Add basic codec driver implementation · e00447fa
      Jyri Sarha 提交于
      This commit adds a bare bones driver support for TLV320AIC31XX family
      audio codecs. The driver adds basic stereo playback trough headphone
      and speaker outputs and mono capture trough microphone inputs.
      
      The driver is currently missing support at least for mini DSP features
      and jack detection. I have tested the driver only on TLV320AIC3111,
      but based on the data sheets TLV320AIC3100, TLV320AIC3110, and
      TLV320AIC3120 should work Ok too.
      
      The base for the implementation was taken from:
      git@gitorious.org:ti-codecs/ti-codecs.git ajitk/topics/k3.10.1-aic31xx
      -branch at commit 77504eba0294764e9e63b4a0c696b44db187cd13.
      Signed-off-by: NJyri Sarha <jsarha@ti.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      e00447fa
  4. 12 3月, 2014 1 次提交
    • E
      tcp: tcp_release_cb() should release socket ownership · c3f9b018
      Eric Dumazet 提交于
      Lars Persson reported following deadlock :
      
      -000 |M:0x0:0x802B6AF8(asm) <-- arch_spin_lock
      -001 |tcp_v4_rcv(skb = 0x8BD527A0) <-- sk = 0x8BE6B2A0
      -002 |ip_local_deliver_finish(skb = 0x8BD527A0)
      -003 |__netif_receive_skb_core(skb = 0x8BD527A0, ?)
      -004 |netif_receive_skb(skb = 0x8BD527A0)
      -005 |elk_poll(napi = 0x8C770500, budget = 64)
      -006 |net_rx_action(?)
      -007 |__do_softirq()
      -008 |do_softirq()
      -009 |local_bh_enable()
      -010 |tcp_rcv_established(sk = 0x8BE6B2A0, skb = 0x87D3A9E0, th = 0x814EBE14, ?)
      -011 |tcp_v4_do_rcv(sk = 0x8BE6B2A0, skb = 0x87D3A9E0)
      -012 |tcp_delack_timer_handler(sk = 0x8BE6B2A0)
      -013 |tcp_release_cb(sk = 0x8BE6B2A0)
      -014 |release_sock(sk = 0x8BE6B2A0)
      -015 |tcp_sendmsg(?, sk = 0x8BE6B2A0, ?, ?)
      -016 |sock_sendmsg(sock = 0x8518C4C0, msg = 0x87D8DAA8, size = 4096)
      -017 |kernel_sendmsg(?, ?, ?, ?, size = 4096)
      -018 |smb_send_kvec()
      -019 |smb_send_rqst(server = 0x87C4D400, rqst = 0x87D8DBA0)
      -020 |cifs_call_async()
      -021 |cifs_async_writev(wdata = 0x87FD6580)
      -022 |cifs_writepages(mapping = 0x852096E4, wbc = 0x87D8DC88)
      -023 |__writeback_single_inode(inode = 0x852095D0, wbc = 0x87D8DC88)
      -024 |writeback_sb_inodes(sb = 0x87D6D800, wb = 0x87E4A9C0, work = 0x87D8DD88)
      -025 |__writeback_inodes_wb(wb = 0x87E4A9C0, work = 0x87D8DD88)
      -026 |wb_writeback(wb = 0x87E4A9C0, work = 0x87D8DD88)
      -027 |wb_do_writeback(wb = 0x87E4A9C0, force_wait = 0)
      -028 |bdi_writeback_workfn(work = 0x87E4A9CC)
      -029 |process_one_work(worker = 0x8B045880, work = 0x87E4A9CC)
      -030 |worker_thread(__worker = 0x8B045880)
      -031 |kthread(_create = 0x87CADD90)
      -032 |ret_from_kernel_thread(asm)
      
      Bug occurs because __tcp_checksum_complete_user() enables BH, assuming
      it is running from softirq context.
      
      Lars trace involved a NIC without RX checksum support but other points
      are problematic as well, like the prequeue stuff.
      
      Problem is triggered by a timer, that found socket being owned by user.
      
      tcp_release_cb() should call tcp_write_timer_handler() or
      tcp_delack_timer_handler() in the appropriate context :
      
      BH disabled and socket lock held, but 'owned' field cleared,
      as if they were running from timer handlers.
      
      Fixes: 6f458dfb ("tcp: improve latencies of timer triggered events")
      Reported-by: NLars Persson <lars.persson@axis.com>
      Tested-by: NLars Persson <lars.persson@axis.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3f9b018
  5. 11 3月, 2014 2 次提交
    • X
      ASoC: io: New signature for snd_soc_codec_set_cache_io() · 092eba93
      Xiubo Li 提交于
      Now that all users have been converted to regmap and the config.reg_bits
      and config.val_bits can be setted by each user through regmap core API.
      So these two params are redundant here.
      
      Since the only control type that left is SND_SOC_REGMAP, so remove it. Drop
      the control params and add struct regmap *regmap to simplify the code.
      Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      092eba93
    • J
      mm: fix GFP_THISNODE callers and clarify · e97ca8e5
      Johannes Weiner 提交于
      GFP_THISNODE is for callers that implement their own clever fallback to
      remote nodes.  It restricts the allocation to the specified node and
      does not invoke reclaim, assuming that the caller will take care of it
      when the fallback fails, e.g.  through a subsequent allocation request
      without GFP_THISNODE set.
      
      However, many current GFP_THISNODE users only want the node exclusive
      aspect of the flag, without actually implementing their own fallback or
      triggering reclaim if necessary.  This results in things like page
      migration failing prematurely even when there is easily reclaimable
      memory available, unless kswapd happens to be running already or a
      concurrent allocation attempt triggers the necessary reclaim.
      
      Convert all callsites that don't implement their own fallback strategy
      to __GFP_THISNODE.  This restricts the allocation a single node too, but
      at the same time allows the allocator to enter the slowpath, wake
      kswapd, and invoke direct reclaim if necessary, to make the allocation
      happen when memory is full.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NRik van Riel <riel@redhat.com>
      Cc: Jan Stancek <jstancek@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e97ca8e5
  6. 10 3月, 2014 4 次提交
    • A
      get rid of fget_light() · bd2a31d5
      Al Viro 提交于
      instead of returning the flags by reference, we can just have the
      low-level primitive return those in lower bits of unsigned long,
      with struct file * derived from the rest.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bd2a31d5
    • L
      vfs: atomic f_pos accesses as per POSIX · 9c225f26
      Linus Torvalds 提交于
      Our write() system call has always been atomic in the sense that you get
      the expected thread-safe contiguous write, but we haven't actually
      guaranteed that concurrent writes are serialized wrt f_pos accesses, so
      threads (or processes) that share a file descriptor and use "write()"
      concurrently would quite likely overwrite each others data.
      
      This violates POSIX.1-2008/SUSv4 Section XSI 2.9.7 that says:
      
       "2.9.7 Thread Interactions with Regular File Operations
      
        All of the following functions shall be atomic with respect to each
        other in the effects specified in POSIX.1-2008 when they operate on
        regular files or symbolic links: [...]"
      
      and one of the effects is the file position update.
      
      This unprotected file position behavior is not new behavior, and nobody
      has ever cared.  Until now.  Yongzhi Pan reported unexpected behavior to
      Michael Kerrisk that was due to this.
      
      This resolves the issue with a f_pos-specific lock that is taken by
      read/write/lseek on file descriptors that may be shared across threads
      or processes.
      Reported-by: NYongzhi Pan <panyongzhi@gmail.com>
      Reported-by: NMichael Kerrisk <mtk.manpages@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9c225f26
    • M
      ASoC: dapm: Staticise dapm_mark_dirty() · 492c0a18
      Mark Brown 提交于
      The function is not called outside soc-dapm.c so there is no need for it
      to be exported.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      492c0a18
    • L
      ASoC: Add a per component dai list · 1438c2f6
      Lars-Peter Clausen 提交于
      Now that every DAI has a component we can track the DAIs on a per component
      basis. This simplifies the DAI lookup when we are only interested in DAIs of a
      specific component and also makes it possible to have multiple components with
      the same parent device and also register DAIs.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      1438c2f6
  7. 09 3月, 2014 1 次提交
  8. 08 3月, 2014 1 次提交
    • D
      SUNRPC: Fix oops when trace sunrpc_task events in nfs client · 2ca310fc
      Ditang Chen 提交于
      When tracking sunrpc_task events in nfs client, the clnt pointer may be NULL.
      
      [  139.269266] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      [  139.269915] IP: [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915] PGD 1d293067 PUD 1d294067 PMD 0
      [  139.269915] Oops: 0000 [#1] SMP
      [  139.269915] Modules linked in: nfsv4 dns_resolver nfs lockd sunrpc fscache sg ppdev e1000
      serio_raw pcspkr parport_pc parport i2c_piix4 i2c_core microcode xfs libcrc32c sd_mod sr_mod
      cdrom ata_generic crc_t10dif crct10dif_common pata_acpi ahci libahci ata_piix libata dm_mirror
      dm_region_hash dm_log dm_mod
      [  139.269915] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 3.10.0-84.el7.x86_64 #1
      [  139.269915] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  139.269915] Workqueue: rpciod rpc_async_schedule [sunrpc]
      [  139.269915] task: ffff88001b598000 ti: ffff88001b632000 task.ti: ffff88001b632000
      [  139.269915] RIP: 0010:[<ffffffffa026f216>]  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915] RSP: 0018:ffff88001b633d70  EFLAGS: 00010206
      [  139.269915] RAX: ffff88001dfc5338 RBX: ffff88001cc37a00 RCX: ffff88001dfc5334
      [  139.269915] RDX: ffff88001dfc5338 RSI: 0000000000000000 RDI: ffff88001dfc533c
      [  139.269915] RBP: ffff88001b633db0 R08: 000000000000002c R09: 000000000000000a
      [  139.269915] R10: 0000000000062180 R11: 00000020759fb9dc R12: ffffffffa0292c20
      [  139.269915] R13: ffff88001dfc5334 R14: 0000000000000000 R15: 0000000000000000
      [  139.269915] FS:  0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
      [  139.269915] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  139.269915] CR2: 0000000000000004 CR3: 000000001d290000 CR4: 00000000000006f0
      [  139.269915] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  139.269915] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  139.269915] Stack:
      [  139.269915]  000000001b633d98 0000000000000246 ffff88001df1dc00 ffff88001cc37a00
      [  139.269915]  ffff88001bc35e60 0000000000000000 ffff88001ffa0a48 ffff88001bc35ee0
      [  139.269915]  ffff88001b633e08 ffffffffa02704b5 0000000000010000 ffff88001cc37a70
      [  139.269915] Call Trace:
      [  139.269915]  [<ffffffffa02704b5>] __rpc_execute+0x1d5/0x400 [sunrpc]
      [  139.269915]  [<ffffffffa0270706>] rpc_async_schedule+0x26/0x30 [sunrpc]
      [  139.269915]  [<ffffffff8107867b>] process_one_work+0x17b/0x460
      [  139.269915]  [<ffffffff8107942b>] worker_thread+0x11b/0x400
      [  139.269915]  [<ffffffff81079310>] ? rescuer_thread+0x3e0/0x3e0
      [  139.269915]  [<ffffffff8107fc80>] kthread+0xc0/0xd0
      [  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
      [  139.269915]  [<ffffffff815d122c>] ret_from_fork+0x7c/0xb0
      [  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
      [  139.269915] Code: 4c 8b 45 c8 48 8d 7d d0 89 4d c4 41 89 c9 b9 28 00 00 00 e8 9d b4 e9
      e0 48 85 c0 49 89 c5 74 a2 48 89 c7 e8 9d 3f e9 e0 48 89 c2 <41> 8b 46 04 48 8b 7d d0 4c
      89 e9 4c 89 e6 89 42 0c 0f b7 83 d4
      [  139.269915] RIP  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915]  RSP <ffff88001b633d70>
      [  139.269915] CR2: 0000000000000004
      [  140.946406] ---[ end trace ba486328b98d7622 ]---
      Signed-off-by: NDitang Chen <chendt.fnst@cn.fujitsu.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      2ca310fc
  9. 07 3月, 2014 2 次提交
    • T
      firewire: don't use PREPARE_DELAYED_WORK · 70044d71
      Tejun Heo 提交于
      PREPARE_[DELAYED_]WORK() are being phased out.  They have few users
      and a nasty surprise in terms of reentrancy guarantee as workqueue
      considers work items to be different if they don't have the same work
      function.
      
      firewire core-device and sbp2 have been been multiplexing work items
      with multiple work functions.  Introduce fw_device_workfn() and
      sbp2_lu_workfn() which invoke fw_device->workfn and
      sbp2_logical_unit->workfn respectively and always use the two
      functions as the work functions and update the users to set the
      ->workfn fields instead of overriding work functions using
      PREPARE_DELAYED_WORK().
      
      This fixes a variety of possible regressions since a2c1c57b
      "workqueue: consider work function when searching for busy work items"
      due to which fw_workqueue lost its required non-reentrancy property.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: linux1394-devel@lists.sourceforge.net
      Cc: stable@vger.kernel.org # v3.9+
      Cc: stable@vger.kernel.org # v3.8.2+
      Cc: stable@vger.kernel.org # v3.4.60+
      Cc: stable@vger.kernel.org # v3.2.40+
      70044d71
    • A
      net: Improve SO_TIMESTAMPING documentation and fix a minor code bug · adca4767
      Andrew Lutomirski 提交于
      The original documentation was very unclear.
      
      The code fix is presumably related to the formerly unclear
      documentation: SOCK_TIMESTAMPING_RX_SOFTWARE has no effect on
      __sock_recv_timestamp's behavior, so calling __sock_recv_ts_and_drops
      from sock_recv_ts_and_drops if only SOCK_TIMESTAMPING_RX_SOFTWARE is
      set is pointless.  This should have no user-observable effect.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      adca4767
  10. 06 3月, 2014 8 次提交
  11. 05 3月, 2014 4 次提交
  12. 04 3月, 2014 5 次提交
    • L
      mm: numa: bugfix for LAST_CPUPID_NOT_IN_PAGE_FLAGS · 1ae71d03
      Liu Ping Fan 提交于
      When doing some numa tests on powerpc, I triggered an oops bug.  I find
      it is caused by using page->_last_cpupid.  It should be initialized as
      "-1 & LAST_CPUPID_MASK", but not "-1".  Otherwise, in task_numa_fault(),
      we will miss the checking (last_cpupid == (-1 & LAST_CPUPID_MASK)).  And
      finally cause an oops bug in task_numa_group(), since the online cpu is
      less than possible cpu.  This happen with CONFIG_SPARSE_VMEMMAP disabled
      
      Call trace:
      
        SMP NR_CPUS=64 NUMA PowerNV
        Modules linked in:
        CPU: 24 PID: 804 Comm: systemd-udevd Not tainted3.13.0-rc1+ #32
        task: c000001e2746aa80 ti: c000001e32c50000 task.ti:c000001e32c50000
        REGS: c000001e32c53510 TRAP: 0300   Not tainted(3.13.0-rc1+)
        MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI>  CR:28024424  XER: 20000000
        CFAR: c000000000009324 DAR: 7265717569726857 DSISR:40000000 SOFTE: 1
        NIP  .task_numa_fault+0x1470/0x2370
        LR  .task_numa_fault+0x1468/0x2370
        Call Trace:
         .task_numa_fault+0x1468/0x2370 (unreliable)
         .do_numa_page+0x480/0x4a0
         .handle_mm_fault+0x4ec/0xc90
         .do_page_fault+0x3a8/0x890
         handle_page_fault+0x10/0x30
        Instruction dump:
        3c82fefb 3884b138 48d9cff1 60000000 48000574 3c62fefb3863af78 3c82fefb
        3884b138 48d9cfd5 60000000 e93f0100 <812902e4> 7d2907b45529063e 7d2a07b4
        ---[ end trace 15f2510da5ae07cf ]---
      Signed-off-by: NLiu Ping Fan <pingfank@linux.vnet.ibm.com>
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1ae71d03
    • V
      mm: include VM_MIXEDMAP flag in the VM_SPECIAL list to avoid m(un)locking · 9050d7eb
      Vlastimil Babka 提交于
      Daniel Borkmann reported a VM_BUG_ON assertion failing:
      
        ------------[ cut here ]------------
        kernel BUG at mm/mlock.c:528!
        invalid opcode: 0000 [#1] SMP
        Modules linked in: ccm arc4 iwldvm [...]
         video
        CPU: 3 PID: 2266 Comm: netsniff-ng Not tainted 3.14.0-rc2+ #8
        Hardware name: LENOVO 2429BP3/2429BP3, BIOS G4ET37WW (1.12 ) 05/29/2012
        task: ffff8801f87f9820 ti: ffff88002cb44000 task.ti: ffff88002cb44000
        RIP: 0010:[<ffffffff81171ad0>]  [<ffffffff81171ad0>] munlock_vma_pages_range+0x2e0/0x2f0
        Call Trace:
          do_munmap+0x18f/0x3b0
          vm_munmap+0x41/0x60
          SyS_munmap+0x22/0x30
          system_call_fastpath+0x1a/0x1f
        RIP   munlock_vma_pages_range+0x2e0/0x2f0
        ---[ end trace a0088dcf07ae10f2 ]---
      
      because munlock_vma_pages_range() thinks it's unexpectedly in the middle
      of a THP page.  This can be reproduced with default config since 3.11
      kernels.  A reproducer can be found in the kernel's selftest directory
      for networking by running ./psock_tpacket.
      
      The problem is that an order=2 compound page (allocated by
      alloc_one_pg_vec_page() is part of the munlocked VM_MIXEDMAP vma (mapped
      by packet_mmap()) and mistaken for a THP page and assumed to be order=9.
      
      The checks for THP in munlock came with commit ff6a6da6 ("mm:
      accelerate munlock() treatment of THP pages"), i.e.  since 3.9, but did
      not trigger a bug.  It just makes munlock_vma_pages_range() skip such
      compound pages until the next 512-pages-aligned page, when it encounters
      a head page.  This is however not a problem for vma's where mlocking has
      no effect anyway, but it can distort the accounting.
      
      Since commit 7225522b ("mm: munlock: batch non-THP page isolation
      and munlock+putback using pagevec") this can trigger a VM_BUG_ON in
      PageTransHuge() check.
      
      This patch fixes the issue by adding VM_MIXEDMAP flag to VM_SPECIAL, a
      list of flags that make vma's non-mlockable and non-mergeable.  The
      reasoning is that VM_MIXEDMAP vma's are similar to VM_PFNMAP, which is
      already on the VM_SPECIAL list, and both are intended for non-LRU pages
      where mlocking makes no sense anyway.  Related Lkml discussion can be
      found in [2].
      
       [1] tools/testing/selftests/net/psock_tpacket
       [2] https://lkml.org/lkml/2014/1/10/427Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Reported-by: NDaniel Borkmann <dborkman@redhat.com>
      Tested-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Cc: John David Anglin <dave.anglin@bell.net>
      Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Jared Hulbert <jaredeh@gmail.com>
      Tested-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: NRik van Riel <riel@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: <stable@vger.kernel.org> [3.11.x+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9050d7eb
    • D
      mm: close PageTail race · 668f9abb
      David Rientjes 提交于
      Commit bf6bddf1 ("mm: introduce compaction and migration for
      ballooned pages") introduces page_count(page) into memory compaction
      which dereferences page->first_page if PageTail(page).
      
      This results in a very rare NULL pointer dereference on the
      aforementioned page_count(page).  Indeed, anything that does
      compound_head(), including page_count() is susceptible to racing with
      prep_compound_page() and seeing a NULL or dangling page->first_page
      pointer.
      
      This patch uses Andrea's implementation of compound_trans_head() that
      deals with such a race and makes it the default compound_head()
      implementation.  This includes a read memory barrier that ensures that
      if PageTail(head) is true that we return a head page that is neither
      NULL nor dangling.  The patch then adds a store memory barrier to
      prep_compound_page() to ensure page->first_page is set.
      
      This is the safest way to ensure we see the head page that we are
      expecting, PageTail(page) is already in the unlikely() path and the
      memory barriers are unfortunately required.
      
      Hugetlbfs is the exception, we don't enforce a store memory barrier
      during init since no race is possible.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Holger Kiehl <Holger.Kiehl@dwd.de>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Rafael Aquini <aquini@redhat.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      668f9abb
    • M
      ASoC: io: Remove hw_read() operation · feff9f3c
      Mark Brown 提交于
      We now no longer have any users of hw_read() in the kernel so remove the
      code in order to prevent any new users being added. Users should be using
      regmap.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      feff9f3c
    • S
      tracing: Do not add event files for modules that fail tracepoints · 45ab2813
      Steven Rostedt (Red Hat) 提交于
      If a module fails to add its tracepoints due to module tainting, do not
      create the module event infrastructure in the debugfs directory. As the events
      will not work and worse yet, they will silently fail, making the user wonder
      why the events they enable do not display anything.
      
      Having a warning on module load and the events not visible to the users
      will make the cause of the problem much clearer.
      
      Link: http://lkml.kernel.org/r/20140227154923.265882695@goodmis.org
      
      Fixes: 6d723736 "tracing/events: add support for modules to TRACE_EVENT"
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: stable@vger.kernel.org # 2.6.31+
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      45ab2813
  13. 03 3月, 2014 1 次提交
  14. 02 3月, 2014 1 次提交
  15. 01 3月, 2014 6 次提交
    • E
      audit: Send replies in the proper network namespace. · 6f285b19
      Eric W. Biederman 提交于
      In perverse cases of file descriptor passing the current network
      namespace of a process and the network namespace of a socket used by
      that socket may differ.  Therefore use the network namespace of the
      appropiate socket to ensure replies always go to the appropiate
      socket.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      6f285b19
    • L
      ASoC: dapm: Consolidate MUXs and virtual MUXs · 236aaa68
      Lars-Peter Clausen 提交于
      MUXs and virtual MUXs are almost identical, the only difference is that for
      virtual MUX there is no hardware backing register in which setting is stored.
      This patch adds code, which is similar to what we already do for DAPM mixer
      controls to support virtual mixer controls, to DAPM enum controls. The new code
      will check if the enum does a hardware backing register and skip over reading
      and writing to the register if it has not.  This allows us to use the same code
      path for both MUXs and virtual MUXs and a lot of nearly identical code can be
      removed.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      236aaa68
    • L
      ASoC: Add macros for defining virtual enums · b948837a
      Lars-Peter Clausen 提交于
      With the upcoming consolidation of normal MUXs and virtual MUXs we need to be
      able to distinguish between enums with and without a backing register at the
      enum level. Use the same approach as used for virtual mixer controls by setting
      the reg field of the enum to SND_SOC_NOPM for enums without a backing register.
      This patch adds a set of helper macros that can be used to define such enums.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      b948837a
    • L
      ASoC: dapm: Consolidate MUXs and value MUXs · 3727b496
      Lars-Peter Clausen 提交于
      MUXs and value MUXs are almost identical, the only difference is that a value
      MUX uses a look-up table to map from the selected control item to a register
      value, while MUXs use a direct mapping. This patch uses
      snd_soc_enum_item_to_val() and snd_soc_enum_val_to_item(), which where earlier
      introduced during the consolidation of enum and value enum controls, to hide
      this difference. This allows us to use the same code path for both MUXs and
      value MUXs and a lot of nearly duplicated code can be removed.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      3727b496
    • L
      ASoC: Consolidate enum and value enum controls · 29ae2fa5
      Lars-Peter Clausen 提交于
      The implementations for enum and value enum controls are almost identical. The
      only difference is that the value enum uses an additional look-up table to map
      the control value to the register value, while the enum control uses a direct
      mapping. Enums and value enums can easily be distinguished at runtime, for value
      enums the values field of the snd_soc_enum struct contains the look-up table,
      while for enums it is NULL. This patch adds two new small helper functions
      called snd_soc_enum_item_to_val() and snd_soc_enum_val_to_item() which map
      between register value and control item. If the items field of the snd_soc_enum
      struct is NULL the function will do a direct mapping otherwise they'll use the
      look-up table to do the mapping. Using these small helper functions it is
      possible to use the same kcontrol handlers for both enums and value enums. The
      functions are added a inline functions in soc.h so they can also be used by the
      DAPM code to accomplish similar consolidation.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      29ae2fa5
    • L
      8303d769
  16. 26 2月, 2014 1 次提交
    • D
      ipc,mqueue: remove limits for the amount of system-wide queues · f3713fd9
      Davidlohr Bueso 提交于
      Commit 93e6f119 ("ipc/mqueue: cleanup definition names and
      locations") added global hardcoded limits to the amount of message
      queues that can be created.  While these limits are per-namespace,
      reality is that it ends up breaking userspace applications.
      Historically users have, at least in theory, been able to create up to
      INT_MAX queues, and limiting it to just 1024 is way too low and dramatic
      for some workloads and use cases.  For instance, Madars reports:
      
       "This update imposes bad limits on our multi-process application.  As
        our app uses approaches that each process opens its own set of queues
        (usually something about 3-5 queues per process).  In some scenarios
        we might run up to 3000 processes or more (which of-course for linux
        is not a problem).  Thus we might need up to 9000 queues or more.  All
        processes run under one user."
      
      Other affected users can be found in launchpad bug #1155695:
        https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695
      
      Instead of increasing this limit, revert it entirely and fallback to the
      original way of dealing queue limits -- where once a user's resource
      limit is reached, and all memory is used, new queues cannot be created.
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      Reported-by: NMadars Vitolins <m@silodev.com>
      Acked-by: NDoug Ledford <dledford@redhat.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: <stable@vger.kernel.org>	[3.5+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f3713fd9