From: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Andreas Gruenbacher <agruenba@redhat.com>, LKML <linux-kernel@vger.kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Bob Peterson <rpeterso@redhat.com>, Steve Whitehouse <swhiteho@redhat.com>, Jan Kara <jack@suse.cz>, NeilBrown <neilb@suse.com>, "Darrick J. Wong" <darrick.wong@oracle.com>, cluster-devel <cluster-devel@redhat.com> Subject: Re: [PATCH v5 03/18] gfs2: add compat_ioctl support Date: Sun, 18 Aug 2019 22:17:06 +0200 [thread overview] Message-ID: <CAHpGcMJ2EScNiPapyugC_fz+AEhdpKmx3VmYjTH_2me8WLxB2A@mail.gmail.com> (raw) In-Reply-To: <CAK8P3a3kiyytayaSs2LB=deK0OMs42Ayn4VErhjL6eM3FTGtpw@mail.gmail.com> Am So., 18. Aug. 2019 um 21:32 Uhr schrieb Arnd Bergmann <arnd@arndb.de>: > On Fri, Aug 16, 2019 at 7:32 PM Andreas Gruenbacher <agruenba@redhat.com> wrote: > > On Wed, Aug 14, 2019 at 10:45 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > + /* These are just misnamed, they actually get/put from/to user an int */ > > > + switch(cmd) { > > > + case FS_IOC32_GETFLAGS: > > > + cmd = FS_IOC_GETFLAGS; > > > + break; > > > + case FS_IOC32_SETFLAGS: > > > + cmd = FS_IOC_SETFLAGS; > > > + break; > > > > I'd like the code to be more explicit here: > > > > case FITRIM: > > case FS_IOC_GETFSLABEL: > > break; > > default: > > return -ENOIOCTLCMD; > > I've looked at it again: if we do this, the function actually becomes > longer than the native gfs2_ioctl(). Should we just make a full copy then? I don't think the length of gfs2_compat_ioctl is really an issue as long as the function is that simple. > static long gfs2_compat_ioctl(struct file *filp, unsigned int cmd, > unsigned long arg) > { > switch(cmd) { > case FS_IOC32_GETFLAGS: > return gfs2_get_flags(filp, (u32 __user *)arg); > case FS_IOC32_SETFLAGS: > return gfs2_set_flags(filp, (u32 __user *)arg); > case FITRIM: > return gfs2_fitrim(filp, (void __user *)arg); > case FS_IOC_GETFSLABEL: > return gfs2_getlabel(filp, (char __user *)arg); > } > > return -ENOTTY; > } Don't we still need the compat_ptr conversion? That seems to be the main point of having a compat_ioctl operation. > > Should we feed this through the gfs2 tree? > > A later patch that removes the FITRIM handling from fs/compat_ioctl.c > depends on it, so I'd like to keep everything together. Ok, fine for me. Thanks, Andreas
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Grünbacher <andreas.gruenbacher@gmail.com> To: cluster-devel.redhat.com Subject: [Cluster-devel] [PATCH v5 03/18] gfs2: add compat_ioctl support Date: Sun, 18 Aug 2019 22:17:06 +0200 [thread overview] Message-ID: <CAHpGcMJ2EScNiPapyugC_fz+AEhdpKmx3VmYjTH_2me8WLxB2A@mail.gmail.com> (raw) In-Reply-To: <CAK8P3a3kiyytayaSs2LB=deK0OMs42Ayn4VErhjL6eM3FTGtpw@mail.gmail.com> Am So., 18. Aug. 2019 um 21:32 Uhr schrieb Arnd Bergmann <arnd@arndb.de>: > On Fri, Aug 16, 2019 at 7:32 PM Andreas Gruenbacher <agruenba@redhat.com> wrote: > > On Wed, Aug 14, 2019 at 10:45 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > + /* These are just misnamed, they actually get/put from/to user an int */ > > > + switch(cmd) { > > > + case FS_IOC32_GETFLAGS: > > > + cmd = FS_IOC_GETFLAGS; > > > + break; > > > + case FS_IOC32_SETFLAGS: > > > + cmd = FS_IOC_SETFLAGS; > > > + break; > > > > I'd like the code to be more explicit here: > > > > case FITRIM: > > case FS_IOC_GETFSLABEL: > > break; > > default: > > return -ENOIOCTLCMD; > > I've looked at it again: if we do this, the function actually becomes > longer than the native gfs2_ioctl(). Should we just make a full copy then? I don't think the length of gfs2_compat_ioctl is really an issue as long as the function is that simple. > static long gfs2_compat_ioctl(struct file *filp, unsigned int cmd, > unsigned long arg) > { > switch(cmd) { > case FS_IOC32_GETFLAGS: > return gfs2_get_flags(filp, (u32 __user *)arg); > case FS_IOC32_SETFLAGS: > return gfs2_set_flags(filp, (u32 __user *)arg); > case FITRIM: > return gfs2_fitrim(filp, (void __user *)arg); > case FS_IOC_GETFSLABEL: > return gfs2_getlabel(filp, (char __user *)arg); > } > > return -ENOTTY; > } Don't we still need the compat_ptr conversion? That seems to be the main point of having a compat_ioctl operation. > > Should we feed this through the gfs2 tree? > > A later patch that removes the FITRIM handling from fs/compat_ioctl.c > depends on it, so I'd like to keep everything together. Ok, fine for me. Thanks, Andreas
next prev parent reply other threads:[~2019-08-18 20:17 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-14 20:42 [PATCH v5 00/18] compat_ioctl.c removal, part 2/3 Arnd Bergmann 2019-08-14 20:42 ` [Cluster-devel] " Arnd Bergmann 2019-08-14 20:42 ` Arnd Bergmann 2019-08-14 20:42 ` Arnd Bergmann 2019-08-14 20:42 ` [f2fs-dev] " Arnd Bergmann 2019-08-14 20:42 ` [PATCH v5 01/18] xfs: compat_ioctl: use compat_ptr() Arnd Bergmann 2019-08-14 21:37 ` Dave Chinner 2019-08-15 6:43 ` Arnd Bergmann 2019-08-15 7:13 ` Christoph Hellwig 2019-08-15 7:56 ` Arnd Bergmann 2019-08-15 7:56 ` Arnd Bergmann 2019-08-15 8:02 ` Christoph Hellwig 2019-08-15 10:26 ` Christoph Hellwig 2019-08-15 11:02 ` Arnd Bergmann 2019-08-15 12:15 ` Dave Chinner 2019-08-15 14:03 ` Christoph Hellwig 2019-08-15 19:20 ` Arnd Bergmann 2019-08-15 19:28 ` Darrick J. Wong 2019-08-15 19:46 ` Arnd Bergmann 2019-08-14 20:42 ` [PATCH v5 02/18] xfs: compat_ioctl: add missing conversions Arnd Bergmann 2019-08-14 20:42 ` [PATCH v5 03/18] gfs2: add compat_ioctl support Arnd Bergmann 2019-08-14 20:42 ` [Cluster-devel] " Arnd Bergmann 2019-08-15 12:07 ` Bob Peterson 2019-08-15 12:07 ` [Cluster-devel] " Bob Peterson 2019-08-16 17:31 ` Andreas Gruenbacher 2019-08-16 17:31 ` [Cluster-devel] " Andreas Gruenbacher 2019-08-18 19:31 ` Arnd Bergmann 2019-08-18 19:31 ` [Cluster-devel] " Arnd Bergmann 2019-08-18 20:17 ` Andreas Grünbacher [this message] 2019-08-18 20:17 ` Andreas Grünbacher 2019-08-19 9:09 ` Arnd Bergmann 2019-08-19 9:09 ` [Cluster-devel] " Arnd Bergmann 2019-08-19 9:37 ` Andreas Gruenbacher 2019-08-19 9:37 ` [Cluster-devel] " Andreas Gruenbacher 2019-08-14 20:42 ` [PATCH v5 04/18] fs: compat_ioctl: move FITRIM emulation into file systems Arnd Bergmann 2019-08-14 20:42 ` Arnd Bergmann 2019-08-14 20:42 ` [f2fs-dev] " Arnd Bergmann 2019-08-14 20:42 ` [Ocfs2-devel] " Arnd Bergmann 2019-08-14 20:42 ` [PATCH v5 05/18] watchdog: cpwd: use generic compat_ptr_ioctl Arnd Bergmann 2019-08-15 18:06 ` Guenter Roeck 2019-10-07 23:28 ` Guenter Roeck 2019-10-08 7:38 ` Arnd Bergmann 2019-08-14 20:49 ` [PATCH v5 06/18] compat_ioctl: move WDIOC handling into wdt drivers Arnd Bergmann 2019-08-14 20:49 ` Arnd Bergmann 2019-08-14 20:49 ` Arnd Bergmann 2019-08-15 18:10 ` Guenter Roeck 2019-08-15 18:10 ` Guenter Roeck 2019-08-15 18:10 ` Guenter Roeck 2019-08-14 20:49 ` [PATCH v5 07/18] compat_ioctl: reimplement SG_IO handling Arnd Bergmann 2019-08-14 20:49 ` [PATCH v5 08/18] af_unix: add compat_ioctl support Arnd Bergmann 2019-08-14 20:49 ` [PATCH v5 09/18] compat_ioctl: handle SIOCOUTQNSD Arnd Bergmann 2019-08-14 20:54 ` [PATCH v5 10/18] compat_ioctl: move SIOCOUTQ out of compat_ioctl.c Arnd Bergmann 2019-08-15 14:09 ` Greg Kroah-Hartman 2019-08-14 20:54 ` [PATCH v5 11/18] tty: handle compat PPP ioctls Arnd Bergmann 2019-08-15 14:09 ` Greg Kroah-Hartman 2019-08-14 20:54 ` [PATCH v5 12/18] compat_ioctl: unify copy-in of ppp filters Arnd Bergmann 2019-08-14 20:54 ` Arnd Bergmann 2019-08-14 20:54 ` [PATCH v5 13/18] compat_ioctl: move PPPIOCSCOMPRESS to ppp_generic Arnd Bergmann 2019-08-14 20:54 ` Arnd Bergmann 2019-08-14 20:54 ` [PATCH v5 14/18] compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t Arnd Bergmann 2019-08-14 20:54 ` Arnd Bergmann 2019-08-14 20:54 ` [PATCH v5 15/18] compat_ioctl: ppp: move simple commands into ppp_generic.c Arnd Bergmann 2019-08-14 20:54 ` Arnd Bergmann 2019-08-14 20:54 ` [PATCH v5 16/18] compat_ioctl: move SG_GET_REQUEST_TABLE handling Arnd Bergmann 2019-08-14 20:54 ` [PATCH v5 17/18] pktcdvd: add compat_ioctl handler Arnd Bergmann 2019-08-14 20:54 ` [PATCH v5 18/18] scsi: sd: enable compat ioctls for sed-opal Arnd Bergmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAHpGcMJ2EScNiPapyugC_fz+AEhdpKmx3VmYjTH_2me8WLxB2A@mail.gmail.com \ --to=andreas.gruenbacher@gmail.com \ --cc=agruenba@redhat.com \ --cc=arnd@arndb.de \ --cc=cluster-devel@redhat.com \ --cc=darrick.wong@oracle.com \ --cc=jack@suse.cz \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=neilb@suse.com \ --cc=rpeterso@redhat.com \ --cc=swhiteho@redhat.com \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.