Re: [PATCH] sched/isolation: isolate from handling managed interrupt

[Ming Lei <ming.lei@redhat.com>]

Hi Thomas,

On Thu, Jan 16, 2020 at 01:08:17PM +0100, Thomas Gleixner wrote:
> Ming,
> 
> Ming Lei <ming.lei@redhat.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?

Yeah, it is clear.

But GFP_ATOMIC is usually allowed in atomic context, could you
explain it a bit why it can't be done in this case?

We still can fallback to current behavior if the allocation
fails.

Or could you suggest to solve the issue in other way if GFP_ATOMIC
can't be done?


Thanks,
Ming