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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zda-r16ysaKzPdLV@APC323>
Date: Thu, 22 Feb 2024 11:25:35 +0800
From: Yu-Chien Peter Lin <peterlin@...estech.com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: <acme@...nel.org>, <adrian.hunter@...el.com>, <ajones@...tanamicro.com>,
        <alexander.shishkin@...ux.intel.com>, <andre.przywara@....com>,
        <anup@...infault.org>, <aou@...s.berkeley.edu>,
        <atishp@...shpatra.org>, <conor+dt@...nel.org>,
        <conor.dooley@...rochip.com>, <conor@...nel.org>,
        <devicetree@...r.kernel.org>, <evan@...osinc.com>,
        <geert+renesas@...der.be>, <guoren@...nel.org>, <heiko@...ech.de>,
        <irogers@...gle.com>, <jernej.skrabec@...il.com>, <jolsa@...nel.org>,
        <jszhang@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <linux-perf-users@...r.kernel.org>,
        <linux-renesas-soc@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
        <linux-sunxi@...ts.linux.dev>, <locus84@...estech.com>,
        <magnus.damm@...il.com>, <mark.rutland@....com>, <mingo@...hat.com>,
        <n.shubin@...ro.com>, <namhyung@...nel.org>, <palmer@...belt.com>,
        <paul.walmsley@...ive.com>, <peterz@...radead.org>,
        <prabhakar.mahadev-lad.rj@...renesas.com>, <rdunlap@...radead.org>,
        <robh+dt@...nel.org>, <samuel@...lland.org>,
        <sunilvl@...tanamicro.com>, <tim609@...estech.com>, <uwu@...nowy.me>,
        <wens@...e.org>, <will@...nel.org>, <inochiama@...look.com>,
        <unicorn_wang@...look.com>, <wefu@...hat.com>,
        Randolph <randolph@...estech.com>, Atish Patra <atishp@...osinc.com>
Subject: Re: [PATCH v8 02/10] irqchip/riscv-intc: Allow large non-standard
 interrupt number

Hi Thomas,

On Tue, Feb 13, 2024 at 11:04:53AM +0100, Thomas Gleixner wrote:
> On Mon, Jan 29 2024 at 17:25, Yu Chien Peter Lin wrote:
> >  static asmlinkage void riscv_intc_irq(struct pt_regs *regs)
> >  {
> >  	unsigned long cause = regs->cause & ~CAUSE_IRQ_FLAG;
> >  
> > -	if (unlikely(cause >= BITS_PER_LONG))
> > -		panic("unexpected interrupt cause");
> > -
> > -	generic_handle_domain_irq(intc_domain, cause);
> > +	if (generic_handle_domain_irq(intc_domain, cause))
> > +		pr_warn_ratelimited("Failed to handle interrupt (cause: %ld)\n",
> > +				    cause);
> 
> Either let the cause stick out or you need brackets. See:
> 
>   https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#bracket-rules
> 
> >  }
> >  
> >  /*
> > @@ -93,6 +95,14 @@ static int riscv_intc_domain_alloc(struct irq_domain *domain,
> >  	if (ret)
> >  		return ret;
> >  
> > +	/*
> > +	 * Only allow hwirq for which we have corresponding standard or
> > +	 * custom interrupt enable register.
> > +	 */
> > +	if ((riscv_intc_nr_irqs <= hwirq && hwirq < riscv_intc_custom_base) ||
> > +	    (riscv_intc_custom_base + riscv_intc_custom_nr_irqs) <= hwirq)
> > +		return -EINVAL;
> 
> Duh. This mix of ordering required to read this 3 times. What's wrong
> with writing this consistently:
> 
> 	if ((hwirq >= riscv_intc_nr_irqs && hwirq < riscv_intc_custom_base) ||
> 	    (hwirq >= iscv_intc_custom_base + riscv_intc_custom_nr_irqs)
> 		return -EINVAL;
> 
> Hmm?
> 
> > -	pr_info("%d local interrupts mapped\n", BITS_PER_LONG);
> > +	pr_info("%d local interrupts mapped\n", riscv_intc_nr_irqs);
> > +	if (riscv_intc_custom_nr_irqs)
> > +		pr_info("%d custom local interrupts mapped\n",
> > +			riscv_intc_custom_nr_irqs);
> 
> See bracket rules.
>   
> >  	return 0;
> >  }
> > @@ -166,6 +178,10 @@ static int __init riscv_intc_init(struct device_node *node,
> >  		return 0;
> >  	}
> >  
> > +	riscv_intc_nr_irqs = BITS_PER_LONG;
> > +	riscv_intc_custom_base = riscv_intc_nr_irqs;
> 
> Why don't you initialize the static variables with constants right away?
> 
> > +	riscv_intc_custom_nr_irqs = 0;
> 
> It's already 0, no?
> 
> >  	return riscv_intc_init_common(of_node_to_fwnode(node));
> >  }
> 
> Thanks,
> 
>         tglx

Thanks for pointing these out, I'll fix them in PATCH v9.

Regards,
Peter Lin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ