Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1693141pxb; Mon, 22 Feb 2021 08:34:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJw2Mh+E+NedMEpWZBniFBWiTfFuWqcHm4ng3GhrHgdRHfGw0p4AxLK6GwodUtEYIRGZ5+Is X-Received: by 2002:a05:6402:1453:: with SMTP id d19mr1549318edx.59.1614011655308; Mon, 22 Feb 2021 08:34:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614011655; cv=none; d=google.com; s=arc-20160816; b=NmjK279FYk8+15rQiPEoS/mYQ0frAqMyMxpFFq9RACAChKcM3f5Xc2HUE5e9LZErvU Q62pmu8ZJQkBIh7jNXcbC2Nzrs87PrMiEVoRRmUl+lKw2BufJfnv4vFWfNlXtzbpA6nC Ycbe2l6HAJR/zi7s12r6eFfv6hxVnKxDoAoXE5JRwQlL6usaiNgK544akkyRlbWbD210 DLK9mvJHzfztLNWqLwThDBgLI4+7lkCMz34p/Zyf88525eNWKdy9Rwm0TiK5uu6roy9J 0OG2LwCyXW5bOHtgPduklUYVQsUmPkxGj03/hsQejqR1Qvozdu2hJlQvi+bLdVBLkK5P yH7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=it/5mLgPFgWhUhmslZc7vqJpzzZZCr/QWMw633oh2pE=; b=dBmOcd1hvlrUOYQseVIeyMVzEH5vtTV0Cxf3KsUb+4GDm3Cjrsd+fFKYoKkR9dia6/ h+ZVsVW7T1ofSL0PUK/JlVc56fdoRp7TtjWd4zxAUEOIgfL9T43jnGKW6Hf+3pGZpYnR hTdYfFP9T3ZKQ/kVqA76bo3lg3UUcbf8tpZQufMIYPtZn62WvcS2kxWYqVWMS1J6aEeg RBULT8RQt+K815KlevgOmAId/VZ8K42asle7qNtMt9zzxUnCcyE2h8a+tpLZFRiPCxZ2 KJX6iee43DuWY23qtJezaWcP5B7+faFP2NfAIkjxkOJ2egnol60NBLSSFg8cXdt8o5PJ hD6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-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 ec1si12353537ejb.598.2021.02.22.08.33.50; Mon, 22 Feb 2021 08:34:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-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-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230223AbhBVQdZ (ORCPT + 99 others); Mon, 22 Feb 2021 11:33:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231577AbhBVQcs (ORCPT ); Mon, 22 Feb 2021 11:32:48 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5AFBC061794; Mon, 22 Feb 2021 08:31:29 -0800 (PST) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1lEE7A-006xZ6-IT; Mon, 22 Feb 2021 17:31:16 +0100 Message-ID: <3823be537c3c138de90154835573113c6577188e.camel@sipsolutions.net> Subject: Re: [PATCH net v1 3/3] [RFC] mac80211: ieee80211_store_ack_skb(): make use of skb_clone_sk_optional() From: Johannes Berg To: Oleksij Rempel , mkl@pengutronix.de, "David S. Miller" , Jakub Kicinski , Oliver Hartkopp , Robin van der Gracht Cc: kernel@pengutronix.de, linux-can@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Dumazet , linux-wireless@vger.kernel.org Date: Mon, 22 Feb 2021 17:30:59 +0100 In-Reply-To: <20210222151247.24534-4-o.rempel@pengutronix.de> References: <20210222151247.24534-1-o.rempel@pengutronix.de> <20210222151247.24534-4-o.rempel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 2021-02-22 at 16:12 +0100, Oleksij Rempel wrote: > This code is trying to clone the skb with optional skb->sk. But this > will fail to clone the skb if socket was closed just after the skb was > pushed into the networking stack. Which IMHO is completely fine. If we then still clone the SKB we can't do anything with it, since the point would be to ... send it back to the socket, but it's gone. Nothing to fix here, I'd think. If you wanted to get a copy back that gives you the status of the SKB, it should not come as a huge surprise that you have to keep the socket open for that :) Having the ACK skb will just make us do more work by handing it back to skb_complete_wifi_ack() at TX status time, which is supposed to put it into the socket's error queue, but if the socket is closed ... no point in that. johannes