From: Christoph Hellwig <hch@infradead.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
mark.rutland@arm.com, steve@sk2.org, davidgow@google.com,
catalin.marinas@arm.com, linus.walleij@linaro.org,
Palmer Dabbelt <palmerdabbelt@google.com>,
elver@google.com, glider@google.com, willy@infradead.org,
zong.li@sifive.com, mchehab+samsung@kernel.org,
linux-riscv@lists.infradead.org, alex.shi@linux.alibaba.com,
will@kernel.org, dan.j.williams@intel.com,
linux-arch@vger.kernel.org, uwe@kleine-koenig.org, alex@ghiti.fr,
takahiro.akashi@linaro.org, paulmck@kernel.org,
masahiroy@kernel.org, linux@armlinux.org.uk, krzk@kernel.org,
ardb@kernel.org, bgolaszewski@baylibre.com,
kernel-team@android.com, pmladek@suse.com,
zaslonko@linux.ibm.com, aou@eecs.berkeley.edu,
keescook@chromium.org, Arnd Bergmann <arnd@arndb.de>,
rostedt@goodmis.org
Subject: Re: [PATCH 1/5] lib: Add a generic version of devmem_is_allowed()
Date: Fri, 10 Jul 2020 06:38:50 +0100 [thread overview]
Message-ID: <20200710053850.GA27019@infradead.org> (raw)
In-Reply-To: <20200709204921.GJ781326@linux.ibm.com>
On Thu, Jul 09, 2020 at 11:49:21PM +0300, Mike Rapoport wrote:
> > +#ifndef CONFIG_GENERIC_DEVMEM_IS_ALLOWED
> > +extern int devmem_is_allowed(unsigned long pfn);
> > +#endif
Nit: no need for the extern here.
> > +config GENERIC_LIB_DEVMEM_IS_ALLOWED
> > + bool
> > + select ARCH_HAS_DEVMEM_IS_ALLOWED
>
> This seems to work the other way around from the usual Kconfig chains.
> In the most cases ARCH_HAS_SOMETHING selects GENERIC_SOMETHING.
>
> I believe nicer way would be to make
>
> config STRICT_DEVMEM
> bool "Filter access to /dev/mem"
> depends on MMU && DEVMEM
> depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
>
> config GENERIC_LIB_DEVMEM_IS_ALLOWED
> bool
>
> and then s/select ARCH_HAS_DEVMEM_IS_ALLOWED/select GENERIC_LIB_DEVMEM_IS_ALLOWED/
> in the arch Kconfigs and drop ARCH_HAS_DEVMEM_IS_ALLOWED in the end.
To take a step back: Is there any reason to not just always
STRICT_DEVMEM? Maybe for a few architectures that don't currently
support a strict /dev/mem the generic version isn't quite correct, but
someone selecting the option and finding the issue is the best way to
figure that out..
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
mark.rutland@arm.com, steve@sk2.org, davidgow@google.com,
catalin.marinas@arm.com, linus.walleij@linaro.org,
Palmer Dabbelt <palmerdabbelt@google.com>,
elver@google.com, glider@google.com, willy@infradead.org,
zong.li@sifive.com, mchehab+samsung@kernel.org,
linux-riscv@lists.infradead.org, alex.shi@linux.alibaba.com,
will@kernel.org, dan.j.williams@intel.com,
linux-arch@vger.kernel.org, uwe@kleine-koenig.org, alex@ghiti.fr,
takahiro.akashi@linaro.org, paulmck@kernel.org,
masahiroy@kernel.org, linux@armlinux.org.uk, krzk@kernel.org,
ardb@kernel.org, bgolaszewski@baylibre.com,
kernel-team@android.com, pmladek@suse.com,
zaslonko@linux.ibm.com, aou@eecs.berkeley.edu,
keescook@chromium.org, Arnd Bergmann <arnd@arndb.de>,
rostedt@goodmis.org, broonie@kernel.org,
matti.vaittinen@fi.rohmeurope.com, gregory.0xf0@gmail.com,
Paul Walmsley <paul.walmsley@sifive.com>,
tglx@linutronix.de, andriy.shevchenko@linux.intel.com,
gxt@pku.edu.cn, linux-arm-kernel@lists.infradead.org,
rdunlap@infradead.org, Nick Desaulniers <ndesaulniers@google.com>,
linux-kernel@vger.kernel.org, mcgrof@kernel.org,
james.morse@arm.com, mhiramat@kernel.org,
akpm@linux-foundation.org, davem@davemloft.net
Subject: Re: [PATCH 1/5] lib: Add a generic version of devmem_is_allowed()
Date: Fri, 10 Jul 2020 06:38:50 +0100 [thread overview]
Message-ID: <20200710053850.GA27019@infradead.org> (raw)
Message-ID: <20200710053850.LX7yZROi_DvKaGazVhouqtC3dL7r-FydZ48GtodmvBM@z> (raw)
In-Reply-To: <20200709204921.GJ781326@linux.ibm.com>
On Thu, Jul 09, 2020 at 11:49:21PM +0300, Mike Rapoport wrote:
> > +#ifndef CONFIG_GENERIC_DEVMEM_IS_ALLOWED
> > +extern int devmem_is_allowed(unsigned long pfn);
> > +#endif
Nit: no need for the extern here.
> > +config GENERIC_LIB_DEVMEM_IS_ALLOWED
> > + bool
> > + select ARCH_HAS_DEVMEM_IS_ALLOWED
>
> This seems to work the other way around from the usual Kconfig chains.
> In the most cases ARCH_HAS_SOMETHING selects GENERIC_SOMETHING.
>
> I believe nicer way would be to make
>
> config STRICT_DEVMEM
> bool "Filter access to /dev/mem"
> depends on MMU && DEVMEM
> depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
>
> config GENERIC_LIB_DEVMEM_IS_ALLOWED
> bool
>
> and then s/select ARCH_HAS_DEVMEM_IS_ALLOWED/select GENERIC_LIB_DEVMEM_IS_ALLOWED/
> in the arch Kconfigs and drop ARCH_HAS_DEVMEM_IS_ALLOWED in the end.
To take a step back: Is there any reason to not just always
STRICT_DEVMEM? Maybe for a few architectures that don't currently
support a strict /dev/mem the generic version isn't quite correct, but
someone selecting the option and finding the issue is the best way to
figure that out..
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: mark.rutland@arm.com, steve@sk2.org, gregory.0xf0@gmail.com,
catalin.marinas@arm.com, linus.walleij@linaro.org,
Palmer Dabbelt <palmerdabbelt@google.com>,
zaslonko@linux.ibm.com, glider@google.com, krzk@kernel.org,
zong.li@sifive.com, mchehab+samsung@kernel.org,
linux-riscv@lists.infradead.org, alex.shi@linux.alibaba.com,
will@kernel.org, ardb@kernel.org, linux-arch@vger.kernel.org,
paulmck@kernel.org, alex@ghiti.fr, bgolaszewski@baylibre.com,
masahiroy@kernel.org, linux@armlinux.org.uk, willy@infradead.org,
takahiro.akashi@linaro.org, james.morse@arm.com,
kernel-team@android.com, Arnd Bergmann <arnd@arndb.de>,
pmladek@suse.com, elver@google.com, aou@eecs.berkeley.edu,
keescook@chromium.org, uwe@kleine-koenig.org,
rostedt@goodmis.org, broonie@kernel.org, davidgow@google.com,
Paul Walmsley <paul.walmsley@sifive.com>,
dan.j.williams@intel.com, andriy.shevchenko@linux.intel.com,
gxt@pku.edu.cn, linux-arm-kernel@lists.infradead.org,
Nick Desaulniers <ndesaulniers@google.com>,
tglx@linutronix.de, rdunlap@infradead.org,
matti.vaittinen@fi.rohmeurope.com, linux-kernel@vger.kernel.org,
mcgrof@kernel.org, Palmer Dabbelt <palmer@dabbelt.com>,
mhiramat@kernel.org, akpm@linux-foundation.org,
davem@davemloft.net
Subject: Re: [PATCH 1/5] lib: Add a generic version of devmem_is_allowed()
Date: Fri, 10 Jul 2020 06:38:50 +0100 [thread overview]
Message-ID: <20200710053850.GA27019@infradead.org> (raw)
In-Reply-To: <20200709204921.GJ781326@linux.ibm.com>
On Thu, Jul 09, 2020 at 11:49:21PM +0300, Mike Rapoport wrote:
> > +#ifndef CONFIG_GENERIC_DEVMEM_IS_ALLOWED
> > +extern int devmem_is_allowed(unsigned long pfn);
> > +#endif
Nit: no need for the extern here.
> > +config GENERIC_LIB_DEVMEM_IS_ALLOWED
> > + bool
> > + select ARCH_HAS_DEVMEM_IS_ALLOWED
>
> This seems to work the other way around from the usual Kconfig chains.
> In the most cases ARCH_HAS_SOMETHING selects GENERIC_SOMETHING.
>
> I believe nicer way would be to make
>
> config STRICT_DEVMEM
> bool "Filter access to /dev/mem"
> depends on MMU && DEVMEM
> depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
>
> config GENERIC_LIB_DEVMEM_IS_ALLOWED
> bool
>
> and then s/select ARCH_HAS_DEVMEM_IS_ALLOWED/select GENERIC_LIB_DEVMEM_IS_ALLOWED/
> in the arch Kconfigs and drop ARCH_HAS_DEVMEM_IS_ALLOWED in the end.
To take a step back: Is there any reason to not just always
STRICT_DEVMEM? Maybe for a few architectures that don't currently
support a strict /dev/mem the generic version isn't quite correct, but
someone selecting the option and finding the issue is the best way to
figure that out..
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2020-07-10 5:39 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 20:05 Add and use a generic version of devmem_is_allowed() Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` [PATCH 1/5] lib: Add " Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:49 ` Mike Rapoport
2020-07-09 20:49 ` Mike Rapoport
2020-07-09 20:49 ` Mike Rapoport
2020-07-09 20:49 ` Mike Rapoport
2020-07-09 20:54 ` Palmer Dabbelt
2020-07-09 20:54 ` Palmer Dabbelt
2020-07-09 20:54 ` Palmer Dabbelt
2020-07-09 20:54 ` Palmer Dabbelt
2020-07-10 5:38 ` Christoph Hellwig [this message]
2020-07-10 5:38 ` Christoph Hellwig
2020-07-10 5:38 ` Christoph Hellwig
2020-07-10 5:48 ` Nick Kossifidis
2020-07-10 5:48 ` Nick Kossifidis
2020-07-10 5:48 ` Nick Kossifidis
2020-07-10 5:51 ` Christoph Hellwig
2020-07-10 5:51 ` Christoph Hellwig
2020-07-10 5:51 ` Christoph Hellwig
2020-07-09 20:05 ` [PATCH 2/5] RISC-V: Use the new generic devmem_is_allowed() Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` [PATCH 3/5] arm: Use the " Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` [PATCH 4/5] arm64: " Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` [PATCH 5/5] unicore32: " Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
2020-07-09 20:05 ` Palmer Dabbelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200710053850.GA27019@infradead.org \
--to=hch@infradead.org \
--cc=alex.shi@linux.alibaba.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bgolaszewski@baylibre.com \
--cc=catalin.marinas@arm.com \
--cc=dan.j.williams@intel.com \
--cc=davidgow@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=palmer@dabbelt.com \
--cc=palmerdabbelt@google.com \
--cc=paulmck@kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=rppt@linux.ibm.com \
--cc=steve@sk2.org \
--cc=takahiro.akashi@linaro.org \
--cc=uwe@kleine-koenig.org \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=zaslonko@linux.ibm.com \
--cc=zong.li@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.