1. 05 May, 2023 8 commits
    • Vlad Buslov's avatar
      net/sched: flower: fix filter idr initialization · dd4f6bbf
      Vlad Buslov authored
      The cited commit moved idr initialization too early in fl_change() which
      allows concurrent users to access the filter that is still being
      initialized and is in inconsistent state, which, in turn, can cause NULL
      pointer dereference [0]. Since there is no obvious way to fix the ordering
      without reverting the whole cited commit, alternative approach taken to
      first insert NULL pointer into idr in order to allocate the handle but
      still cause fl_get() to return NULL and prevent concurrent users from
      seeing the filter while providing miss-to-action infrastructure with valid
      handle id early in fl_change().
      
      [  152.434728] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN
      [  152.436163] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
      [  152.437269] CPU: 4 PID: 3877 Comm: tc Not tainted 6.3.0-rc4+ #5
      [  152.438110] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      [  152.439644] RIP: 0010:fl_dump_key+0x8b/0x1d10 [cls_flower]
      [  152.440461] Code: 01 f2 02 f2 c7 40 08 04 f2 04 f2 c7 40 0c 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 00 01 00 00 48 89 c8 48 c1 e8 03 <0f> b6 04 10 84 c0 74 08 3c 03 0f 8e 98 19 00 00 8b 13 85 d2 74 57
      [  152.442885] RSP: 0018:ffff88817a28f158 EFLAGS: 00010246
      [  152.443851] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [  152.444826] RDX: dffffc0000000000 RSI: ffffffff8500ae80 RDI: ffff88810a987900
      [  152.445791] RBP: ffff888179d88240 R08: ffff888179d8845c R09: ffff888179d88240
      [  152.446780] R10: ffffed102f451e48 R11: 00000000fffffff2 R12: ffff88810a987900
      [  152.447741] R13: ffffffff8500ae80 R14: ffff88810a987900 R15: ffff888149b3c738
      [  152.448756] FS:  00007f5eb2a34800(0000) GS:ffff88881ec00000(0000) knlGS:0000000000000000
      [  152.449888] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  152.450685] CR2: 000000000046ad19 CR3: 000000010b0bd006 CR4: 0000000000370ea0
      [  152.451641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  152.452628] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  152.453588] Call Trace:
      [  152.454032]  <TASK>
      [  152.454447]  ? netlink_sendmsg+0x7a1/0xcb0
      [  152.455109]  ? sock_sendmsg+0xc5/0x190
      [  152.455689]  ? ____sys_sendmsg+0x535/0x6b0
      [  152.456320]  ? ___sys_sendmsg+0xeb/0x170
      [  152.456916]  ? do_syscall_64+0x3d/0x90
      [  152.457529]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
      [  152.458321]  ? ___sys_sendmsg+0xeb/0x170
      [  152.458958]  ? __sys_sendmsg+0xb5/0x140
      [  152.459564]  ? do_syscall_64+0x3d/0x90
      [  152.460122]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
      [  152.460852]  ? fl_dump_key_options.part.0+0xea0/0xea0 [cls_flower]
      [  152.461710]  ? _raw_spin_lock+0x7a/0xd0
      [  152.462299]  ? _raw_read_lock_irq+0x30/0x30
      [  152.462924]  ? nla_put+0x15e/0x1c0
      [  152.463480]  fl_dump+0x228/0x650 [cls_flower]
      [  152.464112]  ? fl_tmplt_dump+0x210/0x210 [cls_flower]
      [  152.464854]  ? __kmem_cache_alloc_node+0x1a7/0x330
      [  152.465592]  ? nla_put+0x15e/0x1c0
      [  152.466160]  tcf_fill_node+0x515/0x9a0
      [  152.466766]  ? tc_setup_offload_action+0xf0/0xf0
      [  152.467463]  ? __alloc_skb+0x13c/0x2a0
      [  152.468067]  ? __build_skb_around+0x330/0x330
      [  152.468814]  ? fl_get+0x107/0x1a0 [cls_flower]
      [  152.469503]  tc_del_tfilter+0x718/0x1330
      [  152.470115]  ? is_bpf_text_address+0xa/0x20
      [  152.470765]  ? tc_ctl_chain+0xee0/0xee0
      [  152.471335]  ? __kernel_text_address+0xe/0x30
      [  152.471948]  ? unwind_get_return_address+0x56/0xa0
      [  152.472639]  ? __thaw_task+0x150/0x150
      [  152.473218]  ? arch_stack_walk+0x98/0xf0
      [  152.473839]  ? __stack_depot_save+0x35/0x4c0
      [  152.474501]  ? stack_trace_save+0x91/0xc0
      [  152.475119]  ? security_capable+0x51/0x90
      [  152.475741]  rtnetlink_rcv_msg+0x2c1/0x9d0
      [  152.476387]  ? rtnl_calcit.isra.0+0x2b0/0x2b0
      [  152.477042]  ? __sys_sendmsg+0xb5/0x140
      [  152.477664]  ? do_syscall_64+0x3d/0x90
      [  152.478255]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
      [  152.479010]  ? __stack_depot_save+0x35/0x4c0
      [  152.479679]  ? __stack_depot_save+0x35/0x4c0
      [  152.480346]  netlink_rcv_skb+0x12c/0x360
      [  152.480929]  ? rtnl_calcit.isra.0+0x2b0/0x2b0
      [  152.481517]  ? do_syscall_64+0x3d/0x90
      [  152.482061]  ? netlink_ack+0x1550/0x1550
      [  152.482612]  ? rhashtable_walk_peek+0x170/0x170
      [  152.483262]  ? kmem_cache_alloc_node+0x1af/0x390
      [  152.483875]  ? _copy_from_iter+0x3d6/0xc70
      [  152.484528]  netlink_unicast+0x553/0x790
      [  152.485168]  ? netlink_attachskb+0x6a0/0x6a0
      [  152.485848]  ? unwind_next_frame+0x11cc/0x1a10
      [  152.486538]  ? arch_stack_walk+0x61/0xf0
      [  152.487169]  netlink_sendmsg+0x7a1/0xcb0
      [  152.487799]  ? netlink_unicast+0x790/0x790
      [  152.488355]  ? iovec_from_user.part.0+0x4d/0x220
      [  152.488990]  ? _raw_spin_lock+0x7a/0xd0
      [  152.489598]  ? netlink_unicast+0x790/0x790
      [  152.490236]  sock_sendmsg+0xc5/0x190
      [  152.490796]  ____sys_sendmsg+0x535/0x6b0
      [  152.491394]  ? import_iovec+0x7/0x10
      [  152.491964]  ? kernel_sendmsg+0x30/0x30
      [  152.492561]  ? __copy_msghdr+0x3c0/0x3c0
      [  152.493160]  ? do_syscall_64+0x3d/0x90
      [  152.493706]  ___sys_sendmsg+0xeb/0x170
      [  152.494283]  ? may_open_dev+0xd0/0xd0
      [  152.494858]  ? copy_msghdr_from_user+0x110/0x110
      [  152.495541]  ? __handle_mm_fault+0x2678/0x4ad0
      [  152.496205]  ? copy_page_range+0x2360/0x2360
      [  152.496862]  ? __fget_light+0x57/0x520
      [  152.497449]  ? mas_find+0x1c0/0x1c0
      [  152.498026]  ? sockfd_lookup_light+0x1a/0x140
      [  152.498703]  __sys_sendmsg+0xb5/0x140
      [  152.499306]  ? __sys_sendmsg_sock+0x20/0x20
      [  152.499951]  ? do_user_addr_fault+0x369/0xd80
      [  152.500595]  do_syscall_64+0x3d/0x90
      [  152.501185]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
      [  152.501917] RIP: 0033:0x7f5eb294f887
      [  152.502494] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
      [  152.505008] RSP: 002b:00007ffd2c708f78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      [  152.506152] RAX: ffffffffffffffda RBX: 00000000642d9472 RCX: 00007f5eb294f887
      [  152.507134] RDX: 0000000000000000 RSI: 00007ffd2c708fe0 RDI: 0000000000000003
      [  152.508113] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
      [  152.509119] R10: 00007f5eb2808708 R11: 0000000000000246 R12: 0000000000000001
      [  152.510068] R13: 0000000000000000 R14: 00007ffd2c70d1b8 R15: 0000000000485400
      [  152.511031]  </TASK>
      [  152.511444] Modules linked in: cls_flower sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay zram zsmalloc fuse [last unloaded: mlx5_core]
      [  152.515720] ---[ end trace 0000000000000000 ]---
      
      Fixes: 08a0063d ("net/sched: flower: Move filter handle initialization earlier")
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarPedro Tammela <pctammela@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dd4f6bbf
    • Shenwei Wang's avatar
      net: fec: correct the counting of XDP sent frames · 26312c68
      Shenwei Wang authored
      In the current xdp_xmit implementation, if any single frame fails to
      transmit due to insufficient buffer descriptors, the function nevertheless
      reports success in sending all frames. This results in erroneously
      indicating that frames were transmitted when in fact they were dropped.
      
      This patch fixes the issue by ensureing the return value properly
      indicates the actual number of frames successfully transmitted, rather than
      potentially reporting success for all frames when some could not transmit.
      
      Fixes: 6d6b39f1 ("net: fec: add initial XDP support")
      Signed-off-by: default avatarGagandeep Singh <g.singh@nxp.com>
      Signed-off-by: default avatarShenwei Wang <shenwei.wang@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26312c68
    • Wei Fang's avatar
      net: enetc: check the index of the SFI rather than the handle · 299efdc2
      Wei Fang authored
      We should check whether the current SFI (Stream Filter Instance) table
      is full before creating a new SFI entry. However, the previous logic
      checks the handle by mistake and might lead to unpredictable behavior.
      
      Fixes: 888ae5a3 ("net: enetc: add tc flower psfp offload driver")
      Signed-off-by: default avatarWei Fang <wei.fang@nxp.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      299efdc2
    • Martin Habets's avatar
      sfc: Add back mailing list · c00ce547
      Martin Habets authored
      We used to have a mailing list in the MAINTAINERS file, but removed this
      when we became part of Xilinx as it stopped working.
      Now inside AMD we have the list again. Add it back so patches will be seen
      by all sfc developers.
      Signed-off-by: default avatarMartin Habets <habetsm.xilinx@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c00ce547
    • Wenliang Wang's avatar
      virtio_net: suppress cpu stall when free_unused_bufs · f8bb5104
      Wenliang Wang authored
      For multi-queue and large ring-size use case, the following error
      occurred when free_unused_bufs:
      rcu: INFO: rcu_sched self-detected stall on CPU.
      
      Fixes: 986a4f4d ("virtio_net: multiqueue support")
      Signed-off-by: default avatarWenliang Wang <wangwenliang.1995@bytedance.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f8bb5104
    • Michal Swiatkowski's avatar
      ice: block LAN in case of VF to VF offload · 9f699b71
      Michal Swiatkowski authored
      VF to VF traffic shouldn't go outside. To enforce it, set only the loopback
      enable bit in case of all ingress type rules added via the tc tool.
      
      Fixes: 0d08a441 ("ice: ndo_setup_tc implementation for PF")
      Reported-by: default avatarSujai Buvaneswaran <Sujai.Buvaneswaran@intel.com>
      Signed-off-by: default avatarMichal Swiatkowski <michal.swiatkowski@linux.intel.com>
      Tested-by: default avatarGeorge Kuruvinakunnel <george.kuruvinakunnel@intel.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f699b71
    • Arınç ÜNAL's avatar
      net: dsa: mt7530: fix network connectivity with multiple CPU ports · 120a56b0
      Arınç ÜNAL authored
      On mt753x_cpu_port_enable() there's code that enables flooding for the CPU
      port only. Since mt753x_cpu_port_enable() runs twice when both CPU ports
      are enabled, port 6 becomes the only port to forward the frames to. But
      port 5 is the active port, so no frames received from the user ports will
      be forwarded to port 5 which breaks network connectivity.
      
      Every bit of the BC_FFP, UNM_FFP, and UNU_FFP bits represents a port. Fix
      this issue by setting the bit that corresponds to the CPU port without
      overwriting the other bits.
      
      Clear the bits beforehand only for the MT7531 switch. According to the
      documents MT7621 Giga Switch Programming Guide v0.3 and MT7531 Reference
      Manual for Development Board v1.0, after reset, the BC_FFP, UNM_FFP, and
      UNU_FFP bits are set to 1 for MT7531, 0 for MT7530.
      
      The commit 5e5502e0 ("net: dsa: mt7530: fix roaming from DSA user
      ports") silently changed the method to set the bits on the MT7530_MFC.
      Instead of clearing the relevant bits before mt7530_cpu_port_enable()
      which runs under a for loop, the commit started doing it on
      mt7530_cpu_port_enable().
      
      Back then, this didn't really matter as only a single CPU port could be
      used since the CPU port number was hardcoded. The driver was later changed
      with commit 1f9a6abe ("net: dsa: mt7530: get cpu-port via dp->cpu_dp
      instead of constant") to retrieve the CPU port via dp->cpu_dp. With that,
      this silent change became an issue for when using multiple CPU ports.
      
      Fixes: 5e5502e0 ("net: dsa: mt7530: fix roaming from DSA user ports")
      Signed-off-by: default avatarArınç ÜNAL <arinc.unal@arinc9.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      120a56b0
    • Arınç ÜNAL's avatar
      net: dsa: mt7530: fix corrupt frames using trgmii on 40 MHz XTAL MT7621 · 37c218d8
      Arınç ÜNAL authored
      The multi-chip module MT7530 switch with a 40 MHz oscillator on the
      MT7621AT, MT7621DAT, and MT7621ST SoCs forwards corrupt frames using
      trgmii.
      
      This is caused by the assumption that MT7621 SoCs have got 150 MHz PLL,
      hence using the ncpo1 value, 0x0780.
      
      My testing shows this value works on Unielec U7621-06, Bartel's testing
      shows it won't work on Hi-Link HLK-MT7621A and Netgear WAC104. All devices
      tested have got 40 MHz oscillators.
      
      Using the value for 125 MHz PLL, 0x0640, works on all boards at hand. The
      definitions for 125 MHz PLL exist on the Banana Pi BPI-R2 BSP source code
      whilst 150 MHz PLL don't.
      
      Forwarding frames using trgmii on the MCM MT7530 switch with a 25 MHz
      oscillator on the said MT7621 SoCs works fine because the ncpo1 value
      defined for it is for 125 MHz PLL.
      
      Change the 150 MHz PLL comment to 125 MHz PLL, and use the 125 MHz PLL
      ncpo1 values for both oscillator frequencies.
      
      Link: https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/81d24bbce7d99524d0771a8bdb2d6663e4eb4faa/u-boot-mt/drivers/net/rt2880_eth.c#L2195
      Fixes: 7ef6f6f8 ("net: dsa: mt7530: Add MT7621 TRGMII mode support")
      Tested-by: default avatarBartel Eerdekens <bartel.eerdekens@constell8.be>
      Signed-off-by: default avatarArınç ÜNAL <arinc.unal@arinc9.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37c218d8
  2. 04 May, 2023 1 commit
  3. 03 May, 2023 26 commits
  4. 01 May, 2023 5 commits
    • David S. Miller's avatar
      Merge branch 'rxrpc-timeout-fixes' · fb7cba61
      David S. Miller authored
      David Howells says:
      
      ====================
      rxrpc: Timeout handling fixes
      
      Here are three patches to fix timeouts handling in AF_RXRPC:
      
       (1) The hard call timeout should be interpreted in seconds, not
           milliseconds.
      
       (2) Allow a waiting call to be aborted (thereby cancelling the call) in
           the case a signal interrupts sendmsg() and leaves it hanging until it
           is granted a channel on a connection.
      
       (3) Kernel-generated calls get the timer started on them even if they're
           still waiting to be attached to a connection.  If the timer expires
           before the wait is complete and a conn is attached, an oops will
           occur.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb7cba61
    • David Howells's avatar
      rxrpc: Fix timeout of a call that hasn't yet been granted a channel · db099c62
      David Howells authored
      afs_make_call() calls rxrpc_kernel_begin_call() to begin a call (which may
      get stalled in the background waiting for a connection to become
      available); it then calls rxrpc_kernel_set_max_life() to set the timeouts -
      but that starts the call timer so the call timer might then expire before
      we get a connection assigned - leading to the following oops if the call
      stalled:
      
      	BUG: kernel NULL pointer dereference, address: 0000000000000000
      	...
      	CPU: 1 PID: 5111 Comm: krxrpcio/0 Not tainted 6.3.0-rc7-build3+ #701
      	RIP: 0010:rxrpc_alloc_txbuf+0xc0/0x157
      	...
      	Call Trace:
      	 <TASK>
      	 rxrpc_send_ACK+0x50/0x13b
      	 rxrpc_input_call_event+0x16a/0x67d
      	 rxrpc_io_thread+0x1b6/0x45f
      	 ? _raw_spin_unlock_irqrestore+0x1f/0x35
      	 ? rxrpc_input_packet+0x519/0x519
      	 kthread+0xe7/0xef
      	 ? kthread_complete_and_exit+0x1b/0x1b
      	 ret_from_fork+0x22/0x30
      
      Fix this by noting the timeouts in struct rxrpc_call when the call is
      created.  The timer will be started when the first packet is transmitted.
      
      It shouldn't be possible to trigger this directly from userspace through
      AF_RXRPC as sendmsg() will return EBUSY if the call is in the
      waiting-for-conn state if it dropped out of the wait due to a signal.
      
      Fixes: 9d35d880 ("rxrpc: Move client call connection to the I/O thread")
      Reported-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: "David S. Miller" <davem@davemloft.net>
      cc: Eric Dumazet <edumazet@google.com>
      cc: Jakub Kicinski <kuba@kernel.org>
      cc: Paolo Abeni <pabeni@redhat.com>
      cc: linux-afs@lists.infradead.org
      cc: netdev@vger.kernel.org
      cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db099c62
    • David Howells's avatar
      rxrpc: Make it so that a waiting process can be aborted · 0eb362d2
      David Howells authored
      When sendmsg() creates an rxrpc call, it queues it to wait for a connection
      and channel to be assigned and then waits before it can start shovelling
      data as the encrypted DATA packet content includes a summary of the
      connection parameters.
      
      However, sendmsg() may get interrupted before a connection gets assigned
      and further sendmsg() calls will fail with EBUSY until an assignment is
      made.
      
      Fix this so that the call can at least be aborted without failing on
      EBUSY.  We have to be careful here as sendmsg() mustn't be allowed to start
      the call timer if the call doesn't yet have a connection assigned as an
      oops may follow shortly thereafter.
      
      Fixes: 540b1c48 ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
      Reported-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: "David S. Miller" <davem@davemloft.net>
      cc: Eric Dumazet <edumazet@google.com>
      cc: Jakub Kicinski <kuba@kernel.org>
      cc: Paolo Abeni <pabeni@redhat.com>
      cc: linux-afs@lists.infradead.org
      cc: netdev@vger.kernel.org
      cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0eb362d2
    • David Howells's avatar
      rxrpc: Fix hard call timeout units · 0d098d83
      David Howells authored
      The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
      seconds, so fix the point at which sendmsg() applies it to the call to
      convert to jiffies from seconds, not milliseconds.
      
      Fixes: a158bdd3 ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: "David S. Miller" <davem@davemloft.net>
      cc: Eric Dumazet <edumazet@google.com>
      cc: Jakub Kicinski <kuba@kernel.org>
      cc: Paolo Abeni <pabeni@redhat.com>
      cc: linux-afs@lists.infradead.org
      cc: netdev@vger.kernel.org
      cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d098d83
    • Tom Rix's avatar
      net: atlantic: Define aq_pm_ops conditionally on CONFIG_PM · 4f163bf8
      Tom Rix authored
      For s390, gcc with W=1 reports
      drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c:458:32: error:
        'aq_pm_ops' defined but not used [-Werror=unused-const-variable=]
        458 | static const struct dev_pm_ops aq_pm_ops = {
            |                                ^~~~~~~~~
      
      The only use of aq_pm_ops is conditional on CONFIG_PM.
      The definition of aq_pm_ops and its functions should also
      be conditional on CONFIG_PM.
      Signed-off-by: default avatarTom Rix <trix@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4f163bf8