[PATCH v8 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

This series was original by a bug fix in nvme-over-tcp driver which only checked whether a page was allocated from slab allcoator, but forgot to check its page_count: The page handled by sendpage should be neither a Slab page nor 0 page_count page. As Sagi Grimberg suggested, the original fix is r

[PATCH v8 6/7] scsi: libiscsi: use sendpage_ok() in iscsi_tcp_segment_map()

In iscsci driver, iscsi_tcp_segment_map() uses the following code to check whether the page should or not be handled by sendpage: if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg))) The "page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)" part is to make sure the page can b

[PATCH v8 2/7] net: add WARN_ONCE in kernel_sendpage() for improper zero-copy send

If a page sent into kernel_sendpage() is a slab page or it doesn't have ref_count, this page is improper to send by the zero copy sendpage() method. Otherwise such page might be unexpected released in network code path and causes impredictable panic due to kernel memory management data structure co

[PATCH v8 3/7] nvme-tcp: check page by sendpage_ok() before calling kernel_sendpage()

Currently nvme_tcp_try_send_data() doesn't use kernel_sendpage() to send slab pages. But for pages allocated by __get_free_pages() without __GFP_COMP, which also have refcount as 0, they are still sent by kernel_sendpage() to remote end, this is problematic. The new introduced helper sendpage_ok()

[PATCH v8 1/7] net: introduce helper sendpage_ok() in include/linux/net.h

The original problem was from nvme-over-tcp code, who mistakenly uses kernel_sendpage() to send pages allocated by __get_free_pages() without __GFP_COMP flag. Such pages don't have refcount (page_count is 0) on tail pages, sending them by kernel_sendpage() may trigger a kernel panic from a corrupte

[PATCH v8 4/7] tcp: use sendpage_ok() to detect misused .sendpage

commit a10674bf2406 ("tcp: detecting the misuse of .sendpage for Slab objects") adds the checks for Slab pages, but the pages don't have page_count are still missing from the check. Network layer's sendpage method is not designed to send page_count 0 pages neither, therefore both PageSlab() and pa

[PATCH v8 5/7] drbd: code cleanup by using sendpage_ok() to check page for kernel_sendpage()

In _drbd_send_page() a page is checked by following code before sending it by kernel_sendpage(), (page_count(page) < 1) || PageSlab(page) If the check is true, this page won't be send by kernel_sendpage() and handled by sock_no_sendpage(). This kind of check is exactly what macro sendpage_

[PATCH v8 7/7] libceph: use sendpage_ok() in ceph_tcp_sendpage()

In libceph, ceph_tcp_sendpage() does the following checks before handle the page by network layer's zero copy sendpage method, if (page_count(page) >= 1 && !PageSlab(page)) This check is exactly what sendpage_ok() does. This patch replace the open coded checks by sendpage_ok() as a code cl

Re: [PATCH v8 1/7] net: introduce helper sendpage_ok() in include/linux/net.h

On Fri, Sep 25, 2020 at 11:01:13PM +0800, Coly Li wrote: > The original problem was from nvme-over-tcp code, who mistakenly uses > kernel_sendpage() to send pages allocated by __get_free_pages() without > __GFP_COMP flag. Such pages don't have refcount (page_count is 0) on > tail pages, sending the

[PATCH] TODO: Update to todo list.

This patch is to update the todo list. Tasks are suggested by The Lee-Man Signed-off-by: Sonu k --- TODO | 13 + 1 file changed, 13 insertions(+) diff --git a/TODO b/TODO index 7328180..a3d1d91 100644 --- a/TODO +++ b/TODO @@ -377,3 +377,16 @@ I am working on this one. Hopefully it

Re: Todo list for open-iscsi

Thanks The Lee-Man, I just sent out a patch for todo update. On Sat, Aug 8, 2020 at 4:01 AM The Lee-Man wrote: > > Heh. I just realized you uncovered one item you could do: update the todo > list! But there are things in that list that you could help with. > > -- > You received this message bec

[PATCH v2 0/1] scsi: libiscsi: fix NOP race condition

From: Lee Duncan A customer that uses iSCSI NOPs extensively found a race condition caused in part by the two-lock system used in iscsi (a forward and a back lock), since sending an iSCSI NOP uses the forward lock, and receiving one uses the back lock. Because of this, processing of the "send" ca

[PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

From: Lee Duncan iSCSI NOPs are sometimes "lost", mistakenly sent to the user-land iscsid daemon instead of handled in the kernel, as they should be, resulting in a message from the daemon like: > iscsid: Got nop in, but kernel supports nop handling. This can occur because of the forward- and b

Re: [PATCH v8 6/7] scsi: libiscsi: use sendpage_ok() in iscsi_tcp_segment_map()

Coly, > In iscsci driver, iscsi_tcp_segment_map() uses the following code to > check whether the page should or not be handled by sendpage: > if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg))) > > The "page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)" part is to > make