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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0555BC43460 for ; Tue, 20 Apr 2021 08:10:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C9CCF610CC for ; Tue, 20 Apr 2021 08:10:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229834AbhDTILF (ORCPT ); Tue, 20 Apr 2021 04:11:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229736AbhDTILF (ORCPT ); Tue, 20 Apr 2021 04:11:05 -0400 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A83AC06138B for ; Tue, 20 Apr 2021 01:10:33 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id u21so56921574ejo.13 for ; Tue, 20 Apr 2021 01:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FG5E8uWGSrCvajWCjQUTriiKHPgt6q+O5wn0TlE95pQ=; b=zCCqheyR986/BDJiX2v51ephpReLZP0aCw2199pReb60w50j/aQo+xHHfXXUBXXydW 1iPjmITiaWa8banzSpUECuDdbVOiI4NKC9wnSLuBbE/YC5846UJY1XwLTipBgGV/fZlh aeu7T47FtiIPMNezvjA8OW4GOsvVFAnqOuyar1inVAZrF4tNsRDporJAlldNike4y7TC ly3OBtz7A1LspIgPb3Egr4a3gGJ9ZTu+aBMUhkcr20HtAmV66EIp8V9kIURR3gtLEGMV /7R5yQCiCUDpNn62ZghQyGjtFrsbOBqiirdidAeJx9UGX/bJtpyuOWB6GZnHLQfoMoL+ y10Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FG5E8uWGSrCvajWCjQUTriiKHPgt6q+O5wn0TlE95pQ=; b=onW4lx4/yfHVc/7yY2twjnW2xGx51vEPz7ynQBXgUdeJLf4Z0z83JsL6wVLo0TddgC 9vB66sC/q0BgoVSNL4o1KHfKJ99k8PiXIfshWyubidsZU/HzlzSvxA84OT5h9E+MOGlU U27MR2GB0wKSrqD2jInnYUh5Rdml9W9bkJDZ+wvkwGvW94yDRlFCpK7M6nYMo0LAxJi1 pXBpmDxAvdUiBWN2bmHT7D7buuCW4ZRBePk1161mHlTHjAHGbyz/huGZWWqmz5JbLnJa 4HgKAeAd8GNraezQ5E3TZ6aZP6DHAU0O2jQ2iW7SJo1p7NTDMwGnIvEcFctSh2giVTT9 tTWQ== X-Gm-Message-State: AOAM532KAL3Uz6FoUlsnw8gOuOQueY/5X2m/LHAveOj6JWzV5EJvToML P+dGfgYHOGnQkggpn+0xW12WOQ== X-Google-Smtp-Source: ABdhPJzlY+PZZYIcEGbGdwXLxztX7H+aBXujACcm1iNj1AFfW9eP/eWpWxhk451ND+trCv13A9EbkQ== X-Received: by 2002:a17:906:c34d:: with SMTP id ci13mr25303488ejb.430.1618906231985; Tue, 20 Apr 2021 01:10:31 -0700 (PDT) Received: from apalos.home (ppp-94-65-92-88.home.otenet.gr. [94.65.92.88]) by smtp.gmail.com with ESMTPSA id yr16sm11854378ejb.63.2021.04.20.01.10.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Apr 2021 01:10:31 -0700 (PDT) Date: Tue, 20 Apr 2021 11:10:26 +0300 From: Ilias Apalodimas To: Matthew Wilcox Cc: Jesper Dangaard Brouer , Shakeel Butt , Matteo Croce , netdev , Linux MM , Ayush Sawal , Vinay Kumar Yadav , Rohit Maheshwari , "David S. Miller" , Jakub Kicinski , Thomas Petazzoni , Marcin Wojtas , Russell King , Mirko Lindner , Stephen Hemminger , Tariq Toukan , Jesper Dangaard Brouer , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Boris Pismenny , Arnd Bergmann , Andrew Morton , "Peter Zijlstra (Intel)" , Vlastimil Babka , Yu Zhao , Will Deacon , Michel Lespinasse , Fenghua Yu , Roman Gushchin , Hugh Dickins , Peter Xu , Jason Gunthorpe , Guoqing Jiang , Jonathan Lemon , Alexander Lobakin , Cong Wang , wenxu , Kevin Hao , Aleksandr Nogikh , Jakub Sitnicki , Marco Elver , Willem de Bruijn , Miaohe Lin , Yunsheng Lin , Guillaume Nault , LKML , linux-rdma@vger.kernel.org, bpf , Eric Dumazet , David Ahern , Lorenzo Bianconi , Saeed Mahameed , Andrew Lunn , Paolo Abeni Subject: Re: [PATCH net-next v3 2/5] mm: add a signature in struct page Message-ID: References: <20210409223801.104657-1-mcroce@linux.microsoft.com> <20210409223801.104657-3-mcroce@linux.microsoft.com> <20210410154824.GZ2531743@casper.infradead.org> <20210414214132.74f721dd@carbon> <20210419132204.1e07d5b9@carbon> <20210419130148.GA2531743@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210419130148.GA2531743@casper.infradead.org> Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org Hi Matthew, [...] > > And the contents of this page already came from that device ... if it > wanted to write bad data, it could already have done so. > > > > > (3) The page_pool is optimized for refcnt==1 case, and AFAIK TCP-RX > > > > zerocopy will bump the refcnt, which means the page_pool will not > > > > recycle the page when it see the elevated refcnt (it will instead > > > > release its DMA-mapping). > > > > > > Yes this is right but the userspace might have already consumed and > > > unmapped the page before the driver considers to recycle the page. > > > > That is a good point. So, there is a race window where it is possible > > to gain recycling. > > > > It seems my page_pool co-maintainer Ilias is interested in taking up the > > challenge to get this working with TCP RX zerocopy. So, lets see how > > this is doable. > > You could also check page_ref_count() - page_mapcount() instead of > just checking page_ref_count(). Assuming mapping/unmapping can't > race with recycling? > That's not a bad idea. As I explained on my last reply to Shakeel, I don't think the current patch will blow up anywhere. If the page is unmapped prior to kfree_skb() it will be recycled. If it's done in a reverse order, we'll just free the page entirely and will have to re-allocate it. The only thing I need to test is potential races (assuming those can even happen?). Trying to recycle the page outside of kfree_skb() means we'd have to 'steal' the page, during put_page() (or some function that's outside the networking scope). I think this is going to have a measurable performance penalty though not in networking, but in general. In any case, that should be orthogonal to the current patchset. So unless someone feels strongly about it, I'd prefer keeping the current code and trying to enable recycling in the skb zc case, when we have enough users of the API. Thanks /Ilias