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] [day] [month] [year] [list]
Message-ID: <1353424232.20110.18.camel@smile>
Date:	Tue, 20 Nov 2012 17:10:32 +0200
From:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Vinod Koul <vinod.koul@...el.com>,
	spear-devel <spear-devel@...t.st.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dw_dmac: store direction in the custom channel
 structure

On Tue, 2012-11-20 at 19:38 +0530, Viresh Kumar wrote: 
> On 20 November 2012 19:08, Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> > Currently the direction value is come from the generic slave configuration
> 
> s/is come/comes
> 
> > structure and explicitly as a preparation function parameter. The first one is
> > kinda obsoleted. Thus, we have to store the value passed to the preparation
> > function somewhere in our structures to be able to use it later. The best
> > candidate to provide the storage is a custom channel structure. Until now we
> > still keep and check the direction field of the slave config structure as well.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > ---
> >  drivers/dma/dw_dmac.c      |   10 ++++++++--
> >  drivers/dma/dw_dmac_regs.h |    2 ++
> >  2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> > index 5e2c4dc..58c6d3c 100644
> > --- a/drivers/dma/dw_dmac.c
> > +++ b/drivers/dma/dw_dmac.c
> > @@ -178,9 +178,9 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
> >                 cfghi = dws->cfg_hi;
> >                 cfglo |= dws->cfg_lo & ~DWC_CFGL_CH_PRIOR_MASK;
> >         } else {
> > -               if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> > +               if (dwc->direction == DMA_MEM_TO_DEV)
> >                         cfghi = DWC_CFGH_DST_PER(dwc->dma_sconfig.slave_id);
> > -               else if (dwc->dma_sconfig.direction == DMA_DEV_TO_MEM)
> > +               else if (dwc->direction == DMA_DEV_TO_MEM)
> >                         cfghi = DWC_CFGH_SRC_PER(dwc->dma_sconfig.slave_id);
> >         }
> 
> I have a doubt here. This routine is called both for memcpy and slave transfers.
> Earlier if (dws), code was used to check slave/non-slave transfer but with your
> earlier patch, for if (!dws) case too, there can be slave transfers
> based on direction.
> 
> Consider a situation. A channel is used for slave transfers and have
> direction set
> to DMA_DEV_TO_MEM. Now, channel is freed and used for memcpy. Now the
> direction value is retained as we haven't updated it. So, is this a
> potential bug?

Yeah, good point. I think we have to set direction in all possible entry
points (prep functions only?). It means at least we need to update
memcpy prep as well.

I'll update patch tomorrow.

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ