On Sun, Aug 16, 2020 at 10:45 PM Christoph Hellwig hch@lst.de wrote:
On Sun, Aug 16, 2020 at 10:55:09AM -0700, Cong Wang wrote:
On Sun, Aug 16, 2020 at 1:36 AM Coly Li colyli@suse.de 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 them by kernel_sendpage() may trigger a kernel panic from a corrupted kernel heap, because these pages are incorrectly freed in network stack as page_count 0 pages.
This patch introduces a helper sendpage_ok(), it returns true if the checking page,
- is not slab page: PageSlab(page) is false.
- has page refcount: page_count(page) is not zero
All drivers who want to send page to remote end by kernel_sendpage() may use this helper to check whether the page is OK. If the helper does not return true, the driver should try other non sendpage method (e.g. sock_no_sendpage()) to handle the page.
Can we leave this helper to mm subsystem?
I know it is for sendpage, but its implementation is all about some mm details and its two callers do not belong to net subsystem either.
Think this in another way: who would fix it if it is buggy? I bet mm people should. ;)
No. This is all about a really unusual imitation in sendpage, which
So netdev people will have to understand and support PageSlab() or page_count()?
If it is unusual even for mm people, how could netdev people suppose to understand this unusual mm bug? At least not any better.
is pretty much unexpected. In fact the best thing would be to make sock_sendpage do the right thing and call sock_no_sendpage based on this condition, so that driver writers don't have to worry at all.
Agreed, but kernel_sendpage() still relies on mm to provide a helper to make the decision and ensure this helper is always up-to-date.
In short, it is all about ownership.
Thanks.