Reviewed-by: Shane Seymour
Reviewed-by: Shane Seymour
> len = snprintf(fname, 99, "%s", buf);
> - fname[len-1] = '\0';
Since it appears that's the only time len is actually used in that function can
you please remove the variable len completely as part of the patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Tested with a HP AE311-60001 PCIe card. It used to repeat the same VPD every 4k
for 32k now only the 154 bytes are returned and lspci - reports that the
data up
to and including the end and that the check sum is good:
...
Capabilities: [74] Vital Product Data
Product N
> The 'end' tag is actually 0x0f, it's the representation as a
> small resource data type tag that's 0x78 (ie shifted by 3).
> This patch also adds helper functions to extract the resource
> data type tags for both large and small resource data types.
>
> Cc: Alexander Duyck
> Cc: Bjorn Helgaas
>
> The only 'error' cases I've encountered so far is a read of all zeroes (and a
> halting the machine once you've read beyond a certain point) or a read of
> 0xff throughout the entire area. So that approach would work for both of them.
I should add that I'd tested the previous patch and this patc
Thank you for taking the issues I raised about converting
unsigned to signed into account.
Reviewed-by: Shane Seymour
> v4: Check the start/len arguments for overflows prior to feeding the page
> cache bogus numbers (that it'll ignore anyway).
> Signed-off-by: Darrick J. Wong
Reviewed-by: Shane Seymour
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
> I don't have a device large enough to test for signedness errors, since
> passing
> huge values for start and len never make it past the i_size_read check.
If you have someone trying to bypass your sanity checks then if
start=18446744073709551104 and len=1024 the result of adding them togethe
> which would make the other checks I suggested to ensure that neither start
> or end were more than (uint64_t)LLONG_MAX unnecessary.
My apologies I was wrong about what I said above - after thinking about it for
longer you still need to make sure that at least len is not greater than
(uint64_t)
> I don't have a device large enough to test for signedness errors, since
> passing
> huge values for start and len never make it past the i_size_read check.
> However, I do see that I forgot to check the padding values, so I'll update
> that.
Then do you want to at least consider converting end
A quick question about this part of the patch:
> + uint64_t end = start + len - 1;
> + if (end >= i_size_read(bdev->bd_inode))
return -EINVAL;
> + /* Invalidate the page cache, including dirty pages */
> + mapping = bdev->bd_inode->i_mapping;
> + truncate_ino
I found the manual pages really confusing so I had a go at rewriting
them - there were places in the manual page that didn't match the
functionality provided by your code as well as I could tell).
My apologies for a few formatting issues though. I still don't like
parts of epoll_pwait1 but it's le
Before you start reading this I want to apologize in advance for the length of
this email. The length is important though to make sure all of the arguments
and counter-arguments are represented in asking for feedback about how tape
statistics would be best implemented.
There is some demand for
14 matches
Mail list logo