On Wed, Nov 25, 2015 at 04:22:25PM +0100, Arnd Bergmann wrote:
> struct timeval on 32-bit systems will have its tv_sec
> value overflow in year 2038 and beyond.
> Use a 64 bit value to print time of the coredump in seconds.
> ktime_get_real_seconds is chosen here for efficiency reasons.
>
> Sugges
On Wed, Sep 14, 2016 at 09:45:55AM -0700, Linus Torvalds wrote:
> On Wed, Sep 14, 2016 at 7:48 AM, Deepa Dinamani
> wrote:
> > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC
> > macros.
> > The macros are not y2038 safe. There is no plan to transition them into
> > bein
On Sat, Feb 18, 2017 at 03:30:04PM -0800, Deepa Dinamani wrote:
> Add fields to the superblock to track the min and max
> timestamps supported by filesystems.
>
> Initially, when a superblock is allocated, initialize
> it to the max and min values the fields can hold.
> Individual filesystems over
On Sun, Jun 18, 2017 at 11:45:07PM -0700, Deepa Dinamani wrote:
> The series aims at isolating data conversions of time_t based structures:
> struct timespec and struct itimerspec at user space boundaries.
> This helps to later change the underlying types to handle y2038 changes
> to these.
>
> Th
On Mon, Jun 19, 2017 at 12:31:00PM -0700, Deepa Dinamani wrote:
> 3. I was also aiming for user pointers to be not touched by timer
> specific code as it can get messy if not handled properly with 2
> compat time_t versions.
So have one helper that deals with all copyout and have it used by
all
On Mon, Jun 19, 2017 at 01:52:05PM -0700, Deepa Dinamani wrote:
> On Mon, Jun 19, 2017 at 12:46 PM, Al Viro wrote:
> > On Mon, Jun 19, 2017 at 12:31:00PM -0700, Deepa Dinamani wrote:
> >
> >> 3. I was also aiming for user pointers to be not touched by timer
> >>
On Sat, Jun 24, 2017 at 11:45:01AM -0700, Deepa Dinamani wrote:
> The series aims at isolating data conversions of time_t based structures:
> struct timespec and struct itimerspec at user space boundaries.
> This helps to later change the underlying types to handle y2038 changes
> to these.
Nice..
On Mon, Jun 26, 2017 at 03:35:25AM +0100, Al Viro wrote:
> On Sat, Jun 24, 2017 at 11:45:01AM -0700, Deepa Dinamani wrote:
> > The series aims at isolating data conversions of time_t based structures:
> > struct timespec and struct itimerspec at user space boundaries.
> >
On Tue, Nov 07, 2017 at 03:09:24PM +0100, Arnd Bergmann wrote:
> There was a typo in the new version of put_tv32() that caused
> uninitialized stack data to be written back to user space, rather
> than writing the actual timeval for the emulation of
> gettimeofday(), wait4(), usleep_thread() and ol
't been replaced with sys_ni_syscall() everywhere
is that extra twist needed in case of syscall #0.
Let's keep it only for syscall #0 and replace the rest with sys_ni_syscall.
And use sys_ni_syscall for "number out range" in ptraced-call case, as
we'd been doing f
On Fri, Aug 10, 2018 at 07:31:55PM -0700, Richard Henderson wrote:
> > +++ b/arch/alpha/kernel/entry.S
> > @@ -473,7 +473,7 @@ entSys:
> > bne $3, strace
> > beq $4, 1f
> > ldq $27, 0($5)
> > -1: jsr $26, ($27), alpha_ni_syscall
> > +1: jsr $26, ($27), sys_ni_syscal
On Fri, Aug 10, 2018 at 09:10:04PM -0700, Richard Henderson wrote:
> On 08/10/2018 07:45 PM, Al Viro wrote:
> > BTW, seeing that it's your code - why was unop used in
> > alpha_ni_syscall? I don't remember the rules re pipeline
> > stalls; is it that some earlier
On Mon, Jul 16, 2018 at 03:53:53PM +0530, Firoz Khan wrote:
> It is correct to keep __IGNORE* entry in non uapi header
> asm/unistd.h while uapi/asm/unistd.h must hold information
> only useful for user space applications.
> diff --git a/arch/alpha/include/uapi/asm/unistd.h
> b/arch/alpha/include
On Mon, Aug 27, 2018 at 10:03:09PM +0200, Arnd Bergmann wrote:
> +#ifdef CONFIG_COMPAT
> +#define RTC_IRQP_READ32 _IOR('p', 0x0b, compat_ulong_t)
> +#define RTC_IRQP_SET32 _IOW('p', 0x0c, compat_ulong_t)
> +#define RTC_EPOCH_READ32 _IOR('p', 0x0d, compat_ulong_t)
> +
On Tue, Apr 16, 2019 at 10:19:40PM +0200, Arnd Bergmann wrote:
> diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> index c708400fff4a..04252c3492ee 100644
> --- a/drivers/net/ppp/ppp_generic.c
> +++ b/drivers/net/ppp/ppp_generic.c
> @@ -899,6 +899,7 @@ static const struct
On Tue, Apr 16, 2019 at 10:19:42PM +0200, Arnd Bergmann wrote:
> +#ifdef CONFIG_COMPAT
> +struct ppp_option_data32 {
> + compat_caddr_t ptr;
Huh? compat_uptr_t, surely? I realize that compat_ioctl.c is bogus
that way right now, but let's not spread that crap into the places
where it's harde
On Tue, Apr 16, 2019 at 10:19:46PM +0200, Arnd Bergmann wrote:
> Many drivers have ioctl() handlers that are completely compatible between
> 32-bit and 64-bit architectures, except for the argument that is passed
> down from user space and may have to be passed through compat_ptr()
> in order to be
On Tue, Apr 16, 2019 at 10:19:48PM +0200, Arnd Bergmann wrote:
> A handful of drivers all have a trivial wrapper around their ioctl
> handler, but don't call the compat_ptr() conversion function at the
> moment. In practice this does not matter, since none of them are used
> on the s390 architectur
On Tue, Apr 16, 2019 at 10:19:49PM +0200, Arnd Bergmann wrote:
> The ceph_ioctl function is used both for files and directories, but only
> the files support doing that in 32-bit compat mode.
>
> For consistency, add the same compat handler to the dir operations
> as well.
>
> Reviewed-by: "Yan,
On Tue, Apr 16, 2019 at 10:25:35PM +0200, Arnd Bergmann wrote:
> +static int atyfb_compat_ioctl(struct fb_info *info, u_int cmd, u_long arg)
> +{
> + return atyfb_ioctl(info, cmd, (u_long)compat_ptr(arg));
> +}
> +#endif
Huh? Why isn't that using compat_ioctl_ptr()?
__
On Wed, Apr 17, 2019 at 10:27:00PM +0100, Al Viro wrote:
> On Tue, Apr 16, 2019 at 10:25:35PM +0200, Arnd Bergmann wrote:
> > +static int atyfb_compat_ioctl(struct fb_info *info, u_int cmd, u_long arg)
> > +{
> > + return atyfb_ioctl(info, cmd, (u_long)compat_ptr(arg)
On Thu, Apr 18, 2019 at 12:03:07AM +0200, Arnd Bergmann wrote:
> On Wed, Apr 17, 2019 at 11:13 PM Al Viro wrote:
> >
> > On Tue, Apr 16, 2019 at 10:19:40PM +0200, Arnd Bergmann wrote:
> > > diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
On Thu, Apr 18, 2019 at 12:53:00AM +0100, Al Viro wrote:
> Why would you want to duplicate large chunks of anything?
> The above is not even compile-tested, but... I can put
> together a patch if you wish. Or am I missing something
> here?
Actually, there's another broken p
On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> If I understand your patch description well, using compat_ptr_ioctl
> only works if the driver is not for s390, right?
No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
and be done with that; compat_ptr
On Thu, Apr 25, 2019 at 05:55:23PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr
On Fri, Apr 26, 2019 at 04:50:41PM +0200, Arnd Bergmann wrote:
> For some reason, the conversion of the VFS code away from 'struct timespec'
> left one function behind that still uses it, for absolutely no reason.
>
> Using timespec64 will make the atime update logic work correctly past
> y2038.
On Wed, Oct 09, 2019 at 09:10:11PM +0200, Arnd Bergmann wrote:
> Each of these drivers has a copy of the same trivial helper function to
> convert the pointer argument and then call the native ioctl handler.
>
> We now have a generic implementation of that, so use it.
I'd rather flipped your #7 (
On Thu, Oct 17, 2019 at 04:33:09PM +0200, Arnd Bergmann wrote:
> However, looking at this again after your comment I found a rather
> more serious bug in my new RTC_IRQP_SET handling: Any 64-bit
> machine can now bypass the permission check for RTC_IRQP_SET by
> calling RTC_IRQP_SET32 instead.
Yo
On Tue, Oct 22, 2019 at 12:26:09PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 22, 2019 at 6:34 AM Al Viro wrote:
> >
> > On Wed, Oct 09, 2019 at 09:10:11PM +0200, Arnd Bergmann wrote:
> > > Each of these drivers has a copy of the same trivial helper function to
> >
On Sun, Nov 24, 2019 at 09:31:45PM +0200, Amir Goldstein wrote:
> Push clamping timestamps down the call stack into notify_change(), so
> in-kernel callers like nfsd and overlayfs will get similar timestamp
> set behavior as utimes.
Makes sense; said that, shouldn't we go through ->setattr() inst
e don't need
to bother with that there, with notify_change() doing normalization
in all cases now (it already did for implicit case, since current_time()
clamps).
Suggested-by: Miklos Szeredi
Fixes: 42e729b9ddbb ("utimes: Clamp the timestamps before update")
31 matches
Mail list logo
