On Tue, Jan 07, 2020 at 10:16:14AM -0800, Darrick J. Wong wrote:
> Yeah. Fixing that (and maybe adding an ioctl to set the FS UUID online)
> were on my list for 5.6 but clearly I have to defer everything until 5.7
> because we've just run out of time.
>
> Uh... I started looking into unifying
On Thu, Jan 02, 2020 at 10:07:49AM -0800, Darrick J. Wong wrote:
> > Sorry I missed that comment earlier. I've had a fresh look now, but
> > I think we still need to deprecate XFS_IOC_SWAPEXT and add a
> > v5 version of it, since the comparison will fail as soon as the range
> > of the inode
Looks good,
Reviewed-by: Christoph Hellwig
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
On Thu, Jan 02, 2020 at 09:34:48PM +0100, Arnd Bergmann wrote:
> I tried adding the helper now but ran into a stupid problem: the best
> place to put it would be linux/time32.h, but then I have to include
> linux/compat.h from there, which in turn pulls in tons of other
> headers in any file using
On Wed, Dec 18, 2019 at 05:39:29PM +0100, Arnd Bergmann wrote:
> +/* disallow y2038-unsafe ioctls with CONFIG_COMPAT_32BIT_TIME=n */
> +static bool xfs_have_compat_bstat_time32(unsigned int cmd)
> +{
> + if (IS_ENABLED(CONFIG_COMPAT_32BIT_TIME))
> + return true;
> +
> + if
ick J. Wong
> Signed-off-by: Arnd Bergmann
Looks good,
Reviewed-by: Christoph Hellwig
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
> +#ifdef CONFIG_COMPAT
> +static int compat_put_ushort(unsigned long arg, unsigned short val)
> +{
> + return put_user(val, (unsigned short __user *)compat_ptr(arg));
> +}
> +
> +static int compat_put_int(unsigned long arg, int val)
> +{
> + return put_user(val, (compat_int_t __user
> +static int put_user_long(long val, unsigned long arg)
> +{
> +#ifdef CONFIG_COMPAT
> + if (in_compat_syscall())
> + return put_user(val, (compat_long_t __user *)compat_ptr(arg));
> +#endif
> + return put_user(val, (long __user *)arg);
> +}
We had this
#ifdef CONFIG_COMPAT
On Thu, Dec 12, 2019 at 01:28:08AM +0100, Paolo Bonzini wrote:
> I think it's because the only ioctl for virtio-blk is SG_IO. It makes
> sense to lump it in with scsi, but I wouldn't mind getting rid of
> CONFIG_VIRTIO_BLK_SCSI altogether.
CONFIG_VIRTIO_BLK_SCSI has been broken for about two
On Wed, Dec 11, 2019 at 09:42:36PM +0100, Arnd Bergmann wrote:
> In the v5.4 merge window, a cleanup patch from Al Viro conflicted
> with my rework of the compat handling for sg.c read(). Linus Torvalds
> did a correct merge but pointed out that the resulting code is still
> unsatisfactory.
>
> I
Amir just send another patch dealing with the time stamps. I'd suggest
you chime into the discussion in that thread.
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
nly to get the time_t out of the ABI..
Reviewed-by: Christoph Hellwig
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
> The conversion does not include the old 64-bit sh5 architecture, which
> has never shipped and not even compiled in a long time.
Maybe it is time to drop the code for it then?
___
Y2038 mailing list
Y2038@lists.linaro.org
On Fri, Dec 07, 2018 at 02:48:17PM +0100, Arnd Bergmann wrote:
> The dreamcast RTC support has an extra level of indirection to
> provide either the old read_persistent_clock/update_persistent_clock
> interface or the rtc-generic device for hctosys/systohc.
s/dreamcast/sh/ in the above sentence?
On Thu, Sep 20, 2018 at 08:48:37PM +, Paul Burton wrote:
> > Speaking of nanoMIPS, what is your plan for the syscall ABI there?
> > I can see two ways of approaching it:
> >
> > a) keep all the MIPSisms in the data structures, and just use a subset of
> > o32 that drops all the obsolete
On Tue, Aug 21, 2018 at 10:33:00PM +0200, Arnd Bergmann wrote:
> As part of the system call rework for 64-bit time_t, we are restructuring
> the way that compat syscalls deal with 32-bit time_t, reusing the
> implementation for 32-bit architectures. Christoph Hellwig suggested
&
On Mon, Jul 16, 2018 at 12:11:53PM +0200, Arnd Bergmann wrote:
> I don't think it makes a big difference whether we change it now or later,
> but if Christoph feels that it addresses his concern about the compat_
> namespace being reused during the transition, doing it earlier would
> enable us to
On Mon, Jul 16, 2018 at 06:10:52PM +0200, Arnd Bergmann wrote:
> When 32-bit architectures get changed to support 64-bit time_t,
> utimensat() needs to use the new __kernel_timespec structure as its
> argument.
>
> The older utime(), utimes() and futimesat() system calls don't need a
>
"consolidate cond_syscall and SYSCALL_ALIAS declarations")
> and should not be used anyway.
Looks good,
Reviewed-by: Christoph Hellwig
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
> select CONFIG_COMPAT, so the #if check is still correct here. It's
> a bit odd to include it in the syscall table though, as it's the
> same as sys_lseek() on 64-bit, but with strange calling conventions.
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Jul 16, 2018 at 06:10:48PM +0200, Arnd Bergmann wrote:
> We have four generations of stat() syscalls:
> - the oldstat syscalls that are only used on the older architectures
> - the newstat family that is used on all 64-bit architectures but
> lacked support for large files on 32-bit
l have not decided whether the 32-bit time handling
> will always use the compat syscalls, or in which form, I think this
> is a useful cleanup that we can merge regardless.
Looks good:
Reviewed-by: Christoph Hellwig
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
On Fri, Jul 06, 2018 at 01:42:46PM +0200, Arnd Bergmann wrote:
> We can also rename all the compat syscalls that are now shared
> with 32-bit, e.g. using sys_waitid_time32() instead of
> compat_sys_waitid(), and that would be consistent with the
> new _time64() naming that we are introducing for
On Fri, Jul 06, 2018 at 10:42:47PM -0700, Deepa Dinamani wrote:
> struct timex is not y2038 safe.
> Switch all the syscall apis to use y2038 safe __kernel_timex.
So you switch existing syscalls to use a different structure.
If this actually happens to be safe it needs a big explanation
in the
On Fri, Jul 06, 2018 at 10:42:46PM -0700, Deepa Dinamani wrote:
> struct timex is not y2038 safe.
> Replace all uses of timex with y2038 safe __kernel_timex.
>
> Note that struct __kernel_timex is an ABI interface definition.
If it actually is an ABI interface it should probably have a different
I don't think this patches makes sense without the next one,
which actually uses the structure.
> +/* CONFIG_64BIT_TIME enables new 64 bit time_t syscalls in the compat path
> + * and 32-bit emulation.
> + */
Wrong comment style, also the 'compat path is the 32 (or 31 in case of
s390) bit
On Fri, Jul 06, 2018 at 10:42:41PM -0700, Deepa Dinamani wrote:
> As we repurpose more compat syscalls to be used in non CONFIG_COMPAT
> usecases as part of solving y2038, we need to make these basic types
> available unconditionally.
NAK. Compat code is for foreign ABIs. If this code is going
Looks good,
Reviewed-by: Christoph Hellwig
>
> Now that time compat syscalls are being reused in non CONFIG_COMPAT
> modes, asm-generic/compat.h provides definitions for riscv 32 bit
> mode.
>
> Alternative would be to make compat_time.h to be conditional on
> CONFIG_COMPAT_
On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
> defconfig, allmodconfig and nomodconfig.
> And hence does not inlude definitions for compat data types.
>
> Now that time syscalls are being reused in non CONFIG_COMPAT
> modes, include asm-generic definitions for riscv.
>
>
On Wed, Jan 10, 2018 at 04:48:05PM +0100, Arnd Bergmann wrote:
> Ok, fair enough. Given that the old version gets obsoleted by this
> one, it shouldn't get much uglier than it already is here when you
> start out with a regular timespec. We just need to be aware of possible
> clashes when we get
On Wed, Jan 10, 2018 at 12:03:24PM +0100, Arnd Bergmann wrote:
> I'd suggest passing a variant of timespec with two 64-bit members.
> Deepa has posted patches for this structure in the past and was planning
> to do a new version (with minor changes from review) soon, but we
> can just well use it
On Tue, Jan 09, 2018 at 11:16:16PM +0100, Arnd Bergmann wrote:
> Hmm, these two new syscall entry points turn into four when we add in
> support for 64-bit time_t, as we'd have to support all combinations of 32/64
> bit aio_context_t and time_t.
At least they'll also replace plain old
32 matches
Mail list logo
