From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40470C7EE23 for ; Fri, 26 May 2023 08:49:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242797AbjEZItX (ORCPT ); Fri, 26 May 2023 04:49:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242614AbjEZItT (ORCPT ); Fri, 26 May 2023 04:49:19 -0400 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA92F119; Fri, 26 May 2023 01:49:17 -0700 (PDT) Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-307d20548adso248866f8f.0; Fri, 26 May 2023 01:49:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685090956; x=1687682956; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=s4Sjrbm6d6EO6iQQ0zbM7JAHxdD9NnQEGIWbfdTn3q4=; b=kxgIC8qndyOU6bBu/akOD1HMJGDqlMOtFDUf9zvh9AZM9TVABXXL2+0tIWkKt1fxyZ lYBNooGA0eF5O+l3Y313YWx2f9JM/z1+M3/+BAOwy46EPzp+vNfqwKIFGEPTxFCNiYdB V63mS88EBcXZoC559mhAnRlbvF9zfyyJbWLH5CJxxTJDNseyi1SywddrokGGl2sOaIpK B9AxRL4cWMsxLCspdWxK1/W8ywpbyySVuCQ/MWxfU8sJ8s7y2yVlvEqGCOiUlXFSqW0q BGc+byNO39HcbPKooV6WoeFT4ce1FiJtKzTBcRktMx0J/76CTdZ1MRsggBcs8Dy5/R+L zM3A== X-Gm-Message-State: AC+VfDyi1IZP6u9nGOoA+9q+CAm6cs09BP3rP28LtSSyvYrruXB0Jbpe 2k2DXZ+hGkwWlFlLtflJOhk= X-Google-Smtp-Source: ACHHUZ7zycneQMT5MV6N2pE69nG7qYgQwCpYDyX2JqqJ+e0B9ZF6lJoMXa9DIxgrYpSDUMuFvhezxA== X-Received: by 2002:a05:6000:196b:b0:30a:b4e1:a89b with SMTP id da11-20020a056000196b00b0030ab4e1a89bmr731849wrb.67.1685090956051; Fri, 26 May 2023 01:49:16 -0700 (PDT) Received: from gmail.com (fwdproxy-cln-005.fbsv.net. [2a03:2880:31ff:5::face:b00c]) by smtp.gmail.com with ESMTPSA id y3-20020a5d4703000000b002f103ca90cdsm4338479wrq.101.2023.05.26.01.49.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 May 2023 01:49:15 -0700 (PDT) Date: Fri, 26 May 2023 01:49:10 -0700 From: Breno Leitao To: Willem de Bruijn Cc: dsahern@kernel.org, Remi Denis-Courmont , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexander Aring , Stefan Schmidt , Miquel Raynal , Matthieu Baerts , Mat Martineau , Marcelo Ricardo Leitner , Xin Long , leit@fb.com, axboe@kernel.dk, asml.silence@gmail.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, dccp@vger.kernel.org, linux-wpan@vger.kernel.org, mptcp@lists.linux.dev, linux-sctp@vger.kernel.org Subject: Re: [PATCH net-next v3] net: ioctl: Use kernel memory on protocol ioctl callbacks Message-ID: References: <20230525125503.400797-1-leitao@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 25, 2023 at 11:05:40AM -0400, Willem de Bruijn wrote: > On Thu, May 25, 2023 at 8:55 AM Breno Leitao wrote: > > @@ -1547,6 +1547,28 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, sockptr_t optval, > > return ret; > > } > > > > +/* Execute if this ioctl is a special mroute ioctl */ > > +int ipmr_sk_ioctl(struct sock *sk, unsigned int cmd, void __user *arg) > > +{ > > + switch (cmd) { > > + /* These userspace buffers will be consumed by ipmr_ioctl() */ > > + case SIOCGETVIFCNT: { > > + struct sioc_vif_req buffer; > > + > > + return sock_ioctl_inout(sk, cmd, arg, &buffer, > > + sizeof(buffer)); > > + } > > More importantly, if we go down the path of demultiplexing in protocol > independent code to call protocol specific handlers, then there there > is no need to have them call protocol independent helpers like > sock_ioct_inout again. Just call the protocol-specific ioctl handlers > directly? That is what I was expecting, but, the code is exactly the same and I kept it in the generic section. This is what this code needs to do: * Copy X byte from userspace * sk->sk_prot->ioctl() * Copy X bytes back to userspace I tried to keep the code generic enough that it could be reused. I can definitely push the same code to two different protocols, if you prefer, no strong opinion.