Bug 218671
Summary: | nfsd: memory leak when client does many file operations | ||
---|---|---|---|
Product: | File System | Reporter: | scpcom |
Component: | NFS | Assignee: | Chuck Lever (cel) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | ||
Priority: | P3 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: |
Description
scpcom
2024-04-01 17:25:31 UTC
The bad commit adds a page_frag_cache to be used when sending a four-byte record marker as part of an RPC reply. The pages backing the page_frag_cache never seem to be freed. Possible workarounds until a fix is available: Revert e18e157bb5c8; Use a kernel release before v6.6; Or, use proto=rdma or proto=udp I've confirmed that our original belief that sock_sendmsg() would manage the reference counts of the pages underlying the bvec was wrong: when MSG_SPLICE_PAGES is in use, sock_sendmsg() is synchronous and the page reference counts are not altered. Thus the pages underlying the page_frag_cache are never released. Releasing the fragment immediately seems to be a safe, narrow, and effective fix. We believe that commit 05258a0a69b3 ("SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP") fixes this issue. It will be available in v6.9-rc3. |