netdev - Re: [PATCH net-next v2 11/12] net: homa: create homa_plumbing.c homa

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 for Android: free password hash cracker in your pocket

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

Message-ID: <b4bf68f1-189c-4685-8e1a-d8cbf60c1120@linux.alibaba.com>
Date: Mon, 9 Dec 2024 14:56:43 +0800
From: "D. Wythe" <alibuda@...ux.alibaba.com>
To: John Ousterhout <ouster@...stanford.edu>
Cc: netdev@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH net-next v2 11/12] net: homa: create homa_plumbing.c
 homa_utils.c



On 12/6/24 3:49 AM, John Ousterhout wrote:
> On Sun, Dec 1, 2024 at 7:51 PM D. Wythe <alibuda@...ux.alibaba.com> wrote:
>>> +int homa_setsockopt(struct sock *sk, int level, int optname, sockptr_t optval,
>>> +                 unsigned int optlen)
>>> +{
>>> +     struct homa_sock *hsk = homa_sk(sk);
>>> +     struct homa_set_buf_args args;
>>> +     int ret;
>>> +
>>> +     if (level != IPPROTO_HOMA || optname != SO_HOMA_SET_BUF ||
>>> +         optlen != sizeof(struct homa_set_buf_args))
>>> +             return -EINVAL;
>>
>> SO_HOMA_SET_BUF is a bit odd here, maybe HOMA_RCVBUF ? which also can be
>> implemented in getsockopt.
> 
> I have changed it to HOMA_RCVBUF (and renamed struct homa_set_buf_args
> to struct homa_rcvbuf_args). I also implemented getsockopt for
> HOMA_RCVBUF.
> 
>>> +
>>> +     if (copy_from_sockptr(&args, optval, optlen))
>>> +             return -EFAULT;
>>> +
>>> +     /* Do a trivial test to make sure we can at least write the first
>>> +      * page of the region.
>>> +      */
>>> +     if (copy_to_user((__force void __user *)args.start, &args, sizeof(args)))
>>> +             return -EFAULT;
>>
>> To share buffer between kernel and userspace, maybe you should refer to the implementation of
>> io_pin_pbuf_ring()
> 
> I'm not sure what you mean here. Are you suggesting that I look at the
> code of io_pin_pbuf_ring to make sure I've done everything needed to
> share buffers? I don't believe that Homa needs to do anything special
> (e.g. it doesn't need to pin the user's buffers); it just saves the
> address and makes copy_to_user calls later when needed (and these
> calls are all done at syscall level in the context of the
> application). Is there something I'm missing?
> 

I just thought that since the received buffer is shared between kernel and user-space, if using 
vmap() to map the very memory, so that we don't need to use such "copy_to_user" to transfer the data 
from kernel to user-space, we can use memcpy() instead. This shall be more faster, but I had no 
relevant data to prove it..

So I'm not going to insist on it, it ups to you.

D. Wythe