Re: [PATCH tip/core/rcu 14/15] rcu/tree: Allocate a page when caller is preemptible

[Michal Hocko]

On Thu 01-10-20 09:27:09, Paul E. McKenney wrote:
[...]
> commit ea5c19d21233b5e8d3d06c0d4ecd6be9f2829dc3
> Author: Paul E. McKenney 
> Date:   Thu Oct 1 09:24:40 2020 -0700
> 
> kvfree_rcu: Use __GFP_NOMEMALLOC for single-argument kvfree_rcu()
> 
> This commit applies the __GFP_NOMEMALLOC gfp flag to memory allocations
> carried out by the single-argument variant of kvfree_rcu(), thus avoiding
> this can-sleep code path from dipping into the emergency reserves.
> 
> Suggested-by: Michal Hocko 
> Signed-off-by: Paul E. McKenney 

LGTM. At least for this one I feel competent to give you
Acked-by: Michal Hocko 

> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 242f0f0..6132452 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -3364,7 +3364,8 @@ add_ptr_to_bulk_krc_lock(struct kfree_rcu_cpu **krcp,
>  {
>   struct kvfree_rcu_bulk_data *bnode;
>   bool can_alloc_page = preemptible();
> - gfp_t gfp = (can_sleep ? GFP_KERNEL | __GFP_RETRY_MAYFAIL : GFP_ATOMIC) 
> | __GFP_NOWARN;
> + gfp_t gfp = (can_sleep ? GFP_KERNEL | __GFP_RETRY_MAYFAIL | 
> __GFP_NOMEMALLOC
> +: GFP_ATOMIC) | __GFP_NOWARN;
>   int idx;
>  
>   *krcp = krc_this_cpu_lock(flags);

-- 
Michal Hocko
SUSE Labs

Re: [GIT PULL][PATCH v4 0/9] Update to zstd-1.4.6

[Christoph Hellwig]

On Thu, Oct 01, 2020 at 06:35:34PM +, Nick Terrell wrote:
> I???m open to suggestions on how to get a zstd update done better. I don???t
> know of any way to break this patch up into smaller patches that all compile.
> The code is all generated directly from upstream and modified to work in the
> kernel by automated scripts.

Documentation/process/submitting-patches.rst:


"Separate your changes
-

Separate each **logical change** into a separate patch.

For example, if your changes include both bug fixes and performance
enhancements for a single driver, separate those changes into two
or more patches.  If your changes include an API update, and a new
driver which uses that new API, separate those into two patches."

It's not that hard, is it?  Please do your very basic homework instead
of pretending to be a special snowflake and then come back.

Re: get_cycles from modular code in jitterentropy, was Re: [PATCH] clocksource: clint: Export clint_time_val for modules

[Stephan Mueller]

Am Freitag, 2. Oktober 2020, 08:49:05 CEST schrieb Christoph Hellwig:

Hi Christoph,

> On Tue, Sep 29, 2020 at 11:56:18PM -0700, Palmer Dabbelt wrote:
> > clint_time_val will soon be used by the RISC-V implementation of
> > random_get_entropy(), which is a static inline function that may be used
> > by
> > modules (at least CRYPTO_JITTERENTROPY=m).
> 
> At very least this needs to be an EXPORT_SYMBOL_GPL.  But I really don't
> think modules have any business using get_cycles, so I'd much rather
> fix CRYPTO_JITTERENTROPY to be required to be build in.

Changing CRYPTO_JITTERENTROPY from tistate to bool should be no problem.

I will provide a patch.

Ciao
Stephan

Re: [PATCH v4 0/9] Update to zstd-1.4.6

[Christoph Hellwig]

On Wed, Sep 30, 2020 at 08:05:45PM +, Nick Terrell wrote:
> 
> 
> > On Sep 29, 2020, at 11:53 PM, Christoph Hellwig  wrote:
> > 
> > As you keep resend this I keep retelling you that should not do it.
> > Please provide a proper Linux API, and switch to that.  Versioned APIs
> > have absolutely no business in the Linux kernel.
> 
> The API is not versioned. We provide a stable ABI for a large section of our 
> API,
> and the parts that aren???t ABI stable don???t change in semantics, and 
> undergo long
> deprecation periods before being removed.
> 
> The change of callers is a one-time change to transition from the existing API
> in the kernel, which was never upstream's API, to upstream's API.

Again, please transition it to a sane kernel API.  We don't have an
"upstream" in this case.

Re: [PATCH v4 00/52] Fix html build with Sphinx 3.1 and above

[Mauro Carvalho Chehab]

Em Thu, 1 Oct 2020 15:48:54 -0600
Jonathan Corbet  escreveu:

> On Wed, 30 Sep 2020 15:24:23 +0200
> Mauro Carvalho Chehab  wrote:
> 
> > This series add proper support for Sphinx 3.1 and above for building the 
> > html docs.
> > 
> > This series comes after the one I wrote fixing the warnings. 
> > 
> > With this series applied on the top of next-20200922, there are just 12
> > warnings:
> > - 2 of them happens also on Sphinx 2.4.4
> >  (both seem easy to fix: I'll send later fixes for those);
> > - 10 happens only on Sphinx 3.2.1.
> > 
> > The new warnings are all due to duplicated C domain cross-reference 
> > symbols. 
> > 
> > Basically, the C domain on Sphinx doesn't allow to have an struct and
> > a function with the same name. I opened an issue on Sphinx.:
> > 
> > https://github.com/sphinx-doc/sphinx/issues/8241
> > 
> > Hopefully, some newer version may have it fixed.
> > 
> > There is still one thing that requires a fix: the automarkup.py. The
> > way cross-references are stored with Sphinx 3 are different.
> > I didn't try yet to address it, but I suspect that it shouldn't be
> > hard to address it.  
> 
> Modulo my comment on part 4, I think this is what we want.  It's kind of
> unfortunate that it's all necessary, but that's the way things are these
> days, I guess.

Yes, it is unfortunate. Yet, my feeling is that this approach provides
us a good way to transition to the new C domain parser, which has some
advantages over the older code.

> This part is a bit intimidating, though:
> 
> >  288 files changed, 1709 insertions(+), 2183 deletions(-)  

Yes. Yet, the media userspace API is responsible for most of it:

 224 files changed, 1076 insertions(+), 1716 deletions(-)

As most of the uAPI documentation doesn't rely on kernel-doc
(mostly due to historic reasons).

To be fair, most of the other changes outside the building system
are due to already-existing issues at the documentation. There are
several kernel-doc tags creating duplicated C references.

While Sphinx < 3 C domain parser were able to detect them, such
warnings are disabled by default.

> Should we maybe position this as an end-of-merge-window blast, once other
> stuff has hopefully mostly settled?  I can certainly warn Linus that it's
> coming when I send the main docs pull.

Yeah, adding this series, together with the remaining patches fixing
all warnings with Sphinx < 3 at the end of the merge window seems
the right thing to do, IMO.

> I wonder how soon we could pull our minimum version forward to 3.1 and
> drop a bunch of stuff?  I fear it may not be for a while, alas...

I guess it may take some time. In any case, for the next minimal
version, I would set for the upcoming one that will fix those
issue reported here:

https://github.com/sphinx-doc/sphinx/issues/7819
https://github.com/sphinx-doc/sphinx/issues/8241

One such example is this warning:

.../Documentation/driver-api/miscellaneous:48: 
../drivers/pwm/core.c:669: WARNING: Duplicate C declaration, also defined in 
'driver-api/miscellaneous'.
Declaration is 'int pwm_capture (struct pwm_device *pwm, struct 
pwm_capture *result, unsigned long timeout)'.

(See: we have a function pwm_capture and a struct with the
 same name. Both have kernel-doc tags at drivers/pwm/core.c)

Without fixing it, there's no way to produce a zero-warning
docs building[1] with Sphinx versions above 2.4.x.

[1] Well, it could be possible to rename such kAPI symbols to
make Sphinx happy, but IMO, the C domain there should be able
to fully support the C language.

> Thanks for doing all this work,

Anytime.

Thanks,
Mauro

Re: linux-next: Tree for Oct 1 (drivers/mfd/simple-mfd-i2c.o)

[Lee Jones]

On Thu, 01 Oct 2020, Randy Dunlap wrote:

> On 10/1/20 11:32 PM, Lee Jones wrote:
> > On Thu, 01 Oct 2020, Randy Dunlap wrote:
> > 
> >> On 10/1/20 4:39 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20200930:
> >>>
> >>
> >> on x86_64:
> >>
> >> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_probe':
> >> simple-mfd-i2c.c:(.text+0x48): undefined reference to 
> >> `__devm_regmap_init_i2c'
> >> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_driver_init':
> >> simple-mfd-i2c.c:(.init.text+0x14): undefined reference to 
> >> `i2c_register_driver'
> >> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_driver_exit':
> >> simple-mfd-i2c.c:(.exit.text+0xd): undefined reference to `i2c_del_driver'
> >>
> >>
> >> CONFIG_I2C=m
> >> CONFIG_MFD_SIMPLE_MFD_I2C=y
> >> CONFIG_MFD_SL28CPLD=y
> >>
> >>
> >> Is linux-next missing the source code for CONFIG_MFD_SL28CPLD?
> > 
> > There isn't any associated source code.  It's a virtual symbol.
> > 
> >> The build error is caused by:
> >>
> >> config MFD_SL28CPLD
> >>tristate "Kontron sl28cpld Board Management Controller"
> >>select MFD_SIMPLE_MFD_I2C
> >>
> >> that "select" when "depends on I2C" is absent/missing.
> > 
> > Okay, so CONFIG_MFD_SIMPLE_MFD_I2C needs to depend on I2C too?  I made
> > the assumption that 'select REGMAP_I2C' would do the right thing.
> 
> "select" never follows any dependency chains, so Yes, the other symbol
> needs to depend on I2C also.

Makes sense.  Will fix, thanks.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 2/2] PM/hibernate: remove the bogus call to get_gendisk in software_resume

[Christoph Hellwig]

On Wed, Sep 30, 2020 at 05:45:27PM +0200, Rafael J. Wysocki wrote:
> On Fri, Sep 25, 2020 at 6:15 PM Christoph Hellwig  wrote:
> >
> > get_gendisk grabs a reference on the disk and file operation, so this
> > code will leak both of them while having absolutely no use for the
> > gendisk itself.
> >
> > This effectively reverts commit 2df83fa4bce421f
> > ("PM / Hibernate: Use get_gendisk to verify partition if resume_file is 
> > integer format")
> >
> > Signed-off-by: Christoph Hellwig 
> 
> Acked-by: Rafael J. Wysocki 

Can you pick it up through the PM tree?  The big rework in this area
I have planned won't land before 5.11 anyway.

get_cycles from modular code in jitterentropy, was Re: [PATCH] clocksource: clint: Export clint_time_val for modules

[Christoph Hellwig]

On Tue, Sep 29, 2020 at 11:56:18PM -0700, Palmer Dabbelt wrote:
> clint_time_val will soon be used by the RISC-V implementation of
> random_get_entropy(), which is a static inline function that may be used by
> modules (at least CRYPTO_JITTERENTROPY=m).

At very least this needs to be an EXPORT_SYMBOL_GPL.  But I really don't
think modules have any business using get_cycles, so I'd much rather
fix CRYPTO_JITTERENTROPY to be required to be build in.

> 
> Reported-by: kernel test robot 
> Signed-off-by: Palmer Dabbelt 
> ---
>  drivers/clocksource/timer-clint.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clocksource/timer-clint.c 
> b/drivers/clocksource/timer-clint.c
> index d17367dee02c..6cfe2ab73eb0 100644
> --- a/drivers/clocksource/timer-clint.c
> +++ b/drivers/clocksource/timer-clint.c
> @@ -38,6 +38,7 @@ static unsigned int clint_timer_irq;
>  
>  #ifdef CONFIG_RISCV_M_MODE
>  u64 __iomem *clint_time_val;
> +EXPORT_SYMBOL(clint_time_val);
>  #endif
>  
>  static void clint_send_ipi(const struct cpumask *target)
> -- 
> 2.28.0.709.gb0816b6eb0-goog
> 
> 
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
---end quoted text---

Re: [PATCH v4 03/11] arm64, kfence: enable KFENCE for ARM64

[Jann Horn]

On Tue, Sep 29, 2020 at 3:38 PM Marco Elver  wrote:
> Add architecture specific implementation details for KFENCE and enable
> KFENCE for the arm64 architecture. In particular, this implements the
> required interface in . Currently, the arm64 version does
> not yet use a statically allocated memory pool, at the cost of a pointer
> load for each is_kfence_address().
[...]
> diff --git a/arch/arm64/include/asm/kfence.h b/arch/arm64/include/asm/kfence.h
[...]
> +static inline bool arch_kfence_initialize_pool(void)
> +{
> +   const unsigned int num_pages = 
> ilog2(roundup_pow_of_two(KFENCE_POOL_SIZE / PAGE_SIZE));
> +   struct page *pages = alloc_pages(GFP_KERNEL, num_pages);
> +
> +   if (!pages)
> +   return false;
> +
> +   __kfence_pool = page_address(pages);
> +   return true;
> +}

If you're going to do "virt_to_page(meta->addr)->slab_cache = cache;"
on these pages in kfence_guarded_alloc(), and pass them into kfree(),
you'd better mark these pages as non-compound - something like
alloc_pages_exact() or split_page() may help. Otherwise, I think when
SLUB's kfree() does virt_to_head_page() right at the start, that will
return a pointer to the first page of the entire __kfence_pool, and
then when it loads page->slab_cache, it gets some random cache and
stuff blows up. Kinda surprising that you haven't run into that during
your testing, maybe I'm missing something...

Also, this kinda feels like it should be the "generic" version of
arch_kfence_initialize_pool() and live in mm/kfence/core.c ?

[PATCH] selftests/vm: fix: make check_config.sh executable

[John Hubbard]

commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency") created the new check_config.sh file without the execute
bits set. This is a problem because the Makefile runs it with "./", so
now "make" is failing in that directory.

The posted patch [1] does seem to have it as an executable file, so I'm
not sure how this happened. But in any case, make check_config.sh
executable again, so that "make" in selftests/vm works once again.

[1] 
https://lore.kernel.org/linux-doc/20200929212747.251804-9-jhubb...@nvidia.com/

Fixes: commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs 
dependency")
Signed-off-by: John Hubbard 
---

Hi,

This applies to today's 20201001) linux-next. I forgot if this needs to
be a separate patch or if it can be fixed up in Andrew's tree.

thanks,
John Hubbard
NVIDIA


 tools/testing/selftests/vm/check_config.sh | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 tools/testing/selftests/vm/check_config.sh

diff --git a/tools/testing/selftests/vm/check_config.sh 
b/tools/testing/selftests/vm/check_config.sh
old mode 100644
new mode 100755
-- 
2.28.0

Re: [PATCH blk-next 1/2] blk-mq-rdma: Delete not-used multi-queue RDMA map queue code

[Christoph Hellwig]

On Tue, Sep 29, 2020 at 11:24:49AM -0700, Sagi Grimberg wrote:
> Yes, basically usage of managed affinity caused people to report
> regressions not being able to change irq affinity from procfs.

Well, why would they change it?  The whole point of the infrastructure
is that there is a single sane affinity setting for a given setup. Now
that setting needed some refinement from the original series (e.g. the
current series about only using housekeeping cpus if cpu isolation is
in use).  But allowing random users to modify affinity is just a receipe
for a trainwreck.

So I think we need to bring this back ASAP, as doing affinity right
out of the box is an absolute requirement for sane performance without
all the benchmarketing deep magic.

Re: [PATCH][next] crypto: sun8i-ss@: fix memory leak on pointer d

[Herbert Xu]

On Tue, Sep 29, 2020 at 02:38:19PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Currently the error return path on a failed dma_mapping_error call
> is not kfree'ing memory allocated to d. Add an extra error exit label
> to end of the function where the kfree and return occurs to fix this
> issue.
> 
> Addresses-Coverity: ("Resource leak")
> Fixes: ac2614d721de ("crypto: sun8i-ss - Add support for the PRNG")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

This patch is already in the queue:

https://patchwork.kernel.org/patch/11804435/

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/5] Speed up mremap on large regions

[Lokesh Gidra]

On Thu, Oct 1, 2020 at 10:36 PM Kirill A. Shutemov
 wrote:
>
> On Thu, Oct 01, 2020 at 05:09:02PM -0700, Lokesh Gidra wrote:
> > On Thu, Oct 1, 2020 at 9:00 AM Kalesh Singh  wrote:
> > >
> > > On Thu, Oct 1, 2020 at 8:27 AM Kirill A. Shutemov
> > >  wrote:
> > > >
> > > > On Wed, Sep 30, 2020 at 03:42:17PM -0700, Lokesh Gidra wrote:
> > > > > On Wed, Sep 30, 2020 at 3:32 PM Kirill A. Shutemov
> > > > >  wrote:
> > > > > >
> > > > > > On Wed, Sep 30, 2020 at 10:21:17PM +, Kalesh Singh wrote:
> > > > > > > mremap time can be optimized by moving entries at the PMD/PUD 
> > > > > > > level if
> > > > > > > the source and destination addresses are PMD/PUD-aligned and
> > > > > > > PMD/PUD-sized. Enable moving at the PMD and PUD levels on arm64 
> > > > > > > and
> > > > > > > x86. Other architectures where this type of move is supported and 
> > > > > > > known to
> > > > > > > be safe can also opt-in to these optimizations by enabling 
> > > > > > > HAVE_MOVE_PMD
> > > > > > > and HAVE_MOVE_PUD.
> > > > > > >
> > > > > > > Observed Performance Improvements for remapping a PUD-aligned 
> > > > > > > 1GB-sized
> > > > > > > region on x86 and arm64:
> > > > > > >
> > > > > > > - HAVE_MOVE_PMD is already enabled on x86 : N/A
> > > > > > > - Enabling HAVE_MOVE_PUD on x86   : ~13x speed up
> > > > > > >
> > > > > > > - Enabling HAVE_MOVE_PMD on arm64 : ~ 8x speed up
> > > > > > > - Enabling HAVE_MOVE_PUD on arm64 : ~19x speed up
> > > > > > >
> > > > > > >   Altogether, HAVE_MOVE_PMD and HAVE_MOVE_PUD
> > > > > > >   give a total of ~150x speed up on arm64.
> > > > > >
> > > > > > Is there a *real* workload that benefit from HAVE_MOVE_PUD?
> > > > > >
> > > > > We have a Java garbage collector under development which requires
> > > > > moving physical pages of multi-gigabyte heap using mremap. During this
> > > > > move, the application threads have to be paused for correctness. It is
> > > > > critical to keep this pause as short as possible to avoid jitters
> > > > > during user interaction. This is where HAVE_MOVE_PUD will greatly
> > > > > help.
> > > >
> > > > Any chance to quantify the effect of mremap() with and without
> > > > HAVE_MOVE_PUD?
> > > >
> > > > I doubt it's a major contributor to the GC pause. I expect you need to
> > > > move tens of gigs to get sizable effect. And if your GC routinely moves
> > > > tens of gigs, maybe problem somewhere else?
> > > >
> > > > I'm asking for numbers, because increase in complexity comes with cost.
> > > > If it doesn't provide an substantial benefit to a real workload
> > > > maintaining the code forever doesn't make sense.
> > >
> > mremap is indeed the biggest contributor to the GC pause. It has to
> > take place in what is typically known as a 'stop-the-world' pause,
> > wherein all application threads are paused. During this pause the GC
> > thread flips the GC roots (threads' stacks, globals etc.), and then
> > resumes threads along with concurrent compaction of the heap.This
> > GC-root flip differs depending on which compaction algorithm is being
> > used.
> >
> > In our case it involves updating object references in threads' stacks
> > and remapping java heap to a different location. The threads' stacks
> > can be handled in parallel with the mremap. Therefore, the dominant
> > factor is indeed the cost of mremap. From patches 2 and 4, it is clear
> > that remapping 1GB without this optimization will take ~9ms on arm64.
> >
> > Although this mremap has to happen only once every GC cycle, and the
> > typical size is also not going to be more than a GB or 2, pausing
> > application threads for ~9ms is guaranteed to cause jitters. OTOH,
> > with this optimization, mremap is reduced to ~60us, which is a totally
> > acceptable pause time.
> >
> > Unfortunately, implementation of the new GC algorithm hasn't yet
> > reached the point where I can quantify the effect of this
> > optimization. But I can confirm that without this optimization the new
> > GC will not be approved.
>
> IIUC, the 9ms -> 90us improvement attributed to combination HAVE_MOVE_PMD
> and HAVE_MOVE_PUD, right? I expect HAVE_MOVE_PMD to be reasonable for some
> workloads, but marginal benefit of HAVE_MOVE_PUD is in doubt. Do you see
> it's useful for your workload?
>
Yes, 9ms -> 90us is when both are combined. The past experience has
been that even ~1ms long stop-the-world pause is prone to cause
jitters. HAVE_MOVE_PMD takes us only this far. So HAVE_MOVE_PUD is
required to bring the mremap cost to acceptable level.

Ideally, I was hoping that the functionality of HAVE_MOVE_PMD can be
extended to all levels of the hierarchical page table, and in the
process simplify the implementation. But unfortunately, that doesn't
seem to be possible from patch 3.

> --
>  Kirill A. Shutemov

Re: linux-next: Tree for Oct 1 (drivers/mfd/simple-mfd-i2c.o)

[Randy Dunlap]

On 10/1/20 11:32 PM, Lee Jones wrote:
> On Thu, 01 Oct 2020, Randy Dunlap wrote:
> 
>> On 10/1/20 4:39 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20200930:
>>>
>>
>> on x86_64:
>>
>> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_probe':
>> simple-mfd-i2c.c:(.text+0x48): undefined reference to 
>> `__devm_regmap_init_i2c'
>> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_driver_init':
>> simple-mfd-i2c.c:(.init.text+0x14): undefined reference to 
>> `i2c_register_driver'
>> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_driver_exit':
>> simple-mfd-i2c.c:(.exit.text+0xd): undefined reference to `i2c_del_driver'
>>
>>
>> CONFIG_I2C=m
>> CONFIG_MFD_SIMPLE_MFD_I2C=y
>> CONFIG_MFD_SL28CPLD=y
>>
>>
>> Is linux-next missing the source code for CONFIG_MFD_SL28CPLD?
> 
> There isn't any associated source code.  It's a virtual symbol.
> 
>> The build error is caused by:
>>
>> config MFD_SL28CPLD
>>  tristate "Kontron sl28cpld Board Management Controller"
>>  select MFD_SIMPLE_MFD_I2C
>>
>> that "select" when "depends on I2C" is absent/missing.
> 
> Okay, so CONFIG_MFD_SIMPLE_MFD_I2C needs to depend on I2C too?  I made
> the assumption that 'select REGMAP_I2C' would do the right thing.

"select" never follows any dependency chains, so Yes, the other symbol
needs to depend on I2C also.


thanks.
-- 
~Randy

[PATCH v2] scsi: ufs: fix missing brace warning for old compilers

[Pujin Shi]

For older versions of gcc, the array = {0}; will cause warnings:

drivers/scsi/ufs/ufshcd-crypto.c: In function 'ufshcd_crypto_keyslot_program':
drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: missing braces around 
initializer [-Wmissing-braces]
  union ufs_crypto_cfg_entry cfg = { 0 };
^
drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: (near initialization for 
'cfg.reg_val') [-Wmissing-braces]
drivers/scsi/ufs/ufshcd-crypto.c: In function 'ufshcd_clear_keyslot':
drivers/scsi/ufs/ufshcd-crypto.c:103:8: warning: missing braces around 
initializer [-Wmissing-braces]
  union ufs_crypto_cfg_entry cfg = { 0 };
^
2 warnings generated

Fixes: 70297a8ac7a7 ("scsi: ufs: UFS crypto API")
Signed-off-by: Pujin Shi 
---
 drivers/scsi/ufs/ufshcd-crypto.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
index d2edbd960ebf..07310b12a5dc 100644
--- a/drivers/scsi/ufs/ufshcd-crypto.c
+++ b/drivers/scsi/ufs/ufshcd-crypto.c
@@ -59,7 +59,7 @@ static int ufshcd_crypto_keyslot_program(struct 
blk_keyslot_manager *ksm,
u8 data_unit_mask = key->crypto_cfg.data_unit_size / 512;
int i;
int cap_idx = -1;
-   union ufs_crypto_cfg_entry cfg = { 0 };
+   union ufs_crypto_cfg_entry cfg = {};
int err;
 
BUILD_BUG_ON(UFS_CRYPTO_KEY_SIZE_INVALID != 0);
@@ -100,7 +100,7 @@ static int ufshcd_clear_keyslot(struct ufs_hba *hba, int 
slot)
 * Clear the crypto cfg on the device. Clearing CFGE
 * might not be sufficient, so just clear the entire cfg.
 */
-   union ufs_crypto_cfg_entry cfg = { 0 };
+   union ufs_crypto_cfg_entry cfg = {};
 
return ufshcd_program_key(hba, &cfg, slot);
 }
-- 
2.18.1

[tip:x86/platform] BUILD SUCCESS a0947081af2ac9549e6ba19877456730713bde23

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/platform
branch HEAD: a0947081af2ac9549e6ba19877456730713bde23  x86/uv/time: Use a 
flexible array in struct uv_rtc_timer_head

elapsed time: 722m

configs tested: 115
configs skipped: 62

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
sh  landisk_defconfig
sh sh03_defconfig
arm64alldefconfig
powerpc mpc832x_mds_defconfig
powerpc rainier_defconfig
m68kmvme147_defconfig
m68k  hp300_defconfig
arm  gemini_defconfig
arc  axs103_smp_defconfig
csky alldefconfig
shshmin_defconfig
powerpccell_defconfig
arm   efm32_defconfig
arm   milbeaut_m10v_defconfig
h8300alldefconfig
arm   viper_defconfig
i386 alldefconfig
parisc  defconfig
powerpcklondike_defconfig
xtensa  defconfig
sh   rts7751r2dplus_defconfig
powerpc mpc85xx_cds_defconfig
h8300 edosk2674_defconfig
sh  defconfig
arm   omap1_defconfig
mips   sb1250_swarm_defconfig
nios2   defconfig
riscvalldefconfig
arm palmz72_defconfig
xtensa  audio_kc705_defconfig
powerpc ksi8560_defconfig
shsh7785lcr_defconfig
powerpc mpc8313_rdb_defconfig
powerpcmvme5100_defconfig
powerpc  ppc6xx_defconfig
s390 alldefconfig
arm  pxa910_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a003-20200930
i386 randconfig-a002-20200930
i386 randconfig-a006-20200930
i386 randconfig-a005-20200930
i386 randconfig-a004-20200930
i386 randconfig-a001-20200930
x86_64   randconfig-a015-20200930
x86_64   randconfig-a013-20200930
x86_64   randconfig-a012-20200930
x86_64   randconfig-a016-20200930
x86_64   randconfig-a014-20200930
x86_64   randconfig-a011-20200930
i386 randconfig-a011-20200930
i386 randconfig-a015-20200930
i386 randconfig-a012-20200930
i386 randconfig-a014-20200930
i386 randconfig-a016-20200930
i386 randconfig-a013-20200930
i386 randconfig-a014-20201001
i386 randconfig-a015-20201001
i386 randconfig-a013-20201001
i386 randconfig-a016-20201001
i386 randconfig-a011-20201001
i386 randconfig-a012-20201001
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv

Re: [PATCH v4 01/11] mm: add Kernel Electric-Fence infrastructure

[Jann Horn]

On Tue, Sep 29, 2020 at 3:38 PM Marco Elver  wrote:
> This adds the Kernel Electric-Fence (KFENCE) infrastructure. KFENCE is a
> low-overhead sampling-based memory safety error detector of heap
> use-after-free, invalid-free, and out-of-bounds access errors.
>
> KFENCE is designed to be enabled in production kernels, and has near
> zero performance overhead. Compared to KASAN, KFENCE trades performance
> for precision. The main motivation behind KFENCE's design, is that with
> enough total uptime KFENCE will detect bugs in code paths not typically
> exercised by non-production test workloads. One way to quickly achieve a
> large enough total uptime is when the tool is deployed across a large
> fleet of machines.
>
> KFENCE objects each reside on a dedicated page, at either the left or
> right page boundaries.

(modulo slab alignment)

> The pages to the left and right of the object
> page are "guard pages", whose attributes are changed to a protected
> state, and cause page faults on any attempted access to them. Such page
> faults are then intercepted by KFENCE, which handles the fault
> gracefully by reporting a memory access error. To detect out-of-bounds
> writes to memory within the object's page itself, KFENCE also uses
> pattern-based redzones. The following figure illustrates the page
> layout:
[...]
> diff --git a/include/linux/kfence.h b/include/linux/kfence.h
[...]
> +/**
> + * is_kfence_address() - check if an address belongs to KFENCE pool
> + * @addr: address to check
> + *
> + * Return: true or false depending on whether the address is within the 
> KFENCE
> + * object range.
> + *
> + * KFENCE objects live in a separate page range and are not to be intermixed
> + * with regular heap objects (e.g. KFENCE objects must never be added to the
> + * allocator freelists). Failing to do so may and will result in heap
> + * corruptions, therefore is_kfence_address() must be used to check whether
> + * an object requires specific handling.
> + */
> +static __always_inline bool is_kfence_address(const void *addr)
> +{
> +   return unlikely((char *)addr >= __kfence_pool &&
> +   (char *)addr < __kfence_pool + KFENCE_POOL_SIZE);
> +}

If !CONFIG_HAVE_ARCH_KFENCE_STATIC_POOL, this should probably always
return false if __kfence_pool is NULL, right?

[...]
> diff --git a/lib/Kconfig.kfence b/lib/Kconfig.kfence
[...]
> +menuconfig KFENCE
> +   bool "KFENCE: low-overhead sampling-based memory safety error 
> detector"
> +   depends on HAVE_ARCH_KFENCE && !KASAN && (SLAB || SLUB)
> +   depends on JUMP_LABEL # To ensure performance, require jump labels
> +   select STACKTRACE
> +   help
> + KFENCE is low-overhead sampling-based detector for heap 
> out-of-bounds

nit: "is a"

> + access, use-after-free, and invalid-free errors. KFENCE is designed
> + to have negligible cost to permit enabling it in production
> + environments.
[...]
> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
[...]
> +module_param_named(sample_interval, kfence_sample_interval, ulong, 0600);

This is a writable module parameter, but if the sample interval was 0
or a very large value, changing this value at runtime won't actually
change the effective interval because the work item will never get
kicked off again, right?

Should this maybe use module_param_cb() instead, with a "set" callback
that not only changes the value, but also schedules the work item?

[...]
> +/*
> + * The pool of pages used for guard pages and objects. If supported, 
> allocated
> + * statically, so that is_kfence_address() avoids a pointer load, and simply
> + * compares against a constant address. Assume that if KFENCE is compiled 
> into
> + * the kernel, it is usually enabled, and the space is to be allocated one 
> way
> + * or another.
> + */

If this actually brings a performance win, the proper way to do this
would probably be to implement this as generic kernel infrastructure
that makes the compiler emit large-offset relocations (either through
compiler support or using inline asm statements that move an immediate
into a register output and register the location in a special section,
kinda like how e.g. static keys work) and patches them at boot time,
or something like that - there are other places in the kernel where
very hot code uses global pointers that are only ever written once
during boot, e.g. the dentry cache of the VFS and the futex hash
table. Those are probably far hotter than the kfence code.

While I understand that that goes beyond the scope of this project, it
might be something to work on going forward - this kind of
special-case logic that turns the kernel data section into heap memory
would not be needed if we had that kind of infrastructure.

> +#ifdef CONFIG_HAVE_ARCH_KFENCE_STATIC_POOL
> +char __kfence_pool[KFENCE_POOL_SIZE] __kfence_pool_attrs;
> +#else
> +char *__kfence_pool __read_mostly;

not __ro_after_init ?

> +#endif
[...]
> +/* Freelist with availabl

Re: linux-next: Tree for Oct 1 (drivers/mfd/simple-mfd-i2c.o)

[Lee Jones]

On Thu, 01 Oct 2020, Randy Dunlap wrote:

> On 10/1/20 4:39 AM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20200930:
> > 
> 
> on x86_64:
> 
> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_probe':
> simple-mfd-i2c.c:(.text+0x48): undefined reference to `__devm_regmap_init_i2c'
> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_driver_init':
> simple-mfd-i2c.c:(.init.text+0x14): undefined reference to 
> `i2c_register_driver'
> ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_driver_exit':
> simple-mfd-i2c.c:(.exit.text+0xd): undefined reference to `i2c_del_driver'
> 
> 
> CONFIG_I2C=m
> CONFIG_MFD_SIMPLE_MFD_I2C=y
> CONFIG_MFD_SL28CPLD=y
> 
> 
> Is linux-next missing the source code for CONFIG_MFD_SL28CPLD?

There isn't any associated source code.  It's a virtual symbol.

> The build error is caused by:
> 
> config MFD_SL28CPLD
>   tristate "Kontron sl28cpld Board Management Controller"
>   select MFD_SIMPLE_MFD_I2C
> 
> that "select" when "depends on I2C" is absent/missing.

Okay, so CONFIG_MFD_SIMPLE_MFD_I2C needs to depend on I2C too?  I made
the assumption that 'select REGMAP_I2C' would do the right thing.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] arm64: dts: zynqmp: Fix pcie ranges description

[Michal Simek]

Hi Laurent,

On 02. 10. 20 4:02, Laurent Pinchart wrote:
> Hi Michal,
> 
> Thank you for the patch.
> 
> On Tue, Sep 29, 2020 at 01:43:22PM +0200, Michal Simek wrote:
>> DT schema is checking tuples which should be properly separated. The patch
>> is doing this separation to avoid the following warning:
>> ..yaml: axi: pcie@fd0e:ranges: [[33554432, 0, 3758096384, 0,
>> 3758096384, 0, 268435456, 1124073472, 6, 0, 6, 0, 2, 0]] is not valid under
>> any of the given schemas (Possible causes of the failure):
>> ...dt.yaml: axi: pcie@fd0e:ranges: True was expected
>> ...dt.yaml: axi: pcie@fd0e:ranges:0: [33554432, 0, 3758096384, 0,
>> 3758096384, 0, 268435456, 1124073472, 6, 0, 6, 0, 2, 0] is too long
> 
> I would keep the error message unwrapped as it's a bit confusing to
> read, even if it exceeds the normal 72 columns limit of commit messaged.

>From git log I see that both ways are used.

> 
>> Signed-off-by: Michal Simek 
> 
> Reviewed-by: Laurent Pinchart 

Thanks,
Michal

Re: [PATCH v9 2/8] mtd: rawnand: rockchip: NFC drivers for RK3308, RK2928 and others

[Miquel Raynal]

Hi Yifeng,

Yifeng Zhao  wrote on Tue, 29 Sep 2020
17:08:05 +0800:

> This driver supports Rockchip NFC (NAND Flash Controller) found on RK3308,
> RK2928, RKPX30, RV1108 and other SOCs. The driver has been tested using
> 8-bit NAND interface on the ARM based RK3308 platform.
> 
> Support Rockchip SoCs and NFC versions:
> - PX30 and RK3326(NFCv900).
>   ECC: 16/40/60/70 bits/1KB.
>   CLOCK: ahb and nfc.
> - RK3308 and RV1108(NFCv800).
>   ECC: 16 bits/1KB.
>   CLOCK: ahb and nfc.
> - RK3036 and RK3128(NFCv622).
>   ECC: 16/24/40/60 bits/1KB.
>   CLOCK: ahb and nfc.
> - RK3066, RK3188 and RK2928(NFCv600).
>   ECC: 16/24/40/60 bits/1KB.
>   CLOCK: ahb.
> 
> Supported features:
> - Read full page data by DMA.
> - Support HW ECC(one step is 1KB).
> - Support 2 - 32K page size.
> - Support 8 CS(depend on SoCs)
> 
> Limitations:
> - No support for the ecc step size is 512.
> - Untested on some SoCs.
> - No support for subpages.
> - No support for the builtin randomizer.
> - The original bad block mask is not supported. It is recommended to use
>   the BBT(bad block table).
> 
> Signed-off-by: Yifeng Zhao 
> ---
> 
> Changes in v9:
> - The nfc->buffer will realloc while the page size of the second mtd
>   is large than the first one
> - Fix coding style.
> - Remove struct rk_nfc_clk.
> - Prepend some function with rk_nfc_.
> - Replace function readl_poll_timeout_atomic with readl_relaxed_poll_timeout.
> - Remove function rk_nfc_read_byte and rk_nfc_write_byte.
> - Don't select the die if 'check_only == true' in function rk_nfc_exec_op.
> - Modify function rk_nfc_write_page and rk_nfc_write_page_raw.

You should probably rebase your patches on a more recent kernel, there
are several inconsistencies with the current core (see the kernel test
robot reports). Please consider having a look at the history to follow
the naming. If you need help, please ask!

Cheers,
Miquèl

Re: WARNING in cfg80211_connect

[Johannes Berg]

On Thu, 2020-10-01 at 21:31 -0700, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit 16d4d43595b4780daac8fcea6d042689124cb094
> Author: Christoph Hellwig 
> Date:   Wed Jul 20 01:38:55 2016 +
> 
> xfs: split direct I/O and DAX path
> 

LOL!

Unlike in many other cases, here I don't even see why it went down that
path. You'd think that Christoph's commit should have no effect
whatsoever, but here we are with syzbot claiming a difference?

I mean, often enough it says something is "caused" by a patch because
that caused e.g. generic netlink family renumbering, or because it
emitted some other ioctl() calls or whatnot that are invalid before and
valid after some other (feature) patch (or vice versa sometimes), but
you'd think that this patch would have _zero_ userspace observable
effect?

Which I guess means that the reproduction of this bug is random, perhaps
timing related.

johannes

Re: [PATCH v3 2/2] Add hardware monitoring driver for Moortec MR75203 PVT controller

[Tanwar, Rahul]

Hi Guenter,

On 2/10/2020 2:26 am, Guenter Roeck wrote:
> On 9/29/20 1:59 AM, Rahul Tanwar wrote:
>> PVT controller (MR75203) is used to configure & control
>> Moortec embedded analog IP which contains temprature
>> sensor(TS), voltage monitor(VM) & process detector(PD)
>> modules. Add hardware monitoring driver to support
>> MR75203 PVT controller.
>>
>> Signed-off-by: Rahul Tanwar 
>> ---
>>  drivers/hwmon/Kconfig   |  10 +
>>  drivers/hwmon/Makefile  |   1 +
>>  drivers/hwmon/mr75203.c | 605 
>> 
>>  3 files changed, 616 insertions(+)
>>  create mode 100644 drivers/hwmon/mr75203.c
>>
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 8dc28b26916e..2defb46677b4 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1112,6 +1112,16 @@ config SENSORS_MENF21BMC_HWMON
>>This driver can also be built as a module. If so the module
>>will be called menf21bmc_hwmon.
>>  
>> +config SENSORS_MR75203
>> +tristate "Moortec Semiconductor MR75203 PVT Controller"
>> +select REGMAP_MMIO
>> +help
>> +  If you say yes here you get support for Moortec MR75203
>> +  PVT controller.
>> +
>> +  This driver can also be built as a module. If so, the module
>> +  will be called mr75203.
>> +
>>  config SENSORS_ADCXX
>>  tristate "National Semiconductor ADCxxxSxxx"
>>  depends on SPI_MASTER
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index a8f4b35b136b..bb4bd92a5149 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -142,6 +142,7 @@ obj-$(CONFIG_SENSORS_MCP3021)+= mcp3021.o
>>  obj-$(CONFIG_SENSORS_TC654) += tc654.o
>>  obj-$(CONFIG_SENSORS_MLXREG_FAN) += mlxreg-fan.o
>>  obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
>> +obj-$(CONFIG_SENSORS_MR75203)   += mr75203.o
>>  obj-$(CONFIG_SENSORS_NCT6683)   += nct6683.o
>>  obj-$(CONFIG_SENSORS_NCT6775)   += nct6775.o
>>  obj-$(CONFIG_SENSORS_NCT7802)   += nct7802.o
>> diff --git a/drivers/hwmon/mr75203.c b/drivers/hwmon/mr75203.c
>> new file mode 100644
>> index ..30a70a3ae82b
>> --- /dev/null
>> +++ b/drivers/hwmon/mr75203.c
>> @@ -0,0 +1,605 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2020 MaxLinear, Inc.
>> + *
>> + * This driver is a hardware monitoring driver for PVT controller
>> + * (MR75203) which is used to configure & control Moortec embedded
>> + * analog IP to enable multiple embedded temprature sensor(TS),
>
> temperature

Well noted.

>> + * voltage monitor(VM) & process detector(PD) modules.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* PVT Common register */
>> +#define PVT_IP_CONFIG   0x04
>> +#define TS_NUM_MSK  GENMASK(4, 0)
>> +#define TS_NUM_SFT  0
>> +#define PD_NUM_MSK  GENMASK(12, 8)
>> +#define PD_NUM_SFT  8
>> +#define VM_NUM_MSK  GENMASK(20, 16)
>> +#define VM_NUM_SFT  16
>> +#define CH_NUM_MSK  GENMASK(31, 24)
>> +#define CH_NUM_SFT  24
>> +
>> +/* Macro Common Register */
>> +#define CLK_SYNTH   0x00
>> +#define CLK_SYNTH_LO_SFT0
>> +#define CLK_SYNTH_HI_SFT8
>> +#define CLK_SYNTH_HOLD_SFT  16
>> +#define CLK_SYNTH_ENBIT(24)
>> +#define CLK_SYS_CYCLES_MAX  514
>> +#define CLK_SYS_CYCLES_MIN  2
>> +#define HZ_PER_MHZ  100L
>> +
>> +#define SDIF_DISABLE0x04
>> +
>> +#define SDIF_STAT   0x08
>> +#define SDIF_BUSY   BIT(0)
>> +#define SDIF_LOCK   BIT(1)
>> +
>> +#define SDIF_W  0x0c
>> +#define SDIF_PROG   BIT(31)
>> +#define SDIF_WRN_W  BIT(27)
>> +#define SDIF_WRN_R  0x00
>> +#define SDIF_ADDR_SFT   24
>> +
>> +#define SDIF_HALT   0x10
>> +#define SDIF_CTRL   0x14
>> +#define SDIF_SMPL_CTRL  0x20
>> +
>> +/* TS & PD Individual Macro Register */
>> +#define COM_REG_SIZE0x40
>> +
>> +#define SDIF_DONE(n)(COM_REG_SIZE + 0x14 + 0x40 * (n))
>> +#define SDIF_SMPL_DONE  BIT(0)
>> +
>> +#define SDIF_DATA(n)(COM_REG_SIZE + 0x18 + 0x40 * (n))
>> +#define SAMPLE_DATA_MSK GENMASK(15, 0)
>> +
>> +#define HILO_RESET(n)   (COM_REG_SIZE + 0x2c + 0x40 * (n))
>> +
>> +/* VM Individual Macro Register */
>> +#define VM_COM_REG_SIZE 0x200
>> +#define VM_SDIF_DONE(n) (VM_COM_REG_SIZE + 0x34 + 0x200 * (n))
>> +#define VM_SDIF_DATA(n) (VM_COM_REG_SIZE + 0x40 + 0x200 * (n))
>> +
>> +/* SDA Slave Register */
>> +#define IP_CTRL 0x00
>> +#define IP_RST_REL  BIT(1)
>> +#define IP_RUN_CONT BIT(3)
>> +#define IP_AUTO BIT(8)
>> +#define IP_VM_MODE  BIT(10)
>> +
>> +#define IP_CFG  0x01
>> +#define CFG0_MODE_2 BIT(0)
>> +#define CFG0_PARALLEL_OUT   0
>> +#define CFG0_12_BIT 0
>> +#define CFG1_VOL_MEAS_MODE  0
>> +#define CFG1_PARALLEL_OUT   0
>> +#define CFG1_14_BIT 0
>> +
>> +#define IP_DATA 0

Re: [PATCH v4 04/52] scripts: kernel-doc: make it more compatible with Sphinx 3.x

[Mauro Carvalho Chehab]

Em Thu, 1 Oct 2020 15:41:00 -0600
Jonathan Corbet  escreveu:

> On Wed, 30 Sep 2020 15:24:27 +0200
> Mauro Carvalho Chehab  wrote:
> 
> > With Sphinx 3.x, the ".. c:type:" tag was changed to accept either:
> > 
> > .. c:type:: typedef-like declaration
> > .. c:type:: name
> > 
> > Using it for other types (including functions) don't work anymore.
> > 
> > So, there are newer tags for macro, enum, struct, union, and others,
> > which doesn't exist on older versions.
> > 
> > Add a check for the Sphinx version and change the produced tags
> > accordingly.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  scripts/kernel-doc | 71 ++
> >  1 file changed, 65 insertions(+), 6 deletions(-)  
> 
> So this seems generally good, but I do wonder if we shouldn't just pass
> the sphinx version into kernel-doc as a parameter?  We're already doing a
> version check in the makefile, we should be able to capture the result and
> pass it in, maybe?  

My plan is to work later on a patch adding support for it ;)

Yet, there's something to consider: troubleshooting.

I mean, if a warning is produced during "make htmldocs", as part
of troubleshooting, people do:

./scripts/kernel-doc 

It sounds more natural that, by default, it will output the same
output as the one generated via "make htmldocs".

So, the version detection code there sounds the right way for
doing it.

Yet, as you pointed, as kerneldoc.py knows the Sphinx version,
it should be easy for it to pass an argument and avoid version
detection, by calling kernel-doc as:

./scripts/kernel-doc --sphinx3 

or

./scripts/kernel-doc --sphinx-version 3 

(not sure yet about how to name such arguments ;-) )

That might give some performance gain.

Btw, with regards to performance, I have a few other ideas that
might help how to improve kernel-doc (yet to be verified).

At least for now, I opted to keep it more straight without
adding more complexity. My plan is to work on those
things after the merge window.

Thanks,
Mauro

Re: [PATCH v2 RESEND 0/9] Some fixes for spi-s3c64xx

[Krzysztof Kozlowski]

On Thu, 1 Oct 2020 at 21:44, Mark Brown  wrote:
>
> On Thu, Oct 01, 2020 at 09:02:57PM +0200, Krzysztof Kozlowski wrote:
>
> > That is correct. We did not provide final comments on the list so they
> > could be added here - in change log. This would also be an explanation
> > why there is a resend. Another solution would be to extend the commit #7
> > description - why only CMU case is covered.
>
> If there's a new changelog then it's not a resend, the changelog is part
> of the content so I'd expect a version bump for that alone.  IIRC the
> changelog needed some clarification anyway?

Yes, documenting the non-CMU case in changeloge would be good. It
should be also v3 because of another reason: two patches got reordered
to a more meaningful position in patchset, which brought minor
differences in them.

Best regards,
Krzysztof

[PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

[Nicolin Chen]

The bus_set_iommu() in tegra_smmu_probe() enumerates all clients
to call in tegra_smmu_probe_device() where each client searches
its DT node for smmu pointer and swgroup ID, so as to configure
an fwspec. But this requires a valid smmu pointer even before mc
and smmu drivers are probed. So in tegra_smmu_probe() we added a
line of code to fill mc->smmu, marking "a bit of a hack".

This works for most of clients in the DTB, however, doesn't work
for a client that doesn't exist in DTB, a PCI device for example.

Actually, if we return ERR_PTR(-ENODEV) in ->probe_device() when
it's called from bus_set_iommu(), iommu core will let everything
carry on. Then when a client gets probed, of_iommu_configure() in
iommu core will search DTB for swgroup ID and call ->of_xlate()
to prepare an fwspec, similar to tegra_smmu_probe_device() and
tegra_smmu_configure(). Then it'll call tegra_smmu_probe_device()
again, and this time we shall return smmu->iommu pointer properly.

So we can get rid of tegra_smmu_find() and tegra_smmu_configure()
along with DT polling code by letting the iommu core handle every
thing, except a problem that we search iommus property in DTB not
only for swgroup ID but also for mc node to get mc->smmu pointer
to call dev_iommu_priv_set() and return the smmu->iommu pointer.
So we'll need to find another way to get smmu pointer.

Referencing the implementation of sun50i-iommu driver, of_xlate()
has client's dev pointer, mc node and swgroup ID. This means that
we can call dev_iommu_priv_set() in of_xlate() instead, so we can
simply get smmu pointer in ->probe_device().

This patch reworks tegra_smmu_probe_device() by:
1) Removing mc->smmu hack in tegra_smmu_probe() so as to return
   ERR_PTR(-ENODEV) in tegra_smmu_probe_device() during stage of
   tegra_smmu_probe/tegra_mc_probe().
2) Moving dev_iommu_priv_set() to of_xlate() so we can get smmu
   pointer in tegra_smmu_probe_device() to replace DTB polling.
3) Removing tegra_smmu_configure() accordingly since iommu core
   takes care of it.

Signed-off-by: Nicolin Chen 
---

Changelog
v3->v4
 * Moved dev_iommu_priv_set() to of_xlate() so we don't need
   to poll DTB for smmu pointer.
 * Removed the hack in tegra_smmu_probe() by returning ERR_PTR(
   -ENODEV) in tegra_smmu_probe_device() to let iommu core call
   in again.
 * Removed tegra_smmu_find() and tegra_smmu_configure() as iommu
   core takes care of fwspec.
v2->v3
 * Used devm_tegra_get_memory_controller() to get mc pointer
 * Replaced IS_ERR_OR_NULL with IS_ERR in .probe_device()
v1->v2
 * Replaced in .probe_device() tegra_smmu_find/tegra_smmu_configure()
   with tegra_get_memory_controller call.
 * Dropped the hack in tegra_smmu_probe().

 drivers/iommu/tegra-smmu.c | 90 --
 1 file changed, 9 insertions(+), 81 deletions(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index a573a5151c69..02d02b0c55c4 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -797,75 +797,9 @@ static phys_addr_t tegra_smmu_iova_to_phys(struct 
iommu_domain *domain,
return SMMU_PFN_PHYS(pfn) + SMMU_OFFSET_IN_PAGE(iova);
 }
 
-static struct tegra_smmu *tegra_smmu_find(struct device_node *np)
-{
-   struct platform_device *pdev;
-   struct tegra_mc *mc;
-
-   pdev = of_find_device_by_node(np);
-   if (!pdev)
-   return NULL;
-
-   mc = platform_get_drvdata(pdev);
-   if (!mc)
-   return NULL;
-
-   return mc->smmu;
-}
-
-static int tegra_smmu_configure(struct tegra_smmu *smmu, struct device *dev,
-   struct of_phandle_args *args)
-{
-   const struct iommu_ops *ops = smmu->iommu.ops;
-   int err;
-
-   err = iommu_fwspec_init(dev, &dev->of_node->fwnode, ops);
-   if (err < 0) {
-   dev_err(dev, "failed to initialize fwspec: %d\n", err);
-   return err;
-   }
-
-   err = ops->of_xlate(dev, args);
-   if (err < 0) {
-   dev_err(dev, "failed to parse SW group ID: %d\n", err);
-   iommu_fwspec_free(dev);
-   return err;
-   }
-
-   return 0;
-}
-
 static struct iommu_device *tegra_smmu_probe_device(struct device *dev)
 {
-   struct device_node *np = dev->of_node;
-   struct tegra_smmu *smmu = NULL;
-   struct of_phandle_args args;
-   unsigned int index = 0;
-   int err;
-
-   while (of_parse_phandle_with_args(np, "iommus", "#iommu-cells", index,
- &args) == 0) {
-   smmu = tegra_smmu_find(args.np);
-   if (smmu) {
-   err = tegra_smmu_configure(smmu, dev, &args);
-   of_node_put(args.np);
-
-   if (err < 0)
-   return ERR_PTR(err);
-
-   /*
-* Only a single IOMMU master interface is currently
-* supported by the Linux kerne

[PATCH v4 3/3] iommu/tegra-smmu: Add PCI support

[Nicolin Chen]

This patch simply adds support for PCI devices.

Signed-off-by: Nicolin Chen 
---

Changelog
v3->v4
 * Dropped !iommu_present() check
 * Added CONFIG_PCI check in the exit path
v2->v3
 * Replaced ternary conditional operator with if-else in .device_group()
 * Dropped change in tegra_smmu_remove()
v1->v2
 * Added error-out labels in tegra_smmu_probe()
 * Dropped pci_request_acs() since IOMMU core would call it.

 drivers/iommu/tegra-smmu.c | 37 +++--
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 02d02b0c55c4..b701a7b55e84 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -865,7 +866,11 @@ static struct iommu_group *tegra_smmu_device_group(struct 
device *dev)
group->smmu = smmu;
group->soc = soc;
 
-   group->group = iommu_group_alloc();
+   if (dev_is_pci(dev))
+   group->group = pci_device_group(dev);
+   else
+   group->group = generic_device_group(dev);
+
if (IS_ERR(group->group)) {
devm_kfree(smmu->dev, group);
mutex_unlock(&smmu->lock);
@@ -1069,22 +1074,32 @@ struct tegra_smmu *tegra_smmu_probe(struct device *dev,
iommu_device_set_fwnode(&smmu->iommu, dev->fwnode);
 
err = iommu_device_register(&smmu->iommu);
-   if (err) {
-   iommu_device_sysfs_remove(&smmu->iommu);
-   return ERR_PTR(err);
-   }
+   if (err)
+   goto err_sysfs;
 
err = bus_set_iommu(&platform_bus_type, &tegra_smmu_ops);
-   if (err < 0) {
-   iommu_device_unregister(&smmu->iommu);
-   iommu_device_sysfs_remove(&smmu->iommu);
-   return ERR_PTR(err);
-   }
+   if (err < 0)
+   goto err_unregister;
+
+#ifdef CONFIG_PCI
+   err = bus_set_iommu(&pci_bus_type, &tegra_smmu_ops);
+   if (err < 0)
+   goto err_bus_set;
+#endif
 
if (IS_ENABLED(CONFIG_DEBUG_FS))
tegra_smmu_debugfs_init(smmu);
 
return smmu;
+
+err_bus_set: __maybe_unused;
+   bus_set_iommu(&platform_bus_type, NULL);
+err_unregister:
+   iommu_device_unregister(&smmu->iommu);
+err_sysfs:
+   iommu_device_sysfs_remove(&smmu->iommu);
+
+   return ERR_PTR(err);
 }
 
 void tegra_smmu_remove(struct tegra_smmu *smmu)
-- 
2.17.1

[PATCH v4 1/3] iommu/tegra-smmu: Use fwspec in tegra_smmu_(de)attach_dev

[Nicolin Chen]

In tegra_smmu_(de)attach_dev() functions, we poll DTB for each
client's iommus property to get swgroup ID in order to prepare
"as" and enable smmu. Actually tegra_smmu_configure() prepared
an fwspec for each client, and added to the fwspec all swgroup
IDs of client DT node in DTB.

So this patch uses fwspec in tegra_smmu_(de)attach_dev() so as
to replace the redundant DT polling code.

Signed-off-by: Nicolin Chen 
---

Changelog
v3->v4:
 * Seperated the change, as a cleanup, from the rework patch
v1->v3:
 * N/A

 drivers/iommu/tegra-smmu.c | 50 +++---
 1 file changed, 20 insertions(+), 30 deletions(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 6a3ecc334481..a573a5151c69 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -484,60 +484,50 @@ static void tegra_smmu_as_unprepare(struct tegra_smmu 
*smmu,
 static int tegra_smmu_attach_dev(struct iommu_domain *domain,
 struct device *dev)
 {
+   struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
struct tegra_smmu_as *as = to_smmu_as(domain);
-   struct device_node *np = dev->of_node;
-   struct of_phandle_args args;
unsigned int index = 0;
int err = 0;
 
-   while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells", index,
-  &args)) {
-   unsigned int swgroup = args.args[0];
-
-   if (args.np != smmu->dev->of_node) {
-   of_node_put(args.np);
-   continue;
-   }
-
-   of_node_put(args.np);
+   if (!fwspec)
+   return -ENOENT;
 
+   for (index = 0; index < fwspec->num_ids; index++) {
err = tegra_smmu_as_prepare(smmu, as);
-   if (err < 0)
-   return err;
+   if (err)
+   goto disable;
 
-   tegra_smmu_enable(smmu, swgroup, as->id);
-   index++;
+   tegra_smmu_enable(smmu, fwspec->ids[index], as->id);
}
 
if (index == 0)
return -ENODEV;
 
return 0;
+
+disable:
+   while (index--) {
+   tegra_smmu_disable(smmu, fwspec->ids[index], as->id);
+   tegra_smmu_as_unprepare(smmu, as);
+   }
+
+   return err;
 }
 
 static void tegra_smmu_detach_dev(struct iommu_domain *domain, struct device 
*dev)
 {
+   struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct tegra_smmu_as *as = to_smmu_as(domain);
-   struct device_node *np = dev->of_node;
struct tegra_smmu *smmu = as->smmu;
-   struct of_phandle_args args;
unsigned int index = 0;
 
-   while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells", index,
-  &args)) {
-   unsigned int swgroup = args.args[0];
-
-   if (args.np != smmu->dev->of_node) {
-   of_node_put(args.np);
-   continue;
-   }
-
-   of_node_put(args.np);
+   if (!fwspec)
+   return;
 
-   tegra_smmu_disable(smmu, swgroup, as->id);
+   for (index = 0; index < fwspec->num_ids; index++) {
+   tegra_smmu_disable(smmu, fwspec->ids[index], as->id);
tegra_smmu_as_unprepare(smmu, as);
-   index++;
}
 }
 
-- 
2.17.1

[PATCH v4 0/3] iommu/tegra-smmu: Add PCI support

[Nicolin Chen]

This series is to add PCI support in tegra-smmu driver.

Changelog (Detail in each patch)
v3->v4
 * Dropped helper function
 * Found another way to get smmu pointer
v2->v3
 * Replaced with devm_tegra_get_memory_controller
 * Updated changes by following Dmitry's comments
v1->v2
 * Added PATCH-1 suggested by Dmitry
 * Reworked PATCH-2 to unify certain code

Nicolin Chen (3):
  iommu/tegra-smmu: Use fwspec in tegra_smmu_(de)attach_dev
  iommu/tegra-smmu: Rework tegra_smmu_probe_device()
  iommu/tegra-smmu: Add PCI support

 drivers/iommu/tegra-smmu.c | 177 -
 1 file changed, 56 insertions(+), 121 deletions(-)

-- 
2.17.1

Re: [PATCH] compat: move strut compat_iovec out of #ifdef CONFIG_COMPAT

[Christoph Hellwig]

ping?  This is needed to unbreak the work.iov_iter branch that is in
for-next.

On Mon, Sep 28, 2020 at 06:14:14PM +0200, Christoph Hellwig wrote:
> This avoid annoying ifdefs in iov_iter.c
> 
> Signed-off-by: Christoph Hellwig 
> ---
> 
> This fixes a build failure with the import_iovec / compat_import_iovec
> unification.
> 
>  include/linux/compat.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/compat.h b/include/linux/compat.h
> index 80b9b8cc1cd405..3e3d2beafed312 100644
> --- a/include/linux/compat.h
> +++ b/include/linux/compat.h
> @@ -91,6 +91,11 @@
>   static inline long __do_compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
>  #endif /* COMPAT_SYSCALL_DEFINEx */
>  
> +struct compat_iovec {
> + compat_uptr_t   iov_base;
> + compat_size_t   iov_len;
> +};
> +
>  #ifdef CONFIG_COMPAT
>  
>  #ifndef compat_user_stack_pointer
> @@ -248,11 +253,6 @@ typedef struct compat_siginfo {
>   } _sifields;
>  } compat_siginfo_t;
>  
> -struct compat_iovec {
> - compat_uptr_t   iov_base;
> - compat_size_t   iov_len;
> -};
> -
>  struct compat_rlimit {
>   compat_ulong_t  rlim_cur;
>   compat_ulong_t  rlim_max;
> -- 
> 2.28.0
---end quoted text---

Re: [PATCH v4 02/11] x86, kfence: enable KFENCE for x86

[Jann Horn]

On Tue, Sep 29, 2020 at 3:38 PM Marco Elver  wrote:
> Add architecture specific implementation details for KFENCE and enable
> KFENCE for the x86 architecture. In particular, this implements the
> required interface in  for setting up the pool and
> providing helper functions for protecting and unprotecting pages.
[...]
> diff --git a/arch/x86/include/asm/kfence.h b/arch/x86/include/asm/kfence.h
[...]
> +/* Protect the given page and flush TLBs. */
> +static inline bool kfence_protect_page(unsigned long addr, bool protect)
> +{
[...]
> +   flush_tlb_one_kernel(addr);

flush_tlb_one_kernel() -> flush_tlb_one_user() ->
__flush_tlb_one_user() -> native_flush_tlb_one_user() only flushes on
the local CPU core, not on others. If you want to leave it this way, I
think this needs a comment explaining why we're not doing a global
flush (locking context / performance overhead / ... ?).

[PATCH v3 1/2] exfat: add exfat_update_inode()

[Tetsuhiro Kohada]

Integrate exfat_sync_inode() and mark_inode_dirty() as exfat_update_inode()
Also, return the result of _exfat_write_inode () when sync is specified.

Signed-off-by: Tetsuhiro Kohada 
---
Changes in v3
 - no change
Changes in v2
 - no change

 fs/exfat/exfat_fs.h |  2 +-
 fs/exfat/file.c |  5 +
 fs/exfat/inode.c|  9 +++--
 fs/exfat/namei.c| 35 +++
 4 files changed, 16 insertions(+), 35 deletions(-)

diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
index b8f0e829ecbd..ec0ee516aee2 100644
--- a/fs/exfat/exfat_fs.h
+++ b/fs/exfat/exfat_fs.h
@@ -466,7 +466,7 @@ int exfat_count_dir_entries(struct super_block *sb, struct 
exfat_chain *p_dir);
 
 /* inode.c */
 extern const struct inode_operations exfat_file_inode_operations;
-void exfat_sync_inode(struct inode *inode);
+int exfat_update_inode(struct inode *inode);
 struct inode *exfat_build_inode(struct super_block *sb,
struct exfat_dir_entry *info, loff_t i_pos);
 void exfat_hash_inode(struct inode *inode, loff_t i_pos);
diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index a92478eabfa4..e510b95dbf77 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -245,10 +245,7 @@ void exfat_truncate(struct inode *inode, loff_t size)
goto write_size;
 
inode->i_ctime = inode->i_mtime = current_time(inode);
-   if (IS_DIRSYNC(inode))
-   exfat_sync_inode(inode);
-   else
-   mark_inode_dirty(inode);
+   exfat_update_inode(inode);
 
inode->i_blocks = ((i_size_read(inode) + (sbi->cluster_size - 1)) &
~(sbi->cluster_size - 1)) >> inode->i_blkbits;
diff --git a/fs/exfat/inode.c b/fs/exfat/inode.c
index 730373e0965a..5a55303e1f65 100644
--- a/fs/exfat/inode.c
+++ b/fs/exfat/inode.c
@@ -91,10 +91,15 @@ int exfat_write_inode(struct inode *inode, struct 
writeback_control *wbc)
return ret;
 }
 
-void exfat_sync_inode(struct inode *inode)
+int exfat_update_inode(struct inode *inode)
 {
lockdep_assert_held(&EXFAT_SB(inode->i_sb)->s_lock);
-   __exfat_write_inode(inode, 1);
+
+   if (IS_DIRSYNC(inode))
+   return __exfat_write_inode(inode, 1);
+
+   mark_inode_dirty(inode);
+   return 0;
 }
 
 /*
diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index 676094f2abe2..4eb7cb528e97 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -561,10 +561,7 @@ static int exfat_create(struct inode *dir, struct dentry 
*dentry, umode_t mode,
 
inode_inc_iversion(dir);
dir->i_ctime = dir->i_mtime = current_time(dir);
-   if (IS_DIRSYNC(dir))
-   exfat_sync_inode(dir);
-   else
-   mark_inode_dirty(dir);
+   exfat_update_inode(dir);
 
i_pos = exfat_make_i_pos(&info);
inode = exfat_build_inode(sb, &info, i_pos);
@@ -812,10 +809,7 @@ static int exfat_unlink(struct inode *dir, struct dentry 
*dentry)
inode_inc_iversion(dir);
dir->i_mtime = dir->i_atime = current_time(dir);
exfat_truncate_atime(&dir->i_atime);
-   if (IS_DIRSYNC(dir))
-   exfat_sync_inode(dir);
-   else
-   mark_inode_dirty(dir);
+   exfat_update_inode(dir);
 
clear_nlink(inode);
inode->i_mtime = inode->i_atime = current_time(inode);
@@ -846,10 +840,7 @@ static int exfat_mkdir(struct inode *dir, struct dentry 
*dentry, umode_t mode)
 
inode_inc_iversion(dir);
dir->i_ctime = dir->i_mtime = current_time(dir);
-   if (IS_DIRSYNC(dir))
-   exfat_sync_inode(dir);
-   else
-   mark_inode_dirty(dir);
+   exfat_update_inode(dir);
inc_nlink(dir);
 
i_pos = exfat_make_i_pos(&info);
@@ -976,10 +967,7 @@ static int exfat_rmdir(struct inode *dir, struct dentry 
*dentry)
inode_inc_iversion(dir);
dir->i_mtime = dir->i_atime = current_time(dir);
exfat_truncate_atime(&dir->i_atime);
-   if (IS_DIRSYNC(dir))
-   exfat_sync_inode(dir);
-   else
-   mark_inode_dirty(dir);
+   exfat_update_inode(dir);
drop_nlink(dir);
 
clear_nlink(inode);
@@ -1352,19 +1340,13 @@ static int exfat_rename(struct inode *old_dir, struct 
dentry *old_dentry,
new_dir->i_ctime = new_dir->i_mtime = new_dir->i_atime =
EXFAT_I(new_dir)->i_crtime = current_time(new_dir);
exfat_truncate_atime(&new_dir->i_atime);
-   if (IS_DIRSYNC(new_dir))
-   exfat_sync_inode(new_dir);
-   else
-   mark_inode_dirty(new_dir);
+   exfat_update_inode(new_dir);
 
i_pos = ((loff_t)EXFAT_I(old_inode)->dir.dir << 32) |
(EXFAT_I(old_inode)->entry & 0x);
exfat_unhash_inode(old_inode);
exfat_hash_inode(old_inode, i_pos);
-   if (IS_DIRSYNC(new_dir))
-   exfat_sync_inode(old_inode);
-   else
-   mark_inode_dirty(old_inode);
+   exfat_update_inode(old_inode);
 
if (S

[PATCH v3 2/2] exfat: aggregate dir-entry updates into __exfat_write_inode().

[Tetsuhiro Kohada]

The following function writes the updated inode information as dir-entry
by themselves.
 - __exfat_truncate()
 - exfat_map_cluster()
 - exfat_find_empty_entry()
Aggregate these writes into __exfat_write_inode().

In exfat_map_cluster(), the value obtained from i_size_read() is set to
stream.valid_size and stream.size.
However, in the context of get_block(), inode->i_size has not been set yet,
so the same value as current will be set, which is a meaningless update.
Furthermore, if it is called with previous size=0, the newly allocated
cluster number will be set to stream.start_clu, and stream.valid_size/size
will be 0, which is illegal.
Update stream.valid_size/size and stream.start_clu when __exfat_write_inode
is called after i_size is set, to prevent meaningless/illegal updates.

Others:
 - Remove double inode-update in __exfat_truncate() and exfat_truncate().
 - In __exfat_write_inode(), rename 'on_disk_size' to 'filesize' and
   add adjustment when filesize is 0.

Signed-off-by: Tetsuhiro Kohada 
---
Changes in v3
 - Remove update_inode() in exfat_map_cluster()/exfat_truncate()
 - Update commit-message
Changes in v2
 - Fix endian issue

 fs/exfat/file.c  | 52 +---
 fs/exfat/inode.c | 47 +++
 fs/exfat/namei.c | 26 +---
 3 files changed, 22 insertions(+), 103 deletions(-)

diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index e510b95dbf77..211fb947747a 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -100,7 +100,7 @@ int __exfat_truncate(struct inode *inode, loff_t new_size)
struct super_block *sb = inode->i_sb;
struct exfat_sb_info *sbi = EXFAT_SB(sb);
struct exfat_inode_info *ei = EXFAT_I(inode);
-   int evict = (ei->dir.dir == DIR_DELETED) ? 1 : 0;
+   int ret;
 
/* check if the given file ID is opened */
if (ei->type != TYPE_FILE && ei->type != TYPE_DIR)
@@ -150,49 +150,10 @@ int __exfat_truncate(struct inode *inode, loff_t new_size)
ei->attr |= ATTR_ARCHIVE;
 
/* update the directory entry */
-   if (!evict) {
-   struct timespec64 ts;
-   struct exfat_dentry *ep, *ep2;
-   struct exfat_entry_set_cache *es;
-   int err;
-
-   es = exfat_get_dentry_set(sb, &(ei->dir), ei->entry,
-   ES_ALL_ENTRIES);
-   if (!es)
-   return -EIO;
-   ep = exfat_get_dentry_cached(es, 0);
-   ep2 = exfat_get_dentry_cached(es, 1);
-
-   ts = current_time(inode);
-   exfat_set_entry_time(sbi, &ts,
-   &ep->dentry.file.modify_tz,
-   &ep->dentry.file.modify_time,
-   &ep->dentry.file.modify_date,
-   &ep->dentry.file.modify_time_cs);
-   ep->dentry.file.attr = cpu_to_le16(ei->attr);
-
-   /* File size should be zero if there is no cluster allocated */
-   if (ei->start_clu == EXFAT_EOF_CLUSTER) {
-   ep2->dentry.stream.valid_size = 0;
-   ep2->dentry.stream.size = 0;
-   } else {
-   ep2->dentry.stream.valid_size = cpu_to_le64(new_size);
-   ep2->dentry.stream.size = ep2->dentry.stream.valid_size;
-   }
-
-   if (new_size == 0) {
-   /* Any directory can not be truncated to zero */
-   WARN_ON(ei->type != TYPE_FILE);
-
-   ep2->dentry.stream.flags = ALLOC_FAT_CHAIN;
-   ep2->dentry.stream.start_clu = EXFAT_FREE_CLUSTER;
-   }
-
-   exfat_update_dir_chksum_with_entry_set(es);
-   err = exfat_free_dentry_set(es, inode_needs_sync(inode));
-   if (err)
-   return err;
-   }
+   inode->i_ctime = inode->i_mtime = current_time(inode);
+   ret = exfat_update_inode(inode);
+   if (ret)
+   return ret;
 
/* cut off from the FAT chain */
if (ei->flags == ALLOC_FAT_CHAIN && last_clu != EXFAT_FREE_CLUSTER &&
@@ -244,9 +205,6 @@ void exfat_truncate(struct inode *inode, loff_t size)
if (err)
goto write_size;
 
-   inode->i_ctime = inode->i_mtime = current_time(inode);
-   exfat_update_inode(inode);
-
inode->i_blocks = ((i_size_read(inode) + (sbi->cluster_size - 1)) &
~(sbi->cluster_size - 1)) >> inode->i_blkbits;
 write_size:
diff --git a/fs/exfat/inode.c b/fs/exfat/inode.c
index 5a55303e1f65..cf29b14ce7f9 100644
--- a/fs/exfat/inode.c
+++ b/fs/exfat/inode.c
@@ -19,7 +19,7 @@
 
 static int __exfat_write_inode(struct inode *inode, int sync)
 {
-   unsigned long long on_disk_size;
+   unsigned long long filesize;
struct exfat_dentry *ep, *ep2;
struct exfat_entry

Re: [RFC PATCH v3 2/2] mm: remove extra ZONE_DEVICE struct page refcount

[Christoph Hellwig]

On Thu, Oct 01, 2020 at 11:17:15AM -0700, Ralph Campbell wrote:
> ZONE_DEVICE struct pages have an extra reference count that complicates the
> code for put_page() and several places in the kernel that need to check the
> reference count to see that a page is not being used (gup, compaction,
> migration, etc.). Clean up the code so the reference count doesn't need to
> be treated specially for ZONE_DEVICE.
> 
> Signed-off-by: Ralph Campbell 

Looks good,

Reviewed-by: Christoph Hellwig 

Re: [RFC PATCH v3 1/2] ext4/xfs: add page refcount helper

[Christoph Hellwig]

On Thu, Oct 01, 2020 at 11:17:14AM -0700, Ralph Campbell wrote:
> There are several places where ZONE_DEVICE struct pages assume a reference
> count == 1 means the page is idle and free. Instead of open coding this,
> add a helper function to hide this detail.
> 
> Signed-off-by: Ralph Campbell 

Looks good:

Reviewed-by: Christoph Hellwig 

[PATCH 5/6] scripts: kernel-doc: add support for typedef enum

[Mauro Carvalho Chehab]

The PHY kernel-doc markup has gained support for documenting
a typedef enum.

However, right now the parser was not prepared for it.

So, add support for parsing it.

Fixes: 4069a572d423 ("net: phy: Document core PHY structures")
Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kernel-doc | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index d94e28fcead0..5ac3749905e5 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1339,14 +1339,22 @@ sub show_warnings($$) {
 sub dump_enum($$) {
 my $x = shift;
 my $file = shift;
+my $members;
+
 
 $x =~ s@/\*.*?\*/@@gos;# strip comments.
 # strip #define macros inside enums
 $x =~ s@#\s*((define|ifdef)\s+|endif)[^;]*;@@gos;
 
-if ($x =~ /enum\s+(\w*)\s*\{(.*)\}/) {
+if ($x =~ /typedef\s+enum\s*\{(.*)\}\s*(\w*)\s*;/) {
+   $declaration_name = $2;
+   $members = $1;
+} elsif ($x =~ /enum\s+(\w*)\s*\{(.*)\}/) {
$declaration_name = $1;
-   my $members = $2;
+   $members = $2;
+}
+
+if ($declaration_name) {
my %_members;
 
$members =~ s/\s+$//;
@@ -1381,8 +1389,7 @@ sub dump_enum($$) {
'sections' => \%sections,
'purpose' => $declaration_purpose
   });
-}
-else {
+} else {
print STDERR "${file}:$.: error: Cannot parse enum!\n";
++$errors;
 }
-- 
2.26.2

[PATCH 1/6] net: core: document two new elements of struct net_device

[Mauro Carvalho Chehab]

As warned by "make htmldocs", there are two new struct elements
that aren't documented:

../include/linux/netdevice.h:2159: warning: Function parameter or 
member 'unlink_list' not described in 'net_device'
../include/linux/netdevice.h:2159: warning: Function parameter or 
member 'nested_level' not described in 'net_device'

Fixes: 1fc70edb7d7b ("net: core: add nested_level variable in net_device")
Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/netdevice.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 78880047907e..7852921480da 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1843,6 +1843,11 @@ enum netdev_priv_flags {
  * @udp_tunnel_nic:UDP tunnel offload state
  * @xdp_state: stores info on attached XDP BPF programs
  *
+ * @nested_level:  Used as as a parameter of spin_lock_nested() of
+ * dev->addr_list_lock.
+ * @unlink_list:   As netif_addr_lock() can be called recursively,
+ * keep a list of interfaces to be deleted.
+ *
  * FIXME: cleanup struct net_device such that network protocol info
  * moves out.
  */
-- 
2.26.2

[PATCH 6/6] docs: gpio: add a new document to its index.rst

[Mauro Carvalho Chehab]

There's now a new ReST file. Add it to the index.rst file.

Fixes: ce7a2f77f976 ("docs: gpio: Add GPIO Aggregator documentation")
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/admin-guide/gpio/index.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/admin-guide/gpio/index.rst 
b/Documentation/admin-guide/gpio/index.rst
index ef2838638e96..7db367572f30 100644
--- a/Documentation/admin-guide/gpio/index.rst
+++ b/Documentation/admin-guide/gpio/index.rst
@@ -9,6 +9,7 @@ gpio
 
 gpio-aggregator
 sysfs
+gpio-mockup
 
 .. only::  subproject and html
 
-- 
2.26.2

[PATCH 2/6] docs: vcpu.rst: fix some build warnings

[Mauro Carvalho Chehab]

As warned with make htmldocs:

.../Documentation/virt/kvm/devices/vcpu.rst:70: WARNING: Malformed 
table.
Text in column margin in table line 2.

===  ==
-ENODEV: PMUv3 not supported or GIC not initialized
-ENXIO:  PMUv3 not properly configured or in-kernel irqchip not
 configured as required prior to calling this attribute
-EBUSY:  PMUv3 already initialized
-EINVAL: Invalid filter range
===  ==

The ':' character for two lines are above the size of the column.
Besides that, other tables at the file doesn't use ':', so
just drop them.

While here, also fix this warning also introduced at the same patch:

.../Documentation/virt/kvm/devices/vcpu.rst:88: WARNING: Block quote 
ends without a blank line; unexpected unindent.

By marking the C code as a literal block.

Fixes: 8be86a5eec04 ("KVM: arm64: Document PMU filtering API")
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/virt/kvm/devices/vcpu.rst | 26 -
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/Documentation/virt/kvm/devices/vcpu.rst 
b/Documentation/virt/kvm/devices/vcpu.rst
index da7c2ef7dafc..2acec3b9ef65 100644
--- a/Documentation/virt/kvm/devices/vcpu.rst
+++ b/Documentation/virt/kvm/devices/vcpu.rst
@@ -67,25 +67,25 @@ irqchip.
 :Returns:
 
 ===  ==
--ENODEV: PMUv3 not supported or GIC not initialized
--ENXIO:  PMUv3 not properly configured or in-kernel irqchip not
+-ENODEV  PMUv3 not supported or GIC not initialized
+-ENXIO   PMUv3 not properly configured or in-kernel irqchip not
  configured as required prior to calling this attribute
--EBUSY:  PMUv3 already initialized
--EINVAL: Invalid filter range
+-EBUSY   PMUv3 already initialized
+-EINVAL  Invalid filter range
 ===  ==
 
-Request the installation of a PMU event filter described as follows:
+Request the installation of a PMU event filter described as follows::
 
-struct kvm_pmu_event_filter {
-   __u16   base_event;
-   __u16   nevents;
+struct kvm_pmu_event_filter {
+   __u16   base_event;
+   __u16   nevents;
 
-#define KVM_PMU_EVENT_ALLOW0
-#define KVM_PMU_EVENT_DENY 1
+#define KVM_PMU_EVENT_ALLOW0
+#define KVM_PMU_EVENT_DENY 1
 
-   __u8action;
-   __u8pad[3];
-};
+   __u8action;
+   __u8pad[3];
+};
 
 A filter range is defined as the range [@base_event, @base_event + @nevents),
 together with an @action (KVM_PMU_EVENT_ALLOW or KVM_PMU_EVENT_DENY). The
-- 
2.26.2

[PATCH 0/6] Fix new html build warnings from next-20201001

[Mauro Carvalho Chehab]

There are some new warnings when building the documentation from
yesterday's linux next. This small series fix them.

- patch 1 documents two new kernel-doc parameters on a net core file.
  I used the commit log in order to help documenting them;
- patch 2 fixes some tags at UMLv2 howto;
- patches 3 and 5 add some new documents at the corresponding
  index file.
- patch 4 changes kernel-doc script for it to recognize typedef enums.

Patch 4 should probably be merged via docs tree, but the others
are against stuff recently added at linux-next. So, the better is to
merge them directly at the trees which introduced the issue.

-

As a reference, the patches fixing all html build warnings are at:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=sphinx3-fixes-v3

Such series also adds support for Sphinx versions 3.1 and above.

It should be noticed that, with Sphinx version 3 and above, there
are a few new warnings, because currently Sphinx assumes a
that names are unique for all C symbols. There are a few cases
where we have the same name for a function and for a struct at
the Kernel. Upstream is already working on a solution for that.

So, for now, I recomend doing html builds with version < 3.


Mauro Carvalho Chehab (6):
  net: core: document two new elements of struct net_device
  docs: vcpu.rst: fix some build warnings
  docs: virt: user_mode_linux_howto_v2.rst: fix a literal block markup
  docs: i2c: index.rst: add slave-testunit-backend.rst
  scripts: kernel-doc: add support for typedef enum
  docs: gpio: add a new document to its index.rst

 Documentation/admin-guide/gpio/index.rst  |  1 +
 .../admin-guide/hw-vuln/l1d_flush.rst |  3 +--
 Documentation/i2c/index.rst   |  1 +
 Documentation/virt/kvm/devices/vcpu.rst   | 26 +--
 .../virt/uml/user_mode_linux_howto_v2.rst |  1 +
 include/linux/netdevice.h |  5 
 scripts/kernel-doc| 15 ---
 7 files changed, 33 insertions(+), 19 deletions(-)

-- 
2.26.2

[PATCH 4/6] docs: i2c: index.rst: add slave-testunit-backend.rst

[Mauro Carvalho Chehab]

As warned by Sphinx:

.../Documentation/i2c/slave-testunit-backend.rst: WARNING: document 
isn't included in any toctree

This document is not included anywhere.

Fixes: a8335c64c5f0 ("i2c: add slave testunit driver")
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/admin-guide/hw-vuln/l1d_flush.rst | 3 +--
 Documentation/i2c/index.rst | 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/hw-vuln/l1d_flush.rst 
b/Documentation/admin-guide/hw-vuln/l1d_flush.rst
index adc4ecc72361..f794e2b1096c 100644
--- a/Documentation/admin-guide/hw-vuln/l1d_flush.rst
+++ b/Documentation/admin-guide/hw-vuln/l1d_flush.rst
@@ -22,8 +22,7 @@ mechanism
 Usage Guidelines
 
 
-Please see document: :ref:`Documentation/userspace-api/spec_ctrl.rst` for
-details.
+Please see document: :doc:`/userspace-api/spec_ctrl` for details.
 
 **NOTE**: The feature is disabled by default, applications need to
 specifically opt into the feature to enable it.
diff --git a/Documentation/i2c/index.rst b/Documentation/i2c/index.rst
index 8a2ad3845191..9b8df313902c 100644
--- a/Documentation/i2c/index.rst
+++ b/Documentation/i2c/index.rst
@@ -38,6 +38,7 @@ Debugging
 
gpio-fault-injection
i2c-stub
+   slave-testunit-backend
 
 Slave I2C
 =
-- 
2.26.2

[PATCH 3/6] docs: virt: user_mode_linux_howto_v2.rst: fix a literal block markup

[Mauro Carvalho Chehab]

There's a missing new line for a literal block:

.../Documentation/virt/uml/user_mode_linux_howto_v2.rst:682: WARNING: 
Unexpected indentation.

Fixes: 04301bf5b072 ("docs: replace the old User Mode Linux HowTo with a new 
one")
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/virt/uml/user_mode_linux_howto_v2.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst 
b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
index f70e6f5873c6..312e431695d9 100644
--- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst
+++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
@@ -679,6 +679,7 @@ Starting UML
 
 We can now run UML.
 ::
+
# linux mem=2048M umid=TEST \
 ubd0=Filesystem.img \
 vec0:transport=tap,ifname=tap0,depth=128,gro=1 \
-- 
2.26.2

Re: [perf report] 977f739b71: perf-test.skid_test.round2.MEM_LOAD_L3_MISS_RETIRED.LOCAL_DRAM_dtlb_withou t_NMI_fixed_period.fail

[Philip Li]

On Wed, Sep 30, 2020 at 02:41:07PM +0200, Michael Petlan wrote:
> Hello. To me, it looks rather a random failure. Is it actually reproducible
> and proven that the patch has caused it? The patch doesn't seem to cause
thanks for the input, we will look into this and provide update. Now since
we are in Chinese national holiday (until Oct 9), please allow some time
before we get back to work on this.

Thanks

> the fails below.
> Cheers,
> Michael
> 
> On Wed, 30 Sep 2020, kernel test robot wrote:
> > Greeting,
> > 
> > FYI, we noticed the following commit (built with gcc-9):
> > 
> > commit: 977f739b7126bf98b5202e243f60cbc0a1ec2c3b ("perf report: Disable 
> > ordered_events for raw dump")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > 
> > 
> > in testcase: perf-test
> > version: perf-test-x86_64-git-1_20200717
> > with following parameters:
> > 
> > type: lkp
> > ucode: 0xd6
> > 
> > test-description: The internal Perf Test suite.
> > 
> > 
> > on test machine: 4 threads Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz with 
> > 32G memory
> > 
> > caused below changes (please refer to attached dmesg/kmsg for entire 
> > log/backtrace):
> > 
> > 
> > 
> > 
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot 
> > 
> > 
> > 2020-09-28 17:02:40 ./skid_test/run.sh
> > Mon Sep 28 17:02:58 UTC 2020
> > 3 test cases pass for skid_test test. 3 test cases fail for skid_test test.
> > Test Case BR_INST_RETIRED.ALL_BRANCHES_PEBS_triad_loop_with_NMI PASS!
> > Test Case MEM_LOAD_RETIRED.L2_HIT_dtlb_with_NMI PASS!
> > Test Case MEM_LOAD_L3_MISS_RETIRED.LOCAL_DRAM_dtlb_with_NMI FAILED!
> > Test Case 
> > BR_INST_RETIRED.ALL_BRANCHES_PEBS_triad_loop_without_NMI_fixed_period PASS!
> > Test Case MEM_LOAD_RETIRED.L2_HIT_dtlb_without_NMI_fixed_period FAILED!
> > Test Case MEM_LOAD_L3_MISS_RETIRED.LOCAL_DRAM_dtlb_without_NMI_fixed_period 
> > FAILED!
> > 
> > 
> > 
> > To reproduce:
> > 
> > git clone https://github.com/intel/lkp-tests.git
> > cd lkp-tests
> > bin/lkp install job.yaml  # job file is attached in this email
> > bin/lkp run job.yaml
> > 
> > 
> > 
> > Thanks,
> > Rong Chen
> > 
> > 
> 

Re: [PATCH v4 02/11] x86, kfence: enable KFENCE for x86

[Jann Horn]

On Tue, Sep 29, 2020 at 3:38 PM Marco Elver  wrote:
> Add architecture specific implementation details for KFENCE and enable
> KFENCE for the x86 architecture. In particular, this implements the
> required interface in  for setting up the pool and
> providing helper functions for protecting and unprotecting pages.
>
> For x86, we need to ensure that the pool uses 4K pages, which is done
> using the set_memory_4k() helper function.
[...]
> diff --git a/arch/x86/include/asm/kfence.h b/arch/x86/include/asm/kfence.h
[...]
> +/* Protect the given page and flush TLBs. */
> +static inline bool kfence_protect_page(unsigned long addr, bool protect)
> +{
> +   unsigned int level;
> +   pte_t *pte = lookup_address(addr, &level);
> +
> +   if (!pte || level != PG_LEVEL_4K)

Do we actually expect this to happen, or is this just a "robustness"
check? If we don't expect this to happen, there should be a WARN_ON()
around the condition.

> +   return false;
> +
> +   if (protect)
> +   set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT));
> +   else
> +   set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));

Hmm... do we have this helper (instead of using the existing helpers
for modifying memory permissions) to work around the allocation out of
the data section?

> +   flush_tlb_one_kernel(addr);
> +   return true;
> +}
> +
> +#endif /* _ASM_X86_KFENCE_H */
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
[...]
> @@ -701,6 +702,9 @@ no_context(struct pt_regs *regs, unsigned long error_code,
> }
>  #endif
>
> +   if (kfence_handle_page_fault(address))
> +   return;
> +
> /*
>  * 32-bit:
>  *

The standard 5 lines of diff context don't really make it obvious
what's going on here. Here's a diff with more context:


/*
 * Stack overflow?  During boot, we can fault near the initial
 * stack in the direct map, but that's not an overflow -- check
 * that we're in vmalloc space to avoid this.
 */
if (is_vmalloc_addr((void *)address) &&
(((unsigned long)tsk->stack - 1 - address < PAGE_SIZE) ||
 address - ((unsigned long)tsk->stack + THREAD_SIZE) < PAGE_SIZE)) {
unsigned long stack = __this_cpu_ist_top_va(DF) -
sizeof(void *);
/*
 * We're likely to be running with very little stack space
 * left.  It's plausible that we'd hit this condition but
 * double-fault even before we get this far, in which case
 * we're fine: the double-fault handler will deal with it.
 *
 * We don't want to make it all the way into the oops code
 * and then double-fault, though, because we're likely to
 * break the console driver and lose most of the stack dump.
 */
asm volatile ("movq %[stack], %%rsp\n\t"
  "call handle_stack_overflow\n\t"
  "1: jmp 1b"
  : ASM_CALL_CONSTRAINT
  : "D" ("kernel stack overflow (page fault)"),
"S" (regs), "d" (address),
[stack] "rm" (stack));
unreachable();
}
 #endif

+   if (kfence_handle_page_fault(address))
+   return;
+
/*
 * 32-bit:
 *
 *   Valid to do another page fault here, because if this fault
 *   had been triggered by is_prefetch fixup_exception would have
 *   handled it.
 *
 * 64-bit:
 *
 *   Hall of shame of CPU/BIOS bugs.
 */
if (is_prefetch(regs, error_code, address))
return;

if (is_errata93(regs, address))
return;

/*
 * Buggy firmware could access regions which might page fault, try to
 * recover from such faults.
 */
if (IS_ENABLED(CONFIG_EFI))
efi_recover_from_page_fault(address);

 oops:
/*
 * Oops. The kernel tried to access some bad page. We'll have to
 * terminate things with extreme prejudice:
 */
flags = oops_begin();



Shouldn't kfence_handle_page_fault() happen after prefetch handling,
at least? Maybe directly above the "oops" label?

Re: [PATCH 4/5] clk: qcom: Add SDM660 GPU Clock Controller (GPUCC) driver

[Philip Li]

On Wed, Sep 30, 2020 at 11:58:50PM +0200, AngeloGioacchino Del Regno wrote:
> The kernel test robot is wrong: this commit builds fine by
Thanks for the info and sorry for the wrong report. Currently it is
hard to detect the base in this case automatically, if possible, we
recommend to use --base option when git format patch, this provides
extra hint to us when looking for the base.

> merging in the required patch series (464958) named
> "Qualcomm clock fixes and preparation for SDM660"
> https://lore.kernel.org/patchwork/project/lkml/list/?series=464958
> 
> In that series there is a commit that generalizes the MSM8996-only
> gfx3d clock ops and introduces the definition of clk_rcg2_gfx3d.
> 
> Il giorno mer 30 set 2020 alle ore 22:46 kernel test robot
>  ha scritto:
> >
> > Hi,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on clk/clk-next]
> > [also build test ERROR on robh/for-next linux/master linus/master v5.9-rc7 
> > next-20200930]
> > [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/kholk11-gmail-com/SDM630-660-Multimedia-and-GPU-clock-controllers/20200926-210437
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git 
> > clk-next
> > config: m68k-allmodconfig (attached as .config)
> > compiler: m68k-linux-gcc (GCC) 9.3.0
> > 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
> > # 
> > https://github.com/0day-ci/linux/commit/0551514b1ab723837163a8c4cd84d22831e38019
> > git remote add linux-review https://github.com/0day-ci/linux
> > git fetch --no-tags linux-review 
> > kholk11-gmail-com/SDM630-660-Multimedia-and-GPU-clock-controllers/20200926-210437
> > git checkout 0551514b1ab723837163a8c4cd84d22831e38019
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
> > ARCH=m68k
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot 
> >
> > All errors (new ones prefixed by >>):
> >
> > >> drivers/clk/qcom/gpucc-sdm660.c:106:15: error: variable 'gfx3d_clk_src' 
> > >> has initializer but incomplete type
> >  106 | static struct clk_rcg2_gfx3d gfx3d_clk_src = {
> >  |   ^~
> > >> drivers/clk/qcom/gpucc-sdm660.c:107:3: error: 'struct clk_rcg2_gfx3d' 
> > >> has no member named 'div'
> >  107 |  .div = 2,
> >  |   ^~~
> >drivers/clk/qcom/gpucc-sdm660.c:107:9: warning: excess elements in 
> > struct initializer
> >  107 |  .div = 2,
> >  | ^
> >drivers/clk/qcom/gpucc-sdm660.c:107:9: note: (near initialization for 
> > 'gfx3d_clk_src')
> > >> drivers/clk/qcom/gpucc-sdm660.c:108:3: error: 'struct clk_rcg2_gfx3d' 
> > >> has no member named 'rcg'
> >  108 |  .rcg = {
> >  |   ^~~
> > >> drivers/clk/qcom/gpucc-sdm660.c:108:9: error: extra brace group at end 
> > >> of initializer
> >  108 |  .rcg = {
> >  | ^
> >drivers/clk/qcom/gpucc-sdm660.c:108:9: note: (near initialization for 
> > 'gfx3d_clk_src')
> >drivers/clk/qcom/gpucc-sdm660.c:108:9: warning: excess elements in 
> > struct initializer
> >drivers/clk/qcom/gpucc-sdm660.c:108:9: note: (near initialization for 
> > 'gfx3d_clk_src')
> > >> drivers/clk/qcom/gpucc-sdm660.c:121:3: error: 'struct clk_rcg2_gfx3d' 
> > >> has no member named 'hws'
> >  121 |  .hws = (struct clk_hw*[]){
> >  |   ^~~
> >drivers/clk/qcom/gpucc-sdm660.c:121:9: warning: excess elements in 
> > struct initializer
> >  121 |  .hws = (struct clk_hw*[]){
> >  | ^
> >drivers/clk/qcom/gpucc-sdm660.c:121:9: note: (near initialization for 
> > 'gfx3d_clk_src')
> > >> drivers/clk/qcom/gpucc-sdm660.c:139:25: error: invalid use of undefined 
> > >> type 'struct clk_rcg2_gfx3d'
> >  139 | .hw = &gfx3d_clk_src.rcg.clkr.hw,
> >  | ^
> >drivers/clk/qcom/gpucc-sdm660.c:257:45: error: 'NO_RET_PERIPH' 
> > undeclared here (not in a function)
> >  257 |  .flags = CLAMP_IO | SW_RESET | AON_RESET | NO_RET_PERIPH,
> >  | ^
> >drivers/clk/qcom/gpucc-sdm660.c:277:34: error: invalid use of undefined 
> > type 'struct clk_rcg2_gfx3d'
> >  277 |  [GFX3D_CLK_SRC] = &gfx3d_clk_src.rcg.clkr,
> >  |  ^
> > >> drivers/clk/qcom/gpucc-sdm660.c:106:30: error: storage size of 
> > >> 'gfx3d_clk_src' isn't known
> >  106 | static struct clk_rcg2_gfx3d gfx3d_clk_src = {
> >  |  ^
> >
> > vim 

Re: [kbuild-all] Re: [PATCH v5 03/15] misc: bcm-vk: add autoload support

[Philip Li]

On Thu, Oct 01, 2020 at 10:48:08AM -0700, Scott Branden wrote:
> 
> 
> On 2020-09-30 9:07 p.m., kernel test robot wrote:
> > Hi Scott,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on char-misc/char-misc-testing]
> > [also build test ERROR on soc/for-next kees/for-next/pstore linus/master 
> > v5.9-rc7 next-20200930]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> Yes, this patch series will not compile as described in the cover letter 
> without Kees' patches:
> 
> This patch series drops previous patches in [1]
> that were incorporated by Kees Cook into patch series
> "Introduce partial kernel_read_file() support" [2].
> 
> Remaining patches are contained in this series to add Broadcom VK driver.
> (which depends on request_firmware_into_buf API addition in
> other patch series [2] being applied first).
> 
> Please note this patch series will not compile without [2].
Thanks for the detail info, and sorry for the wrong report. Currently
we are not able to analyz the info in cover letter which may lead to
wrong base used. If possible, you can give a try to use --base option
when git format patch, this provides more hints to us when looking
for a base.

> 
> [1] 
> https://lore.kernel.org/lkml/20200706232309.12010-1-scott.bran...@broadcom.com/
> [2] 
> https://lore.kernel.org/lkml/20200729175845.1745471-1-keesc...@chromium.org/
> 
> 
> 
> > 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/Scott-Branden/Add-Broadcom-VK-driver/20201001-093119
> > base:   
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 
> > c471bf4b11c7df0f0f9f42b5aeec424dc62d0c7e
> > config: powerpc-allyesconfig (attached as .config)
> > compiler: powerpc64-linux-gcc (GCC) 9.3.0
> > 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
> > # 
> > https://github.com/0day-ci/linux/commit/f04a1673933a1af94e44bc650533bbb271e3dcc1
> > git remote add linux-review https://github.com/0day-ci/linux
> > git fetch --no-tags linux-review 
> > Scott-Branden/Add-Broadcom-VK-driver/20201001-093119
> > git checkout f04a1673933a1af94e44bc650533bbb271e3dcc1
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
> > ARCH=powerpc 
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot 
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/misc/bcm-vk/bcm_vk_dev.c: In function 
> > 'bcm_vk_load_image_by_type':
> >>> drivers/misc/bcm-vk/bcm_vk_dev.c:284:8: error: implicit declaration of 
> >>> function 'request_partial_firmware_into_buf'; did you mean 
> >>> 'request_firmware_into_buf'? [-Werror=implicit-function-declaration]
> >  284 |  ret = request_partial_firmware_into_buf(&fw, filename, dev,
> >  |^
> >  |request_firmware_into_buf
> >cc1: some warnings being treated as errors
> >
> > vim +284 drivers/misc/bcm-vk/bcm_vk_dev.c
> >
> >206  
> >207  static int bcm_vk_load_image_by_type(struct bcm_vk *vk, u32 
> > load_type,
> >208   const char *filename)
> >209  {
> >210  struct device *dev = &vk->pdev->dev;
> >211  const struct firmware *fw = NULL;
> >212  void *bufp = NULL;
> >213  size_t max_buf, offset;
> >214  int ret;
> >215  u64 offset_codepush;
> >216  u32 codepush;
> >217  u32 value;
> >218  dma_addr_t boot_dma_addr;
> >219  bool is_stdalone;
> >220  
> >221  if (load_type == VK_IMAGE_TYPE_BOOT1) {
> >222  /*
> >223   * After POR, enable VK soft BOOTSRC so bootrom 
> > do not clear
> >224   * the pushed image (the TCM memories).
> >225   */
> >226  value = vkread32(vk, BAR_0, BAR_BOOTSRC_SE

Re: [PATCH 1/1] sched/uclamp: release per-task uclamp control if user set to default value

[Yun Hsiang]

On Wed, Sep 30, 2020 at 03:12:51PM +0200, Dietmar Eggemann wrote:
Hi Dietmar,

> Hi Yun,
> 
> On 28/09/2020 10:26, Yun Hsiang wrote:
> > If the user wants to release the util clamp and let cgroup to control it,
> > we need a method to reset.
> > 
> > So if the user set the task uclamp to the default value (0 for UCLAMP_MIN
> > and 1024 for UCLAMP_MAX), reset the user_defined flag to release control.
> > 
> > Signed-off-by: Yun Hsiang 
> 
> could you explain with a little bit more detail why you would need this
> feature?
> 
> Currently we assume that once the per-task uclamp (user-defined) values
> are set, you could only change the effective uclamp values of this task
> by (1) moving it into another taskgroup or (2) changing the system
> default uclamp values.
> 

Assume a module that controls group (such as top-app in android) uclamp and
task A in the group.
Once task A set uclamp, it will not be affected by the group setting.
If task A doesn't want to control itself anymore,
it can not go back to the initial state to let the module(group) control.
But the other tasks in the group will be affected by the group.

The policy might be
1) if the task wants to control it's uclamp, use task uclamp value
(but under group uclamp constraint)
2) if the task doesn't want to control it's uclamp, use group uclamp value.

If the policy is proper, we need a reset method for per-task uclamp.

> > ---
> >  kernel/sched/core.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 9a2fbf98fd6f..fa63d70d783a 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -1187,6 +1187,7 @@ static void __setscheduler_uclamp(struct task_struct 
> > *p,
> >   const struct sched_attr *attr)
> >  {
> > enum uclamp_id clamp_id;
> > +   bool user_defined;
> >  
> > /*
> >  * On scheduling class change, reset to default clamps for tasks
> > @@ -1210,14 +1211,16 @@ static void __setscheduler_uclamp(struct 
> > task_struct *p,
> > if (likely(!(attr->sched_flags & SCHED_FLAG_UTIL_CLAMP)))
> > return;
> >  
> > +   user_defined = attr->sched_util_min == 0 ? false : true;
> > if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) {
> > uclamp_se_set(&p->uclamp_req[UCLAMP_MIN],
> > - attr->sched_util_min, true);
> > + attr->sched_util_min, user_defined);
> > }
> >  
> > +   user_defined = attr->sched_util_max == 1024 ? false : true;
> > if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) {
> > uclamp_se_set(&p->uclamp_req[UCLAMP_MAX],
> > - attr->sched_util_max, true);
> > + attr->sched_util_max, user_defined);
> > }
> >  }

Re: [kbuild-all] Re: [PATCH] mm: memcg/slab: fix slab statistics in !SMP configuration

[Philip Li]

On Thu, Oct 01, 2020 at 05:55:59PM -0700, Roman Gushchin wrote:
> On Fri, Oct 02, 2020 at 08:08:40AM +0800, kbuild test robot wrote:
> > Hi Roman,
> > 
> > Thank you for the patch! Yet something to improve:
> > 
> > [auto build test ERROR on mmotm/master]
> 
> It's a bogus error, the patch was applied onto mmotm/master, which doesn't
> contain necessary slab controller patches.
sorry for the wrong report, and thanks for the input, we will check
this to see whether we can find an appropriate base for this case.
Meanwhile, you can give a try to use --base option when git format patch, which
helps us to have more clue when looking for base info.

> 
> Thanks!
> 
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Roman-Gushchin/mm-memcg-slab-fix-slab-statistics-in-SMP-configuration/20201002-044114
> > base:   git://git.cmpxchg.org/linux-mmotm.git master
> > config: i386-randconfig-s002-20200930 (attached as .config)
> > compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> > reproduce:
> > # apt-get install sparse
> > # sparse version: v0.6.2-201-g24bdaac6-dirty
> > # 
> > https://github.com/0day-ci/linux/commit/3e4248734433fea1624e4971258042af2f231e02
> > git remote add linux-review https://github.com/0day-ci/linux
> > git fetch --no-tags linux-review 
> > Roman-Gushchin/mm-memcg-slab-fix-slab-statistics-in-SMP-configuration/20201002-044114
> > git checkout 3e4248734433fea1624e4971258042af2f231e02
> > # save the attached .config to linux build tree
> > make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 
> > 
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >In file included from include/linux/mm.h:1317,
> > from include/linux/memcontrol.h:20,
> > from include/linux/swap.h:9,
> > from include/linux/suspend.h:5,
> > from arch/x86/kernel/asm-offsets.c:13:
> >include/linux/vmstat.h: In function '__mod_node_page_state':
> > >> include/linux/vmstat.h:295:6: error: implicit declaration of function 
> > >> 'vmstat_item_in_bytes' [-Werror=implicit-function-declaration]
> >  295 |  if (vmstat_item_in_bytes(item)) {
> >  |  ^~~~
> >cc1: some warnings being treated as errors
> >make[2]: *** [scripts/Makefile.build:99: arch/x86/kernel/asm-offsets.s] 
> > Error 1
> >make[2]: Target '__build' not remade because of errors.
> >make[1]: *** [Makefile:1139: prepare0] Error 2
> >make[1]: Target 'prepare' not remade because of errors.
> >make: *** [Makefile:179: sub-make] Error 2
> >make: Target 'prepare' not remade because of errors.
> > 
> > vim +/vmstat_item_in_bytes +295 include/linux/vmstat.h
> > 
> >291  
> >292  static inline void __mod_node_page_state(struct pglist_data 
> > *pgdat,
> >293  enum node_stat_item item, int delta)
> >294  {
> >  > 295  if (vmstat_item_in_bytes(item)) {
> >296  VM_WARN_ON_ONCE(delta & (PAGE_SIZE - 1));
> >297  delta >>= PAGE_SHIFT;
> >298  }
> >299  
> >300  node_page_state_add(delta, pgdat, item);
> >301  }
> >302  
> > 
> > ---
> > 0-DAY CI Kernel Test Service, Intel Corporation
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_hyperkitty_list_kbuild-2Dall-40lists.01.org&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=a91mqnAqjcA0iLpnhkpBXCmVqE_BuOIny-YmkB8jp2U&s=4EiiISKLS8YORtIb2rqP7oxVeqhBmKzMHqJzWhDAuMw&e=
> >  
> 
> ___
> kbuild-all mailing list -- kbuild-...@lists.01.org
> To unsubscribe send an email to kbuild-all-le...@lists.01.org

Re: [PATCH 0/5] Speed up mremap on large regions

[Kirill A. Shutemov]

On Thu, Oct 01, 2020 at 05:09:02PM -0700, Lokesh Gidra wrote:
> On Thu, Oct 1, 2020 at 9:00 AM Kalesh Singh  wrote:
> >
> > On Thu, Oct 1, 2020 at 8:27 AM Kirill A. Shutemov
> >  wrote:
> > >
> > > On Wed, Sep 30, 2020 at 03:42:17PM -0700, Lokesh Gidra wrote:
> > > > On Wed, Sep 30, 2020 at 3:32 PM Kirill A. Shutemov
> > > >  wrote:
> > > > >
> > > > > On Wed, Sep 30, 2020 at 10:21:17PM +, Kalesh Singh wrote:
> > > > > > mremap time can be optimized by moving entries at the PMD/PUD level 
> > > > > > if
> > > > > > the source and destination addresses are PMD/PUD-aligned and
> > > > > > PMD/PUD-sized. Enable moving at the PMD and PUD levels on arm64 and
> > > > > > x86. Other architectures where this type of move is supported and 
> > > > > > known to
> > > > > > be safe can also opt-in to these optimizations by enabling 
> > > > > > HAVE_MOVE_PMD
> > > > > > and HAVE_MOVE_PUD.
> > > > > >
> > > > > > Observed Performance Improvements for remapping a PUD-aligned 
> > > > > > 1GB-sized
> > > > > > region on x86 and arm64:
> > > > > >
> > > > > > - HAVE_MOVE_PMD is already enabled on x86 : N/A
> > > > > > - Enabling HAVE_MOVE_PUD on x86   : ~13x speed up
> > > > > >
> > > > > > - Enabling HAVE_MOVE_PMD on arm64 : ~ 8x speed up
> > > > > > - Enabling HAVE_MOVE_PUD on arm64 : ~19x speed up
> > > > > >
> > > > > >   Altogether, HAVE_MOVE_PMD and HAVE_MOVE_PUD
> > > > > >   give a total of ~150x speed up on arm64.
> > > > >
> > > > > Is there a *real* workload that benefit from HAVE_MOVE_PUD?
> > > > >
> > > > We have a Java garbage collector under development which requires
> > > > moving physical pages of multi-gigabyte heap using mremap. During this
> > > > move, the application threads have to be paused for correctness. It is
> > > > critical to keep this pause as short as possible to avoid jitters
> > > > during user interaction. This is where HAVE_MOVE_PUD will greatly
> > > > help.
> > >
> > > Any chance to quantify the effect of mremap() with and without
> > > HAVE_MOVE_PUD?
> > >
> > > I doubt it's a major contributor to the GC pause. I expect you need to
> > > move tens of gigs to get sizable effect. And if your GC routinely moves
> > > tens of gigs, maybe problem somewhere else?
> > >
> > > I'm asking for numbers, because increase in complexity comes with cost.
> > > If it doesn't provide an substantial benefit to a real workload
> > > maintaining the code forever doesn't make sense.
> >
> mremap is indeed the biggest contributor to the GC pause. It has to
> take place in what is typically known as a 'stop-the-world' pause,
> wherein all application threads are paused. During this pause the GC
> thread flips the GC roots (threads' stacks, globals etc.), and then
> resumes threads along with concurrent compaction of the heap.This
> GC-root flip differs depending on which compaction algorithm is being
> used.
> 
> In our case it involves updating object references in threads' stacks
> and remapping java heap to a different location. The threads' stacks
> can be handled in parallel with the mremap. Therefore, the dominant
> factor is indeed the cost of mremap. From patches 2 and 4, it is clear
> that remapping 1GB without this optimization will take ~9ms on arm64.
> 
> Although this mremap has to happen only once every GC cycle, and the
> typical size is also not going to be more than a GB or 2, pausing
> application threads for ~9ms is guaranteed to cause jitters. OTOH,
> with this optimization, mremap is reduced to ~60us, which is a totally
> acceptable pause time.
> 
> Unfortunately, implementation of the new GC algorithm hasn't yet
> reached the point where I can quantify the effect of this
> optimization. But I can confirm that without this optimization the new
> GC will not be approved.

IIUC, the 9ms -> 90us improvement attributed to combination HAVE_MOVE_PMD
and HAVE_MOVE_PUD, right? I expect HAVE_MOVE_PMD to be reasonable for some
workloads, but marginal benefit of HAVE_MOVE_PUD is in doubt. Do you see
it's useful for your workload?

-- 
 Kirill A. Shutemov

Re: [PATCH v3 10/13] ASoC: tegra: Add audio graph based card driver

[Kuninori Morimoto]

Hi Sameer

> Add Tegra audio machine driver which is based on generic audio graph card
> driver. It re-uses most of the common stuff from audio graph driver and
> uses the same DT binding. Required Tegra specific customizations are done
> in the driver.
(snip)
> +static const struct snd_soc_ops tegra_audio_graph_ops = {
> + .startup= asoc_simple_startup,
> + .shutdown   = asoc_simple_shutdown,
> + .hw_params  = tegra_audio_graph_hw_params,
> +};

This is just an idea,
but can we use hooks here somehow ?

.ops_hook_pre
.ops_hook_func
.ops_hook_post

if (priv->ops_hook_pre->func)
priv->ops_hook_pre->func_pre(...);

if (priv->ops_hook_func->func)
priv->ops_hook_func->func(...); /* driver's function */
else
graph_func(...);/* audio-graph function */

if (priv->ops_hook_post->func)
priv->ops_hook_post->func(...);


> +static int tegra_audio_graph_probe(struct platform_device *pdev)
> +{
> + struct asoc_simple_priv *priv;
> + struct device *dev = &pdev->dev;
> + struct snd_soc_card *card;
> + struct link_info li;
> + int err;
> +
> + /* Allocate the private data and the DAI link array */
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->data = (struct tegra_audio_graph_data *)
> + devm_kzalloc(dev, sizeof(*priv->data), GFP_KERNEL);
> + if (!priv->data)
> + return -ENOMEM;
> +
> + card = simple_priv_to_card(priv);
> +
> + card->owner = THIS_MODULE;
> + card->dev = dev;
> + card->component_chaining = true;
> + card->probe = tegra_audio_graph_card_probe;
> +
> + priv->ops = &tegra_audio_graph_ops;
> + priv->force_dpcm = 1;
> +
> + memset(&li, 0, sizeof(li));
> + graph_get_dais_count(priv, &li);
> + if (!li.link || !li.dais)
> + return -EINVAL;
> +
> + err = asoc_simple_init_priv(priv, &li);
> + if (err < 0)
> + return err;
> +
> + err = graph_parse_of(priv);
> + if (err < 0) {
> + if (err != -EPROBE_DEFER)
> + dev_err(dev, "Parse error %d\n", err);
> + goto cleanup;
> + }
> +
> + snd_soc_card_set_drvdata(card, priv);
> +
> + asoc_simple_debug_info(priv);
> +
> + err = devm_snd_soc_register_card(dev, card);
> + if (err < 0)
> + goto cleanup;
> +
> + return 0;
> +
> +cleanup:
> + asoc_simple_clean_reference(card);
> +
> + return err;
> +}

These are almost same as graph_probe().
Maybe we can separate graph_probe() and export function ?

struct tegra_audio_graph_data
{
struct asoc_simple_priv simple;
...
};
#define simple_to_priv(_simple) container_of((_simple), struct my_priv, 
simple)

static int tegra_audio_graph_probe(struct platform_device *pdev)
{
struct tegra_audio_graph_data *data;
struct asoc_simple_priv *priv;

/* Allocate the private data */
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;

/* initial audio-graph */
ret = audio_graph_init(priv, pdev);
if (ret < 0)
return -xxx;

/* over-write for own settings */
card = simple_priv_to_card(priv);
card->component_chaining = true;
card->probe = tegra_audio_graph_card_probe;

priv = &data->simple;
priv->ops_hook_pre = &tegra_audio_graph_ops;
priv->force_dpcm = 1;

/* audio-graph remain */
return audio_graph_prove(priv, pdev);
}

Thank you for your help !!

Best regards
---
Kuninori Morimoto

linux-next: manual merge of the tip tree with the iommu tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  include/linux/iommu.h

between commits:

  23cc3493b5e1 ("iommu/uapi: Rename uapi functions")
  d90573812eea ("iommu/uapi: Handle data and argsz filled by users")

from the iommu tree and commit:

  c7b6bac9c72c ("drm, iommu: Change type of pasid to u32")

from the tip tree.

I fixed it up (I used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgptWE2NOZQWA.pgp
Description: OpenPGP digital signature

HALIFAX TRANSFER

[Susan]

--
Halifax bank PLC on behalf of UNICEF have released your Charity cash 
transfer of $76,000,000 to assist the less privilege and charity 
organizations of your choice for a 30% compensation.


Indicate if you are interested in handling this reputable charity 
project by providing your Identity & details to this email to commence 
this project.


Susan

[rcu:dev.2020.09.29a] BUILD SUCCESS 490b638d7c241ac06cee168ccf8688bb8b872478

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
dev.2020.09.29a
branch HEAD: 490b638d7c241ac06cee168ccf8688bb8b872478  kvfree_rcu(): Switch 
from kmalloc/kfree to __get_free_page/free_page.

elapsed time: 720m

configs tested: 122
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
sh  landisk_defconfig
sh sh03_defconfig
arm64alldefconfig
powerpc mpc832x_mds_defconfig
powerpc rainier_defconfig
m68kmvme147_defconfig
mipsmalta_kvm_guest_defconfig
um   x86_64_defconfig
sh   se7724_defconfig
xtensasmp_lx200_defconfig
arm am200epdkit_defconfig
powerpc mpc834x_mds_defconfig
powerpc  pcm030_defconfig
ia64generic_defconfig
archsdk_defconfig
arm ezx_defconfig
sh shx3_defconfig
mips cu1830-neo_defconfig
armmmp2_defconfig
powerpcgamecube_defconfig
mips  ath79_defconfig
arm  simpad_defconfig
s390   zfcpdump_defconfig
powerpc   ppc64_defconfig
powerpc  ppc6xx_defconfig
powerpc taishan_defconfig
arm   spitz_defconfig
h8300   defconfig
arm axm55xx_defconfig
m68km5307c3_defconfig
xtensa  audio_kc705_defconfig
microblaze  mmu_defconfig
powerpc  allmodconfig
nios2   defconfig
riscvalldefconfig
arm palmz72_defconfig
powerpc ksi8560_defconfig
shsh7785lcr_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc   allnoconfig
i386 randconfig-a003-20200930
i386 randconfig-a002-20200930
i386 randconfig-a006-20200930
i386 randconfig-a005-20200930
i386 randconfig-a004-20200930
i386 randconfig-a001-20200930
x86_64   randconfig-a015-20200930
x86_64   randconfig-a013-20200930
x86_64   randconfig-a012-20200930
x86_64   randconfig-a016-20200930
x86_64   randconfig-a014-20200930
x86_64   randconfig-a011-20200930
x86_64   randconfig-a012-20201001
x86_64   randconfig-a015-20201001
x86_64   randconfig-a014-20201001
x86_64   randconfig-a013-20201001
x86_64   randconfig-a011-20201001
x86_64   randconfig-a016-20201001
i386 randconfig-a011-20200930
i386 randconfig-a015-20200930
i386 randconfig-a012-20200930
i386 randconfig-a014-20200930
i386 randconfig-a016-20200930
i386 randconfig-a013-20200930
riscvnommu_k210_defconfig
riscvallyesconfig
riscv

Re: [PATCH v5 11/15] misc: bcm-vk: add BCM_VK_QSTATS

[Greg Kroah-Hartman]

On Thu, Oct 01, 2020 at 03:12:11PM -0700, Scott Branden wrote:
> 
> 
> On 2020-09-30 7:33 p.m., Florian Fainelli wrote:
> >
> >
> > On 9/30/2020 6:28 PM, Scott Branden wrote:
> >> Add BCM_VK_QSTATS Kconfig option to allow for enabling debug VK
> >> queue statistics.
> >>
> >> These statistics keep track of max, abs_max, and average for the
> >> messages queues.
> >>
> >> Co-developed-by: Desmond Yan 
> >> Signed-off-by: Desmond Yan 
> >> Signed-off-by: Scott Branden 
> >> ---
> >
> > [snip]
> >
> >> +#if defined(CONFIG_BCM_VK_QSTATS)
> >> +    /* clear qstats */
> >> +    for (i = 0; i < VK_MSGQ_MAX_NR; i++) {
> >> +    memset(&vk->to_v_msg_chan.qstats[i].qcnts, 0,
> >> +   sizeof(vk->to_v_msg_chan.qstats[i].qcnts));
> >> +    memset(&vk->to_h_msg_chan.qstats[i].qcnts, 0,
> >> +   sizeof(vk->to_h_msg_chan.qstats[i].qcnts));
> >> +    }
> >> +#endif
> >>   /* clear 4096 bits of bitmap */
> >>   bitmap_clear(vk->bmap, 0, VK_MSG_ID_BITMAP_SIZE);
> >
> > It was not clear from looking at this patch how are the statistics exposed 
> > and how does one actually get them?
> The QSTATS, since it is only for debug purpose, it will dump out periodically 
> based on processed_num.
> Nothing fancy as we only compile it in in extreme case for recreating a 
> scenario.
> 
> The following is the part:
> 
> +       if (++qcnts->cnt >= BCM_VK_QSTATS_ACC_CNT) {
> +               /* log average and clear counters */
> +               dev_info(&vk->pdev->dev,
> +                        "%s[%d]: Max: [%3d/%3d] Acc %d num %d, Aver %d\n",
> +                        tag, qstats->q_num,
> +                        qcnts->max_occ, qcnts->max_abs,
> +                        qcnts->acc_sum,
> +                        qcnts->cnt,
> +                        qcnts->acc_sum / qcnts->cnt);

Ah, that's not ok, don't flood the kernel log for non-error things
please.  If you need to "report" stuff, when all is going well, use the
other common interfaces for that.

Again, drivers, when all is working, are quiet.

thanks,

greg k-h

[PATCH 2/3] PCI: endpoint: Add endpoint restart management

[Kunihiko Hayashi]

Add new functions to manage recovery of configuration parameters and
restart the controller when asserting bus-reset from root-complex (RC).

This feature is only available if bus-reset (PERST#) line is physically
routed between RC and endpoint and the signal from RC affects endpoint.
This feature works as follows.

- This adds a polling thread, that polls and detects the bus-reset signal,
  and recovers configuration parameters for endpoint. The polling period
  is fixed at EPC_RESTART_POLL_PERIOD_MS.

- After the endpoint controller starts and the user sets configuration
  parameters using sysfs or function drivers, once RC asserts bus-reset
  and endpoint can receive it, the endpoint controller will also reset
  and initialize configuration parameters.

- If the thread detects bus-reset signal, the thread stops the controller,
  unbinds it, quickly binds it and restart it. The configuration
  paremters are restored to the user's values.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/pci/endpoint/Kconfig   |   9 +++
 drivers/pci/endpoint/Makefile  |   1 +
 drivers/pci/endpoint/pci-epc-restart.c | 114 +
 include/linux/pci-epc.h|  15 +
 4 files changed, 139 insertions(+)
 create mode 100644 drivers/pci/endpoint/pci-epc-restart.c

diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index 17bbdc9..016c82a 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -28,6 +28,15 @@ config PCI_ENDPOINT_CONFIGFS
   configure the endpoint function and used to bind the
   function with a endpoint controller.
 
+config PCI_ENDPOINT_RESTART
+   bool "PCI Endpoint Restart Management Support"
+   depends on PCI_ENDPOINT
+   help
+  Enable restart management functions, which detects bus-reset
+  from root complex, and recover endpoint configuration.
+  This is only available if bus-reset line is physically routed
+  between root complex and endpoint.
+
 source "drivers/pci/endpoint/functions/Kconfig"
 
 endmenu
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
index 95b2fe4..7301aea 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -4,5 +4,6 @@
 #
 
 obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS)+= pci-ep-cfs.o
+obj-$(CONFIG_PCI_ENDPOINT_RESTART) += pci-epc-restart.o
 obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
   pci-epc-mem.o functions/
diff --git a/drivers/pci/endpoint/pci-epc-restart.c 
b/drivers/pci/endpoint/pci-epc-restart.c
new file mode 100644
index 000..ab956be
--- /dev/null
+++ b/drivers/pci/endpoint/pci-epc-restart.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * PCI Endpoint Controller Restart Management
+ *
+ * Copyright (C) 2019-2020 Socionext Inc.
+ * Author: Kunihiko Hayashi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EPC_RESTART_POLL_PERIOD_MS 80
+
+static int pci_epc_restart_thread(void *dev_id)
+{
+   struct pci_epc *epc = dev_id;
+   struct pci_epf *epf;
+   int ret = 0;
+
+   dev_info(&epc->dev, "[epc-restart] thread start\n");
+
+   while (!kthread_should_stop()) {
+   if (epc->restart_poll) {
+   /* call polling function */
+   ret = epc->restart_poll(epc->restart_poll_data);
+   if (!ret) {
+   msleep(EPC_RESTART_POLL_PERIOD_MS);
+   continue;
+   } else if (ret < 0) {
+   break;
+   }
+   } else {
+   /* wait for interrupt */
+   ret = 
wait_for_completion_interruptible(&epc->restart_comp);
+   if (ret <= 0)
+   break;
+   }
+
+   if (!pci_epc_is_started(epc))
+   continue;
+
+   /*
+* After stop linkup, call unbind() once and call bind() again.
+* to reload config parameters to the controller.
+*/
+   pci_epc_stop(epc);
+   list_for_each_entry(epf, &epc->pci_epf, list) {
+   pci_epf_unbind(epf);
+   pci_epf_bind(epf);
+   }
+   pci_epc_start(epc);
+
+   dev_info(&epc->dev, "[epc-restart] assert\n");
+   }
+
+   dev_info(&epc->dev, "[epc-restart] thread exit\n");
+
+   return ret;
+}
+
+/**
+ * pci_epc_restart_init() - initialize epc-restart thread
+ * @epc: the EPC device
+ */
+int pci_epc_restart_init(struct pci_epc *epc)
+{
+   init_completion(&epc->restart_comp);
+
+   epc->restart_task = kthread_run(pci_epc_restart_thread, epc,
+   "pci-epc-restart");
+   if (IS_ERR(epc->restart_task))
+ 

[PATCH 0/3] PCI: endpoint: Add endpoint restart management support

[Kunihiko Hayashi]

Add new functions to manage recovery of configuration for endpoint controller
and restart the controller when asserting bus-reset from root complex (RC).

This feature is only available if bus-reset (PERST#) line is physically
routed between RC and endpoint, and the signal from RC also resets
the endpoint controller.

This series is only for UniPhier PCIe endpoint controller at this point.

Kunihiko Hayashi (3):
  PCI: endpoint: Add 'started' to pci_epc to set whether the controller
is started
  PCI: endpoint: Add endpoint restart management
  PCI: uniphier-ep: Add EPC restart management support

 drivers/pci/controller/dwc/Kconfig|   1 +
 drivers/pci/controller/dwc/pcie-uniphier-ep.c |  34 +++-
 drivers/pci/endpoint/Kconfig  |   9 ++
 drivers/pci/endpoint/Makefile |   1 +
 drivers/pci/endpoint/pci-epc-core.c   |   2 +
 drivers/pci/endpoint/pci-epc-restart.c| 114 ++
 include/linux/pci-epc.h   |  22 +
 7 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pci/endpoint/pci-epc-restart.c

-- 
2.7.4

[PATCH 3/3] PCI: uniphier-ep: Add EPC restart management support

[Kunihiko Hayashi]

Set the polling function and call the init function to enable EPC restart
management. The polling function detects that the bus-reset signal is a
rising edge.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/pci/controller/dwc/Kconfig|  1 +
 drivers/pci/controller/dwc/pcie-uniphier-ep.c | 34 +--
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index bc04986..4932095 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -296,6 +296,7 @@ config PCIE_UNIPHIER_EP
depends on OF && HAS_IOMEM
depends on PCI_ENDPOINT
select PCIE_DW_EP
+   select PCI_ENDPOINT_RESTART
help
  Say Y here if you want PCIe endpoint controller support on
  UniPhier SoCs. This driver supports Pro5 SoC.
diff --git a/drivers/pci/controller/dwc/pcie-uniphier-ep.c 
b/drivers/pci/controller/dwc/pcie-uniphier-ep.c
index 1483559..bd187b1 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier-ep.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier-ep.c
@@ -26,6 +26,7 @@
 #define PCL_RSTCTRL_PIPE3  BIT(0)
 
 #define PCL_RSTCTRL1   0x0020
+#define PCL_RSTCTRL_PERST_MON  BIT(16)
 #define PCL_RSTCTRL_PERST  BIT(0)
 
 #define PCL_RSTCTRL2   0x0024
@@ -60,6 +61,7 @@ struct uniphier_pcie_ep_priv {
struct clk *clk, *clk_gio;
struct reset_control *rst, *rst_gio;
struct phy *phy;
+   bool bus_reset_status;
const struct pci_epc_features *features;
 };
 
@@ -218,6 +220,23 @@ static const struct dw_pcie_ep_ops uniphier_pcie_ep_ops = {
.get_features = uniphier_pcie_get_features,
 };
 
+static bool uniphier_pcie_ep_poll_reset(void *data)
+{
+   struct uniphier_pcie_ep_priv *priv = data;
+   bool ret, status;
+
+   if (!priv)
+   return false;
+
+   status = !(readl(priv->base + PCL_RSTCTRL1) & PCL_RSTCTRL_PERST_MON);
+
+   /* return true if the rising edge of bus reset is detected */
+   ret = !!(status == false && priv->bus_reset_status == true);
+   priv->bus_reset_status = status;
+
+   return ret;
+}
+
 static int uniphier_add_pcie_ep(struct uniphier_pcie_ep_priv *priv,
struct platform_device *pdev)
 {
@@ -241,10 +260,21 @@ static int uniphier_add_pcie_ep(struct 
uniphier_pcie_ep_priv *priv,
ep->addr_size = resource_size(res);
 
ret = dw_pcie_ep_init(ep);
-   if (ret)
+   if (ret) {
dev_err(dev, "Failed to initialize endpoint (%d)\n", ret);
+   return ret;
+   }
 
-   return ret;
+   /* Set up epc-restart thread */
+   pci_epc_restart_register_poll_func(ep->epc,
+   uniphier_pcie_ep_poll_reset, priv);
+   /* With call of poll_reset() directly, initialize internal state */
+   uniphier_pcie_ep_poll_reset(priv);
+   ret = pci_epc_restart_init(ep->epc);
+   if (ret)
+   dev_err(dev, "Failed to initialize epc-restart (%d)\n", ret);
+
+   return 0;
 }
 
 static int uniphier_pcie_ep_enable(struct uniphier_pcie_ep_priv *priv)
-- 
2.7.4

[PATCH 1/3] PCI: endpoint: Add 'started' to pci_epc to set whether the controller is started

[Kunihiko Hayashi]

This adds a member 'started' as a boolean value to struct pci_epc to set
whether the controller is started, and also adds a function to get the
value.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/pci/endpoint/pci-epc-core.c | 2 ++
 include/linux/pci-epc.h | 7 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index cadd3db..155be574 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -148,6 +148,7 @@ void pci_epc_stop(struct pci_epc *epc)
 
mutex_lock(&epc->lock);
epc->ops->stop(epc);
+   epc->started = false;
mutex_unlock(&epc->lock);
 }
 EXPORT_SYMBOL_GPL(pci_epc_stop);
@@ -170,6 +171,7 @@ int pci_epc_start(struct pci_epc *epc)
 
mutex_lock(&epc->lock);
ret = epc->ops->start(epc);
+   epc->started = true;
mutex_unlock(&epc->lock);
 
return ret;
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index cc66bec..d875d2d 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -107,6 +107,7 @@ struct pci_epc_mem {
  * @lock: mutex to protect pci_epc ops
  * @function_num_map: bitmap to manage physical function number
  * @notifier: used to notify EPF of any EPC events (like linkup)
+ * @started: true if this EPC is started
  */
 struct pci_epc {
struct device   dev;
@@ -121,6 +122,7 @@ struct pci_epc {
struct mutexlock;
unsigned long   function_num_map;
struct atomic_notifier_head notifier;
+   boolstarted;
 };
 
 /**
@@ -167,6 +169,11 @@ pci_epc_register_notifier(struct pci_epc *epc, struct 
notifier_block *nb)
return atomic_notifier_chain_register(&epc->notifier, nb);
 }
 
+static inline bool pci_epc_is_started(struct pci_epc *epc)
+{
+   return epc->started;
+}
+
 struct pci_epc *
 __devm_pci_epc_create(struct device *dev, const struct pci_epc_ops *ops,
  struct module *owner);
-- 
2.7.4

Re: [PATCH 0/8] Add support for UHS modes in TI's J721e and J7200 boards

[Faiz Abbas]

Hi Nishanth,

On 02/10/20 12:43 am, Nishanth Menon wrote:
> On 00:35-20201002, Faiz Abbas wrote:
>> The following patches add support for UHS modes for TI's j721e and j7200
>> boards.
>>
>> Patches 1-3 add support for gpios to j7200-evm
>>
>> Patches 4-6 add support for voltage regulators for required by the
>> SD card in both devices as well as enable UHS modes at 1.8V
>>
>> Patches 5-6 add some required configs to the arm64 defconfig.
>>
>> This series depends on driver patches adding tuning support here:
>> https://lore.kernel.org/linux-arm-kernel/20200923105206.7988-1-faiz_ab...@ti.com/
>>
>> Faiz Abbas (8):
>>   arm64: dts: ti: k3-j7200-main: Add gpio nodes in main domain
>>   arm64: dts: ti: k3-j7200: Add gpio nodes in wakeup domain
>>   arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio
>> modules
>>   arm64: dts: ti: k3-j721e-main: Add output tap delay values
>>   arm64: dts: ti: k3-j721e-common-proc-board: Add support SD card UHS
>> modes
>>   arm64: dts: ti: k3-j7200-common-proc-board: Add support SD card UHS
>> modes
> 
> Split these up please!

Into SD card UHS and gpio series?

>>   arm64: defconfig: Enable OMAP I2C driver
>>   arm64: defconfig: Enable DAVINCI_GPIO driver
>>
> 
> defconfig patches can be posted independent of dts patches, they go to
> different branches.

I was trying to follow Arnd's advice here:
https://lore.kernel.org/linux-arm-kernel/CAK8P3a1JpCCCV-CVQj3+eMfWF+=4auhppv390tyj2pkn63_...@mail.gmail.com/

He says that defconfig patches can be sent at the same time as dts updates and 
maintainers can send those
as separate pull requests.

Thanks,
Faiz

Re: [PATCH 1/2] rcu/tree: Add a warning if CPU being onlined did not report QS already

[Paul E. McKenney]

On Tue, Sep 29, 2020 at 03:29:27PM -0400, Joel Fernandes (Google) wrote:
> Currently, rcu_cpu_starting() checks to see if the RCU core expects a
> quiescent state from the incoming CPU.  However, the current interaction
> between RCU quiescent-state reporting and CPU-hotplug operations should
> mean that the incoming CPU never needs to report a quiescent state.
> First, the outgoing CPU reports a quiescent state if needed.  Second,
> the race where the CPU is leaving just as RCU is initializing a new
> grace period is handled by an explicit check for this condition.  Third,
> the CPU's leaf rcu_node structure's ->lock serializes these checks.
> 
> This means that if rcu_cpu_starting() ever feels the need to report
> a quiescent state, then there is a bug somewhere in the CPU hotplug
> code or the RCU grace-period handling code.  This commit therefore
> adds a WARN_ON_ONCE() to bring that bug to everyone's attention.
> 
> Cc: Paul E. McKenney 
> Cc: Neeraj Upadhyay 
> Suggested-by: Paul E. McKenney 
> Signed-off-by: Joel Fernandes (Google) 

Queued for testing and further review, thank you!

Thanx, Paul

> ---
>  kernel/rcu/tree.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 55d3700dd1e7..5efe0a98ea45 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -4119,7 +4119,9 @@ void rcu_cpu_starting(unsigned int cpu)
>   rcu_gpnum_ovf(rnp, rdp); /* Offline-induced counter wrap? */
>   rdp->rcu_onl_gp_seq = READ_ONCE(rcu_state.gp_seq);
>   rdp->rcu_onl_gp_flags = READ_ONCE(rcu_state.gp_flags);
> - if (rnp->qsmask & mask) { /* RCU waiting on incoming CPU? */
> +
> + /* An incoming CPU should never be blocking a grace period. */
> + if (WARN_ON_ONCE(rnp->qsmask & mask)) { /* RCU waiting on incoming CPU? 
> */
>   rcu_disable_urgency_upon_qs(rdp);
>   /* Report QS -after- changing ->qsmaskinitnext! */
>   rcu_report_qs_rnp(mask, rnp, rnp->gp_seq, flags);
> -- 
> 2.28.0.709.gb0816b6eb0-goog
> 

[PATCH v2] x86/dumpstack: Fix misleading instruction pointer error message

[Mark Mossberg]

Printing "Bad RIP value" if copy_code() fails can be misleading for
userspace pointers, since copy_code() can fail if the instruction
pointer is valid, but the code is paged out. This is because copy_code()
calls copy_from_user_nmi() for userspace pointers, which disables page
fault handling.

This is reproducible in OOM situations, where it's plausible that the
code may be reclaimed in the time between entry into the kernel and when
this message is printed. This leaves a misleading log in dmesg that
suggests instruction pointer corruption has occurred, which may alarm
users.

This patch changes the message to state the error condition more
precisely.

Thanks to Jann Horn for help with understanding OOM reclamation.

Signed-off-by: Mark Mossberg 
---
 arch/x86/kernel/dumpstack.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 48ce44576947..ea8d51ec251b 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -115,7 +115,8 @@ void show_opcodes(struct pt_regs *regs, const char *loglvl)
unsigned long prologue = regs->ip - PROLOGUE_SIZE;
 
if (copy_code(regs, opcodes, prologue, sizeof(opcodes))) {
-   printk("%sCode: Bad RIP value.\n", loglvl);
+   printk("%sCode: Unable to access opcode bytes at RIP 0x%lx.\n",
+  loglvl, prologue);
} else {
printk("%sCode: %" __stringify(PROLOGUE_SIZE) "ph <%02x> %"
   __stringify(EPILOGUE_SIZE) "ph\n", loglvl, opcodes,
-- 
2.25.1

Re: WARNING in cfg80211_connect

[syzbot]

syzbot has bisected this issue to:

commit 16d4d43595b4780daac8fcea6d042689124cb094
Author: Christoph Hellwig 
Date:   Wed Jul 20 01:38:55 2016 +

xfs: split direct I/O and DAX path

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=14f662b790
start commit:   87d5034d Merge tag 'mlx5-updates-2020-09-30' of git://git...
git tree:   net-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=16f662b790
console output: https://syzkaller.appspot.com/x/log.txt?x=12f662b790
kernel config:  https://syzkaller.appspot.com/x/.config?x=7b5cc8ec2218e99d
dashboard link: https://syzkaller.appspot.com/bug?extid=5f9392825de654244975
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1100d33390
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1414c99790

Reported-by: syzbot+5f9392825de654244...@syzkaller.appspotmail.com
Fixes: 16d4d43595b4 ("xfs: split direct I/O and DAX path")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

drivers/gpu/drm/i915/gt/intel_workarounds.c:1082:20: error: function 'is_nonpriv_flags_valid' is not needed and will not be emitted

[kernel test robot]

Hi Nick,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   60e720931556fc1034d0981460164dcf02697679
commit: 9f4069b055d1508c833115df7493b6e0001e5c9b drm/i915: re-disable 
-Wframe-address
date:   5 months ago
config: x86_64-randconfig-a005-20201001 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
bcd05599d0e53977a963799d6ee4f6e0bc21331b)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f4069b055d1508c833115df7493b6e0001e5c9b
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 9f4069b055d1508c833115df7493b6e0001e5c9b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gt/intel_workarounds.c:1082:20: error: function 
>> 'is_nonpriv_flags_valid' is not needed and will not be emitted 
>> [-Werror,-Wunneeded-internal-declaration]
   static inline bool is_nonpriv_flags_valid(u32 flags)
  ^
   1 error generated.
--
>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:259:19: error: unused 
>> function 'rq_prio' [-Werror,-Wunused-function]
   static inline int rq_prio(const struct i915_request *rq)
 ^
   1 error generated.
--
>> drivers/gpu/drm/i915/gvt/gtt.c:267:19: error: unused function 'get_pt_type' 
>> [-Werror,-Wunused-function]
   static inline int get_pt_type(int type)
 ^
>> drivers/gpu/drm/i915/gvt/gtt.c:590:20: error: unused function 
>> 'ppgtt_set_guest_root_entry' [-Werror,-Wunused-function]
   static inline void ppgtt_set_guest_root_entry(struct intel_vgpu_mm *mm,
  ^
   2 errors generated.

vim +/is_nonpriv_flags_valid +1082 drivers/gpu/drm/i915/gt/intel_workarounds.c

094304beb4e1f4 drivers/gpu/drm/i915/intel_workarounds.cTvrtko Ursulin 
2018-12-03  1081  
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12 @1082  static inline bool is_nonpriv_flags_valid(u32 flags)
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1083  {
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1084  /* Check only valid flag bits are set */
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1085  if (flags & ~RING_FORCE_TO_NONPRIV_MASK_VALID)
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1086  return false;
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1087  
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1088  /* NB: Only 3 out of 4 enum values are valid for access 
field */
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1089  if ((flags & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1090  RING_FORCE_TO_NONPRIV_ACCESS_INVALID)
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1091  return false;
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1092  
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1093  return true;
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1094  }
1e2b7f497c28a4 drivers/gpu/drm/i915/gt/intel_workarounds.c John Harrison  
2019-07-12  1095  

:: The code at line 1082 was first introduced by commit
:: 1e2b7f497c28a47793a95d8f0cc8e135899827f1 drm/i915: Add test for invalid 
flag bits in whitelist entries

:: TO: John Harrison 
:: CC: Tvrtko Ursulin 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH 1/2] scsi: ufs: Use memset to initialize variable in ufshcd_crypto_keyslot_program

[Eric Biggers]

On Fri, Oct 02, 2020 at 12:05:17PM +0800, Pujin Shi wrote:
> Clang warns:
> 
> drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: missing braces around 
> initializer [-Wmissing-braces]
>   union ufs_crypto_cfg_entry cfg = { 0 };
> ^
> 

Which version of clang?  I don't see the warning with clang 10.0.1
(or with gcc 10.2.0).

> Signed-off-by: Pujin Shi 
> ---
>  drivers/scsi/ufs/ufshcd-crypto.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd-crypto.c 
> b/drivers/scsi/ufs/ufshcd-crypto.c
> index d2edbd960ebf..8fca2a40c517 100644
> --- a/drivers/scsi/ufs/ufshcd-crypto.c
> +++ b/drivers/scsi/ufs/ufshcd-crypto.c
> @@ -59,9 +59,11 @@ static int ufshcd_crypto_keyslot_program(struct 
> blk_keyslot_manager *ksm,
>   u8 data_unit_mask = key->crypto_cfg.data_unit_size / 512;
>   int i;
>   int cap_idx = -1;
> - union ufs_crypto_cfg_entry cfg = { 0 };
> + union ufs_crypto_cfg_entry cfg;
>   int err;
>  
> + memset(&cfg, 0, sizeof(cfg));
> +

How about an empty initializer?

union ufs_crypto_cfg_entry cfg = {};

Same comments on your other patch.

- Eric

Re: [PATCH v7 07/13] PCI/AER: Extend AER error handling to RCECs

[Sean V Kelley]

On 1 Oct 2020, at 16:14, Bjorn Helgaas wrote:


On Wed, Sep 30, 2020 at 02:58:14PM -0700, Sean V Kelley wrote:

From: Jonathan Cameron 

Currently the kernel does not handle AER errors for Root Complex
integrated End Points (RCiEPs)[0]. These devices sit on a root bus 
within
the Root Complex (RC). AER handling is performed by a Root Complex 
Event
Collector (RCEC) [1] which is a effectively a type of RCiEP on the 
same

root bus.

For an RCEC (technically not a Bridge), error messages "received" 
from
associated RCiEPs must be enabled for "transmission" in order to 
cause a
System Error via the Root Control register or (when the Advanced 
Error

Reporting Capability is present) reporting via the Root Error Command
register and logging in the Root Error Status register and Error 
Source

Identification register.

In addition to the defined OS level handling of the reset flow for 
the

associated RCiEPs of an RCEC, it is possible to also have non-native
handling. In that case there is no need to take any actions on the 
RCEC
because the firmware is responsible for them. This is true where APEI 
[2]

is used to report the AER errors via a GHES[v2] HEST entry [3] and
relevant AER CPER record [4] and non-native handling is in use.

We effectively end up with two different types of discovery for
purposes of handling AER errors:

1) Normal bus walk - we pass the downstream port above a bus to which
the device is attached and it walks everything below that point.

2) An RCiEP with no visible association with an RCEC as there is no 
need
to walk devices. In that case, the flow is to just call the callbacks 
for

the actual device, which in turn references its associated RCEC.

A new walk function pci_walk_bridge(), similar to pci_walk_bus(),
is provided that takes a pci_dev instead of a bus. If that bridge
corresponds to a downstream port it will walk the subordinate bus of
that bridge. If the device does not then it will call the function on
that device alone.

[0] ACPI PCI Express Base Specification 5.0-1 1.3.2.3 Root Complex
Integrated Endpoint Rules.
[1] ACPI PCI Express Base Specification 5.0-1 6.2 Error Signalling 
and

Logging
[2] ACPI Specification 6.3 Chapter 18 ACPI Platform Error Interface 
(APEI)

[3] ACPI Specification 6.3 18.2.3.7 Generic Hardware Error Source
[4] UEFI Specification 2.8, N.2.7 PCI Express Error Section

Signed-off-by: Jonathan Cameron 
Signed-off-by: Sean V Kelley 
---
 drivers/pci/pcie/err.c | 52 
+-

 1 file changed, 41 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 9e552330155b..c4ceca42a3bf 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -146,44 +146,73 @@ static int report_resume(struct pci_dev *dev, 
void *data)

return 0;
 }

+/**
+ * pci_walk_bridge - walk bridges potentially AER affected
+ * @bridge   bridge which may be an RCEC with associated RCiEPs,
+ *   an RCiEP associated with an RCEC, or a Port.
+ * @cb   callback to be called for each device found
+ * @userdata arbitrary pointer to be passed to callback.
+ *
+ * If the device provided is a bridge, walk the subordinate bus,
+ * including any bridged devices on buses under this bus.
+ * Call the provided callback on each device found.
+ *
+ * If the device provided has no subordinate bus, call the provided
+ * callback on the device itself.
+ */
+static void pci_walk_bridge(struct pci_dev *bridge, int (*cb)(struct 
pci_dev *, void *),

+   void *userdata)
+{
+   if (bridge->subordinate)
+   pci_walk_bus(bridge->subordinate, cb, userdata);
+   else
+   cb(bridge, userdata);
+}
+
 pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_channel_state_t state,
 			pci_ers_result_t (*reset_subordinate_devices)(struct pci_dev 
*pdev))

 {
pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
-   struct pci_bus *bus;
struct pci_dev *bridge;
int type;

/*
 * Error recovery runs on all subordinates of the first downstream
 * bridge. If the downstream bridge detected the error, it is
-* cleared at the end.
+	 * cleared at the end. For RCiEPs we should reset just the RCiEP 
itself.

 */
type = pci_pcie_type(dev);
if (type == PCI_EXP_TYPE_ROOT_PORT ||
-   type == PCI_EXP_TYPE_DOWNSTREAM)
+   type == PCI_EXP_TYPE_DOWNSTREAM ||
+   type == PCI_EXP_TYPE_RC_EC ||
+   type == PCI_EXP_TYPE_RC_END)
bridge = dev;
else
bridge = pci_upstream_bridge(dev);

-   bus = bridge->subordinate;
pci_dbg(dev, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
-   pci_walk_bus(bus, report_frozen_detected, &status);
-   status = reset_subordinate_device(dev);
+   pci_walk_bridge(bridge, report_frozen_detecte

linux-next: build warning after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

sound/soc/fsl/fsl_spdif.c: In function 'fsl_spdif_probe':
sound/soc/fsl/fsl_spdif.c:1255:22: warning: unused variable 'np' 
[-Wunused-variable]
 1255 |  struct device_node *np = pdev->dev.of_node;
  |  ^~

Introduced by commit

  601fd3a7d849 ("ASoC: fsl_spdif: Fix unnecessary check in fsl_spdif_probe()")

-- 
Cheers,
Stephen Rothwell


pgpQ2KRRqO0KP.pgp
Description: OpenPGP digital signature

Re: dsa: mv88e6xxx: serdes link without phy

[Chris Packham]

On 2/10/20 1:36 am, Andrew Lunn wrote:
>>> Can you run 1000Base-X over these links?
>> With some reading "1000base-x" does seem the right thing to say here.
>> It's even what is reflected in the CMODE field for those ports.
> One more thing you might need is
>
> managed = "in-band-status";
>
>>> If you can, it is probably
>>> worth chatting to Russell King about using inband-signalling, and what
>>> is needed to make it work without having back to back SFPs. If i
>>> remember correctly, Russell has said not much is actually needed.
>> That'd be ideal. The sticking point seems to be allowing it to have no PHY.
> I think there is more to it than that. This is new ground to some
> extent.

managed = "in-band-status"; helps to convince things that there isn't a 
PHY. I need to update mv88e6xxx_mac_link_up to not force the link when 
mode == MLO_AN_INBAND.

I also have a problem with mv88e6xxx_serdes_pcs_get_state expecting 
mv88e6xxx_serdes_get_lane() to return a lane number. Implementing 
mv88e6xxx_serdes_get_lane() for the mv88e6097 causes a lot of other code 
paths to trigger which didn't before. I think I'm close to getting 
something sensible working for my hardware but I'm off on leave for a 
week so I just wanted to get this out before I go.

Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()

[Guenter Roeck]

On 10/1/20 3:22 PM, Andreas Kemnade wrote:
> On Wed, 30 Sep 2020 22:00:09 +0200
> Arnd Bergmann  wrote:
> 
>> On Wed, Sep 30, 2020 at 6:44 PM Guenter Roeck  wrote:
>>>
>>> On Wed, Sep 30, 2020 at 10:54:42AM +0200, Andreas Kemnade wrote:  
 Hi,

 after the $subject patch I get lots of errors like this:  
>>>
>>> For reference, this refers to commit fff2d0f701e6 ("hwmon: (applesmc)
>>> avoid overlong udelay()").
>>>  
 [  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
 [  120.378621] applesmc: LKSB: write data fail
 [  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
 [  120.512787] applesmc: LKSB: write data fail

 CPU sticks at low speed and no fan is turning on.
 Reverting this patch on top of 5.9-rc6 solves this problem.

 Some information from dmidecode:

 Base Board Information
 Manufacturer: Apple Inc.
 Product Name: Mac-7DF21CB3ED6977E5
 Version: MacBookAir6,2

 Handle 0x0020, DMI type 11, 5 bytes OEM Strings String 1: Apple 
 ROM Version.  Model:   …,
 Handle 0x0020, DMI type 11, 5 bytes
 OEM Strings
 String 1: Apple ROM Version.  Model:MBA61.  EFI Version:  
 122.0.0
 String 2: .0.0.  Built by: root@saumon.  Date: Wed Jun 
 10 18:
 String 3: 10:36 PDT 2020.  Revision: 122 (B&I).  ROM Version:  
 F000_B
 String 4: 00.  Build Type:   Official Build, Release.  Compiler:   
   Appl
 String 5: e clang version 3.0 (tags/Apple/clang-211.10.1) (based 
 on LLVM
 String 6: 3.0svn).

 Writing to things in /sys/devices/platform/applesmc.768 gives also the
 said errors.
 But writing 1 to fan1_maunal and 5000 to fan1_output turns the fan on
 despite error messages.
  
>>> Not really sure what to do here. I could revert the patch, but then we'd 
>>> gain
>>> clang compile failures. Arnd, any idea ?  
>>
>> It seems that either I made a mistake in the conversion and it sleeps for
>> less time than before, or my assumption was wrong that converting a delay to
>> a sleep is safe here.
>>
>> The error message indicates that the write fails, not the read, so that
>> is what I'd look at first. Right away I can see that the maximum time to
>> retry is only half of what it used to be, as we used to wait for
>> 0x10, 0x20, 0x40, 0x80, ..., 0x2 microseconds for a total of
>> 0x3fff0 microseconds (262ms), while my patch went with the 131ms
>> total delay based on the comment saying "/* wait up to 128 ms for a
>> status change. */".
>>
> Yes, that is also what I read from the code. I just thought there must
> be something simple, which just needs a short look from another pair of
> eyes.
> 
>> Since there is sleeping wait, I see no reason the timeout couldn't
>> be extended a lot, e.g. to a second, as in
>>
>> #define APPLESMC_MAX_WAIT 0x10
>>
>> If that doesn't work, I'd try using mdelay() in place of
>> usleep_range(), such as
>>
>>mdelay(DIV_ROUND_UP(us, USEC_PER_MSEC)));
>>
>> This adds back a really nasty latency, but it should avoid the
>> compile-time problem.
>>
>> Andreas, can you try those two things? (one at a time,
>> not both)
> 
> Ok, I tried. None of them works. I rechecked my work and created real
> git commits out of them and CONFIG_LOCALVERSION_AUTO is also set so
> the usual stupid things are rules out.
> In detail:
> On top of 5.9-rc6 + *reverted* patch:
> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> index fd99c9df8a00..2a9bd7f2b71b 100644
> --- a/drivers/hwmon/applesmc.c
> +++ b/drivers/hwmon/applesmc.c
> @@ -45,7 +45,7 @@
>  /* wait up to 128 ms for a status change. */
>  #define APPLESMC_MIN_WAIT0x0010
>  #define APPLESMC_RETRY_WAIT  0x0100
> -#define APPLESMC_MAX_WAIT0x2
> +#define APPLESMC_MAX_WAIT0x8000
>  
>  #define APPLESMC_READ_CMD0x10
>  #define APPLESMC_WRITE_CMD   0x11
> 

Oh man, that code is so badlys broken.

send_byte() repeats sending the data if it was not immediately successful.
That is done for both data and commands. Effectively that happens if
the command is not immediately accepted. However, send_argument()
clearly assumes that each data byte is sent exactly once. Sending
it more than once will mess up the key that is supposed to be sent.
The Apple SMC emulation code in qemu confirms that data bytes can not
be written more than once.

Of course, theoretically it may be that the first data byte was not
accepted (after all, the ACK bit is not set), but the ACK bit is
not checked again after udelay(APPLESMC_RETRY_WAIT), so it may
well have been set in the 256 uS between its check and re-writing
the data.

In other words, this entire code only works accidentally to start with.

If you like, you could play around with the code and find out if and
when exactly bit 1 (busy) is set, if and when bit 2 (ack) is set, and
if and when any other bit is set. 

[PATCH 2/2] scsi: ufs: Use memset to initialize variable in ufshcd_clear_keyslot

[Pujin Shi]

Clang warns:

drivers/scsi/ufs/ufshcd-crypto.c:103:8: warning: missing braces around 
initializer [-Wmissing-braces]
  union ufs_crypto_cfg_entry cfg = { 0 };
^

Signed-off-by: Pujin Shi 
---
 drivers/scsi/ufs/ufshcd-crypto.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
index 8fca2a40c517..bd439021ccce 100644
--- a/drivers/scsi/ufs/ufshcd-crypto.c
+++ b/drivers/scsi/ufs/ufshcd-crypto.c
@@ -103,6 +103,9 @@ static int ufshcd_clear_keyslot(struct ufs_hba *hba, int 
slot)
 * might not be sufficient, so just clear the entire cfg.
 */
union ufs_crypto_cfg_entry cfg = { 0 };
+   union ufs_crypto_cfg_entry cfg;
+
+   memset(&cfg, 0, sizeof(cfg));
 
return ufshcd_program_key(hba, &cfg, slot);
 }
-- 
2.18.1

[PATCH 1/2] scsi: ufs: Use memset to initialize variable in ufshcd_crypto_keyslot_program

[Pujin Shi]

Clang warns:

drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: missing braces around 
initializer [-Wmissing-braces]
  union ufs_crypto_cfg_entry cfg = { 0 };
^

Signed-off-by: Pujin Shi 
---
 drivers/scsi/ufs/ufshcd-crypto.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
index d2edbd960ebf..8fca2a40c517 100644
--- a/drivers/scsi/ufs/ufshcd-crypto.c
+++ b/drivers/scsi/ufs/ufshcd-crypto.c
@@ -59,9 +59,11 @@ static int ufshcd_crypto_keyslot_program(struct 
blk_keyslot_manager *ksm,
u8 data_unit_mask = key->crypto_cfg.data_unit_size / 512;
int i;
int cap_idx = -1;
-   union ufs_crypto_cfg_entry cfg = { 0 };
+   union ufs_crypto_cfg_entry cfg;
int err;
 
+   memset(&cfg, 0, sizeof(cfg));
+
BUILD_BUG_ON(UFS_CRYPTO_KEY_SIZE_INVALID != 0);
for (i = 0; i < hba->crypto_capabilities.num_crypto_cap; i++) {
if (ccap_array[i].algorithm_id == alg->ufs_alg &&
-- 
2.18.1

Re: linux-next: manual merge of the bpf-next tree with the bpf tree

[Stephen Rothwell]

Hi all,

On Wed, 30 Sep 2020 14:07:15 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/lib/bpf/btf.c
> 
> between commit:
> 
>   1245008122d7 ("libbpf: Fix native endian assumption when parsing BTF")
> 
> from the bpf tree and commit:
> 
>   3289959b97ca ("libbpf: Support BTF loading and raw data output in both 
> endianness")
> 
> from the bpf-next tree.
> 
> I fixed it up (I used the latter version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This is now a conflict between the net-next and net trees.
-- 
Cheers,
Stephen Rothwell


pgpwaOh611k1j.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c

between commit:

  b19515253623 ("drm/amd/pm: setup APU dpm clock table in SMU HW 
initialization")

from the Linus tree and commits:

  82cac71c1b64 ("drm/amd/pm: put Navi1X umc cdr workaround in post_smu_init")
  236b156f7388 ("drm/amd/pm: apply no power source workaround if dc reported by 
gpio")
  1653a179c822 ("drm/amd/pm: move NAVI1X power mode switching workaround to 
post_init")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 8dc5abb6931e,5c4b74f964fc..
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@@ -955,35 -1013,6 +1002,17 @@@ static int smu_smc_hw_setup(struct smu_
return ret;
}
  
-   ret = smu_disable_umc_cdr_12gbps_workaround(smu);
-   if (ret) {
-   dev_err(adev->dev, "Workaround failed to disable UMC CDR 
feature on 12Gbps SKU!\n");
-   return ret;
-   }
- 
-   /*
-* For Navi1X, manually switch it to AC mode as PMFW
-* may boot it with DC mode.
-*/
-   ret = smu_set_power_source(smu,
-  adev->pm.ac_power ? SMU_POWER_SOURCE_AC :
-  SMU_POWER_SOURCE_DC);
-   if (ret) {
-   dev_err(adev->dev, "Failed to switch to %s mode!\n", 
adev->pm.ac_power ? "AC" : "DC");
-   return ret;
-   }
- 
 +  /*
 +   * Set initialized values (get from vbios) to dpm tables context such as
 +   * gfxclk, memclk, dcefclk, and etc. And enable the DPM feature for each
 +   * type of clks.
 +   */
 +  ret = smu_set_default_dpm_table(smu);
 +  if (ret) {
 +  dev_err(adev->dev, "Failed to setup default dpm clock 
tables!\n");
 +  return ret;
 +  }
 +
ret = smu_notify_display_change(smu);
if (ret)
return ret;


pgpNa4QYOhfcn.pgp
Description: OpenPGP digital signature

[tip:x86/misc] BUILD SUCCESS f94c91f7ba3ba7de2bc8aa31be28e1abb22f849e

[kernel test robot]

 allmodconfig
powerpc  allyesconfig
powerpc   allnoconfig
i386 randconfig-a003-20200930
i386 randconfig-a002-20200930
i386 randconfig-a006-20200930
i386 randconfig-a005-20200930
i386 randconfig-a004-20200930
i386 randconfig-a001-20200930
x86_64   randconfig-a015-20200930
x86_64   randconfig-a013-20200930
x86_64   randconfig-a012-20200930
x86_64   randconfig-a016-20200930
x86_64   randconfig-a014-20200930
x86_64   randconfig-a011-20200930
x86_64   randconfig-a012-20201001
x86_64   randconfig-a015-20201001
x86_64   randconfig-a014-20201001
x86_64   randconfig-a013-20201001
x86_64   randconfig-a011-20201001
x86_64   randconfig-a016-20201001
i386 randconfig-a011-20200930
i386 randconfig-a015-20200930
i386 randconfig-a012-20200930
i386 randconfig-a014-20200930
i386 randconfig-a016-20200930
i386 randconfig-a013-20200930
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a001-20200930
x86_64   randconfig-a005-20200930
x86_64   randconfig-a003-20200930
x86_64   randconfig-a004-20200930
x86_64   randconfig-a002-20200930
x86_64   randconfig-a006-20200930
x86_64   randconfig-a004-20201001
x86_64   randconfig-a001-20201001
x86_64   randconfig-a002-20201001
x86_64   randconfig-a003-20201001
x86_64   randconfig-a005-20201001
x86_64   randconfig-a006-20201001

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

[tip:core/debugobjects] BUILD SUCCESS 88451f2cd3cec2abc30debdf129422d2699d1eba

[kernel test robot]

 randconfig-a001-20200930
x86_64   randconfig-a015-20200930
x86_64   randconfig-a013-20200930
x86_64   randconfig-a012-20200930
x86_64   randconfig-a016-20200930
x86_64   randconfig-a014-20200930
x86_64   randconfig-a011-20200930
x86_64   randconfig-a012-20201001
x86_64   randconfig-a015-20201001
x86_64   randconfig-a014-20201001
x86_64   randconfig-a013-20201001
x86_64   randconfig-a011-20201001
x86_64   randconfig-a016-20201001
i386 randconfig-a011-20200930
i386 randconfig-a015-20200930
i386 randconfig-a012-20200930
i386 randconfig-a014-20200930
i386 randconfig-a016-20200930
i386 randconfig-a013-20200930
i386 randconfig-a014-20201001
i386 randconfig-a015-20201001
i386 randconfig-a013-20201001
i386 randconfig-a016-20201001
i386 randconfig-a011-20201001
i386 randconfig-a012-20201001
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a004-20201001
x86_64   randconfig-a001-20201001
x86_64   randconfig-a002-20201001
x86_64   randconfig-a003-20201001
x86_64   randconfig-a005-20201001
x86_64   randconfig-a006-20201001
x86_64   randconfig-a001-20200930
x86_64   randconfig-a005-20200930
x86_64   randconfig-a003-20200930
x86_64   randconfig-a004-20200930
x86_64   randconfig-a002-20200930
x86_64   randconfig-a006-20200930

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [RFC PATCH v1 04/26] docs: reporting-bugs: step-by-step guide for issues in stable & longterm

[Randy Dunlap]

On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Handle stable and longterm kernels in a subsection, as dealing with them
> directly in the main part of the step-by-step guide turned out to make
> it messy and hard to follow: it looked a bit like code with a large
> amount of if-then-else section to handle special cases, which made the
> default code-flow hard to understand.
> 
> Yet again each step will later be repeated in a reference section and
> described in more detail.
> 
> Signed-off-by: Thorsten Leemhuis 
> ---
>  Documentation/admin-guide/reporting-bugs.rst | 49 
>  1 file changed, 49 insertions(+)
> 
> diff --git a/Documentation/admin-guide/reporting-bugs.rst 
> b/Documentation/admin-guide/reporting-bugs.rst
> index 203df36af55f..e0a6f4328e87 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -156,6 +156,55 @@ After these preparations you'll now enter the main part:
> yourself, if you don't get any help or if it is unsatisfying.
>  
>  
> +Reporting issues only occurring in older kernel version lines
> +-
> +
> +This section is for you, if you tried the latest mainline kernel as outlined
> +above, but failed to reproduce your issue there; at the same time you want to
> +see the issue fixed in older version lines or a vendor kernel that's 
> regularly
> +rebased on new stable or longterm releases. If that case follow these steps:
> +
> + * Prepare yourself for the possibility that going through the next few steps
> +   might not get the issue solved in older releases: the fix might be too 
> big or
> +   risky to get backported there.
> +
> + * Check if the kernel developers still maintain the Linux kernel version 
> line
> +   you care about: go to `the front-page of kernel.org `_
> +   and make sure it mentions the latest release of the particular version 
> line
> +   without an '[EOL]' tag.

Explain somewhere that EOL = End Of Life (in parens).

> +
> + * Check the `archives of the Linux stable mailing list
> +   `_  for existing reports.
> +
> + * Install the latest release from the particular version line as a vanilla
> +   kernel. Ensure this kernel is not tainted and still shows the problem, as 
> the
> +   issue might have already been fixed there.
> +
> + * Search the Linux kernel version control system for the change that fixed
> +   the issue in mainline, as its commit message might tell you if the fix is
> +   scheduled for backporting already. If you don't find anything that way,
> +   search the appropriate mailing lists for posts that discuss such an issue 
> or
> +   peer-review possible fixes. That might lead you to the commit with the fix
> +   or tell you if it's unsuitable for backporting. If backporting was not
> +   considered at all, join the newest discussion, asking if its in the cards.

   it's

> +
> + * Check if you're dealing with a regression that was never present in
> +   mainline by installing the first release of the version line you care 
> about.
> +   If the issue doesn't show up with it, you basically need to report the 
> issue
> +   with this version like you would report a problem with mainline (see 
> above).
> +   This ideally includes a bisection followed by a search for existing 
> reports
> +   on the net; with the help of the subject and the two relevant commit-ids. 
> If
> +   that doesn't turn up anything, write the report; CC or forward the report 
> to
> +   the stable maintainers, the stable mailing list, and those that authored 
> the

   those who (?)

> +   change. Include the shortened commit-id if you found the change that 
> causes
> +   it.
> +
> + * One of the former steps should lead to a solution. If that doesn't work 
> out,
> +   ask the maintainers for the subsystem that seems to be causing the issue 
> for
> +   advice; CC the mailing list for the particular subsystem as well as the
> +   stable mailing list.
> +
> +
>  .. 
> 
>  .. Temporary marker added while this document is rewritten. Sections above
>  .. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
> 


-- 
~Randy

Re: [PATCH] random: use correct memory barriers for crng_node_pool

[Eric Biggers]

On Thu, Sep 24, 2020 at 08:31:02PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 24, 2020 at 07:09:08PM -0700, Eric Biggers wrote:
> > On Thu, Sep 24, 2020 at 05:59:34PM -0700, Paul E. McKenney wrote:
> > > On Tue, Sep 22, 2020 at 02:55:58PM -0700, Eric Biggers wrote:
> > > > On Tue, Sep 22, 2020 at 01:56:28PM -0700, Paul E. McKenney wrote:
> > > > > > You're missing the point here.  b and c could easily be allocated 
> > > > > > by a function
> > > > > > alloc_b() that's in another file.
> > > > > 
> > > > > I am still missing something.
> > > > > 
> > > > > If by "allocated" you mean something like kmalloc(), the compiler 
> > > > > doesn't
> > > > > know the address.  If you instead mean that there is a function that
> > > > > returns the address of another translation unit's static variable, 
> > > > > then
> > > > > any needed ordering should preferably be built into that function's 
> > > > > API.
> > > > > Either way, one would hope for some documentation of anything the 
> > > > > caller
> > > > > needed to be careful of.
> > > > > 
> > > > > > > Besides which, control dependencies should be used only by LKMM 
> > > > > > > experts
> > > > > > > at this point.  
> > > > > > 
> > > > > > What does that even mean?  Control dependencies are everywhere.
> > > > > 
> > > > > Does the following work better for you?
> > > > > 
> > > > > "... the non-local ordering properties of control dependencies should 
> > > > > be
> > > > > relied on only by LKMM experts ...".
> > > > 
> > > > No.  I don't know what that means.  And I think very few people would 
> > > > know.
> > > > 
> > > > I just want to know if I use the one-time init pattern with a pointer 
> > > > to a data
> > > > structure foo, are the readers using foo_use() supposed to use 
> > > > READ_ONCE() or
> > > > are they supposed to use smp_load_acquire().
> > > > 
> > > > It seems the answer is that smp_load_acquire() is the only safe choice, 
> > > > since
> > > > foo_use() *might* involve a control dependency, or might in the future 
> > > > since
> > > > it's part of another kernel subsystem and its implementation could 
> > > > change.
> > > 
> > > First, the specific issue of one-time init.
> > > 
> > > If you are the one writing the code implementing one-time init, it is your
> > > choice.  It seems like you prefer smp_load_acquire().  If someone sees
> > > performance problems due to the resulting memory-barrier instructions,
> > > they have the option of submitting a patch and either forking the
> > > implementation or taking your implementation over from you, depending
> > > on how that conversation goes.
> > 
> > It doesn't matter what I "prefer".  The question is, how to write code that 
> > is
> > actually guaranteed to be correct on all supported Linux architectures, 
> > without
> > assuming internal implementation details of other kernel subsystems.
> 
> And that question allows ample room for personal preferences.
> 
> There are after all tradeoffs.  Do you want to live within the current
> knowledge of your users, or are you willing to invest time and energy
> into teaching them something new?  If someone wants a level of performance
> that is accommodated only by a difficult-to-use pattern, will you choose
> to accommodate them, or will you tell them to build write their own?
> 
> There are often a number of ways to make something work, and they all
> have advantages and disadvantages.  There are tradeoffs, and preferences
> have a role to play as well.

Having options doesn't matter if no one can agree on which one to use.  This is
the second bug fix that I can't get accepted due to bikeshedding over how to
implement "one-time init":

First patch:
v1: 
https://lkml.kernel.org/linux-fsdevel/2020071300.205104-1-ebigg...@kernel.org
v2: 
https://lkml.kernel.org/linux-fsdevel/20200717050510.95832-1-ebigg...@kernel.org
Related thread: 
https://lkml.kernel.org/lkml/20200717044427.68747-1-ebigg...@kernel.org

Second patch (this one):
https://lkml.kernel.org/lkml/20200916233042.51634-1-ebigg...@kernel.org

The problem is identical in both cases.  In both cases, the code currently
implements "one-time init" using a plain load on the reader side, which is
undefined behavior and isn't sufficient on all supported Linux architectures
(even *if* there is no control dependency, which is something that usually is
hard to determine, as I've explained several times).

However in both cases, no one can agree on what to replace the broken code with.
And the opinions were conflicting.  In the first patch, people were advocating
for smp_load_acquire() over READ_ONCE() because it's too hard to determine when
READ_ONCE() is safe.  And even after I switched to smp_load_acquire(), the patch
was still rejected, with conflicting reasons.

Now in the second patch, people are instead advocating for READ_ONCE() over
smp_load_acquire().  And you're claiming that all kernel developers are expected
to read Documentation/RCU/rcu_dereference.rst and design all 

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  Documentation/devicetree/bindings/net/renesas,ravb.txt

between commit:

  307eea32b202 ("dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC")

from the net tree and commit:

  d7adf6331189 ("dt-bindings: net: renesas,etheravb: Convert to json-schema")

from the net-next tree.

I fixed it up (I deleted the file and added the following patch) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Fri, 2 Oct 2020 12:57:33 +1000
Subject: [PATCH] fix up for "dt-bindings: net: renesas,ravb: Add support for 
r8a774e1 SoC"

Signed-off-by: Stephen Rothwell 
---
 Documentation/devicetree/bindings/net/renesas,etheravb.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml 
b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
index e13653051b23..244befb6402a 100644
--- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
@@ -31,6 +31,7 @@ properties:
   - renesas,etheravb-r8a774a1 # RZ/G2M
   - renesas,etheravb-r8a774b1 # RZ/G2N
   - renesas,etheravb-r8a774c0 # RZ/G2E
+  - renesas,etheravb-r8a774e1 # RZ/G2H
   - renesas,etheravb-r8a7795  # R-Car H3
   - renesas,etheravb-r8a7796  # R-Car M3-W
   - renesas,etheravb-r8a77961 # R-Car M3-W+
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell


pgpPrsixnGiQ6.pgp
Description: OpenPGP digital signature

RE: [PATCH] perf evlist: fix memory corruption for Kernel PMU event

[Song Bao Hua (Barry Song)]

> -Original Message-
> From: Andi Kleen [mailto:a...@linux.intel.com]
> Sent: Friday, October 2, 2020 12:07 PM
> To: Song Bao Hua (Barry Song) 
> Cc: linux-kernel@vger.kernel.org; Linuxarm ; Peter
> Zijlstra ; Ingo Molnar ; Arnaldo
> Carvalho de Melo ; Mark Rutland
> ; Alexander Shishkin
> ; Jiri Olsa ;
> Namhyung Kim ; Adrian Hunter
> ; Alexey Budankov
> 
> Subject: Re: [PATCH] perf evlist: fix memory corruption for Kernel PMU event
> 
> On Fri, Oct 02, 2020 at 12:57:29AM +1300, Barry Song wrote:
> > Commit 7736627b865d ("perf stat: Use affinity for closing file
> > descriptors") will use FD(evsel, cpu, thread) to read and write file
> > descriptors xyarray. For a kernel PMU event, this leads to serious
> > memory corruption and perf crash.
> > I have seen evlist->core.cpus->nr is 1 while evsel has cpus->nr with
> > the total number of CPUs. so xyarray which is allocated by
> > evlist->core.cpus->nr will get overflow. This leads to various
> > segmentation faults in perf tool for kernel PMU events, eg:
> > ./perf stat -e bus_cycles  sleep 1
> > *** Error in `./perf': free(): invalid next size (fast):
> > 0x401e6370 *** Aborted (core dumped)
> 
> Thanks.
> 
> I believe there is already a patch queued for this.

Andi, thanks! Could you share the link or the commit ID? I'd like to take a 
look at the fix.
I could still reproduce this issue in the latest linus' tree and I didn't find 
any commit
related to this issue in linux-next and tip/perf/core.

> 
> The problem seems to only happen on ARM64.

My platform which has this issue is really ARM64.

Thanks
Barry

Re: [RFC PATCH v1 03/26] docs: reporting-bugs: step-by-step guide on how to report issues

[Randy Dunlap]

On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> 
> Signed-off-by: Thorsten Leemhuis 
> ---
>  Documentation/admin-guide/reporting-bugs.rst | 103 +++
>  1 file changed, 103 insertions(+)
> 
> diff --git a/Documentation/admin-guide/reporting-bugs.rst 
> b/Documentation/admin-guide/reporting-bugs.rst
> index 7bde6f32ff72..203df36af55f 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -53,6 +53,109 @@ Security issues are typically best report privately; also 
> CC the security team
>  or forward your report there.
>  
>  
> +Step-by-step guide how to report issues to the kernel maintainers
> +=
> +
> +Above TL;DR outlines roughly how to report issues to the Linux kernel

   The above

> +developers. It might be all that's needed for people already familiar with
> +reporting issues to Free/Libre & Open Source Software (FLOSS) projects. For
> +everyone else there is this section. It is more detailed and uses a
> +step-by-step approach. It still tries to be brief for readability; if it's to

  
too

> +brief for you, look up the details in the reference section below, where each
> +of the steps is explained in more detail.
> +
> +Note, this section covers a few more aspects than the TL;DR and does things 
> in a

   Note:

> +slightly different order. That's in your interest, to make sure you notice 
> early
> +if an issue that looks like a Linux kernel problem is actually caused by
> +something else. These steps thus help to ensure the time you invest in this
> +process won't feel wasted in the end:
> +
> + * Stop reading this document and report the problem to your vendor instead,
> +   unless you are running a vanilla mainline kernel already or are willing to
> +   install it.
> +
> + * See if the issue you are dealing with qualifies as regression, security
> +   issue, or a really severe problem: those are 'issues of high priority' 
> that
> +   need special handling in some steps that are about to follow.
> +
> + * Check if your kernel was 'tainted' when the issue occurred, as the event 
> that
> +   made the kernel set this flag might be causing the issue you face.
> +
> + * Locate the driver or kernel subsystem that seems to be causing the issue.
> +   Find out how and where its developers expect reports. Note: most of the 
> time
> +   this won't be `bugzilla.kernel.org `_, as 
> issues
> +   typically need to be sent by mail to a maintainer and a public mailing 
> list.
> +
> + * Search the archives of the bug tracker or mailing list in question
> +   thoroughly for reports that might match your issue. Also check if you find
> +   something with your favorite internet search engine or in the `Linux 
> Kernel
> +   Mailing List (LKML) archives `_. If you 
> find
> +   anything, join the discussion instead of sending a new report.
> +
> + * Create a fresh backup and put system repair and restore tools at hand.
> +
> + * Ensure your system does not enhance its kernels by building additional
> +   kernel modules on-the-fly locally, which solutions like DKMS might be 
> doing
> +   without your knowledge.
> +
> + * Make sure it's not the kernels surroundings that are causing the issue you

 kernel's

> +   face.
> +
> + * Write down coarsely how to reproduce the issue. If you deal with multiple
> +   issue at once, create separate notes for each of them and make sure they

  issues

> +   work independently on a freshly booted system. That's needed, as each 
> issue
> +   needs to get reported to the kernel developers separately, unless they are
> +   strongly entangled.
> +
> +After these preparations you'll now enter the main part:
> +
> + * Install the latest Linux mainline kernel: that's where all issue get fixed
> +   first, because it's the version line the kernel developers mainly care 
> about.
> +   Testing and reporting with the latest Linux stable kernel can be 
> acceptable

can be an 
acceptable

> +   alternative in some situations, but is best avoided.
> +
> + * Ensure the kernel you just installed does not 'taint' itself when running.
> +
> + * Reproduce the issue with the kernel you just installed. If it doesn't 
> show up
> +   there, head over to the instructions for issues only happening with stable
> +   and longterm kernels if you want to see it fixed there.

Can you link (reference) to that section?

> +
> + * Optimize your notes: try to find and write the most straightforward way to
> +   reproduce your issue. Make sure the end result has all the important 
> details,
> +   and at the same time is easy to read and understand for others that hear
> +   about it for the first time. And if you learned something in t

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Nicolin Chen]

On Fri, Oct 02, 2020 at 04:55:34AM +0300, Dmitry Osipenko wrote:
> 02.10.2020 04:07, Nicolin Chen пишет:
> > On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote:
> > If we can't come to an agreement on globalizing mc pointer, would
> > it be possible to pass tegra_mc_driver through tegra_smmu_probe()
> > so we can continue to use driver_find_device_by_fwnode() as v1?
> >
> > v1: https://lkml.org/lkml/2020/9/26/68
> 
>  tegra_smmu_probe() already takes a struct tegra_mc *. Did you mean
>  tegra_smmu_probe_device()? I don't think we can do that because it isn't
> >>>
> >>> I was saying to have a global parent_driver pointer: similar to
> >>> my v1, yet rather than "extern" the tegra_mc_driver, we pass it
> >>> through egra_smmu_probe() and store it in a static global value
> >>> so as to call tegra_smmu_get_by_fwnode() in ->probe_device().
> >>>
> >>> Though I agree that creating a global device pointer (mc) might
> >>> be controversial, yet having a global parent_driver pointer may
> >>> not be against the rule, considering that it is common in iommu
> >>> drivers to call driver_find_device_by_fwnode in probe_device().
> >>
> >> You don't need the global pointer if you have SMMU OF node.
> >>
> >> You could also get driver pointer from mc->dev->driver.
> >>
> >> But I don't think you need to do this at all. The probe_device() could
> >> be invoked only for the tegra_smmu_ops and then seems you could use
> >> dev_iommu_priv_set() in tegra_smmu_of_xlate(), like sun50i-iommu driver
> >> does.
> > 
> > Getting iommu device pointer using driver_find_device_by_fwnode()
> > is a common practice in ->probe_device() of other iommu drivers.
> 
> Please give me a full list of the IOMMU drivers which use this method.
> 
> > But this requires a device_driver pointer that tegra-smmu doesn't
> > have. So passing tegra_mc_driver through tegra_smmu_probe() will
> > address it.
> > 
> 
> If you're borrowing code and ideas from other drivers, then at least
> please borrow them from a modern good-looking drivers. And I already
> pointed out that following cargo cult is not always a good idea.
> 
> ARM-SMMU isn't a modern driver and it has legacy code. You shouldn't
> copy it blindly. The sun50i-iommu driver was added half year ago, you
> may use it as a reference.

I took a closer look at sun50i-iommu driver. It's a good idea.
I think I can come up with a cleaner one. Will send v4.

Thanks for the advice.

drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c:426:32: warning: unused variable 'aq_pm_ops'

[kernel test robot]

Hi zhengbin,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   60e720931556fc1034d0981460164dcf02697679
commit: 0ee0bbb018938addf87b54d447cc5633d2e53490 net: atlantic: make symbol 
'aq_pm_ops' static
date:   11 months ago
config: x86_64-randconfig-a003-20201001 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
bcd05599d0e53977a963799d6ee4f6e0bc21331b)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ee0bbb018938addf87b54d447cc5633d2e53490
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 0ee0bbb018938addf87b54d447cc5633d2e53490
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c:426:32: warning: unused 
>> variable 'aq_pm_ops' [-Wunused-const-variable]
   static const struct dev_pm_ops aq_pm_ops = {
  ^
   1 warning generated.

vim +/aq_pm_ops +426 drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c

   425  
 > 426  static const struct dev_pm_ops aq_pm_ops = {
   427  .suspend = aq_pm_suspend_poweroff,
   428  .poweroff = aq_pm_suspend_poweroff,
   429  .freeze = aq_pm_freeze,
   430  .resume = aq_pm_resume_restore,
   431  .restore = aq_pm_resume_restore,
   432  .thaw = aq_pm_thaw,
   433  };
   434  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[PATCH] seccomp: Make duplicate listener detection non-racy

[Jann Horn]

Currently, init_listener() tries to prevent adding a filter with
SECCOMP_FILTER_FLAG_NEW_LISTENER if one of the existing filters already
has a listener. However, this check happens without holding any lock that
would prevent another thread from concurrently installing a new filter
(potentially with a listener) on top of the ones we already have.

Theoretically, this is also a data race: The plain load from
current->seccomp.filter can race with concurrent writes to the same
location.

Fix it by moving the check into the region that holds the siglock to guard
against concurrent TSYNC.

(I am not marking this for stable backport because I believe that this does
not have any implications beyond a theoretical data race and allowing
userspace to create seccomp filters with weird semantics if userspace
concurrently installs seccomp filters in a way no benign userspace workload
would.)

(The "Fixes" tag points to the commit that introduced the theoretical
data race; concurrent installation of another filter with TSYNC only
became possible later, in commit 51891498f2da ("seccomp: allow TSYNC and
USER_NOTIF together").)

Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Reviewed-by: Tycho Andersen 
Signed-off-by: Jann Horn 
---
NOTE: After Tycho gave his Reviewed-by, I've had to adjust the errno
to -EBUSY (my original patch broke UAPI, good thing we have selftests),
remove the unused "cur" from init_listener(), and remove the now
useless initialization of "ret".

 kernel/seccomp.c | 38 +++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 676d4af62103..c359ef4380ad 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -1472,13 +1472,7 @@ static const struct file_operations
seccomp_notify_ops = {

 static struct file *init_listener(struct seccomp_filter *filter)
 {
-   struct file *ret = ERR_PTR(-EBUSY);
-   struct seccomp_filter *cur;
-
-   for (cur = current->seccomp.filter; cur; cur = cur->prev) {
-   if (cur->notif)
-   goto out;
-   }
+   struct file *ret;

ret = ERR_PTR(-ENOMEM);
filter->notif = kzalloc(sizeof(*(filter->notif)), GFP_KERNEL);
@@ -1504,6 +1498,31 @@ static struct file *init_listener(struct
seccomp_filter *filter)
return ret;
 }

+/*
+ * Does @new_child have a listener while an ancestor also has a listener?
+ * If so, we'll want to reject this filter.
+ * This only has to be tested for the current process, even in the TSYNC case,
+ * because TSYNC installs @child with the same parent on all threads.
+ * Note that @new_child is not hooked up to its parent at this point yet, so
+ * we use current->seccomp.filter.
+ */
+static bool has_duplicate_listener(struct seccomp_filter *new_child)
+{
+   struct seccomp_filter *cur;
+
+   /* must be protected against concurrent TSYNC */
+   lockdep_assert_held(¤t->sighand->siglock);
+
+   if (!new_child->notif)
+   return false;
+   for (cur = current->seccomp.filter; cur; cur = cur->prev) {
+   if (cur->notif)
+   return true;
+   }
+
+   return false;
+}
+
 /**
  * seccomp_set_mode_filter: internal function for setting seccomp filter
  * @flags:  flags to change filter behavior
@@ -1575,6 +1594,11 @@ static long seccomp_set_mode_filter(unsigned int flags,
if (!seccomp_may_assign_mode(seccomp_mode))
goto out;

+   if (has_duplicate_listener(prepared)) {
+   ret = -EBUSY;
+   goto out;
+   }
+
ret = seccomp_attach_filter(flags, prepared);
if (ret)
goto out;

base-commit: fb0155a09b0224a7147cb07a4ce6034c8d29667f
-- 
2.28.0.806.g8561365e88-goog

[PATCH net-next 4/4] net: dsa: Utilize __vlan_find_dev_deep_rcu()

[Florian Fainelli]

Now that we are guaranteed that dsa_untag_bridge_pvid() is called after
eth_type_trans() we can utilize __vlan_find_dev_deep_rcu() which will
take care of finding an 802.1Q upper on top of a bridge master.

A common use case, prior to 12a1526d067 ("net: dsa: untag the bridge
pvid from rx skbs") was to configure a bridge 802.1Q upper like this:

ip link add name br0 type bridge vlan_filtering 0
ip link add link br0 name br0.1 type vlan id 1

in order to pop the default_pvid VLAN tag.

With this change we restore that behavior while still allowing the DSA
receive path to automatically pop the VLAN tag.

Signed-off-by: Florian Fainelli 
---
 net/dsa/dsa_priv.h | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index d6ce8c2a2590..12998bf04e55 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -204,7 +204,6 @@ static inline struct sk_buff *dsa_untag_bridge_pvid(struct 
sk_buff *skb)
struct net_device *br = dp->bridge_dev;
struct net_device *dev = skb->dev;
struct net_device *upper_dev;
-   struct list_head *iter;
u16 vid, pvid, proto;
int err;
 
@@ -246,13 +245,9 @@ static inline struct sk_buff *dsa_untag_bridge_pvid(struct 
sk_buff *skb)
 * supports because vlan_filtering is 0. In that case, we should
 * definitely keep the tag, to make sure it keeps working.
 */
-   netdev_for_each_upper_dev_rcu(dev, upper_dev, iter) {
-   if (!is_vlan_dev(upper_dev))
-   continue;
-
-   if (vid == vlan_dev_vlan_id(upper_dev))
-   return skb;
-   }
+   upper_dev = __vlan_find_dev_deep_rcu(br, htons(proto), vid);
+   if (upper_dev)
+   return skb;
 
__vlan_hwaccel_clear_tag(skb);
 
-- 
2.25.1

[PATCH net-next 3/4] net: dsa: Obtain VLAN protocol from skb->protocol

[Florian Fainelli]

Now that dsa_untag_bridge_pvid() is called after eth_type_trans() we are
guaranteed that skb->protocol will be set to a correct value, thus
allowing us to avoid calling vlan_eth_hdr().

Signed-off-by: Florian Fainelli 
---
 net/dsa/dsa_priv.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 0348dbab4131..d6ce8c2a2590 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -201,7 +201,6 @@ dsa_slave_to_master(const struct net_device *dev)
 static inline struct sk_buff *dsa_untag_bridge_pvid(struct sk_buff *skb)
 {
struct dsa_port *dp = dsa_slave_to_port(skb->dev);
-   struct vlan_ethhdr *hdr = vlan_eth_hdr(skb);
struct net_device *br = dp->bridge_dev;
struct net_device *dev = skb->dev;
struct net_device *upper_dev;
@@ -217,7 +216,7 @@ static inline struct sk_buff *dsa_untag_bridge_pvid(struct 
sk_buff *skb)
return skb;
 
/* Move VLAN tag from data to hwaccel */
-   if (!skb_vlan_tag_present(skb) && hdr->h_vlan_proto == htons(proto)) {
+   if (!skb_vlan_tag_present(skb) && skb->protocol == htons(proto)) {
skb = skb_vlan_untag(skb);
if (!skb)
return NULL;
-- 
2.25.1

[PATCH net-next 0/4] net: dsa: Improve dsa_untag_bridge_pvid()

[Florian Fainelli]

Hi David, Jakub,

This patch series is based on the recent discussions with Vladimir:

https://lore.kernel.org/netdev/20201001030623.343535-1-f.faine...@gmail.com/

the simplest way forward was to call dsa_untag_bridge_pvid() after
eth_type_trans() has been set which guarantees that skb->protocol is set
to a correct value and this allows us to utilize
__vlan_find_dev_deep_rcu() properly without playing or using the bridge
master as a net_device reference.

Florian Fainelli (4):
  net: dsa: Call dsa_untag_bridge_pvid() from dsa_switch_rcv()
  net: dsa: b53: Set untag_bridge_pvid
  net: dsa: Obtain VLAN protocol from skb->protocol
  net: dsa: Utilize __vlan_find_dev_deep_rcu()

 drivers/net/dsa/b53/b53_common.c |  1 +
 include/net/dsa.h|  8 
 net/dsa/dsa.c|  9 +
 net/dsa/dsa_priv.h   | 14 --
 net/dsa/tag_brcm.c   | 15 ++-
 5 files changed, 24 insertions(+), 23 deletions(-)

-- 
2.25.1

[PATCH net-next 2/4] net: dsa: b53: Set untag_bridge_pvid

[Florian Fainelli]

Indicate to the DSA receive path that we need to untage the bridge PVID,
this allows us to remove the dsa_untag_bridge_pvid() calls from
net/dsa/tag_brcm.c.

Signed-off-by: Florian Fainelli 
---
 drivers/net/dsa/b53/b53_common.c |  1 +
 net/dsa/tag_brcm.c   | 15 ++-
 2 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 73507cff3bc4..ce18ba0b74eb 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -2603,6 +2603,7 @@ struct b53_device *b53_switch_alloc(struct device *base,
dev->ops = ops;
ds->ops = &b53_switch_ops;
ds->configure_vlan_while_not_filtering = true;
+   ds->untag_bridge_pvid = true;
dev->vlan_enabled = ds->configure_vlan_while_not_filtering;
mutex_init(&dev->reg_mutex);
mutex_init(&dev->stats_mutex);
diff --git a/net/dsa/tag_brcm.c b/net/dsa/tag_brcm.c
index 69d6b8c597a9..ad72dff8d524 100644
--- a/net/dsa/tag_brcm.c
+++ b/net/dsa/tag_brcm.c
@@ -152,11 +152,6 @@ static struct sk_buff *brcm_tag_rcv_ll(struct sk_buff *skb,
/* Remove Broadcom tag and update checksum */
skb_pull_rcsum(skb, BRCM_TAG_LEN);
 
-   /* Set the MAC header to where it should point for
-* dsa_untag_bridge_pvid() to parse the correct VLAN header.
-*/
-   skb_set_mac_header(skb, -ETH_HLEN);
-
skb->offload_fwd_mark = 1;
 
return skb;
@@ -187,7 +182,7 @@ static struct sk_buff *brcm_tag_rcv(struct sk_buff *skb, 
struct net_device *dev,
nskb->data - ETH_HLEN - BRCM_TAG_LEN,
2 * ETH_ALEN);
 
-   return dsa_untag_bridge_pvid(nskb);
+   return nskb;
 }
 
 static const struct dsa_device_ops brcm_netdev_ops = {
@@ -214,14 +209,8 @@ static struct sk_buff *brcm_tag_rcv_prepend(struct sk_buff 
*skb,
struct net_device *dev,
struct packet_type *pt)
 {
-   struct sk_buff *nskb;
-
/* tag is prepended to the packet */
-   nskb = brcm_tag_rcv_ll(skb, dev, pt, ETH_HLEN);
-   if (!nskb)
-   return nskb;
-
-   return dsa_untag_bridge_pvid(nskb);
+   return brcm_tag_rcv_ll(skb, dev, pt, ETH_HLEN);
 }
 
 static const struct dsa_device_ops brcm_prepend_netdev_ops = {
-- 
2.25.1

[PATCH net-next 1/4] net: dsa: Call dsa_untag_bridge_pvid() from dsa_switch_rcv()

[Florian Fainelli]

When a DSA switch driver needs to call dsa_untag_bridge_pvid(), it can
set dsa_switch::untag_brige_pvid to indicate this is necessary.

This is a pre-requisite to making sure that we are always calling
dsa_untag_bridge_pvid() after eth_type_trans() has been called.

Signed-off-by: Florian Fainelli 
---
 include/net/dsa.h | 8 
 net/dsa/dsa.c | 9 +
 2 files changed, 17 insertions(+)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index b502a63d196e..8b0696e08cac 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -308,6 +308,14 @@ struct dsa_switch {
 */
boolconfigure_vlan_while_not_filtering;
 
+   /* If the switch driver always programs the CPU port as egress tagged
+* despite the VLAN configuration indicating otherwise, then setting
+* @untag_bridge_pvid will force the DSA receive path to pop the 
bridge's
+* default_pvid VLAN tagged frames to offer a consistent behavior
+* between a vlan_filtering=0 and vlan_filtering=1 bridge device.
+*/
+   booluntag_bridge_pvid;
+
/* In case vlan_filtering_is_global is set, the VLAN awareness state
 * should be retrieved from here and not from the per-port settings.
 */
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 5c18c0214aac..dec4ab59b7c4 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -225,6 +225,15 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct 
net_device *dev,
skb->pkt_type = PACKET_HOST;
skb->protocol = eth_type_trans(skb, skb->dev);
 
+   if (unlikely(cpu_dp->ds->untag_bridge_pvid)) {
+   nskb = dsa_untag_bridge_pvid(skb);
+   if (!nskb) {
+   kfree_skb(skb);
+   return 0;
+   }
+   skb = nskb;
+   }
+
s = this_cpu_ptr(p->stats64);
u64_stats_update_begin(&s->syncp);
s->rx_packets++;
-- 
2.25.1

Re: [PATCH v3 1/1] kdump: append uts_namespace.name offset to VMCOREINFO

[lijiang]

Hi, Alexander

在 2020年09月30日 18:23, Alexander Egorenkov 写道:
> The offset of the field 'init_uts_ns.name' has changed
> since commit 9a56493f6942 ("uts: Use generic ns_common::count").
> 
> Link: 
> https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain
> 
> Make the offset of the field 'uts_namespace.name' available
> in VMCOREINFO because tools like 'crash-utility' and
> 'makedumpfile' must be able to read it from crash dumps.
> 
> Signed-off-by: Alexander Egorenkov 
> ---
> 
> v2 -> v3:
>  * Added documentation to vmcoreinfo.rst
>  * Use the short form of the commit reference
> 
> v1 -> v2:
>  * Improved commit message
>  * Added link to the discussion of the uts namespace changes
> 
>  Documentation/admin-guide/kdump/vmcoreinfo.rst | 6 ++
>  kernel/crash_core.c| 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst 
> b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> index e44a6c01f336..3861a25faae1 100644
> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> @@ -39,6 +39,12 @@ call.
>  User-space tools can get the kernel name, host name, kernel release
>  number, kernel version, architecture name and OS type from it.
>  
> +(uts_namespace, name)
> +-
> +
> +Offset of the name's member. Crash Utility and Makedumpfile get
> +the start address of the init_uts_ns.name from this.
> +

Thank you for the update. The v3 looks good to me.

>  node_online_map
>  ---
>  
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 106e4500fd53..173fdc261882 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -447,6 +447,7 @@ static int __init crash_save_vmcoreinfo_init(void)
>   VMCOREINFO_PAGESIZE(PAGE_SIZE);
>  
>   VMCOREINFO_SYMBOL(init_uts_ns);
> + VMCOREINFO_OFFSET(uts_namespace, name);
>   VMCOREINFO_SYMBOL(node_online_map);
>  #ifdef CONFIG_MMU
>   VMCOREINFO_SYMBOL_ARRAY(swapper_pg_dir);
> 

Re: [RFC PATCH v1 02/26] docs: reporting-bugs: Create a TLDR how to report issues

[Randy Dunlap]

On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Get straight to the point in a few paragraphs instead of forcing users
> to read quite a bit of text, like the old approach did.
> 
> All normally needed fits into the first two paragraphs. The third is
> dedicated to issues only happening in stable and longterm kernels, as
> things otherwise get hard to follow. At the end explicitly spell out
> that some issues need to be handled slightly different.
> 
> This TLDR naturally leaves lots of details out. But it will be good
> enough in some situations, for example for users that recently reported
> an issue or are familiar with reporting issues to FLOSS projects.
> 
> Signed-off-by: Thorsten Leemhuis 
> ---
>  Documentation/admin-guide/reporting-bugs.rst | 43 
>  1 file changed, 43 insertions(+)
> 
> diff --git a/Documentation/admin-guide/reporting-bugs.rst 
> b/Documentation/admin-guide/reporting-bugs.rst
> index 4bbb9132782b..7bde6f32ff72 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -10,6 +10,49 @@ Reporting bugs
>  .. inconsistent/not make sense before all patches of the rewrite got applied.
>  .. 
> ###
>  
> +
> +The short guide (aka TL;DR)
> +===
> +
> +This is how you report issues with the Linux kernel to its developers:
> +
> +If you deal with multiple issues at once, process each of them separately. 
> Try
> +your best guess which area of the kernel might be responsible for your issue.
> +Check the `MAINTAINERS file
> +`_
> +how developers of that particular area expect to be told about issues; note,

   for how
?

> +it's rarely `bugzilla.kernel.org `_, as most
> +subsystems expect reports by mail sent to their maintainers and their public
> +mailing list!
> +
> +Check the archives of the determined destination thoroughly for existing
> +reports; also search the LKML archives and the internet as a whole. If you 
> can't
> +find any, install the `latest Linux mainline version `_.
> +Make sure to use a vanilla kernel and avert any add-on kernel modules 
> externally
> +developed; also ensure the kernel is running in a healthy environment and 
> does
> +not 'taint' itself before the issue occurs. If you can reproduce it, write a

I don't care for "does not 'taint' itself". How about
 and is 
not
   already tainted before the issue occurs.

> +report to the destination you determined earlier. Afterwards keep the ball
> +rolling by proactive testing, a status update now and then, and helping where
> +you can.
> +
> +You can't reproduce an issue with mainline you want to see fixed in older
> +version lines? Then make sure the line you care about still gets support.
> +Install its latest release as vanilla kernel. If you can reproduce the issue

Is "vanilla" well understood?

> +there, try to find the commit that fixed it in mainline or any discussion
> +preceding it: those will often mention if backporting is planed or 
> impossible;
> +if not, ask for it. In case you don't find anything, check if it's a 
> regression
> +specific to the version line that need to be bisected and report just like a

that needs

> +problem in mainline with the stable mailing list CCed. If you reached this 
> point
> +without a solution, ask for advice by mailing the subsystem maintainer with 
> the
> +subsystem and stable mailing list in CC.
> +
> +If you deal with a regression, bisect it to find the culprit and CC or 
> forward
> +your report to its developers.
> +
> +Security issues are typically best report privately; also CC the security 
> team

  reported

> +or forward your report there.
> +
> +
>  .. 
> 
>  .. Temporary marker added while this document is rewritten. Sections above
>  .. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
> 


-- 
~Randy

[PATCH] drivers:tty:pty: Fix a race causing data loss on close

[minyard]

From: Corey Minyard 

If you write to a pty master an immediately close the pty master, the
receiver might get a chunk of data dropped, but then receive some later
data.  That's obviously something rather unexpected for a user.  It
certainly confused my test program.

It turns out that tty_vhangup() gets called from pty_close(), and that
causes the data on the slave side to be flushed, but due to races more
data can be copied into the slave side's buffer after that.  Consider
the following sequence:

thread1thread2thread3
   write data into buffer,
  n_tty buffer is filled
   pty_close()
tty_vhangup()
 tty_ldisc_hangup()
  n_tty_flush_buffer()
   reset_buffer_flags()
n_tty_read()
 up_read(&tty->termios_rwsem);
down_read(&tty->termios_rwsem);
clear n_tty buffer contents
up_read(&tty->termios_rwsem);
 tty_buffer_flush_work()
  schedules work calling
flush_to_ldisc()
  flush_to_ldisc()
   receive_buf()
tty_port_default_receive_buf()
 tty_ldisc_receive_buf()
  tty_ldisc_receive_buf()
   n_tty_receive_buf2()
n_tty_receive_buf_common()
 down_read(&tty->termios_rwsem);
 __receive_buf()
  copies data into n_tty buffer
 up_read(&tty->termios_rwsem);
 down_read(&tty->termios_rwsem);
 copy buffer data to user

This change checks to see if the tty is being hung up before copying
anything in n_tty_receive_buf_common().  It has to be done after the
tty->termios_rwsem semaphore is claimed, for reasons that should be
apparent from the sequence above.

Signed-off-by: Corey Minyard 
---
I sent a program to reproduce this, I extended it to prove it wasn't the
test program that caused the issue, and I've uploaded it to:
  http://sourceforge.net/projects/ser2net/files/tmp/testpty.c
if you want to run it.  It has a lot of comments that explain what is
going on.

This is not a very satisfying fix, though.  It works reliably, but it
doesn't seem right to me.  My inclination was to remove the up and down
semaphore around tty_buffer_flush_work() in n_tty_read(), as it just
schedules some work, no need to unlock for that.  But that resulted
in a deadlock elsewhere, so that up/down on the semaphore is there for
another reason.

The locking in the tty code is really hard to follow.  I believe this is
actually a locking problem, but fixing it looks daunting to me.

-corey

 drivers/tty/n_tty.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 1794d84e7bf6..1c33c26dc229 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1704,6 +1704,9 @@ n_tty_receive_buf_common(struct tty_struct *tty, const 
unsigned char *cp,
 
down_read(&tty->termios_rwsem);
 
+   if (test_bit(TTY_HUPPING, &tty->flags))
+   goto out_upsem;
+
do {
/*
 * When PARMRK is set, each input char may take up to 3 chars
@@ -1760,6 +1763,7 @@ n_tty_receive_buf_common(struct tty_struct *tty, const 
unsigned char *cp,
} else
n_tty_check_throttle(tty);
 
+out_upsem:
up_read(&tty->termios_rwsem);
 
return rcvd;
-- 
2.17.1

Re: [Linux-kernel-mentees][PATCH v2] net: usb: rtl8150: prevent set_ethernet_addr from setting uninit address

[David Miller]

From: Anant Thazhemadam 
Date: Thu,  1 Oct 2020 13:02:20 +0530

> When get_registers() fails (which happens when usb_control_msg() fails)
> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> as the address.
> 
> Checking for the return values appropriately, and handling the case
> wherein set_ethernet_addr() fails like this, helps in avoiding the
> mac address being incorrectly set in this manner.
> 
> Reported-by: syzbot+abbc768b560c84d92...@syzkaller.appspotmail.com
> Tested-by: syzbot+abbc768b560c84d92...@syzkaller.appspotmail.com
> Signed-off-by: Anant Thazhemadam 
> Acked-by: Petko Manolov 

First, please remove "Linux-kernel-mentees" from the Subject line.

All patch submitters should have their work judged equally, whoever
they are.  So this Subject text gives no extra information, and it
simply makes scanning Subject lines in one's mailer more difficult.

Second, when a MAC address fails to probe a random MAC address should
be selected.  We have helpers for this.  This way an interface still
comes up and is usable, even in the event of a failed MAC address
probe.

Re: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component support

[Randy Dunlap]

Hi--

On 10/1/20 1:39 PM, Chang S. Bae wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index a1068742a6df..742167c6f789 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5838,6 +5838,21 @@
>   which allow the hypervisor to 'idle' the guest on lock
>   contention.
>  
> + xstate.enable=  [X86-64]
> + xstate.disable= [X86-64]
> + The kernel is compiled with a default xstate bitmask --
> + enabling it to use the XSAVE hardware to efficiently
> + save and restore thread states on context switch.
> + xstate.enable allows adding to that default mask at
> + boot-time without recompiling the kernel just to support
> + the new thread state. (Note that the kernel will ignore
> + any bits in the mask that do not correspond to features
> + that are actually available in CPUID)  xstate.disable

 in CPUID.)

> + allows clearing bits in the default mask, forcing the
> + kernel to forget that it supports the specified thread
> + state. When a bit set for both, the kernel takes
> + xstate.disable in a priority.

   as a priority.


What do these bitmasks look like?  what do the bits mean?
Where does a user find this info?


thanks.
-- 
~Randy

Re: [PATCH v13 19/26] mm: Re-introduce do_mmap_pgoff()

[Peter Collingbourne]

On Fri, Sep 25, 2020 at 7:57 AM Yu-cheng Yu  wrote:
>
> There was no more caller passing vm_flags to do_mmap(), and vm_flags was
> removed from the function's input by:
>
> commit 45e55300f114 ("mm: remove unnecessary wrapper function 
> do_mmap_pgoff()").
>
> There is a new user now.  Shadow stack allocation passes VM_SHSTK to
> do_mmap().  Re-introduce the vm_flags and do_mmap_pgoff().

I would prefer to change the callers to pass the additional 0 argument
instead of bringing the wrapper function back, but if we're going to
bring it back then we should fix the naming (both functions take a
pgoff argument, so the previous name do_mmap_pgoff() was just plain
confusing).

Peter

Re: [PATCH] arm64: dts: zynqmp: Fix pcie ranges description

[Laurent Pinchart]

Hi Michal,

Thank you for the patch.

On Tue, Sep 29, 2020 at 01:43:22PM +0200, Michal Simek wrote:
> DT schema is checking tuples which should be properly separated. The patch
> is doing this separation to avoid the following warning:
> ..yaml: axi: pcie@fd0e:ranges: [[33554432, 0, 3758096384, 0,
> 3758096384, 0, 268435456, 1124073472, 6, 0, 6, 0, 2, 0]] is not valid under
> any of the given schemas (Possible causes of the failure):
> ...dt.yaml: axi: pcie@fd0e:ranges: True was expected
> ...dt.yaml: axi: pcie@fd0e:ranges:0: [33554432, 0, 3758096384, 0,
> 3758096384, 0, 268435456, 1124073472, 6, 0, 6, 0, 2, 0] is too long

I would keep the error message unwrapped as it's a bit confusing to
read, even if it exceeds the normal 72 columns limit of commit messaged.

> Signed-off-by: Michal Simek 

Reviewed-by: Laurent Pinchart 

> ---
> 
> I have seen one conversation about it but don't have link which I can point
> to.
> ---
>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi 
> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index 771f60e0346d..98073f3223e5 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -542,8 +542,8 @@ pcie: pcie@fd0e {
> <0x0 0xfd48 0x0 0x1000>,
> <0x80 0x 0x0 0x100>;
>   reg-names = "breg", "pcireg", "cfg";
> - ranges = <0x0200 0x 0xe000 0x 
> 0xe000 0x 0x1000  /* non-prefetchable memory */
> -   0x4300 0x0006 0x 0x0006 
> 0x 0x0002 0x>;/* prefetchable memory */
> + ranges = <0x0200 0x 0xe000 0x 
> 0xe000 0x 0x1000>,/* non-prefetchable memory */
> +  <0x4300 0x0006 0x 0x0006 
> 0x 0x0002 0x>;/* prefetchable memory */
>   bus-range = <0x00 0xff>;
>   interrupt-map-mask = <0x0 0x0 0x0 0x7>;
>   interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,

-- 
Regards,

Laurent Pinchart

Re: linux-next: build failure after merge of the net-next tree

[Stephen Rothwell]

Hi Dave,

On Thu, 01 Oct 2020 18:40:13 -0700 (PDT) David Miller  
wrote:
>
> From: Stephen Rothwell 
> Date: Tue, 29 Sep 2020 13:04:46 +1000
> 
> > Caused by commit
> > 
> >   eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested 
> > interface infrastructure")
> > 
> > interacting with commit
> > 
> >   e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver 
> > implementation")
> > 
> > also in the net-next tree.  
> 
> I would argue against that "also" as the first commit is only in the
> 'net' tree right now. :-)

Sorry, my mistake.  I was wondering why your testing did not seem to be
affected.

> This is simply something I'll have to resolve the next time net is merged
> into net-next.

Absolutely, no problem.

-- 
Cheers,
Stephen Rothwell


pgphqcGgvxOE6.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

[Dmitry Osipenko]

02.10.2020 04:07, Nicolin Chen пишет:
> On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote:
> If we can't come to an agreement on globalizing mc pointer, would
> it be possible to pass tegra_mc_driver through tegra_smmu_probe()
> so we can continue to use driver_find_device_by_fwnode() as v1?
>
> v1: https://lkml.org/lkml/2020/9/26/68

 tegra_smmu_probe() already takes a struct tegra_mc *. Did you mean
 tegra_smmu_probe_device()? I don't think we can do that because it isn't
>>>
>>> I was saying to have a global parent_driver pointer: similar to
>>> my v1, yet rather than "extern" the tegra_mc_driver, we pass it
>>> through egra_smmu_probe() and store it in a static global value
>>> so as to call tegra_smmu_get_by_fwnode() in ->probe_device().
>>>
>>> Though I agree that creating a global device pointer (mc) might
>>> be controversial, yet having a global parent_driver pointer may
>>> not be against the rule, considering that it is common in iommu
>>> drivers to call driver_find_device_by_fwnode in probe_device().
>>
>> You don't need the global pointer if you have SMMU OF node.
>>
>> You could also get driver pointer from mc->dev->driver.
>>
>> But I don't think you need to do this at all. The probe_device() could
>> be invoked only for the tegra_smmu_ops and then seems you could use
>> dev_iommu_priv_set() in tegra_smmu_of_xlate(), like sun50i-iommu driver
>> does.
> 
> Getting iommu device pointer using driver_find_device_by_fwnode()
> is a common practice in ->probe_device() of other iommu drivers.

Please give me a full list of the IOMMU drivers which use this method.

> But this requires a device_driver pointer that tegra-smmu doesn't
> have. So passing tegra_mc_driver through tegra_smmu_probe() will
> address it.
> 

If you're borrowing code and ideas from other drivers, then at least
please borrow them from a modern good-looking drivers. And I already
pointed out that following cargo cult is not always a good idea.

ARM-SMMU isn't a modern driver and it has legacy code. You shouldn't
copy it blindly. The sun50i-iommu driver was added half year ago, you
may use it as a reference.

Always consult the IOMMU core code. If you're too unsure about
something, then maybe better to start a new thread and ask Joerg about
the best modern practices that IOMMU drivers should use.

Re: [PATCH v3 07/13] ASoC: audio-graph: Update driver as per new exposed members

[Kuninori Morimoto]

Hi Sameer

> As per the members exposed earlier in the series, audio graph driver
> is updated to make use of these. Functionally there is no change
> in behavior if these are not populated. So following changes are made
> as part of this.
> 
>  - Update 'dai_link->ops' for DPCM links if a custom 'snd_soc_ops'
>is defined by the vendor driver.
> 
>  - Consider 'force_dpcm' flag status when deciding if a DAI link
>needs to be treated as DPCM or not. In doing so the logic is
>moved to a separate inline function for a better readability.
> 
>  - Populate 'dpcm_selectable' flag which is then used to detect
>DPCM DAI links.
> 
> Signed-off-by: Sameer Pujar 
> Cc: Kuninori Morimoto 
> ---

Can we merge [06/13] and [07/13] patches ?

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH v3 06/13] ASoC: simple-card-utils: Expose new members for asoc_simple_priv

[Kuninori Morimoto]

Hi Sameer

Thank you for the patch

> Add new members in struct 'asoc_simple_priv'. Idea is to leverage
> simple or graph card driver as much as possible and vendor can
> maintain a thin driver to control the behavior by populating these
> newly exposed members.

re-use simple/audio-graph driver is nice idea.
My planning next new audio-graph2 can renuse it.

> diff --git a/include/sound/simple_card_utils.h 
> b/include/sound/simple_card_utils.h
> index 86a1e95..9825308 100644
> --- a/include/sound/simple_card_utils.h
> +++ b/include/sound/simple_card_utils.h
> @@ -56,6 +56,10 @@ struct asoc_simple_priv {
>   struct asoc_simple_dai *dais;
>   struct snd_soc_codec_conf *codec_conf;
>   struct gpio_desc *pa_gpio;
> + const struct snd_soc_ops *ops;
> + unsigned int force_dpcm:1;
> + uintptr_t dpcm_selectable;
> + void *data;
>  };

I have opinions about these.

About dpcm_selectable, indeed current audio-graph is using it as "uintptr_t",
but as you know, it checks whether it was non-NULL or not only.
This means we can use it as bit-field.

BTW, do we need to have dpcm_selectable at priv ?

One note is that, -scu- user is only me (locally),
and it will be removed when audio-graph2 was created.
(My plan is keep code for you, but remove compatible)

About *data, I think we can avoid *data
if driver side priv includes asoc_simple_priv ?

struct my_priv {
struct asoc_simple_priv *simple;
...
};

#define simple_to_priv(_simple) container_of((_simple), struct my_priv, 
simple)


Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH net v1] net: phy: realtek: Modify 2.5G PHY name to RTL8226

[David Miller]

From: Willy Liu 
Date: Wed, 30 Sep 2020 14:48:58 +0800

> Realtek single-chip Ethernet PHY solutions can be separated as below:
> 10M/100Mbps: RTL8201X
> 1Gbps: RTL8211X
> 2.5Gbps: RTL8226/RTL8221X
> RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY.
> Since RTL8226 is single port only, realtek changes its name to RTL8221B from
> the second version.
> PHY ID for RTL8226 is 0x001cc800 and RTL8226B/RTL8221B is 0x001cc840.
> 
> RTL8125 is not a single PHY solution, it integrates PHY/MAC/PCIE bus
> controller and embedded memory.
> 
> Signed-off-by: Willy Liu 

Applied to net-next as this is just renaming rather than a functional
change.

Re: [PATCH] caif_virtio: Remove redundant initialization of variable err

[David Miller]

From: Jing Xiangfeng 
Date: Wed, 30 Sep 2020 09:29:54 +0800

> After commit a8c7687bf216 ("caif_virtio: Check that vringh_config is not
> null"), the variable err is being initialized with '-EINVAL' that is
> meaningless. So remove it.
> 
> Signed-off-by: Jing Xiangfeng 

Applied to net-next.

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Tue, 29 Sep 2020 13:04:46 +1000

> Caused by commit
> 
>   eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested 
> interface infrastructure")
> 
> interacting with commit
> 
>   e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation")
> 
> also in the net-next tree.

I would argue against that "also" as the first commit is only in the
'net' tree right now. :-)

This is simply something I'll have to resolve the next time net is merged
into net-next.

Thanks.