From: Simon Horman <horms@kernel.org>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: "Paolo Abeni" <pabeni@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
virtualization@lists.linux.dev,
"Si-Wei Liu" <si-wei.liu@oracle.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH 1/5] virtio-net: fix overflow inside virtnet_rq_alloc
Date: Fri, 25 Oct 2024 14:22:05 +0100 [thread overview]
Message-ID: <20241025132205.GV1202098@kernel.org> (raw)
In-Reply-To: <1729823753.4548287-2-xuanzhuo@linux.alibaba.com>
On Fri, Oct 25, 2024 at 10:35:53AM +0800, Xuan Zhuo wrote:
> On Thu, 17 Oct 2024 15:42:59 +0200, Paolo Abeni <pabeni@redhat.com> wrote:
> >
> >
> > On 10/14/24 05:12, Xuan Zhuo wrote:
> > > When the frag just got a page, then may lead to regression on VM.
> > > Specially if the sysctl net.core.high_order_alloc_disable value is 1,
> > > then the frag always get a page when do refill.
> > >
> > > Which could see reliable crashes or scp failure (scp a file 100M in size
> > > to VM):
> > >
> > > The issue is that the virtnet_rq_dma takes up 16 bytes at the beginning
> > > of a new frag. When the frag size is larger than PAGE_SIZE,
> > > everything is fine. However, if the frag is only one page and the
> > > total size of the buffer and virtnet_rq_dma is larger than one page, an
> > > overflow may occur.
> > >
> > > Here, when the frag size is not enough, we reduce the buffer len to fix
> > > this problem.
> > >
> > > Fixes: f9dac92ba908 ("virtio_ring: enable premapped mode whatever use_dma_api")
> > > Reported-by: "Si-Wei Liu" <si-wei.liu@oracle.com>
> > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >
> > This looks like a fix that should target the net tree, but the following
> > patches looks like net-next material. Any special reason to bundle them
> > together?
>
> Sorry, I forgot to add net-next as a target tree.
>
> This may look like a fix. But the feature was disabled in the last Linux
> version. So the bug cannot be triggered, so we don't need to push to the net
> tree.
I think it would be useful to be clear in the commit message, use of tags,
and target tree regarding fixes and non-fixes.
Please describe in the commit message why this is not fixing a bug, as you
have described above. And please do not include Fixes tags in patches that
are not bug fixes, which seems to be the case here.
If you want to refer to the patch that introduced the problem, you can use
the following syntax, in the commit message, before the tags. Unlike Fixes
tags, this may be line wrapped.
This problem is not a bug fix for net because... It was was introduced by
commit f9dac92ba908 ("virtio_ring: enable premapped mode whatever use_dma_api").
Reported-by: ...
...
next prev parent reply other threads:[~2024-10-25 13:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-14 3:12 [PATCH 0/5] virtio_net: enable premapped mode by default Xuan Zhuo
2024-10-14 3:12 ` [PATCH 1/5] virtio-net: fix overflow inside virtnet_rq_alloc Xuan Zhuo
2024-10-17 13:42 ` Paolo Abeni
2024-10-19 16:34 ` Michael S. Tsirkin
2024-10-25 2:35 ` Xuan Zhuo
2024-10-25 13:22 ` Simon Horman [this message]
2024-10-18 7:41 ` Jason Wang
2024-10-25 2:40 ` Xuan Zhuo
2024-10-14 3:12 ` [PATCH 2/5] virtio_net: introduce vi->mode Xuan Zhuo
2024-10-18 7:48 ` Jason Wang
2024-10-25 2:47 ` Xuan Zhuo
2024-10-14 3:12 ` [PATCH 3/5] virtio_net: big mode skip the unmap check Xuan Zhuo
2024-10-14 3:12 ` [PATCH 4/5] virtio_net: enable premapped mode for merge and small by default Xuan Zhuo
2024-10-18 8:00 ` Jason Wang
2024-10-25 2:53 ` Xuan Zhuo
2024-10-14 3:12 ` [PATCH 5/5] virtio_net: rx remove premapped failover code Xuan Zhuo
2024-10-18 8:01 ` Jason Wang
2024-10-14 4:57 ` [PATCH 0/5] virtio_net: enable premapped mode by default Michael S. Tsirkin
2024-10-16 7:55 ` Darren Kenny
2024-10-18 14:59 ` Darren Kenny
2024-10-19 16:32 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241025132205.GV1202098@kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=si-wei.liu@oracle.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).