All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Sitnicki via Virtualization <virtualization@lists.linux-foundation.org>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Caleb Raitto <caraitto@google.com>,
	kernel-team@cloudflare.com, "Michael S. Tsirkin" <mst@redhat.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 1/2] virtio_pci: Don't make an extra copy of cpu affinity mask
Date: Tue, 24 Oct 2023 13:26:49 +0200	[thread overview]
Message-ID: <87a5s82qig.fsf@cloudflare.com> (raw)
In-Reply-To: <1698144808.8577316-1-xuanzhuo@linux.alibaba.com>

On Tue, Oct 24, 2023 at 06:53 PM +08, Xuan Zhuo wrote:
> On Tue, 24 Oct 2023 10:17:19 +0200, Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> On Tue, Oct 24, 2023 at 10:31 AM +08, Xuan Zhuo wrote:
>> > On Mon, 23 Oct 2023 18:52:45 +0200, Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> >> On Thu, Oct 19, 2023 at 08:55 PM +08, Xuan Zhuo wrote:
>> >> > On Thu, 19 Oct 2023 12:16:24 +0200, Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> >> >> Since commit 19e226e8cc5d ("virtio: Make vp_set_vq_affinity() take a
>> >> >> mask.") it is actually not needed to have a local copy of the cpu mask.
>> >> >
>> >> >
>> >> > Could you give more info to prove this?
>> >
>> >
>> > Actually, my question is that can we pass a val on the stack(or temp value) to
>> > the irq_set_affinity_hint()?
>> >
>> > Such as the virtio-net uses zalloc_cpumask_var to alloc a cpu_mask, and
>> > that will be released.
>> >
>> >
>> >
>> > 	int __irq_apply_affinity_hint(unsigned int irq, const struct cpumask *m,
>> > 				      bool setaffinity)
>> > 	{
>> > 		unsigned long flags;
>> > 		struct irq_desc *desc = irq_get_desc_lock(irq, &flags, IRQ_GET_DESC_CHECK_GLOBAL);
>> >
>> > 		if (!desc)
>> > 			return -EINVAL;
>> > ->		desc->affinity_hint = m;
>> > 		irq_put_desc_unlock(desc, flags);
>> > 		if (m && setaffinity)
>> > 			__irq_set_affinity(irq, m, false);
>> > 		return 0;
>> > 	}
>> > 	EXPORT_SYMBOL_GPL(__irq_apply_affinity_hint);
>> >
>> > The above code directly refers the mask pointer. If the mask is a temp value, I
>> > think that is a bug.
>>
>> You are completely right. irq_set_affinity_hint stores the mask pointer.
>> irq_affinity_hint_proc_show later dereferences it when user reads out
>> /proc/irq/*/affinity_hint.
>>
>> I have failed to notice that. That's why we need cpumask_copy to stay.
>>
>> My patch is buggy. Please disregard.
>>
>> I will send a v2 to only migrate from deprecated irq_set_affinity_hint.
>>
>> > And I notice that many places directly pass the temp value to this API.
>> > And I am a little confused. ^_^ Or I missed something.
>>
>> There seem two be two gropus of callers:
>>
>> 1. Those that use get_cpu_mask/cpumask_of/cpumask_of_node to produce a
>>    cpumask pointer which is a preallocated constant.
>>
>>    $ weggli 'irq_set_affinity_hint(_, $func(_));' ~/src/linux
>>
>> 2. Those that pass a pointer to memory somewhere.
>>
>>    $ weggli 'irq_set_affinity_hint(_, $mask);' ~/src/linux
>>
>> (weggli tool can be found at https://github.com/weggli-rs/weggli)
>>
>> I've looked over the callers from group #2 but I couldn't find any
>> passing a pointer memory on stack :-)
>
> Pls check stmmac_request_irq_multi_msi()

Good catch. That one looks buggy.

I should also checked for callers that take an address of a var/field:

  $ weggli 'irq_set_affinity_hint(_, &$mask);' ~/src/linux
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Jakub Sitnicki <jakub@cloudflare.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	linux-kernel@vger.kernel.org, kernel-team@cloudflare.com,
	Caleb Raitto <caraitto@google.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 1/2] virtio_pci: Don't make an extra copy of cpu affinity mask
Date: Tue, 24 Oct 2023 13:26:49 +0200	[thread overview]
Message-ID: <87a5s82qig.fsf@cloudflare.com> (raw)
In-Reply-To: <1698144808.8577316-1-xuanzhuo@linux.alibaba.com>

On Tue, Oct 24, 2023 at 06:53 PM +08, Xuan Zhuo wrote:
> On Tue, 24 Oct 2023 10:17:19 +0200, Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> On Tue, Oct 24, 2023 at 10:31 AM +08, Xuan Zhuo wrote:
>> > On Mon, 23 Oct 2023 18:52:45 +0200, Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> >> On Thu, Oct 19, 2023 at 08:55 PM +08, Xuan Zhuo wrote:
>> >> > On Thu, 19 Oct 2023 12:16:24 +0200, Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> >> >> Since commit 19e226e8cc5d ("virtio: Make vp_set_vq_affinity() take a
>> >> >> mask.") it is actually not needed to have a local copy of the cpu mask.
>> >> >
>> >> >
>> >> > Could you give more info to prove this?
>> >
>> >
>> > Actually, my question is that can we pass a val on the stack(or temp value) to
>> > the irq_set_affinity_hint()?
>> >
>> > Such as the virtio-net uses zalloc_cpumask_var to alloc a cpu_mask, and
>> > that will be released.
>> >
>> >
>> >
>> > 	int __irq_apply_affinity_hint(unsigned int irq, const struct cpumask *m,
>> > 				      bool setaffinity)
>> > 	{
>> > 		unsigned long flags;
>> > 		struct irq_desc *desc = irq_get_desc_lock(irq, &flags, IRQ_GET_DESC_CHECK_GLOBAL);
>> >
>> > 		if (!desc)
>> > 			return -EINVAL;
>> > ->		desc->affinity_hint = m;
>> > 		irq_put_desc_unlock(desc, flags);
>> > 		if (m && setaffinity)
>> > 			__irq_set_affinity(irq, m, false);
>> > 		return 0;
>> > 	}
>> > 	EXPORT_SYMBOL_GPL(__irq_apply_affinity_hint);
>> >
>> > The above code directly refers the mask pointer. If the mask is a temp value, I
>> > think that is a bug.
>>
>> You are completely right. irq_set_affinity_hint stores the mask pointer.
>> irq_affinity_hint_proc_show later dereferences it when user reads out
>> /proc/irq/*/affinity_hint.
>>
>> I have failed to notice that. That's why we need cpumask_copy to stay.
>>
>> My patch is buggy. Please disregard.
>>
>> I will send a v2 to only migrate from deprecated irq_set_affinity_hint.
>>
>> > And I notice that many places directly pass the temp value to this API.
>> > And I am a little confused. ^_^ Or I missed something.
>>
>> There seem two be two gropus of callers:
>>
>> 1. Those that use get_cpu_mask/cpumask_of/cpumask_of_node to produce a
>>    cpumask pointer which is a preallocated constant.
>>
>>    $ weggli 'irq_set_affinity_hint(_, $func(_));' ~/src/linux
>>
>> 2. Those that pass a pointer to memory somewhere.
>>
>>    $ weggli 'irq_set_affinity_hint(_, $mask);' ~/src/linux
>>
>> (weggli tool can be found at https://github.com/weggli-rs/weggli)
>>
>> I've looked over the callers from group #2 but I couldn't find any
>> passing a pointer memory on stack :-)
>
> Pls check stmmac_request_irq_multi_msi()

Good catch. That one looks buggy.

I should also checked for callers that take an address of a var/field:

  $ weggli 'irq_set_affinity_hint(_, &$mask);' ~/src/linux

  reply	other threads:[~2023-10-24 11:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-19 10:16 [PATCH 1/2] virtio_pci: Don't make an extra copy of cpu affinity mask Jakub Sitnicki via Virtualization
2023-10-19 10:16 ` Jakub Sitnicki
2023-10-19 10:16 ` [PATCH 2/2] virtio_pci: Switch away from deprecated irq_set_affinity_hint Jakub Sitnicki via Virtualization
2023-10-19 10:16   ` Jakub Sitnicki
2023-10-19 12:54   ` Xuan Zhuo
2023-10-19 12:54     ` Xuan Zhuo
2023-10-19 12:55 ` [PATCH 1/2] virtio_pci: Don't make an extra copy of cpu affinity mask Xuan Zhuo
2023-10-19 12:55   ` Xuan Zhuo
2023-10-23 16:52   ` Jakub Sitnicki via Virtualization
2023-10-23 16:52     ` Jakub Sitnicki
2023-10-24  2:31     ` Xuan Zhuo
2023-10-24  2:31       ` Xuan Zhuo
2023-10-24  8:17       ` Jakub Sitnicki via Virtualization
2023-10-24  8:17         ` Jakub Sitnicki
2023-10-24 10:53         ` Xuan Zhuo
2023-10-24 10:53           ` Xuan Zhuo
2023-10-24 11:26           ` Jakub Sitnicki via Virtualization [this message]
2023-10-24 11:26             ` Jakub Sitnicki
2023-10-24 11:46             ` Xuan Zhuo
2023-10-24 11:46               ` Xuan Zhuo
2023-10-24 11:55               ` Jakub Sitnicki via Virtualization
2023-10-24 11:55                 ` Jakub Sitnicki

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=87a5s82qig.fsf@cloudflare.com \
    --to=virtualization@lists.linux-foundation.org \
    --cc=caraitto@google.com \
    --cc=jakub@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --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.