On Fri, Nov 10, 2017 at 08:51:58AM -0800, James Bottomley wrote:
> On Fri, 2017-11-10 at 17:01 +0800, Ming Lei wrote:
> > cmd->cmnd can be allocated/freed dynamically in case of
> > T10_PI_TYPE2_PROTECTION,
> > so we should check it in scsi_show_rq() because this request may have
> > been freed alr
On Fri, Nov 10, 2017 at 7:58 AM, Arnd Bergmann wrote:
> The calculation of the number of seconds since Sunday 00:00:00 overflows
> in 2106, meaning that we instead will return the seconds since Wednesday
> 06:28:16 afterwards.
>
> Using 64-bit time stamps avoids this slight inconsistency, and the
On Fri, Nov 10, 2017 at 7:58 AM, Arnd Bergmann wrote:
> twl_aen_queue_event/twa_aen_queue_event, we use do_gettimeofday()
> to read the lower 32 bits of the current time in seconds, to pass
> them to the TW_IOCTL_GET_NEXT_EVENT ioctl or the 3ware_aen_read
> sysfs file.
>
> This will overflow on al
On Fri, Nov 10, 2017 at 7:58 AM, Arnd Bergmann wrote:
> The TW_IOCTL_GET_LOCK ioctl uses do_gettimeofday() to check whether
> a lock has expired. This can misbehave due to a concurrent
> settimeofday() call, as it is based on 'real' time, and it
> will overflow in y2038 on 32-bit architectures, pr
The bfa drivers are in deep maintenance mode for some time now. We have not had
issues reported on them for a while, but it would be good to continue to have
them.
The series looks ok to me too.
Thanks,
Anil
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: 10 Nove
This stuff look ok - but I have a bigger question and that is if
bfa is still alive at all. Everytime I look at it I have doubts if
it works at all, so I wonder if we need to keep it on life support.
On Fri, 2017-11-10 at 17:01 +0800, Ming Lei wrote:
> cmd->cmnd can be allocated/freed dynamically in case of
> T10_PI_TYPE2_PROTECTION,
> so we should check it in scsi_show_rq() because this request may have
> been freed already here, and cmd->cmnd has been set as null.
>
> We choose to accept rea
-ci/linux/commits/Michal-Potomski/scsi-ufs-Fix-Runtime-PM/20171110-191314
base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: x86_64-randconfig-v0-11102116 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached
twl_aen_queue_event/twa_aen_queue_event, we use do_gettimeofday()
to read the lower 32 bits of the current time in seconds, to pass
them to the TW_IOCTL_GET_NEXT_EVENT ioctl or the 3ware_aen_read
sysfs file.
This will overflow on all architectures in year 2106, there is
not much we can do about th
The calculation of the number of seconds since Sunday 00:00:00 overflows
in 2106, meaning that we instead will return the seconds since Wednesday
06:28:16 afterwards.
Using 64-bit time stamps avoids this slight inconsistency, and the
deprecated do_gettimeofday(), replacing it with the simpler
ktim
The TW_IOCTL_GET_LOCK ioctl uses do_gettimeofday() to check whether
a lock has expired. This can misbehave due to a concurrent
settimeofday() call, as it is based on 'real' time, and it
will overflow in y2038 on 32-bit architectures, producing
unexpected results when used across the overflow time.
do_gettimeofday() overflows in 2038 on 32-bit architectures and
is deprecated, so convert this driver to call ktime_get_real()
directly. This also simplifies the calculation.
Signed-off-by: Arnd Bergmann
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 7 +++
1 file changed, 3 insertions(+)
do_gettimeofday() is deprecated since it will stop working in 2038 on
32-bit platforms. The firmware interface here actually supports times
until year 25500, so we should use longer timestamps.
Using ktime_get_real_seconds() to get a 64-bit seconds value
and time64_to_tm() to convert it into the r
The bfa driver is one of the main users of do_gettimeofday(), a function
that I'm trying to remove as part of the y2038 cleanup.
The timestamps are all uses in slightly different ways, so this has turned
into a rather longish series for doing something that should be simple.
The last patch in the
We use the deprecated do_gettimeofday() function to read the
current time when resetting the statistics in both bfa_port
and bfa_svc. This works fine because overflow is handled
correctly, but we want to get rid of do_gettimeofday() and
using a non-monotonic time suffers from concurrent
settimeofda
do_gettimeofday() is deprecated because of the y2038 overflow.
Here, we use the result to pass into a 32-bit field in the firmware,
which still risks an overflow, but if the firmware is written
to expect unsigned values, it can at least last until y2106,
and there is not much we can do about it.
T
io_profile_start_time() gets read using do_gettimeofday() and passed
down as a 32-bit value through multiple functions. This will overflow
in y2038 or y2106, depending on whether it gets interpreted as
unsigned in the end.
This changes do_gettimeofday() to ktime_get_real_seconds() and pushes
the p
BFA_TRC_TS() calculates a 32-bit microsecond timestamp using the
deprecated do_gettimeofday() function. This overflows roughly every
71 minutes, so it's obviously not used as an absolute time stamp,
but it seems wrong to use a time base for it that will jump
during settimeofday() calls, leap second
bfa_aen_entry_s is passed to user space in a netlink message, but
is defined using a 'struct timeval' and an 'enum' that are not only
different between architectures, but also between 32-bit user space and
64-bit kernels they may run on, as well as depending on the particular
C library that defines
The bfa_get_log_time() returns a 64-bit timestamp that does not
suffer from the y2038 overflow on 64-bit systems. However, on 32-bit
architectures the timestamp will jump from 0x7fff
to 0x8000 in y2038 and produce wrong results.
The ktime_get_real_seconds() function does th
bfa_aen_entry_s is passed through a netlink socket that can be read
by either 32-bit or 64-bit processes, but the data format is different
between the two on current implementations.
Originally, this was using a 'struct timeval', which also suffers from
getting redefined with a new libc implementa
In bfa_ioc_send_enable, we use the deprecated do_gettimeofday() function
to read the current time. This is not a problem, since the firmware
interface is already limited to 32-bit timestamps, but it's better
to use ktime_get_seconds() and document what the limitation is.
I noticed that I did the s
Just like all previous UAS capable Seagate disk enclosures, this
one needs a US_FL_NO_ATA_1X quirk.
Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Andrey Astafyev <1...@246060.ru>
Signed-off-by: Hans de Goede
---
drivers/usb/storage/unusual_uas.h | 7 +++
1 file changed, 7 insertions(+)
d
/commits/Michal-Potomski/scsi-ufs-Fix-Runtime-PM/20171110-191314
base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https
> diff --git a/drivers/net/ethernet/broadcom/b44.c
> b/drivers/net/ethernet/broadcom/b44.c
> index a1125d1..2f6ffe5 100644
> --- a/drivers/net/ethernet/broadcom/b44.c
> +++ b/drivers/net/ethernet/broadcom/b44.c
> @@ -2344,6 +2344,10 @@ static int b44_init_one(struct ssb_device *sdev,
> struc
cmd->cmnd can be allocated/freed dynamically in case of T10_PI_TYPE2_PROTECTION,
so we should check it in scsi_show_rq() because this request may have
been freed already here, and cmd->cmnd has been set as null.
We choose to accept read-after-free and dump request data as far as possible.
This pa
26 matches
Mail list logo
