Re: [PATCH 2/2] scsi: ufs: add inline crypto support to UFS HCD

2018-12-11 Thread Eric Biggers
[+Cc other people who have been working on this] Hi Parshuram, On Tue, Dec 11, 2018 at 09:50:27AM +, Parshuram Thombare wrote: > Add real time crypto support to UFS HCD using new device > mapper 'crypto-ufs'. dmsetup tool can be used to enable > real time / inline crypto support using device

Re: scsi: sg: assorted memory corruptions

2018-02-10 Thread Eric Biggers
On Sun, Feb 04, 2018 at 12:10:58PM +0100, Dmitry Vyukov wrote: > > > > To get memory corruption it's actually sufficient just to submit "1-byte" > > reads; > > there's no need for the SG_NEXT_CMD_LEN ioctl or anything: > > > > #include > > #include > > > > int main() > >

Re: scsi: sg: assorted memory corruptions

2018-02-04 Thread Eric Biggers
On Thu, Feb 01, 2018 at 05:21:12PM +0100, 'Dmitry Vyukov' via syzkaller wrote: > On Thu, Feb 1, 2018 at 5:17 PM, Ben Hutchings > wrote: > > On Thu, 2018-02-01 at 08:04 +0100, Dmitry Vyukov wrote: > >> On Thu, Feb 1, 2018 at 7:03 AM, Douglas Gilbert > >> wrote: > >> > On 2018-01-30 07:22 AM, Dmit

[PATCH] libata: don't try to pass through NCQ commands to non-NCQ devices

2018-02-03 Thread Eric Biggers
From: Eric Biggers syzkaller hit a WARN() in ata_bmdma_qc_issue() when writing to /dev/sg0. This happened because it issued an ATA pass-through command (ATA_16) where the protocol field indicated that NCQ should be used -- but the device did not support NCQ. We could just remove the WARN() from

[PATCH] libata: fix length validation of ATAPI-relayed SCSI commands

2018-02-03 Thread Eric Biggers
From: Eric Biggers syzkaller reported a crash in ata_bmdma_fill_sg() when writing to /dev/sg1. The immediate cause was that the ATA command's scatterlist was not DMA-mapped, which causes 'pi - 1' to underflow, resulting in a write to 'qc->ap->bmdma_prd[0x]

[PATCH] libata: remove WARN() for DMA or PIO command without data

2018-02-03 Thread Eric Biggers
From: Eric Biggers syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0. This happened because it issued a READ_6 command with no data buffer. Just remove the WARN(), as it doesn't appear indicate a kernel bug. The expected behavior is to fail the command, which the code

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

2017-04-21 Thread Eric Biggers
Hi Elena, On Fri, Apr 21, 2017 at 10:55:29AM +, Reshetova, Elena wrote: > > > > At the very least, what is there now could probably be made about twice as > > fast > > by removing the checks that don't actually help mitigate refcount overflow > > bugs, > > specifically all the checks in ref

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

2017-04-20 Thread Eric Biggers
Hi Elena, On Thu, Apr 20, 2017 at 04:10:16PM +, Reshetova, Elena wrote: > > > All the objections from DaveM on the amount of cycles spent on the > > new refcount_t apply to the block layer fast path operations as well. > > Ok, could you please indicate the correct way to measure the impact f