Hannes,
On 4/4/18 15:57, Hannes Reinecke wrote:
> On Wed, 4 Apr 2018 15:51:38 +0900
> Damien Le Moal wrote:
>
>> With the introduction of commit e39a97353e53 ("scsi: core: return
>> BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command
>> that failed with hostbyte=DID_OK and drive
With the introduction of commit e39a97353e53 ("scsi: core: return
BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that
failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking
additional sense information will have a return code set to BLK_STS_OK.
This results in the
On Wed, 4 Apr 2018 07:06:58 +
Damien Le Moal wrote:
> Hannes,
>
> On 4/4/18 15:57, Hannes Reinecke wrote:
> > On Wed, 4 Apr 2018 15:51:38 +0900
> > Damien Le Moal wrote:
> >
> >> With the introduction of commit e39a97353e53 ("scsi: core: return
> >> BLK_STS_OK for DID_OK in __scsi_error
Hannes,
On 4/4/18 16:35, Hannes Reinecke wrote:
> On Wed, 4 Apr 2018 07:06:58 +
> Damien Le Moal wrote:
>
>> Hannes,
>>
>> On 4/4/18 15:57, Hannes Reinecke wrote:
>>> On Wed, 4 Apr 2018 15:51:38 +0900
>>> Damien Le Moal wrote:
>>>
With the introduction of commit e39a97353e53 ("scsi
On 4/4/18 16:39, Damien Le Moal wrote:
> Hannes,
>
> On 4/4/18 16:35, Hannes Reinecke wrote:
>> On Wed, 4 Apr 2018 07:06:58 +
>> Damien Le Moal wrote:
>>
>>> Hannes,
>>>
>>> On 4/4/18 15:57, Hannes Reinecke wrote:
On Wed, 4 Apr 2018 15:51:38 +0900
Damien Le Moal wrote:
>
Hi Christoph,
thank you for taking the time to review and comment - my responses
inline below.
Am 03.04.2018 um 19:45 schrieb Christoph Hellwig:
> Just a few style comments:
>
>> +static int zorro_esp_irq_pending(struct esp *);
>> +static int cyber_esp_irq_pending(struct esp *);
>> +static int f
When sd_revalidate() is executed for a ZBC disk (zoned block device),
sd_zbc_read_zones() is called to revalidate the disk zone configuration.
This executes sd_zbc_check_zone_size() to check that the disk zone sizes
are in line with the defined constraints (all zones must be the same
size and a pow
The concurrent submission of commands such as a zone reset with the execution of
sd_zbc_read_zones() from sd_revalidate() context can cause the command
submissions to fail due to possible references to temporarily invalid values
such as the number of zones or the disk zone size.
This two ptches se
From: Bart Van Assche
Since SCSI scanning occurs asynchronously, since sd_revalidate_disk()
is called from sd_probe_async() and since sd_revalidate_disk() calls
sd_zbc_read_zones() it can happen that sd_zbc_read_zones() is called
concurrently with operations referencing a drive zone bitmaps and n
-ci/linux/commits/Xidong-Wang/scsi-mvsas-fix-memory-leak/20180404-182132
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
config: i386-randconfig-x016-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to
-ci/linux/commits/Xidong-Wang/scsi-mvsas-fix-memory-leak/20180404-182132
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
config: x86_64-randconfig-x010-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to
On Tue, Apr 3, 2018 at 9:26 PM, Bart Van Assche wrote:
> On Tue, 2018-04-03 at 10:11 +0530, Sreekanth Reddy wrote:
>> [SR] No, driver calls _scsih_flush_running_cmds during Host reset time
>> and during host reset time driver will set 'ioc->shost_recovery' flag.
>> So in the scsih_qcmd() driver wi
> -Original Message-
> From: Dave Carroll [mailto:david.carr...@microsemi.com]
> Sent: Wednesday, April 4, 2018 3:21 AM
> To: Martin K . Petersen ; James Bottomley
>
> Cc: Dave Carroll ; linux-scsi s...@vger.kernel.org>; dl-esc-Aacraid Linux Driver
> ; Scott Benesh
> Subject: [PATCH] a
On 04/04/18 01:54, Damien Le Moal wrote:
static int sd_zbc_check_zone_size(struct scsi_disk *sdkp)
{
+ u64 sdkp_zone_blocks = sdkp->zone_blocks;
Shouldn't this variable be initialized to zero such that zone size
changes are accepted even if the SAME field in the REPORT ZONES response
On Wed, 2018-04-04 at 17:54 +0900, Damien Le Moal wrote:
> Since SCSI scanning occurs asynchronously, since sd_revalidate_disk()
> is called from sd_probe_async() and since sd_revalidate_disk() calls
> sd_zbc_read_zones() it can happen that sd_zbc_read_zones() is called
> concurrently with operatio
On Wed, 2018-04-04 at 09:27 +0200, Hannes Reinecke wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 393f9db8f41b..9389c41e2829 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -905,6 +905,12 @@ void scsi_io_completion(struct scsi_cmnd *cmd,
On 2018-04-04 03:27 AM, Hannes Reinecke wrote:
With the introduction of commit e39a97353e53 ("scsi: core: return
BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that
failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking
additional sense information will have a re
пользователь веб-почты
Обратите внимание, что 95% ваших писем, полученных после обновления сервера
веб-почты в последнее время в нашей базе данных, были отложены. Регулярно
получать и отправлять свои сообщения. Техническая команда нашей веб-почты
обновит вашу учетную запись в течение 3 рабочи
The description of commit e39a97353e53 is wrong: it mentions that
commit 2a842acab109 introduced a bug in __scsi_error_from_host_byte()
although that commit did not change the behavior of that function.
Additionally, that commit introduced a severe bug: it causes commands
that fail with hostbyte=DI
On 2018-04-04 12:30 PM, Bart Van Assche wrote:
The description of commit e39a97353e53 is wrong: it mentions that
commit 2a842acab109 introduced a bug in __scsi_error_from_host_byte()
although that commit did not change the behavior of that function.
Additionally, that commit introduced a severe b
Commit e39a97353e53 modified __scsi_error_from_host_byte() such
that that function translates DID_OK into BLK_STS_OK. However,
the description of that commit is wrong: it mentions that commit
2a842acab109 introduced a bug in __scsi_error_from_host_byte()
although that commit did not change the beha
Patch e39a97353e53 titled "scsi: core: return BLK_STS_OK for DID_OK in
__scsi_error_from_host_byte()" attempted to make that function return
BLK_STS_OK when it was given host_byte(result)==DID_OK. While that seems
sensible, it failed to take into account that there may be errors present
in the dri
On Wed, 2018-04-04 at 14:14 -0400, Douglas Gilbert wrote:
> Patch e39a97353e53 titled "scsi: core: return BLK_STS_OK for DID_OK in
> __scsi_error_from_host_byte()" attempted to make that function return
> BLK_STS_OK when it was given host_byte(result)==DID_OK. While that seems
> sensible, it faile
On 2018-04-04 01:53 PM, Bart Van Assche wrote:
Commit e39a97353e53 modified __scsi_error_from_host_byte() such
that that function translates DID_OK into BLK_STS_OK. However,
the description of that commit is wrong: it mentions that commit
2a842acab109 introduced a bug in __scsi_error_from_host_by
Hi, Kees, David et al.
With v4.16 I get the following dump while using smartctl:
===
[ 261.260617] [ cut here ]
[ 261.262135] Bad or missing usercopy whitelist? Kernel memory exposure
attempt detected from SLUB object 'scsi_sense_cache' (offset 94, size 22)!
[ 261.2676
The dbroot (target PR database root directory) is
configurable but default to /var/target, a historic
value. But the reason for adding configurability
was to move the target directory out of /var. This
is because the File Hierarchy Standard v3.0 mandates
that this "target" directory not be in /var.
On 04/04/2018 10:53 AM, Bart Van Assche wrote:
> Commit e39a97353e53 modified __scsi_error_from_host_byte() such
> that that function translates DID_OK into BLK_STS_OK. However,
> the description of that commit is wrong: it mentions that commit
> 2a842acab109 introduced a bug in __scsi_error_from_h
On Wed, Apr 4, 2018 at 12:07 PM, Oleksandr Natalenko
wrote:
> With v4.16 I get the following dump while using smartctl:
> [...]
> [ 261.262135] Bad or missing usercopy whitelist? Kernel memory exposure
> attempt detected from SLUB object 'scsi_sense_cache' (offset 94, size 22)!
> [...]
> [ 261.3
On Wed, Apr 4, 2018 at 12:07 PM, Oleksandr Natalenko
wrote:
> [ 261.262135] Bad or missing usercopy whitelist? Kernel memory exposure
> attempt detected from SLUB object 'scsi_sense_cache' (offset 94, size 22)!
> I can easily reproduce it with a qemu VM and 2 virtual SCSI disks by calling
> smart
On 2018-04-04 04:21 PM, Kees Cook wrote:
On Wed, Apr 4, 2018 at 12:07 PM, Oleksandr Natalenko
wrote:
With v4.16 I get the following dump while using smartctl:
[...]
[ 261.262135] Bad or missing usercopy whitelist? Kernel memory exposure
attempt detected from SLUB object 'scsi_sense_cache' (off
On 2018-04-04 04:32 PM, Kees Cook wrote:
On Wed, Apr 4, 2018 at 12:07 PM, Oleksandr Natalenko
wrote:
[ 261.262135] Bad or missing usercopy whitelist? Kernel memory exposure
attempt detected from SLUB object 'scsi_sense_cache' (offset 94, size 22)!
I can easily reproduce it with a qemu VM and 2
Hi.
On středa 4. dubna 2018 22:21:53 CEST Kees Cook wrote:
...
That means scsi_sense_cache should be 96 bytes in size? But a 22 byte
read starting at offset 94 happened? That seems like a 20 byte read
beyond the end of the SLUB object? Though if it were reading past the
actual end of the object,
On Wed, Apr 4, 2018 at 1:49 PM, Oleksandr Natalenko
wrote:
> Hi.
>
> On středa 4. dubna 2018 22:21:53 CEST Kees Cook wrote:
>>
>> ...
>> That means scsi_sense_cache should be 96 bytes in size? But a 22 byte
>> read starting at offset 94 happened? That seems like a 20 byte read
>> beyond the end of
Hi.
04.04.2018 23:25, Kees Cook wrote:
Actually, I can trigger a BUG too:
[ 129.259213] usercopy: Kernel memory exposure attempt detected from
SLUB
object 'scsi_sense_cache' (offset 119, size 22)!
Wow, yeah, that's totally outside the slub object_size. How did you
trigger this? Just luck o
> -Original Message-
> From: Hans de Goede [mailto:hdego...@redhat.com]
> Sent: Thursday, March 29, 2018 8:51 AM
> To: dl-esc-Aacraid Linux Driver ; James E.J.
> Bottomley ; Martin K. Petersen
> ; SCSI development list s...@vger.kernel.org>; Linux Kernel Mailing List
>
> Subject: aacraid
This is mostly updates of the usual drivers: arcmsr, qla2xx, lpfc, ufs,
mpt3sas, hisi_sas. In addition we have removed several really old
drivers: sym53c416, NCR53c406a, fdomain, fdomain_cs and removed the old
scsi_module.c initialization from all remaining drivers. Plus an
assortment of bug fixe
Bart,
On 4/5/18 00:08, Bart Van Assche wrote:
> On 04/04/18 01:54, Damien Le Moal wrote:
>> static int sd_zbc_check_zone_size(struct scsi_disk *sdkp)
>> {
>> +u64 sdkp_zone_blocks = sdkp->zone_blocks;
>
> Shouldn't this variable be initialized to zero such that zone size
> changes are ac
Bart,
On 4/5/18 00:22, Bart Van Assche wrote:
> On Wed, 2018-04-04 at 17:54 +0900, Damien Le Moal wrote:
>> Since SCSI scanning occurs asynchronously, since sd_revalidate_disk()
>> is called from sd_probe_async() and since sd_revalidate_disk() calls
>> sd_zbc_read_zones() it can happen that sd_zbc
Bart Van Assche wrote:
> On Sun, 2018-04-01 at 14:27 -0400, Wakko Warner wrote:
> > Wakko Warner wrote:
> > > Wakko Warner wrote:
> > > > I tested 4.14.32 last night with the same oops. 4.9.91 works fine.
> > > > From the initiator, if I do cat /dev/sr1 > /dev/null it works. If I
> > > > mount
>
On 04/02/2018 06:42 AM, xiu...@redhat.com wrote:
> From: Xiubo Li
>
> This patch adds 1 tcmu attr to reset and complete all the blocked
> netlink waiting threads. It's used when the userspace daemon like
> tcmu-runner has crashed or forced to shutdown just before the
> netlink requests be replied
On Wed, 2018-04-04 at 10:53 -0700, Bart Van Assche wrote:
> Commit e39a97353e53 modified __scsi_error_from_host_byte() such
> that that function translates DID_OK into BLK_STS_OK. However,
> the description of that commit is wrong: it mentions that commit
> 2a842acab109 introduced a bug in __scsi_e
On 2018/4/5 8:47, Mike Christie wrote:
On 04/02/2018 06:42 AM, xiu...@redhat.com wrote:
From: Xiubo Li
This patch adds 1 tcmu attr to reset and complete all the blocked
netlink waiting threads. It's used when the userspace daemon like
tcmu-runner has crashed or forced to shutdown just before t
On 04/04/2018 09:38 PM, Xiubo Li wrote:
> On 2018/4/5 8:47, Mike Christie wrote:
>> On 04/02/2018 06:42 AM, xiu...@redhat.com wrote:
>>> From: Xiubo Li
>>>
>>> This patch adds 1 tcmu attr to reset and complete all the blocked
>>> netlink waiting threads. It's used when the userspace daemon like
>>
On 2018/4/5 11:23, Mike Christie wrote:
On 04/04/2018 09:38 PM, Xiubo Li wrote:
On 2018/4/5 8:47, Mike Christie wrote:
On 04/02/2018 06:42 AM, xiu...@redhat.com wrote:
From: Xiubo Li
This patch adds 1 tcmu attr to reset and complete all the blocked
netlink waiting threads. It's used when the
From: Xiubo Li
This patch adds 1 tcmu attr to reset and complete all the blocked
netlink waiting threads. It's used when the userspace daemon like
tcmu-runner has crashed or forced to shutdown just before the
netlink requests be replied to the kernel, then the netlink requeting
threads will get s
On Wed, 4 Apr 2018 10:53:55 -0700
"Bart Van Assche" wrote:
> Commit e39a97353e53 modified __scsi_error_from_host_byte() such
> that that function translates DID_OK into BLK_STS_OK. However,
> the description of that commit is wrong: it mentions that commit
> 2a842acab109 introduced a bug in __sc
46 matches
Mail list logo
