Message ID | 202305051103396748797@zte.com.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp106808vqo; Thu, 4 May 2023 20:11:18 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4wzXAFuO0FPMcGz0diAJ9BeMZYUo7EkqyOXROzXnt2KEuRP1NTDk5IZmfIz8drvksFKDSu X-Received: by 2002:a05:6a00:ccb:b0:63d:315f:560f with SMTP id b11-20020a056a000ccb00b0063d315f560fmr609685pfv.13.1683256278229; Thu, 04 May 2023 20:11:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683256278; cv=none; d=google.com; s=arc-20160816; b=WIyrRByyCMuItetWSxX4ybVeT3rHM6/KE5bJMhfz2kywbe0AwfOzJuR5D8t+V21jWR zNtxGpgw9tbQa57l5T7ZJ6Hmfwvwj/opIu+ryns4vbMfQyxFTP2TuK1+vrCa0tlFOr+/ yRUGz6odamb/59HbxpPlWaD4ev45bwBCK5uxvUCyAmzDtA/K2Tn65ypMX/oKFpq/O2AS mEISNvKRUZVI2vQzZlU6PEH1pD40juePw9L4rBCkMiBG6UXL1kI/yfI5ZLsaSg+4hXMH PDM4mB4zcc4T+PyfBny4a0N0YgfRjhRjNmPJ9arnASZZhdmcUZHIFjztDUUONjHSOnEu 22JQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:cc:to:from:mime-version:message-id:date; bh=49Ka2WDTWAXpHfKljjf9G8XIOIBeETNUtzQcTYFjvvs=; b=VAZGAL+07OOzforOvdN2po+Lkg/pkEKuLhlX0bOC0kjSfoSMaE/jVk6XxCSshfuHNf 0OTB8Vw+7QUIcCsn+FC+dRHNzXcyPVL/w1AMluBedogDqvyq4yGkRg6WlTFavB7Ddx7h e1SY3/5udrBhAOoxjkcvAjEQTLvKuWcaQqNzckqOpRoUgDCy5k0/++K86BquT7Zl5JC1 A6tq4oTKRmO4HdYM6h+/hOg6okHXOsyyU29BPyPrManwqf3DplbZONE/WorvmKy+mM5v 8WdT6J7Q0MwQpeHb1ZI5VA/tY8VdnZ2eV5UhMYMaquJds0NniX0TiGOaHJ9aeruliaL9 xtww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zte.com.cn Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z19-20020aa79493000000b005e1cabb612fsi978570pfk.67.2023.05.04.20.11.04; Thu, 04 May 2023 20:11:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zte.com.cn Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229871AbjEEDEI (ORCPT <rfc822;b08248@gmail.com> + 99 others); Thu, 4 May 2023 23:04:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229768AbjEEDDv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 4 May 2023 23:03:51 -0400 Received: from mxct.zte.com.cn (mxct.zte.com.cn [183.62.165.209]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4613B11B7C; Thu, 4 May 2023 20:03:50 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4QCFrN1bVGz4y3Zj; Fri, 5 May 2023 11:03:48 +0800 (CST) Received: from xaxapp01.zte.com.cn ([10.88.99.176]) by mse-fl2.zte.com.cn with SMTP id 34533ca6093308; Fri, 5 May 2023 11:03:38 +0800 (+08) (envelope-from ye.xingchen@zte.com.cn) Received: from mapi (xaxapp02[null]) by mapi (Zmail) with MAPI id mid31; Fri, 5 May 2023 11:03:39 +0800 (CST) Date: Fri, 5 May 2023 11:03:39 +0800 (CST) X-Zmail-TransId: 2afa6454720b650-79091 X-Mailer: Zmail v1.0 Message-ID: <202305051103396748797@zte.com.cn> Mime-Version: 1.0 From: <ye.xingchen@zte.com.cn> To: <sumit.semwal@linaro.org> Cc: <gustavo@padovan.org>, <christian.koenig@amd.com>, <linux-media@vger.kernel.org>, <dri-devel@lists.freedesktop.org>, <linaro-mm-sig@lists.linaro.org>, <linux-kernel@vger.kernel.org> Subject: =?utf-8?q?=5BPATCH=5D_dma-buf/sync=5Ffile=3A_Use_fdget=28=29?= Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-fl2.zte.com.cn 34533ca6093308 X-Fangmail-Gw-Spam-Type: 0 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 64547213.000/4QCFrN1bVGz4y3Zj X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765022135168820625?= X-GMAIL-MSGID: =?utf-8?q?1765022135168820625?= |
Series |
dma-buf/sync_file: Use fdget()
|
|
Commit Message
ye.xingchen@zte.com.cn
May 5, 2023, 3:03 a.m. UTC
From: Ye Xingchen <ye.xingchen@zte.com.cn> convert the fget() use to fdget(). Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> --- drivers/dma-buf/sync_file.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
Comments
Am 05.05.23 um 05:03 schrieb ye.xingchen@zte.com.cn: > From: Ye Xingchen <ye.xingchen@zte.com.cn> > > convert the fget() use to fdget(). Well the rational is missing. Why should we do that? Christian. > > Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> > --- > drivers/dma-buf/sync_file.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > index af57799c86ce..222b13b1bdb8 100644 > --- a/drivers/dma-buf/sync_file.c > +++ b/drivers/dma-buf/sync_file.c > @@ -78,18 +78,18 @@ EXPORT_SYMBOL(sync_file_create); > > static struct sync_file *sync_file_fdget(int fd) > { > - struct file *file = fget(fd); > + struct struct fd f = fdget(fd); > > - if (!file) > + if (!f.file) > return NULL; > > - if (file->f_op != &sync_file_fops) > + if (f.file->f_op != &sync_file_fops) > goto err; > > - return file->private_data; > + return f.file->private_data; > > err: > - fput(file); > + fdput(f); > return NULL; > } >
On Fri, May 05, 2023 at 11:03:39AM +0800, ye.xingchen@zte.com.cn wrote: > From: Ye Xingchen <ye.xingchen@zte.com.cn> > > convert the fget() use to fdget(). NAK.
On Fri, May 05, 2023 at 10:22:09AM +0200, Christian König wrote: > Am 05.05.23 um 05:03 schrieb ye.xingchen@zte.com.cn: > > From: Ye Xingchen <ye.xingchen@zte.com.cn> > > > > convert the fget() use to fdget(). > > Well the rational is missing. Why should we do that? We very definitely should not. The series appears to be pure cargo-culting and it's completely wrong. There is such thing as unwarranted use of fget(). Under some conditions converting to fdget() is legitimate *and* is an improvement. HOWEVER, those conditions are not met in this case. Background: references in descriptor table do contribute to struct file refcount. fget() finds the reference by descriptor and returns it, having bumped the refcount. In case when descriptor table is shared, we must do that - otherwise e.g. close() or dup2() from another thread could very well have destroyed the struct file we'd just found. However, if descriptor table is *NOT* shared, there's no need to mess with refcount at all. Provided that * we are not grabbing the reference to keep it (stash into some data structure, etc.); as soon as we return from syscall, the reference in descriptor table is fair game for e.g. close(2). Or exit(2), for that matter. * we remember whether it was shared or not - we can't just recheck that when we are done with the file; after all, descriptor table might have been shared when we looked the file up, but another thread might've died since then and left it not shared anymore. * we do not rip the same reference out of our descriptor table ourselves - not without seriously convoluted precautions. Very few places in the kernel can lead to closing descriptors, so in practice it only becomes a problem when a particularly ugly ioctl decides that it would be neat to close some descriptor(s). Example of such convolutions: binder_deferred_fd_close(). fdget() returns a pair that consists of struct file reference *AND* indication whether we have grabbed a reference. fdput() takes such pair. Both are inlined, and compiler is smart enough to split the pair into two separate local variables. The underlying primitive actually stashes the "have grabbed the refcount" into the LSB of returned word; see __to_fd() in include/linux/file.h for details. It really generates a decent code and a plenty of places where we want a file by descriptor are just fine with it. This patch is flat-out broken, since it loses the "have we bumped the refcount" information - the callers do not get it. It might be possible to massage the calling conventions to enable the conversion to fdget(), but it's not obvious that result would be cleaner and in any case, the patch in question doesn't even try that.
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index af57799c86ce..222b13b1bdb8 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -78,18 +78,18 @@ EXPORT_SYMBOL(sync_file_create); static struct sync_file *sync_file_fdget(int fd) { - struct file *file = fget(fd); + struct struct fd f = fdget(fd); - if (!file) + if (!f.file) return NULL; - if (file->f_op != &sync_file_fops) + if (f.file->f_op != &sync_file_fops) goto err; - return file->private_data; + return f.file->private_data; err: - fput(file); + fdput(f); return NULL; }