From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E82CE7DA82; Tue, 29 Oct 2024 09:40:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730194805; cv=none; b=SjuVt11eFfzWIyV4/WRiez1IuG9+6mUW8z9kAJKCBgzKZYgMKRM2xm2AXnZpE8ne9OujJk4SprEEybaHHe5fLSEIirU9fkfc8RFlQuM1VRY2dsiG2deHFq//X7Q30Y91aBJG0wc+qf637vqiek4o2iDodKuNrlw5RW+69Dz5ZQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730194805; c=relaxed/simple; bh=64GcQ2hYxd29h7Z4cbBbpVIa+hnqlUlUrU7Xbn1LDzY=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=taKpYntMtHxiZo4djxDvBty4jb97EKkCJ1bCPjHoSS2atNnK8Ey4e56e26pcHg5++Oi44c+VMUaLPvWIOdM6O8KkaPZ7imVipeNriABDEfXUGKqUqOkplwm1CEU4nU743KYLn1ISHYfB/YNOB4z2qy48efKOecerX7j5Ovwewpg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com 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 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemf200006.china.huawei.com (7.185.36.61) 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.