All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	"Guodeqing (A)" <geffrey.guo@huawei.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Max Gurtovoy <mgurtovoy@nvidia.com>,
	"mst@redhat.com" <mst@redhat.com>
Subject: Re: [PATCH] virtio-net: fix the kzalloc/kfree mismatch problem
Date: Wed, 2 Jun 2021 15:59:25 +0300	[thread overview]
Message-ID: <YLeArcxMkty2n/Xz@unreal> (raw)
In-Reply-To: <abcc9911-67d8-8764-b986-d749187d4977@redhat.com>

On Wed, Jun 02, 2021 at 03:19:46PM +0800, Jason Wang wrote:
> 
> 在 2021/6/2 下午1:50, Leon Romanovsky 写道:
> > On Mon, May 24, 2021 at 10:37:14AM +0800, Jason Wang wrote:
> > > 在 2021/5/24 上午10:06, Xuan Zhuo 写道:
> > > > On Mon, 24 May 2021 01:48:53 +0000, Guodeqing (A) <geffrey.guo@huawei.com> wrote:
> > > > > > -----Original Message-----
> > > > > > From: Max Gurtovoy [mailto:mgurtovoy@nvidia.com]
> > > > > > Sent: Sunday, May 23, 2021 15:25
> > > > > > To: Guodeqing (A) <geffrey.guo@huawei.com>; mst@redhat.com
> > > > > > Cc: jasowang@redhat.com; davem@davemloft.net; kuba@kernel.org;
> > > > > > virtualization@lists.linux-foundation.org; netdev@vger.kernel.org
> > > > > > Subject: Re: [PATCH] virtio-net: fix the kzalloc/kfree mismatch problem
> > > > > > 
> > > > > > 
> > > > > > On 5/22/2021 11:02 AM, guodeqing wrote:
> > > > > > > If the virtio_net device does not suppurt the ctrl queue feature, the
> > > > > > > vi->ctrl was not allocated, so there is no need to free it.
> > > > > > you don't need this check.
> > > > > > 
> > > > > > from kfree doc:
> > > > > > 
> > > > > > "If @objp is NULL, no operation is performed."
> > > > > > 
> > > > > > This is not a bug. I've set vi->ctrl to be NULL in case !vi->has_cvq.
> > > > > > 
> > > > > > 
> > > > >     yes,  this is not a bug, the patch is just a optimization, because the vi->ctrl maybe
> > > > >     be freed which  was not allocated, this may give people a misunderstanding.
> > > > >     Thanks.
> > > > I think it may be enough to add a comment, and the code does not need to be
> > > > modified.
> > > > 
> > > > Thanks.
> > > 
> > > Or even just leave the current code as is. A lot of kernel codes was wrote
> > > under the assumption that kfree() should deal with NULL.
> > It is not assumption but standard practice that can be seen as side
> > effect of "7) Centralized exiting of functions" section of coding-style.rst.
> > 
> > Thanks
> 
> 
> I don't see the connection to the centralized exiting.
> 
> Something like:
> 
> if (foo)
>     kfree(foo);
> 
> won't break the centralization.

The key words are "side effect". Once you centralize everything, you
won't want to see "if (foo) kfree(foo)" spaghetti code.

Of course such construction doesn't break anything, but the idea is
to reduce useless code and not add it.

Thanks

> 
> Thanks
> 
> 
> > 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Leon Romanovsky <leon@kernel.org>
To: Jason Wang <jasowang@redhat.com>
Cc: Max Gurtovoy <mgurtovoy@nvidia.com>,
	"Guodeqing \(A\)" <geffrey.guo@huawei.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH] virtio-net: fix the kzalloc/kfree mismatch problem
Date: Wed, 2 Jun 2021 15:59:25 +0300	[thread overview]
Message-ID: <YLeArcxMkty2n/Xz@unreal> (raw)
In-Reply-To: <abcc9911-67d8-8764-b986-d749187d4977@redhat.com>

On Wed, Jun 02, 2021 at 03:19:46PM +0800, Jason Wang wrote:
> 
> 在 2021/6/2 下午1:50, Leon Romanovsky 写道:
> > On Mon, May 24, 2021 at 10:37:14AM +0800, Jason Wang wrote:
> > > 在 2021/5/24 上午10:06, Xuan Zhuo 写道:
> > > > On Mon, 24 May 2021 01:48:53 +0000, Guodeqing (A) <geffrey.guo@huawei.com> wrote:
> > > > > > -----Original Message-----
> > > > > > From: Max Gurtovoy [mailto:mgurtovoy@nvidia.com]
> > > > > > Sent: Sunday, May 23, 2021 15:25
> > > > > > To: Guodeqing (A) <geffrey.guo@huawei.com>; mst@redhat.com
> > > > > > Cc: jasowang@redhat.com; davem@davemloft.net; kuba@kernel.org;
> > > > > > virtualization@lists.linux-foundation.org; netdev@vger.kernel.org
> > > > > > Subject: Re: [PATCH] virtio-net: fix the kzalloc/kfree mismatch problem
> > > > > > 
> > > > > > 
> > > > > > On 5/22/2021 11:02 AM, guodeqing wrote:
> > > > > > > If the virtio_net device does not suppurt the ctrl queue feature, the
> > > > > > > vi->ctrl was not allocated, so there is no need to free it.
> > > > > > you don't need this check.
> > > > > > 
> > > > > > from kfree doc:
> > > > > > 
> > > > > > "If @objp is NULL, no operation is performed."
> > > > > > 
> > > > > > This is not a bug. I've set vi->ctrl to be NULL in case !vi->has_cvq.
> > > > > > 
> > > > > > 
> > > > >     yes,  this is not a bug, the patch is just a optimization, because the vi->ctrl maybe
> > > > >     be freed which  was not allocated, this may give people a misunderstanding.
> > > > >     Thanks.
> > > > I think it may be enough to add a comment, and the code does not need to be
> > > > modified.
> > > > 
> > > > Thanks.
> > > 
> > > Or even just leave the current code as is. A lot of kernel codes was wrote
> > > under the assumption that kfree() should deal with NULL.
> > It is not assumption but standard practice that can be seen as side
> > effect of "7) Centralized exiting of functions" section of coding-style.rst.
> > 
> > Thanks
> 
> 
> I don't see the connection to the centralized exiting.
> 
> Something like:
> 
> if (foo)
>     kfree(foo);
> 
> won't break the centralization.

The key words are "side effect". Once you centralize everything, you
won't want to see "if (foo) kfree(foo)" spaghetti code.

Of course such construction doesn't break anything, but the idea is
to reduce useless code and not add it.

Thanks

> 
> Thanks
> 
> 
> > 
> 
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-06-02 12:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-22  8:02 [PATCH] virtio-net: fix the kzalloc/kfree mismatch problem guodeqing
2021-05-23  7:24 ` Max Gurtovoy
2021-05-24  1:48   ` Guodeqing (A)
2021-05-24  2:06     ` Xuan Zhuo
2021-05-24  2:37       ` Jason Wang
2021-05-24  2:37         ` Jason Wang
2021-05-24  8:34         ` Max Gurtovoy
2021-05-25  1:12           ` Guodeqing (A)
2021-05-25  1:11         ` Guodeqing (A)
2021-06-02  5:50         ` Leon Romanovsky
2021-06-02  5:50           ` Leon Romanovsky
2021-06-02  7:19           ` Jason Wang
2021-06-02  7:19             ` Jason Wang
2021-06-02 12:59             ` Leon Romanovsky [this message]
2021-06-02 12:59               ` Leon Romanovsky

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=YLeArcxMkty2n/Xz@unreal \
    --to=leon@kernel.org \
    --cc=davem@davemloft.net \
    --cc=geffrey.guo@huawei.com \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=mgurtovoy@nvidia.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.