1. 08 12月, 2015 8 次提交
  2. 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
  3. 03 12月, 2015 5 次提交
  4. 02 12月, 2015 4 次提交
  5. 01 12月, 2015 1 次提交
    • V
      drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz clock difference · 4c6bcf44
      Ville Syrjälä 提交于
      Rather than using drm_match_cea_mode() to see if the EDID detailed
      timings are supposed to represent one of the CEA/HDMI modes, add a
      special version of that function that takes in an explicit clock
      tolerance value (in kHz). When looking at the detailed timings specify
      the tolerance as 5kHz due to the 10kHz clock resolution limit inherent
      in detailed timings.
      
      drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks,
      which only allows smaller errors for lower clocks (eg. for 25200 it
      won't allow any error) and a bigger error for higher clocks (eg. for
      297000 it actually matches 296913-297000). So it doesn't really match
      what we want for the fixup. Using the explicit +-5kHz is much better
      for this use case.
      
      Not sure if we should change the normal mode matching to also use
      something else besides KHZ2PICOS() since it allows a different
      proportion of error depending on the clock. I believe VESA CVT
      allows a maximum deviation of .5%, so using that for normal mode
      matching might be a good idea?
      
      Cc: Adam Jackson <ajax@redhat.com>
      Tested-by: nathan.d.ciobanu@linux.intel.com
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217
      Fixes: fa3a7340 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NAdam Jackson <ajax@redhat.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4c6bcf44
  6. 30 11月, 2015 4 次提交
  7. 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
  8. 26 11月, 2015 4 次提交
    • C
      drm: Serialise multiple event readers · 9b2c0b7f
      Chris Wilson 提交于
      The previous patch reintroduced a race condition whereby a failure in
      one reader may allow a second reader to see out-of-order events.
      Introduce a mutex to serialise readers so that an event is completed in
      its entirety before another reader may process an event. The two readers
      may race against each other, but the events each retrieves are in the
      correct order.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1448462343-2072-2-git-send-email-chris@chris-wilson.co.ukReviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9b2c0b7f
    • 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
  9. 25 11月, 2015 5 次提交
    • 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
    • G
      drm/mm: use list_next_entry · 87069f44
      Geliang Tang 提交于
      To make the intention clearer, use list_next_entry instead of list_entry.
      Signed-off-by: NGeliang Tang <geliangtang@163.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      87069f44
    • J
      drm: fix potential dangling else problems in for_each_ macros · 373701b1
      Jani Nikula 提交于
      We have serious dangling else bugs waiting to happen in our for_each_
      style macros with ifs. Consider, for example,
      
       #define drm_for_each_plane_mask(plane, dev, plane_mask) \
               list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
                       if ((plane_mask) & (1 << drm_plane_index(plane)))
      
      If this is used in context:
      
      	if (condition)
      		drm_for_each_plane_mask(plane, dev, plane_mask);
      	else
      		foo();
      
      foo() will be called for each plane *not* in plane_mask, if condition
      holds, and not at all if condition doesn't hold.
      
      Fix this by reversing the conditions in the macros, and adding an else
      branch for the "for each" block, so that other if/else blocks can't
      interfere. Provide a "for_each_if" helper macro to make it easier to get
      this right.
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1448392916-2281-1-git-send-email-jani.nikula@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      373701b1
    • 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
  10. 24 11月, 2015 3 次提交
新手
引导
客服 返回
顶部