Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp317390pxb; Tue, 31 Aug 2021 22:49:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyV2tmeVaHRPL9bUIRS/bnu5f6X7TvTaQR/yJX19nGh9xkazMmSEWrCW62fOfjZfujzEqBj X-Received: by 2002:aa7:dace:: with SMTP id x14mr33182275eds.169.1630475381589; Tue, 31 Aug 2021 22:49:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630475381; cv=none; d=google.com; s=arc-20160816; b=B4ZeHDhZ9YS+vNWnoL//Yv+FZxhvufi2z9PjReM5924ad6pU8PSb4Zk7ULe/NZLd2O CYo4+Pf9qTJ824KnDd6/nOIGB9AcUk4gHKaC/63lhc6KVr41ABXH8429c233nA1J0T3w 7eTp49Riw49gBZ33/6XFdymZuy+99rZVWnWr7EIbqxzh9sFsSMbS2N2nSYJhJpTCQzy8 NhvXluDD7Jw6h80OkDBL1JhEvoMIskOtCGVzE+ZfWXeN2aTXfCHKrIaauvkOGlsRVWvC x7AqfdDOmrxmrwKfbEFY7Blxz4uI5YoI+9U1wyeOHO/CGsBlAwStWHWxhMGtsMnutMrH hJew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=hz/5VPxYP3pUOpwDxyj0G0/w05BnmhFnG1Uw6WPefH8=; b=bdpv80P73Cok1i7UNTVJB+U8KWkDJcr1i22nCiAS83DKjnjL+Bja6Ao51cfXftw+hl 4GQ0IuwFpX5G6XzqUfWOnIyRVg79ULXQnlQozsgBZkA6AQCLptw0AWfvjaJca5gXZMHi K0w51OUSy0DIBjXSIlIiet3znpLgRYU3p5NKGEicw8WIvSvQ7V+7hefGdXKRmMwu89y6 sI9tIqclkTa/jI2SPPaE8FmA8pV3iKXRHFQDkWbA3DgvAY9RVhcvE6+k1XZXSClnnlrp jdizMWcc/ho25flj9/X7N0YMJH3BcsJ/WPEaSYzrQh869UxgHJnw6UvtmCcBADZzb0Aq HRaA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k8si19549523ejk.222.2021.08.31.22.48.50; Tue, 31 Aug 2021 22:49:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242085AbhIAFpq convert rfc822-to-8bit (ORCPT + 99 others); Wed, 1 Sep 2021 01:45:46 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:53410 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242082AbhIAFpp (ORCPT ); Wed, 1 Sep 2021 01:45:45 -0400 Received: from smtpclient.apple (p5b3d2185.dip0.t-ipconnect.de [91.61.33.133]) by mail.holtmann.org (Postfix) with ESMTPSA id 89AAFCECED; Wed, 1 Sep 2021 07:44:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [PATCH 1/4] Bluetooth: Add bt_skb_sendmsg helper From: Marcel Holtmann In-Reply-To: <20210901002621.414016-1-luiz.dentz@gmail.com> Date: Wed, 1 Sep 2021 07:44:48 +0200 Cc: linux-bluetooth@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <9067109F-D8FD-47E9-AD02-FB6B7DFFDB3E@holtmann.org> References: <20210901002621.414016-1-luiz.dentz@gmail.com> To: Luiz Augusto von Dentz X-Mailer: Apple Mail (2.3654.120.0.1.13) Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Luiz, > bt_skb_sendmsg helps takes care of allocation the skb and copying the > the contents of msg over to the skb while checking for possible errors > so it should be safe to call it without holding lock_sock. > > Signed-off-by: Luiz Augusto von Dentz > --- > include/net/bluetooth/bluetooth.h | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h > index 9125effbf448..f858efcf9f40 100644 > --- a/include/net/bluetooth/bluetooth.h > +++ b/include/net/bluetooth/bluetooth.h > @@ -420,6 +420,32 @@ static inline struct sk_buff *bt_skb_send_alloc(struct sock *sk, > return NULL; > } > > +/* Shall not be called with lock_sock held */ > +static inline struct sk_buff *bt_skb_sendmsg(struct sock *sk, > + struct msghdr *msg, > + size_t len, size_t header, > + size_t footer) > +{ > + struct sk_buff *skb; > + int err; > + > + skb = bt_skb_send_alloc(sk, len + header + footer, > + msg->msg_flags & MSG_DONTWAIT, &err); > + if (!skb) > + return ERR_PTR(err); > + > + skb_reserve(skb, header); I am not with you on this one since bt_skb_send_alloc already calls skb_reserve in the first place. /** * skb_reserve - adjust headroom * @skb: buffer to alter * @len: bytes to move * * Increase the headroom of an empty &sk_buff by reducing the tail * room. This is only allowed for an empty buffer. */ In addition we have this comment here. So what kind of headroom do we need with this SKB? And wouldn’t it be better to actually assign a tailroom instead of just a large enough buffer? /** * skb_tailroom_reserve - adjust reserved_tailroom * @skb: buffer to alter * @mtu: maximum amount of headlen permitted * @needed_tailroom: minimum amount of reserved_tailroom * * Set reserved_tailroom so that headlen can be as large as possible but * not larger than mtu and tailroom cannot be smaller than * needed_tailroom. * The required headroom should already have been reserved before using * this function. */ We also have this capability inside the SKBs. So while the basic idea of this patchset seems fine, we need to figure out the details and not overload us in spaghetti code by wanting to have a common bt_skb_* helper. Maybe it is actually not helpful in this case since we just have to have a too large parameter list to satisfy all 3 users. Regards Marcel