Message ID | d11b93ad8e3b669afaff942e25c3fca65c6a983c.1689074739.git.legion@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp405923vqm; Tue, 11 Jul 2023 04:30:20 -0700 (PDT) X-Google-Smtp-Source: APBJJlEeWa5jjzEGlJCCR4ocRQwN+Cll+7FBcr2kxW8JC3bjxKTEgglfRvPQW7N5O0oQ/7APnXd7 X-Received: by 2002:a17:90a:f40f:b0:263:30d6:dca with SMTP id ch15-20020a17090af40f00b0026330d60dcamr15698486pjb.29.1689075020081; Tue, 11 Jul 2023 04:30:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689075020; cv=none; d=google.com; s=arc-20160816; b=sgKuokgm0yPmlK8MxLyqZujAP5eBh8wektQjY/Dw9PzxNzcDhfQIFkl/8/EaVRQKq7 CWz3isgt9032et25Fq6yx5hy4qHNRQtNljpRAfeS6eBjoz+Dth5A+eYB1EHsMAJ+APpl vtKkv1ASIr30xpr/oTMqHcSo2pn3piss4UzHBnAcAuuhvenkISO0mrTq6zOK5eS0vicC aup6uHUeN4S++wxsOFtHsqy7vIHeApfjk9K3+ZjGrT9/Q+qYLUdhGRrCaZ/tr11XZCUm tNuPRKnOUoG4G7/+JTVdGYWtBZT7EUBDO8vtUZW490hgB+b9viijNvCjcPyb/vLyJVnj 4wKA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=tqGTDjWgCyl3301VCICiGeNnsnGd2C5+b72JLCu08OI=; fh=seYkIZwGhsaZ2mPN9tbwuL3qzBlMHi0iBX9GrZDxiYI=; b=GupDeQAlkqzfvVzjEbj88ZqrUSUsdX1GxNEl6o2u9B3nKqx8pKc6oSIpnM/G2ZSHOT Nyktf6fVBwSnQnOQmzxWGyWrc5jB6t8l8JQ70kqbp/Oj1A+f1A04+vtEdZv+A4rt3Vsf a4+AAVYveQy4G5nCwoFVrcqgYWKI/9CW+iWEnQhrdJnJLe0lobrn2mHubPZ78R1HVPMr 1rHuBrHZOUiXll18CAPgXVTojs283Wk5jQHZTH9pq25O6ZowDw9X3GQk6P+jOpjl1R1K Ctdkh9yTU+Z6AfxuR5HdlYdEjMu75h9ZeYcA0BtJ/bQOqeAPT48sTdotin3XLJFOfvCf rVeQ== 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ca18-20020a17090af31200b0024c1ddfa1bfsi4845353pjb.92.2023.07.11.04.30.07; Tue, 11 Jul 2023 04:30:20 -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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230255AbjGKL3F (ORCPT <rfc822;gnulinuxfreebsd@gmail.com> + 99 others); Tue, 11 Jul 2023 07:29:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232112AbjGKL2i (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 11 Jul 2023 07:28:38 -0400 Received: from us-smtp-delivery-44.mimecast.com (unknown [207.211.30.44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42C1F1BC9 for <linux-kernel@vger.kernel.org>; Tue, 11 Jul 2023 04:28:27 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-349-1yjghznhNHO9f6zghBUlhw-1; Tue, 11 Jul 2023 07:26:39 -0400 X-MC-Unique: 1yjghznhNHO9f6zghBUlhw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F71B3C13928; Tue, 11 Jul 2023 11:26:38 +0000 (UTC) Received: from localhost.localdomain.com (unknown [10.45.225.44]) by smtp.corp.redhat.com (Postfix) with ESMTP id C5A9463F3C; Tue, 11 Jul 2023 11:26:25 +0000 (UTC) From: Alexey Gladkov <legion@kernel.org> To: LKML <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk Cc: Palmer Dabbelt <palmer@sifive.com>, James.Bottomley@HansenPartnership.com, acme@kernel.org, alexander.shishkin@linux.intel.com, axboe@kernel.dk, benh@kernel.crashing.org, borntraeger@de.ibm.com, bp@alien8.de, catalin.marinas@arm.com, christian@brauner.io, dalias@libc.org, davem@davemloft.net, deepa.kernel@gmail.com, deller@gmx.de, dhowells@redhat.com, fenghua.yu@intel.com, firoz.khan@linaro.org, fweimer@redhat.com, geert@linux-m68k.org, glebfm@altlinux.org, gor@linux.ibm.com, hare@suse.com, heiko.carstens@de.ibm.com, hpa@zytor.com, ink@jurassic.park.msu.ru, jhogan@kernel.org, kim.phillips@arm.com, ldv@altlinux.org, linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux@armlinux.org.uk, linuxppc-dev@lists.ozlabs.org, luto@kernel.org, mattst88@gmail.com, mingo@redhat.com, monstr@monstr.eu, mpe@ellerman.id.au, namhyung@kernel.org, paul.burton@mips.com, paulus@samba.org, peterz@infradead.org, ralf@linux-mips.org, rth@twiddle.net, schwidefsky@de.ibm.com, sparclinux@vger.kernel.org, stefan@agner.ch, tglx@linutronix.de, tony.luck@intel.com, tycho@tycho.ws, will@kernel.org, x86@kernel.org, ysato@users.sourceforge.jp Subject: [PATCH v3 2/5] fs: Add fchmodat4() Date: Tue, 11 Jul 2023 13:25:43 +0200 Message-Id: <d11b93ad8e3b669afaff942e25c3fca65c6a983c.1689074739.git.legion@kernel.org> In-Reply-To: <cover.1689074739.git.legion@kernel.org> References: <87o8pscpny.fsf@oldenburg2.str.redhat.com> <cover.1689074739.git.legion@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,RDNS_NONE,SPF_HELO_NONE,SPF_SOFTFAIL, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no 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: INBOX X-GMAIL-THRID: 1771123528131488174 X-GMAIL-MSGID: 1771123528131488174 |
Series |
Add a new fchmodat4() syscall
|
|
Commit Message
Alexey Gladkov
July 11, 2023, 11:25 a.m. UTC
From: Palmer Dabbelt <palmer@sifive.com> On the userspace side fchmodat(3) is implemented as a wrapper function which implements the POSIX-specified interface. This interface differs from the underlying kernel system call, which does not have a flags argument. Most implementations require procfs [1][2]. There doesn't appear to be a good userspace workaround for this issue but the implementation in the kernel is pretty straight-forward. The new fchmodat4() syscall allows to pass the AT_SYMLINK_NOFOLLOW flag, unlike existing fchmodat. [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/fchmodat.c;h=17eca54051ee28ba1ec3f9aed170a62630959143;hb=a492b1e5ef7ab50c6fdd4e4e9879ea5569ab0a6c#l35 [2] https://git.musl-libc.org/cgit/musl/tree/src/stat/fchmodat.c?id=718f363bc2067b6487900eddc9180c84e7739f80#n28 Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Alexey Gladkov <legion@kernel.org> --- fs/open.c | 18 ++++++++++++++---- include/linux/syscalls.h | 2 ++ 2 files changed, 16 insertions(+), 4 deletions(-)
Comments
On Tue, Jul 11, 2023, at 13:25, Alexey Gladkov wrote: > From: Palmer Dabbelt <palmer@sifive.com> > > On the userspace side fchmodat(3) is implemented as a wrapper > function which implements the POSIX-specified interface. This > interface differs from the underlying kernel system call, which does not > have a flags argument. Most implementations require procfs [1][2]. > > There doesn't appear to be a good userspace workaround for this issue > but the implementation in the kernel is pretty straight-forward. > > The new fchmodat4() syscall allows to pass the AT_SYMLINK_NOFOLLOW flag, > unlike existing fchmodat. > > [1] > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/fchmodat.c;h=17eca54051ee28ba1ec3f9aed170a62630959143;hb=a492b1e5ef7ab50c6fdd4e4e9879ea5569ab0a6c#l35 > [2] > https://git.musl-libc.org/cgit/musl/tree/src/stat/fchmodat.c?id=718f363bc2067b6487900eddc9180c84e7739f80#n28 > > Signed-off-by: Palmer Dabbelt <palmer@sifive.com> > Signed-off-by: Alexey Gladkov <legion@kernel.org> I don't know the history of why we ended up with the different interface, or whether this was done intentionally in the kernel or if we want this syscall. Assuming this is in fact needed, I double-checked that the implementation looks correct to me and is portable to all the architectures, without the need for a compat wrapper. Acked-by: Arnd Bergmann <arnd@arndb.de>
On Tue, Jul 11, 2023 at 01:42:19PM +0200, Arnd Bergmann wrote: > On Tue, Jul 11, 2023, at 13:25, Alexey Gladkov wrote: > > From: Palmer Dabbelt <palmer@sifive.com> > > > > On the userspace side fchmodat(3) is implemented as a wrapper > > function which implements the POSIX-specified interface. This > > interface differs from the underlying kernel system call, which does not > > have a flags argument. Most implementations require procfs [1][2]. > > > > There doesn't appear to be a good userspace workaround for this issue > > but the implementation in the kernel is pretty straight-forward. > > > > The new fchmodat4() syscall allows to pass the AT_SYMLINK_NOFOLLOW flag, > > unlike existing fchmodat. > > > > [1] > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/fchmodat.c;h=17eca54051ee28ba1ec3f9aed170a62630959143;hb=a492b1e5ef7ab50c6fdd4e4e9879ea5569ab0a6c#l35 > > [2] > > https://git.musl-libc.org/cgit/musl/tree/src/stat/fchmodat.c?id=718f363bc2067b6487900eddc9180c84e7739f80#n28 > > > > Signed-off-by: Palmer Dabbelt <palmer@sifive.com> > > Signed-off-by: Alexey Gladkov <legion@kernel.org> > > I don't know the history of why we ended up with the different > interface, or whether this was done intentionally in the kernel > or if we want this syscall. > > Assuming this is in fact needed, I double-checked that the > implementation looks correct to me and is portable to all the > architectures, without the need for a compat wrapper. > > Acked-by: Arnd Bergmann <arnd@arndb.de> The system call itself is useful afaict. But please, s/fchmodat4/fchmodat2/ With very few exceptions we don't version by argument number but by revision and we should stick to one scheme: openat()->openat2() eventfd()->eventfd2() clone()/clone2()->clone3() dup()->dup2()->dup3() // coincides with nr of arguments pipe()->pipe2() // coincides with nr of arguments renameat()->renameat2()
On Tue, Jul 11, 2023 at 01:25:43PM +0200, Alexey Gladkov wrote: > -static int do_fchmodat(int dfd, const char __user *filename, umode_t mode) > +static int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int lookup_flags) This function can still be called do_fchmodat(); we don't need to version internal functions.
On Tue, Jul 11, 2023 at 01:28:04PM +0100, Matthew Wilcox wrote: > On Tue, Jul 11, 2023 at 01:25:43PM +0200, Alexey Gladkov wrote: > > -static int do_fchmodat(int dfd, const char __user *filename, umode_t mode) > > +static int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int lookup_flags) > > This function can still be called do_fchmodat(); we don't need to > version internal functions. Yes. I tried not to change too much when adopting a patch. In the new version, I will return the old name. Thanks.
On Tue, Jul 11, 2023 at 01:52:01PM +0200, Christian Brauner wrote: > On Tue, Jul 11, 2023 at 01:42:19PM +0200, Arnd Bergmann wrote: > > On Tue, Jul 11, 2023, at 13:25, Alexey Gladkov wrote: > > > From: Palmer Dabbelt <palmer@sifive.com> > > > > > > On the userspace side fchmodat(3) is implemented as a wrapper > > > function which implements the POSIX-specified interface. This > > > interface differs from the underlying kernel system call, which does not > > > have a flags argument. Most implementations require procfs [1][2]. > > > > > > There doesn't appear to be a good userspace workaround for this issue > > > but the implementation in the kernel is pretty straight-forward. > > > > > > The new fchmodat4() syscall allows to pass the AT_SYMLINK_NOFOLLOW flag, > > > unlike existing fchmodat. > > > > > > [1] > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/fchmodat.c;h=17eca54051ee28ba1ec3f9aed170a62630959143;hb=a492b1e5ef7ab50c6fdd4e4e9879ea5569ab0a6c#l35 > > > [2] > > > https://git.musl-libc.org/cgit/musl/tree/src/stat/fchmodat.c?id=718f363bc2067b6487900eddc9180c84e7739f80#n28 > > > > > > Signed-off-by: Palmer Dabbelt <palmer@sifive.com> > > > Signed-off-by: Alexey Gladkov <legion@kernel.org> > > > > I don't know the history of why we ended up with the different > > interface, or whether this was done intentionally in the kernel > > or if we want this syscall. > > > > Assuming this is in fact needed, I double-checked that the > > implementation looks correct to me and is portable to all the > > architectures, without the need for a compat wrapper. > > > > Acked-by: Arnd Bergmann <arnd@arndb.de> > > The system call itself is useful afaict. But please, > > s/fchmodat4/fchmodat2/ Sure. I will. > With very few exceptions we don't version by argument number but by > revision and we should stick to one scheme: > > openat()->openat2() > eventfd()->eventfd2() > clone()/clone2()->clone3() > dup()->dup2()->dup3() // coincides with nr of arguments > pipe()->pipe2() // coincides with nr of arguments > renameat()->renameat2() >
On Tue, Jul 11, 2023 at 02:51:01PM +0200, Alexey Gladkov wrote: > On Tue, Jul 11, 2023 at 01:52:01PM +0200, Christian Brauner wrote: > > On Tue, Jul 11, 2023 at 01:42:19PM +0200, Arnd Bergmann wrote: > > > On Tue, Jul 11, 2023, at 13:25, Alexey Gladkov wrote: > > > > From: Palmer Dabbelt <palmer@sifive.com> > > > > > > > > On the userspace side fchmodat(3) is implemented as a wrapper > > > > function which implements the POSIX-specified interface. This > > > > interface differs from the underlying kernel system call, which does not > > > > have a flags argument. Most implementations require procfs [1][2]. > > > > > > > > There doesn't appear to be a good userspace workaround for this issue > > > > but the implementation in the kernel is pretty straight-forward. > > > > > > > > The new fchmodat4() syscall allows to pass the AT_SYMLINK_NOFOLLOW flag, > > > > unlike existing fchmodat. > > > > > > > > [1] > > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/fchmodat.c;h=17eca54051ee28ba1ec3f9aed170a62630959143;hb=a492b1e5ef7ab50c6fdd4e4e9879ea5569ab0a6c#l35 > > > > [2] > > > > https://git.musl-libc.org/cgit/musl/tree/src/stat/fchmodat.c?id=718f363bc2067b6487900eddc9180c84e7739f80#n28 > > > > > > > > Signed-off-by: Palmer Dabbelt <palmer@sifive.com> > > > > Signed-off-by: Alexey Gladkov <legion@kernel.org> > > > > > > I don't know the history of why we ended up with the different > > > interface, or whether this was done intentionally in the kernel > > > or if we want this syscall. > > > > > > Assuming this is in fact needed, I double-checked that the > > > implementation looks correct to me and is portable to all the > > > architectures, without the need for a compat wrapper. > > > > > > Acked-by: Arnd Bergmann <arnd@arndb.de> > > > > The system call itself is useful afaict. But please, > > > > s/fchmodat4/fchmodat2/ > > Sure. I will. Thanks. Can you also wire this up for every architecture, please? I don't see that this has been done in this series.
On Tue, Jul 11, 2023 at 04:01:03PM +0200, Christian Brauner wrote: > On Tue, Jul 11, 2023 at 02:51:01PM +0200, Alexey Gladkov wrote: > > On Tue, Jul 11, 2023 at 01:52:01PM +0200, Christian Brauner wrote: > > > On Tue, Jul 11, 2023 at 01:42:19PM +0200, Arnd Bergmann wrote: > > > > On Tue, Jul 11, 2023, at 13:25, Alexey Gladkov wrote: > > > > > From: Palmer Dabbelt <palmer@sifive.com> > > > > > > > > > > On the userspace side fchmodat(3) is implemented as a wrapper > > > > > function which implements the POSIX-specified interface. This > > > > > interface differs from the underlying kernel system call, which does not > > > > > have a flags argument. Most implementations require procfs [1][2]. > > > > > > > > > > There doesn't appear to be a good userspace workaround for this issue > > > > > but the implementation in the kernel is pretty straight-forward. > > > > > > > > > > The new fchmodat4() syscall allows to pass the AT_SYMLINK_NOFOLLOW flag, > > > > > unlike existing fchmodat. > > > > > > > > > > [1] > > > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/fchmodat.c;h=17eca54051ee28ba1ec3f9aed170a62630959143;hb=a492b1e5ef7ab50c6fdd4e4e9879ea5569ab0a6c#l35 > > > > > [2] > > > > > https://git.musl-libc.org/cgit/musl/tree/src/stat/fchmodat.c?id=718f363bc2067b6487900eddc9180c84e7739f80#n28 > > > > > > > > > > Signed-off-by: Palmer Dabbelt <palmer@sifive.com> > > > > > Signed-off-by: Alexey Gladkov <legion@kernel.org> > > > > > > > > I don't know the history of why we ended up with the different > > > > interface, or whether this was done intentionally in the kernel > > > > or if we want this syscall. > > > > > > > > Assuming this is in fact needed, I double-checked that the > > > > implementation looks correct to me and is portable to all the > > > > architectures, without the need for a compat wrapper. > > > > > > > > Acked-by: Arnd Bergmann <arnd@arndb.de> > > > > > > The system call itself is useful afaict. But please, > > > > > > s/fchmodat4/fchmodat2/ > > > > Sure. I will. > > Thanks. Can you also wire this up for every architecture, please? > I don't see that this has been done in this series. Sure. I have already added in all architectures as far as I can tell: $ diff -s <(find arch/ -name '*.tbl' |sort -u) <(git grep -lw fchmodat2 arch/ |sort -u) Files /dev/fd/63 and /dev/fd/62 are identical
diff --git a/fs/open.c b/fs/open.c index 4478adcc4f3a..58bb88c6afb6 100644 --- a/fs/open.c +++ b/fs/open.c @@ -671,11 +671,11 @@ SYSCALL_DEFINE2(fchmod, unsigned int, fd, umode_t, mode) return err; } -static int do_fchmodat(int dfd, const char __user *filename, umode_t mode) +static int do_fchmodat4(int dfd, const char __user *filename, umode_t mode, int lookup_flags) { struct path path; int error; - unsigned int lookup_flags = LOOKUP_FOLLOW; + retry: error = user_path_at(dfd, filename, lookup_flags, &path); if (!error) { @@ -689,15 +689,25 @@ static int do_fchmodat(int dfd, const char __user *filename, umode_t mode) return error; } +SYSCALL_DEFINE4(fchmodat4, int, dfd, const char __user *, filename, + umode_t, mode, int, flags) +{ + if (unlikely(flags & ~AT_SYMLINK_NOFOLLOW)) + return -EINVAL; + + return do_fchmodat4(dfd, filename, mode, + flags & AT_SYMLINK_NOFOLLOW ? 0 : LOOKUP_FOLLOW); +} + SYSCALL_DEFINE3(fchmodat, int, dfd, const char __user *, filename, umode_t, mode) { - return do_fchmodat(dfd, filename, mode); + return do_fchmodat4(dfd, filename, mode, LOOKUP_FOLLOW); } SYSCALL_DEFINE2(chmod, const char __user *, filename, umode_t, mode) { - return do_fchmodat(AT_FDCWD, filename, mode); + return do_fchmodat4(AT_FDCWD, filename, mode, LOOKUP_FOLLOW); } /** diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index 497bdd968c32..b17d37d2bad6 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -466,6 +466,8 @@ asmlinkage long sys_chroot(const char __user *filename); asmlinkage long sys_fchmod(unsigned int fd, umode_t mode); asmlinkage long sys_fchmodat(int dfd, const char __user *filename, umode_t mode); +asmlinkage long sys_fchmodat4(int dfd, const char __user *filename, + umode_t mode, int flags); asmlinkage long sys_fchownat(int dfd, const char __user *filename, uid_t user, gid_t group, int flag); asmlinkage long sys_fchown(unsigned int fd, uid_t user, gid_t group);