netdev - Re: [PATCH net-next 2/7] rds: hold a sock ref from rds_message to the rds

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 28 Jan 2018 19:54:58 +0100
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>, rds-devel@....oracle.com,
        santosh.shilimkar@...cle.com
Subject: Re: [PATCH net-next 2/7] rds: hold a sock ref from rds_message to the rds_sock

On Sun, Jan 28, 2018 at 5:18 PM, Sowmini Varadhan
<sowmini.varadhan@...cle.com> wrote:
> On (01/28/18 14:51), Willem de Bruijn wrote:
>> > On (01/25/18 15:44), Willem de Bruijn wrote:
>      ;
>> >> You may alos be able to do the same as tcp zerocopy and
>> >> hold an sk reference on the notification skb.
>      ;
>> I don't quite follow. Every notification skb is created when pages refcount
>> is increased. It persists until at least rds_rm_zerocopy_callback, after data
>> skb has been freed and pages refcount has been decreased.
>>
>> In this callback, skb is consumed if another skb is already queued on
>> the error queue, otherwise it is queued itself. It needs to hold a sock ref
>> until it can be queued.
>
> maybe I did not follow the original suggestion- were you
> suggesting that I hold a pointer to the sk from e.g., the skb->cb
> itself?

Yes, I mean associating the notification skb that is eventually
queued onto the error queue with the socket. For tcp zerocopy,
this happens implicitly in sock_omalloc.

> I dont know that it would make things simpler,
> whereas having the pointer and refcount in the rds_message itself,
> and track this independantly of whether/not zcopy was used, seems
> like a more consistent dsta-structure model, so I'd like to leave
> this as is.

Sounds good. You know the rds internals a lot better than I do,
so are the better judge on whether to choose that or sock_omalloc.