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: <2a7cf26aa11adf43ec4f29ab733afc695039633c.camel@buserror.net>
Date:   Mon, 02 Mar 2020 02:58:52 -0600
From:   Scott Wood <oss@...error.net>
To:     王文虎 <wenhu.wang@...o.com>
Cc:     wangwenhu <wenhu.pku@...il.com>,
        Kumar Gala <galak@...nel.crashing.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        trivial@...nel.org, Rai Harninder <harninder.rai@....com>
Subject: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable

On Mon, 2020-03-02 at 12:42 +0800, 王文虎 wrote:
> 发件人:Scott Wood <oss@...error.net>
> 发送日期:2020-03-01 07:12:58
> 收件人:"王文虎" <wenhu.wang@...o.com>
> 抄送人:wangwenhu <wenhu.pku@...il.com>,Kumar Gala <galak@...nel.crashing.org>,B
> enjamin Herrenschmidt <benh@...nel.crashing.org>,Paul Mackerras <
> paulus@...ba.org>,Michael Ellerman <mpe@...erman.id.au>,
> linuxppc-dev@...ts.ozlabs.org,linux-kernel@...r.kernel.org,
> trivial@...nel.org,Rai Harninder <harninder.rai@....com>
> 主题:Re: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On
> Tue, 2020-01-21 at 14:38 +0800, 王文虎 wrote:
> > > 发件人:Scott Wood <oss@...error.net>
> > > 发送日期:2020-01-21 13:49:59
> > > 收件人:"王文虎" <wenhu.wang@...o.com>
> > > 抄送人:wangwenhu <wenhu.pku@...il.com>,Kumar Gala <
> > > galak@...nel.crashing.org>,B
> > > enjamin Herrenschmidt <benh@...nel.crashing.org>,Paul Mackerras <
> > > paulus@...ba.org>,Michael Ellerman <mpe@...erman.id.au>,
> > > linuxppc-dev@...ts.ozlabs.org,linux-kernel@...r.kernel.org,
> > > trivial@...nel.org,Rai Harninder <harninder.rai@....com>
> > > 主题:Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On
> > > Tue, 2020-01-21 at 13:20 +0800, 王文虎 wrote:
> > > > > From: Scott Wood <oss@...error.net>
> > > > > Date: 2020-01-21 11:25:25
> > > > > To:  wangwenhu <wenhu.pku@...il.com>,Kumar Gala <
> > > > > galak@...nel.crashing.org>,
> > > > > Benjamin Herrenschmidt <benh@...nel.crashing.org>,Paul Mackerras <
> > > > > paulus@...ba.org>,Michael Ellerman <mpe@...erman.id.au>,
> > > > > linuxppc-dev@...ts.ozlabs.org,linux-kernel@...r.kernel.org
> > > > > Cc:  trivial@...nel.org,wenhu.wang@...o.com,Rai Harninder <
> > > > > harninder.rai@....com>
> > > > > Subject: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM
> > > > > configurable>On Mon, 2020-01-20 at 06:43 -0800, wangwenhu wrote:
> > > > > > > From: wangwenhu <wenhu.wang@...o.com>
> > > > > > > 
> > > > > > > When generating .config file with menuconfig on Freescale BOOKE
> > > > > > > SOC, FSL_85XX_CACHE_SRAM is not configurable for the lack of
> > > > > > > description in the Kconfig field, which makes it impossible
> > > > > > > to support L2Cache-Sram driver. Add a description to make it
> > > > > > > configurable.
> > > > > > > 
> > > > > > > Signed-off-by: wangwenhu <wenhu.wang@...o.com>
> > > > > > 
> > > > > > The intent was that drivers using the SRAM API would select the
> > > > > > symbol.  What
> > > > > > is the use case for selecting it manually?
> > > > > > 
> > > > > 
> > > > > With a repository of multiple products(meaning different defconfigs)
> > > > > and
> > > > > multiple
> > > > > developers, the Kconfigs of the Kernel Source Tree change
> > > > > frequently. So
> > > > > the
> > > > > "make menuconfig"
> > > > > process is needed for defconfigs' re-generating or updating for the
> > > > > complexity of dependencies
> > > > > between different features defined in the Kconfigs.
> > > > 
> > > > That doesn't answer my question of how the SRAM code would be useful
> > > > other
> > > > than to some other driver that uses the API (which would use
> > > > "select").  There
> > > > is no userspace API.  You could use the kernel command line to
> > > > configure
> > > > the
> > > > SRAM but you need to get the address of it for it to be useful.
> > > > 
> > > 
> > > Like you've asked below, via /dev/mem or direct calling within the
> > > Kernel.
> > > And they are not submitted yes, under development.
> > 
> > If they are calling within the kernel, then whatever driver that is should
> > select FSL_85XX_CACHE_SRAM.  Directly accessing /dev/mem without any way
> > for
> > the kernel to advertise where it is or which parts of SRAM are available
> > for
> > use sounds like a bad idea.
> > 
> 
> Yes, definitely. So like we enable the moulde which should selet 
> FSL_85XX_CACHE_SRAM to build vmlinux, FSL_85XX_CACHE_SRAM 
> could not be seleted because of the Kconfig definition problem 
> which I am trying to fix now.  So would you please merge the patch 
> for the convenience of later works depending on the driver.

Sorry, I don't think it's something that should be enabled by itself with
nothing using the allocators.  Suppose we took this patch, and people enabled
it and accessed it via /dev/mem.  Then suppose a driver is patched to allocate
some sram and use it.  They'd be stepping on each others' toes undetected.

If you want to expose it to userspace, add code that allocates some or all of
the sram and make it something userspace can mmap.  Or, if nothing's going to
use them, remove the allocators and export the entire thing to userspace
(again via an sram-specific mappable rather than /dev/mem).

-Scott


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ