linux-kernel - Re: [PATCH 1/1] genirq/cpuhotplug: Bump debugging information print down to KERN

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: <87fsvgp4jd.ffs@tglx>
Date:   Wed, 11 Aug 2021 14:08:38 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Ming Lei <ming.lei@...hat.com>, Hannes Reinecke <hare@...e.com>
Subject: Re: [PATCH 1/1] genirq/cpuhotplug: Bump debugging information print
 down to KERN_DEBUG

On Wed, Aug 11 2021 at 08:57, Lee Jones wrote:
> On Tue, 10 Aug 2021, Thomas Gleixner wrote:
>> > @@ -42,7 +42,7 @@ static inline bool irq_needs_fixup(struct irq_data *d)
>> >  		 * If this happens then there was a missed IRQ fixup at some
>> >  		 * point. Warn about it and enforce fixup.
>> >  		 */
>> > -		pr_warn("Eff. affinity %*pbl of IRQ %u contains only offline CPUs after offlining CPU %u\n",
>> 
>> This one is clearly a warning as this should not happen. See the
>> comments around that.
>> 
>> > +		pr_debug("Eff. affinity %*pbl of IRQ %u contains only offline CPUs after offlining CPU %u\n",
>> >  			cpumask_pr_args(m), d->irq, cpu);
>> >  		return true;
>> >  	}
>> > @@ -166,7 +166,7 @@ void irq_migrate_all_off_this_cpu(void)
>> >  		raw_spin_unlock(&desc->lock);
>> >  
>> >  		if (affinity_broken) {
>> > -			pr_warn_ratelimited("IRQ %u: no longer affine to CPU%u\n",
>> > +			pr_debug_ratelimited("IRQ %u: no longer affine to CPU%u\n",
>> >  					    irq, smp_processor_id());
>> 
>> Maybe, but distro people might have opinions on that.
>
> The trouble is, even if these are real warnings, they have an affect
> on performance on real products.  To the point where so much logging
> builds up during pre-release testing, that it sets off the watchdog(s)
> on some high profile consumer devices.

I'm fine with making the second one debug, but the first one really
should not trigger at all.

Thanks,

        tglx