Skip to content
Snippets Groups Projects
  1. Jun 29, 2024
  2. May 17, 2024
  3. May 07, 2024
  4. Apr 22, 2024
  5. Apr 12, 2024
  6. Apr 08, 2024
  7. Apr 05, 2024
  8. Apr 04, 2024
  9. Mar 15, 2024
  10. Mar 14, 2024
  11. Mar 13, 2024
  12. Mar 12, 2024
    • tyiu's avatar
      binder: change nice value of rt to non-rt call · 048cd1f2
      tyiu authored
      
      Currently, when a node does not support real-time priority inheritance
      but serves a real-time thread, the thread priority is hard coded to 120
      with normal scheduling policy.
      
      This patch aims to boost the normal priority of a thread that serves
      real-time thread from 120 to 100 to better mitigate a binder priority
      inversion on real-time threads.
      
      Bug: 327270040
      Test: abtd runs
      Change-Id: I8c36edd48a1bc2ede457862cf80533c293c4b0e9
      Signed-off-by: default avatartyiu <tyiu@google.com>
      048cd1f2
  13. Mar 08, 2024
    • Greg Kroah-Hartman's avatar
      Merge 52c46caf ("tcp: Add memory barrier to tcp_push()") into android-mainline · cc833652
      Greg Kroah-Hartman authored
      
      Steps on the way to 4.19.307
      
      Change-Id: I67749a2eebff3778e717a9acce93c1d7ed1f6328
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      cc833652
    • Peiyong Wang's avatar
      BACKPORT: net: core: enable SO_BINDTODEVICE for non-root users · 8ea171e4
      Peiyong Wang authored
      
      Currently, SO_BINDTODEVICE requires CAP_NET_RAW. This change allows a
      non-root user to bind a socket to an interface if it is not already
      bound. This is useful to allow an application to bind itself to a
      specific VRF for outgoing or incoming connections. Currently, an
      application wanting to manage connections through several VRF need to
      be privileged.
      
      Previously, IP_UNICAST_IF and IPV6_UNICAST_IF were added for
      Wine (76e21053 and c4062dfc) specifically for use by
      non-root processes. However, they are restricted to sendmsg() and not
      usable with TCP. Allowing SO_BINDTODEVICE would allow TCP clients to
      get the same privilege. As for TCP servers, outside the VRF use case,
      SO_BINDTODEVICE would only further restrict connections a server could
      accept.
      
      When an application is restricted to a VRF (with `ip vrf exec`), the
      socket is bound to an interface at creation and therefore, a
      non-privileged call to SO_BINDTODEVICE to escape the VRF fails.
      
      When an application bound a socket to SO_BINDTODEVICE and transmit it
      to a non-privileged process through a Unix socket, a tentative to
      change the bound device also fails.
      
      Before:
      
          >>> import socket
          >>> s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
          >>> s.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, b"dummy0")
          Traceback (most recent call last):
            File "<stdin>", line 1, in <module>
          PermissionError: [Errno 1] Operation not permitted
      
      After:
      
          >>> import socket
          >>> s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
          >>> s.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, b"dummy0")
          >>> s.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, b"dummy0")
          Traceback (most recent call last):
            File "<stdin>", line 1, in <module>
          PermissionError: [Errno 1] Operation not permitted
      
      Bug: 323792489
      Signed-off-by: default avatarVincent Bernat <vincent@bernat.ch>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      (cherry picked from commit c427bfec)
      Change-Id: Ie3f4c536b78da12dd961dc681c6dfb0cdf1a06b7
      Signed-off-by: default avatarPeiyong Wang <wangpeiyong@xiaomi.corp-partner.google.com>
      8ea171e4
  14. Mar 07, 2024
  15. Feb 28, 2024
  16. Feb 27, 2024
    • Wlogsky's avatar
      display: Add HBM support · e2de32e5
      Wlogsky authored
      
      Expanding brightness range for HBM so that the design can fit into
      Android U design.
      
      Bug: 317308706
      Test: adb shell echo 256 > /sys/class/backlight/panel_0/brightness
      Change-Id: I495bf0cc7c1339a1b0e0599985c76c7c46702010
      Signed-off-by: default avatarWlogsky <wlogsky@google.com>
      e2de32e5
  17. Feb 26, 2024
  18. Feb 23, 2024
    • Salvatore Dipietro's avatar
      tcp: Add memory barrier to tcp_push() · 52c46caf
      Salvatore Dipietro authored
      [ Upstream commit 7267e8dc ]
      
      On CPUs with weak memory models, reads and updates performed by tcp_push
      to the sk variables can get reordered leaving the socket throttled when
      it should not. The tasklet running tcp_wfree() may also not observe the
      memory updates in time and will skip flushing any packets throttled by
      tcp_push(), delaying the sending. This can pathologically cause 40ms
      extra latency due to bad interactions with delayed acks.
      
      Adding a memory barrier in tcp_push removes the bug, similarly to the
      previous commit bf06200e ("tcp: tsq: fix nonagle handling").
      smp_mb__after_atomic() is used to not incur in unnecessary overhead
      on x86 since not affected.
      
      Patch has been tested using an AWS c7g.2xlarge instance with Ubuntu
      22.04 and Apache Tomcat 9.0.83 running the basic servlet below:
      
      import java.io.IOException;
      import java.io.OutputStreamWriter;
      import java.io.PrintWriter;
      import javax.servlet.ServletException;
      import javax.servlet.http.HttpServlet;
      import javax.servlet.http.HttpServletRequest;
      import javax.servlet.http.HttpServletResponse;
      
      public class HelloWorldServlet extends HttpServlet {
          @Override
          protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
              response.setContentType("text/html;charset=utf-8");
              OutputStreamWriter osw = new OutputStreamWriter(response.getOutputStream(),"UTF-8");
              String s = "a".repeat(3096);
              osw.write(s,0,s.length());
              osw.flush();
          }
      }
      
      Load was applied using wrk2 (https://github.com/kinvolk/wrk2) from an AWS
      c6i.8xlarge instance. Before the patch an additional 40ms latency from P99.99+
      values is observed while, with the patch, the extra latency disappears.
      
      No patch and tcp_autocorking=1
      ./wrk -t32 -c128 -d40s --latency -R10000  http://172.31.60.173:8080/hello/hello
        ...
       50.000%    0.91ms
       75.000%    1.13ms
       90.000%    1.46ms
       99.000%    1.74ms
       99.900%    1.89ms
       99.990%   41.95ms  <<< 40+ ms extra latency
       99.999%   48.32ms
      100.000%   48.96ms
      
      With patch and tcp_autocorking=1
      ./wrk -t32 -c128 -d40s --latency -R10000  http://172.31.60.173:8080/hello/hello
      
      
        ...
       50.000%    0.90ms
       75.000%    1.13ms
       90.000%    1.45ms
       99.000%    1.72ms
       99.900%    1.83ms
       99.990%    2.11ms  <<< no 40+ ms extra latency
       99.999%    2.53ms
      100.000%    2.62ms
      
      Patch has been also tested on x86 (m7i.2xlarge instance) which it is not
      affected by this issue and the patch doesn't introduce any additional
      delay.
      
      Fixes: 7aa5470c ("tcp: tsq: move tsq_flags close to sk_wmem_alloc")
      Signed-off-by: default avatarSalvatore Dipietro <dipiets@amazon.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20240119190133.43698-1-dipiets@amazon.com
      
      
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      52c46caf
    • Petr Pavlu's avatar
      tracing: Ensure visibility when inserting an element into tracing_map · 5022b331
      Petr Pavlu authored
      [ Upstream commit 2b447606 ]
      
      Running the following two commands in parallel on a multi-processor
      AArch64 machine can sporadically produce an unexpected warning about
      duplicate histogram entries:
      
       $ while true; do
           echo hist:key=id.syscall:val=hitcount > \
             /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger
           cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
           sleep 0.001
         done
       $ stress-ng --sysbadaddr $(nproc)
      
      The warning looks as follows:
      
      [ 2911.172474] ------------[ cut here ]------------
      [ 2911.173111] Duplicates detected: 1
      [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408
      [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)
      [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1
      [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G            E      6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01
      [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018
      [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
      [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408
      [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408
      [ 2911.185310] sp : ffff8000a1513900
      [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001
      [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008
      [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180
      [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff
      [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8
      [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731
      [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c
      [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8
      [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000
      [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480
      [ 2911.194259] Call trace:
      [ 2911.194626]  tracing_map_sort_entries+0x3e0/0x408
      [ 2911.195220]  hist_show+0x124/0x800
      [ 2911.195692]  seq_read_iter+0x1d4/0x4e8
      [ 2911.196193]  seq_read+0xe8/0x138
      [ 2911.196638]  vfs_read+0xc8/0x300
      [ 2911.197078]  ksys_read+0x70/0x108
      [ 2911.197534]  __arm64_sys_read+0x24/0x38
      [ 2911.198046]  invoke_syscall+0x78/0x108
      [ 2911.198553]  el0_svc_common.constprop.0+0xd0/0xf8
      [ 2911.199157]  do_el0_svc+0x28/0x40
      [ 2911.199613]  el0_svc+0x40/0x178
      [ 2911.200048]  el0t_64_sync_handler+0x13c/0x158
      [ 2911.200621]  el0t_64_sync+0x1a8/0x1b0
      [ 2911.201115] ---[ end trace 0000000000000000 ]---
      
      The problem appears to be caused by CPU reordering of writes issued from
      __tracing_map_insert().
      
      The check for the presence of an element with a given key in this
      function is:
      
       val = READ_ONCE(entry->val);
       if (val && keys_match(key, val->key, map->key_size)) ...
      
      The write of a new entry is:
      
       elt = get_free_elt(map);
       memcpy(elt->key, key, map->key_size);
       entry->val = elt;
      
      The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"
      stores may become visible in the reversed order on another CPU. This
      second CPU might then incorrectly determine that a new key doesn't match
      an already present val->key and subsequently insert a new element,
      resulting in a duplicate.
      
      Fix the problem by adding a write barrier between
      "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;", and for
      good measure, also use WRITE_ONCE(entry->val, elt) for publishing the
      element. The sequence pairs with the mentioned "READ_ONCE(entry->val);"
      and the "val->key" check which has an address dependency.
      
      The barrier is placed on a path executed when adding an element for
      a new key. Subsequent updates targeting the same key remain unaffected.
      
      From the user's perspective, the issue was introduced by commit
      c193707d ("tracing: Remove code which merges duplicates"), which
      followed commit cbf4100e ("tracing: Add support to detect and avoid
      duplicates"). The previous code operated differently; it inherently
      expected potential races which result in duplicates but merged them
      later when they occurred.
      
      Link: https://lore.kernel.org/linux-trace-kernel/20240122150928.27725-1-petr.pavlu@suse.com
      
      
      
      Fixes: c193707d ("tracing: Remove code which merges duplicates")
      Signed-off-by: default avatarPetr Pavlu <petr.pavlu@suse.com>
      Acked-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5022b331
    • Sharath Srinivasan's avatar
      net/rds: Fix UBSAN: array-index-out-of-bounds in rds_cmsg_recv · 344350bf
      Sharath Srinivasan authored
      
      [ Upstream commit 13e788de ]
      
      Syzcaller UBSAN crash occurs in rds_cmsg_recv(),
      which reads inc->i_rx_lat_trace[j + 1] with index 4 (3 + 1),
      but with array size of 4 (RDS_RX_MAX_TRACES).
      Here 'j' is assigned from rs->rs_rx_trace[i] and in-turn from
      trace.rx_trace_pos[i] in rds_recv_track_latency(),
      with both arrays sized 3 (RDS_MSG_RX_DGRAM_TRACE_MAX). So fix the
      off-by-one bounds check in rds_recv_track_latency() to prevent
      a potential crash in rds_cmsg_recv().
      
      Found by syzcaller:
      =================================================================
      UBSAN: array-index-out-of-bounds in net/rds/recv.c:585:39
      index 4 is out of range for type 'u64 [4]'
      CPU: 1 PID: 8058 Comm: syz-executor228 Not tainted 6.6.0-gd2f51b3516da #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      BIOS 1.15.0-1 04/01/2014
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106
       ubsan_epilogue lib/ubsan.c:217 [inline]
       __ubsan_handle_out_of_bounds+0xd5/0x130 lib/ubsan.c:348
       rds_cmsg_recv+0x60d/0x700 net/rds/recv.c:585
       rds_recvmsg+0x3fb/0x1610 net/rds/recv.c:716
       sock_recvmsg_nosec net/socket.c:1044 [inline]
       sock_recvmsg+0xe2/0x160 net/socket.c:1066
       __sys_recvfrom+0x1b6/0x2f0 net/socket.c:2246
       __do_sys_recvfrom net/socket.c:2264 [inline]
       __se_sys_recvfrom net/socket.c:2260 [inline]
       __x64_sys_recvfrom+0xe0/0x1b0 net/socket.c:2260
       do_syscall_x64 arch/x86/entry/common.c:51 [inline]
       do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
       entry_SYSCALL_64_after_hwframe+0x63/0x6b
      ==================================================================
      
      Fixes: 3289025a ("RDS: add receive message trace used by application")
      Reported-by: default avatarChenyuan Yang <chenyuan0y@gmail.com>
      Closes: https://lore.kernel.org/linux-rdma/CALGdzuoVdq-wtQ4Az9iottBqC5cv9ZhcE5q8N7LfYFvkRsOVcw@mail.gmail.com/
      
      
      Signed-off-by: default avatarSharath Srinivasan <sharath.srinivasan@oracle.com>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      344350bf
    • Kuniyuki Iwashima's avatar
      llc: Drop support for ETH_P_TR_802_2. · 165ad1e2
      Kuniyuki Iwashima authored
      
      [ Upstream commit e3f9bed9 ]
      
      syzbot reported an uninit-value bug below. [0]
      
      llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
      (0x0011), and syzbot abused the latter to trigger the bug.
      
        write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
      
      llc_conn_handler() initialises local variables {saddr,daddr}.mac
      based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
      them to __llc_lookup().
      
      However, the initialisation is done only when skb->protocol is
      htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
      __llc_lookup_listener() will read garbage.
      
      The missing initialisation existed prior to commit 211ed865
      ("net: delete all instances of special processing for token ring").
      
      It removed the part to kick out the token ring stuff but forgot to
      close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
      
      Let's remove llc_tr_packet_type and complete the deprecation.
      
      [0]:
      BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
       __llc_lookup_established+0xe9d/0xf90
       __llc_lookup net/llc/llc_conn.c:611 [inline]
       llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
       llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
       __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
       __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
       netif_receive_skb_internal net/core/dev.c:5727 [inline]
       netif_receive_skb+0x58/0x660 net/core/dev.c:5786
       tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
       tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
       tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
       call_write_iter include/linux/fs.h:2020 [inline]
       new_sync_write fs/read_write.c:491 [inline]
       vfs_write+0x8ef/0x1490 fs/read_write.c:584
       ksys_write+0x20f/0x4c0 fs/read_write.c:637
       __do_sys_write fs/read_write.c:649 [inline]
       __se_sys_write fs/read_write.c:646 [inline]
       __x64_sys_write+0x93/0xd0 fs/read_write.c:646
       do_syscall_x64 arch/x86/entry/common.c:51 [inline]
       do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
       entry_SYSCALL_64_after_hwframe+0x63/0x6b
      
      Local variable daddr created at:
       llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
       llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
      
      CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
      
      Fixes: 211ed865 ("net: delete all instances of special processing for token ring")
      Reported-by: default avatar <syzbot+b5ad66046b913bc04c6f@syzkaller.appspotmail.com>
      Closes: https://syzkaller.appspot.com/bug?extid=b5ad66046b913bc04c6f
      
      
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20240119015515.61898-1-kuniyu@amazon.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      165ad1e2
    • Eric Dumazet's avatar
      llc: make llc_ui_sendmsg() more robust against bonding changes · 84e9d104
      Eric Dumazet authored
      
      [ Upstream commit dad555c8 ]
      
      syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
      headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
      
      Like some others, llc_ui_sendmsg() releases the socket lock before
      calling sock_alloc_send_skb().
      Then it acquires it again, but does not redo all the sanity checks
      that were performed.
      
      This fix:
      
      - Uses LL_RESERVED_SPACE() to reserve space.
      - Check all conditions again after socket lock is held again.
      - Do not account Ethernet header for mtu limitation.
      
      [1]
      
      skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
      
       kernel BUG at net/core/skbuff.c:193 !
      Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
      pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
       pc : skb_panic net/core/skbuff.c:189 [inline]
       pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
       lr : skb_panic net/core/skbuff.c:189 [inline]
       lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
      sp : ffff800096f97000
      x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
      x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
      x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
      x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
      x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
      x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
      x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
      x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
      x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
      x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
      Call trace:
        skb_panic net/core/skbuff.c:189 [inline]
        skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
        skb_push+0xf0/0x108 net/core/skbuff.c:2451
        eth_header+0x44/0x1f8 net/ethernet/eth.c:83
        dev_hard_header include/linux/netdevice.h:3188 [inline]
        llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
        llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
        llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
        llc_sap_next_state net/llc/llc_sap.c:182 [inline]
        llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
        llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
        llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
        sock_sendmsg_nosec net/socket.c:730 [inline]
        __sock_sendmsg net/socket.c:745 [inline]
        sock_sendmsg+0x194/0x274 net/socket.c:767
        splice_to_socket+0x7cc/0xd58 fs/splice.c:881
        do_splice_from fs/splice.c:933 [inline]
        direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
        splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
        do_splice_direct+0x20c/0x348 fs/splice.c:1194
        do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
        __do_sys_sendfile64 fs/read_write.c:1322 [inline]
        __se_sys_sendfile64 fs/read_write.c:1308 [inline]
        __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
        __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
        invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
        el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
        do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
        el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
        el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
        el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
      Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-and-tested-by: default avatar <syzbot+2a7024e9502df538e8ef@syzkaller.appspotmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Link: https://lore.kernel.org/r/20240118183625.4007013-1-edumazet@google.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      84e9d104
    • Lin Ma's avatar
      vlan: skip nested type that is not IFLA_VLAN_QOS_MAPPING · 91759822
      Lin Ma authored
      
      [ Upstream commit 6c21660fe221a15c789dee2bc2fd95516bc5aeaf ]
      
      In the vlan_changelink function, a loop is used to parse the nested
      attributes IFLA_VLAN_EGRESS_QOS and IFLA_VLAN_INGRESS_QOS in order to
      obtain the struct ifla_vlan_qos_mapping. These two nested attributes are
      checked in the vlan_validate_qos_map function, which calls
      nla_validate_nested_deprecated with the vlan_map_policy.
      
      However, this deprecated validator applies a LIBERAL strictness, allowing
      the presence of an attribute with the type IFLA_VLAN_QOS_UNSPEC.
      Consequently, the loop in vlan_changelink may parse an attribute of type
      IFLA_VLAN_QOS_UNSPEC and believe it carries a payload of
      struct ifla_vlan_qos_mapping, which is not necessarily true.
      
      To address this issue and ensure compatibility, this patch introduces two
      type checks that skip attributes whose type is not IFLA_VLAN_QOS_MAPPING.
      
      Fixes: 07b5b17e ("[VLAN]: Use rtnl_link API")
      Signed-off-by: default avatarLin Ma <linma@zju.edu.cn>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Link: https://lore.kernel.org/r/20240118130306.1644001-1-linma@zju.edu.cn
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      91759822
    • Wen Gu's avatar
      net/smc: fix illegal rmb_desc access in SMC-D connection dump · 27aea648
      Wen Gu authored
      
      [ Upstream commit dbc153fd3c142909e564bb256da087e13fbf239c ]
      
      A crash was found when dumping SMC-D connections. It can be reproduced
      by following steps:
      
      - run nginx/wrk test:
        smc_run nginx
        smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>
      
      - continuously dump SMC-D connections in parallel:
        watch -n 1 'smcss -D'
      
       BUG: kernel NULL pointer dereference, address: 0000000000000030
       CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G	E      6.7.0+ #55
       RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
       Call Trace:
        <TASK>
        ? __die+0x24/0x70
        ? page_fault_oops+0x66/0x150
        ? exc_page_fault+0x69/0x140
        ? asm_exc_page_fault+0x26/0x30
        ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
        ? __kmalloc_node_track_caller+0x35d/0x430
        ? __alloc_skb+0x77/0x170
        smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
        smc_diag_dump+0x26/0x60 [smc_diag]
        netlink_dump+0x19f/0x320
        __netlink_dump_start+0x1dc/0x300
        smc_diag_handler_dump+0x6a/0x80 [smc_diag]
        ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
        sock_diag_rcv_msg+0x121/0x140
        ? __pfx_sock_diag_rcv_msg+0x10/0x10
        netlink_rcv_skb+0x5a/0x110
        sock_diag_rcv+0x28/0x40
        netlink_unicast+0x22a/0x330
        netlink_sendmsg+0x1f8/0x420
        __sock_sendmsg+0xb0/0xc0
        ____sys_sendmsg+0x24e/0x300
        ? copy_msghdr_from_user+0x62/0x80
        ___sys_sendmsg+0x7c/0xd0
        ? __do_fault+0x34/0x160
        ? do_read_fault+0x5f/0x100
        ? do_fault+0xb0/0x110
        ? __handle_mm_fault+0x2b0/0x6c0
        __sys_sendmsg+0x4d/0x80
        do_syscall_64+0x69/0x180
        entry_SYSCALL_64_after_hwframe+0x6e/0x76
      
      It is possible that the connection is in process of being established
      when we dump it. Assumed that the connection has been registered in a
      link group by smc_conn_create() but the rmb_desc has not yet been
      initialized by smc_buf_create(), thus causing the illegal access to
      conn->rmb_desc. So fix it by checking before dump.
      
      Fixes: 4b1b7d3b ("net/smc: add SMC-D diag support")
      Signed-off-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Reviewed-by: default avatarDust Li <dust.li@linux.alibaba.com>
      Reviewed-by: default avatarWenjia Zhang <wenjia@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      27aea648
    • Mauro Carvalho Chehab's avatar
      drivers: core: fix kernel-doc markup for dev_err_probe() · 4d61ff79
      Mauro Carvalho Chehab authored
      
      commit 074b3aad307de6126fbac1fff4996d1034b48fee upstream.
      
      There are two literal blocks there. Fix the markups, in order
      to produce the right html output and solve those warnings:
      
      	./drivers/base/core.c:4218: WARNING: Unexpected indentation.
      	./drivers/base/core.c:4222: WARNING: Definition list ends without a blank line; unexpected unindent.
      	./drivers/base/core.c:4223: WARNING: Block quote ends without a blank line; unexpected unindent.
      
      Fixes: a787e5400a1c ("driver core: add device probe log helper")
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d61ff79
    • Michał Mirosław's avatar
      driver code: print symbolic error code · cf07cb79
      Michał Mirosław authored
      
      commit 693a8e936590f93451e6f5a3d748616f5a59c80b upstream.
      
      dev_err_probe() prepends the message with an error code. Let's make it
      more readable by translating the code to a more recognisable symbol.
      
      Fixes: a787e5400a1c ("driver core: add device probe log helper")
      Signed-off-by: default avatarMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Link: https://lore.kernel.org/r/ea3f973e4708919573026fdce52c264db147626d.1598630856.git.mirq-linux@rere.qmqm.pl
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf07cb79
    • Matthew Wilcox (Oracle)'s avatar
      block: Remove special-casing of compound pages · d2d0b95c
      Matthew Wilcox (Oracle) authored
      
      commit 1b151e24 upstream.
      
      The special casing was originally added in pre-git history; reproducing
      the commit log here:
      
      > commit a318a92567d77
      > Author: Andrew Morton <akpm@osdl.org>
      > Date:   Sun Sep 21 01:42:22 2003 -0700
      >
      >     [PATCH] Speed up direct-io hugetlbpage handling
      >
      >     This patch short-circuits all the direct-io page dirtying logic for
      >     higher-order pages.  Without this, we pointlessly bounce BIOs up to
      >     keventd all the time.
      
      In the last twenty years, compound pages have become used for more than
      just hugetlb.  Rewrite these functions to operate on folios instead
      of pages and remove the special case for hugetlbfs; I don't think
      it's needed any more (and if it is, we can put it back in as a call
      to folio_test_hugetlb()).
      
      This was found by inspection; as far as I can tell, this bug can lead
      to pages used as the destination of a direct I/O read not being marked
      as dirty.  If those pages are then reclaimed by the MM without being
      dirtied for some other reason, they won't be written out.  Then when
      they're faulted back in, they will not contain the data they should.
      It'll take a pretty unusual setup to produce this problem with several
      races all going the wrong way.
      
      This problem predates the folio work; it could for example have been
      triggered by mmaping a THP in tmpfs and using that as the target of an
      O_DIRECT read.
      
      Fixes: 800d8c63 ("shmem: add huge pages support")
      Cc:  <stable@vger.kernel.org>
      Signed-off-by: default avatarMatthew Wilcox (Oracle) <willy@infradead.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2d0b95c
    • Greg Kroah-Hartman's avatar
      Revert "driver core: Annotate dev_err_probe() with __must_check" · b715d543
      Greg Kroah-Hartman authored
      
      commit f601e8f3 upstream.
      
      This reverts commit e1f82a0d as it's
      already starting to cause build warnings in linux-next for things that
      are "obviously correct".
      
      It's up to driver authors do "do the right thing" here with this
      function, and if they don't want to call it as the last line of a
      function, that's up to them, otherwise code that looks like:
      	ret = dev_err_probe(..., ret, ...);
      does look really "odd".
      
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Reported-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Fixes: e1f82a0d ("driver core: Annotate dev_err_probe() with __must_check")
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b715d543
    • Dave Airlie's avatar
      nouveau/vmm: don't set addr on the fail path to avoid warning · 98fcd3b6
      Dave Airlie authored
      
      commit cacea81390fd8c8c85404e5eb2adeb83d87a912e upstream.
      
      nvif_vmm_put gets called if addr is set, but if the allocation
      fails we don't need to call put, otherwise we get a warning like
      
      [523232.435671] ------------[ cut here ]------------
      [523232.435674] WARNING: CPU: 8 PID: 1505697 at drivers/gpu/drm/nouveau/nvif/vmm.c:68 nvif_vmm_put+0x72/0x80 [nouveau]
      [523232.435795] Modules linked in: uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink qrtr bnep sunrpc binfmt_misc intel_rapl_msr intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common isst_if_common iwlmvm nfit libnvdimm vfat fat x86_pkg_temp_thermal intel_powerclamp mac80211 snd_soc_avs snd_soc_hda_codec coretemp snd_hda_ext_core snd_soc_core snd_hda_codec_realtek kvm_intel snd_hda_codec_hdmi snd_compress snd_hda_codec_generic ac97_bus snd_pcm_dmaengine snd_hda_intel libarc4 snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm iwlwifi snd_hda_core btusb snd_hwdep btrtl snd_seq btintel irqbypass btbcm rapl snd_seq_device eeepc_wmi btmtk intel_cstate iTCO_wdt cfg80211 snd_pcm asus_wmi bluetooth intel_pmc_bxt iTCO_vendor_support snd_timer ledtrig_audio pktcdvd snd mei_me
      [523232.435828]  sparse_keymap intel_uncore i2c_i801 platform_profile wmi_bmof mei pcspkr ioatdma soundcore i2c_smbus rfkill idma64 dca joydev acpi_tad loop zram nouveau drm_ttm_helper ttm video drm_exec drm_gpuvm gpu_sched crct10dif_pclmul i2c_algo_bit nvme crc32_pclmul crc32c_intel drm_display_helper polyval_clmulni nvme_core polyval_generic e1000e mxm_wmi cec ghash_clmulni_intel r8169 sha512_ssse3 nvme_common wmi pinctrl_sunrisepoint uas usb_storage ip6_tables ip_tables fuse
      [523232.435849] CPU: 8 PID: 1505697 Comm: gnome-shell Tainted: G        W          6.6.0-rc7-nvk-uapi+ #12
      [523232.435851] Hardware name: System manufacturer System Product Name/ROG STRIX X299-E GAMING II, BIOS 1301 09/24/2021
      [523232.435852] RIP: 0010:nvif_vmm_put+0x72/0x80 [nouveau]
      [523232.435934] Code: 00 00 48 89 e2 be 02 00 00 00 48 c7 04 24 00 00 00 00 48 89 44 24 08 e8 fc bf ff ff 85
      c0 75 0a 48 c7 43 08 00 00 00 00 eb b3 <0f> 0b eb f2 e8 f5 c9 b2 e6 0f 1f 44 00 00 90 90 90 90 90 90 90 90
      [523232.435936] RSP: 0018:ffffc900077ffbd8 EFLAGS: 00010282
      [523232.435937] RAX: 00000000fffffffe RBX: ffffc900077ffc00 RCX: 0000000000000010
      [523232.435938] RDX: 0000000000000010 RSI: ffffc900077ffb38 RDI: ffffc900077ffbd8
      [523232.435940] RBP: ffff888e1c4f2140 R08: 0000000000000000 R09: 0000000000000000
      [523232.435940] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888503811800
      [523232.435941] R13: ffffc900077ffca0 R14: ffff888e1c4f2140 R15: ffff88810317e1e0
      [523232.435942] FS:  00007f933a769640(0000) GS:ffff88905fa00000(0000) knlGS:0000000000000000
      [523232.435943] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [523232.435944] CR2: 00007f930bef7000 CR3: 00000005d0322001 CR4: 00000000003706e0
      [523232.435945] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [523232.435946] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [523232.435964] Call Trace:
      [523232.435965]  <TASK>
      [523232.435966]  ? nvif_vmm_put+0x72/0x80 [nouveau]
      [523232.436051]  ? __warn+0x81/0x130
      [523232.436055]  ? nvif_vmm_put+0x72/0x80 [nouveau]
      [523232.436138]  ? report_bug+0x171/0x1a0
      [523232.436142]  ? handle_bug+0x3c/0x80
      [523232.436144]  ? exc_invalid_op+0x17/0x70
      [523232.436145]  ? asm_exc_invalid_op+0x1a/0x20
      [523232.436149]  ? nvif_vmm_put+0x72/0x80 [nouveau]
      [523232.436230]  ? nvif_vmm_put+0x64/0x80 [nouveau]
      [523232.436342]  nouveau_vma_del+0x80/0xd0 [nouveau]
      [523232.436506]  nouveau_vma_new+0x1a0/0x210 [nouveau]
      [523232.436671]  nouveau_gem_object_open+0x1d0/0x1f0 [nouveau]
      [523232.436835]  drm_gem_handle_create_tail+0xd1/0x180
      [523232.436840]  drm_prime_fd_to_handle_ioctl+0x12e/0x200
      [523232.436844]  ? __pfx_drm_prime_fd_to_handle_ioctl+0x10/0x10
      [523232.436847]  drm_ioctl_kernel+0xd3/0x180
      [523232.436849]  drm_ioctl+0x26d/0x4b0
      [523232.436851]  ? __pfx_drm_prime_fd_to_handle_ioctl+0x10/0x10
      [523232.436855]  nouveau_drm_ioctl+0x5a/0xb0 [nouveau]
      [523232.437032]  __x64_sys_ioctl+0x94/0xd0
      [523232.437036]  do_syscall_64+0x5d/0x90
      [523232.437040]  ? syscall_exit_to_user_mode+0x2b/0x40
      [523232.437044]  ? do_syscall_64+0x6c/0x90
      [523232.437046]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      
      Reported-by: default avatarFaith Ekstrand <faith.ekstrand@collabora.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20240117213852.295565-1-airlied@gmail.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98fcd3b6
    • Andy Shevchenko's avatar
      driver core: Annotate dev_err_probe() with __must_check · d31978bf
      Andy Shevchenko authored
      
      commit e1f82a0dcf388d98bcc7ad195c03bd812405e6b2 upstream.
      
      We have got already new users of this API which interpret it differently
      and miss the opportunity to optimize their code.
      
      In order to avoid similar cases in the future, annotate dev_err_probe()
      with __must_check.
      
      Fixes: a787e5400a1c ("driver core: add device probe log helper")
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Link: https://lore.kernel.org/r/20200826104459.81979-1-andriy.shevchenko@linux.intel.com
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d31978bf
Loading