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. The 64-bit
systems seems like ok with this, so extend threshold only for
32-bits for now.
Signed-off-by: Ivan Khoronzhuk <[email protected]>
---
Based on bpf-next/master
mm/mmap.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 7e8c3e8ae75f..238ce6b71405 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1358,6 +1358,11 @@ static inline u64 file_mmap_size_max(struct file *file, struct inode *inode)
if (S_ISBLK(inode->i_mode))
return MAX_LFS_FILESIZE;
+#if BITS_PER_LONG == 32
+ if (S_ISSOCK(inode->i_mode))
+ return MAX_LFS_FILESIZE;
+#endif
+
/* Special "we do even unsigned file positions" case */
if (file->f_mode & FMODE_UNSIGNED_OFFSET)
return 0;
--
2.17.1
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 <[email protected]>
---
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(+)
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;
--
2.17.1
On 8/12/19 2:43 PM, Ivan Khoronzhuk 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.
>
> Signed-off-by: Ivan Khoronzhuk <[email protected]>
> ---
>
> Based on bpf-next/master
This is mainly for Andrew to pick rather than bpf-next, but I presume it would
apply cleanly to his tree as well.
> v2..v1:
> removed not necessarily #ifdev as ULL and UL for 64 has same size
>
> mm/mmap.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> 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;
>
On Mon, 12 Aug 2019 15:43:26 +0300 Ivan Khoronzhuk <[email protected]> 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?
On Mon, Aug 12, 2019 at 2:45 PM Ivan Khoronzhuk
<[email protected]> 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.
Can you use mmap2() instead that takes a larger offset (2^44) even on
32-bit systems?
/Magnus
> Signed-off-by: Ivan Khoronzhuk <[email protected]>
> ---
>
> 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(+)
>
> 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;
> --
> 2.17.1
>
On Tue, Aug 13, 2019 at 10:02:54AM +0200, Magnus Karlsson wrote:
>On Mon, Aug 12, 2019 at 2:45 PM Ivan Khoronzhuk
><[email protected]> 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.
>
>Can you use mmap2() instead that takes a larger offset (2^44) even on
>32-bit systems?
That's for mmap2.
>
>/Magnus
>
>> Signed-off-by: Ivan Khoronzhuk <[email protected]>
>> ---
>>
>> 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(+)
>>
>> 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;
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
On Mon, Aug 12, 2019 at 02:19:24PM -0700, Andrew Morton wrote:
Hi, Andrew
>On Mon, 12 Aug 2019 15:43:26 +0300 Ivan Khoronzhuk <[email protected]> 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
That's to allow only offset to be passed, mapping length is less than 4Gb.
I have verified all list of mmap for sockets and all of them contain dummy
cb sock_no_mmap() except the following:
xsk_mmap()
tcp_mmap()
packet_mmap()
xsk_mmap() - it's what this fix is needed for.
tcp_mmap() - doesn't have obvious issues with pgoff - no any references on it.
packet_mmap() - return -EINVAL if it's even set.
>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?
It should go to linux-next, no one has been using it till this patch
with 32 bits as w/o this fix af_xdp sockets can't be used at all.
It unblocks af_xdp socket usage for 32bit systems.
That's example of potential next commit message:
Subject: mm: mmap: increase sockets maximum memory size pgoff for 32bits
The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
and XDP_UMEM_PGOFF_COMPLETION_RING offsets. These offsets are established
already and are part of the configuration interface.
But for 32-bit systems, using AF_XDP socket configuration, these values
are too large to pass the maximum allowed file size verification. The
offsets can be tuned off, but instead of changing the existing interface,
let's extend the max allowed file size for sockets.
No one has been using it till this patch with 32 bits as w/o this fix
af_xdp sockets can't be used at all, so it unblocks af_xdp socket usage
for 32bit systems.
All list of mmap cbs for sockets were verified on side effects and
all of them contain dummy cb - sock_no_mmap() at this moment, except the
following:
xsk_mmap() - it's what this fix is needed for.
tcp_mmap() - doesn't have obvious issues with pgoff - no any references on it.
packet_mmap() - return -EINVAL if it's even set.
Is it ok to be replicated in PATCH v2 or this explanation is enough here
to use v1?
--
Regards,
Ivan Khoronzhuk
On Wed, 14 Aug 2019 18:09:36 +0300 Ivan Khoronzhuk <[email protected]> wrote:
> On Mon, Aug 12, 2019 at 02:19:24PM -0700, Andrew Morton wrote:
>
> Hi, Andrew
>
> >On Mon, 12 Aug 2019 15:43:26 +0300 Ivan Khoronzhuk <[email protected]> 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
>
> That's to allow only offset to be passed, mapping length is less than 4Gb.
> I have verified all list of mmap for sockets and all of them contain dummy
> cb sock_no_mmap() except the following:
>
> xsk_mmap()
> tcp_mmap()
> packet_mmap()
>
> xsk_mmap() - it's what this fix is needed for.
> tcp_mmap() - doesn't have obvious issues with pgoff - no any references on it.
> packet_mmap() - return -EINVAL if it's even set.
Great, thanks.
>
> >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?
> It should go to linux-next, no one has been using it till this patch
> with 32 bits as w/o this fix af_xdp sockets can't be used at all.
> It unblocks af_xdp socket usage for 32bit systems.
>
>
> That's example of potential next commit message:
> Subject: mm: mmap: increase sockets maximum memory size pgoff for 32bits
>
> The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING
> and XDP_UMEM_PGOFF_COMPLETION_RING offsets. These offsets are established
> already and are part of the configuration interface.
>
> But for 32-bit systems, using AF_XDP socket configuration, these values
> are too large to pass the maximum allowed file size verification. The
> offsets can be tuned off, but instead of changing the existing interface,
> let's extend the max allowed file size for sockets.
>
> No one has been using it till this patch with 32 bits as w/o this fix
> af_xdp sockets can't be used at all, so it unblocks af_xdp socket usage
> for 32bit systems.
>
> All list of mmap cbs for sockets were verified on side effects and
> all of them contain dummy cb - sock_no_mmap() at this moment, except the
> following:
>
> xsk_mmap() - it's what this fix is needed for.
> tcp_mmap() - doesn't have obvious issues with pgoff - no any references on it.
> packet_mmap() - return -EINVAL if it's even set.
>
> ...
>
> Is it ok to be replicated in PATCH v2 or this explanation is enough here
> to use v1?
I have replaced the changlog in my tree with the above, thanks.