When building a kernel that disables support for 32-bit time_t
system calls, it also makes sense to disable the old xfs_bstat
ioctls completely, as they truncate the timestamps to 32-bit
values once the extended times are supported.
Any application using these needs to be updated to use the v5
int
The compat_time_t type has been removed everywhere else,
as most users rely on old_time32_t for both native and
compat mode handling of 32-bit time_t.
Remove the last one in xfs.
Reviewed-by: Darrick J. Wong
Signed-off-by: Arnd Bergmann
---
fs/xfs/xfs_ioctl32.c | 2 +-
fs/xfs/xfs_ioctl32.h | 2
On Tue, Dec 17, 2019 at 11:18 PM Darrick J. Wong
wrote:
> On Tue, Dec 17, 2019 at 04:02:47PM +0100, Arnd Bergmann wrote:
> > On Mon, Dec 16, 2019 at 5:52 PM Arnd Bergmann wrote:
> > > On Fri, Dec 13, 2019 at 10:17 PM Darrick J. Wong
> > > wrote:
> > >>
> > >> Hmm, so one thing that I clean up o
As a preparation for removing the 32-bit time_t type and
all associated interfaces, change xfs to use time64_t and
ktime_get_real_seconds() for the quota housekeeping.
This avoids one difference between 32-bit and 64-bit kernels,
raising the theoretical limit for the quota grace period
to year 210
On Fri, Dec 13, 2019 at 3:12 PM Arnd Bergmann wrote:
>
> Hi Bruce, Chuck,
>
> NFSd is one of the last areas of the kernel that is not y2038 safe
> yet, this series addresses the remaining issues here.
>
> I did not get any comments for the first version I posted [1], and
> I hope this just means t
On Tue, Dec 17, 2019 at 11:17 PM Arnd Bergmann wrote:
> My plan was originally to keep the SCSI and block parts separate.
> This did not work easily because of interdependencies: I cannot
> do the final SCSI cleanup in a good way without first addressing the
> CDROM ioctls, so this is one series t
On Wed, Dec 18, 2019 at 06:21:06PM +0100, Arnd Bergmann wrote:
> On Fri, Dec 13, 2019 at 3:12 PM Arnd Bergmann wrote:
> >
> > Hi Bruce, Chuck,
> >
> > NFSd is one of the last areas of the kernel that is not y2038 safe
> > yet, this series addresses the remaining issues here.
> >
> > I did not get
On Wed, Dec 18, 2019 at 6:25 PM J. Bruce Fields wrote:
> On Wed, Dec 18, 2019 at 06:21:06PM +0100, Arnd Bergmann wrote:
> > On Fri, Dec 13, 2019 at 3:12 PM Arnd Bergmann wrote:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
> > y2038-nfsd-v2
> >
> > in my y2038 branch
On Tue, 2019-12-17 at 23:16 +0100, Arnd Bergmann wrote:
> Rather than relying on fs/compat_ioctl.c, this adds support
> for a compat_ioctl() callback in the ide-floppy driver directly,
> which lets it translate the scsi commands.
[...]
After this, and before "compat_ioctl: move HDIO ioctl handling
On Wed, Dec 18, 2019 at 7:45 PM Ben Hutchings
wrote:
>
> On Tue, 2019-12-17 at 23:16 +0100, Arnd Bergmann wrote:
> > Rather than relying on fs/compat_ioctl.c, this adds support
> > for a compat_ioctl() callback in the ide-floppy driver directly,
> > which lets it translate the scsi commands.
> [..
On Tue, 2019-12-17 at 23:16 +0100, Arnd Bergmann wrote:
[...]
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
[...]
> @@ -598,6 +599,55 @@ static int sr_block_ioctl(struct block_device *bdev,
> fmode_t mode, unsigned cmd,
> return ret;
> }
>
> +#ifdef CONFIG_COMPAT
> +static int sr_bl
On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote:
[...]
> @@ -1710,6 +1711,38 @@ static int idecd_ioctl(struct block_device *bdev,
> fmode_t mode,
> return ret;
> }
>
> +#ifdef CONFIG_COMPAT
> +static int idecd_locked_compat_ioctl(struct block_device *bdev, fmode_t mode,
> +
I looked at this more closely. Here is the patch that added the sysctl
to the kernel previously: https://lkml.org/lkml/2016/11/2/300.
This was meant to be configurable earlier. That is why this made
sense. But, now it is not. We unconditionally clamp to the fs limits.
I looked around to see if we
On Wed, Dec 18, 2019 at 10:21 PM Deepa Dinamani wrote:
>
> I looked at this more closely. Here is the patch that added the sysctl
> to the kernel previously: https://lkml.org/lkml/2016/11/2/300.
>
> This was meant to be configurable earlier. That is why this made
> sense. But, now it is not. We un
On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote:
> Most of the HDIO ioctls are only used by the obsolete drivers/ide
> subsystem, these can be handled by changing ide_cmd_ioctl() to be aware
> of compat mode and doing the correct transformations in place and using
> it as both native and com
On Wed, Dec 18, 2019 at 10:11 PM Ben Hutchings
wrote:
> On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote:
> > Most of the HDIO ioctls are only used by the obsolete drivers/ide
> > subsystem, these can be handled by changing ide_cmd_ioctl() to be aware
> > of compat mode and doing the correct
On Wed, 2019-12-18 at 23:17 +0100, Arnd Bergmann wrote:
> On Wed, Dec 18, 2019 at 10:11 PM Ben Hutchings
> wrote:
> > On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote:
> > > Most of the HDIO ioctls are only used by the obsolete drivers/ide
> > > subsystem, these can be handled by changing id
On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote:
[...]
> --- /dev/null
> +++ b/Documentation/core-api/ioctl.rst
> @@ -0,0 +1,248 @@
> +==
> +ioctl based interfaces
> +==
> +
> +ioctl() is the most common way for applications to interface
> +with device
Hi Arnd!
> Any suggestion for how this should be merged?
I'm pretty flexible. When you post v3 I'll try to set up a branch to get
an idea what conflicts we might have to deal with. And then we can take
it from there.
--
Martin K. Petersen Oracle Linux Engineering
_
19 matches
Mail list logo
