Tom,
In my opinion this patch you submitted is simply making the code less
safe against a buffer overflow without a sufficiently good reason.
In future please comment on other patches as replies to those patches.
Mixing them together is just confusing.
--Shaun
--
To unsubscribe from this list: s
On 23 August 2016 at 10:45, Shaun Tancheff wrote:
> On Tue, Aug 23, 2016 at 5:17 AM, Tom Yan wrote:
>> Wait a minute. I think you missed or misunderstood something when you
>> listen to someone's opinion in that we should switch to sglist buffer.
>
> No, I think I can trust Christoph Hellwig
I
On Tue, Aug 23, 2016 at 5:17 AM, Tom Yan wrote:
> Wait a minute. I think you missed or misunderstood something when you
> listen to someone's opinion in that we should switch to sglist buffer.
No, I think I can trust Christoph Hellwig
> I think the danger people referred to is exactly what is r
Wait a minute. I think you missed or misunderstood something when you
listen to someone's opinion in that we should switch to sglist buffer.
I think the danger people referred to is exactly what is revealed when
the ugly code is removed in this commit (it doesn't mean that the code
should be kept t
On Tue, Aug 23, 2016 at 3:37 AM, Tom Yan wrote:
> On 23 August 2016 at 07:30, Shaun Tancheff wrote:
> If we really want/need to avoid hitting some real buffer limit (e.g.
> maximum length of scatter/gather list?), then we should in some way
> check n_block against that. If it is too large we the
On 23 August 2016 at 09:18, Shaun Tancheff wrote:
> On Tue, Aug 23, 2016 at 3:37 AM, Tom Yan wrote:
>> On 23 August 2016 at 07:30, Shaun Tancheff wrote:
>
>> If we really want/need to avoid hitting some real buffer limit (e.g.
>> maximum length of scatter/gather list?), then we should in some wa
On 23 August 2016 at 08:37, Tom Yan wrote:
> On 23 August 2016 at 07:30, Shaun Tancheff wrote:
>>
>> But the "humanized" limit is the one you just added and proceeded to
>> change ata_set_lba_range_entries(). You changed from a buffer size
>> to use "num" instead and now you want to remove the p
On 23 August 2016 at 07:30, Shaun Tancheff wrote:
>
> But the "humanized" limit is the one you just added and proceeded to
> change ata_set_lba_range_entries(). You changed from a buffer size
> to use "num" instead and now you want to remove the protection
> entirely?
I am not sure about what yo
On Mon, Aug 22, 2016 at 3:53 PM, Tom Yan wrote:
> On 22 August 2016 at 20:32, Shaun Tancheff wrote:
>> On Mon, Aug 22, 2016 at 3:07 PM, Tom Yan wrote:
>>> I don't see how that's possible. count / n_block will always be
>>> smaller than 65535 * ATA_MAX_TRIM_RNUM(64) = 4194240. Not to mention
>>>
On 22 August 2016 at 20:32, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 3:07 PM, Tom Yan wrote:
>> I don't see how that's possible. count / n_block will always be
>> smaller than 65535 * ATA_MAX_TRIM_RNUM(64) = 4194240. Not to mention
>> that isn't even a "buffer limit" anyway. By SG_IO do yo
On Mon, Aug 22, 2016 at 3:07 PM, Tom Yan wrote:
> I don't see how that's possible. count / n_block will always be
> smaller than 65535 * ATA_MAX_TRIM_RNUM(64) = 4194240. Not to mention
> that isn't even a "buffer limit" anyway. By SG_IO do you mean like
> SCSI Write Same commands that issued with
I don't see how that's possible. count / n_block will always be
smaller than 65535 * ATA_MAX_TRIM_RNUM(64) = 4194240. Not to mention
that isn't even a "buffer limit" anyway. By SG_IO do you mean like
SCSI Write Same commands that issued with sg_write_same or so? If
that's the case, that's what exac
On Mon, Aug 22, 2016 at 1:55 PM, wrote:
> From: Tom Yan
>
> In commit 5c79097a28c2 ("libata-scsi: reject WRITE SAME (16) with
> n_block that exceeds limit"), it is made sure that
> ata_set_lba_range_entries() will never be called with a request
> size (n_block) that is larger than the number of
From: Tom Yan
In commit 5c79097a28c2 ("libata-scsi: reject WRITE SAME (16) with
n_block that exceeds limit"), it is made sure that
ata_set_lba_range_entries() will never be called with a request
size (n_block) that is larger than the number of blocks that a
512-byte block TRIM payload can describ
14 matches
Mail list logo
