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, );
> +
> +   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 = _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] = _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(, 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 = >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_SELECT);
> >227  value |=

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(>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(>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=DwIBAg=5VD0RTtNlTh3ycd41b3MUw=jJYgtDM7QT-W-Fz_d29HYQ=a91mqnAqjcA0iLpnhkpBXCmVqE_BuOIny-YmkB8jp2U=4EiiISKLS8YORtIb2rqP7oxVeqhBmKzMHqJzWhDAuMw=
> >  
> 
> ___
> 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 = >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 = _audio_graph_ops;
> + priv->force_dpcm = 1;
> +
> + memset(, 0, sizeof(li));
> + graph_get_dais_count(priv, );
> + if (!li.link || !li.dais)
> + return -EINVAL;
> +
> + err = asoc_simple_init_priv(priv, );
> + 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 = >simple;
priv->ops_hook_pre = _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(>to_v_msg_chan.qstats[i].qcnts, 0,
> >> +   sizeof(vk->to_v_msg_chan.qstats[i].qcnts));
> >> +    memset(>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(>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(>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(>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, >pci_epf, list) {
+   pci_epf_unbind(epf);
+   pci_epf_bind(epf);
+   }
+   pci_epc_start(epc);
+
+   dev_info(>dev, "[epc-restart] assert\n");
+   }
+
+   dev_info(>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(>restart_comp);
+
+   epc->restart_task = kthread_run(pci_epc_restart_thread, epc,
+   "pci-epc-restart");
+   if (IS_ERR(epc->restart_task))
+   return 

[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(>lock);
epc->ops->stop(epc);
+   epc->started = false;
mutex_unlock(>lock);
 }
 EXPORT_SYMBOL_GPL(pci_epc_stop);
@@ -170,6 +171,7 @@ int pci_epc_start(struct pci_epc *epc)
 
mutex_lock(>lock);
ret = epc->ops->start(epc);
+   epc->started = true;
mutex_unlock(>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(>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(, 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 = reset_subordinate_device(dev);
+   pci_walk_bridge(bridge, report_frozen_detected, );

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).  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(, 0, sizeof(cfg));
 
return ufshcd_program_key(hba, , 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(, 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 

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(>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 = _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(>reg_mutex);
mutex_init(>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(>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(>termios_rwsem);
down_read(>termios_rwsem);
clear n_tty buffer contents
up_read(>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(>termios_rwsem);
 __receive_buf()
  copies data into n_tty buffer
 up_read(>termios_rwsem);
 down_read(>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(>termios_rwsem);
 
+   if (test_bit(TTY_HUPPING, >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(>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 _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.

[PATCH v4] mmc: core: don't set limits.discard_granularity as 0

[Coly Li]

In mmc_queue_setup_discard() the mmc driver queue's discard_granularity
might be set as 0 (when card->pref_erase > max_discard) while the mmc
device still declares to support discard operation. This is buggy and
triggered the following kernel warning message,

WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294
CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1
Hardware name: Google Kevin (DT)
pstate: 0005 (nzcv daif -PAN -UAO BTYPE=--)
pc : __blkdev_issue_discard+0x200/0x294
lr : __blkdev_issue_discard+0x54/0x294
sp : 800011dd3b10
x29: 800011dd3b10 x28:  x27: 800011dd3cc4 x26: 
800011dd3e18 x25: 0004e69b x24: 0c40 x23: 
f1deaaf0 x22: f2849200 x21: 002734d8 x20: 
0008 x19:  x18:  x17: 
 x16:  x15:  x14: 
0394 x13:  x12:  x11: 
 x10: 08b0 x9 : 800011dd3cb0 x8 : 
0004e69b x7 :  x6 : f1926400 x5 : 
f1940800 x4 :  x3 : 0c40 x2 : 
0008 x1 : 002734d8 x0 :  Call trace:
__blkdev_issue_discard+0x200/0x294
__submit_discard_cmd+0x128/0x374
__issue_discard_cmd_orderly+0x188/0x244
__issue_discard_cmd+0x2e8/0x33c
issue_discard_thread+0xe8/0x2f0
kthread+0x11c/0x120
ret_from_fork+0x10/0x1c
---[ end trace e4c8023d33dfe77a ]---

This patch fixes the issue by setting discard_granularity as SECTOR_SIZE
instead of 0 when (card->pref_erase > max_discard) is true. Now no more
complain from __blkdev_issue_discard() for the improper value of discard
granularity.

This issue is exposed after commit b35fd7422c2f ("block: check queue's
limits.discard_granularity in __blkdev_issue_discard()"), a "Fixes:" tag
is also added for the commit to make sure people won't miss this patch
after applying the change of __blkdev_issue_discard().

Fixes: e056a1b5b67b ("mmc: queue: let host controllers specify maximum discard 
timeout")
Fixes: b35fd7422c2f ("block: check queue's limits.discard_granularity in 
__blkdev_issue_discard()").
Reported-and-tested-by: Vicente Bergas 
Signed-off-by: Coly Li 
Acked-by: Adrian Hunter 
Cc: Ulf Hansson 
---
Changelog,
v4, update to Reported-and-tested-by tag for Vicente Bergas.
v3, add Fixes tag for both commits.
v2, change commit id of the Fixes tag.
v1, initial version.

 drivers/mmc/core/queue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 6c022ef0f84d..350d0cc4ee62 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -190,7 +190,7 @@ static void mmc_queue_setup_discard(struct request_queue *q,
q->limits.discard_granularity = card->pref_erase << 9;
/* granularity must not be greater than max. discard */
if (card->pref_erase > max_discard)
-   q->limits.discard_granularity = 0;
+   q->limits.discard_granularity = SECTOR_SIZE;
if (mmc_can_secure_erase_trim(card))
blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
 }
-- 
2.26.2

Re: [PATCH net-next] drivers/net/wan/hdlc_fr: Correctly handle special skb->protocol values

[David Miller]

From: Xie He 
Date: Mon, 28 Sep 2020 05:56:43 -0700

> The fr_hard_header function is used to prepend the header to skbs before
> transmission. It is used in 3 situations:
> 1) When a control packet is generated internally in this driver;
> 2) When a user sends an skb on an Ethernet-emulating PVC device;
> 3) When a user sends an skb on a normal PVC device.
> 
> These 3 situations need to be handled differently by fr_hard_header.
> Different headers should be prepended to the skb in different situations.
> 
> Currently fr_hard_header distinguishes these 3 situations using
> skb->protocol. For situation 1 and 2, a special skb->protocol value
> will be assigned before calling fr_hard_header, so that it can recognize
> these 2 situations. All skb->protocol values other than these special ones
> are treated by fr_hard_header as situation 3.
> 
> However, it is possible that in situation 3, the user sends an skb with
> one of the special skb->protocol values. In this case, fr_hard_header
> would incorrectly treat it as situation 1 or 2.
> 
> This patch tries to solve this issue by using skb->dev instead of
> skb->protocol to distinguish between these 3 situations. For situation
> 1, skb->dev would be NULL; for situation 2, skb->dev->type would be
> ARPHRD_ETHER; and for situation 3, skb->dev->type would be ARPHRD_DLCI.
> 
> This way fr_hard_header would be able to distinguish these 3 situations
> correctly regardless what skb->protocol value the user tries to use in
> situation 3.
> 
> Cc: Krzysztof Halasa 
> Signed-off-by: Xie He 

Applied, thank you.

Re: [PATCH v3] mmc: core: don't set limits.discard_granularity as 0

[Coly Li]

On 2020/10/2 02:47, Vicente Bergas wrote:
> On Thursday, October 1, 2020 9:18:24 AM CEST, Coly Li wrote:
>> In mmc_queue_setup_discard() the mmc driver queue's discard_granularity
>> might be set as 0 (when card->pref_erase > max_discard) while the mmc
>> device still declares to support discard operation. This is buggy and
>> triggered the following kernel warning message,
>>
>> WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294
>> CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1
>> Hardware name: Google Kevin (DT)
>> pstate: 0005 (nzcv daif -PAN -UAO BTYPE=--)
>> pc : __blkdev_issue_discard+0x200/0x294
>> lr : __blkdev_issue_discard+0x54/0x294
>> sp : 800011dd3b10
>> x29: 800011dd3b10 x28:  x27: 800011dd3cc4 x26:
>> 800011dd3e18 x25: 0004e69b x24: 0c40 x23:
>> f1deaaf0 x22: f2849200 x21: 002734d8 x20:
>> 0008 x19:  x18:  x17:
>>  x16:  x15:  x14:
>> 0394 x13:  x12:  x11:
>>  x10: 08b0 x9 : 800011dd3cb0 x8 :
>> 0004e69b x7 :  x6 : f1926400 x5 :
>> f1940800 x4 :  x3 : 0c40 x2 :
>> 0008 x1 : 002734d8 x0 :  Call trace:
>> __blkdev_issue_discard+0x200/0x294
>> __submit_discard_cmd+0x128/0x374
>> __issue_discard_cmd_orderly+0x188/0x244
>> __issue_discard_cmd+0x2e8/0x33c
>> issue_discard_thread+0xe8/0x2f0
>> kthread+0x11c/0x120
>> ret_from_fork+0x10/0x1c
>> ---[ end trace e4c8023d33dfe77a ]---
>>
>> This patch fixes the issue by setting discard_granularity as SECTOR_SIZE
>> instead of 0 when (card->pref_erase > max_discard) is true. Now no more
>> complain from __blkdev_issue_discard() for the improper value of discard
>> granularity.
>>
>> This issue is exposed after commit b35fd7422c2f ("block: check queue's
>> limits.discard_granularity in __blkdev_issue_discard()"), a "Fixes:" tag
>> is also added for the commit to make sure people won't miss this patch
>> after applying the change of __blkdev_issue_discard().
>>
>> Fixes: e056a1b5b67b ("mmc: queue: let host controllers specify maximum
>> discard timeout")
>> Fixes: b35fd7422c2f ("block: check queue's limits.discard_granularity
>> in __blkdev_issue_discard()").
>> Reported-by: Vicente Bergas 
>> Signed-off-by: Coly Li 
>> Acked-by: Adrian Hunter 
>> Cc: Ulf Hansson 
>> ---
>> Changelog,
>> v3, add Fixes tag for both commits.
>> v2, change commit id of the Fixes tag.
>> v1, initial version.
>>
>>  drivers/mmc/core/queue.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
>> index 6c022ef0f84d..350d0cc4ee62 100644
>> --- a/drivers/mmc/core/queue.c
>> +++ b/drivers/mmc/core/queue.c
>> @@ -190,7 +190,7 @@ static void mmc_queue_setup_discard(struct
>> request_queue *q,
>>  q->limits.discard_granularity = card->pref_erase << 9;
>>  /* granularity must not be greater than max. discard */
>>  if (card->pref_erase > max_discard)
>> -    q->limits.discard_granularity = 0;
>> +    q->limits.discard_granularity = SECTOR_SIZE;
>>  if (mmc_can_secure_erase_trim(card))
>>  blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
>>  }
> 
> Tested on rk3399-gru-kevin with f2fs filesystem over the mmc driver, that
> is, the same setup that reproduced the issue.
> The kernel warning message is no longer reported.
> So,
> Tested-by: Vicente Bergas 
> 

Hi Vicente,

Thank you very much!

Coly Li

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

[Nicolin Chen]

On Thu, Oct 01, 2020 at 12:46:14PM +0200, Thierry Reding wrote:
> > > > -   /*
> > > > -* This is a bit of a hack. Ideally we'd want to simply return 
> > > > this
> > > > -* value. However the IOMMU registration process will attempt 
> > > > to add
> > > > -* all devices to the IOMMU when bus_set_iommu() is called. In 
> > > > order
> > > > -* not to rely on global variables to track the IOMMU instance, 
> > > > we
> > > > -* set it here so that it can be looked up from the 
> > > > .probe_device()
> > > > -* callback via the IOMMU device's .drvdata field.
> > > > -*/
> > > > -   mc->smmu = smmu;
> > > 
> > > I don't think this is going to work. I distinctly remember putting this
> > > here because we needed access to this before ->probe_device() had been
> > > called for any of the devices.
> > 
> > Do you remember which exact part of code needs to access mc->smmu
> > before ->probe_device() is called?
> > 
> > What I understood is that IOMMU core didn't allow ERR_PTR(-ENODEV)
> > return value from ->probe_device(), previously ->add_device(), to
> > carry on when you added this code/driver:
> > commit 8918465163171322c77a19d5258a95f56d89d2e4
> > Author: Thierry Reding 
> > Date:   Wed Apr 16 09:24:44 2014 +0200
> > memory: Add NVIDIA Tegra memory controller support
> > 
> > ..until the core had a change one year later:
> > commit 38667f18900afe172a4fe44279b132b4140f920f
> > Author: Joerg Roedel 
> > Date:   Mon Jun 29 10:16:08 2015 +0200
> > iommu: Ignore -ENODEV errors from add_device call-back
> > 
> > As my commit message of this change states, ->probe_device() will
> > be called in from both bus_set_iommu() and really_probe() of each
> > device through of_iommu_configure() -- the later one initializes
> > an fwspec by polling the iommus property in the IOMMU core, same
> > as what we do here in tegra-smmu. If this works, we can probably
> > drop the hack here and get rid of tegra_smmu_configure().
> 
> Looking at this a bit more, I notice that tegra_smmu_configure() does a
> lot of what's already done during of_iommu_configure(), so it'd indeed
> be nice if we could somehow get rid of that. However, like I said, I do
> recall that for DMA/IOMMU we need this prior to ->probe_device(), so it
> isn't clear to me if we can do that.
> 
> So I think in order to make progress we need to check that dropping this
> does indeed still work when we enable DMA/IOMMU (and the preliminary
> patches to pass 1:1 mappings via reserved-memory regions). If so, I
> think it should be safe to remove this.

I am attaching a patch that works with both IOMMU_DOMAIN_UNMANAGED
and IOMMU_DOMAIN_DMA. Would it be possible for you to give a test?

The implementation of getting mc->smmu is using a parent_driver as
I was asking you in the other reply. Yet, it could let us give it a
try.
>From 01693c8d4af5abb38bb5ede4b22590a647909868 Mon Sep 17 00:00:00 2001
From: Nicolin Chen 
Date: Thu, 1 Oct 2020 17:51:26 -0700
Subject: [PATCH] iommu/tegra-smmu: Test

Signed-off-by: Nicolin Chen 
---
 drivers/iommu/tegra-smmu.c | 141 -
 drivers/memory/tegra/mc.c  |   5 +-
 include/soc/tegra/mc.h |   4 +-
 3 files changed, 51 insertions(+), 99 deletions(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 6a3ecc334481..ade952d3143c 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -61,6 +61,9 @@ struct tegra_smmu_as {
 	u32 attr;
 };
 
+static const struct iommu_ops tegra_smmu_ops;
+static struct device_driver *parent_driver;
+
 static struct tegra_smmu_as *to_smmu_as(struct iommu_domain *dom)
 {
 	return container_of(dom, struct tegra_smmu_as, domain);
@@ -484,60 +487,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,
-	   )) {
-		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 

Re: [PATCH blk-next 0/2] Delete the get_vector_affinity leftovers

[Jens Axboe]

On 9/30/20 11:01 PM, Leon Romanovsky wrote:
> On Tue, Sep 29, 2020 at 12:13:56PM +0300, Leon Romanovsky wrote:
>> From: Leon Romanovsky 
>>
>> There are no drivers that implement .get_vector_affinity(), so delete
>> the RDMA function and simplify block code.
>>
>> Thanks
>>
>> P.S. Probably it should go through block tree.
>>
>> Leon Romanovsky (2):
>>   blk-mq-rdma: Delete not-used multi-queue RDMA map queue code
>>   RDMA/core: Delete not-implemented get_vector_affinity
> 
> Jens, Keith
> 
> How can we progress here?

I'd really like for the nvme side to sign off on this first.

-- 
Jens Axboe

[PATCH v2] tracepoint: Fix out of sync data passing by static caller

[Steven Rostedt]

From: Steven Rostedt (VMware) 

Naresh reported a bug discovered in linux-next that I can reliably
trigger myself. It appears to be a side effect of the static calls. It
happens when going from more than one tracepoint callback to a single
one, and removing the first callback on the list. The list of
tracepoint callbacks holds data and a function to call with the
parameters of that tracepoint and a handler to the associated data.

 old_list:
0: func = foo; data = NULL;
1: func = bar; data = _struct;

 new_list:
0: func = bar; data = _struct;


CPU 0   CPU 1
-   -
   tp_funcs = old_list;
   tp_static_caller = tp_interator

   __DO_TRACE()
 
data = tp_funcs[0].data = NULL;

   tp_funcs = new_list;
   tracepoint_update_call()
  tp_static_caller = tp_funcs[0] = bar;
tp_static_caller(data)
   bar(data)
 x = data->item = NULL->item

   BOOM!

[ Update: The current code is actually worse, which is probably why it
  is so easy to trigger. It does the tp_funcs = new_list *after* the
  static_caller update! ]

Funny, I was able to reliably trigger this bug, and always on the
sched_switch tracepoint. Which does make sense, because the
sched_switch tracepoint is a utility tracepoint that is attached to
collect information about tasks when tracing is enabled (like mapping
pids to comms). And most of these utility helpers do not have a data
item attached. But the trace events that attach to tracepoints do have
a data item that is used to find state and know what tracing buffer to
write to.

The race window is probably extended by any synchronization the text
poke may do, which would cause the sched switch to be triggered at
vulnerable times.

I've seen this:

 Testing event sched_migrate_task: OK
 Testing event sched_switch:
 BUG: kernel NULL pointer dereference, address: 0048
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x) - not-present page
 PGD 0 P4D 0
 Oops:  [#1] PREEMPT SMP PTI
 CPU: 4 PID: 158 Comm: kworker/4:2 Not tainted 5.9.0-rc7-test-next-20201001+ #12
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
07/14/2016
 Workqueue:  0x0 (events)
 RIP: 0010:trace_event_raw_event_sched_switch+0x1d/0x160
 Code: 75 c3 e9 4e ff ff ff e8 01 bd 9f 00 90 55 48 89 e5 41 57 49 89 cf 41 56 
49 89 d6 41 55 41 89 f5 41 54 49 89 fc 53 48 83 ec 40 <48> 8b 5f 48 65 48 8b 04 
25 28 00 00 00 48
1 c0 f6 c7
 RSP: 0018:a93680487dc8 EFLAGS: 00010082
 RAX: 98a053129bb0 RBX: 98a05ab2df98 RCX: 98a059a7
 RDX: 98a052ce5180 RSI:  RDI: 
 RBP: a93680487e30 R08:  R09: 0001
 R10: 98a052ce5180 R11:  R12: 
 R13:  R14: 98a052ce5180 R15: 98a059a7
 FS:  () GS:98a05ab0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 0048 CR3: 3b612002 CR4: 001706e0
 Call Trace:
  ? trace_event_raw_event_sched_move_numa+0x100/0x100
  __schedule+0x5dd/0xa40
  schedule+0x45/0xe0
  worker_thread+0xc6/0x3a0
  ? process_one_work+0x570/0x570
  kthread+0x128/0x170
  ? kthread_park+0x90/0x90
  ret_from_fork+0x22/0x30

And that's called directly by the static call to the sched_switch trace
event callback (not the iterator), and it triggers with the data
pointer passed as NULL.

To solve this, add a tracepoint_synchronize_unregister() between
changing tp_funcs and updating the static tracepoint, that does both a
synchronize_rcu() and synchronize_srcu(). This will ensure that when
the static call is updated to the single callback that it will be
receiving the data that it registered with.

Note, to avoid over calling the synchronization functions, it is only
needed when going from the iterator back to a single caller, and if
that single caller wasn't the first one on the list before the update.

Link: 
https://lore.kernel.org/linux-next/CA+G9fYvPXVRO0NV7yL=FxCmFEMYkCwdz7R=9w+_votpt824...@mail.gmail.com

Reported-by: Naresh Kamboju 
Fixes: d25e37d89dd2f ("tracepoint: Optimize using static_call()")
Signed-off-by: Steven Rostedt (VMware) 
---

Changes since v1:

  - Noticed that tp_funcs wasn't assigned first before the static update.

diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 1b4be44d1d2b..3f659f855074 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -221,7 +221,7 @@ static void *func_remove(struct tracepoint_func **funcs,
return old;
 }
 
-static void tracepoint_update_call(struct tracepoint *tp, struct 
tracepoint_func *tp_funcs)
+static void tracepoint_update_call(struct tracepoint *tp, struct 
tracepoint_func *tp_funcs, bool sync)
 {
void *func = tp->iterator;
 
@@ -229

[PATCH 2/2] exec: Broadly lock nascent mm until setup_arg_pages()

[Jann Horn]

While AFAIK there currently is nothing that can modify the VMA tree of a
new mm until userspace has started running under the mm, we should properly
lock the mm here anyway, both to keep lockdep happy when adding locking
assertions and to be safe in the future in case someone e.g. decides to
permit VMA-tree-mutating operations in process_madvise_behavior_valid().

The goal of this patch is to broadly lock the nascent mm in the exec path,
from around the time it is created all the way to the end of
setup_arg_pages() (because setup_arg_pages() accesses bprm->vma).
As long as the mm is write-locked, keep it around in bprm->mm, even after
it has been installed on the task (with an extra reference on the mm, to
reduce complexity in free_bprm()).
After setup_arg_pages(), we have to unlock the mm so that APIs such as
copy_to_user() will work in the following binfmt-specific setup code.

Suggested-by: Jason Gunthorpe 
Suggested-by: Michel Lespinasse 
Signed-off-by: Jann Horn 
---
 fs/exec.c   | 68 -
 include/linux/binfmts.h |  2 +-
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 229dbc7aa61a..fe11d77e397a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -254,11 +254,6 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
return -ENOMEM;
vma_set_anonymous(vma);

-   if (mmap_write_lock_killable(mm)) {
-   err = -EINTR;
-   goto err_free;
-   }
-
/*
 * Place the stack at the largest stack address the architecture
 * supports. Later, we'll move this to an appropriate place. We don't
@@ -276,12 +271,9 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
goto err;

mm->stack_vm = mm->total_vm = 1;
-   mmap_write_unlock(mm);
bprm->p = vma->vm_end - sizeof(void *);
return 0;
 err:
-   mmap_write_unlock(mm);
-err_free:
bprm->vma = NULL;
vm_area_free(vma);
return err;
@@ -364,9 +356,9 @@ static int bprm_mm_init(struct linux_binprm *bprm)
struct mm_struct *mm = NULL;

bprm->mm = mm = mm_alloc();
-   err = -ENOMEM;
if (!mm)
-   goto err;
+   return -ENOMEM;
+   mmap_write_lock_nascent(mm);

/* Save current stack limit for all calculations made during exec. */
task_lock(current->group_leader);
@@ -374,17 +366,12 @@ static int bprm_mm_init(struct linux_binprm *bprm)
task_unlock(current->group_leader);

err = __bprm_mm_init(bprm);
-   if (err)
-   goto err;
-
-   return 0;
-
-err:
-   if (mm) {
-   bprm->mm = NULL;
-   mmdrop(mm);
-   }
+   if (!err)
+   return 0;

+   bprm->mm = NULL;
+   mmap_write_unlock(mm);
+   mmdrop(mm);
return err;
 }

@@ -735,6 +722,7 @@ static int shift_arg_pages(struct vm_area_struct
*vma, unsigned long shift)
 /*
  * Finalizes the stack vm_area_struct. The flags and permissions are updated,
  * the stack is optionally relocated, and some extra space is added.
+ * At the end of this, the mm_struct will be unlocked on success.
  */
 int setup_arg_pages(struct linux_binprm *bprm,
unsigned long stack_top,
@@ -787,9 +775,6 @@ int setup_arg_pages(struct linux_binprm *bprm,
bprm->loader -= stack_shift;
bprm->exec -= stack_shift;

-   if (mmap_write_lock_killable(mm))
-   return -EINTR;
-
vm_flags = VM_STACK_FLAGS;

/*
@@ -807,7 +792,7 @@ int setup_arg_pages(struct linux_binprm *bprm,
ret = mprotect_fixup(vma, , vma->vm_start, vma->vm_end,
vm_flags);
if (ret)
-   goto out_unlock;
+   return ret;
BUG_ON(prev != vma);

if (unlikely(vm_flags & VM_EXEC)) {
@@ -819,7 +804,7 @@ int setup_arg_pages(struct linux_binprm *bprm,
if (stack_shift) {
ret = shift_arg_pages(vma, stack_shift);
if (ret)
-   goto out_unlock;
+   return ret;
}

/* mprotect_fixup is overkill to remove the temporary stack flags */
@@ -846,11 +831,17 @@ int setup_arg_pages(struct linux_binprm *bprm,
current->mm->start_stack = bprm->p;
ret = expand_stack(vma, stack_base);
if (ret)
-   ret = -EFAULT;
+   return -EFAULT;

-out_unlock:
+   /*
+* From this point on, anything that wants to poke around in the
+* mm_struct must lock it by itself.
+*/
+   bprm->vma = NULL;
mmap_write_unlock(mm);
-   return ret;
+   mmput(mm);
+   bprm->mm = NULL;
+   return 0;
 }
 EXPORT_SYMBOL(setup_arg_pages);

@@ -1114,8 +1105,6 @@ static int exec_mmap(struct mm_struct *mm)
if (ret)
return ret;

-   mmap_write_lock_nascent(mm);
-
if (old_mm) {
/*
  

[PATCH 1/2] mmap locking API: Order lock of nascent mm outside lock of live mm

[Jann Horn]

Until now, the mmap lock of the nascent mm was ordered inside the mmap lock
of the old mm (in dup_mmap() and in UML's activate_mm()).
A following patch will change the exec path to very broadly lock the
nascent mm, but fine-grained locking should still work at the same time for
the new mm.
To do this in a way that lockdep is happy about, let's turn around the lock
ordering in both places that currently nest the locks.
Since SINGLE_DEPTH_NESTING is normally used for the inner nesting layer,
make up our own lock subclass MMAP_LOCK_SUBCLASS_NASCENT and use that
instead.

The added locking calls in exec_mmap() are temporary; the following patch
will move the locking out of exec_mmap().

Signed-off-by: Jann Horn 
---
 arch/um/include/asm/mmu_context.h |  3 +--
 fs/exec.c |  4 
 include/linux/mmap_lock.h | 23 +--
 kernel/fork.c |  7 ++-
 4 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/arch/um/include/asm/mmu_context.h
b/arch/um/include/asm/mmu_context.h
index 17ddd4edf875..c13bc5150607 100644
--- a/arch/um/include/asm/mmu_context.h
+++ b/arch/um/include/asm/mmu_context.h
@@ -48,9 +48,8 @@ static inline void activate_mm(struct mm_struct
*old, struct mm_struct *new)
 * when the new ->mm is used for the first time.
 */
__switch_mm(>context.id);
-   mmap_write_lock_nested(new, SINGLE_DEPTH_NESTING);
+   mmap_assert_write_locked(new);
uml_setup_stubs(new);
-   mmap_write_unlock(new);
 }

 static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
diff --git a/fs/exec.c b/fs/exec.c
index a91003e28eaa..229dbc7aa61a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1114,6 +1114,8 @@ static int exec_mmap(struct mm_struct *mm)
if (ret)
return ret;

+   mmap_write_lock_nascent(mm);
+
if (old_mm) {
/*
 * Make sure that if there is a core dump in progress
@@ -1125,6 +1127,7 @@ static int exec_mmap(struct mm_struct *mm)
if (unlikely(old_mm->core_state)) {
mmap_read_unlock(old_mm);
mutex_unlock(>signal->exec_update_mutex);
+   mmap_write_unlock(mm);
return -EINTR;
}
}
@@ -1138,6 +1141,7 @@ static int exec_mmap(struct mm_struct *mm)
tsk->mm->vmacache_seqnum = 0;
vmacache_flush(tsk);
task_unlock(tsk);
+   mmap_write_unlock(mm);
if (old_mm) {
mmap_read_unlock(old_mm);
BUG_ON(active_mm != old_mm);
diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
index 0707671851a8..24de1fe99ee4 100644
--- a/include/linux/mmap_lock.h
+++ b/include/linux/mmap_lock.h
@@ -3,6 +3,18 @@

 #include 

+/*
+ * Lock subclasses for the mmap_lock.
+ *
+ * MMAP_LOCK_SUBCLASS_NASCENT is for core kernel code that wants to lock an mm
+ * that is still being constructed and wants to be able to access the active mm
+ * normally at the same time. It nests outside MMAP_LOCK_SUBCLASS_NORMAL.
+ */
+enum {
+   MMAP_LOCK_SUBCLASS_NORMAL = 0,
+   MMAP_LOCK_SUBCLASS_NASCENT
+};
+
 #define MMAP_LOCK_INITIALIZER(name) \
.mmap_lock = __RWSEM_INITIALIZER((name).mmap_lock),

@@ -16,9 +28,16 @@ static inline void mmap_write_lock(struct mm_struct *mm)
down_write(>mmap_lock);
 }

-static inline void mmap_write_lock_nested(struct mm_struct *mm, int subclass)
+/*
+ * Lock an mm_struct that is still being set up (during fork or exec).
+ * This nests outside the mmap locks of live mm_struct instances.
+ * No interruptible/killable versions exist because at the points where you're
+ * supposed to use this helper, the mm isn't visible to anything else, so we
+ * expect the mmap_lock to be uncontended.
+ */
+static inline void mmap_write_lock_nascent(struct mm_struct *mm)
 {
-   down_write_nested(>mmap_lock, subclass);
+   down_write_nested(>mmap_lock, MMAP_LOCK_SUBCLASS_NASCENT);
 }

 static inline int mmap_write_lock_killable(struct mm_struct *mm)
diff --git a/kernel/fork.c b/kernel/fork.c
index da8d360fb032..db67eb4ac7bd 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -474,6 +474,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
unsigned long charge;
LIST_HEAD(uf);

+   mmap_write_lock_nascent(mm);
uprobe_start_dup_mmap();
if (mmap_write_lock_killable(oldmm)) {
retval = -EINTR;
@@ -481,10 +482,6 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
}
flush_cache_dup_mm(oldmm);
uprobe_dup_mmap(oldmm, mm);
-   /*
-* Not linked in yet - no deadlock potential:
-*/
-   mmap_write_lock_nested(mm, SINGLE_DEPTH_NESTING);

/* No ordering required: file already has been exposed. */
RCU_INIT_POINTER(mm->exe_file, get_mm_exe_file(oldmm));
@@ -600,12 +597,12 @@ static __latent_entropy int 

[PATCH 0/2] Broad write-locking of nascent mm in execve

[Jann Horn]

These two patches replace "mmap locking API: don't check locking
if the mm isn't live yet"[1], which is currently in the mmotm tree,
and should be placed in the same spot where the old patch was.

While I originally said that this would be an alternative
patch (meaning that the existing patch would have worked just
as well), the new patches actually address an additional issue
that the old patch missed (bprm->vma is used after the switch
to the new mm).

I have boot-tested these patches on x64-64 (with lockdep) and
!MMU arm (the latter with both FLAT and ELF).

[1] 
https://lkml.kernel.org/r/cag48ez03yjg9ju_6tgimcavjutyre_o4leq7901b5zocnna...@mail.gmail.com

Jann Horn (2):
  mmap locking API: Order lock of nascent mm outside lock of live mm
  exec: Broadly lock nascent mm until setup_arg_pages()

 arch/um/include/asm/mmu_context.h |  3 +-
 fs/exec.c | 64 ---
 include/linux/binfmts.h   |  2 +-
 include/linux/mmap_lock.h | 23 ++-
 kernel/fork.c |  7 +---
 5 files changed, 59 insertions(+), 40 deletions(-)


base-commit: fb0155a09b0224a7147cb07a4ce6034c8d29667f
prerequisite-patch-id: 08f97130a51898a5f6efddeeb5b42638577398c7
prerequisite-patch-id: 577664d761cd23fe9031ffdb1d3c9ac313572c67
prerequisite-patch-id: dc29a39716aa8689f80ba2767803d9df3709beaa
prerequisite-patch-id: 42b1b546d33391ead2753621f541bcc408af1769
prerequisite-patch-id: 2cbb839f57006f32e21f4229e099ae1bd782be24
prerequisite-patch-id: 1b4daf01cf61654a5ec54b5c3f7c7508be7244ee
prerequisite-patch-id: f46cc8c99f1909fe2a65fbc3cf1f6bc57489a086
prerequisite-patch-id: 2b0caed97223241d5008898dde995d02fda544e4
prerequisite-patch-id: 6b7adcb54989e1ec3370f256ff2c35d19cf785aa
-- 
2.28.0.806.g8561365e88-goog

VM_HUGEPAGE support for XFS

[Matthew Wilcox]

Today I decided to implement VM_HUGEPAGE support for XFS.  It turned out
to be a rather simpler implementation than I was expecting because I
could reuse the readahead implementation.

Feel free to try it for yourself:
http://git.infradead.org/users/willy/pagecache.git

The patches up to "fs: Do not update nr_thps for mappings which support... "
are in linux-next for 5.10.  I hope to get the rest into 5.11.

Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Alan Stern]

On Thu, Oct 01, 2020 at 02:54:12PM -0700, Matthias Kaehlcke wrote:
> Hi,
> 
> thanks for providing more insights on the USB hardware!

Sure.

> On Wed, Sep 30, 2020 at 09:24:13PM -0400, Alan Stern wrote:
> > A hub that attaches only to the USB-3 data wires in a cable is not USB
> > compliant.  A USB-2 device plugged into such a hub would not work.
> > 
> > But ports can be wired up in weird ways.  For example, it is possible
> > to have the USB-3 wires from a port going directly to the host
> > controller, while the USB-2 wires from the same port go through a
> > USB-2 hub which is then connected to a separate host controller.  (In
> > fact, my office computer has just such an arrangement.)
> 
> It's not clear to me how this case would be addressed when (some of) the
> handling is done in xhci-plat.c We have two host controllers now, which one
> is supposed to be in charge? I guess the idea is to specify the hub only
> for one of the controllers?

I don't grasp the point of this question.  It doesn't seem to be
relevant to the case you're concerned about -- your board isn't going to
wire up the special hub in this weird way, is it?

> > > Yes, I've been saying for some time we need a pre-probe. Or we need a
> > > forced probe where the subsystem walks the DT nodes for the bus and
> > > probes the devices in DT (if they're in DT, we know they are present).
> > > This was the discussion only a few weeks ago for MDIO (which I think
> > > concluded with they already do the latter).
> > 
> > This is why I suggested putting the new code into the xhci-platform
> > driver.  That is the right place for doing these "pre-probes" of DT
> > nodes for hubs attached to the host controller.
> 
> Reminder that the driver is not exclusively about powering the hub, but
> also about powering it off conditionally during system suspend, depending
> on what devices are connected to either of the busses. Should this also
> be done in the xhci-platform driver?

It certainly could be.  The platform-specific xhci suspend and resume
routines could power the hub on and off as needed, along with powering
the host controller.

> Since we are talking about "pre-probes" I imagine the idea is to have a
> USB device driver that implements the power on/off sequence (in pre_probe()
> and handles the suspend/resume case. I already went through a variant of
> this with an earlier version of the onboard_hub_driver, where suspend/resume
> case was handled by the USB hub device. One of the problems with this was
> that power must only be turned off after both USB hub devices have been
> suspended. Some instance needs to be aware that there are two USB devices
> and make the decision whether to cut the power during system suspend
> or not, which is one of the reasons I ended up with the platform
> driver. It's not clear to me how this would be addressed by using
> "pre-probes". Potentially some of the handling could be done by
> xhci-platform, but would that be really better than a dedicated driver?

_All_ of the handling could be done by xhci-plat.  Since the xHCI
controller is the parent of both the USB-2 and USB-3 incarnations of
the special hub, it won't get suspended until they are both in
suspend, and it will get resumed before either of them.  Similarly,
the power to the special hub could be switched on as part of the host
controller's probe routine and switched off during the host
controller's remove routine.

Using xhci-plat in this way would be better than a dedicated driver in
the sense that it wouldn't then be necessary to make up a fictitious
platform device and somehow describe it in DT.

The disadvantage is that we would end up with a driver that's
nominally meant to handle host controllers but now also manages (at
least in part) hubs.  A not-so-clean separation of functions.  But
that's not terribly different from the way your current patch works,
right?

Alan Stern

[PATCH] tracepoint: Fix out of sync data passing by static caller

[Steven Rostedt]

From: Steven Rostedt (VMware) 

Naresh reported a bug discovered in linux-next that I can reliably
trigger myself. It appears to be a side effect of the static calls. It
happens when going from more than one tracepoint callback to a single
one, and removing the first callback on the list. The list of
tracepoint callbacks holds data and a function to call with the
parameters of that tracepoint and a handler to the associated data.

 old_list:
0: func = foo; data = NULL;
1: func = bar; data = _struct;

 new_list:
0: func = bar; data = _struct;


CPU 0   CPU 1
-   -
   tp_funcs = old_list;
   tp_static_caller = tp_interator

   __DO_TRACE()
 
data = tp_funcs[0].data = NULL;

   tp_funcs = new_list;
   tracepoint_update_call()
  tp_static_caller = tp_funcs[0] = bar;
tp_static_caller(data)
   bar(data)
 x = data->item = NULL->item

   BOOM!

Funny, I was able to reliably trigger this bug, and always on the
sched_switch tracepoint. Which does make sense, because the
sched_switch tracepoint is a utility tracepoint that is attached to
collect information about tasks when tracing is enabled (like mapping
pids to comms). And most of these utility helpers do not have a data
item attached. But the trace events that attach to tracepoints do have
a data item that is used to find state and know what tracing buffer to
write to.

The race window is probably extended by any synchronization the text
poke may do, which would cause the sched switch to be triggered at
vulnerable times.

I've seen this:

 Testing event sched_migrate_task: OK
 Testing event sched_switch:
 BUG: kernel NULL pointer dereference, address: 0048
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x) - not-present page
 PGD 0 P4D 0
 Oops:  [#1] PREEMPT SMP PTI
 CPU: 4 PID: 158 Comm: kworker/4:2 Not tainted 5.9.0-rc7-test-next-20201001+ #12
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
07/14/2016
 Workqueue:  0x0 (events)
 RIP: 0010:trace_event_raw_event_sched_switch+0x1d/0x160
 Code: 75 c3 e9 4e ff ff ff e8 01 bd 9f 00 90 55 48 89 e5 41 57 49 89 cf 41 56 
49 89 d6 41 55 41 89 f5 41 54 49 89 fc 53 48 83 ec 40 <48> 8b 5f 48 65 48 8b 04 
25 28 00 00 00 48
1 c0 f6 c7
 RSP: 0018:a93680487dc8 EFLAGS: 00010082
 RAX: 98a053129bb0 RBX: 98a05ab2df98 RCX: 98a059a7
 RDX: 98a052ce5180 RSI:  RDI: 
 RBP: a93680487e30 R08:  R09: 0001
 R10: 98a052ce5180 R11:  R12: 
 R13:  R14: 98a052ce5180 R15: 98a059a7
 FS:  () GS:98a05ab0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 0048 CR3: 3b612002 CR4: 001706e0
 Call Trace:
  ? trace_event_raw_event_sched_move_numa+0x100/0x100
  __schedule+0x5dd/0xa40
  schedule+0x45/0xe0
  worker_thread+0xc6/0x3a0
  ? process_one_work+0x570/0x570
  kthread+0x128/0x170
  ? kthread_park+0x90/0x90
  ret_from_fork+0x22/0x30

And that's called directly by the static call to the sched_switch trace
event callback (not the iterator), and it triggers with the data
pointer passed as NULL.

To solve this, add a tracepoint_synchronize_unregister() between
changing tp_funcs and updating the static tracepoint, that does both a
synchronize_rcu() and synchronize_srcu(). This will ensure that when
the static call is updated to the single callback that it will be
receiving the data that it registered with.

Note, to avoid over calling the synchronization functions, it is only
needed when going from the iterator back to a single caller, and if
that single caller wasn't the first one on the list before the update.

Link: 
https://lore.kernel.org/linux-next/CA+G9fYvPXVRO0NV7yL=FxCmFEMYkCwdz7R=9w+_votpt824...@mail.gmail.com

Reported-by: Naresh Kamboju 
Fixes: d25e37d89dd2f ("tracepoint: Optimize using static_call()")
Signed-off-by: Steven Rostedt (VMware) 
---
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 1b4be44d1d2b..b0baec351bd7 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -221,7 +221,7 @@ static void *func_remove(struct tracepoint_func **funcs,
return old;
 }
 
-static void tracepoint_update_call(struct tracepoint *tp, struct 
tracepoint_func *tp_funcs)
+static void tracepoint_update_call(struct tracepoint *tp, struct 
tracepoint_func *tp_funcs, bool sync)
 {
void *func = tp->iterator;
 
@@ -229,8 +229,17 @@ static void tracepoint_update_call(struct tracepoint *tp, 
struct tracepoint_func
if (!tp->static_call_key)
return;
 
-   if (!tp_funcs[1].func)
+   if (!tp_funcs[1].func) {
   

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

[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.
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.

Re: [PATCH v8 6/8] KVM: x86: VMX: Prevent MSR passthrough when MSR access is denied

[Peter Xu]

Hi,

I reported in the v13 cover letter of kvm dirty ring series that this patch
seems to have been broken.  Today I tried to reproduce with a simplest vm, and
after a closer look...

On Fri, Sep 25, 2020 at 04:34:20PM +0200, Alexander Graf wrote:
> @@ -3764,15 +3859,14 @@ static u8 vmx_msr_bitmap_mode(struct kvm_vcpu *vcpu)
>   return mode;
>  }
>  
> -static void vmx_update_msr_bitmap_x2apic(struct kvm_vcpu *vcpu,
> -  unsigned long *msr_bitmap, u8 mode)
> +static void vmx_update_msr_bitmap_x2apic(struct kvm_vcpu *vcpu, u8 mode)
>  {
>   int msr;
>  
> - for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) {
> - unsigned word = msr / BITS_PER_LONG;
> - msr_bitmap[word] = (mode & MSR_BITMAP_MODE_X2APIC_APICV) ? 0 : 
> ~0;
> - msr_bitmap[word + (0x800 / sizeof(long))] = ~0;
> + for (msr = 0x800; msr <= 0x8ff; msr++) {
> + bool intercepted = !!(mode & MSR_BITMAP_MODE_X2APIC_APICV);
> +
> + vmx_set_intercept_for_msr(vcpu, msr, MSR_TYPE_RW, intercepted);
>   }
>  
>   if (mode & MSR_BITMAP_MODE_X2APIC) {

... I think we may want below change to be squashed:

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index d160aad59697..7d3f2815b04d 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -3781,9 +3781,10 @@ static void vmx_update_msr_bitmap_x2apic(struct kvm_vcpu 
*vcpu, u8 mode)
int msr;
 
for (msr = 0x800; msr <= 0x8ff; msr++) {
-   bool intercepted = !!(mode & MSR_BITMAP_MODE_X2APIC_APICV);
+   bool apicv = mode & MSR_BITMAP_MODE_X2APIC_APICV;
 
-   vmx_set_intercept_for_msr(vcpu, msr, MSR_TYPE_RW, intercepted);
+   vmx_set_intercept_for_msr(vcpu, msr, MSR_TYPE_R, !apicv);
+   vmx_set_intercept_for_msr(vcpu, msr, MSR_TYPE_W, true);
}
 
if (mode & MSR_BITMAP_MODE_X2APIC) {

This fixes my problem the same as having this patch reverted.

-- 
Peter Xu

Gute Nachrichten !

[Mr. Marvin]

Die letzten Monate waren nicht gut für Unternehmen, Institutionen und 
Einzelpersonen auf der ganzen Welt. Die globale Epidemie (Covid-19) hat alle 
finanziell erschöpft und Sie wurden nicht freigestellt. Ihr Hilferuf wurde 
gehört und wir sind bereit, Ihnen unsere freundliche Geste anzubieten. Sie 
gehören zu den 3. Chargen, die von unserem Fondsprogramm profitieren, und ich 
muss aufrichtig sagen, dass die 1. und 2. Charge für die von uns geleistete 
Hilfe dankbar ist. Sie haben erfolgreich die kumulierte Gesamtsumme von 
(50.000,00 USD) als Gemeinschaftsspende von Oxfam Aid erhalten. Antworten Sie 
zurück, um weitere Informationen und Anweisungen zur Beantragung Ihres 
Zuschusses zu erhalten.

Denken Sie daran, immer in Sicherheit zu bleiben und soziale Distanzierung zu 
üben. Befolgen Sie immer die Anweisungen der örtlichen Behörden.

Herr Marvin Sims,

Supervisor (Oxfam Finanzabteilung)
Oxfam International Inc

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

[Roman Gushchin]

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.

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
>292static inline void __mod_node_page_state(struct pglist_data 
> *pgdat,
>293enum node_stat_item item, int delta)
>294{
>  > 295if (vmstat_item_in_bytes(item)) {
>296VM_WARN_ON_ONCE(delta & (PAGE_SIZE - 1));
>297delta >>= PAGE_SHIFT;
>298}
>299
>300node_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=DwIBAg=5VD0RTtNlTh3ycd41b3MUw=jJYgtDM7QT-W-Fz_d29HYQ=a91mqnAqjcA0iLpnhkpBXCmVqE_BuOIny-YmkB8jp2U=4EiiISKLS8YORtIb2rqP7oxVeqhBmKzMHqJzWhDAuMw=
>  

[PATCH v3 06/13] x86/platform/uv: Add and Decode Arch Type in UVsystab

[Mike Travis]

A patch to add and process the UV Arch Type field in the UVsystab passed
from UV BIOS to the kernel.  This allows the system to be recognized
without relying on the OEM_ID which OEMs want to change.

Signed-off-by: Mike Travis 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Steve Wahl 
---
 arch/x86/include/asm/uv/bios.h |  16 +++-
 arch/x86/kernel/apic/x2apic_uv_x.c | 135 +
 arch/x86/platform/uv/bios_uv.c |  27 --
 3 files changed, 148 insertions(+), 30 deletions(-)

diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h
index 70050d0136c3..97ac595ebc6a 100644
--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -5,8 +5,8 @@
 /*
  * UV BIOS layer definitions.
  *
- *  Copyright (c) 2008-2009 Silicon Graphics, Inc.  All Rights Reserved.
- *  Copyright (c) Russ Anderson 
+ * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
+ * Copyright (c) Russ Anderson 
  */
 
 #include 
@@ -71,6 +71,11 @@ struct uv_gam_range_entry {
u32 limit;  /* PA bits 56:26 (UV_GAM_RANGE_SHFT) */
 };
 
+#defineUV_AT_SIZE  8   /* 7 character arch type + NULL char */
+struct uv_arch_type_entry {
+   chararchtype[UV_AT_SIZE];
+};
+
 #defineUV_SYSTAB_SIG   "UVST"
 #defineUV_SYSTAB_VERSION_1 1   /* UV2/3 BIOS version */
 #defineUV_SYSTAB_VERSION_UV4   0x400   /* UV4 BIOS base 
version */
@@ -79,10 +84,14 @@ struct uv_gam_range_entry {
 #defineUV_SYSTAB_VERSION_UV4_3 0x403   /* - GAM Range PXM 
Value */
 #defineUV_SYSTAB_VERSION_UV4_LATESTUV_SYSTAB_VERSION_UV4_3
 
+#defineUV_SYSTAB_VERSION_UV5   0x500   /* UV5 GAM base version 
*/
+#defineUV_SYSTAB_VERSION_UV5_LATESTUV_SYSTAB_VERSION_UV5
+
 #defineUV_SYSTAB_TYPE_UNUSED   0   /* End of table (offset 
== 0) */
 #defineUV_SYSTAB_TYPE_GAM_PARAMS   1   /* GAM PARAM 
conversions */
 #defineUV_SYSTAB_TYPE_GAM_RNG_TBL  2   /* GAM entry table */
-#defineUV_SYSTAB_TYPE_MAX  3
+#defineUV_SYSTAB_TYPE_ARCH_TYPE3   /* UV arch type */
+#defineUV_SYSTAB_TYPE_MAX  4
 
 /*
  * The UV system table describes specific firmware
@@ -133,6 +142,7 @@ extern s64 uv_bios_reserved_page_pa(u64, u64 *, u64 *, u64 
*);
 extern int uv_bios_set_legacy_vga_target(bool decode, int domain, int bus);
 
 extern int uv_bios_init(void);
+extern unsigned long get_uv_systab_phys(bool msg);
 
 extern unsigned long sn_rtc_cycles_per_second;
 extern int uv_type;
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 4e055a01cc63..353825a0b327 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -31,7 +31,8 @@ static u64gru_start_paddr, gru_end_paddr;
 static union uvh_apiciduvh_apicid;
 static int uv_node_id;
 
-/* Unpack OEM/TABLE ID's to be NULL terminated strings */
+/* Unpack AT/OEM/TABLE ID's to be NULL terminated strings */
+static u8 uv_archtype[UV_AT_SIZE];
 static u8 oem_id[ACPI_OEM_ID_SIZE + 1];
 static u8 oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
 
@@ -286,20 +287,104 @@ static void __init uv_stringify(int len, char *to, char 
*from)
strncpy(to, from, len-1);
 }
 
+/* Find UV arch type entry in UVsystab */
+static unsigned long __init early_find_archtype(struct uv_systab *st)
+{
+   int i;
+
+   for (i = 0; st->entry[i].type != UV_SYSTAB_TYPE_UNUSED; i++) {
+   unsigned long ptr = st->entry[i].offset;
+
+   if (!ptr)
+   continue;
+   ptr += (unsigned long)st;
+   if (st->entry[i].type == UV_SYSTAB_TYPE_ARCH_TYPE)
+   return ptr;
+   }
+   return 0;
+}
+
+/* Validate UV arch type field in UVsystab */
+static int __init decode_arch_type(unsigned long ptr)
+{
+   struct uv_arch_type_entry *uv_ate = (struct uv_arch_type_entry *)ptr;
+   int n = strlen(uv_ate->archtype);
+
+   if (n > 0 && n < sizeof(uv_ate->archtype)) {
+   pr_info("UV: UVarchtype received from BIOS\n");
+   uv_stringify(UV_AT_SIZE, uv_archtype, uv_ate->archtype);
+   return 1;
+   }
+   return 0;
+}
+
+/* Determine if UV arch type entry might exist in UVsystab */
+static int __init early_get_arch_type(void)
+{
+   unsigned long uvst_physaddr, uvst_size, ptr;
+   struct uv_systab *st;
+   u32 rev;
+   int ret;
+
+   uvst_physaddr = get_uv_systab_phys(0);
+   if (!uvst_physaddr)
+   return 0;
+
+   st = early_memremap_ro(uvst_physaddr, sizeof(struct uv_systab));
+   if (!st) {
+   pr_err("UV: Cannot access UVsystab, remap failed\n");
+   return 0;
+   }
+
+   rev = st->revision;
+   if (rev < UV_SYSTAB_VERSION_UV5) 

Re: [PATCH v3 devicetree 0/2] Add Seville Ethernet switch to T1040RDB

[Vladimir Oltean]

On Thu, Oct 01, 2020 at 01:10:05PM -0700, David Miller wrote:
> From: Vladimir Oltean 
> Date: Thu,  1 Oct 2020 16:20:11 +0300
> 
> > Seville is a DSA switch that is embedded inside the T1040 SoC, and
> > supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
> > 
> > This series adds this switch to the SoC's dtsi files and to the T1040RDB
> > board file.
> 
> I am assuming the devicetree folks will pick this series up.
> 
> Thanks.
> 

I can also resend via net-next if that's easier (the last commit on
arch/powerpc/boot/dts/fsl/t104*, as per today's linux-next, has been in
2018, so there is no conflict).

I need to resend anyway, due to an epic failure where I got the port
numbering wrong...

Re: [RESEND PATCH] spmi: prefix spmi bus device names with "spmi"

[David Collins]

On 10/1/20 11:51 AM, Stephen Boyd wrote:
> Quoting Mark Brown (2020-10-01 10:43:26)
>> On Wed, Sep 30, 2020 at 05:07:20PM -0700, Stephen Boyd wrote:
>>> Quoting David Collins (2020-09-22 15:04:18)
>>
 This helps to disambiguate SPMI device regmaps from I2C ones
 at /sys/kernel/debug/regmap since I2C devices use a very
 similar naming scheme: 0-.
>>
>>> Can regmap debugfs prepend the bus name on the node made in debugfs?
>>> Does it do that already?
>>
>> It doesn't do that.  I have to say that given the use of dev_name() in
>> logging it does feel like it'd be useful to have distinct names for
>> grepping if we're running into collisions, IIRC the reason I went with
>> dev_name() was that it's a commonly used human readable handle for
>> diagnostic infrastrucuture so it makes it easier to follow things around.
> 
> To me the dev_name() usage seems fine. Maybe David has some real reason
> to change this though?
> 
> In general I don't think userspace cares what the SPMI device name is,
> i.e. the device name isn't used for dev nodes because SPMI doesn't
> support ioctls or read/write APIs on the bus. That could be a nice
> feature addition though, to support something like i2c-dev.
> 
> Changing it so that regmap debugfs is less likely to collide looks
> weird. It doesn't actually collide anyway, so it seems like we're adding
> spmi prefix to make it easier to find in debugfs?

Yes, that is correct.  There isn't a collision since I2C uses 0- and
SPMI uses 0-00 naming scheme.  However, those names are very similar and
it is hard for a user to tell which is which inside
/sys/kernel/debug/regmap without a deep understanding of the I2C and SPMI
code.

The SPMI regmap debugfs files are used extensively for testing and debug
purposes internally at Qualcomm and by our customers.  It would be helpful
if the more verbose naming scheme were accepted upstream to avoid
confusion and broken test scripts.

Thanks,
David

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 11/13] x86/platform/uv: Update UV5 TSC Checking

[Mike Travis]

Update check of BIOS TSC sync status to include both possible "invalid"
states provided by newer UV5 BIOS.

Signed-off-by: Mike Travis 
Reviewed-by: Steve Wahl 
---
 arch/x86/include/asm/uv/uv_hub.h   |  2 +-
 arch/x86/kernel/apic/x2apic_uv_x.c | 24 ++--
 2 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index ecf5c93e7ae8..07079b59824d 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -726,7 +726,7 @@ extern void uv_nmi_setup_hubless(void);
 #define UVH_TSC_SYNC_SHIFT_UV2K16  /* UV2/3k have different bits */
 #define UVH_TSC_SYNC_MASK  3   /* 0011 */
 #define UVH_TSC_SYNC_VALID 3   /* 0011 */
-#define UVH_TSC_SYNC_INVALID   2   /* 0010 */
+#define UVH_TSC_SYNC_UNKNOWN   0   /*  */
 
 /* BMC sets a bit this MMR non-zero before sending an NMI */
 #define UVH_NMI_MMRUVH_BIOS_KERNEL_MMR
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 0e40f4866bc3..0c97315bf864 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -199,36 +199,32 @@ static void __init uv_tsc_check_sync(void)
int sync_state;
int mmr_shift;
char *state;
-   bool valid;
 
-   /* Accommodate different UV arch BIOSes */
+   /* Different returns from different UV BIOS versions */
mmr = uv_early_read_mmr(UVH_TSC_SYNC_MMR);
mmr_shift =
is_uv2_hub() ? UVH_TSC_SYNC_SHIFT_UV2K : UVH_TSC_SYNC_SHIFT;
sync_state = (mmr >> mmr_shift) & UVH_TSC_SYNC_MASK;
 
+   /* Check if TSC is valid for all sockets */
switch (sync_state) {
case UVH_TSC_SYNC_VALID:
state = "in sync";
-   valid = true;
+   mark_tsc_async_resets("UV BIOS");
break;
 
-   case UVH_TSC_SYNC_INVALID:
-   state = "unstable";
-   valid = false;
+   /* If BIOS state unknown, don't do anything */
+   case UVH_TSC_SYNC_UNKNOWN:
+   state = "unknown";
break;
+
+   /* Otherwise, BIOS indicates problem with TSC */
default:
-   state = "unknown: assuming valid";
-   valid = true;
+   state = "unstable";
+   mark_tsc_unstable("UV BIOS");
break;
}
pr_info("UV: TSC sync state from BIOS:0%d(%s)\n", sync_state, state);
-
-   /* Mark flag that says TSC != 0 is valid for socket 0 */
-   if (valid)
-   mark_tsc_async_resets("UV BIOS");
-   else
-   mark_tsc_unstable("UV BIOS");
 }
 
 /* Selector for (4|4A|5) structs */
-- 
2.21.0

[PATCH v3 12/13] x86/platform/uv: Update for UV5 NMI MMR changes

[Mike Travis]

The UV NMI MMR addresses and fields moved between UV4 and UV5
necessitating a rewrite of the UV NMI handler.  Adjust references
to accommodate those changes.

Signed-off-by: Mike Travis 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Steve Wahl 
---
 arch/x86/include/asm/uv/uv_hub.h | 13 ---
 arch/x86/platform/uv/uv_nmi.c| 64 +++-
 2 files changed, 54 insertions(+), 23 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 07079b59824d..610bda21a8d9 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -734,19 +734,6 @@ extern void uv_nmi_setup_hubless(void);
 #define UVH_NMI_MMR_SHIFT  63
 #define UVH_NMI_MMR_TYPE   "SCRATCH5"
 
-/* Newer SMM NMI handler, not present in all systems */
-#define UVH_NMI_MMRX   UVH_EVENT_OCCURRED0
-#define UVH_NMI_MMRX_CLEAR UVH_EVENT_OCCURRED0_ALIAS
-#define UVH_NMI_MMRX_SHIFT UVH_EVENT_OCCURRED0_EXTIO_INT0_SHFT
-#define UVH_NMI_MMRX_TYPE  "EXTIO_INT0"
-
-/* Non-zero indicates newer SMM NMI handler present */
-#define UVH_NMI_MMRX_SUPPORTED UVH_EXTIO_INT0_BROADCAST
-
-/* Indicates to BIOS that we want to use the newer SMM NMI handler */
-#define UVH_NMI_MMRX_REQ   UVH_BIOS_KERNEL_MMR_ALIAS_2
-#define UVH_NMI_MMRX_REQ_SHIFT 62
-
 struct uv_hub_nmi_s {
raw_spinlock_t  nmi_lock;
atomic_tin_nmi; /* flag this node in UV NMI IRQ */
diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c
index 9d08ff5a755e..eac26feb0461 100644
--- a/arch/x86/platform/uv/uv_nmi.c
+++ b/arch/x86/platform/uv/uv_nmi.c
@@ -2,8 +2,8 @@
 /*
  * SGI NMI support routines
  *
- *  Copyright (c) 2009-2013 Silicon Graphics, Inc.  All Rights Reserved.
- *  Copyright (c) Mike Travis
+ * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
+ * Copyright (c) Mike Travis
  */
 
 #include 
@@ -54,6 +54,20 @@ static struct uv_hub_nmi_s **uv_hub_nmi_list;
 
 DEFINE_PER_CPU(struct uv_cpu_nmi_s, uv_cpu_nmi);
 
+/* Newer SMM NMI handler, not present in all systems */
+static unsigned long uvh_nmi_mmrx; /* UVH_EVENT_OCCURRED0/1 */
+static unsigned long uvh_nmi_mmrx_clear;   /* UVH_EVENT_OCCURRED0/1_ALIAS 
*/
+static int uvh_nmi_mmrx_shift; /* 
UVH_EVENT_OCCURRED0/1_EXTIO_INT0_SHFT */
+static int uvh_nmi_mmrx_mask;  /* 
UVH_EVENT_OCCURRED0/1_EXTIO_INT0_MASK */
+static char *uvh_nmi_mmrx_type;/* "EXTIO_INT0" */
+
+/* Non-zero indicates newer SMM NMI handler present */
+static unsigned long uvh_nmi_mmrx_supported;   /* UVH_EXTIO_INT0_BROADCAST */
+
+/* Indicates to BIOS that we want to use the newer SMM NMI handler */
+static unsigned long uvh_nmi_mmrx_req; /* UVH_BIOS_KERNEL_MMR_ALIAS_2 
*/
+static int uvh_nmi_mmrx_req_shift; /* 62 */
+
 /* UV hubless values */
 #define NMI_CONTROL_PORT   0x70
 #define NMI_DUMMY_PORT 0x71
@@ -227,13 +241,43 @@ static inline bool uv_nmi_action_is(const char *action)
 /* Setup which NMI support is present in system */
 static void uv_nmi_setup_mmrs(void)
 {
-   if (uv_read_local_mmr(UVH_NMI_MMRX_SUPPORTED)) {
-   uv_write_local_mmr(UVH_NMI_MMRX_REQ,
-   1UL << UVH_NMI_MMRX_REQ_SHIFT);
-   nmi_mmr = UVH_NMI_MMRX;
-   nmi_mmr_clear = UVH_NMI_MMRX_CLEAR;
-   nmi_mmr_pending = 1UL << UVH_NMI_MMRX_SHIFT;
-   pr_info("UV: SMI NMI support: %s\n", UVH_NMI_MMRX_TYPE);
+   /* First determine arch specific MMRs to handshake with BIOS */
+   if (UVH_EVENT_OCCURRED0_EXTIO_INT0_MASK) {
+   uvh_nmi_mmrx = UVH_EVENT_OCCURRED0;
+   uvh_nmi_mmrx_clear = UVH_EVENT_OCCURRED0_ALIAS;
+   uvh_nmi_mmrx_shift = UVH_EVENT_OCCURRED0_EXTIO_INT0_SHFT;
+   uvh_nmi_mmrx_mask = UVH_EVENT_OCCURRED0_EXTIO_INT0_MASK;
+   uvh_nmi_mmrx_type = "OCRD0-EXTIO_INT0";
+
+   uvh_nmi_mmrx_supported = UVH_EXTIO_INT0_BROADCAST;
+   uvh_nmi_mmrx_req = UVH_BIOS_KERNEL_MMR_ALIAS_2;
+   uvh_nmi_mmrx_req_shift = 62;
+
+   } else if (UVH_EVENT_OCCURRED1_EXTIO_INT0_MASK) {
+   uvh_nmi_mmrx = UVH_EVENT_OCCURRED1;
+   uvh_nmi_mmrx_clear = UVH_EVENT_OCCURRED1_ALIAS;
+   uvh_nmi_mmrx_shift = UVH_EVENT_OCCURRED1_EXTIO_INT0_SHFT;
+   uvh_nmi_mmrx_mask = UVH_EVENT_OCCURRED1_EXTIO_INT0_MASK;
+   uvh_nmi_mmrx_type = "OCRD1-EXTIO_INT0";
+
+   uvh_nmi_mmrx_supported = UVH_EXTIO_INT0_BROADCAST;
+   uvh_nmi_mmrx_req = UVH_BIOS_KERNEL_MMR_ALIAS_2;
+   uvh_nmi_mmrx_req_shift = 62;
+
+   } else {
+   pr_err("UV:%s:cannot find EVENT_OCCURRED*_EXTIO_INT0\n",
+   __func__);
+   return;
+   }
+
+   /* Then find out if new NMI is supported */
+   if 

[PATCH v3 03/13] x86/platform/uv: Adjust references in UV kernel modules

[Mike Travis]

Make a small symbol change (is_uv() ==> is_uv_sys()) to accommodate a
change in the uv_mmrs.h file (is_uv() is the new arch selector function).

Signed-off-by: Mike Travis 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Steve Wahl 
---
 drivers/misc/sgi-xp/xp.h| 8 
 drivers/misc/sgi-xp/xp_main.c   | 4 ++--
 drivers/misc/sgi-xp/xp_uv.c | 6 --
 drivers/misc/sgi-xp/xpc_main.c  | 6 +++---
 drivers/misc/sgi-xp/xpc_partition.c | 2 +-
 drivers/misc/sgi-xp/xpnet.c | 2 +-
 6 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/misc/sgi-xp/xp.h b/drivers/misc/sgi-xp/xp.h
index 06469b12aced..0af267baf031 100644
--- a/drivers/misc/sgi-xp/xp.h
+++ b/drivers/misc/sgi-xp/xp.h
@@ -17,11 +17,11 @@
 
 #if defined CONFIG_X86_UV || defined CONFIG_IA64_SGI_UV
 #include 
-#define is_uv()is_uv_system()
+#define is_uv_sys()is_uv_system()
 #endif
 
-#ifndef is_uv
-#define is_uv()0
+#ifndef is_uv_sys
+#define is_uv_sys()0
 #endif
 
 #ifdef USE_DBUG_ON
@@ -79,7 +79,7 @@
 
 #define XPC_MSG_SIZE(_payload_size) \
ALIGN(XPC_MSG_HDR_MAX_SIZE + (_payload_size), \
- is_uv() ? 64 : 128)
+ is_uv_sys() ? 64 : 128)
 
 
 /*
diff --git a/drivers/misc/sgi-xp/xp_main.c b/drivers/misc/sgi-xp/xp_main.c
index 61b03fcefb13..33558555820d 100644
--- a/drivers/misc/sgi-xp/xp_main.c
+++ b/drivers/misc/sgi-xp/xp_main.c
@@ -233,7 +233,7 @@ xp_init(void)
for (ch_number = 0; ch_number < XPC_MAX_NCHANNELS; ch_number++)
mutex_init(_registrations[ch_number].mutex);
 
-   if (is_uv())
+   if (is_uv_sys())
ret = xp_init_uv();
else
ret = 0;
@@ -249,7 +249,7 @@ module_init(xp_init);
 static void __exit
 xp_exit(void)
 {
-   if (is_uv())
+   if (is_uv_sys())
xp_exit_uv();
 }
 
diff --git a/drivers/misc/sgi-xp/xp_uv.c b/drivers/misc/sgi-xp/xp_uv.c
index f15a9f2ac1dd..118aef64518d 100644
--- a/drivers/misc/sgi-xp/xp_uv.c
+++ b/drivers/misc/sgi-xp/xp_uv.c
@@ -148,7 +148,9 @@ xp_restrict_memprotect_uv(unsigned long phys_addr, unsigned 
long size)
 enum xp_retval
 xp_init_uv(void)
 {
-   BUG_ON(!is_uv());
+   WARN_ON(!is_uv_sys());
+   if (!is_uv_sys())
+   return xpUnsupported;
 
xp_max_npartitions = XP_MAX_NPARTITIONS_UV;
 #ifdef CONFIG_X86
@@ -168,5 +170,5 @@ xp_init_uv(void)
 void
 xp_exit_uv(void)
 {
-   BUG_ON(!is_uv());
+   WARN_ON(!is_uv_sys());
 }
diff --git a/drivers/misc/sgi-xp/xpc_main.c b/drivers/misc/sgi-xp/xpc_main.c
index 8a495dc82f16..f533ded72941 100644
--- a/drivers/misc/sgi-xp/xpc_main.c
+++ b/drivers/misc/sgi-xp/xpc_main.c
@@ -1043,7 +1043,7 @@ xpc_do_exit(enum xp_retval reason)
 
xpc_teardown_partitions();
 
-   if (is_uv())
+   if (is_uv_sys())
xpc_exit_uv();
 }
 
@@ -1226,7 +1226,7 @@ xpc_init(void)
dev_set_name(xpc_part, "part");
dev_set_name(xpc_chan, "chan");
 
-   if (is_uv()) {
+   if (is_uv_sys()) {
ret = xpc_init_uv();
 
} else {
@@ -1312,7 +1312,7 @@ xpc_init(void)
 
xpc_teardown_partitions();
 out_1:
-   if (is_uv())
+   if (is_uv_sys())
xpc_exit_uv();
return ret;
 }
diff --git a/drivers/misc/sgi-xp/xpc_partition.c 
b/drivers/misc/sgi-xp/xpc_partition.c
index 099a53bdbb7d..c21d48fd65cd 100644
--- a/drivers/misc/sgi-xp/xpc_partition.c
+++ b/drivers/misc/sgi-xp/xpc_partition.c
@@ -433,7 +433,7 @@ xpc_discovery(void)
 */
region_size = xp_region_size;
 
-   if (is_uv())
+   if (is_uv_sys())
max_regions = 256;
else {
max_regions = 64;
diff --git a/drivers/misc/sgi-xp/xpnet.c b/drivers/misc/sgi-xp/xpnet.c
index 837d6c3fe69c..fc5cd83f21f2 100644
--- a/drivers/misc/sgi-xp/xpnet.c
+++ b/drivers/misc/sgi-xp/xpnet.c
@@ -515,7 +515,7 @@ xpnet_init(void)
 {
int result;
 
-   if (!is_uv())
+   if (!is_uv_sys())
return -ENODEV;
 
dev_info(xpnet, "registering network device %s\n", XPNET_DEVICE_NAME);
-- 
2.21.0

Re: [PATCH 7/7] TC-ETF support PTP clocks

[Thomas Gleixner]

On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:

>   - Add support for using a POSIX dynamic clock with
> Traffic control Earliest TxTime First (ETF) Qdisc.



> --- a/include/uapi/linux/net_tstamp.h
> +++ b/include/uapi/linux/net_tstamp.h
> @@ -167,6 +167,11 @@ enum txtime_flags {
>   SOF_TXTIME_FLAGS_MASK = (SOF_TXTIME_FLAGS_LAST - 1) |
>SOF_TXTIME_FLAGS_LAST
>  };
> +/*
> + * Clock ID to use with POSIX clocks
> + * The ID must be u8 to fit in (struct sock)->sk_clockid
> + */
> +#define SOF_TXTIME_POSIX_CLOCK_ID (0x77)

Random number with a random name. 
  
>  struct sock_txtime {
>   __kernel_clockid_t  clockid;/* reference clockid */
> diff --git a/net/sched/sch_etf.c b/net/sched/sch_etf.c
> index c0de4c6f9299..8e3e0a61fa58 100644
> --- a/net/sched/sch_etf.c
> +++ b/net/sched/sch_etf.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -40,19 +41,40 @@ struct etf_sched_data {
>   struct rb_root_cached head;
>   struct qdisc_watchdog watchdog;
>   ktime_t (*get_time)(void);
> +#ifdef CONFIG_POSIX_TIMERS
> + struct posix_clock *pclock; /* pointer to a posix clock */

Tail comments suck because they disturb the reading flow and this
comment has absolute zero value.

Comments are required to explain things which are not obvious...

> +#endif /* CONFIG_POSIX_TIMERS */

Also this #ifdeffery is bonkers. How is TSN supposed to work without
POSIX_TIMERS in the first place?

>  static const struct nla_policy etf_policy[TCA_ETF_MAX + 1] = {
>   [TCA_ETF_PARMS] = { .len = sizeof(struct tc_etf_qopt) },
>  };
>  
> +static inline ktime_t get_now(struct Qdisc *sch, struct etf_sched_data *q)
> +{
> +#ifdef CONFIG_POSIX_TIMERS
> + if (IS_ERR_OR_NULL(q->get_time)) {
> + struct timespec64 ts;
> + int err = posix_clock_gettime(q->pclock, );
> +
> + if (err) {
> + pr_warn("Clock is disabled (%d) for queue %d\n",
> + err, q->queue);
> + return 0;

That's really useful error handling.

> + }
> + return timespec64_to_ktime(ts);
> + }
> +#endif /* CONFIG_POSIX_TIMERS */
> + return q->get_time();
> +}
> +
>  static inline int validate_input_params(struct tc_etf_qopt *qopt,
>   struct netlink_ext_ack *extack)
>  {
>   /* Check if params comply to the following rules:
>*  * Clockid and delta must be valid.
>*
> -  *  * Dynamic clockids are not supported.
> +  *  * Dynamic CPU clockids are not supported.
>*
>*  * Delta must be a positive or zero integer.
>*
> @@ -60,11 +82,22 @@ static inline int validate_input_params(struct 
> tc_etf_qopt *qopt,
>* expect that system clocks have been synchronized to PHC.
>*/
>   if (qopt->clockid < 0) {
> +#ifdef CONFIG_POSIX_TIMERS
> + /**
> +  * Use of PTP clock through a posix clock.
> +  * The TC application must open the posix clock device file
> +  * and use the dynamic clockid from the file description.

What? How is the code which calls into this guaranteed to have a valid
file descriptor open for a particular dynamic posix clock?

> +  */
> + if (!is_clockid_fd_clock(qopt->clockid)) {
> + NL_SET_ERR_MSG(extack,
> +"Dynamic CPU clockids are not 
> supported");
> + return -EOPNOTSUPP;
> + }
> +#else /* CONFIG_POSIX_TIMERS */
>   NL_SET_ERR_MSG(extack, "Dynamic clockids are not supported");
>   return -ENOTSUPP;
> - }
> -
> - if (qopt->clockid != CLOCK_TAI) {
> +#endif /* CONFIG_POSIX_TIMERS */
> + } else if (qopt->clockid != CLOCK_TAI) {
>   NL_SET_ERR_MSG(extack, "Invalid clockid. CLOCK_TAI must be 
> used");
>   return -EINVAL;
>   }
> @@ -103,7 +136,7 @@ static bool is_packet_valid(struct Qdisc *sch, struct 
> etf_sched_data *q,
>   return false;
>  
>  skip:
> - now = q->get_time();
> + now = get_now(sch, q);

Yuck.

is_packet_valid() is invoked via:

__dev_queue_xmit()
  __dev_xmit_skb()
 etf_enqueue_timesortedlist()
   is_packet_valid()

__dev_queue_xmit() does

   rcu_read_lock_bh();

and your get_now() does

posix_clock_gettime()
down_read(>rwsem);

 > FAIL

down_read() might sleep and cannot be called from a BH disabled
region. This clearly has never been tested with any mandatory debug
option enabled. Why am I not surprised?

Aside of accessing PCH clock being slow at hell this cannot ever work
and there is no way to make it work in any consistent form.

If you have several NICs on several PCH domains then all of these
domains should have one thing in common: CLOCK_TAI and the frequency.

If that's not 

Re: [PATCH rdma-next v3 0/4] Query GID table API

[Jason Gunthorpe]

On Wed, Sep 23, 2020 at 07:50:11PM +0300, Leon Romanovsky wrote:
> When an application is not using RDMA CM and if it is using multiple RDMA
> devices with one or more RoCE ports, finding the right GID table entry is
> a long process.
> 
> For example, with two RoCE dual-port devices in a system, when IP
> failover is used between two RoCE ports, searching a suitable GID
> entry for a given source IP, matching netdevice of given RoCEv1/v2 type
> requires iterating over all 4 ports * 256 entry GID table.
> 
> Even though the best first match GID table for given criteria is used,
> when the matching entry is on the 4th port, it requires reading
> 3 ports * 256 entries * 3 files (GID, netdev, type) = 2304 files.
> 
> The GID table needs to be referred on every QP creation during IP
> failover on other netdevice of an RDMA device.
> 
> In an alternative approach, a GID cache may be maintained and updated on
> GID change event was reported by the kernel. However, it comes with below
> two limitations:
> (a) Maintain a thread per application process instance to listen and update
>  the cache.
> (b) Without the thread, on cache miss event, query the GID table. Even in
>  this approach, if multiple processes are used, a GID cache needs to be
>  maintained on a per-process basis. With a large number of processes,
>  this method doesn't scale.
> 
> Hence, we introduce this series of patches, which introduces an API to
> query the complete GID tables of an RDMA device, that returns all valid
> GID table entries.
> 
> This is done through single ioctl, eliminating 2304 read, 2304 open and
> 2304 close system calls to just a total of 2 calls (one for each device).
> 
> While at it, we also introduce an API to query an individual GID entry
> over ioctl interface, which provides all GID attributes information.
> 
> Thanks
> 
> Avihai Horon (4):
>   RDMA/core: Change rdma_get_gid_attr returned error code
>   RDMA/core: Modify enum ib_gid_type and enum rdma_network_type
>   RDMA/core: Introduce new GID table query API
>   RDMA/uverbs: Expose the new GID query API to user space

I made the edit to fix the locking, please check it

Applied to for-next

Thanks,
Jason

Re: [PATCH rdma-next] overflow: Include header file with SIZE_MAX declaration

[Jason Gunthorpe]

On Sun, Sep 13, 2020 at 01:29:28PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky 
> 
> The various array_size functions use SIZE_MAX define, but missed limits.h
> causes to failure to compile code that needs overflow.h.
> 
>  In file included from drivers/infiniband/core/uverbs_std_types_device.c:6:
>  ./include/linux/overflow.h: In function 'array_size':
>  ./include/linux/overflow.h:258:10: error: 'SIZE_MAX' undeclared (first use 
> in this function)
>258 |   return SIZE_MAX;
>|  ^~~~
> 
> Fixes: 610b15c50e86 ("overflow.h: Add allocation size calculation helpers")
> Signed-off-by: Leon Romanovsky 
> ---
>  include/linux/overflow.h | 1 +
>  1 file changed, 1 insertion(+)

Applied to rdma for-next, seems other patches need this. Thanks

Jason

[tip:x86/asm] BUILD SUCCESS aa5cacdc29d76a005cbbee018a47faa6e724dd2d

[kernel test robot]

 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
i386defconfig
sparc   defconfig
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
riscvnommu_virt_defconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
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

[PATCH v3 00/13] x86/platform/uv: Updates for UV5 Architecture

[Mike Travis]

Changes included in this patch set:

 * Add changes needed for new UV5 UV architecture.  Chief among the
   changes are 52 bits of physical memory address and 57 bits of
   virtual address space.

 * Remove the BAU TLB code cuurently being replaced by BAU APIC driver.

 * Remove System Controller (monitoring) code

 * Updated UV mmrs.h file removing UV1, adding UVY class, optimizing
   the arch selection of the MMR address/field, and trimming down MMR
   selection list reducing number of MMRs being defined.

 * Process UV ArchType in UV BIOS generated UVsystab allowing OEMs to
   use OEM_ID for their own purposes.

 * Update various mapping functions (MMIOH, MMR, GRU) to accommodate
   UV5 differences.

 * Update node present counting for change in MMRs.

 * Update TSC sync check of BIOS sync status.

 * Update NMI handler for UV5 MMR changes.

 * Update copyrights to conform to HPE standards.


This is version 2 with these changes since version 1: 

 * Added diffstats to p-intro.

 * Updated Copyrights to be in one file and only include the year
   the code was modified.

 * Updated to use git format-patch to construct patch email and 
   git send-email to send the patches.


This is version 3 with these changes since version 2: 

 * Changes made to .gitconfig so no internal (unreachable) systems
   are referenced.


Mike Travis (13):
  x86/platform/uv: Remove UV BAU TLB Shootdown Handler
  x86/platform/uv: Remove SCIR MMR references for UVY systems.
  x86/platform/uv: Adjust references in UV kernel modules
  x86/platform/uv: Update UV MMRs for UV5
  x86/platform/uv: Add UV5 direct references
  x86/platform/uv: Add and Decode Arch Type in UVsystab
  x86/platform/uv: Update MMIOH references based on new UV5 MMRs.
  x86/platform/uv: Adjust GAM MMR references affected by UV5 updates
  x86/platform/uv: Update UV5 MMR references in UV GRU
  x86/platform/uv: Update Node Present Counting
  x86/platform/uv: Update UV5 TSC Checking
  x86/platform/uv: Update for UV5 NMI MMR changes
  x86/platform/uv: Update Copyrights to conform to HPE standards

 arch/x86/include/asm/idtentry.h |4 -
 arch/x86/include/asm/uv/bios.h  |   17 +-
 arch/x86/include/asm/uv/uv.h|4 +-
 arch/x86/include/asm/uv/uv_bau.h|  755 ---
 arch/x86/include/asm/uv/uv_hub.h|  165 +-
 arch/x86/include/asm/uv/uv_mmrs.h   | 7646 ++-
 arch/x86/kernel/apic/x2apic_uv_x.c  |  817 ++-
 arch/x86/kernel/idt.c   |3 -
 arch/x86/mm/tlb.c   |   24 -
 arch/x86/platform/uv/Makefile   |2 +-
 arch/x86/platform/uv/bios_uv.c  |   28 +-
 arch/x86/platform/uv/tlb_uv.c   | 2097 
 arch/x86/platform/uv/uv_nmi.c   |   65 +-
 arch/x86/platform/uv/uv_time.c  |   11 +-
 drivers/misc/sgi-gru/grufile.c  |3 +-
 drivers/misc/sgi-xp/xp.h|9 +-
 drivers/misc/sgi-xp/xp_main.c   |5 +-
 drivers/misc/sgi-xp/xp_uv.c |7 +-
 drivers/misc/sgi-xp/xpc_main.c  |7 +-
 drivers/misc/sgi-xp/xpc_partition.c |3 +-
 drivers/misc/sgi-xp/xpnet.c |3 +-
 21 files changed, 4797 insertions(+), 6878 deletions(-)
 delete mode 100644 arch/x86/include/asm/uv/uv_bau.h
 delete mode 100644 arch/x86/platform/uv/tlb_uv.c

-- 
2.21.0

[PATCH v3 07/13] x86/platform/uv: Update MMIOH references based on new UV5 MMRs.

[Mike Travis]

Make modifications to the MMIOH mappings to accommodate changes for UV5.

Signed-off-by: Mike Travis 
Reviewed-by: Steve Wahl 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 211 +++--
 1 file changed, 143 insertions(+), 68 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 353825a0b327..746a56466066 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -228,6 +228,13 @@ static void __init uv_tsc_check_sync(void)
mark_tsc_unstable("UV BIOS");
 }
 
+/* Selector for (4|4A|5) structs */
+#define uvxy_field(sname, field, undef) (  \
+   is_uv(UV4A) ? sname.s4a.field : \
+   is_uv(UV4) ? sname.s4.field :   \
+   is_uv(UV3) ? sname.s3.field :   \
+   undef)
+
 /* [Copied from arch/x86/kernel/cpu/topology.c:detect_extended_topology()] */
 
 #define SMT_LEVEL  0   /* Leaf 0xb SMT level */
@@ -882,6 +889,7 @@ static __init void get_lowmem_redirect(unsigned long *base, 
unsigned long *size)
 }
 
 enum map_type {map_wb, map_uc};
+static const char * const mt[] = { "WB", "UC" };
 
 static __init void map_high(char *id, unsigned long base, int pshift, int 
bshift, int max_pnode, enum map_type map_type)
 {
@@ -893,11 +901,13 @@ static __init void map_high(char *id, unsigned long base, 
int pshift, int bshift
pr_info("UV: Map %s_HI base address NULL\n", id);
return;
}
-   pr_debug("UV: Map %s_HI 0x%lx - 0x%lx\n", id, paddr, paddr + bytes);
if (map_type == map_uc)
init_extra_mapping_uc(paddr, bytes);
else
init_extra_mapping_wb(paddr, bytes);
+
+   pr_info("UV: Map %s_HI 0x%lx - 0x%lx %s (%d segments)\n",
+   id, paddr, paddr + bytes, mt[map_type], max_pnode + 1);
 }
 
 static __init void map_gru_high(int max_pnode)
@@ -931,52 +941,73 @@ static __init void map_mmr_high(int max_pnode)
pr_info("UV: MMR disabled\n");
 }
 
-/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
-static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
-{
-   unsigned long overlay;
-   unsigned long mmr;
-   unsigned long base;
-   unsigned long nasid_mask;
-   unsigned long m_overlay;
-   int i, n, shift, m_io, max_io;
-   int nasid, lnasid, fi, li;
-   char *id;
-
-   if (index == 0) {
-   id = "MMIOH0";
-   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0;
-   overlay = uv_read_local_mmr(m_overlay);
-   base = overlay & UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_BASE_MASK;
+/* Arch specific ENUM cases */
+enum mmioh_arch {
+   UV2_MMIOH = -1,
+   UVY_MMIOH0, UVY_MMIOH1,
+   UVX_MMIOH0, UVX_MMIOH1,
+};
+
+/* Calculate and Map MMIOH Regions */
+void __init calc_mmioh_map(enum mmioh_arch index, int min_pnode, int max_pnode,
+   int shift, unsigned long base, int m_io, int n_io)
+{
+   unsigned long mmr, nasid_mask;
+   int nasid, min_nasid, max_nasid, lnasid, mapped;
+   int i, fi, li, n, max_io;
+   char id[8];
+
+   /* One (UV2) mapping */
+   if (index == UV2_MMIOH) {
+   strncpy(id, "MMIOH", sizeof(id));
+   max_io = max_pnode;
+   mapped = 0;
+   goto map_exit;
+   }
+
+   /* small and large MMIOH mappings */
+   switch (index) {
+   case UVY_MMIOH0:
+   mmr = UVH_RH10_GAM_MMIOH_REDIRECT_CONFIG0;
+   nasid_mask = UVH_RH10_GAM_MMIOH_OVERLAY_CONFIG0_BASE_MASK;
+   n = UVH_RH10_GAM_MMIOH_REDIRECT_CONFIG0_DEPTH;
+   min_nasid = min_pnode;
+   max_nasid = max_pnode;
+   mapped = 1;
+   break;
+   case UVY_MMIOH1:
+   mmr = UVH_RH10_GAM_MMIOH_REDIRECT_CONFIG1;
+   nasid_mask = UVH_RH10_GAM_MMIOH_OVERLAY_CONFIG1_BASE_MASK;
+   n = UVH_RH10_GAM_MMIOH_REDIRECT_CONFIG1_DEPTH;
+   min_nasid = min_pnode;
+   max_nasid = max_pnode;
+   mapped = 1;
+   break;
+   case UVX_MMIOH0:
mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0;
-   m_io = (overlay & UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_M_IO_MASK)
-   >> UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_M_IO_SHFT;
-   shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_M_IO_SHFT;
+   nasid_mask = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_BASE_MASK;
n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_DEPTH;
-   nasid_mask = UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_NASID_MASK;
-   } else {
-   id = "MMIOH1";
-   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1;
-   overlay = uv_read_local_mmr(m_overlay);
-   base = overlay & UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_BASE_MASK;
+   min_nasid = min_pnode * 2;
+

[PATCH v3 09/13] x86/platform/uv: Update UV5 MMR references in UV GRU

[Mike Travis]

Make modifications to the GRU mappings to accommodate changes for UV5.

Signed-off-by: Mike Travis 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Steve Wahl 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 30 --
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 9f89c1e82df0..678001ff789d 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -82,6 +82,9 @@ static unsigned long __init uv_early_read_mmr(unsigned long 
addr)
 
 static inline bool is_GRU_range(u64 start, u64 end)
 {
+   if (!gru_start_paddr)
+   return false;
+
return start >= gru_start_paddr && end <= gru_end_paddr;
 }
 
@@ -913,13 +916,24 @@ static __init void map_high(char *id, unsigned long base, 
int pshift, int bshift
 static __init void map_gru_high(int max_pnode)
 {
union uvh_rh_gam_gru_overlay_config_u gru;
-   int shift = UVH_RH_GAM_GRU_OVERLAY_CONFIG_BASE_SHFT;
-   unsigned long mask = UVH_RH_GAM_GRU_OVERLAY_CONFIG_BASE_MASK;
-   unsigned long base;
+   unsigned long mask, base;
+   int shift;
+
+   if (UVH_RH_GAM_GRU_OVERLAY_CONFIG) {
+   gru.v = uv_read_local_mmr(UVH_RH_GAM_GRU_OVERLAY_CONFIG);
+   shift = UVH_RH_GAM_GRU_OVERLAY_CONFIG_BASE_SHFT;
+   mask = UVH_RH_GAM_GRU_OVERLAY_CONFIG_BASE_MASK;
+   } else if (UVH_RH10_GAM_GRU_OVERLAY_CONFIG) {
+   gru.v = uv_read_local_mmr(UVH_RH10_GAM_GRU_OVERLAY_CONFIG);
+   shift = UVH_RH10_GAM_GRU_OVERLAY_CONFIG_BASE_SHFT;
+   mask = UVH_RH10_GAM_GRU_OVERLAY_CONFIG_BASE_MASK;
+   } else {
+   pr_err("UV: GRU unavailable (no MMR)\n");
+   return;
+   }
 
-   gru.v = uv_read_local_mmr(UVH_RH_GAM_GRU_OVERLAY_CONFIG);
if (!gru.s.enable) {
-   pr_info("UV: GRU disabled\n");
+   pr_info("UV: GRU disabled (by BIOS)\n");
return;
}
 
@@ -1293,7 +1307,11 @@ static void __init uv_init_hub_info(struct uv_hub_info_s 
*hi)
/* Show system specific info: */
pr_info("UV: N:%d M:%d m_shift:%d n_lshift:%d\n", hi->n_val, hi->m_val, 
hi->m_shift, hi->n_lshift);
pr_info("UV: gpa_mask/shift:0x%lx/%d pnode_mask:0x%x apic_pns:%d\n", 
hi->gpa_mask, hi->gpa_shift, hi->pnode_mask, hi->apic_pnode_shift);
-   pr_info("UV: mmr_base/shift:0x%lx/%ld gru_base/shift:0x%lx/%ld\n", 
hi->global_mmr_base, hi->global_mmr_shift, hi->global_gru_base, 
hi->global_gru_shift);
+   pr_info("UV: mmr_base/shift:0x%lx/%ld\n", hi->global_mmr_base, 
hi->global_mmr_shift);
+   if (hi->global_gru_base)
+   pr_info("UV: gru_base/shift:0x%lx/%ld\n",
+   hi->global_gru_base, hi->global_gru_shift);
+
pr_info("UV: gnode_upper:0x%lx gnode_extra:0x%x\n", hi->gnode_upper, 
hi->gnode_extra);
 }
 
-- 
2.21.0

[PATCH v3 10/13] x86/platform/uv: Update Node Present Counting

[Mike Travis]

The changes in the UV5 arch shrunk the NODE PRESENT table to just 2x64
entries (128 total) so are in to 64 bit MMRs instead of a depth of 64
bits in an array.  Adjust references when counting up the nodes present.

Signed-off-by: Mike Travis 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Steve Wahl 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 678001ff789d..0e40f4866bc3 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -1441,20 +1441,32 @@ static int __init decode_uv_systab(void)
 /* Set up physical blade translations from UVH_NODE_PRESENT_TABLE */
 static __init void boot_init_possible_blades(struct uv_hub_info_s *hub_info)
 {
+   unsigned long np;
int i, uv_pb = 0;
 
-   pr_info("UV: NODE_PRESENT_DEPTH = %d\n", UVH_NODE_PRESENT_TABLE_DEPTH);
-   for (i = 0; i < UVH_NODE_PRESENT_TABLE_DEPTH; i++) {
-   unsigned long np;
-
-   np = uv_read_local_mmr(UVH_NODE_PRESENT_TABLE + i * 8);
-   if (np)
+   if (UVH_NODE_PRESENT_TABLE) {
+   pr_info("UV: NODE_PRESENT_DEPTH = %d\n",
+   UVH_NODE_PRESENT_TABLE_DEPTH);
+   for (i = 0; i < UVH_NODE_PRESENT_TABLE_DEPTH; i++) {
+   np = uv_read_local_mmr(UVH_NODE_PRESENT_TABLE + i * 8);
pr_info("UV: NODE_PRESENT(%d) = 0x%016lx\n", i, np);
-
+   uv_pb += hweight64(np);
+   }
+   }
+   if (UVH_NODE_PRESENT_0) {
+   np = uv_read_local_mmr(UVH_NODE_PRESENT_0);
+   pr_info("UV: NODE_PRESENT_0 = 0x%016lx\n", np);
+   uv_pb += hweight64(np);
+   }
+   if (UVH_NODE_PRESENT_1) {
+   np = uv_read_local_mmr(UVH_NODE_PRESENT_1);
+   pr_info("UV: NODE_PRESENT_1 = 0x%016lx\n", np);
uv_pb += hweight64(np);
}
if (uv_possible_blades != uv_pb)
uv_possible_blades = uv_pb;
+
+   pr_info("UV: number nodes/possible blades %d\n", uv_pb);
 }
 
 static void __init build_socket_tables(void)
-- 
2.21.0

[PATCH v3 08/13] x86/platform/uv: Adjust GAM MMR references affected by UV5 updates

[Mike Travis]

Make modifications to the GAM MMR mappings to accommodate changes for UV5.

Signed-off-by: Mike Travis 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Steve Wahl 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 746a56466066..9f89c1e82df0 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -931,12 +931,32 @@ static __init void map_gru_high(int max_pnode)
 
 static __init void map_mmr_high(int max_pnode)
 {
-   union uvh_rh_gam_mmr_overlay_config_u mmr;
-   int shift = UVH_RH_GAM_MMR_OVERLAY_CONFIG_BASE_SHFT;
+   unsigned long base;
+   int shift;
+   bool enable;
+
+   if (UVH_RH10_GAM_MMR_OVERLAY_CONFIG) {
+   union uvh_rh10_gam_mmr_overlay_config_u mmr;
+
+   mmr.v = uv_read_local_mmr(UVH_RH10_GAM_MMR_OVERLAY_CONFIG);
+   enable = mmr.s.enable;
+   base = mmr.s.base;
+   shift = UVH_RH10_GAM_MMR_OVERLAY_CONFIG_BASE_SHFT;
+   } else if (UVH_RH_GAM_MMR_OVERLAY_CONFIG) {
+   union uvh_rh_gam_mmr_overlay_config_u mmr;
+
+   mmr.v = uv_read_local_mmr(UVH_RH_GAM_MMR_OVERLAY_CONFIG);
+   enable = mmr.s.enable;
+   base = mmr.s.base;
+   shift = UVH_RH_GAM_MMR_OVERLAY_CONFIG_BASE_SHFT;
+   } else {
+   pr_err("UV:%s:RH_GAM_MMR_OVERLAY_CONFIG MMR undefined?\n",
+   __func__);
+   return;
+   }
 
-   mmr.v = uv_read_local_mmr(UVH_RH_GAM_MMR_OVERLAY_CONFIG);
-   if (mmr.s.enable)
-   map_high("MMR", mmr.s.base, shift, shift, max_pnode, map_uc);
+   if (enable)
+   map_high("MMR", base, shift, shift, max_pnode, map_uc);
else
pr_info("UV: MMR disabled\n");
 }
-- 
2.21.0

[PATCH v3 13/13] x86/platform/uv: Update Copyrights to conform to HPE standards

[Mike Travis]

Add Copyrights to those files that have been updated for UV5 changes.

Signed-off-by: Mike Travis 
---
 arch/x86/include/asm/uv/bios.h  | 1 +
 arch/x86/include/asm/uv/uv_hub.h| 1 +
 arch/x86/include/asm/uv/uv_mmrs.h   | 1 +
 arch/x86/kernel/apic/x2apic_uv_x.c  | 1 +
 arch/x86/platform/uv/bios_uv.c  | 1 +
 arch/x86/platform/uv/uv_nmi.c   | 1 +
 arch/x86/platform/uv/uv_time.c  | 1 +
 drivers/misc/sgi-gru/grufile.c  | 1 +
 drivers/misc/sgi-xp/xp.h| 1 +
 drivers/misc/sgi-xp/xp_main.c   | 1 +
 drivers/misc/sgi-xp/xp_uv.c | 1 +
 drivers/misc/sgi-xp/xpc_main.c  | 1 +
 drivers/misc/sgi-xp/xpc_partition.c | 1 +
 drivers/misc/sgi-xp/xpnet.c | 1 +
 14 files changed, 14 insertions(+)

diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h
index 97ac595ebc6a..08b3d810dfba 100644
--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -5,6 +5,7 @@
 /*
  * UV BIOS layer definitions.
  *
+ * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
  * Copyright (c) Russ Anderson 
  */
diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 610bda21a8d9..5002f52be332 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -5,6 +5,7 @@
  *
  * SGI UV architectural definitions
  *
+ * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  * Copyright (C) 2007-2014 Silicon Graphics, Inc. All rights reserved.
  */
 
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 06ea2d1aaa3e..57fa67373262 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -5,6 +5,7 @@
  *
  * HPE UV MMR definitions
  *
+ * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  * Copyright (C) 2007-2016 Silicon Graphics, Inc. All rights reserved.
  */
 
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 0c97315bf864..7c895991389c 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -5,6 +5,7 @@
  *
  * SGI UV APIC functions (note: not an Intel compatible APIC)
  *
+ * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  * Copyright (C) 2007-2014 Silicon Graphics, Inc. All rights reserved.
  */
 #include 
diff --git a/arch/x86/platform/uv/bios_uv.c b/arch/x86/platform/uv/bios_uv.c
index b148b4c8c2ec..54511eaccf4d 100644
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -2,6 +2,7 @@
 /*
  * BIOS run time interface routines.
  *
+ * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
  * Copyright (c) Russ Anderson 
  */
diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c
index eac26feb0461..0f5cbcf0da63 100644
--- a/arch/x86/platform/uv/uv_nmi.c
+++ b/arch/x86/platform/uv/uv_nmi.c
@@ -2,6 +2,7 @@
 /*
  * SGI NMI support routines
  *
+ * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
  * Copyright (c) Mike Travis
  */
diff --git a/arch/x86/platform/uv/uv_time.c b/arch/x86/platform/uv/uv_time.c
index e94436ba3022..a39e0f394c0e 100644
--- a/arch/x86/platform/uv/uv_time.c
+++ b/arch/x86/platform/uv/uv_time.c
@@ -2,6 +2,7 @@
 /*
  * SGI RTC clock/timer routines.
  *
+ *  (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  *  Copyright (c) 2009-2013 Silicon Graphics, Inc.  All Rights Reserved.
  *  Copyright (c) Dimitri Sivanich
  */
diff --git a/drivers/misc/sgi-gru/grufile.c b/drivers/misc/sgi-gru/grufile.c
index 18aa8c877bf8..7ffcfc0bb587 100644
--- a/drivers/misc/sgi-gru/grufile.c
+++ b/drivers/misc/sgi-gru/grufile.c
@@ -7,6 +7,7 @@
  * This file supports the user system call for file open, close, mmap, etc.
  * This also incudes the driver initialization code.
  *
+ *  (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  *  Copyright (c) 2008-2014 Silicon Graphics, Inc.  All Rights Reserved.
  */
 
diff --git a/drivers/misc/sgi-xp/xp.h b/drivers/misc/sgi-xp/xp.h
index 0af267baf031..7d839d844847 100644
--- a/drivers/misc/sgi-xp/xp.h
+++ b/drivers/misc/sgi-xp/xp.h
@@ -3,6 +3,7 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
+ * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  * Copyright (C) 2004-2008 Silicon Graphics, Inc. All rights reserved.
  */
 
diff --git a/drivers/misc/sgi-xp/xp_main.c b/drivers/misc/sgi-xp/xp_main.c
index 33558555820d..049c9aef0559 100644
--- a/drivers/misc/sgi-xp/xp_main.c
+++ b/drivers/misc/sgi-xp/xp_main.c
@@ -3,6 +3,7 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
+ * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
  * Copyright (c) 2004-2008 

[PATCH v3 02/13] x86/platform/uv: Remove SCIR MMR references for UVY systems.

[Mike Travis]

UV class systems no longer use System Controller for monitoring of CPU
activity provided by this driver.  Other methods have been developed
for BIOS and the management controller (BMC).  This patch removes that
supporting code.

Signed-off-by: Mike Travis 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/include/asm/uv/uv_hub.h   | 43 ++--
 arch/x86/kernel/apic/x2apic_uv_x.c | 82 --
 2 files changed, 3 insertions(+), 122 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 100d66806503..b21228db75bf 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -129,17 +129,6 @@
  */
 #define UV_MAX_NASID_VALUE (UV_MAX_NUMALINK_BLADES * 2)
 
-/* System Controller Interface Reg info */
-struct uv_scir_s {
-   struct timer_list timer;
-   unsigned long   offset;
-   unsigned long   last;
-   unsigned long   idle_on;
-   unsigned long   idle_off;
-   unsigned char   state;
-   unsigned char   enabled;
-};
-
 /* GAM (globally addressed memory) range table */
 struct uv_gam_range_s {
u32 limit;  /* PA bits 56:26 (GAM_RANGE_SHFT) */
@@ -191,16 +180,13 @@ struct uv_hub_info_s {
 struct uv_cpu_info_s {
void*p_uv_hub_info;
unsigned char   blade_cpu_id;
-   struct uv_scir_sscir;
+   void*reserved;
 };
 DECLARE_PER_CPU(struct uv_cpu_info_s, __uv_cpu_info);
 
 #define uv_cpu_infothis_cpu_ptr(&__uv_cpu_info)
 #define uv_cpu_info_per(cpu)   (_cpu(__uv_cpu_info, cpu))
 
-#defineuv_scir_info(_cpu_info->scir)
-#defineuv_cpu_scir_info(cpu)   (_cpu_info_per(cpu)->scir)
-
 /* Node specific hub common info struct */
 extern void **__uv_hub_info_list;
 static inline struct uv_hub_info_s *uv_hub_info_list(int node)
@@ -297,9 +283,9 @@ union uvh_apicid {
 #define UV3_GLOBAL_MMR32_SIZE  (32UL * 1024 * 1024)
 
 #define UV4_LOCAL_MMR_BASE 0xfa00UL
-#define UV4_GLOBAL_MMR32_BASE  0xfc00UL
+#define UV4_GLOBAL_MMR32_BASE  0
 #define UV4_LOCAL_MMR_SIZE (32UL * 1024 * 1024)
-#define UV4_GLOBAL_MMR32_SIZE  (16UL * 1024 * 1024)
+#define UV4_GLOBAL_MMR32_SIZE  0
 
 #define UV_LOCAL_MMR_BASE  (   \
is_uv2_hub() ? UV2_LOCAL_MMR_BASE : \
@@ -772,29 +758,6 @@ DECLARE_PER_CPU(struct uv_cpu_nmi_s, uv_cpu_nmi);
 #defineUV_NMI_STATE_DUMP   2
 #defineUV_NMI_STATE_DUMP_DONE  3
 
-/* Update SCIR state */
-static inline void uv_set_scir_bits(unsigned char value)
-{
-   if (uv_scir_info->state != value) {
-   uv_scir_info->state = value;
-   uv_write_local_mmr8(uv_scir_info->offset, value);
-   }
-}
-
-static inline unsigned long uv_scir_offset(int apicid)
-{
-   return SCIR_LOCAL_MMR_BASE | (apicid & 0x3f);
-}
-
-static inline void uv_set_cpu_scir_bits(int cpu, unsigned char value)
-{
-   if (uv_cpu_scir_info(cpu)->state != value) {
-   uv_write_global_mmr8(uv_cpu_to_pnode(cpu),
-   uv_cpu_scir_info(cpu)->offset, value);
-   uv_cpu_scir_info(cpu)->state = value;
-   }
-}
-
 /*
  * Get the minimum revision number of the hub chips within the partition.
  * (See UVx_HUB_REVISION_BASE above for specific values.)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 0b6eea3f54e6..f51fabf56010 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -909,85 +909,6 @@ static __init void uv_rtc_init(void)
}
 }
 
-/*
- * percpu heartbeat timer
- */
-static void uv_heartbeat(struct timer_list *timer)
-{
-   unsigned char bits = uv_scir_info->state;
-
-   /* Flip heartbeat bit: */
-   bits ^= SCIR_CPU_HEARTBEAT;
-
-   /* Is this CPU idle? */
-   if (idle_cpu(raw_smp_processor_id()))
-   bits &= ~SCIR_CPU_ACTIVITY;
-   else
-   bits |= SCIR_CPU_ACTIVITY;
-
-   /* Update system controller interface reg: */
-   uv_set_scir_bits(bits);
-
-   /* Enable next timer period: */
-   mod_timer(timer, jiffies + SCIR_CPU_HB_INTERVAL);
-}
-
-static int uv_heartbeat_enable(unsigned int cpu)
-{
-   while (!uv_cpu_scir_info(cpu)->enabled) {
-   struct timer_list *timer = _cpu_scir_info(cpu)->timer;
-
-   uv_set_cpu_scir_bits(cpu, SCIR_CPU_HEARTBEAT|SCIR_CPU_ACTIVITY);
-   timer_setup(timer, uv_heartbeat, TIMER_PINNED);
-   timer->expires = jiffies + SCIR_CPU_HB_INTERVAL;
-   add_timer_on(timer, cpu);
-   uv_cpu_scir_info(cpu)->enabled = 1;
-
-   /* Also ensure that boot CPU is enabled: */
-   cpu = 0;
-   }
-   return 0;
-}
-
-#ifdef CONFIG_HOTPLUG_CPU
-static int