[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <875zhbwqmm.fsf@nanos.tec.linutronix.de>
Date: Thu, 16 Jan 2020 13:08:17 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Ming Lei <ming.lei@...hat.com>, linux-kernel@...r.kernel.org
Cc: Ming Lei <ming.lei@...hat.com>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Peter Xu <peterx@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>
Subject: Re: [PATCH] sched/isolation: isolate from handling managed interrupt
Ming,
Ming Lei <ming.lei@...hat.com> writes:
> @@ -212,12 +213,29 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask,
> {
> struct irq_desc *desc = irq_data_to_desc(data);
> struct irq_chip *chip = irq_data_get_irq_chip(data);
> + const struct cpumask *housekeeping_mask =
> + housekeeping_cpumask(HK_FLAG_MANAGED_IRQ);
> int ret;
> + cpumask_var_t tmp_mask = (struct cpumask *)mask;
>
> if (!chip || !chip->irq_set_affinity)
> return -EINVAL;
>
> - ret = chip->irq_set_affinity(data, mask, force);
> + zalloc_cpumask_var(&tmp_mask, GFP_ATOMIC);
I clearly told you:
"That's wrong. This code is called with interrupts disabled, so
GFP_KERNEL is wrong. And NO, we won't do a GFP_ATOMIC allocation
here."
Is that last sentence unclear in any way?
Thanks,
tglx
Powered by blists - more mailing lists