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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200116215814.GA24827@ming.t460p>
Date:   Fri, 17 Jan 2020 05:58:14 +0800
From:   Ming Lei <ming.lei@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, 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

Hi Thomas,

On Thu, Jan 16, 2020 at 01:08:17PM +0100, Thomas Gleixner wrote:
> 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?

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