[v2,bpf-next] mm: mmap: increase sockets maximum memory size pgoff for 32bits

Message ID 20190812124326.32146-1-ivan.khoronzhuk@linaro.org
State New
Headers show
Series
  • [v2,bpf-next] mm: mmap: increase sockets maximum memory size pgoff for 32bits
Related show

Commit Message

Ivan Khoronzhuk Aug. 12, 2019, 12:43 p.m.
The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are
established already and are part of configuration interface.

But for 32-bit systems, while AF_XDP socket configuration, the values
are to large to pass maximum allowed file size verification.
The offsets can be tuned ofc, but instead of changing existent
interface - extend max allowed file size for sockets.

Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>

---

Based on bpf-next/master

v2..v1:
	removed not necessarily #ifdev as ULL and UL for 64 has same size

 mm/mmap.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.17.1

Comments

Andrew Morton Aug. 12, 2019, 9:19 p.m. | #1
On Mon, 12 Aug 2019 15:43:26 +0300 Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:

> The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING

> and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are

> established already and are part of configuration interface.

> 

> But for 32-bit systems, while AF_XDP socket configuration, the values

> are to large to pass maximum allowed file size verification.

> The offsets can be tuned ofc, but instead of changing existent

> interface - extend max allowed file size for sockets.



What are the implications of this?  That all code in the kernel which
handles mapped sockets needs to be audited (and tested) for correctly
handling mappings larger than 4G on 32-bit machines?  Has that been
done?  Are we confident that we aren't introducing user-visible buggy
behaviour into unsuspecting legacy code?

Also...  what are the user-visible runtime effects of this change? 
Please send along a paragraph which explains this, for the changelog. 
Does this patch fix some user-visible problem?  If so, should be code
be backported into -stable kernels?

Patch

diff --git a/mm/mmap.c b/mm/mmap.c
index 7e8c3e8ae75f..578f52812361 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1358,6 +1358,9 @@  static inline u64 file_mmap_size_max(struct file *file, struct inode *inode)
 	if (S_ISBLK(inode->i_mode))
 		return MAX_LFS_FILESIZE;
 
+	if (S_ISSOCK(inode->i_mode))
+		return MAX_LFS_FILESIZE;
+
 	/* Special "we do even unsigned file positions" case */
 	if (file->f_mode & FMODE_UNSIGNED_OFFSET)
 		return 0;