1. 08 1月, 2016 2 次提交
  2. 21 12月, 2015 1 次提交
  3. 09 12月, 2015 1 次提交
  4. 04 12月, 2015 4 次提交
    • D
      drm/nouveau: Fix pre-nv50 pageflip events (v4) · bbc8764f
      Daniel Vetter 提交于
      Apparently pre-nv50 pageflip events happen before the actual vblank
      period. Therefore that functionality got semi-disabled in
      
      commit af4870e4
      Author: Mario Kleiner <mario.kleiner.de@gmail.com>
      Date:   Tue May 13 00:42:08 2014 +0200
      
          drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
      
      Unfortunately that hack got uprooted in
      
      commit cc1ef118
      Author: Thierry Reding <treding@nvidia.com>
      Date:   Wed Aug 12 17:00:31 2015 +0200
      
          drm/irq: Make pipe unsigned and name consistent
      
      Triggering a warning when trying to sample the vblank timestamp for a
      non-existing pipe. There's a few ways to fix this:
      
      - Open-code the old behaviour, which just enshrines this slight
        breakage of the userspace ABI.
      
      - Revert Mario's commit and again inflict broken timestamps, again not
        pretty.
      
      - Fix this for real by delaying the pageflip TS until the next vblank
        interrupt, thereby making it accurate.
      
      This patch implements the third option. Since having a page flip
      interrupt that happens when the pageflip gets armed and not when it
      completes in the next vblank seems to be fairly common (older i915 hw
      works very similarly) create a new helper to arm vblank events for
      such drivers.
      
      v2 (Mario Kleiner):
      - Fix function prototypes in drmP.h
      - Add missing vblank_put() for pageflip completion without
        pageflip event.
      - Initialize sequence number for queued pageflip event to avoid
        trouble in drm_handle_vblank_events().
      - Remove dead code and spelling fix.
      
      v3 (Mario Kleiner):
      - Add a signed-off-by and cc stable tag per Ilja's advice.
      
      v4 (Thierry Reding):
      - Fix kerneldoc typo, discovered by Michel Dänzer
      - Rearrange tags and changelog
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
      Acked-by: NBen Skeggs <bskeggs@redhat.com>
      Cc: Ilia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: stable@vger.kernel.org # v4.3
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      bbc8764f
    • T
      drm: Fix an unwanted master inheritance v2 · a0af2e53
      Thomas Hellstrom 提交于
      A client calling drmSetMaster() using a file descriptor that was opened
      when another client was master would inherit the latter client's master
      object and all its authenticated clients.
      
      This is unwanted behaviour, and when this happens, instead allocate a
      brand new master object for the client calling drmSetMaster().
      
      Fixes a BUG() throw in vmw_master_set().
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a0af2e53
    • E
      net_sched: fix qdisc_tree_decrease_qlen() races · 4eaf3b84
      Eric Dumazet 提交于
      qdisc_tree_decrease_qlen() suffers from two problems on multiqueue
      devices.
      
      One problem is that it updates sch->q.qlen and sch->qstats.drops
      on the mq/mqprio root qdisc, while it should not : Daniele
      reported underflows errors :
      [  681.774821] PAX: sch->q.qlen: 0 n: 1
      [  681.774825] PAX: size overflow detected in function qdisc_tree_decrease_qlen net/sched/sch_api.c:769 cicus.693_49 min, count: 72, decl: qlen; num: 0; context: sk_buff_head;
      [  681.774954] CPU: 2 PID: 19 Comm: ksoftirqd/2 Tainted: G           O    4.2.6.201511282239-1-grsec #1
      [  681.774955] Hardware name: ASUSTeK COMPUTER INC. X302LJ/X302LJ, BIOS X302LJ.202 03/05/2015
      [  681.774956]  ffffffffa9a04863 0000000000000000 0000000000000000 ffffffffa990ff7c
      [  681.774959]  ffffc90000d3bc38 ffffffffa95d2810 0000000000000007 ffffffffa991002b
      [  681.774960]  ffffc90000d3bc68 ffffffffa91a44f4 0000000000000001 0000000000000001
      [  681.774962] Call Trace:
      [  681.774967]  [<ffffffffa95d2810>] dump_stack+0x4c/0x7f
      [  681.774970]  [<ffffffffa91a44f4>] report_size_overflow+0x34/0x50
      [  681.774972]  [<ffffffffa94d17e2>] qdisc_tree_decrease_qlen+0x152/0x160
      [  681.774976]  [<ffffffffc02694b1>] fq_codel_dequeue+0x7b1/0x820 [sch_fq_codel]
      [  681.774978]  [<ffffffffc02680a0>] ? qdisc_peek_dequeued+0xa0/0xa0 [sch_fq_codel]
      [  681.774980]  [<ffffffffa94cd92d>] __qdisc_run+0x4d/0x1d0
      [  681.774983]  [<ffffffffa949b2b2>] net_tx_action+0xc2/0x160
      [  681.774985]  [<ffffffffa90664c1>] __do_softirq+0xf1/0x200
      [  681.774987]  [<ffffffffa90665ee>] run_ksoftirqd+0x1e/0x30
      [  681.774989]  [<ffffffffa90896b0>] smpboot_thread_fn+0x150/0x260
      [  681.774991]  [<ffffffffa9089560>] ? sort_range+0x40/0x40
      [  681.774992]  [<ffffffffa9085fe4>] kthread+0xe4/0x100
      [  681.774994]  [<ffffffffa9085f00>] ? kthread_worker_fn+0x170/0x170
      [  681.774995]  [<ffffffffa95d8d1e>] ret_from_fork+0x3e/0x70
      
      mq/mqprio have their own ways to report qlen/drops by folding stats on
      all their queues, with appropriate locking.
      
      A second problem is that qdisc_tree_decrease_qlen() calls qdisc_lookup()
      without proper locking : concurrent qdisc updates could corrupt the list
      that qdisc_match_from_root() parses to find a qdisc given its handle.
      
      Fix first problem adding a TCQ_F_NOPARENT qdisc flag that
      qdisc_tree_decrease_qlen() can use to abort its tree traversal,
      as soon as it meets a mq/mqprio qdisc children.
      
      Second problem can be fixed by RCU protection.
      Qdisc are already freed after RCU grace period, so qdisc_list_add() and
      qdisc_list_del() simply have to use appropriate rcu list variants.
      
      A future patch will add a per struct netdev_queue list anchor, so that
      qdisc_tree_decrease_qlen() can have more efficient lookups.
      Reported-by: NDaniele Fucini <dfucini@gmail.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Cong Wang <cwang@twopensource.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4eaf3b84
    • E
      ipv6: kill sk_dst_lock · 6bd4f355
      Eric Dumazet 提交于
      While testing the np->opt RCU conversion, I found that UDP/IPv6 was
      using a mixture of xchg() and sk_dst_lock to protect concurrent changes
      to sk->sk_dst_cache, leading to possible corruptions and crashes.
      
      ip6_sk_dst_lookup_flow() uses sk_dst_check() anyway, so the simplest
      way to fix the mess is to remove sk_dst_lock completely, as we did for
      IPv4.
      
      __ip6_dst_store() and ip6_dst_store() share same implementation.
      
      sk_setup_caps() being called with socket lock being held or not,
      we have to use sk_dst_set() instead of __sk_dst_set()
      
      Note that I had to move the "np->dst_cookie = rt6_get_cookie(rt);"
      in ip6_dst_store() before the sk_setup_caps(sk, dst) call.
      
      This is because ip6_dst_store() can be called from process context,
      without any lock held.
      
      As soon as the dst is installed in sk->sk_dst_cache, dst can be freed
      from another cpu doing a concurrent ip6_dst_store()
      
      Doing the dst dereference before doing the install is needed to make
      sure no use after free would trigger.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6bd4f355
  5. 03 12月, 2015 3 次提交
  6. 02 12月, 2015 4 次提交
  7. 30 11月, 2015 3 次提交
  8. 29 11月, 2015 2 次提交
    • B
      kref: Remove kref_put_spinlock_irqsave() · 3a66d7dc
      Bart Van Assche 提交于
      The last user is gone. Hence remove this function.
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Joern Engel <joern@logfs.org>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      3a66d7dc
    • N
      target: Fix race for SCF_COMPARE_AND_WRITE_POST checking · 057085e5
      Nicholas Bellinger 提交于
      This patch addresses a race + use after free where the first
      stage of COMPARE_AND_WRITE in compare_and_write_callback()
      is rescheduled after the backend sends the secondary WRITE,
      resulting in second stage compare_and_write_post() callback
      completing in target_complete_ok_work() before the first
      can return.
      
      Because current code depends on checking se_cmd->se_cmd_flags
      after return from se_cmd->transport_complete_callback(),
      this results in first stage having SCF_COMPARE_AND_WRITE_POST
      set, which incorrectly falls through into second stage CAW
      processing code, eventually triggering a NULL pointer
      dereference due to use after free.
      
      To address this bug, pass in a new *post_ret parameter into
      se_cmd->transport_complete_callback(), and depend upon this
      value instead of ->se_cmd_flags to determine when to return
      or fall through into ->queue_status() code for CAW.
      
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: <stable@vger.kernel.org> # v3.12+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      057085e5
  9. 26 11月, 2015 3 次提交
    • M
      block/sd: Fix device-imposed transfer length limits · ca369d51
      Martin K. Petersen 提交于
      Commit 4f258a46 ("sd: Fix maximum I/O size for BLOCK_PC requests")
      had the unfortunate side-effect of removing an implicit clamp to
      BLK_DEF_MAX_SECTORS for REQ_TYPE_FS requests in the block layer
      code. This caused problems for some SMR drives.
      
      Debugging this issue revealed a few problems with the existing
      infrastructure since the block layer didn't know how to deal with
      device-imposed limits, only limits set by the I/O controller.
      
       - Introduce a new queue limit, max_dev_sectors, which is used by the
         ULD to signal the maximum sectors for a REQ_TYPE_FS request.
      
       - Ensure that max_dev_sectors is correctly stacked and taken into
         account when overriding max_sectors through sysfs.
      
       - Rework sd_read_block_limits() so it saves the max_xfer and opt_xfer
         values for later processing.
      
       - In sd_revalidate() set the queue's max_dev_sectors based on the
         MAXIMUM TRANSFER LENGTH value in the Block Limits VPD. If this value
         is not reported, fall back to a cap based on the CDB TRANSFER LENGTH
         field size.
      
       - In sd_revalidate(), use OPTIMAL TRANSFER LENGTH from the Block Limits
         VPD--if reported and sane--to signal the preferred device transfer
         size for FS requests. Otherwise use BLK_DEF_MAX_SECTORS.
      
       - blk_limits_max_hw_sectors() is no longer used and can be removed.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93581Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Tested-by: sweeneygj@gmx.com
      Tested-by: NArzeets <anatol.pomozov@gmail.com>
      Tested-by: NDavid Eisner <david.eisner@oriel.oxon.org>
      Tested-by: NMario Kicherer <dev@kicherer.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      ca369d51
    • G
      ARM/PCI: Move align_resource function pointer to pci_host_bridge structure · 7c7a0e94
      Gabriele Paoloni 提交于
      Commit b3a72384 ("ARM/PCI: Replace pci_sys_data->align_resource with
      global function pointer") introduced an ARM-specific align_resource()
      function pointer.  This is not portable to other arches and doesn't work
      for platforms with two different PCIe host bridge controllers.
      
      Move the function pointer to the pci_host_bridge structure so each host
      bridge driver can specify its own align_resource() function.
      Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      7c7a0e94
    • D
      bpf: fix clearing on persistent program array maps · c9da161c
      Daniel Borkmann 提交于
      Currently, when having map file descriptors pointing to program arrays,
      there's still the issue that we unconditionally flush program array
      contents via bpf_fd_array_map_clear() in bpf_map_release(). This happens
      when such a file descriptor is released and is independent of the map's
      refcount.
      
      Having this flush independent of the refcount is for a reason: there
      can be arbitrary complex dependency chains among tail calls, also circular
      ones (direct or indirect, nesting limit determined during runtime), and
      we need to make sure that the map drops all references to eBPF programs
      it holds, so that the map's refcount can eventually drop to zero and
      initiate its freeing. Btw, a walk of the whole dependency graph would
      not be possible for various reasons, one being complexity and another
      one inconsistency, i.e. new programs can be added to parts of the graph
      at any time, so there's no guaranteed consistent state for the time of
      such a walk.
      
      Now, the program array pinning itself works, but the issue is that each
      derived file descriptor on close would nevertheless call unconditionally
      into bpf_fd_array_map_clear(). Instead, keep track of users and postpone
      this flush until the last reference to a user is dropped. As this only
      concerns a subset of references (f.e. a prog array could hold a program
      that itself has reference on the prog array holding it, etc), we need to
      track them separately.
      
      Short analysis on the refcounting: on map creation time usercnt will be
      one, so there's no change in behaviour for bpf_map_release(), if unpinned.
      If we already fail in map_create(), we are immediately freed, and no
      file descriptor has been made public yet. In bpf_obj_pin_user(), we need
      to probe for a possible map in bpf_fd_probe_obj() already with a usercnt
      reference, so before we drop the reference on the fd with fdput().
      Therefore, if actual pinning fails, we need to drop that reference again
      in bpf_any_put(), otherwise we keep holding it. When last reference
      drops on the inode, the bpf_any_put() in bpf_evict_inode() will take
      care of dropping the usercnt again. In the bpf_obj_get_user() case, the
      bpf_any_get() will grab a reference on the usercnt, still at a time when
      we have the reference on the path. Should we later on fail to grab a new
      file descriptor, bpf_any_put() will drop it, otherwise we hold it until
      bpf_map_release() time.
      
      Joint work with Alexei.
      
      Fixes: b2197755 ("bpf: add support for persistent maps/progs")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9da161c
  10. 25 11月, 2015 3 次提交
    • A
      arm64: fix building without CONFIG_UID16 · fbc416ff
      Arnd Bergmann 提交于
      As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
      disabled currently fails because the system call table still needs to
      reference the individual function entry points that are provided by
      kernel/sys_ni.c in this case, and the declarations are hidden inside
      of #ifdef CONFIG_UID16:
      
      arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function)
       __SYSCALL(__NR_lchown, sys_lchown16)
      
      I believe this problem only exists on ARM64, because older architectures
      tend to not need declarations when their system call table is built
      in assembly code, while newer architectures tend to not need UID16
      support. ARM64 only uses these system calls for compatibility with
      32-bit ARM binaries.
      
      This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is
      set unconditionally on ARM64 with CONFIG_COMPAT, so we see the
      declarations whenever we need them, but otherwise the behavior is
      unchanged.
      
      Fixes: af1839eb ("Kconfig: clean up the long arch list for the UID16 config option")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      fbc416ff
    • M
      ipv6: distinguish frag queues by device for multicast and link-local packets · 264640fc
      Michal Kubeček 提交于
      If a fragmented multicast packet is received on an ethernet device which
      has an active macvlan on top of it, each fragment is duplicated and
      received both on the underlying device and the macvlan. If some
      fragments for macvlan are processed before the whole packet for the
      underlying device is reassembled, the "overlapping fragments" test in
      ip6_frag_queue() discards the whole fragment queue.
      
      To resolve this, add device ifindex to the search key and require it to
      match reassembling multicast packets and packets to link-local
      addresses.
      
      Note: similar patch has been already submitted by Yoshifuji Hideaki in
      
        http://patchwork.ozlabs.org/patch/220979/
      
      but got lost and forgotten for some reason.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      264640fc
    • C
      KVM: arm/arm64: arch_timer: Preserve physical dist. active state on LR.active · 0e3dfda9
      Christoffer Dall 提交于
      We were incorrectly removing the active state from the physical
      distributor on the timer interrupt when the timer output level was
      deasserted.  We shouldn't be doing this without considering the virtual
      interrupt's active state, because the architecture requires that when an
      LR has the HW bit set and the pending or active bits set, then the
      physical interrupt must also have the corresponding bits set.
      
      This addresses an issue where we have been observing an inconsistency
      between the LR state and the physical distributor state where the LR
      state was active and the physical distributor was not active, which
      shouldn't happen.
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      0e3dfda9
  11. 24 11月, 2015 5 次提交
    • P
      gpu: ipu-v3: drop unused dmfc field from client platform data · c3ede03c
      Philipp Zabel 提交于
      This field is never used, drop it.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      c3ede03c
    • J
      nfs: use sliding delay when LAYOUTGET gets NFS4ERR_DELAY · 91ab4b4d
      Jeff Layton 提交于
      When LAYOUTGET gets NFS4ERR_DELAY, we currently will wait 15s before
      retrying the call. That is a _very_ long time, so add a timeout value to
      struct nfs4_layoutget and pass nfs4_async_handle_error a pointer to it.
      This allows the RPC engine to use a sliding delay window, instead of a
      15s delay.
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      91ab4b4d
    • C
      nfs: use btrfs ioctl defintions for clone · 0f42a6a9
      Christoph Hellwig 提交于
      The NFS CLONE_RANGE defintion was wrong and thus never worked.  Fix this
      by simply using the btrfs ioctl defintion.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      0f42a6a9
    • A
      thermal: fix thermal_zone_bind_cooling_device prototype · c86b3de8
      Arnd Bergmann 提交于
      When the prototype for thermal_zone_bind_cooling_device
      changed, the static inline wrapper function was left alone,
      which in theory can cause build warnings:
      
      I have seen this error in the past:
      drivers/thermal/db8500_thermal.c: In function 'db8500_cdev_bind':
      drivers/thermal/db8500_thermal.c:78:9: error: too many arguments to function 'thermal_zone_bind_cooling_device'
         ret = thermal_zone_bind_cooling_device(thermal, i, cdev,
      
      while this one no longer shows up, there is no doubt that
      the prototype is still wrong, so let's just fix it anyway.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 6cd9e9f6 ("thermal: of: fix cooling device weights in device tree")
      Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      c86b3de8
    • R
      unix: avoid use-after-free in ep_remove_wait_queue · 7d267278
      Rainer Weikusat 提交于
      Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
      An AF_UNIX datagram socket being the client in an n:1 association with
      some server socket is only allowed to send messages to the server if the
      receive queue of this socket contains at most sk_max_ack_backlog
      datagrams. This implies that prospective writers might be forced to go
      to sleep despite none of the message presently enqueued on the server
      receive queue were sent by them. In order to ensure that these will be
      woken up once space becomes again available, the present unix_dgram_poll
      routine does a second sock_poll_wait call with the peer_wait wait queue
      of the server socket as queue argument (unix_dgram_recvmsg does a wake
      up on this queue after a datagram was received). This is inherently
      problematic because the server socket is only guaranteed to remain alive
      for as long as the client still holds a reference to it. In case the
      connection is dissolved via connect or by the dead peer detection logic
      in unix_dgram_sendmsg, the server socket may be freed despite "the
      polling mechanism" (in particular, epoll) still has a pointer to the
      corresponding peer_wait queue. There's no way to forcibly deregister a
      wait queue with epoll.
      
      Based on an idea by Jason Baron, the patch below changes the code such
      that a wait_queue_t belonging to the client socket is enqueued on the
      peer_wait queue of the server whenever the peer receive queue full
      condition is detected by either a sendmsg or a poll. A wake up on the
      peer queue is then relayed to the ordinary wait queue of the client
      socket via wake function. The connection to the peer wait queue is again
      dissolved if either a wake up is about to be relayed or the client
      socket reconnects or a dead peer is detected or the client socket is
      itself closed. This enables removing the second sock_poll_wait from
      unix_dgram_poll, thus avoiding the use-after-free, while still ensuring
      that no blocked writer sleeps forever.
      Signed-off-by: NRainer Weikusat <rweikusat@mobileactivedefense.com>
      Fixes: ec0d215f ("af_unix: fix 'poll for write'/connected DGRAM sockets")
      Reviewed-by: NJason Baron <jbaron@akamai.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d267278
  12. 23 11月, 2015 1 次提交
    • J
      slab/slub: adjust kmem_cache_alloc_bulk API · 865762a8
      Jesper Dangaard Brouer 提交于
      Adjust kmem_cache_alloc_bulk API before we have any real users.
      
      Adjust API to return type 'int' instead of previously type 'bool'.  This
      is done to allow future extension of the bulk alloc API.
      
      A future extension could be to allow SLUB to stop at a page boundary, when
      specified by a flag, and then return the number of objects.
      
      The advantage of this approach, would make it easier to make bulk alloc
      run without local IRQs disabled.  With an approach of cmpxchg "stealing"
      the entire c->freelist or page->freelist.  To avoid overshooting we would
      stop processing at a slab-page boundary.  Else we always end up returning
      some objects at the cost of another cmpxchg.
      
      To keep compatible with future users of this API linking against an older
      kernel when using the new flag, we need to return the number of allocated
      objects with this API change.
      Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Cc: Vladimir Davydov <vdavydov@virtuozzo.com>
      Acked-by: NChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      865762a8
  13. 21 11月, 2015 5 次提交
    • P
      tty: audit: Fix audit source · 6b2a3d62
      Peter Hurley 提交于
      The data to audit/record is in the 'from' buffer (ie., the input
      read buffer).
      
      Fixes: 72586c60 ("n_tty: Fix auditing support for cannonical mode")
      Cc: stable <stable@vger.kernel.org> # 4.1+
      Cc: Miloslav Trmač <mitr@redhat.com>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Acked-by: NLaura Abbott <labbott@fedoraproject.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b2a3d62
    • J
      mm: fix up sparse warning in gfpflags_allow_blocking · 21fa8442
      Jeff Layton 提交于
      sparse says:
      
          include/linux/gfp.h:274:26: warning: incorrect type in return expression (different base types)
          include/linux/gfp.h:274:26:    expected bool
          include/linux/gfp.h:274:26:    got restricted gfp_t
      
      ...add a forced cast to silence the warning.
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      21fa8442
    • R
      kernel/signal.c: unexport sigsuspend() · 9d8a7652
      Richard Weinberger 提交于
      sigsuspend() is nowhere used except in signal.c itself, so we can mark it
      static do not pollute the global namespace.
      
      But this patch is more than a boring cleanup patch, it fixes a real issue
      on UserModeLinux.  UML has a special console driver to display ttys using
      xterm, or other terminal emulators, on the host side.  Vegard reported
      that sometimes UML is unable to spawn a xterm and he's facing the
      following warning:
      
        WARNING: CPU: 0 PID: 908 at include/linux/thread_info.h:128 sigsuspend+0xab/0xc0()
      
      It turned out that this warning makes absolutely no sense as the UML
      xterm code calls sigsuspend() on the host side, at least it tries.  But
      as the kernel itself offers a sigsuspend() symbol the linker choose this
      one instead of the glibc wrapper.  Interestingly this code used to work
      since ever but always blocked signals on the wrong side.  Some recent
      kernel change made the WARN_ON() trigger and uncovered the bug.
      
      It is a wonderful example of how much works by chance on computers. :-)
      
      Fixes: 68f3f16d ("new helper: sigsuspend()")
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      Reported-by: NVegard Nossum <vegard.nossum@oracle.com>
      Tested-by: NVegard Nossum <vegard.nossum@oracle.com>
      Acked-by: NOleg Nesterov <oleg@redhat.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>
      9d8a7652
    • D
      configfs: allow dynamic group creation · 5cf6a51e
      Daniel Baluta 提交于
      This patchset introduces IIO software triggers, offers a way of configuring
      them via configfs and adds the IIO hrtimer based interrupt source to be used
      with software triggers.
      
      The architecture is now split in 3 parts, to remove all IIO trigger specific
      parts from IIO configfs core:
      
      (1) IIO configfs - creates the root of the IIO configfs subsys.
      (2) IIO software triggers - software trigger implementation, dynamically
          creating /config/iio/triggers group.
      (3) IIO hrtimer trigger - is the first interrupt source for software triggers
          (with syfs to follow). Each trigger type can implement its own set of
          attributes.
      
      Lockdep seems to be happy with the locking in configfs patch.
      
      This patch (of 5):
      
      We don't want to hardcode default groups at subsystem
      creation time. We export:
      	* configfs_register_group
      	* configfs_unregister_group
      to allow drivers to programatically create/destroy groups
      later, after module init time.
      
      This is needed for IIO configfs support.
      
      (akpm: the other 4 patches to be merged via the IIO tree)
      Signed-off-by: NDaniel Baluta <daniel.baluta@intel.com>
      Suggested-by: NLars-Peter Clausen <lars@metafoo.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NJoel Becker <jlbec@evilplan.org>
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Octavian Purdila <octavian.purdila@intel.com>
      Cc: Paul Bolle <pebolle@tiscali.nl>
      Cc: Adriana Reus <adriana.reus@intel.com>
      Cc: Cristina Opriceana <cristina.opriceana@gmail.com>
      Cc: Peter Meerwald <pmeerw@pmeerw.net>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5cf6a51e
    • R
      slab.h: sprinkle __assume_aligned attributes · 94a58c36
      Rasmus Villemoes 提交于
      The various allocators return aligned memory.  Telling the compiler that
      allows it to generate better code in many cases, for example when the
      return value is immediately passed to memset().
      
      Some code does become larger, but at least we win twice as much as we lose:
      
      $ scripts/bloat-o-meter /tmp/vmlinux vmlinux
      add/remove: 0/0 grow/shrink: 13/52 up/down: 995/-2140 (-1145)
      
      An example of the different (and smaller) code can be seen in mm_alloc(). Before:
      
      :       48 8d 78 08             lea    0x8(%rax),%rdi
      :       48 89 c1                mov    %rax,%rcx
      :       48 89 c2                mov    %rax,%rdx
      :       48 c7 00 00 00 00 00    movq   $0x0,(%rax)
      :       48 c7 80 48 03 00 00    movq   $0x0,0x348(%rax)
      :       00 00 00 00
      :       31 c0                   xor    %eax,%eax
      :       48 83 e7 f8             and    $0xfffffffffffffff8,%rdi
      :       48 29 f9                sub    %rdi,%rcx
      :       81 c1 50 03 00 00       add    $0x350,%ecx
      :       c1 e9 03                shr    $0x3,%ecx
      :       f3 48 ab                rep stos %rax,%es:(%rdi)
      
      After:
      
      :       48 89 c2                mov    %rax,%rdx
      :       b9 6a 00 00 00          mov    $0x6a,%ecx
      :       31 c0                   xor    %eax,%eax
      :       48 89 d7                mov    %rdx,%rdi
      :       f3 48 ab                rep stos %rax,%es:(%rdi)
      
      So gcc's strategy is to do two possibly (but not really, of course)
      unaligned stores to the first and last word, then do an aligned rep stos
      covering the middle part with a little overlap.  Maybe arches which do not
      allow unaligned stores gain even more.
      
      I don't know if gcc can actually make use of alignments greater than 8 for
      anything, so one could probably drop the __assume_xyz_alignment macros and
      just use __assume_aligned(8).
      
      The increases in code size are mostly caused by gcc deciding to
      opencode strlen() using the check-four-bytes-at-a-time trick when it
      knows the buffer is sufficiently aligned (one function grew by 200
      bytes). Now it turns out that many of these strlen() calls showing up
      were in fact redundant, and they're gone from -next. Applying the two
      patches to next-20151001 bloat-o-meter instead says
      
      add/remove: 0/0 grow/shrink: 6/52 up/down: 244/-2140 (-1896)
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Acked-by: NChristoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      94a58c36
  14. 20 11月, 2015 3 次提交