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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE155D2AB0D for ; Tue, 29 Oct 2024 09:40:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23D066B009C; Tue, 29 Oct 2024 05:40:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EC796B009D; Tue, 29 Oct 2024 05:40:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B40B6B009E; Tue, 29 Oct 2024 05:40:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E0B266B009C for ; Tue, 29 Oct 2024 05:40:07 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A55A3AB493 for ; Tue, 29 Oct 2024 09:40:07 +0000 (UTC) X-FDA: 82726143192.04.28F294D Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf01.hostedemail.com (Postfix) with ESMTP id CBE2940017 for ; Tue, 29 Oct 2024 09:39:45 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730194725; a=rsa-sha256; cv=none; b=oYt0akXzB1Lubla/iAq7UFboiUDueqIIk0nMCwTGBr5cVUlPBkvc/KWD32HDt+7+AGh2zZ ct/GQjYkwyuR95cEPzPXCYP4ek/eIF2a0s4Fl44Ckl3QLUuYeomE9OUvM3sDqI3/cl5xmB N9gkDfVDyvtiWYS9x2nQKRgsO+/Ffko= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730194725; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GLpQqCl7mOQnzPiWNJFtEBHjpAewCwBHMGVRmyGUmFk=; b=O2TBfL9e1ruvcxKQIeqpKsgcr6/hg3joVUOiWhlm/pcGBjUgghnnlFQKyOP6qs8/wfnwYZ 2PkgiAZLQ4hx90RjESVOAB5XrbkZKAZ6O+IEo5DpeTHFb3RoiXpXuJPt0IeuBrmjuOYyTA sNDjx9tDFWa/naXkpTmggGWYRHw4hrI= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Xd4tg2wx9zpXb0; Tue, 29 Oct 2024 17:38:03 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 314DC180064; Tue, 29 Oct 2024 17:39:59 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 29 Oct 2024 17:39:58 +0800 Message-ID: Date: Tue, 29 Oct 2024 17:39:58 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 04/10] mm: page_frag: introduce page_frag_alloc_abort() related API To: Alexander Duyck CC: , , , , , Andrew Morton , Linux-MM , Jonathan Corbet , References: <20241028115850.3409893-1-linyunsheng@huawei.com> <20241028115850.3409893-5-linyunsheng@huawei.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemf200006.china.huawei.com (7.185.36.61) X-Stat-Signature: 57h3iker3nmgn9uozjo7koe7zosbyefm X-Rspamd-Queue-Id: CBE2940017 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1730194785-209002 X-HE-Meta: U2FsdGVkX1/HE5tdFKAieik6g2lgb/6Iv8sC2+OqKks4dWtDJ0Miqa0a4e7O+tWAsKiqF3aAiQRdAid2EUrQVfNVe9oLW1gUvrRi2YIAyCnMiJZ/OTNasIvUBBDdwr/JYR/bsfkzFYtxXPkPvSXe0hWP6MTBIhhVumhDtirGVvg/DS8/TQnOwkLXELdLz0YBxMPHaXPvgwosYrFPvf1U3cJt90USG7w5Kqwqpn1g/236qpM5mw02GjwxWzX52ilwCmctMQv2MrYPn/s346NUWxCq7kS8ESKIFmq6+PIpLVpugxJXR0RmBWlATQzAQsRqgllUcTQxCSXJXe+CItjjtDQqdFFvl0X9CzhO8xLlBYVck0ZGOx++5WfDGfJCjz3PHEQnEtbC9m84E1dvcxdhsDP492tmOWIWjSjPffrTpwL8F4CrVca8bbH9ydOWHEBr/LVdDJmT2cMGzbSSSa6EnBc8dev6v0FDykx80YrlIapKIqEMyBMXIT8DASj/UYAZ2PRK+3HuoePfNervL2bualdxya28h+pnDx53KqmcDw+CQ247PjcP56QG7dLEEQd4CEHuqEPZYEvJqfc0WwUabWm2y24IF6IUg9rZWqmzRYZLdiMwp6daWooDpsOAfDjO1qxmjMpm14q152fL5XdhOwQW/M9B03qnIj4RDh2ULstnJwI9e7zFWEpWYKCWnT/LtGATZ9XP3kCExlA4gLetiVzCUO9kMBdwb5/GpsSar06Udql22gIjwrnN/ZidgujLA4G+/CDHoKRmTdgSFe9NbF1IEqQkzhrJ5Okd0mRvj1k/whbCy/d+M6hYvd0imE/zhMA/X1yCvWEC/9WMq8IKbs7SPsmCbOoP3x9BIVcMctoi5vXQAWywk6+cf6UfuIav6cgmtsZAePTRhwZk8seNMCnVW741FRVp86l0HZLUJ3FwYy8/Tq142TZNG/+Ha5u1qqviM5pTpVRn36wjV9W T3IRtOeW AZkahJcHDZi4BCmafDcfUijqP3REf2T/voYBnP8R5iS5Dy50SxOUG4FbqxE3C/oh+rXJj4TQOj7T3j/cvzsLtNBbHBK3DncA/7phKvNU0IHvSExhWJa5hzuaAXM1Vbj9RXHZ5DhQUSNVsB6UTeNmQ1lwnNXsGrO1nylJ1u8cwXBnAV7U1S9V+uxxnCKToI9H9ojDaxzDXxe2nZqLrOzXQWpnSZHsxFjvwbrG62lGXQT7jcLtQcClBgwf3MVoF0axAtShZvejl6VE5bmHibfFuxO04BvPsIgjxtHK9uiHwDpgJF+DNPnKuc1Hglj3Sl0JKHsw78T25GajBIr1wdxdFp1PFUA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/10/29 1:53, Alexander Duyck wrote: > On Mon, Oct 28, 2024 at 5:05 AM Yunsheng Lin wrote: >> >> For some case as tun_build_skb() without the needing of >> using complicated prepare & commit API, add the abort API to >> abort the operation of page_frag_alloc_*() related API for >> error handling knowing that no one else is taking extra >> reference to the just allocated fragment, and add abort_ref >> API to only abort the reference counting of the allocated >> fragment if it is already referenced by someone else. >> ... >> + >> +/** >> + * page_frag_alloc_abort_ref - Abort the reference of allocated fragment. >> + * @nc: page_frag cache to which the page fragment is aborted back >> + * @va: virtual address of page fragment to be aborted >> + * @fragsz: size of the page fragment to be aborted >> + * >> + * It is expected to be called from the same context as the allocation API. >> + * Mostly used for error handling cases to abort the reference of allocated >> + * fragment if the fragment has been referenced for other usages, to aovid the >> + * atomic operation of page_frag_free() API. >> + */ >> +void page_frag_alloc_abort_ref(struct page_frag_cache *nc, void *va, >> + unsigned int fragsz) >> +{ >> + VM_BUG_ON(va + fragsz != >> + encoded_page_decode_virt(nc->encoded_page) + nc->offset); >> + >> + nc->pagecnt_bias++; >> +} >> +EXPORT_SYMBOL(page_frag_alloc_abort_ref); > > It isn't clear to me why you split this over two functions. It seems > like you could just update the offset in this lower function rather > than do it in the upper one since you are passing all the arguments > here anyway. For the usecase in tun_build_skb(), There seems to be XDP_REDIRECT and XDP_TX case that the allocated fragment has been referenced for other usages even when xdp_do_redirect() or tun_xdp_tx() return error, so that caller can call page_frag_alloc_abort_ref() to abort its reference of the allocated fragment, but not abort the whole fragment for later reuse. As the doc mentioned above page_frag_alloc_abort_ref(), it is mainly to avoid the atomic operation of page_frag_free() API when the caller has the allocation context and has the all the arguments page_frag_alloc_abort_ref() needs even though it might be a unlikely case if page_frag_alloc_abort() API is already provided.