RE: [PATCH] qlogicpti: Return correct error code

Reviewed-by: Shane Seymour

RE: [PATCH] qlogicpti: Return correct error code

Reviewed-by: Shane Seymour

RE: [PATCH] snic: correctly check for array overrun on overly long version number

Reviewed-by: Shane Seymour

RE: [PATCH] snic: correctly check for array overrun on overly long version number

Reviewed-by: Shane Seymour

RE: [PATCH] ipr: fix out-of-bounds null overwrite

> 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"

RE: [PATCH] ipr: fix out-of-bounds null overwrite

> 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"

RE: [PATCH 2/2] pci: Update VPD size with correct length

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

RE: [PATCH 1/2] pci: Update VPD definitions

> 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

RE: [PATCH 1/2] pci: Update VPD definitions

> 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

RE: [PATCH 2/2] pci: Update VPD size with correct length

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

RE: [PATCHv2] pci: Update VPD size with correct length

> 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

RE: [PATCHv2] pci: Update VPD size with correct length

> 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

RE: [PATCH v5 1/2] block: invalidate the page cache when issuing BLKZEROOUT.

Thank you for taking the issues I raised about converting unsigned to signed into account. Reviewed-by: Shane Seymour

RE: [PATCH v5 1/2] block: invalidate the page cache when issuing BLKZEROOUT.

Thank you for taking the issues I raised about converting unsigned to signed into account. Reviewed-by: Shane Seymour

RE: [PATCH v4] block: create ioctl to discard-or-zeroout a range of blocks

> 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

RE: [PATCH v4] block: create ioctl to discard-or-zeroout a range of blocks

> 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

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

> 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

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

> 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

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

> 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

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

> 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

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

> 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

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

> 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

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

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; > +

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

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; > +

RE: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1

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

RE: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1

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

[RFC] Implementing tape statistics

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

[RFC] Implementing tape statistics

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