| 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
| ||
|
Message-ID: <CANXhq0qzwj1XtLk2+D=HDu4ibpnT9AAhg2=F5m4th_D9M1Er1Q@mail.gmail.com>
Date: Thu, 13 Jan 2022 17:34:19 +0800
From: Zong Li <zong.li@...ive.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Rob Herring <robh+dt@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
Conor Dooley <conor.dooley@...rochip.com>,
Bin Meng <bin.meng@...driver.com>,
Green Wan <green.wan@...ive.com>, Vinod <vkoul@...nel.org>,
dmaengine <dmaengine@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH v2 3/3] dmaengine: sf-pdma: Get number of channel by
device tree
On Thu, Jan 13, 2022 at 4:57 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Zong,
>
> On Thu, Jan 13, 2022 at 8:26 AM Zong Li <zong.li@...ive.com> wrote:
> > On Thu, Jan 13, 2022 at 2:53 PM Zong Li <zong.li@...ive.com> wrote:
> > > On Wed, Jan 12, 2022 at 4:28 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > > On Tue, Jan 11, 2022 at 9:51 AM Zong Li <zong.li@...ive.com> wrote:
> > > > > It currently assumes that there are always four channels, it would
> > > > > cause the error if there is actually less than four channels. Change
> > > > > that by getting number of channel from device tree.
> > > > >
> > > > > For backwards-compatible, it uses the default value (i.e. 4) when there
> > > > > is no 'dma-channels' information in dts.
> > > > >
> > > > > Signed-off-by: Zong Li <zong.li@...ive.com>
> > > >
> > > > Thanks for your patch!
> > > >
> > > > > --- a/drivers/dma/sf-pdma/sf-pdma.c
> > > > > +++ b/drivers/dma/sf-pdma/sf-pdma.c
> > > > > @@ -484,21 +484,24 @@ static int sf_pdma_probe(struct platform_device *pdev)
> > > > > struct sf_pdma *pdma;
> > > > > struct sf_pdma_chan *chan;
> > > > > struct resource *res;
> > > > > - int len, chans;
> > > > > - int ret;
> > > > > + int len, ret;
> > > > > const enum dma_slave_buswidth widths =
> > > > > DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES |
> > > > > DMA_SLAVE_BUSWIDTH_4_BYTES | DMA_SLAVE_BUSWIDTH_8_BYTES |
> > > > > DMA_SLAVE_BUSWIDTH_16_BYTES | DMA_SLAVE_BUSWIDTH_32_BYTES |
> > > > > DMA_SLAVE_BUSWIDTH_64_BYTES;
> > > > >
> > > > > - chans = PDMA_NR_CH;
> > > > > - len = sizeof(*pdma) + sizeof(*chan) * chans;
> > > > > + len = sizeof(*pdma) + sizeof(*chan) * PDMA_MAX_NR_CH;
> > > >
> > > > Why is the last part added (yes, this is a pre-existing issue)?
> > > > struct sf_pdma already contains space for chans[PDMA_MAX_NR_CH].
> > > > Either drop the last part, or change sf_pdma.chans[] to a flexible
> > > > array member.
> > > >
> > > > BTW, you can use the struct_size() or flex_array_size() helper
> > > > to calculate len.
> > >
> > > Thanks for your suggestions, let me fix it in the next version.
> > >
> > > >
> > > > > pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL);
> > > > > if (!pdma)
> > > > > return -ENOMEM;
> > > > >
> > > > > - pdma->n_chans = chans;
> > > > > + ret = of_property_read_u32(pdev->dev.of_node, "dma-channels",
> > > > > + &pdma->n_chans);
> > > > > + if (ret) {
> > > > > + dev_notice(&pdev->dev, "set number of channels to default value: 4\n");
> > > > > + pdma->n_chans = PDMA_MAX_NR_CH;
> > > > > + }
> > > > >
> > > > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > > pdma->membase = devm_ioremap_resource(&pdev->dev, res);
> > > > > @@ -556,7 +559,7 @@ static int sf_pdma_remove(struct platform_device *pdev)
> > > > > struct sf_pdma_chan *ch;
> > > > > int i;
> > > > >
> > > > > - for (i = 0; i < PDMA_NR_CH; i++) {
> > > > > + for (i = 0; i < pdma->n_chans; i++) {
> > > > > ch = &pdma->chans[i];
> > > >
> > > > If dma-channels in DT > PDMA_NR_CH, this becomes an out-of-bound
> > > > access.
> > > >
> > >
> > > Okay, let me get the min() between pdma->chans and PDMA_MAX_NR_CH,
> > > please let me know if it isn't good to you.
> >
> > Please allow me give more details on it, I would compare the value of
> > pdma->chans with PDMA_MAX_NR_CH in probe function, and set the
> > pdma->chans to PDMA_MAX_NR_CH if the value in DT is bigger than
> > PDMA_MAX_NR_CH.
>
> Silently limiting "dma-channels" to PDMA_MAX_NR_CH is not a good idea,
> as that may lead to hard-to-track problems.
>
> Basically you have two options:
> 1. Just use the value of "dma-channels" if present.
> This has the advantage that it will work automatically with
> future variants that have more channels, but allows the
> developer to trigger memory exhaustion by providing a very large value.
> 2. Return -EINVAL if "dma-channels" is larger than PDMA_MAX_NR_CH.
> This is the safest, but requires driver changes for a future variant
> that has more channels.
Many thanks for your tips on that. The second approach might be better
to me, because it is safer and it seems to me that we don't currently
have a plan to extend the channels in the pdma. I will modify it in
the next version.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Powered by blists - more mailing lists