origin

GIT 926af6273fc683cd98cd0ce7bf0d04a02eed6742

commit b6789123bccba8b5feb9901ed2e8c3c39181979d
Author: Hugh Dickins <[email protected]>
Date:   Tue Feb 7 11:11:16 2017 -0800

    mm: fix KPF_SWAPCACHE in /proc/kpageflags
    
    Commit 6326fec1122c ("mm: Use owner_priv bit for PageSwapCache, valid
    when PageSwapBacked") aliased PG_swapcache to PG_owner_priv_1 (and
    depending on PageSwapBacked being true).
    
    As a result, the KPF_SWAPCACHE bit in '/proc/kpageflags' should now be
    synthesized, instead of being shown on unrelated pages which just happen
    to have PG_owner_priv_1 set.
    
    Signed-off-by: Hugh Dickins <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Cc: Nicholas Piggin <[email protected]>
    Cc: Wu Fengguang <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>

commit 912964eacb111551db73429719eb5fadcab0ff8a
Author: Xin Long <[email protected]>
Date:   Tue Feb 7 20:56:08 2017 +0800

    sctp: check af before verify address in sctp_addr_id2transport
    
    Commit 6f29a1306131 ("sctp: sctp_addr_id2transport should verify the
    addr before looking up assoc") invoked sctp_verify_addr to verify the
    addr.
    
    But it didn't check af variable beforehand, once users pass an address
    with family = 0 through sockopt, sctp_get_af_specific will return NULL
    and NULL pointer dereference will be caused by af->sockaddr_len.
    
    This patch is to fix it by returning NULL if af variable is NULL.
    
    Fixes: 6f29a1306131 ("sctp: sctp_addr_id2transport should verify the addr before looking up assoc")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a524c218bc94c705886a0e0fedeee45d1931da32
Author: Vineet Gupta <[email protected]>
Date:   Tue Feb 7 09:44:58 2017 -0800

    ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup
    
    Reported-by: Jo-Philipp Wich <[email protected]>
    Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Vineet Gupta <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>

commit 2dcab598484185dea7ec22219c76dcdd59e3cb90
Author: Marcelo Ricardo Leitner <[email protected]>
Date:   Mon Feb 6 18:10:31 2017 -0200

    sctp: avoid BUG_ON on sctp_wait_for_sndbuf
    
    Alexander Popov reported that an application may trigger a BUG_ON in
    sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
    waiting on it to queue more data and meanwhile another thread peels off
    the association being used by the first thread.
    
    This patch replaces the BUG_ON call with a proper error handling. It
    will return -EPIPE to the original sendmsg call, similarly to what would
    have been done if the association wasn't found in the first place.
    
    Acked-by: Alexander Popov <[email protected]>
    Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
    Reviewed-by: Xin Long <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit bd4ce941c8d5b862b2f83364be5dbe8fc8ab48f8
Author: Benjamin Poirier <[email protected]>
Date:   Mon Feb 6 10:14:31 2017 -0800

    mlx4: Invoke softirqs after napi_reschedule
    
    mlx4 may schedule napi from a workqueue. Afterwards, softirqs are not run
    in a deterministic time frame and the following message may be logged:
    NOHZ: local_softirq_pending 08
    
    The problem is the same as what was described in commit ec13ee80145c
    ("virtio_net: invoke softirqs after __napi_schedule") and this patch
    applies the same fix to mlx4.
    
    Fixes: 07841f9d94c1 ("net/mlx4_en: Schedule napi when RX buffers allocation fails")
    Cc: Eric Dumazet <[email protected]>
    Signed-off-by: Benjamin Poirier <[email protected]>
    Acked-by: Eric Dumazet <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 69629464e0b587f3711739b3aa2bcdaf2e075276
Author: Eric Dumazet <[email protected]>
Date:   Sun Feb 5 09:25:24 2017 -0800

    udp: properly cope with csum errors
    
    Dmitry reported that UDP sockets being destroyed would trigger the
    WARN_ON(atomic_read(&sk->sk_rmem_alloc)); in inet_sock_destruct()
    
    It turns out we do not properly destroy skb(s) that have wrong UDP
    checksum.
    
    Thanks again to syzkaller team.
    
    Fixes : 7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")
    Reported-by: Dmitry Vyukov <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Paolo Abeni <[email protected]>
    Cc: Hannes Frederic Sowa <[email protected]>
    Acked-by: Paolo Abeni <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 2d6a0e9de03ee658a9adc3bfb2f0ca55dff1e478
Author: Ben Hutchings <[email protected]>
Date:   Sat Feb 4 16:57:04 2017 +0000

    catc: Use heap buffer for memory size test
    
    Allocating USB buffers on the stack is not portable, and no longer
    works on x86_64 (with VMAP_STACK enabled as per default).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ben Hutchings <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d41149145f98fe26dcd0bfd1d6cc095e6e041418
Author: Ben Hutchings <[email protected]>
Date:   Sat Feb 4 16:56:56 2017 +0000

    catc: Combine failure cleanup code in catc_probe()
    
    Signed-off-by: Ben Hutchings <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 7926aff5c57b577ab0f43364ff0c59d968f6a414
Author: Ben Hutchings <[email protected]>
Date:   Sat Feb 4 16:56:32 2017 +0000

    rtl8150: Use heap buffers for all register access
    
    Allocating USB buffers on the stack is not portable, and no longer
    works on x86_64 (with VMAP_STACK enabled as per default).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ben Hutchings <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 5593523f968bc86d42a035c6df47d5e0979b5ace
Author: Ben Hutchings <[email protected]>
Date:   Sat Feb 4 16:56:03 2017 +0000

    pegasus: Use heap buffers for all register access
    
    Allocating USB buffers on the stack is not portable, and no longer
    works on x86_64 (with VMAP_STACK enabled as per default).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    References: https://bugs.debian.org/852556
    Reported-by: Lisandro Damián Nicanor Pérez Meyer <[email protected]>
    Tested-by: Lisandro Damián Nicanor Pérez Meyer <[email protected]>
    Signed-off-by: Ben Hutchings <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 837585a5375c38d40361cfe64e6fd11e1addb936
Author: Willem de Bruijn <[email protected]>
Date:   Fri Feb 3 18:20:49 2017 -0500

    macvtap: read vnet_hdr_size once
    
    When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
    Data length is verified to be greater than or equal to expected header
    length tun->vnet_hdr_sz before copying.
    
    Macvtap functions read the value once, but unless READ_ONCE is used,
    the compiler may ignore this and read multiple times. Enforce a single
    read and locally cached value to avoid updates between test and use.
    
    Signed-off-by: Willem de Bruijn <[email protected]>
    Suggested-by: Eric Dumazet <[email protected]>
    Acked-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit e1edab87faf6ca30cd137e0795bc73aa9a9a22ec
Author: Willem de Bruijn <[email protected]>
Date:   Fri Feb 3 18:20:48 2017 -0500

    tun: read vnet_hdr_sz once
    
    When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
    Data length is verified to be greater than or equal to expected header
    length tun->vnet_hdr_sz before copying.
    
    Read this value once and cache locally, as it can be updated between
    the test and use (TOCTOU).
    
    Signed-off-by: Willem de Bruijn <[email protected]>
    Reported-by: Dmitry Vyukov <[email protected]>
    CC: Eric Dumazet <[email protected]>
    Acked-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82
Author: Eric Dumazet <[email protected]>
Date:   Fri Feb 3 14:59:38 2017 -0800

    tcp: avoid infinite loop in tcp_splice_read()
    
    Splicing from TCP socket is vulnerable when a packet with URG flag is
    received and stored into receive queue.
    
    __tcp_splice_read() returns 0, and sk_wait_data() immediately
    returns since there is the problematic skb in queue.
    
    This is a nice way to burn cpu (aka infinite loop) and trigger
    soft lockups.
    
    Again, this gem was found by syzkaller tool.
    
    Fixes: 9c55e01c0cc8 ("[TCP]: Splice receive support.")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Dmitry Vyukov  <[email protected]>
    Cc: Willy Tarreau <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit b3f2d07f4649adcf6905953a10d217b5683e4077
Author: Arnd Bergmann <[email protected]>
Date:   Fri Feb 3 17:35:46 2017 +0100

    hns: avoid stack overflow with CONFIG_KASAN
    
    The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use
    an indexed load for the register address, but it has an absolutely detrimental
    effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely
    kernel stack overflow aside from very complex object code:
    
    hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats':
    hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common':
    hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs':
    hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs':
    hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs':
    hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs':
    hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init':
    hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs':
    hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats':
    hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs':
    hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    
    This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE
    seems safe anyway and it avoids a serious issue for some people. I have verified
    that with gcc-5.3.1, the object code we get is better in the new version
    both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte
    stack frame for hns_dsaf_get_regs() but otherwise have practically identical
    object code.
    
    With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already
    good either way.
    
    This patch is probably not urgent to get into 4.11 as only KASAN=y builds
    with certain compilers are affected, but I still think it makes sense to
    backport into older kernels.
    
    Cc: [email protected]
    Fixes: 511e6bc ("net: add Hisilicon Network Subsystem DSAF support")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a088d1d73a4bcfd7bc482f8d08375b9b665dc3e5
Author: Linus Lüssing <[email protected]>
Date:   Fri Feb 3 08:11:03 2017 +0100

    ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches
    
    When for instance a mobile Linux device roams from one access point to
    another with both APs sharing the same broadcast domain and a
    multicast snooping switch in between:
    
    1)    (c) <~~~> (AP1) <--[SSW]--> (AP2)
    
    2)              (AP1) <--[SSW]--> (AP2) <~~~> (c)
    
    Then currently IPv6 multicast packets will get lost for (c) until an
    MLD Querier sends its next query message. The packet loss occurs
    because upon roaming the Linux host so far stayed silent regarding
    MLD and the snooping switch will therefore be unaware of the
    multicast topology change for a while.
    
    This patch fixes this by always resending MLD reports when an interface
    change happens, for instance from NO-CARRIER to CARRIER state.
    
    Signed-off-by: Linus Lüssing <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit ebf6c9cb23d7e56eec8575a88071dec97ad5c6e2
Author: Eric Dumazet <[email protected]>
Date:   Sun Feb 5 20:23:22 2017 -0800

    ipv6: tcp: add a missing tcp_v6_restore_cb()
    
    Dmitry reported use-after-free in ip6_datagram_recv_specific_ctl()
    
    A similar bug was fixed in commit 8ce48623f0cf ("ipv6: tcp: restore
    IP6CB for pktoptions skbs"), but I missed another spot.
    
    tcp_v6_syn_recv_sock() can indeed set np->pktoptions from ireq->pktopts
    
    Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Dmitry Vyukov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit fd551bac4795854adaa87bad7e5136083719802b
Author: Masashi Honma <[email protected]>
Date:   Thu Jan 26 08:56:13 2017 +0900

    nl80211: Fix mesh HT operation check
    
    A previous change to fix checks for NL80211_MESHCONF_HT_OPMODE
    missed setting the flag when replacing FILL_IN_MESH_PARAM_IF_SET
    with checking codes. This results in dropping the received HT
    operation value when called by nl80211_update_mesh_config(). Fix
    this by setting the flag properly.
    
    Fixes: 9757235f451c ("nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value")
    Signed-off-by: Masashi Honma <[email protected]>
    [rewrite commit message to use Fixes: line]
    Signed-off-by: Johannes Berg <[email protected]>

commit da7061c82e4a1bc6a5e134ef362c86261906c860
Author: Thorsten Horstmann <[email protected]>
Date:   Fri Feb 3 14:38:29 2017 +0100

    mac80211: Fix adding of mesh vendor IEs
    
    The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
    it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
    return value in mesh_add_vendor_ies must therefore be checked against
    ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
    WLAN_EID_VENDOR_SPECIFIC will be rejected.
    
    Fixes: 082ebb0c258d ("mac80211: fix mesh beacon format")
    Signed-off-by: Thorsten Horstmann <[email protected]>
    Signed-off-by: Mathias Kretschmer <[email protected]>
    Signed-off-by: Simon Wunderlich <[email protected]>
    [[email protected]: Add commit message]
    Signed-off-by: Sven Eckelmann <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>

commit 01fba20b5976e445676febbdf6dc78d71c6d7b62
Author: Jouni Malinen <[email protected]>
Date:   Sat Feb 4 18:08:42 2017 +0200

    mac80211: Allocate a sync skcipher explicitly for FILS AEAD
    
    The skcipher could have been of the async variant which may return from
    skcipher_encrypt() with -EINPROGRESS after having queued the request.
    The FILS AEAD implementation here does not have code for dealing with
    that possibility, so allocate a sync cipher explicitly to avoid
    potential issues with hardware accelerators.
    
    This is based on the patch sent out by Ard.
    
    Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
    Reported-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Jouni Malinen <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>

commit e479ab651f071dbd1518ce8fb121c7f42f2bb97d
Author: Jouni Malinen <[email protected]>
Date:   Sat Feb 4 13:59:22 2017 +0200

    mac80211: Fix FILS AEAD protection in Association Request frame
    
    Incorrect num_elem parameter value (1 vs. 5) was used in the
    aes_siv_encrypt() call. This resulted in only the first one of the five
    AAD vectors to SIV getting included in calculation. This does not
    protect all the contents correctly and would not interoperate with a
    standard compliant implementation.
    
    Fix this by using the correct number. A matching fix is needed in the AP
    side (hostapd) to get FILS authentication working properly.
    
    Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
    Reported-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Jouni Malinen <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>

commit 7892032cfe67f4bde6fc2ee967e45a8fbaf33756
Author: Eric Dumazet <[email protected]>
Date:   Sat Feb 4 23:18:55 2017 -0800

    ip6_gre: fix ip6gre_err() invalid reads
    
    Andrey Konovalov reported out of bound accesses in ip6gre_err()
    
    If GRE flags contains GRE_KEY, the following expression
    *(((__be32 *)p) + (grehlen / 4) - 1)
    
    accesses data ~40 bytes after the expected point, since
    grehlen includes the size of IPv6 headers.
    
    Let's use a "struct gre_base_hdr *greh" pointer to make this
    code more readable.
    
    p[1] becomes greh->protocol.
    grhlen is the GRE header length.
    
    Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Andrey Konovalov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d71b7896886345c53ef1d84bda2bc758554f5d61
Author: Eric Dumazet <[email protected]>
Date:   Fri Feb 3 00:03:26 2017 -0800

    netlabel: out of bound access in cipso_v4_validate()
    
    syzkaller found another out of bound access in ip_options_compile(),
    or more exactly in cipso_v4_validate()
    
    Fixes: 20e2a8648596 ("cipso: handle CIPSO options correctly when NetLabel is disabled")
    Fixes: 446fda4f2682 ("[NetLabel]: CIPSOv4 engine")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Dmitry Vyukov  <[email protected]>
    Cc: Paul Moore <[email protected]>
    Acked-by: Paul Moore <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 34b2cef20f19c87999fff3da4071e66937db9644
Author: Eric Dumazet <[email protected]>
Date:   Sat Feb 4 11:16:52 2017 -0800

    ipv4: keep skb->dst around in presence of IP options
    
    Andrey Konovalov got crashes in __ip_options_echo() when a NULL skb->dst
    is accessed.
    
    ipv4_pktinfo_prepare() should not drop the dst if (evil) IP options
    are present.
    
    We could refine the test to the presence of ts_needtime or srr,
    but IP options are not often used, so let's be conservative.
    
    Thanks to syzkaller team for finding this bug.
    
    Fixes: d826eb14ecef ("ipv4: PKTINFO doesnt need dst reference")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Andrey Konovalov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit bfb34527a32a1a576d9bfb7026d3ab0369a6cd60
Author: Dan Williams <[email protected]>
Date:   Sat Feb 4 14:47:31 2017 -0800

    libnvdimm, pfn: fix memmap reservation size versus 4K alignment
    
    When vmemmap_populate() allocates space for the memmap it does so in 2MB
    sized chunks. The libnvdimm-pfn driver incorrectly accounts for this
    when the alignment of the device is set to 4K. When this happens we
    trigger memory allocation failures in altmap_alloc_block_buf() and
    trigger warnings of the form:
    
     WARNING: CPU: 0 PID: 3376 at arch/x86/mm/init_64.c:656 arch_add_memory+0xe4/0xf0
     [..]
     Call Trace:
      dump_stack+0x86/0xc3
      __warn+0xcb/0xf0
      warn_slowpath_null+0x1d/0x20
      arch_add_memory+0xe4/0xf0
      devm_memremap_pages+0x29b/0x4e0
    
    Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute, default to HPAGE_SIZE")
    Cc: <[email protected]>
    Signed-off-by: Dan Williams <[email protected]>

commit a9306a63631493afc75893a4ac405d4e1cbae6aa
Author: Rafael J. Wysocki <[email protected]>
Date:   Sat Feb 4 00:44:36 2017 +0100

    PM / runtime: Avoid false-positive warnings from might_sleep_if()
    
    The might_sleep_if() assertions in __pm_runtime_idle(),
    __pm_runtime_suspend() and __pm_runtime_resume() may generate
    false-positive warnings in some situations.  For example, that
    happens if a nested pm_runtime_get_sync()/pm_runtime_put() pair
    is executed with disabled interrupts within an outer
    pm_runtime_get_sync()/pm_runtime_put() section for the same device.
    [Generally, pm_runtime_get_sync() may sleep, so it should not be
    called with disabled interrupts, but in this particular case the
    previous pm_runtime_get_sync() guarantees that the device will not
    be suspended, so the inner pm_runtime_get_sync() will return
    immediately after incrementing the device's usage counter.]
    
    That started to happen in the i915 driver in 4.10-rc, leading to
    the following splat:
    
     BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032
     in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
     1 lock held by Xorg/1500:
      #0:  (&dev->struct_mutex){+.+.+.}, at:
      [<ffffffffa0680c13>] i915_mutex_lock_interruptible+0x43/0x140 [i915]
     CPU: 0 PID: 1500 Comm: Xorg Not tainted
     Call Trace:
      dump_stack+0x85/0xc2
      ___might_sleep+0x196/0x260
      __might_sleep+0x53/0xb0
      __pm_runtime_resume+0x7a/0x90
      intel_runtime_pm_get+0x25/0x90 [i915]
      aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
      i915_vma_bind+0xaf/0x1e0 [i915]
      i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
      i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
      ? trace_hardirqs_on+0xd/0x10
      ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
      ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
      i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
      ? __might_fault+0x4e/0xb0
      i915_gem_execbuffer2+0xc5/0x260 [i915]
      ? __might_fault+0x4e/0xb0
      drm_ioctl+0x206/0x450 [drm]
      ? i915_gem_execbuffer+0x340/0x340 [i915]
      ? __fget+0x5/0x200
      do_vfs_ioctl+0x91/0x6f0
      ? __fget+0x111/0x200
      ? __fget+0x5/0x200
      SyS_ioctl+0x79/0x90
      entry_SYSCALL_64_fastpath+0x23/0xc6
    
    even though the code triggering it is correct.
    
    Unfortunately, the might_sleep_if() assertions in question are
    too coarse-grained to cover such cases correctly, so make them
    a bit less sensitive in order to avoid the false-positives.
    
    Reported-and-tested-by: Sedat Dilek <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 6e978b22efa1db9f6e71b24440b5f1d93e968ee3
Author: Srinivas Pandruvada <[email protected]>
Date:   Fri Feb 3 14:18:39 2017 -0800

    cpufreq: intel_pstate: Disable energy efficiency optimization
    
    Some Kabylake desktop processors may not reach max turbo when running in
    HWP mode, even if running under sustained 100% utilization.
    
    This occurs when the HWP.EPP (Energy Performance Preference) is set to
    "balance_power" (0x80) -- the default on most systems.
    
    It occurs because the platform BIOS may erroneously enable an
    energy-efficiency setting -- MSR_IA32_POWER_CTL BIT-EE, which is not
    recommended to be enabled on this SKU.
    
    On the failing systems, this BIOS issue was not discovered when the
    desktop motherboard was tested with Windows, because the BIOS also
    neglects to provide the ACPI/CPPC table, that Windows requires to enable
    HWP, and so Windows runs in legacy P-state mode, where this setting has
    no effect.
    
    Linux' intel_pstate driver does not require ACPI/CPPC to enable HWP, and
    so it runs in HWP mode, exposing this incorrect BIOS configuration.
    
    There are several ways to address this problem.
    
    First, Linux can also run in legacy P-state mode on this system.
    As intel_pstate is how Linux enables HWP, booting with
    "intel_pstate=disable"
    will run in acpi-cpufreq/ondemand legacy p-state mode.
    
    Or second, the "performance" governor can be used with intel_pstate,
    which will modify HWP.EPP to 0.
    
    Or third, starting in 4.10, the
    /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference
    attribute in can be updated from "balance_power" to "performance".
    
    Or fourth, apply this patch, which fixes the erroneous setting of
    MSR_IA32_POWER_CTL BIT_EE on this model, allowing the default
    configuration to function as designed.
    
    Signed-off-by: Srinivas Pandruvada <[email protected]>
    Reviewed-by: Len Brown <[email protected]>
    Cc: 4.6+ <[email protected]> # 4.6+
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 5fa8bbda38c668e56b0c6cdecced2eac2fe36dec
Author: Eric Dumazet <[email protected]>
Date:   Thu Feb 2 10:31:35 2017 -0800

    net: use a work queue to defer net_disable_timestamp() work
    
    Dmitry reported a warning [1] showing that we were calling
    net_disable_timestamp() -> static_key_slow_dec() from a non
    process context.
    
    Grabbing a mutex while holding a spinlock or rcu_read_lock()
    is not allowed.
    
    As Cong suggested, we now use a work queue.
    
    It is possible netstamp_clear() exits while netstamp_needed_deferred
    is not zero, but it is probably not worth trying to do better than that.
    
    netstamp_needed_deferred atomic tracks the exact number of deferred
    decrements.
    
    [1]
    [ INFO: suspicious RCU usage. ]
    4.10.0-rc5+ #192 Not tainted
    -------------------------------
    ./include/linux/rcupdate.h:561 Illegal context switch in RCU read-side
    critical section!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 0
    2 locks held by syz-executor14/23111:
     #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>] lock_sock
    include/net/sock.h:1454 [inline]
     #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>]
    rawv6_sendmsg+0x1e65/0x3ec0 net/ipv6/raw.c:919
     #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>] nf_hook
    include/linux/netfilter.h:201 [inline]
     #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>]
    __ip6_local_out+0x258/0x840 net/ipv6/output_core.c:160
    
    stack backtrace:
    CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
    01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:15 [inline]
     dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
     lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4452
     rcu_preempt_sleep_check include/linux/rcupdate.h:560 [inline]
     ___might_sleep+0x560/0x650 kernel/sched/core.c:7748
     __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
     mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
     atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
     __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
     static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
     net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
     sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
     __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
     sk_destruct+0x47/0x80 net/core/sock.c:1460
     __sk_free+0x57/0x230 net/core/sock.c:1468
     sock_wfree+0xae/0x120 net/core/sock.c:1645
     skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
     skb_release_all+0x15/0x60 net/core/skbuff.c:668
     __kfree_skb+0x15/0x20 net/core/skbuff.c:684
     kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
     inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
     inet_frag_put include/net/inet_frag.h:133 [inline]
     nf_ct_frag6_gather+0x1106/0x3840
    net/ipv6/netfilter/nf_conntrack_reasm.c:617
     ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
     nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
     nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
     nf_hook include/linux/netfilter.h:212 [inline]
     __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
     ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
     ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
     ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
     rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
     rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
     inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
     sock_sendmsg_nosec net/socket.c:635 [inline]
     sock_sendmsg+0xca/0x110 net/socket.c:645
     sock_write_iter+0x326/0x600 net/socket.c:848
     do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
     do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
     vfs_writev+0x87/0xc0 fs/read_write.c:911
     do_writev+0x110/0x2c0 fs/read_write.c:944
     SYSC_writev fs/read_write.c:1017 [inline]
     SyS_writev+0x27/0x30 fs/read_write.c:1014
     entry_SYSCALL_64_fastpath+0x1f/0xc2
    RIP: 0033:0x445559
    RSP: 002b:00007f6f46fceb58 EFLAGS: 00000292 ORIG_RAX: 0000000000000014
    RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000445559
    RDX: 0000000000000001 RSI: 0000000020f1eff0 RDI: 0000000000000005
    RBP: 00000000006e19c0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000700000
    R13: 0000000020f59000 R14: 0000000000000015 R15: 0000000000020400
    BUG: sleeping function called from invalid context at
    kernel/locking/mutex.c:752
    in_atomic(): 1, irqs_disabled(): 0, pid: 23111, name: syz-executor14
    INFO: lockdep is turned off.
    CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
    01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:15 [inline]
     dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
     ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780
     __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
     mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
     atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
     __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
     static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
     net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
     sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
     __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
     sk_destruct+0x47/0x80 net/core/sock.c:1460
     __sk_free+0x57/0x230 net/core/sock.c:1468
     sock_wfree+0xae/0x120 net/core/sock.c:1645
     skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
     skb_release_all+0x15/0x60 net/core/skbuff.c:668
     __kfree_skb+0x15/0x20 net/core/skbuff.c:684
     kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
     inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
     inet_frag_put include/net/inet_frag.h:133 [inline]
     nf_ct_frag6_gather+0x1106/0x3840
    net/ipv6/netfilter/nf_conntrack_reasm.c:617
     ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
     nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
     nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
     nf_hook include/linux/netfilter.h:212 [inline]
     __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
     ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
     ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
     ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
     rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
     rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
     inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
     sock_sendmsg_nosec net/socket.c:635 [inline]
     sock_sendmsg+0xca/0x110 net/socket.c:645
     sock_write_iter+0x326/0x600 net/socket.c:848
     do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
     do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
     vfs_writev+0x87/0xc0 fs/read_write.c:911
     do_writev+0x110/0x2c0 fs/read_write.c:944
     SYSC_writev fs/read_write.c:1017 [inline]
     SyS_writev+0x27/0x30 fs/read_write.c:1014
     entry_SYSCALL_64_fastpath+0x1f/0xc2
    RIP: 0033:0x445559
    
    Fixes: b90e5794c5bd ("net: dont call jump_label_dec from irq context")
    Suggested-by: Cong Wang <[email protected]>
    Reported-by: Dmitry Vyukov <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit e471486c13b82b1338d49c798f78bb62b1ed0a9e
Author: Dan Williams <[email protected]>
Date:   Thu Feb 2 10:31:00 2017 -0800

    acpi, nfit: fix acpi_nfit_flush_probe() crash
    
    We queue an on-stack work item to 'nfit_wq' and wait for it to complete
    as part of a 'flush_probe' request. However, if the user cancels the
    wait we need to make sure the item is flushed from the queue otherwise
    we are leaving an out-of-scope stack address on the work list.
    
     BUG: unable to handle kernel paging request at ffffbcb3c72f7cd0
     IP: [<ffffffffa9413a7b>] __list_add+0x1b/0xb0
     [..]
     RIP: 0010:[<ffffffffa9413a7b>]  [<ffffffffa9413a7b>] __list_add+0x1b/0xb0
     RSP: 0018:ffffbcb3c7ba7c00  EFLAGS: 00010046
     [..]
     Call Trace:
      [<ffffffffa90bb11a>] insert_work+0x3a/0xc0
      [<ffffffffa927fdda>] ? seq_open+0x5a/0xa0
      [<ffffffffa90bb30a>] __queue_work+0x16a/0x460
      [<ffffffffa90bbb08>] queue_work_on+0x38/0x40
      [<ffffffffc0cf2685>] acpi_nfit_flush_probe+0x95/0xc0 [nfit]
      [<ffffffffc0cf25d0>] ? nfit_visible+0x40/0x40 [nfit]
      [<ffffffffa9571495>] wait_probe_show+0x25/0x60
      [<ffffffffa9546b30>] dev_attr_show+0x20/0x50
    
    Fixes: 7ae0fa439faf ("nfit, libnvdimm: async region scrub workqueue")
    Cc: <[email protected]>
    Reviewed-by: Vishal Verma <[email protected]>
    Signed-off-by: Dan Williams <[email protected]>

commit 3808d34838184fd29088d6b3a364ba2f1c018fb6
Author: Stanislaw Gruszka <[email protected]>
Date:   Thu Feb 2 13:32:10 2017 +0100

    ethtool: do not vzalloc(0) on registers dump
    
    If ->get_regs_len() callback return 0, we allocate 0 bytes of memory,
    what print ugly warning in dmesg, which can be found further below.
    
    This happen on mac80211 devices where ieee80211_get_regs_len() just
    return 0 and driver only fills ethtool_regs structure and actually
    do not provide any dump. However I assume this can happen on other
    drivers i.e. when for some devices driver provide regs dump and for
    others do not. Hence preventing to to print warning in ethtool code
    seems to be reasonable.
    
    ethtool: vmalloc: allocation failure: 0 bytes, mode:0x24080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO)
    <snip>
    Call Trace:
    [<ffffffff813bde47>] dump_stack+0x63/0x8c
    [<ffffffff811b0a1f>] warn_alloc+0x13f/0x170
    [<ffffffff811f0476>] __vmalloc_node_range+0x1e6/0x2c0
    [<ffffffff811f0874>] vzalloc+0x54/0x60
    [<ffffffff8169986c>] dev_ethtool+0xb4c/0x1b30
    [<ffffffff816adbb1>] dev_ioctl+0x181/0x520
    [<ffffffff816714d2>] sock_do_ioctl+0x42/0x50
    <snip>
    Mem-Info:
    active_anon:435809 inactive_anon:173951 isolated_anon:0
     active_file:835822 inactive_file:196932 isolated_file:0
     unevictable:0 dirty:8 writeback:0 unstable:0
     slab_reclaimable:157732 slab_unreclaimable:10022
     mapped:83042 shmem:306356 pagetables:9507 bounce:0
     free:130041 free_pcp:1080 free_cma:0
    Node 0 active_anon:1743236kB inactive_anon:695804kB active_file:3343288kB inactive_file:787728kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:332168kB dirty:32kB writeback:0kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 1225424kB writeback_tmp:0kB unstable:0kB pages_scanned:0 all_unreclaimable? no
    Node 0 DMA free:15900kB min:136kB low:168kB high:200kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15984kB managed:15900kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
    lowmem_reserve[]: 0 3187 7643 7643
    Node 0 DMA32 free:419732kB min:28124kB low:35152kB high:42180kB active_anon:541180kB inactive_anon:248988kB active_file:1466388kB inactive_file:389632kB unevictable:0kB writepending:0kB present:3370280kB managed:3290932kB mlocked:0kB slab_reclaimable:217184kB slab_unreclaimable:4180kB kernel_stack:160kB pagetables:984kB bounce:0kB free_pcp:2236kB local_pcp:660kB free_cma:0kB
    lowmem_reserve[]: 0 0 4456 4456
    
    Signed-off-by: Stanislaw Gruszka <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 013e8167899d389075160412a8c0c5e0581e1f13
Author: David Lebrun <[email protected]>
Date:   Thu Feb 2 11:29:38 2017 +0100

    ipv6: sr: remove cleanup flag and fix HMAC computation
    
    In the latest version of the IPv6 Segment Routing IETF draft [1] the
    cleanup flag is removed and the flags field length is shrunk from 16 bits
    to 8 bits. As a consequence, the input of the HMAC computation is modified
    in a non-backward compatible way by covering the whole octet of flags
    instead of only the cleanup bit. As such, if an implementation compatible
    with the latest draft computes the HMAC of an SRH who has other flags set
    to 1, then the HMAC result would differ from the current implementation.
    
    This patch carries those modifications to prevent conflict with other
    implementations of IPv6 SR.
    
    [1] https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05
    
    Signed-off-by: David Lebrun <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f5b0cba8f23915e92932f11eb063e37d70556a89
Author: Ondrej Kozina <[email protected]>
Date:   Tue Jan 31 15:47:11 2017 +0100

    dm crypt: replace RCU read-side section with rwsem
    
    The lockdep splat below hints at a bug in RCU usage in dm-crypt that
    was introduced with commit c538f6ec9f56 ("dm crypt: add ability to use
    keys from the kernel key retention service").  The kernel keyring
    function user_key_payload() is in fact a wrapper for
    rcu_dereference_protected() which must not be called with only
    rcu_read_lock() section mark.
    
    Unfortunately the kernel keyring subsystem doesn't currently provide
    an interface that allows the use of an RCU read-side section.  So for
    now we must drop RCU in favour of rwsem until a proper function is
    made available in the kernel keyring subsystem.
    
    ===============================
    [ INFO: suspicious RCU usage. ]
    4.10.0-rc5 #2 Not tainted
    -------------------------------
    ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
    other info that might help us debug this:
    rcu_scheduler_active = 2, debug_locks = 1
    2 locks held by cryptsetup/6464:
     #0:  (&md->type_lock){+.+.+.}, at: [<ffffffffa02472a2>] dm_lock_md_type+0x12/0x20 [dm_mod]
     #1:  (rcu_read_lock){......}, at: [<ffffffffa02822f8>] crypt_set_key+0x1d8/0x4b0 [dm_crypt]
    stack backtrace:
    CPU: 1 PID: 6464 Comm: cryptsetup Not tainted 4.10.0-rc5 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
    Call Trace:
     dump_stack+0x67/0x92
     lockdep_rcu_suspicious+0xc5/0x100
     crypt_set_key+0x351/0x4b0 [dm_crypt]
     ? crypt_set_key+0x1d8/0x4b0 [dm_crypt]
     crypt_ctr+0x341/0xa53 [dm_crypt]
     dm_table_add_target+0x147/0x330 [dm_mod]
     table_load+0x111/0x350 [dm_mod]
     ? retrieve_status+0x1c0/0x1c0 [dm_mod]
     ctl_ioctl+0x1f5/0x510 [dm_mod]
     dm_ctl_ioctl+0xe/0x20 [dm_mod]
     do_vfs_ioctl+0x8e/0x690
     ? ____fput+0x9/0x10
     ? task_work_run+0x7e/0xa0
     ? trace_hardirqs_on_caller+0x122/0x1b0
     SyS_ioctl+0x3c/0x70
     entry_SYSCALL_64_fastpath+0x18/0xad
    RIP: 0033:0x7f392c9a4ec7
    RSP: 002b:00007ffef6383378 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007ffef63830a0 RCX: 00007f392c9a4ec7
    RDX: 000000000124fcc0 RSI: 00000000c138fd09 RDI: 0000000000000005
    RBP: 00007ffef6383090 R08: 00000000ffffffff R09: 00000000012482b0
    R10: 2a28205d34383336 R11: 0000000000000246 R12: 00007f392d803a08
    R13: 00007ffef63831e0 R14: 0000000000000000 R15: 00007f392d803a0b
    
    Fixes: c538f6ec9f56 ("dm crypt: add ability to use keys from the kernel key retention service")
    Reported-by: Milan Broz <[email protected]>
    Signed-off-by: Ondrej Kozina <[email protected]>
    Reviewed-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 4087a1fffe38106e10646606a27f10d40451862d
Author: Mike Snitzer <[email protected]>
Date:   Wed Jan 25 16:24:52 2017 +0100

    dm rq: cope with DM device destruction while in dm_old_request_fn()
    
    Fixes a crash in dm_table_find_target() due to a NULL struct dm_table
    being passed from dm_old_request_fn() that races with DM device
    destruction.
    
    Reported-by: [email protected]
    Signed-off-by: Mike Snitzer <[email protected]>
    Cc: [email protected]

commit d19a55ccad15a486ffe03030570744e5d5bd9f8e
Author: Mike Snitzer <[email protected]>
Date:   Fri Jan 6 15:33:14 2017 -0500

    dm mpath: cleanup -Wbool-operation warning in choose_pgpath()
    
    Reported-by: David Binderman <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 7c2cf1c4615cc2f576d0604406cdf0065f00b83b
Author: Harsh Jain <[email protected]>
Date:   Fri Jan 27 16:09:06 2017 +0530

    crypto: chcr - Fix key length for RFC4106
    
    Check keylen before copying salt to avoid wrap around of Integer.
    
    Signed-off-by: Harsh Jain <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit 0b529f143e8baad441a5aac9ad55ec2434d8fb46
Author: Harsh Jain <[email protected]>
Date:   Wed Feb 1 21:10:28 2017 +0530

    crypto: algif_aead - Fix kernel panic on list_del
    
    Kernel panics when userspace program try to access AEAD interface.
    Remove node from Linked List before freeing its memory.
    
    Cc: <[email protected]>
    Signed-off-by: Harsh Jain <[email protected]>
    Reviewed-by: Stephan Müller <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit c26819900036f5b91608051a0fc7c76f6b4ffc7b
Author: Herbert Xu <[email protected]>
Date:   Wed Feb 1 22:17:39 2017 +0800

    crypto: aesni - Fix failure when pcbc module is absent
    
    When aesni is built as a module together with pcbc, the pcbc module
    must be present for aesni to load.  However, the pcbc module may not
    be present for reasons such as its absence on initramfs.  This patch
    allows the aesni to function even if the pcbc module is enabled but
    not present.
    
    Reported-by: Arkadiusz Miśkiewicz <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit e5da5c5667381d2772374ee6a2967b3576c9483d
Author: Gary R Hook <[email protected]>
Date:   Fri Jan 27 17:09:04 2017 -0600

    crypto: ccp - Fix double add when creating new DMA command
    
    Eliminate a double-add by creating a new list to manage
    command descriptors when created; move the descriptor to
    the pending list when the command is submitted.
    
    Cc: <[email protected]>
    Signed-off-by: Gary R Hook <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit 500c0106e638e08c2c661c305ed57d6b67e10908
Author: Gary R Hook <[email protected]>
Date:   Fri Jan 27 15:28:45 2017 -0600

    crypto: ccp - Fix DMA operations when IOMMU is enabled
    
    An I/O page fault occurs when the IOMMU is enabled on a
    system that supports the v5 CCP.  DMA operations use a
    Request ID value that does not match what is expected by
    the IOMMU, resulting in the I/O page fault.  Setting the
    Request ID value to 0 corrects this issue.
    
    Cc: <[email protected]>
    Signed-off-by: Gary R Hook <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit f5f7bebc91ab378dea5aad5277c4d283e46472d9
Author: Harsh Jain <[email protected]>
Date:   Tue Jan 24 10:34:33 2017 +0530

    crypto: chcr - Check device is allocated before use
    
    Ensure dev is allocated for crypto uld context before using the device
    for crypto operations.
    
    Cc: <[email protected]>
    Signed-off-by: Atul Gupta <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit 94e1dab1c94715e18bb0bada503de3f3d7593076
Author: Harsh Jain <[email protected]>
Date:   Tue Jan 24 10:34:32 2017 +0530

    crypto: chcr - Fix panic on dma_unmap_sg
    
    Save DMA mapped sg list addresses to request context buffer.
    
    Signed-off-by: Atul Gupta <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit cafe8df8b9bc9aa3dffa827c1a6757c6cd36f657
Author: Mao Wenan <[email protected]>
Date:   Tue Jan 31 18:46:43 2017 -0800

    net: phy: Fix lack of reference count on PHY driver
    
    There is currently no reference count being held on the PHY driver,
    which makes it possible to remove the PHY driver module while the PHY
    state machine is running and polling the PHY. This could cause crashes
    similar to this one to show up:
    
    [   43.361162] BUG: unable to handle kernel NULL pointer dereference at 0000000000000140
    [   43.361162] IP: phy_state_machine+0x32/0x490
    [   43.361162] PGD 59dc067
    [   43.361162] PUD 0
    [   43.361162]
    [   43.361162] Oops: 0000 [#1] SMP
    [   43.361162] Modules linked in: dsa_loop [last unloaded: broadcom]
    [   43.361162] CPU: 0 PID: 1299 Comm: kworker/0:3 Not tainted 4.10.0-rc5+ #415
    [   43.361162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
    [   43.361162] Workqueue: events_power_efficient phy_state_machine
    [   43.361162] task: ffff880006782b80 task.stack: ffffc90000184000
    [   43.361162] RIP: 0010:phy_state_machine+0x32/0x490
    [   43.361162] RSP: 0018:ffffc90000187e18 EFLAGS: 00000246
    [   43.361162] RAX: 0000000000000000 RBX: ffff8800059e53c0 RCX:
    ffff880006a15c60
    [   43.361162] RDX: ffff880006782b80 RSI: 0000000000000000 RDI:
    ffff8800059e5428
    [   43.361162] RBP: ffffc90000187e48 R08: ffff880006a15c40 R09:
    0000000000000000
    [   43.361162] R10: 0000000000000000 R11: 0000000000000000 R12:
    ffff8800059e5428
    [   43.361162] R13: ffff8800059e5000 R14: 0000000000000000 R15:
    ffff880006a15c40
    [   43.361162] FS:  0000000000000000(0000) GS:ffff880006a00000(0000)
    knlGS:0000000000000000
    [   43.361162] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   43.361162] CR2: 0000000000000140 CR3: 0000000005979000 CR4:
    00000000000006f0
    [   43.361162] Call Trace:
    [   43.361162]  process_one_work+0x1b4/0x3e0
    [   43.361162]  worker_thread+0x43/0x4d0
    [   43.361162]  ? __schedule+0x17f/0x4e0
    [   43.361162]  kthread+0xf7/0x130
    [   43.361162]  ? process_one_work+0x3e0/0x3e0
    [   43.361162]  ? kthread_create_on_node+0x40/0x40
    [   43.361162]  ret_from_fork+0x29/0x40
    [   43.361162] Code: 56 41 55 41 54 4c 8d 67 68 53 4c 8d af 40 fc ff ff
    48 89 fb 4c 89 e7 48 83 ec 08 e8 c9 9d 27 00 48 8b 83 60 ff ff ff 44 8b
    73 98 <48> 8b 90 40 01 00 00 44 89 f0 48 85 d2 74 08 4c 89 ef ff d2 8b
    
    Keep references on the PHY driver module right before we are going to
    utilize it in phy_attach_direct(), and conversely when we don't use it
    anymore in phy_detach().
    
    Signed-off-by: Mao Wenan <[email protected]>
    [florian: rebase, rework commit message]
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 770f82253dbd7e6892a88018f2f6cd395f48d214
Author: Martin KaFai Lau <[email protected]>
Date:   Tue Jan 31 22:35:33 2017 -0800

    mlx4: xdp_prog becomes inactive after ethtool '-L' or '-G'
    
    After calling mlx4_en_try_alloc_resources (e.g. by changing the
    number of rx-queues with ethtool -L), the existing xdp_prog becomes
    inactive.
    
    The bug is that the xdp_prog ptr has not been carried over from
    the old rx-queues to the new rx-queues
    
    Fixes: 47a38e155037 ("net/mlx4_en: add support for fast rx drop bpf program")
    Cc: Brenden Blanco <[email protected]>
    Cc: Saeed Mahameed <[email protected]>
    Cc: Tariq Toukan <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f32b20e89e82c9ff1825fc5c5d69753ff5558ccd
Author: Martin KaFai Lau <[email protected]>
Date:   Tue Jan 31 22:35:32 2017 -0800

    mlx4: Fix memory leak after mlx4_en_update_priv()
    
    In mlx4_en_update_priv(), dst->tx_ring[t] and dst->tx_cq[t]
    are over-written by src->tx_ring[t] and src->tx_cq[t] without
    first calling kfree.
    
    One of the reproducible code paths is by doing 'ethtool -L'.
    
    The fix is to do the kfree in mlx4_en_free_resources().
    
    Here is the kmemleak report:
    unreferenced object 0xffff880841211800 (size 2048):
      comm "ethtool", pid 3096, jiffies 4294716940 (age 528.353s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81930718>] kmemleak_alloc+0x28/0x50
        [<ffffffff8120b213>] kmem_cache_alloc_trace+0x103/0x260
        [<ffffffff8170e0a8>] mlx4_en_try_alloc_resources+0x118/0x1a0
        [<ffffffff817065a9>] mlx4_en_set_ringparam+0x169/0x210
        [<ffffffff818040c5>] dev_ethtool+0xae5/0x2190
        [<ffffffff8181b898>] dev_ioctl+0x168/0x6f0
        [<ffffffff817d7a72>] sock_do_ioctl+0x42/0x50
        [<ffffffff817d819b>] sock_ioctl+0x21b/0x2d0
        [<ffffffff81247a73>] do_vfs_ioctl+0x93/0x6a0
        [<ffffffff812480f9>] SyS_ioctl+0x79/0x90
        [<ffffffff8193d7ea>] entry_SYSCALL_64_fastpath+0x18/0xad
        [<ffffffffffffffff>] 0xffffffffffffffff
    unreferenced object 0xffff880841213000 (size 2048):
      comm "ethtool", pid 3096, jiffies 4294716940 (age 528.353s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81930718>] kmemleak_alloc+0x28/0x50
        [<ffffffff8120b213>] kmem_cache_alloc_trace+0x103/0x260
        [<ffffffff8170e0cb>] mlx4_en_try_alloc_resources+0x13b/0x1a0
        [<ffffffff817065a9>] mlx4_en_set_ringparam+0x169/0x210
        [<ffffffff818040c5>] dev_ethtool+0xae5/0x2190
        [<ffffffff8181b898>] dev_ioctl+0x168/0x6f0
        [<ffffffff817d7a72>] sock_do_ioctl+0x42/0x50
        [<ffffffff817d819b>] sock_ioctl+0x21b/0x2d0
        [<ffffffff81247a73>] do_vfs_ioctl+0x93/0x6a0
        [<ffffffff812480f9>] SyS_ioctl+0x79/0x90
        [<ffffffff8193d7ea>] entry_SYSCALL_64_fastpath+0x18/0xad
        [<ffffffffffffffff>] 0xffffffffffffffff
    
    (gdb) list *mlx4_en_try_alloc_resources+0x118
    0xffffffff8170e0a8 is in mlx4_en_try_alloc_resources (drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2145).
    2140                    if (!dst->tx_ring_num[t])
    2141                            continue;
    2142
    2143                    dst->tx_ring[t] = kzalloc(sizeof(struct mlx4_en_tx_ring *) *
    2144                                              MAX_TX_RINGS, GFP_KERNEL);
    2145                    if (!dst->tx_ring[t])
    2146                            goto err_free_tx;
    2147
    2148                    dst->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
    2149                                            MAX_TX_RINGS, GFP_KERNEL);
    (gdb) list *mlx4_en_try_alloc_resources+0x13b
    0xffffffff8170e0cb is in mlx4_en_try_alloc_resources (drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2150).
    2145                    if (!dst->tx_ring[t])
    2146                            goto err_free_tx;
    2147
    2148                    dst->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
    2149                                            MAX_TX_RINGS, GFP_KERNEL);
    2150                    if (!dst->tx_cq[t]) {
    2151                            kfree(dst->tx_ring[t]);
    2152                            goto err_free_tx;
    2153                    }
    2154            }
    
    Fixes: ec25bc04ed8e ("net/mlx4_en: Add resilience in low memory systems")
    Cc: Eugenia Emantayev <[email protected]>
    Cc: Saeed Mahameed <[email protected]>
    Cc: Tariq Toukan <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 685ce0626840e2673fe64ea8807684f7324fec5f
Author: Giovanni Cabiddu <[email protected]>
Date:   Thu Dec 22 15:00:24 2016 +0000

    crypto: qat - zero esram only for DH85x devices
    
    Zero embedded ram in DH85x devices. This is not
    needed for newer generations as it is done by HW.
    
    Cc: <[email protected]>
    Signed-off-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit 3484ecbe0e9deb94afb0b9b6172d77e98eb72b94
Author: Giovanni Cabiddu <[email protected]>
Date:   Thu Dec 22 15:00:12 2016 +0000

    crypto: qat - fix bar discovery for c62x
    
    Some accelerators of the c62x series have only two bars.
    This patch skips BAR0 if the accelerator does not have it.
    
    Cc: <[email protected]>
    Signed-off-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>

commit 9d032f4201d39e5cf43a8709a047e481f5723fdc
Author: Dan Williams <[email protected]>
Date:   Wed Jan 25 00:54:07 2017 +0530

    libnvdimm, namespace: do not delete namespace-id 0
    
    Given that the naming of pmem devices changes from the pmemX form to the
    pmemX.Y form when namespace id is greater than 0, arrange for namespaces
    with id-0 to be exempt from deletion. Otherwise a simple reconfiguration
    of an existing namespace to a new mode results in a name change of the
    resulting block device:
    
        # ndctl list --namespace=namespace1.0
        {
          "dev":"namespace1.0",
          "mode":"raw",
          "size":2147483648,
          "uuid":"3dadf3dc-89b9-4b24-b20e-abc8a4707ce3",
          "blockdev":"pmem1"
        }
    
        # ndctl create-namespace --reconfig=namespace1.0 --mode=memory --force
        {
          "dev":"namespace1.1",
          "mode":"memory",
          "size":2111832064,
          "uuid":"7b4a6341-7318-4219-a02c-fb57c0bbf613",
          "blockdev":"pmem1.1"
        }
    
    This change does require tooling changes to explicitly look for
    namespaceX.0 if the seed has already advanced to another namespace.
    
    Cc: <[email protected]>
    Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple pmem-namespaces per region")
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Signed-off-by: Dan Williams <[email protected]>

commit 970d14e3989160ee9e97c7d75ecbc893fd29dab9
Author: Bhumika Goyal <[email protected]>
Date:   Wed Jan 25 00:54:07 2017 +0530

    nvdimm: constify device_type structures
    
    Declare device_type structure as const as it is only stored in the
    type field of a device structure. This field is of type const, so add
    const to declaration of device_type structure.
    
    File size before:
      text	   data	    bss	    dec	    hex	filename
      19278	   3199	     16	  22493	   57dd	nvdimm/namespace_devs.o
    
    File size after:
      text	   data	    bss	    dec	    hex	filename
      19929	   3160	     16	  23105	   5a41	nvdimm/namespace_devs.o
    
    Signed-off-by: Bhumika Goyal <[email protected]>
    Signed-off-by: Dan Williams <[email protected]>

commit 52f5631a4c056ad01682393be56d2be237e81610
Author: Jurij Smakov <[email protected]>
Date:   Mon Jan 30 15:41:36 2017 -0600

    rtlwifi: rtl8192ce: Fix loading of incorrect firmware
    
    In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
    d86e64768859, an error in the edit results in the wrong firmware
    being loaded for some models of the RTL8188/8192CE. In this condition,
    the connection suffered from high ping latency, slow transfer rates,
     and required higher signal strengths to work at all
    
    See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
    https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
    https://github.com/lwfinger/rtlwifi_new/issues/203 for descriptions
    of the problems. This patch fixes all of those problems.
    
    Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
    Signed-off-by: Jurij Smakov <[email protected]>
    Signed-off-by: Larry Finger <[email protected]>
    Cc: Stable <[email protected]> # 4.9+
    Signed-off-by: Kalle Valo <[email protected]>

commit f9f96fc10c09ca16e336854c08bc1563eed97985
Author: Hans Verkuil <[email protected]>
Date:   Tue Jan 10 09:44:54 2017 -0200

    [media] cec: fix wrong last_la determination
    
    Due to an incorrect condition the last_la used for the initial attempt at
    claiming a logical address could be wrong.
    
    The last_la wasn't converted to a mask when ANDing with type2mask, so that
    test was broken.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>

commit 8015d6b83cadc8f9f94c7bc8430255090ddf43d4
Author: Hans Verkuil <[email protected]>
Date:   Mon Jan 2 09:54:24 2017 -0200

    [media] cec-intro.rst: mention the v4l-utils package and CEC utilities
    
    Mention where to find the CEC utilities.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>

commit ed72b81bb7a49e8bfaa8dd6ab0b0e103ff0771ae
Author: Hans Verkuil <[email protected]>
Date:   Mon Jan 2 09:41:40 2017 -0200

    [media] cec rst: remove "This API is not yet finalized" notice
    
    The API is now finalized, so this notice should be dropped.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>

commit 3c223c19aea85d3dda1416c187915f4a30b04b1f
Author: Markus Mayer <[email protected]>
Date:   Mon Dec 19 12:10:28 2016 -0800

    cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend
    
    The AVS GET_PMAP command does return a P-state along with the P-map
    information. However, that P-state is the initial P-state when the
    P-map was first downloaded to AVS. It is *not* the current P-state.
    
    Therefore, we explicitly retrieve the P-state using the GET_PSTATE
    command.
    
    Signed-off-by: Markus Mayer <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit 9b02c54bc951fca884ba5719f42a27e8240965bf
Author: Markus Mayer <[email protected]>
Date:   Mon Dec 19 12:10:27 2016 -0800

    cpufreq: brcmstb-avs-cpufreq: extend sysfs entry brcm_avs_pmap
    
    We extend the brcm_avs_pmap sysfs entry (which issues the GET_PMAP
    command to AVS) to include all fields from struct pmap. This means
    adding mode (AVS, DVS, DVFS) and state (the P-state) to the output.
    
    Signed-off-by: Markus Mayer <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

Author: mmotm auto import

Documentation/media/uapi/cec/cec-func-close.rst

@@ -33,11 +33,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 Closes the cec device. Resources associated with the file descriptor are
 freed. The device configuration remain unchanged.
 

Documentation/media/uapi/cec/cec-func-ioctl.rst

@@ -39,11 +39,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 The :c:func:`ioctl()` function manipulates cec device parameters. The
 argument ``fd`` must be an open file descriptor.
 

Documentation/media/uapi/cec/cec-func-open.rst

@@ -46,11 +46,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 To open a cec device applications call :c:func:`open()` with the
 desired device name. The function has no side effects; the device
 configuration remain unchanged.

Documentation/media/uapi/cec/cec-func-poll.rst

@@ -39,11 +39,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 With the :c:func:`poll()` function applications can wait for CEC
 events.
 

Documentation/media/uapi/cec/cec-intro.rst

@@ -3,11 +3,6 @@
 Introduction
 ============
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 HDMI connectors provide a single pin for use by the Consumer Electronics
 Control protocol. This protocol allows different devices connected by an
 HDMI cable to communicate. The protocol for CEC version 1.4 is defined
@@ -31,3 +26,15 @@ control just the CEC pin.
 Drivers that support CEC will create a CEC device node (/dev/cecX) to
 give userspace access to the CEC adapter. The
 :ref:`CEC_ADAP_G_CAPS` ioctl will tell userspace what it is allowed to do.
+
+In order to check the support and test it, it is suggested to download
+the `v4l-utils <https://git.linuxtv.org/v4l-utils.git/>`_ package. It
+provides three tools to handle CEC:
+
+- cec-ctl: the Swiss army knife of CEC. Allows you to configure, transmit
+  and monitor CEC messages.
+
+- cec-compliance: does a CEC compliance test of a remote CEC device to
+  determine how compliant the CEC implementation is.
+
+- cec-follower: emulates a CEC follower.

Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst

@@ -29,11 +29,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 All cec devices must support :ref:`ioctl CEC_ADAP_G_CAPS <CEC_ADAP_G_CAPS>`. To query
 device information, applications call the ioctl with a pointer to a
 struct :c:type:`cec_caps`. The driver fills the structure and

Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst

@@ -35,11 +35,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 To query the current CEC logical addresses, applications call
 :ref:`ioctl CEC_ADAP_G_LOG_ADDRS <CEC_ADAP_G_LOG_ADDRS>` with a pointer to a
 struct :c:type:`cec_log_addrs` where the driver stores the logical addresses.

Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst

@@ -35,11 +35,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 To query the current physical address applications call
 :ref:`ioctl CEC_ADAP_G_PHYS_ADDR <CEC_ADAP_G_PHYS_ADDR>` with a pointer to a __u16 where the
 driver stores the physical address.

Documentation/media/uapi/cec/cec-ioc-dqevent.rst

@@ -30,11 +30,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 CEC devices can send asynchronous events. These can be retrieved by
 calling :c:func:`CEC_DQEVENT`. If the file descriptor is in
 non-blocking mode and no event is pending, then it will return -1 and

Documentation/media/uapi/cec/cec-ioc-g-mode.rst

@@ -31,11 +31,6 @@ Arguments
 Description
 ===========
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 By default any filehandle can use :ref:`CEC_TRANSMIT`, but in order to prevent
 applications from stepping on each others toes it must be possible to
 obtain exclusive access to the CEC adapter. This ioctl sets the