Re: [BUG] BLKZEROOUT on dm-crypt container cause OOM / kernel panic

2017-08-10 Thread Tom Yan
all just a dm-crypt issue on handling multiple bios created with next_bio (a bio chain)? On 10 August 2017 at 07:27, Tom Yan <tom.t...@gmail.com> wrote: > I haven't really tested but I was aware of the commit before I send my > last email. It doesn't seem relevant to be honest, because it doesn't

Re: [BUG] BLKZEROOUT on dm-crypt container cause OOM / kernel panic

2017-08-09 Thread Tom Yan
I haven't really tested but I was aware of the commit before I send my last email. It doesn't seem relevant to be honest, because it doesn't change the fact that the inner loop wil only end if the whole request has been looped over. So still one big bio. There are a few things that seem

Re: [PATCH v2 2/2] sd: check BLK_DEF_MAX_SECTORS against max_dev_sectors

2016-08-14 Thread Tom Yan
On 14 August 2016 at 17:00, Tom Yan <tom.t...@gmail.com> wrote: > > That won't really work. min_t() would, though the line is gonna be a > bit long; not sure if I can/should simply cast the type (unsigned int) > to BLK_DEF_MAX_SECTORS. And which braces are you referring to? >

Re: [RFC] libata-scsi: make sure Maximum Write Same Length is not too large

2016-08-14 Thread Tom Yan
On 13 August 2016 at 04:56, Martin K. Petersen <martin.peter...@oracle.com> wrote: >>>>>> "Tom" == Tom Yan <tom.t...@gmail.com> writes: > > Tom, > >>> put_unaligned_be64(65535 * ATA_MAX_TRIM_RNUM / (sector_size / 512), >>> [36]

Re: [PATCH v2 2/2] sd: check BLK_DEF_MAX_SECTORS against max_dev_sectors

2016-08-14 Thread Tom Yan
On 13 August 2016 at 05:37, Martin K. Petersen wrote: > > It would be pretty unusual for a device that is smart enough to report a > transfer length limit to be constrained to 1 MB and change. > Well, it is done pretty much for libata's SATL. Also since

Re: [RFC] sd: dynamically adjust SD_MAX_WS16_BLOCKS as per the actual logical block size

2016-08-14 Thread Tom Yan
On 13 August 2016 at 04:26, Martin K. Petersen <martin.peter...@oracle.com> wrote: >>>>>> "Tom" == Tom Yan <tom.t...@gmail.com> writes: > > Tom, > > Tom> I don't really follow. What would this BLK_MAX_BIO_SECTORS be? It > Tom> doesn't a

Re: [PATCH 1/2] libata-scsi: use dev->max_sectors from libata-core appropriately

2016-08-12 Thread Tom Yan
On 12 August 2016 at 19:56, wrote: > > Also note that ATA_HORKAGE_MAX_SEC_LBA48 is not supposed to work > automatically anyway, even when max_hw_sectors is as high as 65535, > since the effective max_sectors will be set by the SCSI disk driver. > I missed the fact that

Re: [PATCH v2 2/2] libata-core: do not set dev->max_sectors for LBA48 devices

2016-08-12 Thread Tom Yan
On 12 August 2016 at 13:18, Tom Yan <tom.t...@gmail.com> wrote: > On 12 August 2016 at 10:01, Martin K. Petersen > <martin.peter...@oracle.com> wrote: >> >> Again, the point of max_hw_sectors and max_dev_sectors is to enforce the >> hard limits of controller a

Re: [PATCH v2 2/2] libata-core: do not set dev->max_sectors for LBA48 devices

2016-08-11 Thread Tom Yan
On 12 August 2016 at 10:01, Martin K. Petersen wrote: > > Again, the point of max_hw_sectors and max_dev_sectors is to enforce the > hard limits of controller and device respectively. Nothing else. > Sounds like libata-scsi is doing something wrong then. It should not

Re: [RFC] libata-scsi: make sure Maximum Write Same Length is not too large

2016-08-11 Thread Tom Yan
On 12 August 2016 at 09:34, Martin K. Petersen wrote: >> "Tom," == tom ty89 writes: > > Tom, > > + put_unaligned_be64(65535 * ATA_MAX_TRIM_RNUM / > + (sector_size / 512), [36]); > > MAXIMUM WRITE

Re: [RFC] libata-scsi: make sure Maximum Write Same Length is not too large

2016-08-11 Thread Tom Yan
ould have probably used the bit shift way instead. On 11 August 2016 at 17:04, Shaun Tancheff <sh...@tancheff.com> wrote: > On Thu, Aug 11, 2016 at 3:26 AM, <tom.t...@gmail.com> wrote: >> From: Tom Yan <tom.t...@gmail.com> >> >> Currently we advertise

Re: [PATCH v2 2/2] libata-core: do not set dev->max_sectors for LBA48 devices

2016-08-11 Thread Tom Yan
On 11 August 2016 at 11:37, Martin K. Petersen <martin.peter...@oracle.com> wrote: >>>>>> "Tom" == Tom Yan <tom.t...@gmail.com> writes: > > I don't agree with conflating the optimal transfer size and the maximum > supported ditto. Sub

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

2016-08-10 Thread Tom Yan
On 10 August 2016 at 15:41, David Milburn wrote: > Hi, > > The 168 makes AHCI_CMD_TBL_SZ equal to 2816 > > AHCI_CMD_TBL_SZ = AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16) > AHCI_CMD_TBL_SZ = 128 + (168 * 16) > > I think if you add in AHCI_CMD_SLOT_SZ (1024) and AHCI_RX_FIS_SZ

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

2016-08-10 Thread Tom Yan
On 10 August 2016 at 11:26, Tejun Heo wrote: > Hmmm.. why not? The hardware limit is 64k and the driver is using a Is that referring to the maximum number of entries allowed in the PRDT, Physical Region Descriptor Table (which is, more precisely, 65535)? > lower limit of 168

Re: [PATCH 1/2] libata-scsi: do not call blk_queue_max_hw_sectors()

2016-08-09 Thread Tom Yan
e: > From: Tom Yan <tom.t...@gmail.com> > > We should just let the scsi driver (hosts.c) call the function. It > has better heuristic anyway (i.e. use SCSI_DEFAULT_MAX_SECTORS as > fallback when max_sectors is not set). > > diff --git a/drivers/ata/libata-scsi.c b/drive

Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

2016-08-07 Thread Tom Yan
So the (not so) recent bump of BLK_DEF_MAX_SECTORS from 1024 to 2560 (commit d2be537c3ba3) seemed to have caused trouble to some of the ATA devices, which were then worked around with ATA_HORKAGE_MAX_SEC_1024. However, I am suspecting that the bump of BLK_DEF_MAX_SECTORS is not the "real" cause