[PATCH] macintosh/therm_adt746x: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master

 If there are any URLs to be removed completely
 or at least not (just) HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.


 drivers/macintosh/therm_adt746x.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/therm_adt746x.c 
b/drivers/macintosh/therm_adt746x.c
index 8f7725dc2166..7e218437730c 100644
--- a/drivers/macintosh/therm_adt746x.c
+++ b/drivers/macintosh/therm_adt746x.c
@@ -5,8 +5,8 @@
  * Copyright (C) 2003, 2004 Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt
  *
  * Documentation from 115254175ADT7467_pra.pdf and 3686221171167ADT7460_b.pdf
- * http://www.onsemi.com/PowerSolutions/product.do?id=ADT7467
- * http://www.onsemi.com/PowerSolutions/product.do?id=ADT7460
+ * https://www.onsemi.com/PowerSolutions/product.do?id=ADT7467
+ * https://www.onsemi.com/PowerSolutions/product.do?id=ADT7460
  *
  */
 
-- 
2.27.0

Re: [PATCH v16 13/22] mm/lru: introduce TestClearPageLRU

[Alexander Duyck]

On Fri, Jul 17, 2020 at 12:46 AM Alex Shi  wrote:
>
>
>
> 在 2020/7/17 上午5:12, Alexander Duyck 写道:
> > On Fri, Jul 10, 2020 at 5:59 PM Alex Shi  wrote:
> >>
> >> Combine PageLRU check and ClearPageLRU into a function by new
> >> introduced func TestClearPageLRU. This function will be used as page
> >> isolation precondition to prevent other isolations some where else.
> >> Then there are may non PageLRU page on lru list, need to remove BUG
> >> checking accordingly.
> >>
> >> Hugh Dickins pointed that __page_cache_release and release_pages
> >> has no need to do atomic clear bit since no user on the page at that
> >> moment. and no need get_page() before lru bit clear in isolate_lru_page,
> >> since it '(1) Must be called with an elevated refcount on the page'.
> >>
> >> As Andrew Morton mentioned this change would dirty cacheline for page
> >> isn't on LRU. But the lost would be acceptable with Rong Chen
> >>  report:
> >> https://lkml.org/lkml/2020/3/4/173
> >>
>
> ...
>
> >> diff --git a/mm/swap.c b/mm/swap.c
> >> index f645965fde0e..5092fe9c8c47 100644
> >> --- a/mm/swap.c
> >> +++ b/mm/swap.c
> >> @@ -83,10 +83,9 @@ static void __page_cache_release(struct page *page)
> >> struct lruvec *lruvec;
> >> unsigned long flags;
> >>
> >> +   __ClearPageLRU(page);
> >> spin_lock_irqsave(>lru_lock, flags);
> >> lruvec = mem_cgroup_page_lruvec(page, pgdat);
> >> -   VM_BUG_ON_PAGE(!PageLRU(page), page);
> >> -   __ClearPageLRU(page);
> >> del_page_from_lru_list(page, lruvec, page_off_lru(page));
> >> spin_unlock_irqrestore(>lru_lock, flags);
> >> }
> >
> > So this piece doesn't make much sense to me. Why not use
> > TestClearPageLRU(page) here? Just a few lines above you are testing
> > for PageLRU(page) and it seems like if you are going to go for an
> > atomic test/clear and then remove the page from the LRU list you
> > should be using it here as well otherwise it seems like you could run
> > into a potential collision since you are testing here without clearing
> > the bit.
> >
>
> Hi Alex,
>
> Thanks a lot for comments!
>
> In this func's call path __page_cache_release, the page is unlikely be
> ClearPageLRU, since this page isn't used by anyone, and going to be freed.
> just __ClearPageLRU would be safe, and could save a non lru page flags 
> disturb.

So if I understand what you are saying correctly you are indicating
that this page should likely not have the LRU flag set and that we
just transitioned it from 1 -> 0 so there should be nobody else
accessing it correct?

It might be useful to document this somewhere. Essentially what we are
doing then is breaking this up into the following cases.

1. Setting the LRU bit requires holding the LRU lock
2. Clearing the LRU bit requires either:
a. Use of atomic operations if page count is 1 or more
b. Non-atomic operations can be used if we cleared last reference count

Is my understanding on this correct? So we have essentially two
scenarios, one for the get_page_unless_zero case, and another with the
put_page_testzero.

> >> @@ -878,9 +877,8 @@ void release_pages(struct page **pages, int nr)
> >> spin_lock_irqsave(_pgdat->lru_lock, 
> >> flags);
> >> }
> >>
> >> -   lruvec = mem_cgroup_page_lruvec(page, 
> >> locked_pgdat);
> >> -   VM_BUG_ON_PAGE(!PageLRU(page), page);
> >> __ClearPageLRU(page);
> >> +   lruvec = mem_cgroup_page_lruvec(page, 
> >> locked_pgdat);
> >> del_page_from_lru_list(page, lruvec, 
> >> page_off_lru(page));
> >> }
> >>
> >
> > Same here. You are just moving the flag clearing, but you didn't
> > combine it with the test. It seems like if you are expecting this to
> > be treated as an atomic operation. It should be a relatively low cost
> > to do since you already should own the cacheline as a result of
> > calling put_page_testzero so I am not sure why you are not combining
> > the two.
>
> before the ClearPageLRU, there is a put_page_testzero(), that means no one 
> using
> this page, and isolate_lru_page can not run on this page the in func checking.
> VM_BUG_ON_PAGE(!page_count(page), page);
> So it would be safe here.

Okay, so this is another 2b case as defined above then.

> >
> >> diff --git a/mm/vmscan.c b/mm/vmscan.c
> >> index c1c4259b4de5..18986fefd49b 100644
> >> --- a/mm/vmscan.c
> >> +++ b/mm/vmscan.c
> >> @@ -1548,16 +1548,16 @@ int __isolate_lru_page(struct page *page, 
> >> isolate_mode_t mode)
> >>  {
> >> int ret = -EINVAL;
> >>
> >> -   /* Only take pages on the LRU. */
> >> -   if (!PageLRU(page))
> >> -   return ret;
> >> -
> >> /* Compaction should not handle unevictable pages but CMA can do 
> >> so */
> >> if (PageUnevictable(page) 

Re: [PATCH 2/2] kvm: mmu: page_track: Fix RCU list API usage

[Daniel Díaz]

The sender of this email would like to recall the message. And drink
more coffee. The sender will also avoid making any more commits on
Friday.

On Fri, 17 Jul 2020 at 13:03, Daniel Díaz  wrote:
>
> Hello!
>
> On Fri, 17 Jul 2020 at 12:07, Paul E. McKenney  wrote:
> >
> > On Thu, Jul 16, 2020 at 05:19:52PM -0700, Dexuan-Linux Cui wrote:
> > > On Thu, Jul 16, 2020 at 7:47 AM Naresh Kamboju
> > >  wrote:
> > > >
> > > > On Sun, 12 Jul 2020 at 21:39, Paul E. McKenney  
> > > > wrote:
> > > > >
> > > > > On Sun, Jul 12, 2020 at 06:40:03PM +0530, 
> > > > > madhuparnabhowmi...@gmail.com wrote:
> > > > > > From: Madhuparna Bhowmik 
> > > > > >
> > > > > > Use hlist_for_each_entry_srcu() instead of 
> > > > > > hlist_for_each_entry_rcu()
> > > > > > as it also checkes if the right lock is held.
> > > > > > Using hlist_for_each_entry_rcu() with a condition argument will not
> > > > > > report the cases where a SRCU protected list is traversed using
> > > > > > rcu_read_lock(). Hence, use hlist_for_each_entry_srcu().
> > > > > >
> > > > > > Signed-off-by: Madhuparna Bhowmik 
> > > > >
> > > > > I queued both for testing and review, thank you!
> > > > >
> > > > > In particular, this one needs an ack by the maintainer.
> > > > >
> > > > > Thanx, Paul
> > > > >
> > > > > >  arch/x86/kvm/mmu/page_track.c | 6 --
> > > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/x86/kvm/mmu/page_track.c 
> > > > > > b/arch/x86/kvm/mmu/page_track.c
> > > > > > index a7bcde34d1f2..a9cd17625950 100644
> > > > > > --- a/arch/x86/kvm/mmu/page_track.c
> > > > > > +++ b/arch/x86/kvm/mmu/page_track.c
> > > > > > @@ -229,7 +229,8 @@ void kvm_page_track_write(struct kvm_vcpu 
> > > > > > *vcpu, gpa_t gpa, const u8 *new,
> > > > > >   return;
> > > > > >
> > > > > >   idx = srcu_read_lock(>track_srcu);
> > > > > > - hlist_for_each_entry_rcu(n, >track_notifier_list, node)
> > > > > > + hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > > > > > + 
> > > > > > srcu_read_lock_held(>track_srcu))
> > > >
> > > > x86 build failed on linux -next 20200716.
> > > >
> > > > arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_write':
> > > > include/linux/rculist.h:727:30: error: left-hand operand of comma
> > > > expression has no effect [-Werror=unused-value]
> > > >   for (__list_check_srcu(cond), \
> > > >   ^
> > > > arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro
> > > > 'hlist_for_each_entry_srcu'
> > > >   hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > > >   ^
> > > > arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_flush_slot':
> > > > include/linux/rculist.h:727:30: error: left-hand operand of comma
> > > > expression has no effect [-Werror=unused-value]
> > > >   for (__list_check_srcu(cond), \
> > > >   ^
> > > > arch/x86/kvm/mmu/page_track.c:258:2: note: in expansion of macro
> > > > 'hlist_for_each_entry_srcu'
> > > >   hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > > >   ^
> > > > cc1: all warnings being treated as errors
> > > > make[3]: *** [arch/x86/kvm/mmu/page_track.o] Error 1
> > > >
> > > > build link,
> > > > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-next/DISTRO=lkft,MACHINE=intel-corei7-64,label=docker-lkft/815/consoleText
> > > >
> > >
> > > Hi, we're seeing the same building failure with the latest linux-next 
> > > tree.
> >
> > I am not seeing this here.  Could you please let us know what compiler
> > and command-line options you are using to generate this?

Please disregard anything below.

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org


> It fails with gcc-8 and gcc-9, but it builds with gcc-10. Quick way to
> reproduce:
>   [host] docker run --rm -it -v /linux:/linux -w /linux
> tuxbuild/build-gcc-9_mips
>   [docker] make ARCH=mips CROSS_COMPILE=mips-linux-gnu- defconfig
>   [docker] make ARCH=mips CROSS_COMPILE=mips-linux-gnu- mm
>
> You can use these other Docker containers: tuxbuild/build-gcc-8_mips
> and tuxbuild/build-gcc-10_mips.
>
> Logs for those builds (and allnoconfig, tinyconfig, with gcc-8, gcc-9
> and gcc-10) can also be found here:
>   https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/643978135
>
> Greetings!
>
> Daniel Díaz
> daniel.d...@linaro.org

[PATCH v2] pwm: bcm-iproc: handle clk_get_rate() return

[Scott Branden]

From: Rayagonda Kokatanur 

Handle clk_get_rate() returning <= 0 condition to avoid
possible division by zero.

Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller")
Signed-off-by: Rayagonda Kokatanur 
Signed-off-by: Scott Branden 

---
Changes from v1: ensure  'polarity' and 'enabled' are populated
when clk_get_rate is 0.
---
 drivers/pwm/pwm-bcm-iproc.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-bcm-iproc.c b/drivers/pwm/pwm-bcm-iproc.c
index 1f829edd8ee7..d392a828fc49 100644
--- a/drivers/pwm/pwm-bcm-iproc.c
+++ b/drivers/pwm/pwm-bcm-iproc.c
@@ -85,8 +85,6 @@ static void iproc_pwmc_get_state(struct pwm_chip *chip, 
struct pwm_device *pwm,
u64 tmp, multi, rate;
u32 value, prescale;
 
-   rate = clk_get_rate(ip->clk);
-
value = readl(ip->base + IPROC_PWM_CTRL_OFFSET);
 
if (value & BIT(IPROC_PWM_CTRL_EN_SHIFT(pwm->hwpwm)))
@@ -99,6 +97,13 @@ static void iproc_pwmc_get_state(struct pwm_chip *chip, 
struct pwm_device *pwm,
else
state->polarity = PWM_POLARITY_INVERSED;
 
+   rate = clk_get_rate(ip->clk);
+   if (rate == 0) {
+   state->period = 0;
+   state->duty_cycle = 0;
+   return;
+   }
+
value = readl(ip->base + IPROC_PWM_PRESCALE_OFFSET);
prescale = value >> IPROC_PWM_PRESCALE_SHIFT(pwm->hwpwm);
prescale &= IPROC_PWM_PRESCALE_MAX;
-- 
2.17.1

[PATCH] ACPI: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 .../firmware-guide/acpi/DSD-properties-rules.rst   |  4 ++--
 .../firmware-guide/acpi/dsd/data-node-references.rst   |  4 ++--
 Documentation/firmware-guide/acpi/dsd/graph.rst| 10 +-
 Documentation/firmware-guide/acpi/dsd/leds.rst |  6 +++---
 Documentation/firmware-guide/acpi/lpit.rst |  2 +-
 drivers/acpi/Kconfig   |  2 +-
 drivers/acpi/nfit/nfit.h   |  2 +-
 7 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/Documentation/firmware-guide/acpi/DSD-properties-rules.rst 
b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst
index 4306f29b6103..8b2d8d0864c2 100644
--- a/Documentation/firmware-guide/acpi/DSD-properties-rules.rst
+++ b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst
@@ -96,5 +96,5 @@ contents.
 References
 ==
 
-.. [1] 
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
-.. [2] 
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf
+.. [1] 
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+.. [2] 
https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf
diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst 
b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
index febccbc5689d..9b17dc77d18c 100644
--- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
+++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
@@ -85,9 +85,9 @@ References
 ==
 
 [1] Hierarchical Data Extension UUID For _DSD.
-,
+,
 referenced 2018-07-17.
 
 [2] Device Properties UUID For _DSD.
-,
+,
 referenced 2016-10-04.
diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst 
b/Documentation/firmware-guide/acpi/dsd/graph.rst
index 1a6ce7afba5e..7072db801aeb 100644
--- a/Documentation/firmware-guide/acpi/dsd/graph.rst
+++ b/Documentation/firmware-guide/acpi/dsd/graph.rst
@@ -154,23 +154,23 @@ References
 ==
 
 [1] _DSD (Device Specific Data) Implementation Guide.
-
http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm,
+
https://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm,
 referenced 2016-10-03.
 
-[2] Devicetree. http://www.devicetree.org, referenced 2016-10-03.
+[2] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
 
 [3] Documentation/devicetree/bindings/graph.txt
 
 [4] Device Properties UUID For _DSD.
-
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
+
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
 referenced 2016-10-04.
 
 [5] Hierarchical Data Extension UUID For _DSD.
-
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf,
+
https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf,
 referenced 2016-10-04.
 
 [6] Advanced Configuration and Power Interface Specification.
-http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf,
+https://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf,
 referenced 2016-10-04.
 
 [7] _DSD Device Properties Usage Rules.
diff --git 

Re: [PATCH] pwm: bcm-iproc: handle clk_get_rate() return

[Scott Branden]

On 2020-07-17 10:22 a.m., Ray Jui wrote:


On 7/17/2020 10:07 AM, Scott Branden wrote:

From: Rayagonda Kokatanur 

Handle clk_get_rate() returning <= 0 condition to avoid
possible division by zero.

Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller")
Signed-off-by: Rayagonda Kokatanur 
Signed-off-by: Scott Branden 
---
  drivers/pwm/pwm-bcm-iproc.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/pwm/pwm-bcm-iproc.c b/drivers/pwm/pwm-bcm-iproc.c
index 1f829edd8ee7..72a8607b6c8d 100644
--- a/drivers/pwm/pwm-bcm-iproc.c
+++ b/drivers/pwm/pwm-bcm-iproc.c
@@ -86,6 +86,11 @@ static void iproc_pwmc_get_state(struct pwm_chip *chip, 
struct pwm_device *pwm,
u32 value, prescale;
  
  	rate = clk_get_rate(ip->clk);

+   if (rate == 0) {
+   state->period = 0;
+   state->duty_cycle = 0;
+   return;
+   }

I'll move the logic after the polarity and enabled fields are populated.

Based on the pwm core code, 'get_state' expects the following fields to
be populated: 'polarity', 'enabled', 'period', and 'duty cycle'.

The above logic will leave 'polarity' and 'enabled' completely
unpopulated when clock rate is zero.

  
  	value = readl(ip->base + IPROC_PWM_CTRL_OFFSET);
  

Re: [PATCH v5 0/7] x86/boot: Remove run-time relocations from compressed kernel

[Sedat Dilek]

On Fri, Jul 17, 2020 at 8:17 PM Nick Desaulniers
 wrote:
>
> On Fri, Jul 17, 2020 at 6:46 AM Arvind Sankar  wrote:
> >
> > On Tue, Jul 14, 2020 at 08:41:26PM -0400, Arvind Sankar wrote:
> > > The compressed kernel currently contains bogus run-time relocations in
> > > the startup code in head_{32,64}.S, which are generated by the linker,
> > > but must not actually be processed at run-time.
> > >
> > > This generates warnings when linking with the BFD linker, and errors
> > > with LLD, which defaults to erroring on run-time relocations in read-only
> > > sections. It also requires the -z noreloc-overflow hack for the 64-bit
> > > kernel, which prevents us from linking it as -pie on an older BFD linker
> > > (<= 2.26) or on LLD, because the locations that are to be apparently
> > > relocated are only 32-bits in size and so cannot really have
> > > R_X86_64_RELATIVE relocations.
> > >
> > > This series aims to get rid of these relocations. I've build- and
> > > boot-tested with combinations of clang/gcc-10 with lld/bfd-2.34, and
> > > gcc-4.9.0 with bfd-2.24, skipping clang on 32-bit because it currently
> > > has other issues [0].
> > >
> >
> > Hi Thomas, Ingo, Borislav, would you be able to take a look over this
> > series in time for 5.9?
>
> Hi Arvind, thanks for the series; I'm behind on testing.  When I try
> to apply this series on top of linux-next, I get a collision in
> drivers/firmware/efi/libstub/Makefile:27 when applying "0002
> x86/boot/compressed: Force hidden visibility for all symbol
> references". Would you mind refreshing the series to avoid that
> collision?
>

I guess taking a Linux-next release as a new base is not a good idea.
With the next Linux-next release... new troubles.
Please, keep the base on recent Linux v5.8-rcX.

- Sedat -

RE: [PATCH 04/20] dlb2: add device ioctl layer and first 4 ioctls

[Eads, Gage]

> -Original Message-
> From: Randy Dunlap 
> Sent: Sunday, July 12, 2020 9:42 AM
> To: Eads, Gage ; linux-kernel@vger.kernel.org;
> a...@arndb.de; gre...@linuxfoundation.org
> Cc: Karlsson, Magnus ; Topel, Bjorn
> 
> Subject: Re: [PATCH 04/20] dlb2: add device ioctl layer and first 4 ioctls
> 
> On 7/12/20 6:43 AM, Gage Eads wrote:
> > +//
> > +/* dlb2 ioctl codes */
> > +//
> > +
> > +#define DLB2_IOC_MAGIC  'h'
> 
> Hi,
> This magic value should be documented in Documentation/userspace-
> api/ioctl/ioctl-number.rst.
> 
> thanks.
> --
> ~Randy

Will fix in v2.

Thanks,
Gage

RE: [PATCH 04/20] dlb2: add device ioctl layer and first 4 ioctls

[Eads, Gage]

> -Original Message-
> From: Randy Dunlap 
> Sent: Sunday, July 12, 2020 9:54 AM
> To: Eads, Gage ; linux-kernel@vger.kernel.org;
> a...@arndb.de; gre...@linuxfoundation.org
> Cc: Karlsson, Magnus ; Topel, Bjorn
> 
> Subject: Re: [PATCH 04/20] dlb2: add device ioctl layer and first 4 ioctls
> 
> On 7/12/20 6:43 AM, Gage Eads wrote:
> > +int dlb2_ioctl_dispatcher(struct dlb2_dev *dev,
> > + unsigned int cmd,
> > + unsigned long arg)
> > +{
> > +   u16 sz = _IOC_SIZE(cmd);
> > +
> > +   if (_IOC_NR(cmd) >= NUM_DLB2_CMD) {
> 
> Does this bounds check need to use array_index_nospec() from
>  ?
> 
> > +   dev_err(dev->dlb2_device,
> > +   "[%s()] Unexpected DLB command %d\n",
> > +   __func__, _IOC_NR(cmd));
> > +   return -1;
> > +   }
> > +
> > +   return dlb2_ioctl_callback_fns[_IOC_NR(cmd)](dev, arg, sz); }
> 
> I don't know if it needs to or not. I just want to make sure that you or
> someone has thought about it.

Thanks for catching this -- it does. Per Arnd's suggestion, I'm going to 
convert this to a switch statement and avoid the index altogether.

Thanks,
Gage

> 
> --
> ~Randy

RE: [PATCH 04/20] dlb2: add device ioctl layer and first 4 ioctls

[Eads, Gage]

 
> > +/* Verify the ioctl argument size and copy the argument into kernel
> > +memory */ static int dlb2_copy_from_user(struct dlb2_dev *dev,
> > +  unsigned long user_arg,
> > +  u16 user_size,
> > +  void *arg,
> > +  size_t size) {
> > +   if (user_size != size) {
> > +   dev_err(dev->dlb2_device,
> > +   "[%s()] Invalid ioctl size\n", __func__);
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (copy_from_user(arg, (void __user *)user_arg, size)) {
> > +   dev_err(dev->dlb2_device,
> > +   "[%s()] Invalid ioctl argument pointer\n", 
> > __func__);
> > +   return -EFAULT;
> > +   }
> > +
> > +   return 0;
> > +}
> 
> You should avoid error messages that are triggered based on user input.
> and can cause a denial-of-service when the console is spammed that way.
> 

Makes sense, will fix.

> A plain copy_from_user() in place of this function should be fine.

This function also validates the user size arg to prevent buffer overflow; 
centralizing it here avoids the case where a programmer accidentally forgets 
the check in an ioctl handler (and reduces code duplication). If it's alright 
with you, I'll keep the function but drop the dev_err() prints.

> 
> > +/* [7:0]: device revision, [15:8]: device version */ #define
> > +DLB2_SET_DEVICE_VERSION(ver, rev) (((ver) << 8) | (rev))
> > +
> > +static int dlb2_ioctl_get_device_version(struct dlb2_dev *dev,
> > +unsigned long user_arg,
> > +u16 size) {
> > +   struct dlb2_get_device_version_args arg;
> > +   struct dlb2_cmd_response response;
> > +   int ret;
> > +
> > +   dev_dbg(dev->dlb2_device, "Entering %s()\n", __func__);
> > +
> > +   response.status = 0;
> > +   response.id = DLB2_SET_DEVICE_VERSION(2, DLB2_REV_A0);
> > +
> > +   ret = dlb2_copy_from_user(dev, user_arg, size, , sizeof(arg));
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = dlb2_copy_resp_to_user(dev, arg.response, );
> 
> Better avoid any indirect pointers. As you always return a constant here, I
> think the entire ioctl command can be removed until you actually need it. If
> you have an ioctl command that needs both input and output, use _IOWR()
> to define it and put all arguments into the same structure.

Ok, I'll merge the response structure into the ioctl structure (here and 
elsewhere).

Say I add this command later: without driver versioning, how would user-space 
know in advance whether the command is supported? It could attempt the command 
and interpret -ENOTTY as "unsupported", but that strikes me as an inelegant way 
to reverse-engineer the version.

> 
> > +static int dlb2_ioctl_create_sched_domain(struct dlb2_dev *dev,
> > + unsigned long user_arg,
> > + u16 size) {
> > +   struct dlb2_create_sched_domain_args arg;
> > +   struct dlb2_cmd_response response = {0};
> > +   int ret;
> > +
> > +   dev_dbg(dev->dlb2_device, "Entering %s()\n", __func__);
> 
> I assume you have finished debugging this version and can remove these
> debug comments again. If you find new bugs, you can add them temporarily,
> but nothing is gained by these here. You can use ftrace to see when functions
> are called.

You're right, and this was mentioned in another comment as well. I'll remove 
these unnecessary dev_dbg() calls.

> 
> > +
> > +   ret = dlb2_copy_from_user(dev, user_arg, size, , sizeof(arg));
> > +   if (ret)
> > +   return ret;
> > +
> > +   /* Copy zeroes to verify the user-provided response pointer */
> > +   ret = dlb2_copy_resp_to_user(dev, arg.response, );
> > +   if (ret)
> > +   return ret;
> 
> There is no need to verify the response pointer. If it fails later, it's the 
> user's
> fault, and they get to deal with it.
> 
> > +static int dlb2_ioctl_get_driver_version(struct dlb2_dev *dev,
> > +unsigned long user_arg,
> > +u16 size) {
> > +   struct dlb2_get_driver_version_args arg;
> > +   struct dlb2_cmd_response response;
> > +   int ret;
> > +
> > +   dev_dbg(dev->dlb2_device, "Entering %s()\n", __func__);
> > +
> > +   response.status = 0;
> > +   response.id = DLB2_VERSION;
> 
> Just remove the driver version command, trying to have explicit interface
> versions creates more problems than it solves.

(See question above)

> 
> > +int dlb2_ioctl_dispatcher(struct dlb2_dev *dev,
> > + unsigned int cmd,
> > + unsigned long arg) {
> > +   u16 sz = _IOC_SIZE(cmd);
> > +
> > +   if (_IOC_NR(cmd) >= NUM_DLB2_CMD) {
> > + 

RE: [PATCH 09/20] dlb2: add ioctl to configure ports, query poll mode

[Eads, Gage]

> -Original Message-
> From: Arnd Bergmann 
> Sent: Sunday, July 12, 2020 10:34 AM
> To: Eads, Gage 
> Cc: linux-kernel@vger.kernel.org; gregkh ;
> Karlsson, Magnus ; Topel, Bjorn
> 
> Subject: Re: [PATCH 09/20] dlb2: add ioctl to configure ports, query poll mode
> 
> On Sun, Jul 12, 2020 at 3:46 PM Gage Eads  wrote:
> >  enum dlb2_user_interface_commands {
> > DLB2_CMD_GET_DEVICE_VERSION,
> > DLB2_CMD_CREATE_SCHED_DOMAIN,
> > DLB2_CMD_GET_SCHED_DOMAIN_FD,
> > DLB2_CMD_GET_NUM_RESOURCES,
> > DLB2_CMD_GET_DRIVER_VERSION,
> > +   DLB2_CMD_QUERY_CQ_POLL_MODE,
> >
> > /* NUM_DLB2_CMD must be last */
> > NUM_DLB2_CMD,
> 
> > @@ -427,6 +513,8 @@ struct dlb2_get_dir_queue_depth_args {  enum
> > dlb2_domain_user_interface_commands {
> > DLB2_DOMAIN_CMD_CREATE_LDB_QUEUE,
> > DLB2_DOMAIN_CMD_CREATE_DIR_QUEUE,
> > +   DLB2_DOMAIN_CMD_CREATE_LDB_PORT,
> > +   DLB2_DOMAIN_CMD_CREATE_DIR_PORT,
> > DLB2_DOMAIN_CMD_GET_LDB_QUEUE_DEPTH,
> > DLB2_DOMAIN_CMD_GET_DIR_QUEUE_DEPTH,
> 
> 
> You cannot add new commands in the middle without changing the ABI.
> 
> Maybe use individual #define lines in place of the enum to make sure these
> remain constants, or add a numeric value for each one when they are
> originally introduced.
> 
> (yes, I realize this is the initial contribution of the new driver, but it 
> still seems
> wrong to have it change in the middle of the series).

Ok, no problem -- I was assuming this patchset would be considered an atomic 
unit. I'll correct this in V2.

Thanks,
Gage

> 
>   Arnd

RE: [PATCH 01/20] dlb2: add skeleton for DLB 2.0 driver

[Eads, Gage]

> -Original Message-
> From: Greg KH 
> Sent: Sunday, July 12, 2020 10:57 AM
> To: Eads, Gage 
> Cc: linux-kernel@vger.kernel.org; a...@arndb.de; Karlsson, Magnus
> ; Topel, Bjorn 
> Subject: Re: [PATCH 01/20] dlb2: add skeleton for DLB 2.0 driver
> 
> On Sun, Jul 12, 2020 at 08:43:12AM -0500, Gage Eads wrote:
> > +config INTEL_DLB2
> > +   tristate "Intel(R) Dynamic Load Balancer 2.0 Driver"
> > +   depends on 64BIT && PCI && X86
> 
> Why just that platform?  What about CONFIG_TEST for everything else?

This device will only appear on an x86 platform. CONFIG_COMPILE_TEST won't 
work, since the driver uses the x86-only function iosubmit_cmds512().

> 
> > +   help
> > + This driver supports the Intel(R) Dynamic Load Balancer 2.0 (DLB 
> > 2.0)
> > + device.
> 
> Are you sure you need the (R) in Kconfig texts everywhere?

The second is probably overkill. Just the first one is required.

> 
> And a bit more info here would be nice, as no one knows if they have this or
> not, right?

Intel hasn't yet announced more information that I can include here. For now, 
"lspci -d 8086:2710" will tell the user if this device is present.

> 
> > --- /dev/null
> > +++ b/drivers/misc/dlb2/dlb2_hw_types.h
> > @@ -0,0 +1,29 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
> 
> Why dual licensed?  I thought that Intel told me they were not going to do
> that anymore for any kernel code going forward as it was just such a pain and
> never actually helped anything.  Has that changed?
> 

The driver is mostly GPLv2-only, but a subset constitutes a "hardware access 
library" that is almost completely OS-independent. "almost" because it has 
calls to non-GPL symbols like kmalloc() and kfree(). This dual-licensed portion 
can be ported to other environments that need the more permissive BSD license.

For the broader policy question, Intel's open source team will get back to you 
on this.

> 
> > + * Copyright(c) 2016-2020 Intel Corporation */
> > +
> > +#ifndef __DLB2_HW_TYPES_H
> > +#define __DLB2_HW_TYPES_H
> > +
> > +#define DLB2_MAX_NUM_VDEVS 16
> > +#define DLB2_MAX_NUM_DOMAINS 32
> > +#define DLB2_MAX_NUM_LDB_QUEUES 32 /* LDB == load-balanced */
> #define
> > +DLB2_MAX_NUM_DIR_QUEUES 64 /* DIR == directed */ #define
> > +DLB2_MAX_NUM_LDB_PORTS 64 #define DLB2_MAX_NUM_DIR_PORTS
> > +DLB2_MAX_NUM_DIR_QUEUES #define DLB2_MAX_NUM_LDB_CREDITS
> 8192 #define
> > +DLB2_MAX_NUM_DIR_CREDITS 2048 #define
> DLB2_MAX_NUM_HIST_LIST_ENTRIES
> > +2048 #define DLB2_MAX_NUM_AQED_ENTRIES 2048 #define
> > +DLB2_MAX_NUM_QIDS_PER_LDB_CQ 8 #define
> > +DLB2_MAX_NUM_SEQUENCE_NUMBER_GROUPS 2 #define
> > +DLB2_MAX_NUM_SEQUENCE_NUMBER_MODES 5 #define
> DLB2_QID_PRIORITIES 8
> > +#define DLB2_NUM_ARB_WEIGHTS 8 #define DLB2_MAX_WEIGHT 255
> #define
> > +DLB2_NUM_COS_DOMAINS 4 #define DLB2_MAX_CQ_COMP_CHECK_LOOPS
> 409600
> > +#define DLB2_MAX_QID_EMPTY_CHECK_LOOPS (32 * 64 * 1024 * (800 / 30))
> > +#define DLB2_HZ 8
> 
> No tabs?  How easy is that to read?  :(

I'll improve this (and a few other instances in later patches) in V2.

Thanks,
Gage

> 
> greg k-h

RE: [PATCH 01/20] dlb2: add skeleton for DLB 2.0 driver

[Eads, Gage]

> -Original Message-
> From: Greg KH 
> Sent: Sunday, July 12, 2020 10:58 AM
> To: Eads, Gage 
> Cc: linux-kernel@vger.kernel.org; a...@arndb.de; Karlsson, Magnus
> ; Topel, Bjorn 
> Subject: Re: [PATCH 01/20] dlb2: add skeleton for DLB 2.0 driver
> 
> On Sun, Jul 12, 2020 at 08:43:12AM -0500, Gage Eads wrote:
> > +static int dlb2_probe(struct pci_dev *pdev,
> > + const struct pci_device_id *pdev_id) {
> > +   struct dlb2_dev *dlb2_dev;
> > +   int ret;
> > +
> > +   dev_dbg(>dev, "probe\n");
> 
> ftrace is your friend.  Remove all of your debugging code now, you don't need
> it anymore, especially for stuff like this where you didn't even need it in 
> the
> first place :(

I'll remove this and other similar dev_dbg() calls. This was an oversight on my 
part.

I have other instances that a kprobe can't easily replace, such as printing 
structure contents, that are useful for tracing the usage of the driver. It 
looks like other misc drivers use dev_dbg() similarly -- do you consider this 
an acceptable use of a debug print?

Thanks,
Gage

> 
> Same for everywhere else in all of these patches.  I'll stop reviewing now,
> someone at Intel should have caught basic stuff like this before now, sad...
> 
> greg k-h

Re: [PATCH v5 0/7] x86/boot: Remove run-time relocations from compressed kernel

[Nick Desaulniers]

On Fri, Jul 17, 2020 at 6:46 AM Arvind Sankar  wrote:
>
> On Tue, Jul 14, 2020 at 08:41:26PM -0400, Arvind Sankar wrote:
> > The compressed kernel currently contains bogus run-time relocations in
> > the startup code in head_{32,64}.S, which are generated by the linker,
> > but must not actually be processed at run-time.
> >
> > This generates warnings when linking with the BFD linker, and errors
> > with LLD, which defaults to erroring on run-time relocations in read-only
> > sections. It also requires the -z noreloc-overflow hack for the 64-bit
> > kernel, which prevents us from linking it as -pie on an older BFD linker
> > (<= 2.26) or on LLD, because the locations that are to be apparently
> > relocated are only 32-bits in size and so cannot really have
> > R_X86_64_RELATIVE relocations.
> >
> > This series aims to get rid of these relocations. I've build- and
> > boot-tested with combinations of clang/gcc-10 with lld/bfd-2.34, and
> > gcc-4.9.0 with bfd-2.24, skipping clang on 32-bit because it currently
> > has other issues [0].
> >
>
> Hi Thomas, Ingo, Borislav, would you be able to take a look over this
> series in time for 5.9?

Hi Arvind, thanks for the series; I'm behind on testing.  When I try
to apply this series on top of linux-next, I get a collision in
drivers/firmware/efi/libstub/Makefile:27 when applying "0002
x86/boot/compressed: Force hidden visibility for all symbol
references". Would you mind refreshing the series to avoid that
collision?
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH v2 3/3] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC

[Mark Brown]

On Thu, Jul 16, 2020 at 06:42:54PM +0800, Xu Yilun wrote:

> +static const struct spi_device_id m10bmc_spi_id[] = {
> + { "m10-n3000", M10_N3000 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(spi, m10bmc_spi_id);

> +static struct spi_driver intel_m10bmc_spi_driver = {
> + .driver = {
> + .name = "intel-m10-bmc",
> + .dev_groups = m10bmc_dev_groups,
> + },
> + .probe = intel_m10_bmc_spi_probe,
> + .id_table = m10bmc_spi_id,
> +};

> +module_spi_driver(intel_m10bmc_spi_driver);

This device has no ACPI information - how will it be instantiated?


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] regmap: add Intel SPI Slave to AVMM Bus Bridge support

[Mark Brown]

On Thu, Jul 16, 2020 at 06:42:52PM +0800, Xu Yilun wrote:

> This patch add support for regmap API that is intended to be used by
> the drivers of some SPI slave chips which integrate the "SPI slave to
> Avalon Master Bridge" (spi-avmm) IP.

At a very high level this looks far too complicated.  Some of that is
due to the protocol it's implementing which looks awfully like you've
got a microcontroller in there trying to proxy a bus of some kind but
there looks to be a lot of abstraction layers simply within the software
here which make things hard to follow.  At the very least there doesn't
seem to be any interaction with this other than proxying stuff.  As
things stand this would be the largest regmap bus implementation by an
order of magnitude.

It is not clear to me that this is really a generic thing that will have
multiple users and that it shouldn't be implemented as reg_read() and
reg_write() operations in the driver that uses it.

> +config REGMAP_SPI_AVMM
> + tristate
> + depends on SPI

Note that for selected symbols dependencies don't take effect.

> @@ -0,0 +1,932 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Intel SPI Slave to AVMM Bus Bridge

Please make the entire comment a C++ one so things look omre
intentional.

> + * Reference Documents could be found at:
> + * https://www.intel.com/content/www/us/en/programmable/documentation/
> + * sfo1400787952932.html

Please don't corrupt links like this, that makes them harder to use.

> + * The main function of the physical layer is the use of PHY_IDLE (4a). Host
> + * issues SCLK to query data from slave, but if slave is not ready to submit
> + * data yet, it will repeat PHY_IDLE until data is prepared.
> + * Because of this special char, it also needs an ESCAPE char (4d), to help
> + * represent data "4a". The escape rule is "4d first, following 4a ^ 20".
> + * So "4d, 6a" for data "4a", and "4d, 6d" for data "4d".

> + * The packet layer defines the boundary of a whole packet. It defines the
> + * Start Of Packet (SOP, 7a) char and End Of Packet (EOP, 7b) char. Please
> + * note that the non-special byte after EOP is the last byte of the packet.
> + * The packet layer also defines a Channel char (7c) + Channel number for
> + * multiple channel transfer. This not currently supported by this driver. So
> + * host will always send "7c, 00" when needed, and will drop the packet if
> + * "7c, non-zero" is received.
> + * Finally, a packet layer ESCAPE char (7d) is also needed to represent a
> + * data value that is the same as the special chars. The escape rule is the
> + * same. The escape rule should be used if the last byte requires it. So if a
> + * packet ends up with data 7a, the last bytes should be "7b, 7d, 5a".

This comment is not particularly intelligable.  I assume all these
number/letter combinations are references to something - it'd be good to
say what.

> +/* slave's register addr is 32 bits */
> +#define REG_SIZE 4UL
> +/* slave's register value is 32 bits */
> +#define VAL_SIZE 4UL

These and many of the other constants are liable to conflict with
something, namespacing would be good.

> +struct trans_header {
> + u8 trans_code;
> + u8 rsvd;
> + __be16 size;
> + __be32 addr;
> +};
> +
> +struct trans_response {
> + u8 r_trans_code;
> + u8 rsvd;
> + __be16 size;
> +};

Do these need to be packed?

> +/* No additional chars are in transaction layer RX, just read out data */
> +#define TRANS_RX_MAX (VAL_SIZE * MAX_RX_CNT)
> +/*

Blank line before the comment.

> +#define TRANS_BUF_SIZE   ((TRANS_TX_MAX > TRANS_RX_MAX) ?
> \
> +  TRANS_TX_MAX : TRANS_RX_MAX)

This could be more simply written using max() couldn't it (which IIRC
can also be evaluated at compile time)?

> +/* Format a transaction layer byte stream for tx_buf */
> +static void trans_tx_prepare(bool is_read, u32 reg, u16 count, u32 *wr_val,
> +  char *tx_buf, unsigned int *tx_len)
> +{
> + struct trans_header *header;
> + u8 trans_code;
> + __le32 *data;
> + int i;
> +
> + trans_code = is_read ?
> + (count == 1 ? TRANS_CODE_READ : TRANS_CODE_SEQ_READ) :
> + (count == 1 ? TRANS_CODE_WRITE : TRANS_CODE_SEQ_WRITE);

Please write this using normal conditional statements for legibility.

> + header = (struct trans_header *)tx_buf;

No need to cast away from char *.

> +/*
> + * The input is a transaction layer byte stream in rx_buf, the output is read
> + * out data.
> + */
> +static int trans_rx_parse(bool is_read, char *rx_buf, unsigned int rx_len,
> +   u16 expected_count, u32 *rd_val)
> +{
> + unsigned int expected_len = expected_count * VAL_SIZE;
> +
> + if (is_read) {
> + if (expected_len != rx_len)
> + return -EINVAL;
> +
> + return rd_trans_rx_parse(rx_buf, rx_len, rd_val);
> +

Re: [PATCH v4 5/9] media: staging: rkisp1: remove unecessary clocks

[Helen Koike]

Hi Rob,

Thanks for your review.

On 7/17/20 2:49 PM, Rob Herring wrote:
> On Thu, Jul 2, 2020 at 1:13 PM Helen Koike  wrote:
>>
>> aclk_isp_wrap is a child of aclk_isp, and hclk_isp_wrap is a child of
>> hclk_isp, thus we can remove parents from the list.
> 
> But it looks like it is the wrap clocks you are removing.

>From this binding yes, but the idea is to add in the dt wherever clock
responsible for the full ACLK path for instance.
In the example below, clock aclk_isp is ACLK_ISP0_WRAPPER.
Does this make sense?

> 
>>
>> Also, for the isp0, we only need the ISP clock, ACLK and HCLK.
>> In the future we'll need a pixel clock for RK3288 and RK3399, and a JPEG
>> clock for RK3288.
>>
>> So with the goal to cleanup the dt-bindings and remove it from staging,
>> simplify clock names to isp, aclk and hclk.
>>
>> For reference, this is the isp clock topology on RK3399:
>>
>>  xin24m
>> pll_npll
>>npll
>>   clk_isp1
>>   clk_isp0
>> pll_cpll
>>cpll
>>   aclk_isp1
>>  aclk_isp1_noc
>>  hclk_isp1
>> aclk_isp1_wrapper
>> hclk_isp1_noc
>>   aclk_isp0
>>  hclk_isp1_wrapper
>>  aclk_isp0_wrapper
>>  aclk_isp0_noc
>>  hclk_isp0
>> hclk_isp0_wrapper
>> hclk_isp0_noc
>>  pclkin_isp1_wrapper
>>
>> Signed-off-by: Helen Koike 
>>
>> ---
>>
>> Changes in V4:
>> - update binding according to suggestion by Robin Murphy
>> on https://patchwork.kernel.org/patch/11475007/
>>
>> Changes in V3:
>> - this is a new patch in the series
>> ---
>>  .../bindings/media/rockchip-isp1.yaml | 30 +--
>>  drivers/staging/media/rkisp1/rkisp1-dev.c |  8 ++---
>>  2 files changed, 17 insertions(+), 21 deletions(-)
>>
>> diff --git 
>> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>>  
>> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>> index 4d111ef2e89c7..f10c53d008748 100644
>> --- 
>> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>> +++ 
>> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>> @@ -24,20 +24,20 @@ properties:
>>  maxItems: 1
>>
>>clocks:
>> -items:
>> -  - description: ISP clock
>> -  - description: ISP AXI clock clock
>> -  - description: ISP AXI clock  wrapper clock
>> -  - description: ISP AHB clock clock
>> -  - description: ISP AHB wrapper clock
> 
> This is the correct way to describe multiple clocks.

The idea was to prepare for rk3288 and rk3399 isp1, as suggested here 
https://patchwork.kernel.org/patch/11475007/#23462085

Or should we do:

clocks:
  oneOf:
# rk3288 clocks
- items:
  - description: ISP clock
  - description: ISP AXI clock
  - description: ISP AHB clock
  - description: ISP Pixel clock
  - description: ISP JPEG source clock
# rk3399 isp0 clocks
- items:
  - description: ISP clock
  - description: ISP AXI clock
  - description: ISP AHB clock
# rk3399 isp1 clocks
- items:
  - description: ISP clock
  - description: ISP AXI clock
  - description: ISP AHB clock
  - description: ISP Pixel clock

?


> 
>> +maxItems: 5
> 
> Now the 4th and 5th clock are undefined.
> 
>> +minItems: 3
>> +description:
>> +  ISP clock
>> +  ISP AXI clock
>> +  ISP AHB clock
>>
>>clock-names:
>> +maxItems: 5
> 
> This should not be more than the number of entries in 'items'.
> 

If we follow what I wrote above, should we have:

clock-names:
  oneOf:
# rk3288 clocks
- items:
  - const: clk_isp
  - const: aclk_isp
  - const: hclk_isp
  - const: pclk_isp_in
  - const: sclk_isp_jpe
# rk3399 isp0 clocks
- items:
  - const: clk_isp
  - const: aclk_isp
  - const: hclk_isp
# rk3399 isp1 clocks
- items:
  - const: clk_isp
  - const: aclk_isp
  - const: hclk_isp
  - const: pclk_isp

?

Thanks
Helen

>> +minItems: 3
>>  items:
>> -  - const: clk_isp
>> -  - const: aclk_isp
>> -  - const: aclk_isp_wrap
>> -  - const: hclk_isp
>> -  - const: hclk_isp_wrap
>> +  - const: isp
>> +  - const: aclk
>> +  - const: hclk
>>
>>iommus:
>>  maxItems: 1
>> @@ -135,11 +135,9 @@ examples:
>>  reg = <0x0 0xff91 0x0 0x4000>;
>>  interrupts = ;
>>  clocks = < SCLK_ISP0>,
>> - < ACLK_ISP0>, < ACLK_ISP0_WRAPPER>,
>> - < HCLK_ISP0>, < HCLK_ISP0_WRAPPER>;
>> -clock-names = "clk_isp",
>> -  "aclk_isp", "aclk_isp_wrap",
>> -  "hclk_isp", "hclk_isp_wrap";
>> + < ACLK_ISP0_WRAPPER>,
>> +  

Re: [PATCH v3 07/12] ima: Fail rule parsing when appraise_flag=blacklist is unsupportable

[Tyler Hicks]

On 2020-07-17 13:40:22, Nayna wrote:
> 
> On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > The "appraise_flag" option is only appropriate for appraise actions
> > and its "blacklist" value is only appropriate when
> > CONFIG_IMA_APPRAISE_MODSIG is enabled and "appraise_flag=blacklist" is
> > only appropriate when "appraise_type=imasig|modsig" is also present.
> > Make this clear at policy load so that IMA policy authors don't assume
> > that other uses of "appraise_flag=blacklist" are supported.
> > 
> > Fixes: 273df864cf74 ("ima: Check against blacklisted hashes for files with 
> > modsig")
> > Signed-off-by: Tyler Hicks 
> > Cc: Nayna Jain 
> > ---
> > 
> > * v3
> >- New patch
> > 
> >   security/integrity/ima/ima_policy.c | 13 -
> >   1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/security/integrity/ima/ima_policy.c 
> > b/security/integrity/ima/ima_policy.c
> > index 81da02071d41..9842e2e0bc6d 100644
> > --- a/security/integrity/ima/ima_policy.c
> > +++ b/security/integrity/ima/ima_policy.c
> > @@ -1035,6 +1035,11 @@ static bool ima_validate_rule(struct ima_rule_entry 
> > *entry)
> > return false;
> > }
> > +   /* Ensure that combinations of flags are compatible with each other */
> > +   if (entry->flags & IMA_CHECK_BLACKLIST &&
> > +   !(entry->flags & IMA_MODSIG_ALLOWED))
> > +   return false;
> > +
> > return true;
> >   }
> > @@ -1371,8 +1376,14 @@ static int ima_parse_rule(char *rule, struct 
> > ima_rule_entry *entry)
> > result = -EINVAL;
> > break;
> > case Opt_appraise_flag:
> > +   if (entry->action != APPRAISE) {
> > +   result = -EINVAL;
> > +   break;
> > +   }
> > +
> > ima_log_string(ab, "appraise_flag", args[0].from);
> > -   if (strstr(args[0].from, "blacklist"))
> > +   if (IS_ENABLED(CONFIG_IMA_APPRAISE_MODSIG) &&
> > +   strstr(args[0].from, "blacklist"))
> > entry->flags |= IMA_CHECK_BLACKLIST;
> 
> If IMA_APPRAISE_MODSIG is disabled, it will allow the following rule to
> load, which is not as expected.
> 
> "appraise func=xxx_CHECK appraise_flag=blacklist appraise_type=imasig"
> 
> Missing is the "else" condition to immediately reject the policy rule.

Thanks for the review. You're right. This change is needed:

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 9842e2e0bc6d..cf3ddb38dfa8 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1385,6 +1385,8 @@ static int ima_parse_rule(char *rule, struct 
ima_rule_entry *entry)
if (IS_ENABLED(CONFIG_IMA_APPRAISE_MODSIG) &&
strstr(args[0].from, "blacklist"))
entry->flags |= IMA_CHECK_BLACKLIST;
+   else
+   result = -EINVAL;
break;
case Opt_permit_directio:
entry->flags |= IMA_PERMIT_DIRECTIO;


Making this change does not conflict with any later patches in the
series.

Mimi, I've rebased and force pushed to my fixup branch with this change,
for your comparison:

 
https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/linux.git/log/?h=next-integrity-testing-fixup

Tyler

> 
> Thanks & Regards,
> 
>  - Nayna
> 

Re: [PATCH] genirq/affinity: Handle affinity setting on inactive interrupts correctly

[kernel test robot]

Hi Thomas,

I love your patch! Yet something to improve:

[auto build test ERROR on linux/master]
[also build test ERROR on tip/x86/core tip/irq/core linus/master v5.8-rc5 
next-20200717]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Thomas-Gleixner/genirq-affinity-Handle-affinity-setting-on-inactive-interrupts-correctly/20200717-211602
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68
config: s390-randconfig-r015-20200717 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
ed6b578040a85977026c93bf4188f996148f3218)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390x-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
 ^
   include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
   ___constant_swab32(x) : \
  ^
   include/uapi/linux/swab.h:19:12: note: expanded from macro 
'___constant_swab32'
   (((__u32)(x) & (__u32)0x00ffUL) << 24) |\
 ^
   In file included from kernel/irq/manage.c:11:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/s390/include/asm/io.h:72:
   include/asm-generic/io.h:490:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
   ~~ ^
   include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
   #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
 ^
   include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
   ___constant_swab32(x) : \
  ^
   include/uapi/linux/swab.h:20:12: note: expanded from macro 
'___constant_swab32'
   (((__u32)(x) & (__u32)0xff00UL) <<  8) |\
 ^
   In file included from kernel/irq/manage.c:11:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/s390/include/asm/io.h:72:
   include/asm-generic/io.h:490:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
   ~~ ^
   include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
   #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
 ^
   include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
   ___constant_swab32(x) : \
  ^
   include/uapi/linux/swab.h:21:12: note: expanded from macro 
'___constant_swab32'
   (((__u32)(x) & (__u32)0x00ffUL) >>  8) |\
 ^
   In file included from kernel/irq/manage.c:11:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/s390/include/asm/io.h:72:
   include/asm-generic/io.h:490:45: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   val = __le32_to_cpu(__raw_readl(PCI_IOBASE + addr));
   ~~ ^
   include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
   #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
 ^
   include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
   ___constant_swab32(x) : \
  ^
   include/uapi/linux/swab.h:22:12: note: expanded from macro 
'___constant_swab32'
   (((__u32)(x) & (__u32)0xff00UL) >> 24)))
 ^
   In file included from kernel/irq/manage.c:11:
 

Re: [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool

[Steven Rostedt]

On Fri, 17 Jul 2020 10:47:51 -0700
Sami Tolvanen  wrote:

> > Someone just submitted a patch for arm64 for this:
> >
> > https://lore.kernel.org/r/20200717143338.19302-1-gregory.herr...@oracle.com
> >
> > Is that what you want?  
> 
> That looks like the same issue, but we need to fix this on x86 instead.

Does x86 have a way to differentiate between the two that record mcount
can check?

-- Steve

Re: [PATCH 1/2] dt-bindings: chrome: Add cros-ec-typec mux props

[Prashant Malani]

Hi Rob,

Just checking in again to see if you have any thoughts about the
proposal outlined in previous emails in this thread.

Best regards,

On Fri, Jul 10, 2020 at 1:51 AM Prashant Malani  wrote:
>
> Hi Rob,
>
> Thought I'd check in again to see if you've had a chance to look at
> this proposal.
>
> Since Type C connector class framework assumes the existing
> "{mode,orientation,data-role}-switch" bindings for non-DT platforms
> already, as I see it, we can either:
>
> 1. Implement a different handling for DT platforms which utilizes port
> end-points and update the Type C connector class framework to parse
> those accordingly; this is what the above proposal suggests. It
> reserves some end-points for the "switches" that the Type C connector
> class framework expects and just follows the OF graph till it finds
> the various switches. Other schemas that use usb-connector.yaml schema
> can add more end-points as their use case deems needed, as long as
> they're not the reserved ones.
>
> 
>
> 2. Let various schemas that use usb-connector.schema add their own
> bindings according to their requirements (in the example of
> cros-ec-typec, it is adding the "*-switch" nodes directly under each
> connector instead of using OF graph so that Type C connector class
> framework can detect the switches, but there other examples for other
> use cases).
>
> I'm fine with either, but since this thread is now nearly 3 months
> old, it would be nice to arrive at a decision.
>
> Best regards,
>
> On Mon, Jun 29, 2020 at 1:41 PM Prashant Malani  wrote:
> >
> > Hi Rob,
> >
> > Just following up on this. Would the below example align better with
> > OF graph requirements?
> >
> > Example begins at , but in summary:
> > - port@1 (Superspeed) of usb-c-connector will have 3 endpoints (0 =
> > goes to mode switch, 1 = goes to orientation switch, 2 = goes to data
> > role switch)
> > - port@2 (SBU) of usb-c-connector will have 2 endpoints (0 = goes to
> > mode switch, 1 = goes to orientation switch)
> > -These end points can go through arbitrarily long paths (including
> > retimers) as long as they end up at the following devices:
> > a. device with compatible string "typec-mode-switch" for endpoint 0.
> > b. device with compatible string "typec-orientation-switch" for 
> > endpoint 1.
> > c. device with compatible string "typec-data-role-switch" for endpoint 
> > 2.
> > - Connector class framework will perform the traversal from
> > usb-c-connector port endpoints to the "*-switch" devices.
> >
> > Best regards,
> >
> > On Fri, Jun 12, 2020 at 10:34 AM Prashant Malani  
> > wrote:
> > >
> > > Hi Rob,
> > >
> > > Thanks as always for your help in reviewing this proposal!
> > >
> > > Kindly see inline
> > >
> > > (Trimming text);
> > > On Thu, Jun 11, 2020 at 02:00:47PM -0600, Rob Herring wrote:
> > > > On Wed, Jun 10, 2020 at 11:49 AM Prashant Malani  
> > > > wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Wed, Jun 10, 2020 at 9:53 AM Rob Herring  wrote:
> > > > > >
> > > > > > > On Tue, Jun 09, 2020 at 04:57:40PM -0700, Prashant Malani wrote:
> > > > >
> > > > > I think the updated example handles this grouping (port@1 going to a
> > > > > "SS mux") although as you said it should probably be a group of muxes,
> > > > > but I think the example illustrates the point. Is that assessment
> > > > > correct?
> > > >
> > > > Yes, but let's stop calling it a mux. It's a "USB Type C signal routing 
> > > > blob".
> > >
> > > Ack.
> > >
> > > Let's go with "-switch" ? That's what the connector class uses and it
> > > conveys the meaning (unless that is a reserved keyword in DT).
> > >
> > > >
> > > > > Would this block the addition of the "*-switch" properties? IIUC the
> > > > > two are related but not dependent on each other.
> > > > >
> > > > > The *-switch properties are phandles which the Type C connector class
> > > > > framework expects (and uses to get handles to those switches).
> > > > > These would point to the "mux" or "group of mux" abstractions as 
> > > > > noted earlier.
> > > >
> > > > You don't need them though. Walk the graph. You get the connector
> > > > port@1 remote endpoint and then get its parent.
> > > >
> > >
> > > I see; would it be something along the lines of this? (DT example
> > > follows; search for "example_end" to jump to bottom):
> > >
> > > 
> > >
> > > connector@0 {
> > > compatible = "usb-c-connector";
> > > reg = <0>;
> > > power-role = "dual";
> > > data-role = "dual";
> > > try-power-role = "source";
> > > 
> > > ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > port@0 {
> > > reg = <0>;
> > > usb_con_hs: endpoint {
> > > remote-endpoint = <_usb_hs_controller>;
> > > };
> > > };
> > >
> > > port@1 {
> > > reg = <1>;
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > 

Re: [PATCH v2] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros

[Marc Zyngier]

On 2020-07-17 18:50, Saravana Kannan wrote:

On Fri, Jul 17, 2020 at 3:49 AM Marc Zyngier  wrote:


Hi Saravana,

Thanks for re-spinning this one.

On Fri, 17 Jul 2020 03:44:47 +0100,
Saravana Kannan  wrote:
>
> Compiling an irqchip driver as a platform driver needs to bunch of
> things to be done right:
> - Making sure the parent domain is initialized first
> - Making sure the device can't be unbound from sysfs
> - Disallowing module unload if it's built as a module
> - Finding the parent node
> - Etc.
>
> Instead of trying to make sure all future irqchip platform drivers get
> this right, provide boilerplate macros that take care of all of this.
>
> An example use would look something like this. Where acme_foo_init and
> acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE.
>
> IRQCHIP_PLATFORM_DRIVER_BEGIN

I think there is some value in having the BEGIN statement containing
the driver name, see below.

> IRQCHIP_MATCH(foo, "acme,foo", acme_foo_init)
> IRQCHIP_MATCH(bar, "acme,bar", acme_bar_init)
> IRQCHIP_PLATFORM_DRIVER_END(acme_irq)
>
> Signed-off-by: Saravana Kannan 
> ---
>  drivers/irqchip/irqchip.c | 22 ++
>  include/linux/irqchip.h   | 23 +++
>  2 files changed, 45 insertions(+)
>
> diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
> index 2b35e68bea82..236ea793f01c 100644
> --- a/drivers/irqchip/irqchip.c
> +++ b/drivers/irqchip/irqchip.c
> @@ -10,8 +10,10 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   * This special of_device_id is the sentinel at the end of the
> @@ -29,3 +31,23 @@ void __init irqchip_init(void)
>   of_irq_init(__irqchip_of_table);
>   acpi_probe_device_table(irqchip);
>  }
> +
> +int platform_irqchip_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct device_node *par_np = of_irq_find_parent(np);
> + of_irq_init_cb_t irq_init_cb = of_device_get_match_data(>dev);
> +
> + if (!irq_init_cb)
> + return -EINVAL;
> +
> + if (par_np == np)
> + par_np = NULL;
> +
> + /* If there's a parent irqchip, make sure it has been initialized. */
> + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY))

There is no guarantee that the calling driver wants BUS_ANY as a token
for its parent. It may work for now, if you only have dependencies to
drivers that only expose a single domain, but that's not a general
purpose check..

At least, please add a comment saying that the new driver may want to
check that the irqdomain it depends on may not be available.


This is just checking if the parent interrupt controller has been
initialized. It's just saying that if NONE of the parent irq domains
have been registered, it's not time for this interrupt controller to
initialize. And yes, as you said, the actual init code can do more
checks and defer probe too. Maybe I'll just put the 2nd sentence as
the comment.


Sure, go ahead.





> + return -EPROBE_DEFER;
> +
> + return irq_init_cb(np, par_np);
> +}
> +EXPORT_SYMBOL_GPL(platform_irqchip_probe);
> diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
> index 950e4b2458f0..6d5eba7cbbb7 100644
> --- a/include/linux/irqchip.h
> +++ b/include/linux/irqchip.h
> @@ -13,6 +13,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  /*
>   * This macro must be used by the different irqchip drivers to declare
> @@ -26,6 +27,28 @@
>   */
>  #define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, 
compat, fn)
>
> +extern int platform_irqchip_probe(struct platform_device *pdev);
> +
> +#define IRQCHIP_PLATFORM_DRIVER_BEGIN \
> +static const struct of_device_id __irqchip_match_table[] = {

How about:

#define IRQCHIP_PLATFORM_DRIVER_BEGIN(drv_name) \
static const struct of_device_id __irqchip_match_table_##drv_name = {

which makes it easier to debug when you want to identify specific
structures in an object (otherwise, they all have the same
name...). it is also much more pleasing aesthetically ;-).


I totally agree. I wanted BEGIN to have the name and END to not have
to specify the name. But I couldn't figure out a way to do it. I
assumed you wouldn't want the names repeated in both BEGIN and END. If
you are okay with that, I prefer your suggestion too.


I'm perfectly fine having the name in both the BEGIN and END tags.
It has a nice LaTeX twist to it ;-).




> +
> +#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn },
> +
> +#define IRQCHIP_PLATFORM_DRIVER_END(drv_name)\
> + {}, \
> +};   \
> +MODULE_DEVICE_TABLE(of, __irqchip_match_table);  \
> +static struct platform_driver drv_name##_driver = {  \

const?


Sure.


> + .probe  = platform_irqchip_probe,   \
> + .driver = { \
> + .name 

Re: [PATCH 2/2] kvm: mmu: page_track: Fix RCU list API usage

[Daniel Díaz]

Hello!

On Fri, 17 Jul 2020 at 12:07, Paul E. McKenney  wrote:
>
> On Thu, Jul 16, 2020 at 05:19:52PM -0700, Dexuan-Linux Cui wrote:
> > On Thu, Jul 16, 2020 at 7:47 AM Naresh Kamboju
> >  wrote:
> > >
> > > On Sun, 12 Jul 2020 at 21:39, Paul E. McKenney  wrote:
> > > >
> > > > On Sun, Jul 12, 2020 at 06:40:03PM +0530, madhuparnabhowmi...@gmail.com 
> > > > wrote:
> > > > > From: Madhuparna Bhowmik 
> > > > >
> > > > > Use hlist_for_each_entry_srcu() instead of hlist_for_each_entry_rcu()
> > > > > as it also checkes if the right lock is held.
> > > > > Using hlist_for_each_entry_rcu() with a condition argument will not
> > > > > report the cases where a SRCU protected list is traversed using
> > > > > rcu_read_lock(). Hence, use hlist_for_each_entry_srcu().
> > > > >
> > > > > Signed-off-by: Madhuparna Bhowmik 
> > > >
> > > > I queued both for testing and review, thank you!
> > > >
> > > > In particular, this one needs an ack by the maintainer.
> > > >
> > > > Thanx, Paul
> > > >
> > > > >  arch/x86/kvm/mmu/page_track.c | 6 --
> > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/arch/x86/kvm/mmu/page_track.c 
> > > > > b/arch/x86/kvm/mmu/page_track.c
> > > > > index a7bcde34d1f2..a9cd17625950 100644
> > > > > --- a/arch/x86/kvm/mmu/page_track.c
> > > > > +++ b/arch/x86/kvm/mmu/page_track.c
> > > > > @@ -229,7 +229,8 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, 
> > > > > gpa_t gpa, const u8 *new,
> > > > >   return;
> > > > >
> > > > >   idx = srcu_read_lock(>track_srcu);
> > > > > - hlist_for_each_entry_rcu(n, >track_notifier_list, node)
> > > > > + hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > > > > + srcu_read_lock_held(>track_srcu))
> > >
> > > x86 build failed on linux -next 20200716.
> > >
> > > arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_write':
> > > include/linux/rculist.h:727:30: error: left-hand operand of comma
> > > expression has no effect [-Werror=unused-value]
> > >   for (__list_check_srcu(cond), \
> > >   ^
> > > arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro
> > > 'hlist_for_each_entry_srcu'
> > >   hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > >   ^
> > > arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_flush_slot':
> > > include/linux/rculist.h:727:30: error: left-hand operand of comma
> > > expression has no effect [-Werror=unused-value]
> > >   for (__list_check_srcu(cond), \
> > >   ^
> > > arch/x86/kvm/mmu/page_track.c:258:2: note: in expansion of macro
> > > 'hlist_for_each_entry_srcu'
> > >   hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > >   ^
> > > cc1: all warnings being treated as errors
> > > make[3]: *** [arch/x86/kvm/mmu/page_track.o] Error 1
> > >
> > > build link,
> > > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-next/DISTRO=lkft,MACHINE=intel-corei7-64,label=docker-lkft/815/consoleText
> > >
> >
> > Hi, we're seeing the same building failure with the latest linux-next tree.
>
> I am not seeing this here.  Could you please let us know what compiler
> and command-line options you are using to generate this?

It fails with gcc-8 and gcc-9, but it builds with gcc-10. Quick way to
reproduce:
  [host] docker run --rm -it -v /linux:/linux -w /linux
tuxbuild/build-gcc-9_mips
  [docker] make ARCH=mips CROSS_COMPILE=mips-linux-gnu- defconfig
  [docker] make ARCH=mips CROSS_COMPILE=mips-linux-gnu- mm

You can use these other Docker containers: tuxbuild/build-gcc-8_mips
and tuxbuild/build-gcc-10_mips.

Logs for those builds (and allnoconfig, tinyconfig, with gcc-8, gcc-9
and gcc-10) can also be found here:
  https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/643978135

Greetings!

Daniel Díaz
daniel.d...@linaro.org

Re: [PATCH v4 1/2] drivers: provide devm_platform_request_irq()

[Markus Elfring]

> v3 -> v4:
>   - The patch v3 sent on May 27 may be lost somewhere in the
> world, so resend it.

Can previous patch review aspects get any more attention?

https://lore.kernel.org/cocci/5dad9b19-ceb5-1606-9f62-7626e5677...@web.de/
https://lkml.org/lkml/2020/5/27/1326

Regards,
Markus

[PATCH net-next 1/2] net: atlantic: align return value of ver_match function with function name

[Mark Starovoytov]

This patch aligns the return value of hw_atl_utils_ver_match function with
its name.
Change the return type to bool, because it's better aligned with the actual
usage. Return true when the version matches, false otherwise.

Signed-off-by: Mark Starovoytov 
Signed-off-by: Igor Russkikh 
---
 .../aquantia/atlantic/hw_atl/hw_atl_utils.c   | 29 +--
 .../aquantia/atlantic/hw_atl/hw_atl_utils.h   |  2 +-
 .../aquantia/atlantic/hw_atl2/hw_atl2_utils.c |  3 +-
 3 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index bf4c41cc312b..22f68e4a638c 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -72,14 +72,11 @@ int hw_atl_utils_initfw(struct aq_hw_s *self, const struct 
aq_fw_ops **fw_ops)
 
self->fw_ver_actual = hw_atl_utils_get_fw_version(self);
 
-   if (hw_atl_utils_ver_match(HW_ATL_FW_VER_1X,
-  self->fw_ver_actual) == 0) {
+   if (hw_atl_utils_ver_match(HW_ATL_FW_VER_1X, self->fw_ver_actual)) {
*fw_ops = _fw_1x_ops;
-   } else if (hw_atl_utils_ver_match(HW_ATL_FW_VER_2X,
- self->fw_ver_actual) == 0) {
+   } else if (hw_atl_utils_ver_match(HW_ATL_FW_VER_2X, 
self->fw_ver_actual)) {
*fw_ops = _fw_2x_ops;
-   } else if (hw_atl_utils_ver_match(HW_ATL_FW_VER_3X,
- self->fw_ver_actual) == 0) {
+   } else if (hw_atl_utils_ver_match(HW_ATL_FW_VER_3X, 
self->fw_ver_actual)) {
*fw_ops = _fw_2x_ops;
} else {
aq_pr_err("Bad FW version detected: %x\n",
@@ -262,9 +259,9 @@ int hw_atl_utils_soft_reset(struct aq_hw_s *self)
/* FW 1.x may bootup in an invalid POWER state (WOL feature).
 * We should work around this by forcing its state back to DEINIT
 */
-   if (!hw_atl_utils_ver_match(HW_ATL_FW_VER_1X,
-   aq_hw_read_reg(self,
-  HW_ATL_MPI_FW_VERSION))) {
+   if (hw_atl_utils_ver_match(HW_ATL_FW_VER_1X,
+  aq_hw_read_reg(self,
+ HW_ATL_MPI_FW_VERSION))) {
int err = 0;
 
hw_atl_utils_mpi_set_state(self, MPI_DEINIT);
@@ -434,20 +431,20 @@ int hw_atl_write_fwsettings_dwords(struct aq_hw_s *self, 
u32 offset, u32 *p,
 p, cnt, MCP_AREA_SETTINGS);
 }
 
-int hw_atl_utils_ver_match(u32 ver_expected, u32 ver_actual)
+bool hw_atl_utils_ver_match(u32 ver_expected, u32 ver_actual)
 {
const u32 dw_major_mask = 0xff00U;
const u32 dw_minor_mask = 0x00ffU;
-   int err = 0;
+   bool ver_match;
 
-   err = (dw_major_mask & (ver_expected ^ ver_actual)) ? -EOPNOTSUPP : 0;
-   if (err < 0)
+   ver_match = (dw_major_mask & (ver_expected ^ ver_actual)) ? false : 
true;
+   if (!ver_match)
goto err_exit;
-   err = ((dw_minor_mask & ver_expected) > (dw_minor_mask & ver_actual)) ?
-   -EOPNOTSUPP : 0;
+   ver_match = ((dw_minor_mask & ver_expected) > (dw_minor_mask & 
ver_actual)) ?
+   false : true;
 
 err_exit:
-   return err;
+   return ver_match;
 }
 
 static int hw_atl_utils_init_ucp(struct aq_hw_s *self,
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
index 0b4b54fc1de0..f5901f8e3907 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
@@ -635,7 +635,7 @@ int hw_atl_utils_fw_rpc_call(struct aq_hw_s *self, unsigned 
int rpc_size);
 int hw_atl_utils_fw_rpc_wait(struct aq_hw_s *self,
 struct hw_atl_utils_fw_rpc **rpc);
 
-int hw_atl_utils_ver_match(u32 ver_expected, u32 ver_actual);
+bool hw_atl_utils_ver_match(u32 ver_expected, u32 ver_actual);
 
 extern const struct aq_fw_ops aq_fw_1x_ops;
 extern const struct aq_fw_ops aq_fw_2x_ops;
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils.c
index f3766780e975..0fe6257d9c08 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl2/hw_atl2_utils.c
@@ -36,8 +36,7 @@ int hw_atl2_utils_initfw(struct aq_hw_s *self, const struct 
aq_fw_ops **fw_ops)
 
self->fw_ver_actual = hw_atl2_utils_get_fw_version(self);
 
-   if (hw_atl_utils_ver_match(HW_ATL2_FW_VER_1X,
-  self->fw_ver_actual) == 0) {
+   if (hw_atl_utils_ver_match(HW_ATL2_FW_VER_1X, self->fw_ver_actual)) {

[PATCH net-next 2/2] net: atlantic: add support for FW 4.x

[Mark Starovoytov]

From: Dmitry Bogdanov 

This patch adds support for FW 4.x, which is about to get into the
production for some products.
4.x is mostly compatible with 3.x, save for soft reset, which requires
the acquisition of 2 additional semaphores.
Other differences (e.g. absence of PTP support) are handled via
capabilities.

Note: 4.x targets specific products only. 3.x is still the main firmware
branch, which should be used by most users (at least for now).

Signed-off-by: Dmitry Bogdanov 
Signed-off-by: Mark Starovoytov 
Signed-off-by: Igor Russkikh 
---
 .../aquantia/atlantic/hw_atl/hw_atl_llh.c | 17 +++--
 .../aquantia/atlantic/hw_atl/hw_atl_llh.h | 10 --
 .../atlantic/hw_atl/hw_atl_llh_internal.h | 11 --
 .../aquantia/atlantic/hw_atl/hw_atl_utils.c   | 35 +++
 4 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c
index d775b23025c1..9c3debae425f 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c
@@ -1,7 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0-only
-/*
- * aQuantia Corporation Network Driver
- * Copyright (C) 2014-2019 aQuantia Corporation. All rights reserved
+/* Atlantic Network Driver
+ *
+ * Copyright (C) 2014-2019 aQuantia Corporation
+ * Copyright (C) 2019-2020 Marvell International Ltd.
  */
 
 /* File hw_atl_llh.c: Definitions of bitfield and register access functions for
@@ -1724,6 +1725,16 @@ u32 hw_atl_sem_mdio_get(struct aq_hw_s *self)
return hw_atl_reg_glb_cpu_sem_get(self, HW_ATL_FW_SM_MDIO);
 }
 
+u32 hw_atl_sem_reset1_get(struct aq_hw_s *self)
+{
+   return hw_atl_reg_glb_cpu_sem_get(self, HW_ATL_FW_SM_RESET1);
+}
+
+u32 hw_atl_sem_reset2_get(struct aq_hw_s *self)
+{
+   return hw_atl_reg_glb_cpu_sem_get(self, HW_ATL_FW_SM_RESET2);
+}
+
 u32 hw_atl_scrpad_get(struct aq_hw_s *aq_hw, u32 scratch_scp)
 {
return aq_hw_read_reg(aq_hw,
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h
index 61a6f70c51cd..f0954711df24 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h
@@ -1,7 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * aQuantia Corporation Network Driver
- * Copyright (C) 2014-2019 aQuantia Corporation. All rights reserved
+/* Atlantic Network Driver
+ *
+ * Copyright (C) 2014-2019 aQuantia Corporation
+ * Copyright (C) 2019-2020 Marvell International Ltd.
  */
 
 /* File hw_atl_llh.h: Declarations of bitfield and register access functions 
for
@@ -838,6 +839,9 @@ u32 hw_atl_sem_ram_get(struct aq_hw_s *self);
 /* get global microprocessor mdio semaphore */
 u32 hw_atl_sem_mdio_get(struct aq_hw_s *self);
 
+u32 hw_atl_sem_reset1_get(struct aq_hw_s *self);
+u32 hw_atl_sem_reset2_get(struct aq_hw_s *self);
+
 /* get global microprocessor scratch pad register */
 u32 hw_atl_scrpad_get(struct aq_hw_s *aq_hw, u32 scratch_scp);
 
diff --git 
a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h
index 7430ff025134..ee11cb88325e 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h
@@ -1,7 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * aQuantia Corporation Network Driver
- * Copyright (C) 2014-2019 aQuantia Corporation. All rights reserved
+/* Atlantic Network Driver
+ *
+ * Copyright (C) 2014-2019 aQuantia Corporation
+ * Copyright (C) 2019-2020 Marvell International Ltd.
  */
 
 /* File hw_atl_llh_internal.h: Preprocessor definitions
@@ -2837,7 +2838,11 @@
 /* Default value of bitfield MDIO Address [F:0] */
 #define HW_ATL_MDIO_ADDRESS_DEFAULT 0x0
 
+#define HW_ATL_MIF_RESET_TIMEOUT_ADR 0x0348
+
 #define HW_ATL_FW_SM_MDIO   0x0U
 #define HW_ATL_FW_SM_RAM0x2U
+#define HW_ATL_FW_SM_RESET1 0x3U
+#define HW_ATL_FW_SM_RESET2 0x4U
 
 #endif /* HW_ATL_LLH_INTERNAL_H */
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index 22f68e4a638c..cacab3352cb8 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -46,6 +46,7 @@
 #define HW_ATL_FW_VER_1X 0x01050006U
 #define HW_ATL_FW_VER_2X 0x0200U
 #define HW_ATL_FW_VER_3X 0x0300U
+#define HW_ATL_FW_VER_4X 0x0400U
 
 #define FORCE_FLASHLESS 0
 
@@ -78,6 +79,8 @@ int hw_atl_utils_initfw(struct aq_hw_s *self, const struct 
aq_fw_ops **fw_ops)
*fw_ops = _fw_2x_ops;
} else if (hw_atl_utils_ver_match(HW_ATL_FW_VER_3X, 
self->fw_ver_actual)) {
*fw_ops = _fw_2x_ops;
+ 

[PATCH net-next 0/2] net: atlantic: add support for FW 4.x

[Mark Starovoytov]

This patch set adds support for FW 4.x, which is about to get into the
production for some products.
4.x is mostly compatible with 3.x, save for soft reset, which requires
the acquisition of 2 additional semaphores.
Other differences (e.g. absence of PTP support) are handled via
capabilities.

Note: 4.x targets specific products only. 3.x is still the main firmware
branch, which should be used by most users (at least for now).

Dmitry Bogdanov (1):
  net: atlantic: add support for FW 4.x

Mark Starovoytov (1):
  net: atlantic: align return value of ver_match function with function
name

 .../aquantia/atlantic/hw_atl/hw_atl_llh.c | 17 +-
 .../aquantia/atlantic/hw_atl/hw_atl_llh.h | 10 +++-
 .../atlantic/hw_atl/hw_atl_llh_internal.h | 11 +++-
 .../aquantia/atlantic/hw_atl/hw_atl_utils.c   | 58 +--
 .../aquantia/atlantic/hw_atl/hw_atl_utils.h   |  2 +-
 .../aquantia/atlantic/hw_atl2/hw_atl2_utils.c |  3 +-
 6 files changed, 70 insertions(+), 31 deletions(-)

-- 
2.25.1

Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call

[Florian Fainelli]

On 7/17/2020 2:45 AM, Sudeep Holla wrote:
> On Wed, Jul 15, 2020 at 03:43:24PM -0700, Florian Fainelli wrote:
>>
>>
>> On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote:
>>> From: Daniele Alessandrelli 
>>>
>>> Currently, when SMC/HVC is used as transport, the base address of the
>>> shared memory used for communication is not passed to the SMCCC call.
>>> This means that such an address must be hard-coded into the bootloader.
>>>
>>> In order to increase flexibility and allow the memory layout to be
>>> changed without modifying the bootloader, this patch adds the shared
>>> memory base address to the a1 argument of the SMCCC call.
>>>
>>> On the Secure Monitor side, the service call implementation can
>>> therefore read the a1 argument in order to know the location of the
>>> shared memory to use. This change is backward compatible to existing
>>> service call implementations as long as they don't check for a1 to be
>>> zero.
>>
>> resource_size_t being defined after phys_addr_t, its size is different
>> between 32-bit, 32-bit with PAE and 64-bit so it would probably make
>> more sense to define an physical address alignment, or maybe an address
>> that is in multiple of 4KBytes so you can address up to 36-bits of
>> physical address even on a 32-bit only system?
>>
> 
> Good point, I had forgotten about LPAE. Thanks for pointing it out.
> 
>> What discovery mechanism does the OS have that the specified address
>> within the SMCCC call has been accepted by the firmware given the return
>> value of that SMCCC call does not appear to be used or checked? Do we
>> just expect a timeout initializing the SCMI subsystem?
>>
> 
> Agreed, we need to add the check for proper return value then and
> definitely document it very clearly as we are trying to standardise
> a call to vendor SiP FID space of SMCCC.
> 
>> Given that the kernel must somehow reserve this memory as a shared
>> memory area for obvious reasons, and the trusted firmware must also
>> ensure it treats this memory region with specific permissions in its
>> translation regime, does it really make sense to give that much flexibility?
>>
> 
> I expect so and this comes as shmem property from DT already. We are
> just passing the value obtained from there as is. This is just to help
> TFA or the firmware to identify the specific channel/shmem as SMC/HVC
> otherwise has no way to do so.

OK, that is fair enough.

> 
>> If your boot loader has FDT patching capability, maybe it can also do a
>> SMC call to provide the address to your trusted firmware, prior to
>> loading the Linux kernel, and then they both agree, prior to boot about
>> the shared memory address?
>>
> 
> Yes, but we definitely can't rely on such mechanism in the kernel. It is
> more a platform choice as they run different bootloaders.
> 

That argument can be be used the other way too if this is a platform
choice, the platform boot loader can ensure that both ends of the SMC
agree on the shared memory region. I do see an advantage to the approach
being suggested here that the shared memory does not necessarily need to
be mapped by the TF prior to Linux booting, but it can be deferred until
when Linux makes the first SMC call but that may require more complexity
on the TF side to issue an appropriate MMU update, so maybe from a
security perspective this is more dangerous..

Alright, I am convinced now this is useful :)
-- 
Florian

Re: [GIT PULL] io_uring fix for 5.8-rc6

[pr-tracker-bot]

The pull request you sent on Fri, 17 Jul 2020 09:52:13 -0600:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.8-2020-07-17

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4ebf8d7649cd86c41c41bf48da4b7761da2d5009

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH 3/3] media: Add support for the AM/FM radio chip KT0913 from KT Micro.

[Joe Perches]

On Fri, 2020-07-17 at 12:04 +0200, Hans Verkuil wrote:
> On 17/07/2020 11:51, Joe Perches wrote:
> > On Fri, 2020-07-17 at 11:29 +0200, Hans Verkuil wrote:
> > > It's standard linux codingstyle to use lowercase for hex numbers.
> > > Can you change that throughout the source for the next version?
> > 
> > Is there a standard?  It's not in coding-style.rst.
> > 
> > While I prefer lowercase too, it seems the kernel has
> > only ~2:1 preference for lowercase to uppercase hex.
> > 
> > $ git grep -ohP '\b0[xX][0-9a-f]+\b' | grep [a-f] | wc -l
> > 1149833
> > $ git grep -ohP '\b0[xX][0-9A-F]+\b' | grep [A-F] | wc -l
> > 575781
> > 
> Well, it's indeed not a standard for the kernel as a whole, but certainly
> for drivers/media:
> 
> $ git grep -ohP '\b0[xX][0-9a-f]+\b' drivers/media/ | grep [a-f] | wc -l
> 109272
> $ git grep -ohP '\b0[xX][0-9A-F]+\b' drivers/media/ | grep [A-F] | wc -l
> 22392
> 
> The media subsystem has a 5:1 preference for lowercase. And uppercase is
> mostly found in older drivers.
> Still, I really prefer lowercase over uppercase, especially in new drivers.

That's certainly any maintainer's preference right.

Slightly unrelated:

The last 100k commits have only a ~2.5:1 use of
lowercase to uppercase hex constants.

While my cut-off for declaring something a generic
kernel style standard is also ~5:1, this isn't a
style check I would put into checkpatch as the
per-subsystem variability is quite high.

cheers, Joe

Re: [Regression] "SUNRPC: Add "@len" parameter to gss_unwrap()" breaks NFS Kerberos on upstream stable 5.4.y

[Kai-Heng Feng]

> On Jul 18, 2020, at 01:34, Chuck Lever  wrote:
> 
> 
> 
>> On Jul 17, 2020, at 1:29 PM, Pierre Sauter  wrote:
>> 
>> Hi Chuck,
>> 
>> Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever:
>>> So this makes me think there's a possibility you are not using upstream
>>> stable kernels. I can't help if I don't know what source code and commit
>>> stream you are using. It also makes me question the bisect result.
>> 
>> Yes you are right, I was referring to Ubuntu kernels 5.4.0-XX. From the
>> discussion in the Ubuntu bugtracker I got the impression that Ubuntu kernels
>> 5.4.0-XX and upstream 5.4.XX are closely related, obviously they are not. The
>> bisection was done by the original bug reporter and also refers to the Ubuntu
>> kernel.
>> 
>> In the meantime I tested v5.4.51 upstream, which shows no problems. Sorry for
>> the bother.
> 
> Pierre, thanks for confirming!
> 
> Kai-Heng suspected an upstream stable commit that is missing in 5.4.0-40,
> but I don't have any good suggestions.

Well, Ubuntu's 5.4 kernel is based on upstream stable v5.4, so I asked users to 
test stable v5.4.51, however the feedback was negative, and that's the reason 
why I raised the issue here.

Anyway, good to know that it's fixed in upstream stable, everything's good now!
Thanks for your effort Chuck.

Kai-Heng


> 
> 
 My krb5 etype is aes256-cts-hmac-sha1-96.
>>> 
>>> Thanks! And what is your NFS server and filesystem? It's possible that the
>>> client is not estimating the size of the reply correctly. Variables include
>>> the size of file handles, MIC verifiers, and wrap tokens.
>> 
>> The server is Debian with v4.19.130 upstream, filesystem ext4.
>> 
>>> You might try:
>>> 
>>> e8d70b321ecc ("SUNRPC: Fix another issue with MIC buffer space")
>> 
>> That one is actually in Ubuntus 5.4.0-40, from looking at the code.
> 
> --
> Chuck Lever

Re: [PATCH v5 03/17] perf ftrace: add option -t/--tid to filter by thread id

[Steven Rostedt]

On Fri, 17 Jul 2020 14:40:53 -0300
Arnaldo Carvalho de Melo  wrote:

> Say you use:
> 
> ^C[root@ssdandy ~]# cyclictest --smp -um -p95
> # /dev/cpu_dma_latency set to 0us
> policy: fifo: loadavg: 0.05 0.03 0.06 2/409 29072
> 
> T: 0 (29065) P:95 I:1000 C:518 Min:  2 Act:2 Avg:2 Max:   
> 6
> T: 1 (29066) P:95 I:1500 C:343 Min:  2 Act:2 Avg:2 Max:   
> 5
> T: 2 (29067) P:95 I:2000 C:256 Min:  2 Act:2 Avg:2 Max:   
> 7
> T: 3 (29068) P:95 I:2500 C:203 Min:  2 Act:2 Avg:2 Max:   
> 5
> T: 4 (29069) P:95 I:3000 C:168 Min:  2 Act:2 Avg:3 Max:   
> 6
> T: 5 (29070) P:95 I:3500 C:143 Min:  2 Act:2 Avg:2 Max:   
> 6
> T: 6 (29071) P:95 I:4000 C:124 Min:  2 Act:2 Avg:2 Max:   
> 7
> T: 7 (29072) P:95 I:4500 C:110 Min:  2 Act:2 Avg:2 Max:
> 
> Then we do:
> 
> # pidof cyclictest
> 29064
> #
> 
> If we use:
> 
> [root@ssdandy ~]# perf record --pid 29064
> ^C[ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.052 MB perf.data (866 samples) ]
> 
> [root@ssdandy ~]# perf report --task
> #  pid  tid ppid  comm
>  00   -1 |swapper
>  2906429064   -1 |cyclictest
>  2906429065   -1 |cyclictest
>  2906429066   -1 |cyclictest
>  2906429067   -1 |cyclictest
>  2906429068   -1 |cyclictest
>  2906429069   -1 |cyclictest
>  2906429070   -1 |cyclictest
>  2906429071   -1 |cyclictest
>  2906429072   -1 |cyclictest
> [root@ssdandy ~]#

"ftrace" is inside the kernel. But you could specify all those PIDs in
the set_ftrace_pid and set_event_pid files, and they will be traced. If
you want to trace the children of those PIDs, you would need to set the
options function function-fork and event-fork respectively. And then
any time a process with a pid in the set_ftrace_pid or set_event_pid
file forks, its child will also be added to that file and it too will
be traced. If the fork options are set, then when a task exits, its pid
will be removed from the file.

 echo 1 > options/function-fork
 echo 1 > options/event-fork


> 
> If we are interested only on the thread running on CPU3 we can do:
> 
> [root@ssdandy ~]# perf report --task
> #  pid  tid ppid  comm
>  00   -1 |swapper
>  2906429064   -1 |cyclictest
>  2906429068   -1 |cyclictest
> [root@ssdandy ~]#
> 
> The first 29064 is just to have info on who created 29068, i.e.:
> 
> Its just the synthesized info for 29068 creator:
> 
> [root@ssdandy ~]# perf report -D | grep -w 29064/29064
> 0 0x4690 [0x30]: PERF_RECORD_COMM: cyclictest:29064/29064
> 0 0x46c0 [0x70]: PERF_RECORD_MMAP2 29064/29064: [0x40(0xa000) @ 0 fd:00 
> 136246288 0]: r-xp /usr/bin/cyclictest
> 0 0x4730 [0x80]: PERF_RECORD_MMAP2 29064/29064: [0x7f990f505000(0x15000) @ 0 
> fd:00 201479398 0]: r-xp /usr/lib64/libgcc_s-4.8.5-20150702.so.1
> 0 0x47b0 [0x70]: PERF_RECORD_MMAP2 29064/29064: [0x7f990f71b000(0x1c3000) @ 0 
> fd:00 201334455 0]: r-xp /usr/lib64/libc-2.17.so
> 0 0x4820 [0x78]: PERF_RECORD_MMAP2 29064/29064: [0x7f990fae9000(0xa000) @ 0 
> fd:00 204604380 0]: r-xp /usr/lib64/libnuma.so.1.0.0
> 0 0x4898 [0x78]: PERF_RECORD_MMAP2 29064/29064: [0x7f990fcf5000(0x17000) @ 0 
> fd:00 201335636 0]: r-xp /usr/lib64/libpthread-2.17.so
> 0 0x4910 [0x78]: PERF_RECORD_MMAP2 29064/29064: [0x7f990ff11000(0x7000) @ 0 
> fd:00 201335640 0]: r-xp /usr/lib64/librt-2.17.so
> 0 0x4988 [0x70]: PERF_RECORD_MMAP2 29064/29064: [0x7f9910119000(0x22000) @ 0 
> fd:00 203595299 0]: r-xp /usr/lib64/ld-2.17.so
> 0 0x49f8 [0x60]: PERF_RECORD_MMAP2 29064/29064: [0x7fff0b52d000(0x2000) @ 0 
> 00:00 0 0]: r-xp [vdso]
> 0 0x4a58 [0x68]: PERF_RECORD_MMAP2 29064/29064: [0xff60(0x1000) @ 
> 0 00:00 0 0]: r-xp [vsyscall]
> [root@ssdandy ~]#
> 
> No PERF_RECORD_SAMPLEs.
> 
> Those are only for:
> 
> [root@ssdandy ~]# perf report -D | grep PERF_RECORD_SAMPLE | head -5
> 147224656598815 0x4ac0 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4001): 29064/29068: 
> 0xa8e5b568 period: 1 addr: 0
> 147224656606270 0x4ae8 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4001): 29064/29068: 
> 0xa8e5b568 period: 1 addr: 0
> 147224656611284 0x4b10 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4001): 29064/29068: 
> 0xa8e5b568 period: 5 addr: 0
> 147224656616225 0x4b38 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4001): 29064/29068: 
> 0xa8e5b568 period: 35 addr: 0
> 147224656621152 0x4b60 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4001): 29064/29068: 
> 0xa8e5b568 period: 252 addr: 0
> [root@ssdandy ~]#
> 
> [root@ssdandy ~]# perf report -D | grep PERF_RECORD_SAMPLE | cut -d: -f3 | 
> sort -u
>  29064/29068

The above can somewhat be done in trace-cmd, but not fully. But that's
all userspace commands, nothing with the kernel.

> [root@ssdandy ~]#
> 
> Is there a way in ftrace to ask for a pid 

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

[Mathieu Desnoyers]

- On Jul 17, 2020, at 1:44 PM, Alan Stern st...@rowland.harvard.edu wrote:

> On Fri, Jul 17, 2020 at 12:22:49PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 17, 2020, at 12:11 PM, Alan Stern st...@rowland.harvard.edu 
>> wrote:
>> 
>> >> > I agree with Nick: A memory barrier is needed somewhere between the
>> >> > assignment at 6 and the return to user mode at 8.  Otherwise you end up
>> >> > with the Store Buffer pattern having a memory barrier on only one side,
>> >> > and it is well known that this arrangement does not guarantee any
>> >> > ordering.
>> >> 
>> >> Yes, I see this now. I'm still trying to wrap my head around why the 
>> >> memory
>> >> barrier at the end of membarrier() needs to be paired with a scheduler
>> >> barrier though.
>> > 
>> > The memory barrier at the end of membarrier() on CPU0 is necessary in
>> > order to enforce the guarantee that any writes occurring on CPU1 before
>> > the membarrier() is executed will be visible to any code executing on
>> > CPU0 after the membarrier().  Ignoring the kthread issue, we can have:
>> > 
>> >CPU0CPU1
>> >x = 1
>> >barrier()
>> >y = 1
>> >r2 = y
>> >membarrier():
>> >  a: smp_mb()
>> >  b: send IPI   IPI-induced mb
>> >  c: smp_mb()
>> >r1 = x
>> > 
>> > The writes to x and y are unordered by the hardware, so it's possible to
>> > have r2 = 1 even though the write to x doesn't execute until b.  If the
>> > memory barrier at c is omitted then "r1 = x" can be reordered before b
>> > (although not before a), so we get r1 = 0.  This violates the guarantee
>> > that membarrier() is supposed to provide.
>> > 
>> > The timing of the memory barrier at c has to ensure that it executes
>> > after the IPI-induced memory barrier on CPU1.  If it happened before
>> > then we could still end up with r1 = 0.  That's why the pairing matters.
>> > 
>> > I hope this helps your head get properly wrapped.  :-)
>> 
>> It does help a bit! ;-)
>> 
>> This explains this part of the comment near the smp_mb at the end of 
>> membarrier:
>> 
>>  * Memory barrier on the caller thread _after_ we finished
>>  * waiting for the last IPI. [...]
>> 
>> However, it does not explain why it needs to be paired with a barrier in the
>> scheduler, clearly for the case where the IPI is skipped. I wonder whether 
>> this
>> part
>> of the comment is factually correct:
>> 
>>  * [...] Matches memory barriers around rq->curr modification in 
>> scheduler.
> 
> The reasoning is pretty much the same as above:
> 
>   CPU0CPU1
>   x = 1
>   barrier()
>   y = 1
>   r2 = y
>   membarrier():
> a: smp_mb()
>   switch to kthread (includes mb)
> b: read rq->curr == kthread
>   switch to user (includes mb)
> c: smp_mb()
>   r1 = x
> 
> Once again, it is possible that x = 1 doesn't become visible to CPU0
> until shortly before b.  But if c is omitted then "r1 = x" can be
> reordered before b (to any time after a), so we can have r1 = 0.
> 
> Here the timing requirement is that c executes after the first memory
> barrier on CPU1 -- which is one of the ones around the rq->curr
> modification.  (In fact, in this scenario CPU1's switch back to the user
> process is irrelevant.)

That indeed covers the last scenario I was wondering about. Thanks Alan!

Mathieu

> 
> Alan Stern

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Alan Stern]

On Fri, Jul 17, 2020 at 06:47:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
...
> > +   /* on success, pairs with smp_load_acquire() above and below */
> > +   if (cmpxchg_release(, NULL, p) != NULL) {
> 
> Why do we have cmpxchg_release() anyway?  Under what circumstances is
> cmpxchg() useful _without_ having release semantics?

To answer just the last question: cmpxchg() is useful for lock 
acquisition, in which case it needs to have acquire semantics rather 
than release semantics.

Alan Stern

Re: [PATCH v2] irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros

[Saravana Kannan]

On Fri, Jul 17, 2020 at 3:49 AM Marc Zyngier  wrote:
>
> Hi Saravana,
>
> Thanks for re-spinning this one.
>
> On Fri, 17 Jul 2020 03:44:47 +0100,
> Saravana Kannan  wrote:
> >
> > Compiling an irqchip driver as a platform driver needs to bunch of
> > things to be done right:
> > - Making sure the parent domain is initialized first
> > - Making sure the device can't be unbound from sysfs
> > - Disallowing module unload if it's built as a module
> > - Finding the parent node
> > - Etc.
> >
> > Instead of trying to make sure all future irqchip platform drivers get
> > this right, provide boilerplate macros that take care of all of this.
> >
> > An example use would look something like this. Where acme_foo_init and
> > acme_bar_init are similar to what would be passed to IRQCHIP_DECLARE.
> >
> > IRQCHIP_PLATFORM_DRIVER_BEGIN
>
> I think there is some value in having the BEGIN statement containing
> the driver name, see below.
>
> > IRQCHIP_MATCH(foo, "acme,foo", acme_foo_init)
> > IRQCHIP_MATCH(bar, "acme,bar", acme_bar_init)
> > IRQCHIP_PLATFORM_DRIVER_END(acme_irq)
> >
> > Signed-off-by: Saravana Kannan 
> > ---
> >  drivers/irqchip/irqchip.c | 22 ++
> >  include/linux/irqchip.h   | 23 +++
> >  2 files changed, 45 insertions(+)
> >
> > diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
> > index 2b35e68bea82..236ea793f01c 100644
> > --- a/drivers/irqchip/irqchip.c
> > +++ b/drivers/irqchip/irqchip.c
> > @@ -10,8 +10,10 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  /*
> >   * This special of_device_id is the sentinel at the end of the
> > @@ -29,3 +31,23 @@ void __init irqchip_init(void)
> >   of_irq_init(__irqchip_of_table);
> >   acpi_probe_device_table(irqchip);
> >  }
> > +
> > +int platform_irqchip_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + struct device_node *par_np = of_irq_find_parent(np);
> > + of_irq_init_cb_t irq_init_cb = of_device_get_match_data(>dev);
> > +
> > + if (!irq_init_cb)
> > + return -EINVAL;
> > +
> > + if (par_np == np)
> > + par_np = NULL;
> > +
> > + /* If there's a parent irqchip, make sure it has been initialized. */
> > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY))
>
> There is no guarantee that the calling driver wants BUS_ANY as a token
> for its parent. It may work for now, if you only have dependencies to
> drivers that only expose a single domain, but that's not a general
> purpose check..
>
> At least, please add a comment saying that the new driver may want to
> check that the irqdomain it depends on may not be available.

This is just checking if the parent interrupt controller has been
initialized. It's just saying that if NONE of the parent irq domains
have been registered, it's not time for this interrupt controller to
initialize. And yes, as you said, the actual init code can do more
checks and defer probe too. Maybe I'll just put the 2nd sentence as
the comment.

>
> > + return -EPROBE_DEFER;
> > +
> > + return irq_init_cb(np, par_np);
> > +}
> > +EXPORT_SYMBOL_GPL(platform_irqchip_probe);
> > diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
> > index 950e4b2458f0..6d5eba7cbbb7 100644
> > --- a/include/linux/irqchip.h
> > +++ b/include/linux/irqchip.h
> > @@ -13,6 +13,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  /*
> >   * This macro must be used by the different irqchip drivers to declare
> > @@ -26,6 +27,28 @@
> >   */
> >  #define IRQCHIP_DECLARE(name, compat, fn) OF_DECLARE_2(irqchip, name, 
> > compat, fn)
> >
> > +extern int platform_irqchip_probe(struct platform_device *pdev);
> > +
> > +#define IRQCHIP_PLATFORM_DRIVER_BEGIN \
> > +static const struct of_device_id __irqchip_match_table[] = {
>
> How about:
>
> #define IRQCHIP_PLATFORM_DRIVER_BEGIN(drv_name) \
> static const struct of_device_id __irqchip_match_table_##drv_name = {
>
> which makes it easier to debug when you want to identify specific
> structures in an object (otherwise, they all have the same
> name...). it is also much more pleasing aesthetically ;-).

I totally agree. I wanted BEGIN to have the name and END to not have
to specify the name. But I couldn't figure out a way to do it. I
assumed you wouldn't want the names repeated in both BEGIN and END. If
you are okay with that, I prefer your suggestion too.

> > +
> > +#define IRQCHIP_MATCH(compat, fn) { .compatible = compat, .data = fn },
> > +
> > +#define IRQCHIP_PLATFORM_DRIVER_END(drv_name)\
> > + {}, \
> > +};   \
> > +MODULE_DEVICE_TABLE(of, __irqchip_match_table);  \
> > +static struct platform_driver drv_name##_driver = {  \
>
> const?

Sure.

> > + .probe  = platform_irqchip_probe,   \
> > + .driver = 

Re: [PATCH] Fix memory overwriting issue when copy an address to user space

[Jakub Kicinski]

On Fri, 17 Jul 2020 10:31:54 + lebon zhou wrote:
> When application provided buffer size less than sockaddr_storage, then
> kernel will overwrite some memory area which may cause memory corruption,
> e.g.: in recvmsg case, let msg_name=malloc(8) and msg_namelen=8, then
> usually application can call recvmsg successful but actually application
> memory get corrupted.
> 
> Fix to return EINVAL when application buffer size less than
> sockaddr_storage.
> 
> Signed-off-by: lebon.zhou 

Please repoist CCing the netdev mailing list.

Re: [patch V3 01/13] entry: Provide generic syscall entry functionality

[Kees Cook]

On Thu, Jul 16, 2020 at 11:55:59PM +0200, Thomas Gleixner wrote:
> Kees Cook  writes:
> > On Thu, Jul 16, 2020 at 08:22:09PM +0200, Thomas Gleixner wrote:
> >> This code is needlessly duplicated and  different in all
> >> architectures.
> >> 
> >> Provide a generic version based on the x86 implementation which has all the
> >> RCU and instrumentation bits right.
> >
> > Ahh! You're reading my mind!
> 
> I told you about that plan at the last conference over a beer :)

Thank you for incepting it in my head, then! ;)

> > [1] 
> > https://lore.kernel.org/lkml/20200716193141.4068476-2-kris...@collabora.com/
> 
> Saw that fly by. *shudder*

Aw, it's nice. Better emulation! :)

> 
> >> +/*
> >> + * Define dummy _TIF work flags if not defined by the architecture or for
> >> + * disabled functionality.
> >> + */
> >
> > When I was thinking about this last week I was pondering having a split
> > between the arch-agnositc TIF flags and the arch-specific TIF flags, and
> > that each arch could have a single "there is agnostic work to be done"
> > TIF in their thread_info, and the agnostic flags could live in
> > task_struct or something. Anyway, I'll keep reading...
> 
> That's going to be nasty. We rather go and expand the TIF storage to
> 64bit. And then do the following in a generic header:

I though the point was to make the TIF_WORK check as fast as possible,
even on the 32-bit word systems. I mean it's not a huge performance hit,
but *shrug*

> 
> #ifndef TIF_ARCH_SPECIFIC
> # define TIF_ARCH_SPECIFIC
> #endif
> 
> enum tif_bits {
>   TIF_NEED_RESCHED = 0,
> TIF_...,
> TIF_LAST_GENERIC,
> TIF_ARCH_SPECIFIC,
> };
> 
> and in the arch specific one:
> 
> #define TIF_ARCH_SPECIFIC \
>   TIF_ARCH_1, \
> TIF_ARCH_2,
> 
> or something like that.

Okay, yeah, that can work.

> > There's been some recent confusion over "has the syscall changed,
> > or did seccomp request it be skipped?" that was explored in arm64[2]
> > (though I see Will and Keno in CC already). There might need to be a
> > clearer way to distinguish between "wild userspace issued a -1 syscall"
> > and "seccomp or ptrace asked for the syscall to be skipped". The
> > difference is mostly about when ENOSYS gets set, with respect to calls
> > to syscall_set_return_value(), but if the syscall gets changed, the arch
> > may need to recheck the value and consider ENOSYS, etc. IIUC, what Will
> > ended up with[3] was having syscall_trace_enter() return the syscall return
> > value instead of the new syscall.
> 
> I was chatting with Will about that yesterday. IIRC he plans to fix the
> immediate issue on arm64 first and then move arm64 over to the generic
> variant. That's the reason why I reshuffled the patch series so the
> generic parts are first which allows me to provide will a branch with
> just those. If there are any changes needed we can just feed them back
> into that branch and fixup the affected architecture trees.
> 
> IOW, that should not block progress on this stuff.

Ok, great! I just wanted to make sure that didn't surprise anyone. :)

-- 
Kees Cook

Re: [PATCH v4 5/9] media: staging: rkisp1: remove unecessary clocks

[Rob Herring]

On Thu, Jul 2, 2020 at 1:13 PM Helen Koike  wrote:
>
> aclk_isp_wrap is a child of aclk_isp, and hclk_isp_wrap is a child of
> hclk_isp, thus we can remove parents from the list.

But it looks like it is the wrap clocks you are removing.

>
> Also, for the isp0, we only need the ISP clock, ACLK and HCLK.
> In the future we'll need a pixel clock for RK3288 and RK3399, and a JPEG
> clock for RK3288.
>
> So with the goal to cleanup the dt-bindings and remove it from staging,
> simplify clock names to isp, aclk and hclk.
>
> For reference, this is the isp clock topology on RK3399:
>
>  xin24m
> pll_npll
>npll
>   clk_isp1
>   clk_isp0
> pll_cpll
>cpll
>   aclk_isp1
>  aclk_isp1_noc
>  hclk_isp1
> aclk_isp1_wrapper
> hclk_isp1_noc
>   aclk_isp0
>  hclk_isp1_wrapper
>  aclk_isp0_wrapper
>  aclk_isp0_noc
>  hclk_isp0
> hclk_isp0_wrapper
> hclk_isp0_noc
>  pclkin_isp1_wrapper
>
> Signed-off-by: Helen Koike 
>
> ---
>
> Changes in V4:
> - update binding according to suggestion by Robin Murphy
> on https://patchwork.kernel.org/patch/11475007/
>
> Changes in V3:
> - this is a new patch in the series
> ---
>  .../bindings/media/rockchip-isp1.yaml | 30 +--
>  drivers/staging/media/rkisp1/rkisp1-dev.c |  8 ++---
>  2 files changed, 17 insertions(+), 21 deletions(-)
>
> diff --git 
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>  
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> index 4d111ef2e89c7..f10c53d008748 100644
> --- 
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> +++ 
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> @@ -24,20 +24,20 @@ properties:
>  maxItems: 1
>
>clocks:
> -items:
> -  - description: ISP clock
> -  - description: ISP AXI clock clock
> -  - description: ISP AXI clock  wrapper clock
> -  - description: ISP AHB clock clock
> -  - description: ISP AHB wrapper clock

This is the correct way to describe multiple clocks.

> +maxItems: 5

Now the 4th and 5th clock are undefined.

> +minItems: 3
> +description:
> +  ISP clock
> +  ISP AXI clock
> +  ISP AHB clock
>
>clock-names:
> +maxItems: 5

This should not be more than the number of entries in 'items'.

> +minItems: 3
>  items:
> -  - const: clk_isp
> -  - const: aclk_isp
> -  - const: aclk_isp_wrap
> -  - const: hclk_isp
> -  - const: hclk_isp_wrap
> +  - const: isp
> +  - const: aclk
> +  - const: hclk
>
>iommus:
>  maxItems: 1
> @@ -135,11 +135,9 @@ examples:
>  reg = <0x0 0xff91 0x0 0x4000>;
>  interrupts = ;
>  clocks = < SCLK_ISP0>,
> - < ACLK_ISP0>, < ACLK_ISP0_WRAPPER>,
> - < HCLK_ISP0>, < HCLK_ISP0_WRAPPER>;
> -clock-names = "clk_isp",
> -  "aclk_isp", "aclk_isp_wrap",
> -  "hclk_isp", "hclk_isp_wrap";
> + < ACLK_ISP0_WRAPPER>,
> + < HCLK_ISP0_WRAPPER>;
> +clock-names = "isp", "aclk", "hclk";
>  iommus = <_mmu>;
>  phys = <>;
>  phy-names = "dphy";
> diff --git a/drivers/staging/media/rkisp1/rkisp1-dev.c 
> b/drivers/staging/media/rkisp1/rkisp1-dev.c
> index f38801fea10d9..175ac25fe99fa 100644
> --- a/drivers/staging/media/rkisp1/rkisp1-dev.c
> +++ b/drivers/staging/media/rkisp1/rkisp1-dev.c
> @@ -406,11 +406,9 @@ static irqreturn_t rkisp1_isr(int irq, void *ctx)
>  }
>
>  static const char * const rk3399_isp_clks[] = {
> -   "clk_isp",
> -   "aclk_isp",
> -   "hclk_isp",
> -   "aclk_isp_wrap",
> -   "hclk_isp_wrap",
> +   "isp",
> +   "aclk",
> +   "hclk",
>  };
>
>  static const struct rkisp1_match_data rk3399_isp_clk_data = {
> --
> 2.26.0
>

Re: [PATCH] net: genetlink: Move initialization to core_initcall

[Daniel Lezcano]

On 17/07/2020 19:34, David Miller wrote:
> From: Daniel Lezcano 
> Date: Wed, 15 Jul 2020 09:43:00 +0200
> 
>> if you agree with this change, is it possible I merge it through the
>> thermal tree in order to fix the issue ?
> 
> No problem:
> 
> Acked-by: David S. Miller 

Thanks!


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: linux-next: build warning after merge of the akpm-current tree

[Roman Gushchin]

On Fri, Jul 17, 2020 at 08:31:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined
>   614 | #define MAX_THRESHOLD 0
>   | 
> mm/vmstat.c:172: note: this is the location of the previous definition
>   172 | #define MAX_THRESHOLD 125
>   | 
> mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined
>   614 | #define MAX_THRESHOLD 0
>   | 
> mm/vmstat.c:172: note: this is the location of the previous definition
>   172 | #define MAX_THRESHOLD 125
>   | 
> 
> Introduced by commit
> 
>   5f6bac149e10 ("mm: vmstat: fix /proc/sys/vm/stat_refresh generating false 
> warnings")
> 
> The preproccesor directives look like this:
> 
> #ifdef CONFIG_SMP
> #define MAX_THRESHOLD 125
> #ifdef CONFIG_HAVE_CMPXCHG_LOCAL
> #else
> #define MAX_THRESHOLD 0
> 
> So I guess the second MAX_THRESHOLD was put after the wrong #else?

Right, I missed it. Sorry for the inconvenience!
And thank you for pointing at it!

The following diff fixes it.

Andrew, can you, please, squash it into the
"mm: vmstat: fix /proc/sys/vm/stat_refresh generating false warnings" ?

Thank you!

--

diff --git a/mm/vmstat.c b/mm/vmstat.c
index 8f0ef8aaf8ee..08e415e0a15d 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -168,9 +168,12 @@ EXPORT_SYMBOL(vm_numa_stat);
 EXPORT_SYMBOL(vm_node_stat);
 
 #ifdef CONFIG_SMP
-
 #define MAX_THRESHOLD 125
+#else
+#define MAX_THRESHOLD 0
+#endif
 
+#ifdef CONFIG_SMP
 int calculate_pressure_threshold(struct zone *zone)
 {
int threshold;
@@ -611,8 +614,6 @@ void dec_node_page_state(struct page *page, enum 
node_stat_item item)
 EXPORT_SYMBOL(dec_node_page_state);
 #else
 
-#define MAX_THRESHOLD 0
-
 /*
  * Use interrupt disable to serialize counter updates
  */
-- 
2.26.2

Re: [PATCH] tools/memory-model: document the "one-time init" pattern

[Matthew Wilcox]

On Thu, Jul 16, 2020 at 09:44:27PM -0700, Eric Biggers wrote:
> +If that doesn't apply, you'll have to implement one-time init yourself.
> +
> +The simplest implementation just uses a mutex and an 'inited' flag.
> +This implementation should be used where feasible:

I think some syntactic sugar should make it feasible for normal people
to implement the most efficient version of this just like they use locks.

> +For the single-pointer case, a further optimized implementation
> +eliminates the mutex and instead uses compare-and-exchange:
> +
> + static struct foo *foo;
> +
> + int init_foo_if_needed(void)
> + {
> + struct foo *p;
> +
> + /* pairs with successful cmpxchg_release() below */
> + if (smp_load_acquire())
> + return 0;
> +
> + p = alloc_foo();
> + if (!p)
> + return -ENOMEM;
> +
> + /* on success, pairs with smp_load_acquire() above and below */
> + if (cmpxchg_release(, NULL, p) != NULL) {

Why do we have cmpxchg_release() anyway?  Under what circumstances is
cmpxchg() useful _without_ having release semantics?

> + free_foo(p);
> + /* pairs with successful cmpxchg_release() above */
> + smp_load_acquire();
> + }
> + return 0;
> + }

How about something like this ...

once.h:

static struct init_once_pointer {
void *p;
};

static inline void *once_get(struct init_once_pointer *oncep)
{ ... }

static inline bool once_store(struct init_once_pointer *oncep, void *p)
{ ... }

--- foo.c ---

struct foo *get_foo(gfp_t gfp)
{
static struct init_once_pointer my_foo;
struct foo *foop;

foop = once_get(_foo);
if (foop)
return foop;

foop = alloc_foo(gfp);
if (!once_store(_foo, foop)) {
free_foo(foop);
foop = once_get(_foo);
}

return foop;
}

Any kernel programmer should be able to handle that pattern.  And no mutex!

Re: [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool

[Sami Tolvanen]

On Fri, Jul 17, 2020 at 10:36 AM Steven Rostedt  wrote:
>
> On Fri, 17 Jul 2020 10:28:13 -0700
> Sami Tolvanen  wrote:
>
> > On Fri, Jun 26, 2020 at 4:29 AM Peter Zijlstra  wrote:
> > >
> > > On Thu, Jun 25, 2020 at 03:40:42PM -0700, Sami Tolvanen wrote:
> > >
> > > > > Not boot tested, but it generates the required sections and they look
> > > > > more or less as expected, ymmv.
> > >
> > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > > > index a291823f3f26..189575c12434 100644
> > > > > --- a/arch/x86/Kconfig
> > > > > +++ b/arch/x86/Kconfig
> > > > > @@ -174,7 +174,6 @@ config X86
> > > > > select HAVE_EXIT_THREAD
> > > > > select HAVE_FAST_GUP
> > > > > select HAVE_FENTRY  if X86_64 || 
> > > > > DYNAMIC_FTRACE
> > > > > -   select HAVE_FTRACE_MCOUNT_RECORD
> > > > > select HAVE_FUNCTION_GRAPH_TRACER
> > > > > select HAVE_FUNCTION_TRACER
> > > > > select HAVE_GCC_PLUGINS
> > > >
> > > > This breaks DYNAMIC_FTRACE according to kernel/trace/ftrace.c:
> > > >
> > > >   #ifndef CONFIG_FTRACE_MCOUNT_RECORD
> > > >   # error Dynamic ftrace depends on MCOUNT_RECORD
> > > >   #endif
> > > >
> > > > And the build errors after that seem to confirm this. It looks like we 
> > > > might
> > > > need another flag to skip recordmcount.
> > >
> > > Hurm, Steve, how you want to do that?
> >
> > Steven, did you have any thoughts about this? Moving recordmcount to
> > an objtool pass that knows about call sites feels like a much cleaner
> > solution than annotating kernel code to avoid unwanted relocations.
> >
>
> Bah, I started to reply to this then went to look for details, got
> distracted, forgot about it, my laptop crashed (due to a zoom call),
> and I lost the email I was writing (haven't looked in the drafts
> folder, but my idea about this has changed since anyway).
>
> So the problem is that we process mcount references in other areas and
> that confuses the ftrace modification portion?

Correct.

> Someone just submitted a patch for arm64 for this:
>
> https://lore.kernel.org/r/20200717143338.19302-1-gregory.herr...@oracle.com
>
> Is that what you want?

That looks like the same issue, but we need to fix this on x86 instead.

Sami

Re: [PATCH v3 3/4] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains

[Rob Clark]

On Thu, Jul 9, 2020 at 4:05 AM Rajendra Nayak  wrote:
>
> Add the OPP tables for DSI and MDP based on the perf state/clk
> requirements, and add the power-domains property to specify the
> scalable power domain.
>
> Signed-off-by: Rajendra Nayak 
> Reviewed-by: Matthias Kaehlcke 

Tested-by: Rob Clark 

Bjorn, the two driver patches are queued up in msm-next, I assume
you'll pickup the two dt patches?

BR,
-R

> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 59 
> 
>  1 file changed, 59 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index fee50d9..3efdd70 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -3296,6 +3296,35 @@
> #power-domain-cells = <1>;
> };
>
> +   dsi_opp_table: dsi-opp-table {
> +   compatible = "operating-points-v2";
> +
> +   opp-1920 {
> +   opp-hz = /bits/ 64 <1920>;
> +   required-opps = <_opp_min_svs>;
> +   };
> +
> +   opp-18000 {
> +   opp-hz = /bits/ 64 <18000>;
> +   required-opps = <_opp_low_svs>;
> +   };
> +
> +   opp-27500 {
> +   opp-hz = /bits/ 64 <27500>;
> +   required-opps = <_opp_svs>;
> +   };
> +
> +   opp-32858 {
> +   opp-hz = /bits/ 64 <32858>;
> +   required-opps = <_opp_svs_l1>;
> +   };
> +
> +   opp-35800 {
> +   opp-hz = /bits/ 64 <35800>;
> +   required-opps = <_opp_nom>;
> +   };
> +   };
> +
> mdss: mdss@ae0 {
> compatible = "qcom,sdm845-mdss";
> reg = <0 0x0ae0 0 0x1000>;
> @@ -3340,6 +3369,8 @@
>   < 
> DISP_CC_MDSS_VSYNC_CLK>;
> assigned-clock-rates = <3>,
><1920>;
> +   operating-points-v2 = <_opp_table>;
> +   power-domains = < SDM845_CX>;
>
> interrupt-parent = <>;
> interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> @@ -3364,6 +3395,30 @@
> };
> };
> };
> +
> +   mdp_opp_table: mdp-opp-table {
> +   compatible = "operating-points-v2";
> +
> +   opp-1920 {
> +   opp-hz = /bits/ 64 <1920>;
> +   required-opps = 
> <_opp_min_svs>;
> +   };
> +
> +   opp-171428571 {
> +   opp-hz = /bits/ 64 
> <171428571>;
> +   required-opps = 
> <_opp_low_svs>;
> +   };
> +
> +   opp-34400 {
> +   opp-hz = /bits/ 64 
> <34400>;
> +   required-opps = 
> <_opp_svs_l1>;
> +   };
> +
> +   opp-43000 {
> +   opp-hz = /bits/ 64 
> <43000>;
> +   required-opps = 
> <_opp_nom>;
> +   };
> +   };
> };
>
> dsi0: dsi@ae94000 {
> @@ -3386,6 +3441,8 @@
>   "core",
>   "iface",
>   "bus";
> +   operating-points-v2 = <_opp_table>;
> +   power-domains = < SDM845_CX>;
>
> phys = <_phy>;
> phy-names = "dsi";
> @@ -3450,6 +3507,8 @@
>   "core",
>   "iface",
>   "bus";
> +   operating-points-v2 = <_opp_table>;
> +   power-domains = < SDM845_CX>;
>
> 

Re: [RFC PATCH v3 00/18] Support for Tegra video capture from external sensor

[Sowjanya Komatineni]

On 7/17/20 10:38 AM, Sowjanya Komatineni wrote:


On 7/17/20 10:23 AM, Sowjanya Komatineni wrote:


On 7/17/20 10:08 AM, Hans Verkuil wrote:

On 17/07/2020 18:34, Sowjanya Komatineni wrote:

On 7/17/20 3:54 AM, Hans Verkuil wrote:

Hi Sowjanya,

On 15/07/2020 06:20, Sowjanya Komatineni wrote:
This series adds support for video capture from external camera 
sensor to

Tegra video driver.

Jetson TX1 has camera expansion connector and supports custom 
camera module

designed as per TX1 design specification.

This series also enables camera capture support for Jetson Nano 
which has

Raspberry PI camera header.

This series is tested with IMX219 camera sensor.

This series include,

VI I2C related fixes
- Camera sensor programming happens through VI I2C which is on 
host1x bus.
- These patches includes device tree and I2C driver fixes for VI 
I2C.


Tegra video driver updates
- TPG Vs Non-TPG based on Kconfig
- Support for external sensor video capture based on device graph 
from DT.

- Support for selection ioctl operations
- Tegra MIPI CSI pads calibration
- CSI T-CLK and T-HS settle time computation based on clock rates.

Host1x driver updates
- Adds API to allow creating mipi device for specific device node.
- Splits MIPI pads calibrate start and waiting for calibration to 
be done.


Device tree updates
- Adds camera connector 2V8, 1V8, 1V2 regulator supplies to 
Jetson TX1 DT.

- Enabled VI and CSI support in Jetson Nano DT.

I'm doing a bit of stress testing with:

while true; do v4l2-ctl --stream-mmap --stream-count=1; done

and I see that the imx274 has often streaming failures:

[  172.025144] IMX274 8-001a: s_stream failed
[  179.025192] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 3132 = 870 (2 bytes)

[  179.033575] IMX274 8-001a: s_stream failed
[  226.525378] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 3130 = 878 (2 bytes)

[  226.533761] IMX274 8-001a: s_stream failed
[  227.029325] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30f6 = 107 (2 bytes)

[  227.037758] IMX274 8-001a: s_stream failed
[  247.025218] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30f6 = 107 (2 bytes)

[  247.033658] IMX274 8-001a: s_stream failed
[  293.025517] IMX274 8-001a: s_stream failed
[  309.024727] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30e0 = 0 (2 bytes)

[  309.032969] IMX274 8-001a: s_stream failed
[  309.529506] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30f8 = 11d2 (3 bytes)

[  309.538103] IMX274 8-001a: imx274_set_frame_length error = -121
[  309.544102] IMX274 8-001a: imx274_set_frame_interval error = -121
[  309.550243] IMX274 8-001a: s_stream failed
[  314.025561] IMX274 8-001a: s_stream failed
[  329.025586] IMX274 8-001a: s_stream failed
[  340.529567] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 303a = f0c (2 bytes)

[  340.538009] IMX274 8-001a: s_stream failed
[  347.525627] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30f6 = 107 (2 bytes)

[  347.534008] IMX274 8-001a: s_stream failed
[  365.033640] IMX274 8-001a: s_stream failed
[  437.525788] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 3038 = c (2 bytes)

[  437.533997] IMX274 8-001a: s_stream failed
[  456.029780] IMX274 8-001a: s_stream failed
[  472.025862] IMX274 8-001a: s_stream failed
[  498.025861] IMX274 8-001a: s_stream failed
[  500.025905] IMX274 8-001a: s_stream failed

where v4l2-ctl returns:

  VIDIOC_STREAMON returned -1 (Remote I/O error)

I don't see this with the imx219.

I also see this occasionally:

[Fri Jul 17 12:51:42 2020] video4linux video1: failed to run 
capture start kthread: -4


Something is not stable here.

Regards,

Hans

Hi Hans,

Running the same single frame continuous loop for more than 2 hours 
now

and I don't see any failure.

Above failure shows i2c bulk writes to IMX274 failure due to which
s_stream also failed.

Not sure if its due to i2c mux in the path to sensor on your module
causing some issue when there is more i2c write traffic as we are 
doing
single stream in continuous loop. Also IMX219 does not show on your 
side

so something specific to IMX274 setup probably.
I'll take a closer look next week. Good to know that it works fine 
for you.




Regarding kthread_run failure where kthread_run() returned -EINTR 
during
capture start thread, I always see this happen at the point of 
stopping

the continuous single stream while loop by pressing ctrl+c after few
loops of execution.
Hmm, if this is normal behavior, then should this message be a debug 
message

only? Or perhaps only show the message if the error code != EINTR.


I believe its good to still show this as its reported by kthread_run 
-> kthread_create_on_node.


But not sure in real usecase we will ever use while true like this 
and we should use script to also break while loop along with v4l2-ctl 
termination when ctrl-c terminate request happens.


Hi Hans, As this happens 

[PATCH 07/13] fs/kernel_read_file: Switch buffer size arg to size_t

[Kees Cook]

In preparation for further refactoring of kernel_read_file*(), rename
the "max_size" argument to the more accurate "buf_size", and correct
its type to size_t. Add kerndoc to explain the specifics of how the
arguments will be used. Note that with buf_size now size_t, it can no
longer be negative (and was never called with a negative value). Adjust
callers to use it as a "maximum size" when *buf is NULL.

Signed-off-by: Kees Cook 
---
 fs/kernel_read_file.c| 34 +++-
 include/linux/kernel_read_file.h |  8 
 security/integrity/digsig.c  |  2 +-
 security/integrity/ima/ima_fs.c  |  2 +-
 4 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index dc28a8def597..e21a76001fff 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -5,15 +5,31 @@
 #include 
 #include 
 
+/**
+ * kernel_read_file() - read file contents into a kernel buffer
+ *
+ * @file   file to read from
+ * @bufpointer to a "void *" buffer for reading into (if
+ * *@buf is NULL, a buffer will be allocated, and
+ * @buf_size will be ignored)
+ * @buf_size   size of buf, if already allocated. If @buf not
+ * allocated, this is the largest size to allocate.
+ * @id the kernel_read_file_id identifying the type of
+ * file contents being read (for LSMs to examine)
+ *
+ * Returns number of bytes read (no single read will be bigger
+ * than INT_MAX), or negative on error.
+ *
+ */
 int kernel_read_file(struct file *file, void **buf,
-loff_t max_size, enum kernel_read_file_id id)
+size_t buf_size, enum kernel_read_file_id id)
 {
loff_t i_size, pos;
ssize_t bytes = 0;
void *allocated = NULL;
int ret;
 
-   if (!S_ISREG(file_inode(file)->i_mode) || max_size < 0)
+   if (!S_ISREG(file_inode(file)->i_mode))
return -EINVAL;
 
ret = deny_write_access(file);
@@ -29,7 +45,7 @@ int kernel_read_file(struct file *file, void **buf,
ret = -EINVAL;
goto out;
}
-   if (i_size > INT_MAX || (max_size > 0 && i_size > max_size)) {
+   if (i_size > INT_MAX || i_size > buf_size) {
ret = -EFBIG;
goto out;
}
@@ -75,7 +91,7 @@ int kernel_read_file(struct file *file, void **buf,
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
 int kernel_read_file_from_path(const char *path, void **buf,
-  loff_t max_size, enum kernel_read_file_id id)
+  size_t buf_size, enum kernel_read_file_id id)
 {
struct file *file;
int ret;
@@ -87,14 +103,14 @@ int kernel_read_file_from_path(const char *path, void 
**buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, max_size, id);
+   ret = kernel_read_file(file, buf, buf_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
 
 int kernel_read_file_from_path_initns(const char *path, void **buf,
- loff_t max_size,
+ size_t buf_size,
  enum kernel_read_file_id id)
 {
struct file *file;
@@ -113,13 +129,13 @@ int kernel_read_file_from_path_initns(const char *path, 
void **buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, max_size, id);
+   ret = kernel_read_file(file, buf, buf_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
 
-int kernel_read_file_from_fd(int fd, void **buf, loff_t max_size,
+int kernel_read_file_from_fd(int fd, void **buf, size_t buf_size,
 enum kernel_read_file_id id)
 {
struct fd f = fdget(fd);
@@ -128,7 +144,7 @@ int kernel_read_file_from_fd(int fd, void **buf, loff_t 
max_size,
if (!f.file)
goto out;
 
-   ret = kernel_read_file(f.file, buf, max_size, id);
+   ret = kernel_read_file(f.file, buf, buf_size, id);
 out:
fdput(f);
return ret;
diff --git a/include/linux/kernel_read_file.h b/include/linux/kernel_read_file.h
index 0ca0bdbed1bd..910039e7593e 100644
--- a/include/linux/kernel_read_file.h
+++ b/include/linux/kernel_read_file.h
@@ -36,16 +36,16 @@ static inline const char *kernel_read_file_id_str(enum 
kernel_read_file_id id)
 }
 
 int kernel_read_file(struct file *file,
-void **buf, loff_t max_size,
+void **buf, size_t buf_size,
 enum kernel_read_file_id id);
 int kernel_read_file_from_path(const char *path,
-  void **buf, loff_t max_size,
+  void **buf, size_t buf_size,
   enum kernel_read_file_id id);
 int 

[PATCH 02/13] fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum

[Kees Cook]

FIRMWARE_PREALLOC_BUFFER is a "how", not a "what", and confuses the LSMs
that are interested in filtering between types of things. The "how"
should be an internal detail made uninteresting to the LSMs.

Fixes: a098ecd2fa7d ("firmware: support loading into a pre-allocated buffer")
Fixes: fd90bc559bfb ("ima: based on policy verify firmware signatures 
(pre-allocated buffer)")
Fixes: 4f0496d8ffa3 ("ima: based on policy warn about loading firmware 
(pre-allocated buffer)")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook 
---
To aid in backporting, this change is made before moving
kernel_read_file() to separate header/source files.
---
 drivers/base/firmware_loader/main.c | 5 ++---
 fs/exec.c   | 7 ---
 include/linux/fs.h  | 2 +-
 kernel/module.c | 2 +-
 security/integrity/digsig.c | 2 +-
 security/integrity/ima/ima_fs.c | 2 +-
 security/integrity/ima/ima_main.c   | 6 ++
 7 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index ca871b13524e..c2f57cedcd6f 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -465,14 +465,12 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
int i, len;
int rc = -ENOENT;
char *path;
-   enum kernel_read_file_id id = READING_FIRMWARE;
size_t msize = INT_MAX;
void *buffer = NULL;
 
/* Already populated data member means we're loading into a buffer */
if (!decompress && fw_priv->data) {
buffer = fw_priv->data;
-   id = READING_FIRMWARE_PREALLOC_BUFFER;
msize = fw_priv->allocated_size;
}
 
@@ -496,7 +494,8 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 
/* load firmware files from the mount namespace of init */
rc = kernel_read_file_from_path_initns(path, ,
-  , msize, id);
+  , msize,
+  READING_FIRMWARE);
if (rc) {
if (rc != -ENOENT)
dev_warn(device, "loading %s failed with error 
%d\n",
diff --git a/fs/exec.c b/fs/exec.c
index e6e8a9a70327..2bf549757ce7 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -927,6 +927,7 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
 {
loff_t i_size, pos;
ssize_t bytes = 0;
+   void *allocated = NULL;
int ret;
 
if (!S_ISREG(file_inode(file)->i_mode) || max_size < 0)
@@ -950,8 +951,8 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
goto out;
}
 
-   if (id != READING_FIRMWARE_PREALLOC_BUFFER)
-   *buf = vmalloc(i_size);
+   if (!*buf)
+   *buf = allocated = vmalloc(i_size);
if (!*buf) {
ret = -ENOMEM;
goto out;
@@ -980,7 +981,7 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
 
 out_free:
if (ret < 0) {
-   if (id != READING_FIRMWARE_PREALLOC_BUFFER) {
+   if (allocated) {
vfree(*buf);
*buf = NULL;
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3f881a892ea7..95fc775ed937 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2993,10 +2993,10 @@ static inline void i_readcount_inc(struct inode *inode)
 #endif
 extern int do_pipe_flags(int *, int);
 
+/* This is a list of *what* is being read, not *how*. */
 #define __kernel_read_file_id(id) \
id(UNKNOWN, unknown)\
id(FIRMWARE, firmware)  \
-   id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
id(FIRMWARE_EFI_EMBEDDED, firmware) \
id(MODULE, kernel-module)   \
id(KEXEC_IMAGE, kexec-image)\
diff --git a/kernel/module.c b/kernel/module.c
index 0c6573b98c36..26105148f4d2 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3988,7 +3988,7 @@ SYSCALL_DEFINE3(finit_module, int, fd, const char __user 
*, uargs, int, flags)
 {
struct load_info info = { };
loff_t size;
-   void *hdr;
+   void *hdr = NULL;
int err;
 
err = may_init_module();
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index e9cbadade74b..ac02b7632353 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -169,7 +169,7 @@ int __init integrity_add_key(const unsigned int id, const 
void *data,
 
 int __init integrity_load_x509(const unsigned int id, const char *path)
 {
-   void *data;
+   void *data = NULL;
loff_t size;
int rc;
key_perm_t perm;
diff --git a/security/integrity/ima/ima_fs.c 

[PATCH 04/13] fs/kernel_read_file: Split into separate include file

[Kees Cook]

From: Scott Branden 

Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h
include file. That header gets pulled in just about everywhere
and doesn't really need functions not related to the general fs interface.

Suggested-by: Christoph Hellwig 
Signed-off-by: Scott Branden 
Reviewed-by: Christoph Hellwig 
Acked-by: Greg Kroah-Hartman 
Link: 
https://lore.kernel.org/r/20200706232309.12010-2-scott.bran...@broadcom.com
Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/main.c |  1 +
 fs/exec.c   |  1 +
 include/linux/fs.h  | 38 -
 include/linux/ima.h |  1 +
 include/linux/kernel_read_file.h| 51 +
 include/linux/security.h|  1 +
 kernel/kexec_file.c |  1 +
 kernel/module.c |  1 +
 security/integrity/digsig.c |  1 +
 security/integrity/ima/ima_fs.c |  1 +
 security/integrity/ima/ima_main.c   |  1 +
 security/integrity/ima/ima_policy.c |  1 +
 security/loadpin/loadpin.c  |  1 +
 security/security.c |  1 +
 security/selinux/hooks.c|  1 +
 15 files changed, 64 insertions(+), 38 deletions(-)
 create mode 100644 include/linux/kernel_read_file.h

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index c2f57cedcd6f..d4a413ea48ce 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/fs/exec.c b/fs/exec.c
index 2bf549757ce7..07a7fe9ac5be 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -23,6 +23,7 @@
  * formats.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index f50a35d54a61..11dd6cc7de58 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2993,44 +2993,6 @@ static inline void i_readcount_inc(struct inode *inode)
 #endif
 extern int do_pipe_flags(int *, int);
 
-/* This is a list of *what* is being read, not *how* nor *where*. */
-#define __kernel_read_file_id(id) \
-   id(UNKNOWN, unknown)\
-   id(FIRMWARE, firmware)  \
-   id(MODULE, kernel-module)   \
-   id(KEXEC_IMAGE, kexec-image)\
-   id(KEXEC_INITRAMFS, kexec-initramfs)\
-   id(POLICY, security-policy) \
-   id(X509_CERTIFICATE, x509-certificate)  \
-   id(MAX_ID, )
-
-#define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
-#define __fid_stringify(dummy, str) #str,
-
-enum kernel_read_file_id {
-   __kernel_read_file_id(__fid_enumify)
-};
-
-static const char * const kernel_read_file_str[] = {
-   __kernel_read_file_id(__fid_stringify)
-};
-
-static inline const char *kernel_read_file_id_str(enum kernel_read_file_id id)
-{
-   if ((unsigned)id >= READING_MAX_ID)
-   return kernel_read_file_str[READING_UNKNOWN];
-
-   return kernel_read_file_str[id];
-}
-
-extern int kernel_read_file(struct file *, void **, loff_t *, loff_t,
-   enum kernel_read_file_id);
-extern int kernel_read_file_from_path(const char *, void **, loff_t *, loff_t,
- enum kernel_read_file_id);
-extern int kernel_read_file_from_path_initns(const char *, void **, loff_t *, 
loff_t,
-enum kernel_read_file_id);
-extern int kernel_read_file_from_fd(int, void **, loff_t *, loff_t,
-   enum kernel_read_file_id);
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
 extern ssize_t kernel_write(struct file *, const void *, size_t, loff_t *);
 extern ssize_t __kernel_write(struct file *, const void *, size_t, loff_t *);
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 9164e1534ec9..148636bfcc8f 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -7,6 +7,7 @@
 #ifndef _LINUX_IMA_H
 #define _LINUX_IMA_H
 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/kernel_read_file.h b/include/linux/kernel_read_file.h
new file mode 100644
index ..78cf3d7dc835
--- /dev/null
+++ b/include/linux/kernel_read_file.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_KERNEL_READ_FILE_H
+#define _LINUX_KERNEL_READ_FILE_H
+
+#include 
+#include 
+
+/* This is a list of *what* is being read, not *how* nor *where*. */
+#define __kernel_read_file_id(id) \
+   id(UNKNOWN, unknown)\
+   id(FIRMWARE, firmware)  \
+   id(MODULE, kernel-module)   \
+   id(KEXEC_IMAGE, kexec-image)\
+   id(KEXEC_INITRAMFS, kexec-initramfs)\
+   id(POLICY, security-policy) \
+   id(X509_CERTIFICATE, x509-certificate)  \
+   id(MAX_ID, )
+
+#define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
+#define __fid_stringify(dummy, str) #str,
+
+enum 

Re: [PATCH v4 4/9] media: staging: dt-bindings: rkisp1: fix "no reg" error in parent node

[Rob Herring]

On Thu, Jul 2, 2020 at 1:13 PM Helen Koike  wrote:
>
> Fix the following error found with make ARCH=arm64 dt_binding_check:
>
> Documentation/devicetree/bindings/media/rockchip-isp1.example.dts:24.27-101.11:
> Warning (unit_address_vs_reg): /example-0/parent@0: node has a unit name, but 
> no reg or ranges property
>
> Reported-by: Johan Jonker 
> Signed-off-by: Helen Koike 
> ---
>
> V3:
> - this is a new patch in the series
> ---
>  .../Documentation/devicetree/bindings/media/rockchip-isp1.yaml   | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git 
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>  
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> index e5b9c0574e352..4d111ef2e89c7 100644
> --- 
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> +++ 
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> @@ -126,6 +126,7 @@ examples:
>  #include 
>
>  parent0: parent@0 {
> +reg = <0 0>;

Just drop the unit-address.

>  #address-cells = <2>;
>  #size-cells = <2>;
>
> --
> 2.26.0
>

[PATCH 01/13] firmware_loader: EFI firmware loader must handle pre-allocated buffer

[Kees Cook]

The EFI platform firmware fallback would clobber any pre-allocated
buffers. Instead, correctly refuse to reallocate when too small (as
already done in the sysfs fallback), or perform allocation normally
when needed.

Fixes: e4c2c0ff00ec ("firmware: Add new platform fallback mechanism and firm 
ware_request_platform()")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook 
---
To aid in backporting, this change is made before moving
kernel_read_file() to separate header/source files.
---
 drivers/base/firmware_loader/fallback_platform.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/base/firmware_loader/fallback_platform.c 
b/drivers/base/firmware_loader/fallback_platform.c
index cdd2c9a9f38a..685edb7dd05a 100644
--- a/drivers/base/firmware_loader/fallback_platform.c
+++ b/drivers/base/firmware_loader/fallback_platform.c
@@ -25,7 +25,10 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
if (rc)
return rc; /* rc == -ENOENT when the fw was not found */
 
-   fw_priv->data = vmalloc(size);
+   if (fw_priv->data && size > fw_priv->allocated_size)
+   return -ENOMEM;
+   if (!fw_priv->data)
+   fw_priv->data = vmalloc(size);
if (!fw_priv->data)
return -ENOMEM;
 
-- 
2.25.1

[PATCH 05/13] fs/kernel_read_file: Split into separate source file

[Kees Cook]

These routines are used in places outside of exec(2), so in preparation
for refactoring them, move them into a separate source file,
fs/kernel_read_file.c.

Signed-off-by: Kees Cook 
---
 fs/Makefile   |   3 +-
 fs/exec.c | 132 
 fs/kernel_read_file.c | 138 ++
 3 files changed, 140 insertions(+), 133 deletions(-)
 create mode 100644 fs/kernel_read_file.c

diff --git a/fs/Makefile b/fs/Makefile
index 2ce5112b02c8..a05fc247b2a7 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -13,7 +13,8 @@ obj-y :=  open.o read_write.o file_table.o super.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o splice.o sync.o utimes.o d_path.o \
stack.o fs_struct.o statfs.o fs_pin.o nsfs.o \
-   fs_types.o fs_context.o fs_parser.o fsopen.o
+   fs_types.o fs_context.o fs_parser.o fsopen.o \
+   kernel_read_file.o
 
 ifeq ($(CONFIG_BLOCK),y)
 obj-y +=   buffer.o block_dev.o direct-io.o mpage.o
diff --git a/fs/exec.c b/fs/exec.c
index 07a7fe9ac5be..d619b79aab30 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -923,138 +923,6 @@ struct file *open_exec(const char *name)
 }
 EXPORT_SYMBOL(open_exec);
 
-int kernel_read_file(struct file *file, void **buf, loff_t *size,
-loff_t max_size, enum kernel_read_file_id id)
-{
-   loff_t i_size, pos;
-   ssize_t bytes = 0;
-   void *allocated = NULL;
-   int ret;
-
-   if (!S_ISREG(file_inode(file)->i_mode) || max_size < 0)
-   return -EINVAL;
-
-   ret = deny_write_access(file);
-   if (ret)
-   return ret;
-
-   ret = security_kernel_read_file(file, id);
-   if (ret)
-   goto out;
-
-   i_size = i_size_read(file_inode(file));
-   if (i_size <= 0) {
-   ret = -EINVAL;
-   goto out;
-   }
-   if (i_size > SIZE_MAX || (max_size > 0 && i_size > max_size)) {
-   ret = -EFBIG;
-   goto out;
-   }
-
-   if (!*buf)
-   *buf = allocated = vmalloc(i_size);
-   if (!*buf) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   pos = 0;
-   while (pos < i_size) {
-   bytes = kernel_read(file, *buf + pos, i_size - pos, );
-   if (bytes < 0) {
-   ret = bytes;
-   goto out_free;
-   }
-
-   if (bytes == 0)
-   break;
-   }
-
-   if (pos != i_size) {
-   ret = -EIO;
-   goto out_free;
-   }
-
-   ret = security_kernel_post_read_file(file, *buf, i_size, id);
-   if (!ret)
-   *size = pos;
-
-out_free:
-   if (ret < 0) {
-   if (allocated) {
-   vfree(*buf);
-   *buf = NULL;
-   }
-   }
-
-out:
-   allow_write_access(file);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(kernel_read_file);
-
-int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
-  loff_t max_size, enum kernel_read_file_id id)
-{
-   struct file *file;
-   int ret;
-
-   if (!path || !*path)
-   return -EINVAL;
-
-   file = filp_open(path, O_RDONLY, 0);
-   if (IS_ERR(file))
-   return PTR_ERR(file);
-
-   ret = kernel_read_file(file, buf, size, max_size, id);
-   fput(file);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
-
-int kernel_read_file_from_path_initns(const char *path, void **buf,
- loff_t *size, loff_t max_size,
- enum kernel_read_file_id id)
-{
-   struct file *file;
-   struct path root;
-   int ret;
-
-   if (!path || !*path)
-   return -EINVAL;
-
-   task_lock(_task);
-   get_fs_root(init_task.fs, );
-   task_unlock(_task);
-
-   file = file_open_root(root.dentry, root.mnt, path, O_RDONLY, 0);
-   path_put();
-   if (IS_ERR(file))
-   return PTR_ERR(file);
-
-   ret = kernel_read_file(file, buf, size, max_size, id);
-   fput(file);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
-
-int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
-enum kernel_read_file_id id)
-{
-   struct fd f = fdget(fd);
-   int ret = -EBADF;
-
-   if (!f.file)
-   goto out;
-
-   ret = kernel_read_file(f.file, buf, size, max_size, id);
-out:
-   fdput(f);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_fd);
-
 #if defined(CONFIG_HAVE_AOUT) || defined(CONFIG_BINFMT_FLAT) || \
 defined(CONFIG_BINFMT_ELF_FDPIC)
 ssize_t read_code(struct file *file, unsigned long addr, loff_t pos, size_t 
len)
diff --git a/fs/kernel_read_file.c 

[PATCH 11/13] module: Call security_kernel_post_load_data()

[Kees Cook]

Now that there is an API for checking loaded contents for modules
loaded without a file, call into the LSM hooks.

Cc: Jessica Yu 
Signed-off-by: Kees Cook 
---
 kernel/module.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index d56cb34d9a2f..90a4788dff9d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2967,7 +2967,7 @@ static int copy_module_from_user(const void __user *umod, 
unsigned long len,
if (info->len < sizeof(*(info->hdr)))
return -ENOEXEC;
 
-   err = security_kernel_load_data(LOADING_MODULE, false);
+   err = security_kernel_load_data(LOADING_MODULE, true);
if (err)
return err;
 
@@ -2977,11 +2977,17 @@ static int copy_module_from_user(const void __user 
*umod, unsigned long len,
return -ENOMEM;
 
if (copy_chunked_from_user(info->hdr, umod, info->len) != 0) {
-   vfree(info->hdr);
-   return -EFAULT;
+   err = -EFAULT;
+   goto out;
}
 
-   return 0;
+   err = security_kernel_post_load_data((char *)info->hdr, info->len,
+LOADING_MODULE);
+out:
+   if (err)
+   vfree(info->hdr);
+
+   return err;
 }
 
 static void free_copy(struct load_info *info)
-- 
2.25.1

[PATCH 06/13] fs/kernel_read_file: Remove redundant size argument

[Kees Cook]

In preparation for refactoring kernel_read_file*(), remove the redundant
"size" argument which is not needed: it can be included in the return
code, with callers adjusted. (VFS reads already cannot be larger than
INT_MAX.)

Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/main.c |  8 
 fs/kernel_read_file.c   | 20 +---
 include/linux/kernel_read_file.h|  8 
 kernel/kexec_file.c | 13 ++---
 kernel/module.c |  7 +++
 security/integrity/digsig.c |  5 +++--
 security/integrity/ima/ima_fs.c |  5 +++--
 7 files changed, 32 insertions(+), 34 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index d4a413ea48ce..ea419c7d3d34 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -462,7 +462,7 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 size_t in_size,
 const void *in_buffer))
 {
-   loff_t size;
+   size_t size;
int i, len;
int rc = -ENOENT;
char *path;
@@ -494,10 +494,9 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
fw_priv->size = 0;
 
/* load firmware files from the mount namespace of init */
-   rc = kernel_read_file_from_path_initns(path, ,
-  , msize,
+   rc = kernel_read_file_from_path_initns(path, , msize,
   READING_FIRMWARE);
-   if (rc) {
+   if (rc < 0) {
if (rc != -ENOENT)
dev_warn(device, "loading %s failed with error 
%d\n",
 path, rc);
@@ -506,6 +505,7 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 path);
continue;
}
+   size = rc;
dev_dbg(device, "Loading firmware from %s\n", path);
if (decompress) {
dev_dbg(device, "f/w decompressing %s\n",
diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index 54d972d4befc..dc28a8def597 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-int kernel_read_file(struct file *file, void **buf, loff_t *size,
+int kernel_read_file(struct file *file, void **buf,
 loff_t max_size, enum kernel_read_file_id id)
 {
loff_t i_size, pos;
@@ -29,7 +29,7 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
ret = -EINVAL;
goto out;
}
-   if (i_size > SIZE_MAX || (max_size > 0 && i_size > max_size)) {
+   if (i_size > INT_MAX || (max_size > 0 && i_size > max_size)) {
ret = -EFBIG;
goto out;
}
@@ -59,8 +59,6 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
}
 
ret = security_kernel_post_read_file(file, *buf, i_size, id);
-   if (!ret)
-   *size = pos;
 
 out_free:
if (ret < 0) {
@@ -72,11 +70,11 @@ int kernel_read_file(struct file *file, void **buf, loff_t 
*size,
 
 out:
allow_write_access(file);
-   return ret;
+   return ret == 0 ? pos : ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
-int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
+int kernel_read_file_from_path(const char *path, void **buf,
   loff_t max_size, enum kernel_read_file_id id)
 {
struct file *file;
@@ -89,14 +87,14 @@ int kernel_read_file_from_path(const char *path, void 
**buf, loff_t *size,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, size, max_size, id);
+   ret = kernel_read_file(file, buf, max_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
 
 int kernel_read_file_from_path_initns(const char *path, void **buf,
- loff_t *size, loff_t max_size,
+ loff_t max_size,
  enum kernel_read_file_id id)
 {
struct file *file;
@@ -115,13 +113,13 @@ int kernel_read_file_from_path_initns(const char *path, 
void **buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, size, max_size, id);
+   ret = kernel_read_file(file, buf, max_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
 
-int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
+int kernel_read_file_from_fd(int fd, void 

Re: [PATCH v4 3/9] media: staging: dt-bindings: rkisp1: re-order properties

[Rob Herring]

On Thu, Jul 2, 2020 at 1:13 PM Helen Koike  wrote:
>
> Organize properties order in dt-binbings to move it out of staging.

typo

>
> On top: compatible, reg and interrupts.
> Then alphabetical order, then properties starting with '#'.
>
> Signed-off-by: Helen Koike 
>
> ---
>
> V2:
> - this is a new patch in the series
> ---
>  .../bindings/media/rockchip-isp1.yaml | 32 +--
>  1 file changed, 16 insertions(+), 16 deletions(-)

Acked-by: Rob Herring 

[PATCH 13/13] fs/kernel_file_read: Add "offset" arg for partial reads

[Kees Cook]

To perform partial reads, callers of kernel_read_file*() must have a
non-NULL file_size argument and a preallocated buffer. The new "offset"
argument can then be used to seek to specific locations in the file to
fill the buffer to, at most, "buf_size" per call.

Where possible, the LSM hooks can report whether a full file has been
read or not so that the contents can be reasoned about.

Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/main.c |  2 +-
 fs/kernel_read_file.c   | 78 -
 include/linux/kernel_read_file.h|  8 +--
 kernel/kexec_file.c |  4 +-
 kernel/module.c |  2 +-
 security/integrity/digsig.c |  2 +-
 security/integrity/ima/ima_fs.c |  3 +-
 7 files changed, 65 insertions(+), 34 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 3439a533927c..fa540ca51961 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -494,7 +494,7 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
fw_priv->size = 0;
 
/* load firmware files from the mount namespace of init */
-   rc = kernel_read_file_from_path_initns(path, , msize,
+   rc = kernel_read_file_from_path_initns(path, 0, , msize,
   NULL,
   READING_FIRMWARE);
if (rc < 0) {
diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index d73bc3fa710a..90d255fbdd9b 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -9,6 +9,7 @@
  * kernel_read_file() - read file contents into a kernel buffer
  *
  * @file   file to read from
+ * @offset where to start reading from (see below).
  * @bufpointer to a "void *" buffer for reading into (if
  * *@buf is NULL, a buffer will be allocated, and
  * @buf_size will be ignored)
@@ -19,19 +20,31 @@
  * @id the kernel_read_file_id identifying the type of
  * file contents being read (for LSMs to examine)
  *
+ * @offset must be 0 unless both @buf and @file_size are non-NULL
+ * (i.e. the caller must be expecting to read partial file contents
+ * via an already-allocated @buf, in at most @buf_size chunks, and
+ * will be able to determine when the entire file was read by
+ * checking @file_size). This isn't a recommended way to read a
+ * file, though, since it is possible that the contents might
+ * change between calls to kernel_read_file().
+ *
  * Returns number of bytes read (no single read will be bigger
  * than INT_MAX), or negative on error.
  *
  */
-int kernel_read_file(struct file *file, void **buf,
+int kernel_read_file(struct file *file, loff_t offset, void **buf,
 size_t buf_size, size_t *file_size,
 enum kernel_read_file_id id)
 {
loff_t i_size, pos;
-   ssize_t bytes = 0;
+   size_t copied;
void *allocated = NULL;
+   bool whole_file;
int ret;
 
+   if (offset != 0 && (!*buf || !file_size))
+   return -EINVAL;
+
if (!S_ISREG(file_inode(file)->i_mode))
return -EINVAL;
 
@@ -39,19 +52,27 @@ int kernel_read_file(struct file *file, void **buf,
if (ret)
return ret;
 
-   ret = security_kernel_read_file(file, id, true);
-   if (ret)
-   goto out;
-
i_size = i_size_read(file_inode(file));
if (i_size <= 0) {
ret = -EINVAL;
goto out;
}
-   if (i_size > INT_MAX || i_size > buf_size) {
+   /* The file is too big for sane activities. */
+   if (i_size > INT_MAX) {
+   ret = -EFBIG;
+   goto out;
+   }
+   /* The entire file cannot be read in one buffer. */
+   if (!file_size && offset == 0 && i_size > buf_size) {
ret = -EFBIG;
goto out;
}
+
+   whole_file = (offset == 0 && i_size <= buf_size);
+   ret = security_kernel_read_file(file, id, whole_file);
+   if (ret)
+   goto out;
+
if (file_size)
*file_size = i_size;
 
@@ -62,9 +83,14 @@ int kernel_read_file(struct file *file, void **buf,
goto out;
}
 
-   pos = 0;
-   while (pos < i_size) {
-   bytes = kernel_read(file, *buf + pos, i_size - pos, );
+   pos = offset;
+   copied = 0;
+   while (copied < buf_size) {
+   ssize_t bytes;
+   size_t wanted = min_t(size_t, buf_size - copied,
+ i_size - pos);
+
+   bytes = kernel_read(file, *buf + copied, wanted, );
if (bytes < 0) {
ret = bytes;
goto out_free;
@@ -72,14 +98,17 @@ int kernel_read_file(struct 

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

[Alan Stern]

On Fri, Jul 17, 2020 at 12:22:49PM -0400, Mathieu Desnoyers wrote:
> - On Jul 17, 2020, at 12:11 PM, Alan Stern st...@rowland.harvard.edu 
> wrote:
> 
> >> > I agree with Nick: A memory barrier is needed somewhere between the
> >> > assignment at 6 and the return to user mode at 8.  Otherwise you end up
> >> > with the Store Buffer pattern having a memory barrier on only one side,
> >> > and it is well known that this arrangement does not guarantee any
> >> > ordering.
> >> 
> >> Yes, I see this now. I'm still trying to wrap my head around why the memory
> >> barrier at the end of membarrier() needs to be paired with a scheduler
> >> barrier though.
> > 
> > The memory barrier at the end of membarrier() on CPU0 is necessary in
> > order to enforce the guarantee that any writes occurring on CPU1 before
> > the membarrier() is executed will be visible to any code executing on
> > CPU0 after the membarrier().  Ignoring the kthread issue, we can have:
> > 
> > CPU0CPU1
> > x = 1
> > barrier()
> > y = 1
> > r2 = y
> > membarrier():
> >   a: smp_mb()
> >   b: send IPI   IPI-induced mb
> >   c: smp_mb()
> > r1 = x
> > 
> > The writes to x and y are unordered by the hardware, so it's possible to
> > have r2 = 1 even though the write to x doesn't execute until b.  If the
> > memory barrier at c is omitted then "r1 = x" can be reordered before b
> > (although not before a), so we get r1 = 0.  This violates the guarantee
> > that membarrier() is supposed to provide.
> > 
> > The timing of the memory barrier at c has to ensure that it executes
> > after the IPI-induced memory barrier on CPU1.  If it happened before
> > then we could still end up with r1 = 0.  That's why the pairing matters.
> > 
> > I hope this helps your head get properly wrapped.  :-)
> 
> It does help a bit! ;-)
> 
> This explains this part of the comment near the smp_mb at the end of 
> membarrier:
> 
>  * Memory barrier on the caller thread _after_ we finished
>  * waiting for the last IPI. [...]
> 
> However, it does not explain why it needs to be paired with a barrier in the
> scheduler, clearly for the case where the IPI is skipped. I wonder whether 
> this part
> of the comment is factually correct:
> 
>  * [...] Matches memory barriers around rq->curr modification in 
> scheduler.

The reasoning is pretty much the same as above:

CPU0CPU1
x = 1
barrier()
y = 1
r2 = y
membarrier():
  a: smp_mb()
switch to kthread (includes mb)
  b: read rq->curr == kthread
switch to user (includes mb)
  c: smp_mb()
r1 = x

Once again, it is possible that x = 1 doesn't become visible to CPU0 
until shortly before b.  But if c is omitted then "r1 = x" can be 
reordered before b (to any time after a), so we can have r1 = 0.

Here the timing requirement is that c executes after the first memory 
barrier on CPU1 -- which is one of the ones around the rq->curr 
modification.  (In fact, in this scenario CPU1's switch back to the user 
process is irrelevant.)

Alan Stern

[PATCH 10/13] firmware_loader: Use security_post_load_data()

[Kees Cook]

Now that security_post_load_data() is wired up, use it instead
of the NULL file argument style of security_post_read_file(),
and update the security_kernel_load_data() call to indicate that a
security_kernel_post_load_data() call is expected.

Wire up the IMA check to match earlier logic. Perhaps a generalized
change to ima_post_load_data() might look something like this:

return process_buffer_measurement(buf, size,
  kernel_load_data_id_str(load_id),
  read_idmap[load_id] ?: FILE_CHECK,
  0, NULL);

Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/fallback.c   |  8 
 .../base/firmware_loader/fallback_platform.c  |  7 ++-
 security/integrity/ima/ima_main.c | 20 +--
 3 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index a196aacce22c..7cfdfdcb819c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -272,9 +272,9 @@ static ssize_t firmware_loading_store(struct device *dev,
dev_err(dev, "%s: map pages failed\n",
__func__);
else
-   rc = security_kernel_post_read_file(NULL,
-   fw_priv->data, fw_priv->size,
-   READING_FIRMWARE);
+   rc = 
security_kernel_post_load_data(fw_priv->data,
+   fw_priv->size,
+   LOADING_FIRMWARE);
 
/*
 * Same logic as fw_load_abort, only the DONE bit
@@ -613,7 +613,7 @@ static bool fw_run_sysfs_fallback(u32 opt_flags)
return false;
 
/* Also permit LSMs and IMA to fail firmware sysfs fallback */
-   ret = security_kernel_load_data(LOADING_FIRMWARE, false);
+   ret = security_kernel_load_data(LOADING_FIRMWARE, true);
if (ret < 0)
return false;
 
diff --git a/drivers/base/firmware_loader/fallback_platform.c 
b/drivers/base/firmware_loader/fallback_platform.c
index a12c79d47efc..4d1157af0e86 100644
--- a/drivers/base/firmware_loader/fallback_platform.c
+++ b/drivers/base/firmware_loader/fallback_platform.c
@@ -17,7 +17,7 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
if (!(opt_flags & FW_OPT_FALLBACK_PLATFORM))
return -ENOENT;
 
-   rc = security_kernel_load_data(LOADING_FIRMWARE, false);
+   rc = security_kernel_load_data(LOADING_FIRMWARE, true);
if (rc)
return rc;
 
@@ -27,6 +27,11 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
 
if (fw_priv->data && size > fw_priv->allocated_size)
return -ENOMEM;
+
+   rc = security_kernel_post_load_data((u8 *)data, size, LOADING_FIRMWARE);
+   if (rc)
+   return rc;
+
if (!fw_priv->data)
fw_priv->data = vmalloc(size);
if (!fw_priv->data)
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index 85000dc8595c..1a7bc4c7437d 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -648,15 +648,6 @@ int ima_post_read_file(struct file *file, void *buf, 
loff_t size,
enum ima_hooks func;
u32 secid;
 
-   if (!file && read_id == READING_FIRMWARE) {
-   if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
-   (ima_appraise & IMA_APPRAISE_ENFORCE)) {
-   pr_err("Prevent firmware loading_store.\n");
-   return -EACCES; /* INTEGRITY_UNKNOWN */
-   }
-   return 0;
-   }
-
/* permit signed certs */
if (!file && read_id == READING_X509_CERTIFICATE)
return 0;
@@ -706,7 +697,7 @@ int ima_load_data(enum kernel_load_data_id id, bool 
contents)
}
break;
case LOADING_FIRMWARE:
-   if (ima_enforce && (ima_appraise & IMA_APPRAISE_FIRMWARE)) {
+   if (ima_enforce && (ima_appraise & IMA_APPRAISE_FIRMWARE) && 
!contents) {
pr_err("Prevent firmware sysfs fallback loading.\n");
return -EACCES; /* INTEGRITY_UNKNOWN */
}
@@ -739,6 +730,15 @@ int ima_load_data(enum kernel_load_data_id id, bool 
contents)
  */
 int ima_post_load_data(char *buf, loff_t size, enum kernel_load_data_id 
load_id)
 {
+   if (load_id == LOADING_FIRMWARE) {
+   if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
+   (ima_appraise & IMA_APPRAISE_ENFORCE)) {
+   pr_err("Prevent firmware loading_store.\n");
+ 

[PATCH 00/13] Introduce partial kernel_read_file() support

[Kees Cook]

Hi,

Here's my attempt at clearing the path to partial read support in
kernel_read_file(), which fixes a number of issues along the way. I'm
still fighting with the firmware test suite (it doesn't seem to pass
for me even in stock v5.7... ?) But I don't want to block Scott's work[1]
any this week, so here's the series as it is currently.

The primary difference to Scott's approach is to avoid adding a new set of
functions and just adapt the existing APIs to deal with "offset". Also,
the fixes for the enum are first in the series so they can be backported
without the header file relocation.

I'll keep poking at the firmware tests...

-Kees

[1] https://lore.kernel.org/lkml/202007161415.10D015477@keescook/

Kees Cook (12):
  firmware_loader: EFI firmware loader must handle pre-allocated buffer
  fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum
  fs/kernel_read_file: Remove FIRMWARE_EFI_EMBEDDED enum
  fs/kernel_read_file: Split into separate source file
  fs/kernel_read_file: Remove redundant size argument
  fs/kernel_read_file: Switch buffer size arg to size_t
  fs/kernel_read_file: Add file_size output argument
  LSM: Introduce kernel_post_load_data() hook
  firmware_loader: Use security_post_load_data()
  module: Call security_kernel_post_load_data()
  LSM: Add "contents" flag to kernel_read_file hook
  fs/kernel_file_read: Add "offset" arg for partial reads

Scott Branden (1):
  fs/kernel_read_file: Split into separate include file

 drivers/base/firmware_loader/fallback.c   |   8 +-
 .../base/firmware_loader/fallback_platform.c  |  12 +-
 drivers/base/firmware_loader/main.c   |  13 +-
 fs/Makefile   |   3 +-
 fs/exec.c | 132 +---
 fs/kernel_read_file.c | 189 ++
 include/linux/fs.h|  39 
 include/linux/ima.h   |  19 +-
 include/linux/kernel_read_file.h  |  55 +
 include/linux/lsm_hook_defs.h |   6 +-
 include/linux/lsm_hooks.h |  12 ++
 include/linux/security.h  |  19 +-
 kernel/kexec.c|   2 +-
 kernel/kexec_file.c   |  18 +-
 kernel/module.c   |  24 ++-
 security/integrity/digsig.c   |   8 +-
 security/integrity/ima/ima_fs.c   |   9 +-
 security/integrity/ima/ima_main.c |  58 --
 security/integrity/ima/ima_policy.c   |   1 +
 security/loadpin/loadpin.c|  17 +-
 security/security.c   |  26 ++-
 security/selinux/hooks.c  |   8 +-
 22 files changed, 432 insertions(+), 246 deletions(-)
 create mode 100644 fs/kernel_read_file.c
 create mode 100644 include/linux/kernel_read_file.h

-- 
2.25.1

[PATCH 08/13] fs/kernel_read_file: Add file_size output argument

[Kees Cook]

In preparation for adding partial read support, add an optional output
argument to kernel_read_file*() that reports the file size so callers
can reason more easily about their reading progress.

Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/main.c |  1 +
 fs/kernel_read_file.c   | 19 +--
 include/linux/kernel_read_file.h|  4 
 kernel/kexec_file.c |  4 ++--
 kernel/module.c |  2 +-
 security/integrity/digsig.c |  2 +-
 security/integrity/ima/ima_fs.c |  2 +-
 7 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index ea419c7d3d34..3439a533927c 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -495,6 +495,7 @@ fw_get_filesystem_firmware(struct device *device, struct 
fw_priv *fw_priv,
 
/* load firmware files from the mount namespace of init */
rc = kernel_read_file_from_path_initns(path, , msize,
+  NULL,
   READING_FIRMWARE);
if (rc < 0) {
if (rc != -ENOENT)
diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index e21a76001fff..2e29c38eb4df 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -14,6 +14,8 @@
  * @buf_size will be ignored)
  * @buf_size   size of buf, if already allocated. If @buf not
  * allocated, this is the largest size to allocate.
+ * @file_size  if non-NULL, the full size of @file will be
+ * written here.
  * @id the kernel_read_file_id identifying the type of
  * file contents being read (for LSMs to examine)
  *
@@ -22,7 +24,8 @@
  *
  */
 int kernel_read_file(struct file *file, void **buf,
-size_t buf_size, enum kernel_read_file_id id)
+size_t buf_size, size_t *file_size,
+enum kernel_read_file_id id)
 {
loff_t i_size, pos;
ssize_t bytes = 0;
@@ -49,6 +52,8 @@ int kernel_read_file(struct file *file, void **buf,
ret = -EFBIG;
goto out;
}
+   if (file_size)
+   *file_size = i_size;
 
if (!*buf)
*buf = allocated = vmalloc(i_size);
@@ -91,7 +96,8 @@ int kernel_read_file(struct file *file, void **buf,
 EXPORT_SYMBOL_GPL(kernel_read_file);
 
 int kernel_read_file_from_path(const char *path, void **buf,
-  size_t buf_size, enum kernel_read_file_id id)
+  size_t buf_size, size_t *file_size,
+  enum kernel_read_file_id id)
 {
struct file *file;
int ret;
@@ -103,14 +109,14 @@ int kernel_read_file_from_path(const char *path, void 
**buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, buf_size, id);
+   ret = kernel_read_file(file, buf, buf_size, file_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
 
 int kernel_read_file_from_path_initns(const char *path, void **buf,
- size_t buf_size,
+ size_t buf_size, size_t *file_size,
  enum kernel_read_file_id id)
 {
struct file *file;
@@ -129,13 +135,14 @@ int kernel_read_file_from_path_initns(const char *path, 
void **buf,
if (IS_ERR(file))
return PTR_ERR(file);
 
-   ret = kernel_read_file(file, buf, buf_size, id);
+   ret = kernel_read_file(file, buf, buf_size, file_size, id);
fput(file);
return ret;
 }
 EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
 
 int kernel_read_file_from_fd(int fd, void **buf, size_t buf_size,
+size_t *file_size,
 enum kernel_read_file_id id)
 {
struct fd f = fdget(fd);
@@ -144,7 +151,7 @@ int kernel_read_file_from_fd(int fd, void **buf, size_t 
buf_size,
if (!f.file)
goto out;
 
-   ret = kernel_read_file(f.file, buf, buf_size, id);
+   ret = kernel_read_file(f.file, buf, buf_size, file_size, id);
 out:
fdput(f);
return ret;
diff --git a/include/linux/kernel_read_file.h b/include/linux/kernel_read_file.h
index 910039e7593e..023293eaf948 100644
--- a/include/linux/kernel_read_file.h
+++ b/include/linux/kernel_read_file.h
@@ -37,15 +37,19 @@ static inline const char *kernel_read_file_id_str(enum 
kernel_read_file_id id)
 
 int kernel_read_file(struct file *file,
 void **buf, size_t buf_size,
+size_t *file_size,
 enum kernel_read_file_id id);
 int kernel_read_file_from_path(const char *path,
   void **buf, size_t 

[PATCH 09/13] LSM: Introduce kernel_post_load_data() hook

[Kees Cook]

There are a few places in the kernel where LSMs would like to have
visibility into the contents of a kernel buffer that has been loaded or
read. While security_kernel_post_read_file() (which includes the
buffer) exists as a pairing for security_kernel_read_file(), no such
hook exists to pair with security_kernel_load_data().

Earlier proposals for just using security_kernel_post_read_file() with a
NULL file argument were rejected (i.e. "file" should always be valid for
the security_..._file hooks, but it appears at least one case was
left in the kernel during earlier refactoring. (This will be fixed in
a subsequent patch.)

Since not all cases of security_kernel_load_data() can have a single
contiguous buffer made available to the LSM hook (e.g. kexec image
segments are separately loaded), there needs to be a way for the LSM to
reason about its expectations of the hook coverage. In order to handle
this, add a "contents" argument to the "kernel_load_data" hook that
indicates if the newly added "kernel_post_load_data" hook will be called
with the full contents once loaded. That way, LSMs requiring full contents
can choose to unilaterally reject "kernel_load_data" with contents=false
(which is effectively the existing hook coverage), but when contents=true
they can allow it and later evaluate the "kernel_post_load_data" hook
once the buffer is loaded.

With this change, LSMs can gain coverage over non-file-backed data loads
(e.g. init_module(2) and firmware userspace helper), which will happen
in subsequent patches.

Additionally prepare IMA to start processing these cases.

Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/fallback.c   |  2 +-
 .../base/firmware_loader/fallback_platform.c  |  2 +-
 include/linux/ima.h   | 12 +--
 include/linux/lsm_hook_defs.h |  4 +++-
 include/linux/lsm_hooks.h |  9 
 include/linux/security.h  | 12 +--
 kernel/kexec.c|  2 +-
 kernel/module.c   |  2 +-
 security/integrity/ima/ima_main.c | 21 ++-
 security/loadpin/loadpin.c|  2 +-
 security/security.c   | 18 +---
 security/selinux/hooks.c  |  2 +-
 12 files changed, 73 insertions(+), 15 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index 5327bfc6ba71..a196aacce22c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -613,7 +613,7 @@ static bool fw_run_sysfs_fallback(u32 opt_flags)
return false;
 
/* Also permit LSMs and IMA to fail firmware sysfs fallback */
-   ret = security_kernel_load_data(LOADING_FIRMWARE);
+   ret = security_kernel_load_data(LOADING_FIRMWARE, false);
if (ret < 0)
return false;
 
diff --git a/drivers/base/firmware_loader/fallback_platform.c 
b/drivers/base/firmware_loader/fallback_platform.c
index 6958ab1a8059..a12c79d47efc 100644
--- a/drivers/base/firmware_loader/fallback_platform.c
+++ b/drivers/base/firmware_loader/fallback_platform.c
@@ -17,7 +17,7 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
if (!(opt_flags & FW_OPT_FALLBACK_PLATFORM))
return -ENOENT;
 
-   rc = security_kernel_load_data(LOADING_FIRMWARE);
+   rc = security_kernel_load_data(LOADING_FIRMWARE, false);
if (rc)
return rc;
 
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 148636bfcc8f..502e36ad7804 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -20,7 +20,9 @@ extern void ima_post_create_tmpfile(struct inode *inode);
 extern void ima_file_free(struct file *file);
 extern int ima_file_mmap(struct file *file, unsigned long prot);
 extern int ima_file_mprotect(struct vm_area_struct *vma, unsigned long prot);
-extern int ima_load_data(enum kernel_load_data_id id);
+extern int ima_load_data(enum kernel_load_data_id id, bool contents);
+extern int ima_post_load_data(char *buf, loff_t size,
+ enum kernel_load_data_id id);
 extern int ima_read_file(struct file *file, enum kernel_read_file_id id);
 extern int ima_post_read_file(struct file *file, void *buf, loff_t size,
  enum kernel_read_file_id id);
@@ -78,7 +80,13 @@ static inline int ima_file_mprotect(struct vm_area_struct 
*vma,
return 0;
 }
 
-static inline int ima_load_data(enum kernel_load_data_id id)
+static inline int ima_load_data(enum kernel_load_data_id id, bool contents)
+{
+   return 0;
+}
+
+static inline int ima_post_load_data(char *buf, loff_t size,
+enum kernel_load_data_id id)
 {
return 0;
 }
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 6791813cd439..aaa2916bbae7 100644
--- 

[PATCH 12/13] LSM: Add "contents" flag to kernel_read_file hook

[Kees Cook]

As with the kernel_load_data LSM hook, add a "contents" flag to the
kernel_read_file LSM hook that indicates whether the LSM can expect
a matching call to the kernel_post_read_file LSM hook with the full
contents of the file. With the coming addition of partial file read
support for kernel_read_file*() API, the LSM will no longer be able
to always see the entire contents of a file during the read calls.

For cases where the LSM must read examine the complete file contents,
it will need to do so on its own every time the kernel_read_file
hook is called with contents=false (or reject such cases). Adjust all
existing LSMs to retain existing behavior.

Signed-off-by: Kees Cook 
---
 fs/kernel_read_file.c |  2 +-
 include/linux/ima.h   |  6 --
 include/linux/lsm_hook_defs.h |  2 +-
 include/linux/lsm_hooks.h |  3 +++
 include/linux/security.h  |  6 --
 security/integrity/ima/ima_main.c | 10 +-
 security/loadpin/loadpin.c| 14 --
 security/security.c   |  7 ---
 security/selinux/hooks.c  |  5 +++--
 9 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index 2e29c38eb4df..d73bc3fa710a 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -39,7 +39,7 @@ int kernel_read_file(struct file *file, void **buf,
if (ret)
return ret;
 
-   ret = security_kernel_read_file(file, id);
+   ret = security_kernel_read_file(file, id, true);
if (ret)
goto out;
 
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 502e36ad7804..259023039dc9 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -23,7 +23,8 @@ extern int ima_file_mprotect(struct vm_area_struct *vma, 
unsigned long prot);
 extern int ima_load_data(enum kernel_load_data_id id, bool contents);
 extern int ima_post_load_data(char *buf, loff_t size,
  enum kernel_load_data_id id);
-extern int ima_read_file(struct file *file, enum kernel_read_file_id id);
+extern int ima_read_file(struct file *file, enum kernel_read_file_id id,
+bool contents);
 extern int ima_post_read_file(struct file *file, void *buf, loff_t size,
  enum kernel_read_file_id id);
 extern void ima_post_path_mknod(struct dentry *dentry);
@@ -91,7 +92,8 @@ static inline int ima_post_load_data(char *buf, loff_t size,
return 0;
 }
 
-static inline int ima_read_file(struct file *file, enum kernel_read_file_id id)
+static inline int ima_read_file(struct file *file, enum kernel_read_file_id id,
+   bool contents)
 {
return 0;
 }
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index aaa2916bbae7..c2ded57c5d9b 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -188,7 +188,7 @@ LSM_HOOK(int, 0, kernel_load_data, enum kernel_load_data_id 
id, bool contents)
 LSM_HOOK(int, 0, kernel_post_load_data, char *buf, loff_t size,
 enum kernel_read_file_id id)
 LSM_HOOK(int, 0, kernel_read_file, struct file *file,
-enum kernel_read_file_id id)
+enum kernel_read_file_id id, bool contents)
 LSM_HOOK(int, 0, kernel_post_read_file, struct file *file, char *buf,
 loff_t size, enum kernel_read_file_id id)
 LSM_HOOK(int, 0, task_fix_setuid, struct cred *new, const struct cred *old,
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 812d626195fc..b66433b5aa15 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -650,6 +650,7 @@
  * @file contains the file structure pointing to the file being read
  * by the kernel.
  * @id kernel read file identifier
+ * @contents if a subsequent @kernel_post_read_file will be called.
  * Return 0 if permission is granted.
  * @kernel_post_read_file:
  * Read a file specified by userspace.
@@ -658,6 +659,8 @@
  * @buf pointer to buffer containing the file contents.
  * @size length of the file contents.
  * @id kernel read file identifier
+ * This must be paired with a prior @kernel_read_file call that had
+ * @contents set to true.
  * Return 0 if permission is granted.
  * @task_fix_setuid:
  * Update the module's state after setting one or more of the user
diff --git a/include/linux/security.h b/include/linux/security.h
index e748974c707b..a5d66b89cd6c 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -390,7 +390,8 @@ int security_kernel_module_request(char *kmod_name);
 int security_kernel_load_data(enum kernel_load_data_id id, bool contents);
 int security_kernel_post_load_data(char *buf, loff_t size,
   enum kernel_load_data_id id);
-int security_kernel_read_file(struct file *file, enum kernel_read_file_id id);
+int security_kernel_read_file(struct file *file, enum kernel_read_file_id id,
+   

[PATCH 03/13] fs/kernel_read_file: Remove FIRMWARE_EFI_EMBEDDED enum

[Kees Cook]

The "FIRMWARE_EFI_EMBEDDED" enum is a "where", not a "what". It
should not be distinguished separately from just "FIRMWARE", as this
confuses the LSMs about what is being loaded. Additionally, there was
no actual validation of the firmware contents happening.

Fixes: e4c2c0ff00ec ("firmware: Add new platform fallback mechanism and 
firmware_request_platform()")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook 
---
To aid in backporting, this change is made before moving
kernel_read_file() to separate header/source files.
---
 drivers/base/firmware_loader/fallback_platform.c | 2 +-
 include/linux/fs.h   | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback_platform.c 
b/drivers/base/firmware_loader/fallback_platform.c
index 685edb7dd05a..6958ab1a8059 100644
--- a/drivers/base/firmware_loader/fallback_platform.c
+++ b/drivers/base/firmware_loader/fallback_platform.c
@@ -17,7 +17,7 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
if (!(opt_flags & FW_OPT_FALLBACK_PLATFORM))
return -ENOENT;
 
-   rc = security_kernel_load_data(LOADING_FIRMWARE_EFI_EMBEDDED);
+   rc = security_kernel_load_data(LOADING_FIRMWARE);
if (rc)
return rc;
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 95fc775ed937..f50a35d54a61 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2993,11 +2993,10 @@ static inline void i_readcount_inc(struct inode *inode)
 #endif
 extern int do_pipe_flags(int *, int);
 
-/* This is a list of *what* is being read, not *how*. */
+/* This is a list of *what* is being read, not *how* nor *where*. */
 #define __kernel_read_file_id(id) \
id(UNKNOWN, unknown)\
id(FIRMWARE, firmware)  \
-   id(FIRMWARE_EFI_EMBEDDED, firmware) \
id(MODULE, kernel-module)   \
id(KEXEC_IMAGE, kexec-image)\
id(KEXEC_INITRAMFS, kexec-initramfs)\
-- 
2.25.1

Re: [PATCH v4 1/9] media: staging: dt-bindings: rkisp1: add missing required nodes

[Rob Herring]

On Thu, Jul 2, 2020 at 1:13 PM Helen Koike  wrote:
>
> Add missing required nodes in json-schema yaml file for
> Rockchip ISP1 dt-bindings.
>
> Signed-off-by: Helen Koike 
> ---
>
> Changes in v2:
> - New patch in the series
> ---
>  .../devicetree/bindings/media/rockchip-isp1.yaml  | 8 
>  1 file changed, 8 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH] mm : fix pte _PAGE_DIRTY bit when fallback migrate page

[Chris Mason]

On 16 Jul 2020, at 6:15, Robbie Ko wrote:


Kirill A. Shutemov 於 2020/7/15 下午4:11 寫道:

On Wed, Jul 15, 2020 at 10:45:39AM +0800, Robbie Ko wrote:

Kirill A. Shutemov 於 2020/7/14 下午6:19 寫道:

On Tue, Jul 14, 2020 at 11:46:12AM +0200, Vlastimil Babka wrote:

On 7/13/20 3:57 AM, Robbie Ko wrote:

Vlastimil Babka 於 2020/7/10 下午11:31 寫道:

On 7/9/20 4:48 AM, robbieko wrote:

From: Robbie Ko 

When a migrate page occurs, we first create a migration entry
to replace the original pte, and then go to 
fallback_migrate_page

to execute a writeout if the migratepage is not supported.

In the writeout, we will clear the dirty bit of the page and 
use
page_mkclean to clear the dirty bit along with the 
corresponding pte,

but page_mkclean does not support migration entry.

I don't follow the scenario.

When we establish migration entries with try_to_unmap(), it 
transfers

dirty bit from PTE to the page.

Sorry, I mean is _PAGE_RW with pte_write

When we establish migration entries with try_to_unmap(),
we create a migration entry, and if pte_write we set it to 
SWP_MIGRATION_WRITE,

which will replace the migration entry with the original pte.

When migratepage,  we go to fallback_migrate_page to execute a 
writeout

if the migratepage is not supported.

In the writeout, we call clear_page_dirty_for_io to  clear the dirty 
bit of the page
and use page_mkclean to clear pte _PAGE_RW with pte_wrprotect in 
page_mkclean_one.


However, page_mkclean_one does not support migration entries, so the
migration entry is still SWP_MIGRATION_WRITE.

In writeout, then we call remove_migration_ptes to remove the 
migration entry,
because it is still SWP_MIGRATION_WRITE so set _PAGE_RW to pte via 
pte_mkwrite.


Therefore, subsequent mmap wirte will not trigger page_mkwrite to 
cause data loss.

Hm, okay.

Folks, is there any good reason why try_to_unmap(TTU_MIGRATION) 
should not

clear PTE (make the PTE none) for file page?


This, I'm not sure.
But I think that for the fs that support migratepage, when migratepage 
is finished,
the page should still be dirty, and the pte should still have 
_PAGE_RW,
when the next mmap write occurs, we don't need to trigger the 
page_mkwrite again.


I don’t know the page migration code well, but you’ll need this one 
as well on the 4.4 kernel you mentioned:


commit 25f3c5021985e885292980d04a1423fd83c967bb
Author: Chris Mason 
Date:   Tue Jan 21 11:51:42 2020 -0500

Btrfs: keep pages dirty when using btrfs_writepage_fixup_worker

And this one as well:

commit 7703bdd8d23e6ef057af3253958a793ec6066b28
Author: Chris Mason 
Date:   Wed Jun 20 07:56:11 2018 -0700

Btrfs: don't clean dirty pages during buffered writes

With those two in place, we haven’t found lost data from the migration 
code, but we did see the fallback migration helper dirtying pages 
without going through page_mkwrite, which triggers the suboptimal btrfs 
fixup worker code path.  This isn’t a yea or nay on the patch, just 
additional info.


-chris

Re: [PATCH v4 2/9] media: staging: dt-bindings: rkisp1: add required items in i2c example

[Rob Herring]

On Thu, Jul 2, 2020 at 1:13 PM Helen Koike  wrote:
>
> Add missing required items in Rockchip ISP1 dt-bindings example for
> a complete i2c node.
>
> Signed-off-by: Helen Koike 
> ---
>
> Changes in v2:
> - new patch in the series
> ---
>  .../devicetree/bindings/media/rockchip-isp1.yaml | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git 
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
>  
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> index a77b6ec500c95..8c7904845788d 100644
> --- 
> a/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> +++ 
> b/drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> @@ -169,6 +169,11 @@ examples:
>  };
>
>  i2c7: i2c@ff16 {
> +compatible = "rockchip,rk3399-i2c";
> +reg = <0x0 0xff16 0x0 0x1000>;

This will give a warning now as the default cell sizes are 1.

> +interrupts = ;
> +clocks = < SCLK_I2C7>, < PCLK_I2C7>;
> +clock-names = "i2c", "pclk";

Just drop the unit address rather than adding all this.

>  clock-frequency = <40>;
>  #address-cells = <1>;
>  #size-cells = <0>;
> --
> 2.26.0
>

Re: [PATCH v5 03/17] perf ftrace: add option -t/--tid to filter by thread id

[Arnaldo Carvalho de Melo]

Em Fri, Jul 17, 2020 at 01:01:24PM -0400, Steven Rostedt escreveu:
> On Fri, 17 Jul 2020 21:26:50 +0800
> Changbin Du  wrote:
> 
> > On Thu, Jul 16, 2020 at 12:36:30PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Sat, Jul 11, 2020 at 08:40:21PM +0800, Changbin Du escreveu:  
> > > > This allows us to trace single thread instead of the whole process.
> > > > 
> > > > Signed-off-by: Changbin Du 
> > > > ---
> > > >  tools/perf/Documentation/perf-ftrace.txt | 4 
> > > >  tools/perf/builtin-ftrace.c  | 2 ++
> > > >  2 files changed, 6 insertions(+)
> > > > 
> > > > diff --git a/tools/perf/Documentation/perf-ftrace.txt 
> > > > b/tools/perf/Documentation/perf-ftrace.txt
> > > > index d79560dea19f..e204bf6d50d8 100644
> > > > --- a/tools/perf/Documentation/perf-ftrace.txt
> > > > +++ b/tools/perf/Documentation/perf-ftrace.txt
> > > > @@ -38,6 +38,10 @@ OPTIONS
> > > >  --pid=::
> > > > Trace on existing process id (comma separated list).
> > > >  
> > > > +-t::
> > > > +--tid=::
> > > > +   Trace on existing thread id (comma separated list).
> > > > +  

> > > Humm, I just  tried:

> > > [root@five ~]# yes > /dev/null &
> > > [1] 18265
> > > [root@five ~]# perf ftrace --tid 18265
> > > ^C[root@five ~]#

> > > After waiting for a while, nothing, what am I doing wrong?

> > I got it wrong. Currently ftrace only can filter by pid. If the pid is not
> > the main thread it won't work.
 
> Wait what?
 
> The "pid" for ftrace is really a "task id" which is a thread id.
 
> [root@bxtest ~]# yes > /dev/null &
> [1] 6799
> [root@bxtest ~]# trace-cmd record -e all -P 6799
> Hit Ctrl^C to stop recording
> ^CCPU 0: 3573031 events lost
> CPU0 data recorded at offset=0x838000
> 627675136 bytes in size
> CPU1 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU2 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU3 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU4 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU5 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU6 data recorded at offset=0x25ed1000
> 0 bytes in size
> CPU7 data recorded at offset=0x25ed1000
> 0 bytes in size
> [root@bxtest ~]# trace-cmd report | head 
> CPU 1 is empty
> CPU 2 is empty
> CPU 3 is empty
> CPU 4 is empty
> CPU 5 is empty
> CPU 6 is empty
> CPU 7 is empty
> cpus=8
>  yes-6799  [000] 67825.580902: sys_exit: NR 1 = 8192
>  yes-6799  [000] 67825.580903: sys_exit_write:   0x2000
> 
> 
> What's different about tid vs pid?

Say you use:

^C[root@ssdandy ~]# cyclictest --smp -um -p95
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.05 0.03 0.06 2/409 29072

T: 0 (29065) P:95 I:1000 C:518 Min:  2 Act:2 Avg:2 Max:   6
T: 1 (29066) P:95 I:1500 C:343 Min:  2 Act:2 Avg:2 Max:   5
T: 2 (29067) P:95 I:2000 C:256 Min:  2 Act:2 Avg:2 Max:   7
T: 3 (29068) P:95 I:2500 C:203 Min:  2 Act:2 Avg:2 Max:   5
T: 4 (29069) P:95 I:3000 C:168 Min:  2 Act:2 Avg:3 Max:   6
T: 5 (29070) P:95 I:3500 C:143 Min:  2 Act:2 Avg:2 Max:   6
T: 6 (29071) P:95 I:4000 C:124 Min:  2 Act:2 Avg:2 Max:   7
T: 7 (29072) P:95 I:4500 C:110 Min:  2 Act:2 Avg:2 Max:

Then we do:

# pidof cyclictest
29064
#

If we use:

[root@ssdandy ~]# perf record --pid 29064
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (866 samples) ]

[root@ssdandy ~]# perf report --task
#  pid  tid ppid  comm
 00   -1 |swapper
 2906429064   -1 |cyclictest
 2906429065   -1 |cyclictest
 2906429066   -1 |cyclictest
 2906429067   -1 |cyclictest
 2906429068   -1 |cyclictest
 2906429069   -1 |cyclictest
 2906429070   -1 |cyclictest
 2906429071   -1 |cyclictest
 2906429072   -1 |cyclictest
[root@ssdandy ~]#

If we are interested only on the thread running on CPU3 we can do:

[root@ssdandy ~]# perf report --task
#  pid  tid ppid  comm
 00   -1 |swapper
 2906429064   -1 |cyclictest
 2906429068   -1 |cyclictest
[root@ssdandy ~]#

The first 29064 is just to have info on who created 29068, i.e.:

Its just the synthesized info for 29068 creator:

[root@ssdandy ~]# perf report -D | grep -w 29064/29064
0 0x4690 [0x30]: PERF_RECORD_COMM: cyclictest:29064/29064
0 0x46c0 [0x70]: PERF_RECORD_MMAP2 29064/29064: [0x40(0xa000) @ 0 fd:00 
136246288 0]: r-xp /usr/bin/cyclictest
0 0x4730 [0x80]: PERF_RECORD_MMAP2 29064/29064: [0x7f990f505000(0x15000) @ 0 
fd:00 201479398 0]: r-xp /usr/lib64/libgcc_s-4.8.5-20150702.so.1
0 0x47b0 [0x70]: PERF_RECORD_MMAP2 29064/29064: [0x7f990f71b000(0x1c3000) @ 0 
fd:00 201334455 0]: r-xp /usr/lib64/libc-2.17.so
0 0x4820 [0x78]: PERF_RECORD_MMAP2 29064/29064: 

Re: [GIT PULL] HID fixes

[pr-tracker-bot]

The pull request you sent on Fri, 17 Jul 2020 14:01:54 +0200 (CEST):

> git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/60541fb62438c6abd821874cfc3a24d280d1cbbf

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] overlayfs fixes for 5.8-rc6

[pr-tracker-bot]

The pull request you sent on Fri, 17 Jul 2020 13:55:30 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git 
> tags/ovl-fixes-5.8-rc6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44fea37378bf735de63263d558763ce50fca05ef

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH 1/2 v2] net: hsr: fix incorrect lsdu size in the tag of HSR frames for small frames

[Grygorii Strashko]

On 17/07/2020 17:55, Murali Karicheri wrote:

For small Ethernet frames with size less than minimum size 66 for HSR
vs 60 for regular Ethernet frames, hsr driver currently doesn't pad the
frame to make it minimum size. This results in incorrect LSDU size being
populated in the HSR tag for these frames. Fix this by padding the frame
to the minimum size applicable for HSR.

Signed-off-by: Murali Karicheri 
---
  no change from original version
  Sending this bug fix ahead of PRP patch series as per comment
  net/hsr/hsr_forward.c | 3 +++
  1 file changed, 3 insertions(+)

  Sending this bug fix ahead of PRP patch series as per comment
diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
index ed13760463de..e42fd356f073 100644
--- a/net/hsr/hsr_forward.c
+++ b/net/hsr/hsr_forward.c
@@ -127,6 +127,9 @@ static void hsr_fill_tag(struct sk_buff *skb, struct 
hsr_frame_info *frame,
int lane_id;
int lsdu_size;
  
+	/* pad to minimum packet size which is 60 + 6 (HSR tag) */

+   skb_put_padto(skb, ETH_ZLEN + HSR_HLEN);


It may fail.
And i worry that it might be not the right place to do that
(if packet is small it will be called for every copy of the packet).
May be it has to be done once when packet enters LRE device?


+
if (port->type == HSR_PT_SLAVE_A)
lane_id = 0;
else



--
Best regards,
grygorii

Re: [PATCH v3] mm/hugetlb: split hugetlb_cma in nodes with memory

[Mike Kravetz]

On 7/17/20 2:51 AM, Anshuman Khandual wrote:
> 
> 
> On 07/17/2020 02:06 PM, Will Deacon wrote:
>> On Fri, Jul 17, 2020 at 10:32:53AM +0530, Anshuman Khandual wrote:
>>>
>>>
>>> On 07/16/2020 11:55 PM, Mike Kravetz wrote:
 >From 17c8f37afbf42fe7412e6eebb3619c6e0b7e1c3c Mon Sep 17 00:00:00 2001
 From: Mike Kravetz 
 Date: Tue, 14 Jul 2020 15:54:46 -0700
 Subject: [PATCH] hugetlb: move cma reservation to code setting up gigantic
  hstate

 Instead of calling hugetlb_cma_reserve() directly from arch specific
 code, call from hugetlb_add_hstate when adding a gigantic hstate.
 hugetlb_add_hstate is either called from arch specific huge page setup,
 or as the result of hugetlb command line processing.  In either case,
 this is late enough in the init process that all numa memory information
 should be initialized.  And, it is early enough to still use early
 memory allocator.
>>>
>>> This assumes that hugetlb_add_hstate() is called from the arch code at
>>> the right point in time for the generic HugeTLB to do the required CMA
>>> reservation which is not ideal. I guess it must have been a reason why
>>> CMA reservation should always called by the platform code which knows
>>> the boot sequence timing better.
>>
>> Ha, except we've moved it around two or three times already in the last
>> month or so, so I'd say we don't have a clue when to call it in the arch
>> code.
> 
> The arch dependency is not going way with this change either. Just that
> its getting transferred to hugetlb_add_hstate() which gets called from
> arch_initcall() in every architecture.
> 
> The perfect timing here happens to be because of arch_initcall() instead.
> This is probably fine, as long as
> 
> 0. hugetlb_add_hstate() is always called at arch_initcall()

In another reply, I give reasoning why it would be safe to call even later
at hugetlb command line processing time.

> 1. N_MEMORY mask is guaranteed to be initialized at arch_initcall()

This is a bit more difficult to guarantee.  I find the init sequence hard to
understand.  Looking at the arm code, arch_initcall(hugetlbpage_init)
happens after N_MEMORY mask is setup.  I can't imagine any arch code setting
up huge pages before N_MEMORY.  But, I suppose it is possible and we would
need to somehow guarantee this.

> 2. CMA reservation is available to be called at arch_initcall()

Since I am pretty sure we can delay the reservation until hugetlb command
line processing time, it would be great if it was always done there.
Unfortunately, I can not immediately think of an easy way to do this.
-- 
Mike Kravetz

Re: [GIT PULL] fuse fixes for 5.8-rc6

[pr-tracker-bot]

The pull request you sent on Fri, 17 Jul 2020 14:31:39 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git 
> tags/fuse-fixes-5.8-rc6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0dd68a34eccd598109eb845d107a7e8e196745db

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH v2] drm: msm: a6xx: fix gpu failure after system resume

[Doug Anderson]

Hi,

On Fri, Jul 17, 2020 at 7:46 AM Jordan Crouse  wrote:
>
> On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote:
> > On targets where GMU is available, GMU takes over the ownership of GX GDSC
> > during its initialization. So, move the refcount-get on GX PD before we
> > initialize the GMU. This ensures that nobody can collapse the GX GDSC
> > once GMU owns the GX GDSC. This patch fixes some GMU OOB errors seen
> > during GPU wake up during a system resume.
>
> > Signed-off-by: Akhil P Oommen 
> > Reported-by: Matthias Kaehlcke 
> > Tested-by: Matthias Kaehlcke 
>
> The Signed-off-by needs to be at the end but I think Rob can do that for you.

It does?  I've always been told that this is supposed to be roughly a
log of what happens.  In that sense you added your SoB before the
review/test happened so it should come before.  I know some
maintainers seem to do things differently but that seems to be the
most common.  In that sense, I think the order that Akhil has is
correct.  ...but, obviously, it's up to the maintainer.  ;-)

Re: [GIT PULL] regmap fixes for v5.8-rc5

[pr-tracker-bot]

The pull request you sent on Fri, 17 Jul 2020 16:42:44 +0100:

> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 
> tags/regmap-fix-v5.8-rc5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ee43695571c258c0945d4c456ea85b2af9aafdf4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] sound fixes for 5.8-rc6

[pr-tracker-bot]

The pull request you sent on Fri, 17 Jul 2020 08:59:07 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
> tags/sound-5.8-rc6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a238ac2d6aa587168db943661646883126f3c3fd

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] regulator fixes for v5.8-rc5

[pr-tracker-bot]

The pull request you sent on Fri, 17 Jul 2020 16:42:54 +0100:

> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> tags/regulator-fix-v5.8-rc5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8da822e8a573767c4777a4b3f11ee12954a8cd0e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH v5 02/17] perf ftrace: add option '-F/--funcs' to list available functions

[Ian Rogers]

On Sat, Jul 11, 2020 at 5:42 AM Changbin Du  wrote:
>
> This adds an option '-F/--funcs' to list all available functions to trace,
> which is read from tracing file 'available_filter_functions'.
>
> $ sudo ./perf ftrace -F | head
> trace_initcall_finish_cb
> initcall_blacklisted
> do_one_initcall
> do_one_initcall
> trace_initcall_start_cb
> run_init_process
> try_to_run_init_process
> match_dev_by_label
> match_dev_by_uuid
> rootfs_init_fs_context
>
> Signed-off-by: Changbin Du 
>
> ---
> v2: option name '-l/--list-functions' -> '-F/--funcs'
> ---
>  tools/perf/Documentation/perf-ftrace.txt |  4 +++
>  tools/perf/builtin-ftrace.c  | 43 
>  2 files changed, 47 insertions(+)
>
> diff --git a/tools/perf/Documentation/perf-ftrace.txt 
> b/tools/perf/Documentation/perf-ftrace.txt
> index 952e46669168..d79560dea19f 100644
> --- a/tools/perf/Documentation/perf-ftrace.txt
> +++ b/tools/perf/Documentation/perf-ftrace.txt
> @@ -30,6 +30,10 @@ OPTIONS
>  --verbose=::
>  Verbosity level.
>
> +-F::
> +--funcs::
> +List all available functions to trace.
> +

Does "perf list tracepoint" contain this information? Perhaps add a
note to clarify.

Thanks,
Ian

>  -p::
>  --pid=::
> Trace on existing process id (comma separated list).
> diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
> index 5f53da87040d..244cc8e6bd60 100644
> --- a/tools/perf/builtin-ftrace.c
> +++ b/tools/perf/builtin-ftrace.c
> @@ -32,6 +32,7 @@ struct perf_ftrace {
> struct evlist   *evlist;
> struct target   target;
> const char  *tracer;
> +   boollist_avail_functions;
> struct list_headfilters;
> struct list_headnotrace;
> struct list_headgraph_funcs;
> @@ -127,6 +128,43 @@ static int append_tracing_file(const char *name, const 
> char *val)
> return __write_tracing_file(name, val, true);
>  }
>
> +static int read_tracing_file_to_stdout(const char *name)
> +{
> +   char buf[4096];
> +   char *file;
> +   int fd;
> +   int ret = -1;
> +
> +   file = get_tracing_file(name);
> +   if (!file) {
> +   pr_debug("cannot get tracing file: %s\n", name);
> +   return -1;
> +   }
> +
> +   fd = open(file, O_RDONLY);
> +   if (fd < 0) {
> +   pr_debug("cannot open tracing file: %s: %s\n",
> +name, str_error_r(errno, buf, sizeof(buf)));
> +   goto out;
> +   }
> +
> +   /* read contents to stdout */
> +   while (true) {
> +   int n = read(fd, buf, sizeof(buf));
> +   if (n <= 0)
> +   goto out_close;
> +   if (fwrite(buf, n, 1, stdout) != 1)
> +   goto out_close;
> +   }
> +   ret = 0;
> +
> +out_close:
> +   close(fd);
> +out:
> +   put_tracing_file(file);
> +   return ret;
> +}
> +
>  static int reset_tracing_cpu(void);
>  static void reset_tracing_filters(void);
>
> @@ -301,6 +339,9 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int 
> argc, const char **argv)
> signal(SIGCHLD, sig_handler);
> signal(SIGPIPE, sig_handler);
>
> +   if (ftrace->list_avail_functions)
> +   return 
> read_tracing_file_to_stdout("available_filter_functions");
> +
> if (reset_tracing_files(ftrace) < 0) {
> pr_err("failed to reset ftrace\n");
> goto out;
> @@ -470,6 +511,8 @@ int cmd_ftrace(int argc, const char **argv)
> const struct option ftrace_options[] = {
> OPT_STRING('t', "tracer", , "tracer",
>"tracer to use: function or function_graph (This option is 
> deprecated)"),
> +   OPT_BOOLEAN('F', "funcs", _avail_functions,
> +   "Show available functions to filter"),
> OPT_STRING('p', "pid", , "pid",
>"trace on existing process id"),
> OPT_INCR('v', "verbose", ,
> --
> 2.25.1
>

Re: [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool

[Steven Rostedt]

On Fri, 17 Jul 2020 10:28:13 -0700
Sami Tolvanen  wrote:

> On Fri, Jun 26, 2020 at 4:29 AM Peter Zijlstra  wrote:
> >
> > On Thu, Jun 25, 2020 at 03:40:42PM -0700, Sami Tolvanen wrote:
> >  
> > > > Not boot tested, but it generates the required sections and they look
> > > > more or less as expected, ymmv.  
> >  
> > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > > index a291823f3f26..189575c12434 100644
> > > > --- a/arch/x86/Kconfig
> > > > +++ b/arch/x86/Kconfig
> > > > @@ -174,7 +174,6 @@ config X86
> > > > select HAVE_EXIT_THREAD
> > > > select HAVE_FAST_GUP
> > > > select HAVE_FENTRY  if X86_64 || DYNAMIC_FTRACE
> > > > -   select HAVE_FTRACE_MCOUNT_RECORD
> > > > select HAVE_FUNCTION_GRAPH_TRACER
> > > > select HAVE_FUNCTION_TRACER
> > > > select HAVE_GCC_PLUGINS  
> > >
> > > This breaks DYNAMIC_FTRACE according to kernel/trace/ftrace.c:
> > >
> > >   #ifndef CONFIG_FTRACE_MCOUNT_RECORD
> > >   # error Dynamic ftrace depends on MCOUNT_RECORD
> > >   #endif
> > >
> > > And the build errors after that seem to confirm this. It looks like we 
> > > might
> > > need another flag to skip recordmcount.  
> >
> > Hurm, Steve, how you want to do that?  
> 
> Steven, did you have any thoughts about this? Moving recordmcount to
> an objtool pass that knows about call sites feels like a much cleaner
> solution than annotating kernel code to avoid unwanted relocations.
> 

Bah, I started to reply to this then went to look for details, got
distracted, forgot about it, my laptop crashed (due to a zoom call),
and I lost the email I was writing (haven't looked in the drafts
folder, but my idea about this has changed since anyway).

So the problem is that we process mcount references in other areas and
that confuses the ftrace modification portion?

Someone just submitted a patch for arm64 for this:

https://lore.kernel.org/r/20200717143338.19302-1-gregory.herr...@oracle.com

Is that what you want?

-- Steve

Re: [Regression] "SUNRPC: Add "@len" parameter to gss_unwrap()" breaks NFS Kerberos on upstream stable 5.4.y

[Chuck Lever]

> On Jul 17, 2020, at 1:29 PM, Pierre Sauter  wrote:
> 
> Hi Chuck,
> 
> Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever:
>> So this makes me think there's a possibility you are not using upstream
>> stable kernels. I can't help if I don't know what source code and commit
>> stream you are using. It also makes me question the bisect result.
> 
> Yes you are right, I was referring to Ubuntu kernels 5.4.0-XX. From the
> discussion in the Ubuntu bugtracker I got the impression that Ubuntu kernels
> 5.4.0-XX and upstream 5.4.XX are closely related, obviously they are not. The
> bisection was done by the original bug reporter and also refers to the Ubuntu
> kernel.
> 
> In the meantime I tested v5.4.51 upstream, which shows no problems. Sorry for
> the bother.

Pierre, thanks for confirming!

Kai-Heng suspected an upstream stable commit that is missing in 5.4.0-40,
but I don't have any good suggestions.


>>> My krb5 etype is aes256-cts-hmac-sha1-96.
>> 
>> Thanks! And what is your NFS server and filesystem? It's possible that the
>> client is not estimating the size of the reply correctly. Variables include
>> the size of file handles, MIC verifiers, and wrap tokens.
> 
> The server is Debian with v4.19.130 upstream, filesystem ext4.
> 
>> You might try:
>> 
>> e8d70b321ecc ("SUNRPC: Fix another issue with MIC buffer space")
> 
> That one is actually in Ubuntus 5.4.0-40, from looking at the code.

--
Chuck Lever

Re: [PATCH v5 04/15] vfio/type1: Report iommu nesting info to userspace

[Auger Eric]

Yi,

On 7/12/20 1:20 PM, Liu Yi L wrote:
> This patch exports iommu nesting capability info to user space through
> VFIO. User space is expected to check this info for supported uAPIs (e.g.
it is not only to check the supported uAPIS but rather to know which
callbacks it must call upon vIOMMU events and which features are
supported by the physical IOMMU.
> PASID alloc/free, bind page table, and cache invalidation) and the vendor
> specific format information for first level/stage page table that will be
> bound to.
> 
> The nesting info is available only after the nesting iommu type is set
> for a container.
to NESTED type
 Current implementation imposes one limitation - one
> nesting container should include at most one group. The philosophy of
> vfio container is having all groups/devices within the container share
> the same IOMMU context. When vSVA is enabled, one IOMMU context could
> include one 2nd-level address space and multiple 1st-level address spaces.
> While the 2nd-level address space is reasonably sharable by multiple groups
> , blindly sharing 1st-level address spaces across all groups within the
> container might instead break the guest expectation. In the future sub/
> super container concept might be introduced to allow partial address space
> sharing within an IOMMU context. But for now let's go with this restriction
> by requiring singleton container for using nesting iommu features. Below
> link has the related discussion about this decision.

Maybe add a note about SMMU related changes spotted by Jean.
> 
> https://lkml.org/lkml/2020/5/15/1028
> 
> Cc: Kevin Tian 
> CC: Jacob Pan 
> Cc: Alex Williamson 
> Cc: Eric Auger 
> Cc: Jean-Philippe Brucker 
> Cc: Joerg Roedel 
> Cc: Lu Baolu 
> Signed-off-by: Liu Yi L 
> ---
> v4 -> v5:
> *) address comments from Eric Auger.
> *) return struct iommu_nesting_info for VFIO_IOMMU_TYPE1_INFO_CAP_NESTING as
>cap is much "cheap", if needs extension in future, just define another cap.
>https://lore.kernel.org/kvm/20200708132947.5b7ee...@x1.home/
> 
> v3 -> v4:
> *) address comments against v3.
> 
> v1 -> v2:
> *) added in v2
> ---
>  drivers/vfio/vfio_iommu_type1.c | 102 
> +++-
>  include/uapi/linux/vfio.h   |  19 
>  2 files changed, 109 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 3bd70ff..ed80104 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -62,18 +62,20 @@ MODULE_PARM_DESC(dma_entry_limit,
>"Maximum number of user DMA mappings per container (65535).");
>  
>  struct vfio_iommu {
> - struct list_headdomain_list;
> - struct list_headiova_list;
> - struct vfio_domain  *external_domain; /* domain for external user */
> - struct mutexlock;
> - struct rb_root  dma_list;
> - struct blocking_notifier_head notifier;
> - unsigned intdma_avail;
> - uint64_tpgsize_bitmap;
> - boolv2;
> - boolnesting;
> - booldirty_page_tracking;
> - boolpinned_page_dirty_scope;
> + struct list_headdomain_list;
> + struct list_headiova_list;
> + /* domain for external user */
> + struct vfio_domain  *external_domain;
> + struct mutexlock;
> + struct rb_root  dma_list;
> + struct blocking_notifier_head   notifier;
> + unsigned intdma_avail;
> + uint64_tpgsize_bitmap;
> + boolv2;
> + boolnesting;
> + booldirty_page_tracking;
> + boolpinned_page_dirty_scope;
> + struct iommu_nesting_info   *nesting_info;
>  };
>  
>  struct vfio_domain {
> @@ -130,6 +132,9 @@ struct vfio_regions {
>  #define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)  \
>   (!list_empty(>domain_list))
>  
> +#define CONTAINER_HAS_DOMAIN(iommu)  (((iommu)->external_domain) || \
> +  (!list_empty(&(iommu)->domain_list)))
> +
>  #define DIRTY_BITMAP_BYTES(n)(ALIGN(n, BITS_PER_TYPE(u64)) / 
> BITS_PER_BYTE)
>  
>  /*
> @@ -1929,6 +1934,13 @@ static void vfio_iommu_iova_insert_copy(struct 
> vfio_iommu *iommu,
>  
>   list_splice_tail(iova_copy, iova);
>  }
> +
> +static void vfio_iommu_release_nesting_info(struct vfio_iommu *iommu)
> +{
> + kfree(iommu->nesting_info);
> + iommu->nesting_info = NULL;
> +}
> +
>  static int vfio_iommu_type1_attach_group(void *iommu_data,
>struct iommu_group *iommu_group)
>  {
> @@ -1959,6 +1971,12 @@ static int vfio_iommu_type1_attach_group(void 
> *iommu_data,
> 

Re: [PATCH] net: genetlink: Move initialization to core_initcall

[David Miller]

From: Daniel Lezcano 
Date: Wed, 15 Jul 2020 09:43:00 +0200

> if you agree with this change, is it possible I merge it through the
> thermal tree in order to fix the issue ?

No problem:

Acked-by: David S. Miller 

Re: [RFC PATCH v3 00/18] Support for Tegra video capture from external sensor

[Sowjanya Komatineni]

On 7/17/20 10:23 AM, Sowjanya Komatineni wrote:


On 7/17/20 10:08 AM, Hans Verkuil wrote:

On 17/07/2020 18:34, Sowjanya Komatineni wrote:

On 7/17/20 3:54 AM, Hans Verkuil wrote:

Hi Sowjanya,

On 15/07/2020 06:20, Sowjanya Komatineni wrote:
This series adds support for video capture from external camera 
sensor to

Tegra video driver.

Jetson TX1 has camera expansion connector and supports custom 
camera module

designed as per TX1 design specification.

This series also enables camera capture support for Jetson Nano 
which has

Raspberry PI camera header.

This series is tested with IMX219 camera sensor.

This series include,

VI I2C related fixes
- Camera sensor programming happens through VI I2C which is on 
host1x bus.

- These patches includes device tree and I2C driver fixes for VI I2C.

Tegra video driver updates
- TPG Vs Non-TPG based on Kconfig
- Support for external sensor video capture based on device graph 
from DT.

- Support for selection ioctl operations
- Tegra MIPI CSI pads calibration
- CSI T-CLK and T-HS settle time computation based on clock rates.

Host1x driver updates
- Adds API to allow creating mipi device for specific device node.
- Splits MIPI pads calibrate start and waiting for calibration to 
be done.


Device tree updates
- Adds camera connector 2V8, 1V8, 1V2 regulator supplies to Jetson 
TX1 DT.

- Enabled VI and CSI support in Jetson Nano DT.

I'm doing a bit of stress testing with:

while true; do v4l2-ctl --stream-mmap --stream-count=1; done

and I see that the imx274 has often streaming failures:

[  172.025144] IMX274 8-001a: s_stream failed
[  179.025192] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 3132 = 870 (2 bytes)

[  179.033575] IMX274 8-001a: s_stream failed
[  226.525378] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 3130 = 878 (2 bytes)

[  226.533761] IMX274 8-001a: s_stream failed
[  227.029325] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30f6 = 107 (2 bytes)

[  227.037758] IMX274 8-001a: s_stream failed
[  247.025218] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30f6 = 107 (2 bytes)

[  247.033658] IMX274 8-001a: s_stream failed
[  293.025517] IMX274 8-001a: s_stream failed
[  309.024727] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30e0 = 0 (2 bytes)

[  309.032969] IMX274 8-001a: s_stream failed
[  309.529506] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30f8 = 11d2 (3 bytes)

[  309.538103] IMX274 8-001a: imx274_set_frame_length error = -121
[  309.544102] IMX274 8-001a: imx274_set_frame_interval error = -121
[  309.550243] IMX274 8-001a: s_stream failed
[  314.025561] IMX274 8-001a: s_stream failed
[  329.025586] IMX274 8-001a: s_stream failed
[  340.529567] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 303a = f0c (2 bytes)

[  340.538009] IMX274 8-001a: s_stream failed
[  347.525627] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 30f6 = 107 (2 bytes)

[  347.534008] IMX274 8-001a: s_stream failed
[  365.033640] IMX274 8-001a: s_stream failed
[  437.525788] IMX274 8-001a: imx274_write_mbreg : i2c bulk write 
failed, 3038 = c (2 bytes)

[  437.533997] IMX274 8-001a: s_stream failed
[  456.029780] IMX274 8-001a: s_stream failed
[  472.025862] IMX274 8-001a: s_stream failed
[  498.025861] IMX274 8-001a: s_stream failed
[  500.025905] IMX274 8-001a: s_stream failed

where v4l2-ctl returns:

  VIDIOC_STREAMON returned -1 (Remote I/O error)

I don't see this with the imx219.

I also see this occasionally:

[Fri Jul 17 12:51:42 2020] video4linux video1: failed to run 
capture start kthread: -4


Something is not stable here.

Regards,

Hans

Hi Hans,

Running the same single frame continuous loop for more than 2 hours now
and I don't see any failure.

Above failure shows i2c bulk writes to IMX274 failure due to which
s_stream also failed.

Not sure if its due to i2c mux in the path to sensor on your module
causing some issue when there is more i2c write traffic as we are doing
single stream in continuous loop. Also IMX219 does not show on your 
side

so something specific to IMX274 setup probably.
I'll take a closer look next week. Good to know that it works fine 
for you.




Regarding kthread_run failure where kthread_run() returned -EINTR 
during

capture start thread, I always see this happen at the point of stopping
the continuous single stream while loop by pressing ctrl+c after few
loops of execution.
Hmm, if this is normal behavior, then should this message be a debug 
message

only? Or perhaps only show the message if the error code != EINTR.


I believe its good to still show this as its reported by kthread_run 
-> kthread_create_on_node.


But not sure in real usecase we will ever use while true like this and 
we should use script to also break while loop along with v4l2-ctl 
termination when ctrl-c terminate request happens.


Hi Hans, As this happens only during this type of case, I can update to 
show 

Re: [PATCH net-next] net: phy: sfp: Cotsworks SFF module EEPROM fixup

[David Miller]

From: Chris Healy 
Date: Tue, 14 Jul 2020 10:59:10 -0700

> Some Cotsworks SFF have invalid data in the first few bytes of the
> module EEPROM.  This results in these modules not being detected as
> valid modules.
> 
> Address this by poking the correct EEPROM values into the module
> EEPROM when the model/PN match and the existing module EEPROM contents
> are not correct.
> 
> Signed-off-by: Chris Healy 

Applied, thank you.

Re: [PATCH v2] driver core: Fix sleeping in invalid context during device link deletion

[Saravana Kannan]

On Fri, Jul 17, 2020 at 9:34 AM Guenter Roeck  wrote:
>
> On Fri, Jul 17, 2020 at 12:13:04AM +0200, Marek Szyprowski wrote:
> > Hi Saravana,
> >
> > On 16.07.2020 23:45, Saravana Kannan wrote:
> > > Marek and Guenter reported that commit 287905e68dd2 ("driver core:
> > > Expose device link details in sysfs") caused sleeping/scheduling while
> > > atomic warnings.
> > >
> > > BUG: sleeping function called from invalid context at 
> > > kernel/locking/mutex.c:935
> > > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 12, name: 
> > > kworker/0:1
> > > 2 locks held by kworker/0:1/12:
> > >#0: ee8074a8 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: 
> > > process_one_work+0x174/0x7dc
> > >#1: ee921f20 ((work_completion)(>work)){+.+.}-{0:0}, at: 
> > > process_one_work+0x174/0x7dc
> > > Preemption disabled at:
> > > [] srcu_invoke_callbacks+0xc0/0x154
> > > - 8< - SNIP
> > > [] (device_del) from [] (device_unregister+0x24/0x64)
> > > [] (device_unregister) from [] 
> > > (srcu_invoke_callbacks+0xcc/0x154)
> > > [] (srcu_invoke_callbacks) from [] 
> > > (process_one_work+0x234/0x7dc)
> > > [] (process_one_work) from [] 
> > > (worker_thread+0x44/0x51c)
> > > [] (worker_thread) from [] (kthread+0x158/0x1a0)
> > > [] (kthread) from [] (ret_from_fork+0x14/0x20)
> > > Exception stack(0xee921fb0 to 0xee921ff8)
> > >
> > > This was caused by the device link device being released in the context
> > > of srcu_invoke_callbacks().  There is no need to wait till the RCU
> > > callback to release the device link device.  So release the device
> > > earlier and move the call_srcu() into the device release code. That way,
> > > the memory will get freed only after the device is released AND the RCU
> > > callback is called.
> > >
> > > Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
> > > Reported-by: Marek Szyprowski 
> > > Reported-by: Guenter Roeck 
> > > Signed-off-by: Saravana Kannan 
> > > ---
> > >
> > > v1->v2:
> > > - Better fix
> > > - Changed subject
> > > - v1 is this patch 
> > > https://lore.kernel.org/lkml/20200716050846.2047110-1-sarava...@google.com/
> > >
> > > Marek and Guenter,
> > >
> > > I reproduced the original issue and tested this fix. Seems to work for
> > > me. Can you confirm?
> >
> > Confirmed, this one fixes the issue! :)
> >
> Same here.
>
> Tested-by: Guenter Roeck 
>
> Guenter
>
> > Tested-by: Marek Szyprowski 
> >

Thanks both.

Greg, can you review this and pull this into driver-core-next too?

-Saravana

Re: [Regression] "SUNRPC: Add "@len" parameter to gss_unwrap()" breaks NFS Kerberos on upstream stable 5.4.y

[Pierre Sauter]

Hi Chuck,

Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever:
> So this makes me think there's a possibility you are not using upstream
> stable kernels. I can't help if I don't know what source code and commit
> stream you are using. It also makes me question the bisect result.

Yes you are right, I was referring to Ubuntu kernels 5.4.0-XX. From the
discussion in the Ubuntu bugtracker I got the impression that Ubuntu kernels
5.4.0-XX and upstream 5.4.XX are closely related, obviously they are not. The
bisection was done by the original bug reporter and also refers to the Ubuntu
kernel.

In the meantime I tested v5.4.51 upstream, which shows no problems. Sorry for
the bother.

> > My krb5 etype is aes256-cts-hmac-sha1-96.
> 
> Thanks! And what is your NFS server and filesystem? It's possible that the
> client is not estimating the size of the reply correctly. Variables include
> the size of file handles, MIC verifiers, and wrap tokens.

The server is Debian with v4.19.130 upstream, filesystem ext4.

> You might try:
> 
> e8d70b321ecc ("SUNRPC: Fix another issue with MIC buffer space")

That one is actually in Ubuntus 5.4.0-40, from looking at the code.

Best Regards
-- 
Pierre Sauter
Studentenwerk München
---

Re: [PATCH] recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.

[Steven Rostedt]

On Fri, 17 Jul 2020 16:33:38 +0200
gregory.herr...@oracle.com wrote:

> From: Gregory Herrero 
> 
> Currently, if a section has a relocation to '_mcount' symbol, a new
> __mcount_loc entry will be added whatever the relocation type is.
> This is problematic when a relocation to '_mcount' is in the middle of a
> section and is not a call for ftrace use.
> 
> Such relocation could be generated with below code for example:
> bool is_mcount(unsigned long addr)
> {
> return (target == (unsigned long) &_mcount);
> }
> 
> With this snippet of code, ftrace will try to patch the mcount location
> generated by this code on module load and fail with:
> 
> Call trace:
>  ftrace_bug+0xa0/0x28c
>  ftrace_process_locs+0x2f4/0x430
>  ftrace_module_init+0x30/0x38
>  load_module+0x14f0/0x1e78
>  __do_sys_finit_module+0x100/0x11c
>  __arm64_sys_finit_module+0x28/0x34
>  el0_svc_common+0x88/0x194
>  el0_svc_handler+0x38/0x8c
>  el0_svc+0x8/0xc
> ---[ end trace d828d06b36ad9d59 ]---
> ftrace failed to modify
> [] 0xa2dbf3a3a41c
>  actual:   66:a9:3c:90
> Initializing ftrace call sites
> ftrace record flags: 200
>  (0)
> expected tramp: a2dc6cf66724
> 
> So Limit the relocation type to R_AARCH64_CALL26 as in perl version of
> recordmcount.
> 

I'd rather have this go through the arm64 tree, as they can test it
better than I can.

Acked-by: Steven Rostedt (VMware) 

-- Steve


> Fixes: ed60453fa8f8 ("ARM: 6511/1: ftrace: add ARM support for C version of 
> recordmcount")
> Signed-off-by: Gregory Herrero 
> ---
>  scripts/recordmcount.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
> index 7225107a9aaf..e59022b3f125 100644
> --- a/scripts/recordmcount.c
> +++ b/scripts/recordmcount.c
> @@ -434,6 +434,11 @@ static int arm_is_fake_mcount(Elf32_Rel const *rp)
>   return 1;
>  }
>  
> +static int arm64_is_fake_mcount(Elf64_Rel const *rp)
> +{
> + return ELF64_R_TYPE(w(rp->r_info)) != R_AARCH64_CALL26;
> +}
> +
>  /* 64-bit EM_MIPS has weird ELF64_Rela.r_info.
>   * 
> http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf
>   * We interpret Table 29 Relocation Operation (Elf64_Rel, Elf64_Rela) [p.40]
> @@ -547,6 +552,7 @@ static int do_file(char const *const fname)
>   make_nop = make_nop_arm64;
>   rel_type_nop = R_AARCH64_NONE;
>   ideal_nop = ideal_nop4_arm64;
> + is_fake_mcount64 = arm64_is_fake_mcount;
>   break;
>   case EM_IA_64:  reltype = R_IA64_IMM64; break;
>   case EM_MIPS:   /* reltype: e_class*/ break;

Re: [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool

[Sami Tolvanen]

On Fri, Jun 26, 2020 at 4:29 AM Peter Zijlstra  wrote:
>
> On Thu, Jun 25, 2020 at 03:40:42PM -0700, Sami Tolvanen wrote:
>
> > > Not boot tested, but it generates the required sections and they look
> > > more or less as expected, ymmv.
>
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index a291823f3f26..189575c12434 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -174,7 +174,6 @@ config X86
> > > select HAVE_EXIT_THREAD
> > > select HAVE_FAST_GUP
> > > select HAVE_FENTRY  if X86_64 || DYNAMIC_FTRACE
> > > -   select HAVE_FTRACE_MCOUNT_RECORD
> > > select HAVE_FUNCTION_GRAPH_TRACER
> > > select HAVE_FUNCTION_TRACER
> > > select HAVE_GCC_PLUGINS
> >
> > This breaks DYNAMIC_FTRACE according to kernel/trace/ftrace.c:
> >
> >   #ifndef CONFIG_FTRACE_MCOUNT_RECORD
> >   # error Dynamic ftrace depends on MCOUNT_RECORD
> >   #endif
> >
> > And the build errors after that seem to confirm this. It looks like we might
> > need another flag to skip recordmcount.
>
> Hurm, Steve, how you want to do that?

Steven, did you have any thoughts about this? Moving recordmcount to
an objtool pass that knows about call sites feels like a much cleaner
solution than annotating kernel code to avoid unwanted relocations.

Sami

Re: [PATCH net-next] net: bcmgenet: fix error returns in bcmgenet_probe()

[Doug Berger]

On 7/17/2020 1:19 AM, Zhang Changzhong wrote:
> The driver forgets to call clk_disable_unprepare() in error path after
> a success calling for clk_prepare_enable().
> 
> Fix to goto err_clk_disable if clk_prepare_enable() is successful.
> 
> Signed-off-by: Zhang Changzhong 
> ---
>  drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index ee84a26..23df6f2 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -4016,7 +4016,7 @@ static int bcmgenet_probe(struct platform_device *pdev)
>   if (err)
>   err = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
>   if (err)
> - goto err;
> + goto err_clk_disable;
Please split this clause out as a separate pull-request with this fixes tag:
Fixes: 99d55638d4b0 ("net: bcmgenet: enable NETIF_F_HIGHDMA flag")

>  
>   /* Mii wait queue */
>   init_waitqueue_head(>wq);
> @@ -4028,14 +4028,14 @@ static int bcmgenet_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(priv->clk_wol)) {
>   dev_dbg(>pdev->dev, "failed to get enet-wol clock\n");
>   err = PTR_ERR(priv->clk_wol);
> - goto err;
> + goto err_clk_disable;
>   }
>  
>   priv->clk_eee = devm_clk_get_optional(>pdev->dev, "enet-eee");
>   if (IS_ERR(priv->clk_eee)) {
>   dev_dbg(>pdev->dev, "failed to get enet-eee clock\n");
>   err = PTR_ERR(priv->clk_eee);
> - goto err;
> + goto err_clk_disable;
>   }
>  
>   /* If this is an internal GPHY, power it on now, before UniMAC is
> 
Please split these changes into a pull-request with fixes tag:
Fixes: c80d36ff63a5 ("net: bcmgenet: Use devm_clk_get_optional() to get
the clocks")

Resubmit the pull-requests with [PATCH net].
That will make them easier to apply to stable branches.

Otherwise:
Acked-by: Doug Berger 

Thanks!

drivers/video/fbdev/riva/fbdev.c:788:29: sparse: sparse: cast removes address space '__iomem' of expression

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   8882572675c1bb1cc544f4e229a11661f1fc52e4
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to 
define address spaces
date:   4 weeks ago
config: m68k-randconfig-s031-20200717 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-49-g707c5017-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=m68k 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)

   drivers/video/fbdev/riva/fbdev.c:493:14: sparse: sparse: cast to restricted 
__le16
   drivers/video/fbdev/riva/fbdev.c:493:14: sparse: sparse: cast to restricted 
__le16
   drivers/video/fbdev/riva/fbdev.c:493:14: sparse: sparse: cast to restricted 
__le16
   drivers/video/fbdev/riva/fbdev.c:493:14: sparse: sparse: cast to restricted 
__le16
   drivers/video/fbdev/riva/fbdev.c:494:14: sparse: sparse: cast to restricted 
__le16
   drivers/video/fbdev/riva/fbdev.c:494:14: sparse: sparse: cast to restricted 
__le16
   drivers/video/fbdev/riva/fbdev.c:494:14: sparse: sparse: cast to restricted 
__le16
   drivers/video/fbdev/riva/fbdev.c:494:14: sparse: sparse: cast to restricted 
__le16
>> drivers/video/fbdev/riva/fbdev.c:788:29: sparse: sparse: cast removes 
>> address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:795:37: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:797:37: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:803:38: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:805:38: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:808:37: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:953:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:954:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:955:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:956:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:957:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:973:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:974:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:982:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:983:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:984:9: sparse: sparse: cast removes address 
space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1421:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1422:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1424:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1425:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1428:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1455:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1456:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1458:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1461:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1524:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1525:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1527:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1530:9: sparse: sparse: cast removes 
address space '__iomem' of expression
   drivers/video/fbdev/riva/fbdev.c:1531:9: sparse: sparse: cas

Good day Dear

[Dr Haruna Bello]

-- 

Good day Dear

I have a project of $18.5 Million Us Dollars which I will like you to
support me
so that the fund will be transfer to your bank account.
Please if you are capable reply back to me so that i will give more
details about this
project.

Thank you I am waiting to hear from you

Re: [patch V2 3/5] posix-cpu-timers: Provide mechanisms to defer timer handling to task_work

[Oleg Nesterov]

Looks correct to me, but I forgot everything about posix-timers.c

this obviously means that the expired timer won't fire until the
task returns to user-mode but probably we don't care.

One cosmetic nit below,

On 07/16, Thomas Gleixner wrote:
>
> +#ifdef CONFIG_POSIX_CPU_TIMERS_TASK_WORK
> +void posix_cpu_timers_work(struct callback_head *work);
> +
> +static inline void posix_cputimer_init_work(struct posix_cputimers *pct)
> +{
> + pct->task_work.func = posix_cpu_timers_work;

init_task_work() ?

> +}
> +#else
> +static inline void posix_cputimer_init_work(struct posix_cputimers *pct) { }
> +#endif
> +
>  static inline void posix_cputimers_init(struct posix_cputimers *pct)
>  {
>   memset(pct, 0, sizeof(*pct));
>   pct->bases[0].nextevt = U64_MAX;
>   pct->bases[1].nextevt = U64_MAX;
>   pct->bases[2].nextevt = U64_MAX;
> + posix_cputimer_init_work(pct);
>  }

And I can't resist. I know this is a common practice, please ignore, but to me

static inline void posix_cputimers_init(struct posix_cputimers *pct)
{
memset(pct, 0, sizeof(*pct));
pct->bases[0].nextevt = U64_MAX;
pct->bases[1].nextevt = U64_MAX;
pct->bases[2].nextevt = U64_MAX;
#ifdef CONFIG_POSIX_CPU_TIMERS_TASK_WORK
init_task_work(>task_work, posix_cpu_timers_work);
#endif
}

looks better than 2 posix_cputimer_init_work() definitions above.

Note also that signal_struct->posix_cputimers.task_work is never used, perhaps
it would be better to move this task_work into task_struct? This way we do not
even need to change posix_cputimers_init(), we call simply initialize
init_task.posix_task_work.

Oleg.

Re: [PATCH net 1/1] docs: ptp.rst: add support for Renesas (IDT) ClockMatrix

[David Miller]

From: 
Date: Tue, 14 Jul 2020 13:15:20 -0400

> From: Min Li 
> 
> Add below to “Ancillary clock features” section
>   - Low Pass Filter (LPF) access from user space
> 
> Add below to list of “Supported hardware” section
>   + Renesas (IDT) ClockMatrix™
> 
> Signed-off-by: Min Li 

Applied, thank you.

[PATCH v7 3/5] ACPI/PCI: Ignore _OSC DPC negotiation result if pcie_ports_dpc_native is set.

[sathyanarayanan . kuppuswamy]

From: Kuppuswamy Sathyanarayanan 

pcie_ports_dpc_native is set only if user requests native handling
of PCIe DPC capability via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result for DPC ownership
only if pcie_ports_dpc_native is unset.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/acpi/pci_root.c | 2 +-
 drivers/pci/pcie/dpc.c  | 3 ++-
 drivers/pci/pcie/portdrv.h  | 2 --
 drivers/pci/pcie/portdrv_core.c | 2 +-
 include/linux/pci.h | 2 ++
 5 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index a82069d064fe..a7bc1a864b14 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -962,7 +962,7 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root 
*root,
}
 
if (!(root->osc_control_set & OSC_PCI_EXPRESS_DPC_CONTROL)) {
-   if (!pcie_ports_native)
+   if (!pcie_ports_native && !pcie_ports_dpc_native)
host_bridge->native_dpc = 0;
else
dev_warn(>dev, "OS overrides %s firmware control",
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index daa9a4153776..5b1025a2994d 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -280,11 +280,12 @@ void pci_dpc_init(struct pci_dev *pdev)
 static int dpc_probe(struct pcie_device *dev)
 {
struct pci_dev *pdev = dev->port;
+   struct pci_host_bridge *host = pci_find_host_bridge(pdev->bus);
struct device *device = >device;
int status;
u16 ctl, cap;
 
-   if (!pcie_aer_is_native(pdev) && !pcie_ports_dpc_native)
+   if (!pcie_aer_is_native(pdev) && !host->native_dpc)
return -ENOTSUPP;
 
status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
index af7cf237432a..0ac20feef24e 100644
--- a/drivers/pci/pcie/portdrv.h
+++ b/drivers/pci/pcie/portdrv.h
@@ -25,8 +25,6 @@
 
 #define PCIE_PORT_DEVICE_MAXSERVICES   5
 
-extern bool pcie_ports_dpc_native;
-
 #ifdef CONFIG_PCIEAER
 int pcie_aer_init(void);
 int pcie_aer_is_native(struct pci_dev *dev);
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index ccd5e0ce5605..2c0278f0fdcc 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -253,7 +253,7 @@ static int get_port_device_capability(struct pci_dev *dev)
 */
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
pci_aer_available() &&
-   (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
+   (host->native_dpc || (services & PCIE_PORT_SERVICE_AER)))
services |= PCIE_PORT_SERVICE_DPC;
 
if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 34c1c4f45288..fe7ce06a4f40 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1556,9 +1556,11 @@ static inline int pci_irqd_intx_xlate(struct irq_domain 
*d,
 #ifdef CONFIG_PCIEPORTBUS
 extern bool pcie_ports_disabled;
 extern bool pcie_ports_native;
+extern bool pcie_ports_dpc_native;
 #else
 #define pcie_ports_disabledtrue
 #define pcie_ports_native  false
+#define pcie_ports_dpc_native  false
 #endif
 
 #define PCIE_LINK_STATE_L0SBIT(0)
-- 
2.17.1

[PATCH v7 1/5] PCI: Conditionally initialize host bridge native_* members

[sathyanarayanan . kuppuswamy]

From: Kuppuswamy Sathyanarayanan 

If CONFIG_PCIEPORTBUS is not enabled in kernel then initialing
struct pci_host_bridge PCIe specific native_* members to "1" is
incorrect. So protect the PCIe specific member initialization
with CONFIG_PCIEPORTBUS.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/pci/probe.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 2f66988cea25..a94b97564ceb 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -588,12 +588,14 @@ static void pci_init_host_bridge(struct pci_host_bridge 
*bridge)
 * may implement its own AER handling and use _OSC to prevent the
 * OS from interfering.
 */
+#ifdef CONFIG_PCIEPORTBUS
bridge->native_aer = 1;
bridge->native_pcie_hotplug = 1;
-   bridge->native_shpc_hotplug = 1;
bridge->native_pme = 1;
bridge->native_ltr = 1;
bridge->native_dpc = 1;
+#endif
+   bridge->native_shpc_hotplug = 1;
 
device_initialize(>dev);
 }
-- 
2.17.1

[PATCH v7 5/5] PCI/DPC: Move AER/DPC dependency checks out of DPC driver

[sathyanarayanan . kuppuswamy]

From: Kuppuswamy Sathyanarayanan 

Currently, AER and DPC Capabilities dependency checks is
distributed between DPC and portdrv service drivers. So move
them out of DPC driver.

Also, since services & PCIE_PORT_SERVICE_AER check already
ensures AER native ownership, no need to add additional
pcie_aer_is_native() check.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/pci/pcie/dpc.c  | 3 ---
 drivers/pci/pcie/portdrv_core.c | 1 +
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 5b1025a2994d..3efbe43764f3 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -285,9 +285,6 @@ static int dpc_probe(struct pcie_device *dev)
int status;
u16 ctl, cap;
 
-   if (!pcie_aer_is_native(pdev) && !host->native_dpc)
-   return -ENOTSUPP;
-
status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
   dpc_handler, IRQF_SHARED,
   "pcie-dpc", pdev);
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e257a2ca3595..ffa1d9fc458e 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -252,6 +252,7 @@ static int get_port_device_capability(struct pci_dev *dev)
 * permission to use AER.
 */
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
+   host->native_dpc &&
(host->native_dpc || (services & PCIE_PORT_SERVICE_AER)))
services |= PCIE_PORT_SERVICE_DPC;
 
-- 
2.17.1

[PATCH v7 2/5] ACPI/PCI: Ignore _OSC negotiation result if pcie_ports_native is set.

[sathyanarayanan . kuppuswamy]

From: Kuppuswamy Sathyanarayanan 

pcie_ports_native is set only if user requests native handling
of PCIe capabilities via pcie_port_setup command line option.
User input takes precedence over _OSC based control negotiation
result. So consider the _OSC negotiated result only if
pcie_ports_native is unset.

Also, since struct pci_host_bridge ->native_* members caches the
ownership status of various PCIe capabilities, use them instead
of distributed checks for pcie_ports_native.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/acpi/pci_root.c   | 62 ++-
 drivers/pci/hotplug/pciehp_core.c |  2 +-
 drivers/pci/pci-acpi.c|  3 --
 drivers/pci/pcie/aer.c|  2 +-
 drivers/pci/pcie/portdrv_core.c   |  9 ++---
 5 files changed, 57 insertions(+), 21 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index f90e841c59f5..a82069d064fe 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -145,6 +145,18 @@ static struct pci_osc_bit_struct pci_osc_control_bit[] = {
{ OSC_PCI_EXPRESS_DPC_CONTROL, "DPC" },
 };
 
+static char *get_osc_desc(u32 bit)
+{
+   int len = sizeof(pci_osc_control_bit) / sizeof(pci_osc_control_bit[0]);
+   int i = 0;
+
+   for (i = 0; i bridge);
-   if (!(root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL))
-   host_bridge->native_pcie_hotplug = 0;
+   if (!(root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL)) {
+   if (!pcie_ports_native)
+   host_bridge->native_pcie_hotplug = 0;
+   else
+   dev_warn(>dev, "OS overrides %s firmware control",
+   get_osc_desc(OSC_PCI_EXPRESS_NATIVE_HP_CONTROL));
+   }
+
if (!(root->osc_control_set & OSC_PCI_SHPC_NATIVE_HP_CONTROL))
host_bridge->native_shpc_hotplug = 0;
-   if (!(root->osc_control_set & OSC_PCI_EXPRESS_AER_CONTROL))
-   host_bridge->native_aer = 0;
-   if (!(root->osc_control_set & OSC_PCI_EXPRESS_PME_CONTROL))
-   host_bridge->native_pme = 0;
-   if (!(root->osc_control_set & OSC_PCI_EXPRESS_LTR_CONTROL))
-   host_bridge->native_ltr = 0;
-   if (!(root->osc_control_set & OSC_PCI_EXPRESS_DPC_CONTROL))
-   host_bridge->native_dpc = 0;
+
+   if (!(root->osc_control_set & OSC_PCI_EXPRESS_AER_CONTROL)) {
+   if (!pcie_ports_native)
+   host_bridge->native_aer = 0;
+   else
+   dev_warn(>dev, "OS overrides %s firmware control",
+   get_osc_desc(OSC_PCI_EXPRESS_AER_CONTROL));
+   }
+
+   if (!(root->osc_control_set & OSC_PCI_EXPRESS_PME_CONTROL)) {
+   if (!pcie_ports_native)
+   host_bridge->native_pme = 0;
+   else
+   dev_warn(>dev, "OS overrides %s firmware control",
+   get_osc_desc(OSC_PCI_EXPRESS_PME_CONTROL));
+   }
+
+   if (!(root->osc_control_set & OSC_PCI_EXPRESS_LTR_CONTROL)) {
+   if (!pcie_ports_native)
+   host_bridge->native_ltr = 0;
+   else
+   dev_warn(>dev, "OS overrides %s firmware control",
+   get_osc_desc(OSC_PCI_EXPRESS_LTR_CONTROL));
+   }
+
+   if (!(root->osc_control_set & OSC_PCI_EXPRESS_DPC_CONTROL)) {
+   if (!pcie_ports_native)
+   host_bridge->native_dpc = 0;
+   else
+   dev_warn(>dev, "OS overrides %s firmware control",
+   get_osc_desc(OSC_PCI_EXPRESS_DPC_CONTROL));
+   }
 
/*
 * Evaluate the "PCI Boot Configuration" _DSM Function.  If it
diff --git a/drivers/pci/hotplug/pciehp_core.c 
b/drivers/pci/hotplug/pciehp_core.c
index bf779f291f15..5fc999bf6f1b 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -255,7 +255,7 @@ static bool pme_is_native(struct pcie_device *dev)
const struct pci_host_bridge *host;
 
host = pci_find_host_bridge(dev->port->bus);
-   return pcie_ports_native || host->native_pme;
+   return host->native_pme;
 }
 
 static void pciehp_disable_interrupt(struct pcie_device *dev)
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 7224b1e5f2a8..e09589571a9d 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -800,9 +800,6 @@ bool pciehp_is_native(struct pci_dev *bridge)
if (!(slot_cap & PCI_EXP_SLTCAP_HPC))
return false;
 
-   if (pcie_ports_native)
-   return true;
-
host = pci_find_host_bridge(bridge->bus);
return host->native_pcie_hotplug;
 }
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 3acf56683915..d663bd9c7257 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -219,7 +219,7 @@ int 

[PATCH v7 4/5] PCI/portdrv: Remove redundant pci_aer_available() check in DPC enable logic

[sathyanarayanan . kuppuswamy]

From: Kuppuswamy Sathyanarayanan 

In DPC service enable logic, check for
services & PCIE_PORT_SERVICE_AER implies pci_aer_available()
is true. So there is no need to explicitly check it again.

Also, passing pcie_ports=dpc-native in kernel command line
implies DPC needs to be enabled in native mode irrespective
of AER ownership status. So checking for pci_aer_available()
without checking for pcie_ports status is incorrect.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/pci/pcie/portdrv_core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 2c0278f0fdcc..e257a2ca3595 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -252,7 +252,6 @@ static int get_port_device_capability(struct pci_dev *dev)
 * permission to use AER.
 */
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
-   pci_aer_available() &&
(host->native_dpc || (services & PCIE_PORT_SERVICE_AER)))
services |= PCIE_PORT_SERVICE_DPC;
 
-- 
2.17.1

[PATCH v7 0/5] Simplify PCIe native ownership detection logic

[sathyanarayanan . kuppuswamy]

From: Kuppuswamy Sathyanarayanan 

Currently, PCIe capabilities ownership status is detected by
verifying the status of pcie_ports_native, pcie_ports_dpc_native
and _OSC negotiated results (cached in  struct pci_host_bridge
->native_* members). But this logic can be simplified, and we can
use only struct pci_host_bridge ->native_* members to detect it. 

This patchset removes the distributed checks for pcie_ports_native,
pcie_ports_dpc_native parameters.

Changes since v6:
 * Created new patch for CONFIG_PCIEPORTBUS check in
   pci_init_host_bridge().
 * Added warning message for a case when pcie_ports_native
   overrides _OSC negotiation result.

Changes since v5:
 * Rebased on top of v5.8-rc1

Changes since v4:
 * Changed the patch set title (Original link: 
https://lkml.org/lkml/2020/5/26/1710)
 * Added AER/DPC dependency logic cleanup fixes.
 

Kuppuswamy Sathyanarayanan (5):
  PCI: Conditionally initialize host bridge native_* members
  ACPI/PCI: Ignore _OSC negotiation result if pcie_ports_native is set.
  ACPI/PCI: Ignore _OSC DPC negotiation result if pcie_ports_dpc_native
is set.
  PCI/portdrv: Remove redundant pci_aer_available() check in DPC enable
logic
  PCI/DPC: Move AER/DPC dependency checks out of DPC driver

 drivers/acpi/pci_root.c   | 62 ++-
 drivers/pci/hotplug/pciehp_core.c |  2 +-
 drivers/pci/pci-acpi.c|  3 --
 drivers/pci/pcie/aer.c|  2 +-
 drivers/pci/pcie/dpc.c|  4 +-
 drivers/pci/pcie/portdrv.h|  2 -
 drivers/pci/pcie/portdrv_core.c   | 13 +++
 drivers/pci/probe.c   |  4 +-
 include/linux/pci.h   |  2 +
 9 files changed, 65 insertions(+), 29 deletions(-)

-- 
2.17.1

Re: [PATCH] pwm: bcm-iproc: handle clk_get_rate() return

[Ray Jui]

On 7/17/2020 10:07 AM, Scott Branden wrote:
> From: Rayagonda Kokatanur 
> 
> Handle clk_get_rate() returning <= 0 condition to avoid
> possible division by zero.
> 
> Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller")
> Signed-off-by: Rayagonda Kokatanur 
> Signed-off-by: Scott Branden 
> ---
>  drivers/pwm/pwm-bcm-iproc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/pwm/pwm-bcm-iproc.c b/drivers/pwm/pwm-bcm-iproc.c
> index 1f829edd8ee7..72a8607b6c8d 100644
> --- a/drivers/pwm/pwm-bcm-iproc.c
> +++ b/drivers/pwm/pwm-bcm-iproc.c
> @@ -86,6 +86,11 @@ static void iproc_pwmc_get_state(struct pwm_chip *chip, 
> struct pwm_device *pwm,
>   u32 value, prescale;
>  
>   rate = clk_get_rate(ip->clk);
> + if (rate == 0) {
> + state->period = 0;
> + state->duty_cycle = 0;
> + return;
> + }

Based on the pwm core code, 'get_state' expects the following fields to
be populated: 'polarity', 'enabled', 'period', and 'duty cycle'.

The above logic will leave 'polarity' and 'enabled' completely
unpopulated when clock rate is zero.

>  
>   value = readl(ip->base + IPROC_PWM_CTRL_OFFSET);
>  
> 

Re: [PATCH v5] x86/speculation/l1tf: Add KConfig for setting the L1D cache flush mode

[Doug Anderson]

Hi,

On Fri, Jul 17, 2020 at 9:22 AM Thomas Gleixner  wrote:
>
> Doug,
>
> Doug Anderson  writes:
> > On Thu, Jul 9, 2020 at 3:51 AM Thomas Gleixner  wrote:
> >> TBH, I don't see why this is a good idea.
> >>
> >>  1) I'm not following your argumentation that the command line option is
> >> a poor Kconfig replacement. The L1TF mode is a boot time (module
> >> load time) decision and the command line parameter is there to
> >> override the carefully chosen and sensible default behaviour.
> >
> > When you say that the default behavior is carefully chosen and
> > sensible, are you saying that (in your opinion) there would never be a
> > good reason for someone distributing a kernel to others to change the
> > default?  Certainly I agree that having the kernel command line
> > parameter is nice to allow someone to override whatever the person
> > building the kernel chose, but IMO it's not a good way to change the
> > default built-in to the kernel.
>
> The problem is that you have to be careful about what you stick into
> Kconfig. It's L1TF on x86 today and tomorrow it's MDS and whatever and
> then you do the same thing on the other architectures as well. And we
> still need the command line options so that generic builds can be
> customized at boot time.
>
> > The current plan (as I understand it) is that we'd like to ship
> > Chromebook kernels with this option changed from the default that's
> > there now.  In your opinion, is that a sane thing to do?
>
> If it's sane for you folks, then feel free to do so. Distros & al patch
> the kernel do death anyway, but that does not mean that mainline has to
> have everything these people chose to do.

Sure, we could carry a local patch.  ...but Chrome OS tries not to be
like all other distros.  We try very hard (and keep trying harder each
year) to _not_ carry local patches.  Sure, we fail sometimes, but we
will still try.  In general it seems like the upstream Linux community
pushes distros and other Linux users to be upstream first so it's a
little discouraging to hear the advice of "just carry a local patch".

In this case, though, I should close the loop.  Abhishek can correct
me if I'm wrong, but I think the answer here was that it _wasn't_ sane
for us to change this option via KConfig or even via kernel command
line.  I believe that Abhishek found that it was better to (in
userspace) look at the sysfs nodes and configure things how he wanted
it at runtime.


> >>  2) You can add the desired mode to the compiled in (partial) kernel
> >> command line today.
> >
> > This might be easier on x86 than it is on ARM.  ARM (and ARM64)
> > kernels only have two modes: kernel provides cmdline and bootloader
> > provides cmdline.  There are out-of-mainline ANDROID patches to
> > address this but nothing in mainline.
> >
> > The patch we're discussing now is x86-only so it's not such a huge
> > deal, but the fact that combining the kernel and bootloader
> > commandline never landed in mainline for arm/arm64 means that this
> > isn't a super common/expected thing to do.
>
> Did you try to get that merged for arm/arm64?

Yes, years ago.  References:

https://lore.kernel.org/r/1326492948-26160-1-git-send-email-diand...@chromium.org
https://lore.kernel.org/r/1328223508-1228-1-git-send-email-diand...@chromium.org

I didn't keep poking it because I got advice (not on the mailing list)
that it was better to add a KConfig option rather than extending the
command line.  ;-)  At the time it seemed a reasonable argument to me
so I didn't keep pushing that patch.


> >>  3) Boot loaders are well capable of handling large kernel command lines
> >> and the extra time spend for reading the parameter does not matter
> >> at all.
> >
> > Long command lines can still be a bit of a chore for humans to deal
> > with.  Many times I've needed to look at "/proc/cmdline" and make
> > sense of it.  The longer the command line is and the more cruft
> > stuffed into it the more of a chore it is.  Yes, this is just one
> > thing to put in the command line, but if 10 different drivers all have
> > their "one thing" to put there it gets really long.  If 100 different
> > drivers all want their one config option there it gets really really
> > long.
>
> This will not go away when you want to support a gazillion of systems
> which need tweaks left and right due to creative hardware/BIOS with a
> generic kernel. And come on, parsing a long command line is not rocket
> science and it's not something you do every two minutes.

It's funny.  Your argument is the same as mine but the opposite.  I
say: "but so much crap will be in the command line and it will be
crazy" and you say "but so much crap will be in the KConfig and it
will be crazy".  ;-)  I guess it depends on where you want to dump
your trash.


> > IMO the command line should be a last resort place to put
> > things and should just contain:
> >
> > 1. Legacy things that _have_ to be in the command line because they've
> > 

Re: [RFC PATCH v3 00/18] Support for Tegra video capture from external sensor

[Sowjanya Komatineni]

On 7/17/20 10:08 AM, Hans Verkuil wrote:

On 17/07/2020 18:34, Sowjanya Komatineni wrote:

On 7/17/20 3:54 AM, Hans Verkuil wrote:

Hi Sowjanya,

On 15/07/2020 06:20, Sowjanya Komatineni wrote:

This series adds support for video capture from external camera sensor to
Tegra video driver.

Jetson TX1 has camera expansion connector and supports custom camera module
designed as per TX1 design specification.

This series also enables camera capture support for Jetson Nano which has
Raspberry PI camera header.

This series is tested with IMX219 camera sensor.

This series include,

VI I2C related fixes
- Camera sensor programming happens through VI I2C which is on host1x bus.
- These patches includes device tree and I2C driver fixes for VI I2C.

Tegra video driver updates
- TPG Vs Non-TPG based on Kconfig
- Support for external sensor video capture based on device graph from DT.
- Support for selection ioctl operations
- Tegra MIPI CSI pads calibration
- CSI T-CLK and T-HS settle time computation based on clock rates.

Host1x driver updates
- Adds API to allow creating mipi device for specific device node.
- Splits MIPI pads calibrate start and waiting for calibration to be done.

Device tree updates
- Adds camera connector 2V8, 1V8, 1V2 regulator supplies to Jetson TX1 DT.
- Enabled VI and CSI support in Jetson Nano DT.

I'm doing a bit of stress testing with:

while true; do v4l2-ctl --stream-mmap --stream-count=1; done

and I see that the imx274 has often streaming failures:

[  172.025144] IMX274 8-001a: s_stream failed
[  179.025192] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 3132 
= 870 (2 bytes)
[  179.033575] IMX274 8-001a: s_stream failed
[  226.525378] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 3130 
= 878 (2 bytes)
[  226.533761] IMX274 8-001a: s_stream failed
[  227.029325] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30f6 
= 107 (2 bytes)
[  227.037758] IMX274 8-001a: s_stream failed
[  247.025218] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30f6 
= 107 (2 bytes)
[  247.033658] IMX274 8-001a: s_stream failed
[  293.025517] IMX274 8-001a: s_stream failed
[  309.024727] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30e0 
= 0 (2 bytes)
[  309.032969] IMX274 8-001a: s_stream failed
[  309.529506] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30f8 
= 11d2 (3 bytes)
[  309.538103] IMX274 8-001a: imx274_set_frame_length error = -121
[  309.544102] IMX274 8-001a: imx274_set_frame_interval error = -121
[  309.550243] IMX274 8-001a: s_stream failed
[  314.025561] IMX274 8-001a: s_stream failed
[  329.025586] IMX274 8-001a: s_stream failed
[  340.529567] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 303a 
= f0c (2 bytes)
[  340.538009] IMX274 8-001a: s_stream failed
[  347.525627] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 30f6 
= 107 (2 bytes)
[  347.534008] IMX274 8-001a: s_stream failed
[  365.033640] IMX274 8-001a: s_stream failed
[  437.525788] IMX274 8-001a: imx274_write_mbreg : i2c bulk write failed, 3038 
= c (2 bytes)
[  437.533997] IMX274 8-001a: s_stream failed
[  456.029780] IMX274 8-001a: s_stream failed
[  472.025862] IMX274 8-001a: s_stream failed
[  498.025861] IMX274 8-001a: s_stream failed
[  500.025905] IMX274 8-001a: s_stream failed

where v4l2-ctl returns:

  VIDIOC_STREAMON returned -1 (Remote I/O error)

I don't see this with the imx219.

I also see this occasionally:

[Fri Jul 17 12:51:42 2020] video4linux video1: failed to run capture start 
kthread: -4

Something is not stable here.

Regards,

Hans

Hi Hans,

Running the same single frame continuous loop for more than 2 hours now
and I don't see any failure.

Above failure shows i2c bulk writes to IMX274 failure due to which
s_stream also failed.

Not sure if its due to i2c mux in the path to sensor on your module
causing some issue when there is more i2c write traffic as we are doing
single stream in continuous loop. Also IMX219 does not show on your side
so something specific to IMX274 setup probably.

I'll take a closer look next week. Good to know that it works fine for you.



Regarding kthread_run failure where kthread_run() returned -EINTR during
capture start thread, I always see this happen at the point of stopping
the continuous single stream while loop by pressing ctrl+c after few
loops of execution.

Hmm, if this is normal behavior, then should this message be a debug message
only? Or perhaps only show the message if the error code != EINTR.


I believe its good to still show this as its reported by kthread_run -> 
kthread_create_on_node.


But not sure in real usecase we will ever use while true like this and 
we should use script to also break while loop along with v4l2-ctl 
termination when ctrl-c terminate request happens.





Regards,

Hans


while true; do v4l2-ctl --stream-mmap --stream-count=1; done

when we stop loop with ctrl+c, v4l2-ctl terminates but loop does 

Re: [PATCH v5 03/15] iommu/smmu: Report empty domain nesting info

[Auger Eric]

Yi,

On 7/12/20 1:20 PM, Liu Yi L wrote:
> This patch is added as instead of returning a boolean for DOMAIN_ATTR_NESTING,
> iommu_domain_get_attr() should return an iommu_nesting_info handle.

you may add in the commit message you return an empty nesting info
struct for now as true nesting is not yet supported by the SMMUs.

Besides:
Reviewed-by: Eric Auger 

Thanks

Eric
> 
> Cc: Will Deacon 
> Cc: Robin Murphy 
> Cc: Eric Auger 
> Cc: Jean-Philippe Brucker 
> Suggested-by: Jean-Philippe Brucker 
> Signed-off-by: Liu Yi L 
> Signed-off-by: Jacob Pan 
> ---
> v4 -> v5:
> *) address comments from Eric Auger.
> ---
>  drivers/iommu/arm-smmu-v3.c | 29 +++--
>  drivers/iommu/arm-smmu.c| 29 +++--
>  2 files changed, 54 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index f578677..ec815d7 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -3019,6 +3019,32 @@ static struct iommu_group 
> *arm_smmu_device_group(struct device *dev)
>   return group;
>  }
>  
> +static int arm_smmu_domain_nesting_info(struct arm_smmu_domain *smmu_domain,
> + void *data)
> +{
> + struct iommu_nesting_info *info = (struct iommu_nesting_info *)data;
> + unsigned int size;
> +
> + if (!info || smmu_domain->stage != ARM_SMMU_DOMAIN_NESTED)
> + return -ENODEV;
> +
> + size = sizeof(struct iommu_nesting_info);
> +
> + /*
> +  * if provided buffer size is smaller than expected, should
> +  * return 0 and also the expected buffer size to caller.
> +  */
> + if (info->size < size) {
> + info->size = size;
> + return 0;
> + }
> +
> + /* report an empty iommu_nesting_info for now */
> + memset(info, 0x0, size);
> + info->size = size;
> + return 0;
> +}
> +
>  static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
>   enum iommu_attr attr, void *data)
>  {
> @@ -3028,8 +3054,7 @@ static int arm_smmu_domain_get_attr(struct iommu_domain 
> *domain,
>   case IOMMU_DOMAIN_UNMANAGED:
>   switch (attr) {
>   case DOMAIN_ATTR_NESTING:
> - *(int *)data = (smmu_domain->stage == 
> ARM_SMMU_DOMAIN_NESTED);
> - return 0;
> + return arm_smmu_domain_nesting_info(smmu_domain, data);
>   default:
>   return -ENODEV;
>   }
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 243bc4c..09e2f1b 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1506,6 +1506,32 @@ static struct iommu_group 
> *arm_smmu_device_group(struct device *dev)
>   return group;
>  }
>  
> +static int arm_smmu_domain_nesting_info(struct arm_smmu_domain *smmu_domain,
> + void *data)
> +{
> + struct iommu_nesting_info *info = (struct iommu_nesting_info *)data;
> + unsigned int size;
> +
> + if (!info || smmu_domain->stage != ARM_SMMU_DOMAIN_NESTED)
> + return -ENODEV;
> +
> + size = sizeof(struct iommu_nesting_info);
> +
> + /*
> +  * if provided buffer size is smaller than expected, should
> +  * return 0 and also the expected buffer size to caller.
> +  */
> + if (info->size < size) {
> + info->size = size;
> + return 0;
> + }
> +
> + /* report an empty iommu_nesting_info for now */
> + memset(info, 0x0, size);
> + info->size = size;
> + return 0;
> +}
> +
>  static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
>   enum iommu_attr attr, void *data)
>  {
> @@ -1515,8 +1541,7 @@ static int arm_smmu_domain_get_attr(struct iommu_domain 
> *domain,
>   case IOMMU_DOMAIN_UNMANAGED:
>   switch (attr) {
>   case DOMAIN_ATTR_NESTING:
> - *(int *)data = (smmu_domain->stage == 
> ARM_SMMU_DOMAIN_NESTED);
> - return 0;
> + return arm_smmu_domain_nesting_info(smmu_domain, data);
>   default:
>   return -ENODEV;
>   }
>