lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 15 Dec 2022 14:36:52 +0000
From:   David Howells <>
To:     Guillaume Nault <>
cc:, Benjamin Coddington <>,
        Jakub Kicinski <>,
        Paolo Abeni <>,
        "David S. Miller" <>,
        Eric Dumazet <>,
        Philipp Reisner <>,
        Lars Ellenberg <>,
        Christoph Böhmwalder 
        <>, Jens Axboe <>,
        Josef Bacik <>,
        Keith Busch <>,
        Christoph Hellwig <>,
        Sagi Grimberg <>,
        Lee Duncan <>, Chris Leech <>,
        Mike Christie <>,
        "James E.J. Bottomley" <>,
        "Martin K. Petersen" <>,
        Valentina Manea <>,
        Shuah Khan <>,
        Greg Kroah-Hartman <>,
        Marc Dionne <>,
        Steve French <>,
        Christine Caulfield <>,
        David Teigland <>,
        Mark Fasheh <>,
        Joel Becker <>,
        Joseph Qi <>,
        Eric Van Hensbergen <>,
        Latchesar Ionkov <>,
        Dominique Martinet <>,
        Ilya Dryomov <>,
        Xiubo Li <>,
        Chuck Lever <>,
        Jeff Layton <>,
        Trond Myklebust <>,
        Anna Schumaker <>,
        Steffen Klassert <>,
        Herbert Xu <>,
Subject: Re: [PATCH net v3 2/3] Treewide: Stop corrupting socket's task_frag

Guillaume Nault <> wrote:

> Maybe setting sk_use_task_frag in fs/afs/rxrpc.c was overzealous but
> I'm not familiar enough with the AF_RXRPC family to tell. If AF_RXRPC
> sockets can't call sk_page_frag() and have no reason to do so in the
> future, then it should be safe to drop this chunk.

As of this merge window, AF_RXRPC doesn't actually allocate sk_buffs apart
from when it calls skb_unshare().  It does steal the incoming sk_buffs from
the UDP socket it uses as a transport, but they're allocated in the IP/IP6
stack somewhere.

The UDP transport socket, on the other hand, will allocate sk_buffs for
transmission, but rxrpc sends an entire UDP packet at a time, each with a
single sendmsg call.

Further, this mostly now moved such that the UDP sendmsg calls are performed
inside an I/O thread.  The application thread does not interact directly with
the UDP transport socket.


Powered by blists - more mailing lists