[PATCH] Documentation: kunit: Add naming guidelines

[David Gow]

As discussed in [1], KUnit tests have hitherto not had a particularly
consistent naming scheme. This adds documentation outlining how tests
and test suites should be named, including how those names should be
used in Kconfig entries and filenames.

[1]:
https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u

Signed-off-by: David Gow 
---
This is a first draft of some naming guidelines for KUnit tests. Note
that I haven't edited it for spelling/grammar/style yet: I wanted to get
some feedback on the actual naming conventions first.

The issues which came most to the forefront while writing it were:
- Do we want to make subsystems a more explicit thing (make the KUnit
  framework recognise them, make suites KTAP subtests of them, etc)
  - I'm leaning towards no, mainly because it doesn't seem necessary,
and it makes the subsystem-with-only-one-suite case ugly.

- Do we want to support (or encourage) Kconfig options and/or modules at
  the subsystem level rather than the suite level?
  - This could be nice: it'd avoid the proliferation of a large number
of tiny config options and modules, and would encourage the test for
 to be _kunit, without other stuff in-between.

- As test names are also function names, it may actually make sense to
  decorate them with "test" or "kunit" or the like.
  - If we're testing a function "foo", "test_foo" seems like as good a
name for the function as any. Sure, many cases may could have better
names like "foo_invalid_context" or something, but that won't make
sense for everything.
  - Alternatively, do we split up the test name and the name of the
function implementing the test?

Thoughts?

 Documentation/dev-tools/kunit/index.rst |   1 +
 Documentation/dev-tools/kunit/style.rst | 139 
 2 files changed, 140 insertions(+)
 create mode 100644 Documentation/dev-tools/kunit/style.rst

diff --git a/Documentation/dev-tools/kunit/index.rst 
b/Documentation/dev-tools/kunit/index.rst
index e93606ecfb01..117c88856fb3 100644
--- a/Documentation/dev-tools/kunit/index.rst
+++ b/Documentation/dev-tools/kunit/index.rst
@@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel
usage
kunit-tool
api/index
+style
faq
 
 What is KUnit?
diff --git a/Documentation/dev-tools/kunit/style.rst 
b/Documentation/dev-tools/kunit/style.rst
new file mode 100644
index ..9363b5607262
--- /dev/null
+++ b/Documentation/dev-tools/kunit/style.rst
@@ -0,0 +1,139 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Test Style and Nomenclature
+===
+
+Subsystems, Suites, and Tests
+=
+
+In order to make tests as easy to find as possible, they're grouped into suites
+and subsystems. A test suite is a group of tests which test a related area of
+the kernel, and a subsystem is a set of test suites which test different parts
+of the same kernel subsystem or driver.
+
+Subsystems
+--
+
+Every test suite must belong to a subsystem. A subsystem is a collection of one
+or more KUnit test suites which test the same driver or part of the kernel. A
+rule of thumb is that a test subsystem should match a single kernel module. If
+the code being tested can't be compiled as a module, in many cases the 
subsystem
+should correspond to a directory in the source tree or an entry in the
+MAINTAINERS file. If unsure, follow the conventions set by tests in similar
+areas.
+
+Test subsystems should be named after the code being tested, either after the
+module (wherever possible), or after the directory or files being tested. Test
+subsystems should be named to avoid ambiguity where necessary.
+
+If a test subsystem name has multiple components, they should be separated by
+underscores. Do not include "test" or "kunit" directly in the subsystem name
+unless you are actually testing other tests or the kunit framework itself.
+
+Example subsystems could be:
+
+* ``ext4``
+* ``apparmor``
+* ``kasan``
+
+.. note::
+The KUnit API and tools do not explicitly know about subsystems. 
They're
+simply a way of categorising test suites and naming modules which
+provides a simple, consistent way for humans to find and run tests. 
This
+may change in the future, though.
+
+Suites
+--
+
+KUnit tests are grouped into test suites, which cover a specific area of
+functionality being tested. Test suites can have shared initialisation and
+shutdown code which is run for all tests in the suite.
+Not all subsystems will need to be split into multiple test suites (e.g. 
simple drivers).
+
+Test suites are named after the subsystem they are part of. If a subsystem
+contains several suites, the specific area under test should be appended to the
+subsystem name, separated by an underscore.
+
+The full test suite name (including the subsystem name) should be specified as
+the ``.name`` member of the ``kunit_suite`` struct, 

[tip:x86/cleanups] BUILD SUCCESS eacb0c101a0bdf14de77cc9d107493e2d8d6389c

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/cleanups
branch HEAD: eacb0c101a0bdf14de77cc9d107493e2d8d6389c  initrd: Remove erroneous 
comment

elapsed time: 722m

configs tested: 140
configs skipped: 13

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

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm s3c6400_defconfig
m68k   bvme6000_defconfig
arm mv78xx0_defconfig
i386 alldefconfig
powerpc64   defconfig
arm  colibri_pxa270_defconfig
arcvdk_hs38_defconfig
armspear6xx_defconfig
csky allyesconfig
mips tb0226_defconfig
sh  r7780mp_defconfig
s390 allyesconfig
cskydefconfig
powerpc mpc5200_defconfig
mips rt305x_defconfig
riscvnommu_virt_defconfig
arm s5pv210_defconfig
armmini2440_defconfig
sh  defconfig
arm   mainstone_defconfig
m68k   m5475evb_defconfig
powerpc  g5_defconfig
mips  pistachio_defconfig
armtrizeps4_defconfig
arm davinci_all_defconfig
nios2 3c120_defconfig
mips   ip27_defconfig
powerpc  ep88xc_defconfig
s390 allmodconfig
microblazeallnoconfig
m68kmvme16x_defconfig
mipsqi_lb60_defconfig
x86_64  defconfig
arc  alldefconfig
arcnsimosci_defconfig
s390  allnoconfig
mips cu1000-neo_defconfig
sh   secureedge5410_defconfig
arm   u8500_defconfig
shedosk7705_defconfig
armspear3xx_defconfig
h8300allmodconfig
sh   j2_defconfig
arm   h5000_defconfig
powerpc  chrp32_defconfig
armclps711x_defconfig
powerpc  storcenter_defconfig
xtensa   alldefconfig
powerpc  pmac32_defconfig
i386  allnoconfig
i386defconfig
i386  debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a002-20200619
i386 randconfig-a006-20200619
i386

Re: [PATCH 3/3] rcu/trace: Add name of the source for gp_seq to prevent confusion

[Joel Fernandes]

On Fri, Jun 19, 2020 at 10:40:01AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 18, 2020 at 10:07:18PM -0400, Joel Fernandes wrote:
> > On Thu, Jun 18, 2020 at 09:36:41PM -0400, Joel Fernandes (Google) wrote:
> > [...]
> > > @@ -2019,7 +2019,7 @@ static int __noreturn rcu_gp_kthread(void *unused)
> > >   cond_resched_tasks_rcu_qs();
> > >   WRITE_ONCE(rcu_state.gp_activity, jiffies);
> > >   WARN_ON(signal_pending(current));
> > > - trace_rcu_grace_period(rcu_state.name, rcu_state.gp_seq,
> > > + trace_rcu_grace_period(rcu_state.name, TPS("rsp"), 
> > > rcu_state.gp_seq,
> > >  TPS("reqwaitsig"));
> > >   }
> > >  
> > > @@ -2263,7 +2263,7 @@ int rcutree_dying_cpu(unsigned int cpu)
> > >   return 0;
> > >  
> > >   blkd = !!(rnp->qsmask & rdp->grpmask);
> > > - trace_rcu_grace_period(rcu_state.name, READ_ONCE(rnp->gp_seq),
> > > + trace_rcu_grace_period(rcu_state.name, TPS("rsp"), 
> > > READ_ONCE(rnp->gp_seq),
> > 
> > This should be: TPS("rnp")  :-(
> > 
> > Happy to fix it up and resend if you'd like. Thanks!
> 
> I queued and pushed 1/2 and 2/2.

Thanks!

> but again, I am still not at all
> convinced by 3/3.  If you want to make RCU trace output human
> readable, post-processing will be needed.

Or I could post-process the code before building it since the pattern seems
easy to parse ;-)

 - Joel

[tip:master] BUILD SUCCESS 46fd0c81965064aa7a4889f704591253c1724e52

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  master
branch HEAD: 46fd0c81965064aa7a4889f704591253c1724e52  Merge branch 'efi/urgent'

elapsed time: 722m

configs tested: 86
configs skipped: 1

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

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a011-20200619
i386 randconfig-a015-20200619
i386 randconfig-a014-20200619
i386 randconfig-a013-20200619
i386 randconfig-a016-20200619
i386 randconfig-a012-20200619
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
um   allmodconfig
x86_64   rhel
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec

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

Re: [PATCH v5] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN

[Guenter Roeck]

On 6/19/20 9:35 PM, Manikandan Elumalai wrote:
> The adm1278 temp attribute need it for openbmc platform .
> This feature not enabled by default, so PMON_CONFIG needs to enable it.
> 
> Signed-off-by: Manikandan Elumalai 
> ---
> ---v5 -align commit and change log. 
> ---v4 -Reported-by: kernel test robot 
> ---v3 -fix invalid signed-off.
> ---   -removed checkpath warnings.
> ---   -write ADM1278_TEMP1_EN and ADM1278_VOUT_EN conf in single line 
> operation.
> ---v2 -add Signed-off-by.
> ---   -removed ADM1278_TEMP1_EN check.
> ---
> ---

Not that it matters much here, but why all the "---" instead of just one,
especially after you were advised that this is not the expected format ?

Guenter

>  drivers/hwmon/pmbus/adm1275.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index 5caa37fb..d4e1925 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
> @@ -666,11 +666,12 @@ static int adm1275_probe(struct i2c_client *client,
>   tindex = 3;
>  
>   info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
> - PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>  
> - /* Enable VOUT if not enabled (it is disabled by default) */
> - if (!(config & ADM1278_VOUT_EN)) {
> - config |= ADM1278_VOUT_EN;
> + /* Enable VOUT & TEMP1 if not enabled (disabled by default) */
> + if ((config & (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)) != 
> (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)) {
> + config |= ADM1278_VOUT_EN | ADM1278_TEMP1_EN;
>   ret = i2c_smbus_write_byte_data(client,
>   ADM1275_PMON_CONFIG,
>   config);
> @@ -681,9 +682,6 @@ static int adm1275_probe(struct i2c_client *client,
>   }
>   }
>  
> - if (config & ADM1278_TEMP1_EN)
> - info->func[0] |=
> - PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>   if (config & ADM1278_VIN_EN)
>   info->func[0] |= PMBUS_HAVE_VIN;
>   break;
> 

Re: [PATCH 4/4] X86: Use KVM CR pin MSRs

[Andy Lutomirski]

On Wed, Jun 17, 2020 at 12:05 PM John Andersen
 wrote:
> Guests using the kexec system call currently do not support
> paravirtualized control register pinning. This is due to early boot
> code writing known good values to control registers, these values do
> not contain the protected bits. This is due to CPU feature
> identification being done at a later time, when the kernel properly
> checks if it can enable protections. As such, the pv_cr_pin command line
> option has been added which instructs the kernel to disable kexec in
> favor of enabling paravirtualized control register pinning. crashkernel
> is also disabled when the pv_cr_pin parameter is specified due to its
> reliance on kexec.

Is there a plan for fixing this for real?  I'm wondering if there is a
sane weakening of this feature that still allows things like kexec.

What happens if a guest tries to reset?  For that matter, what happens
when a guest vCPU sends SIPI to another guest vCPU?  The target CPU
starts up in real mode, right?  There's no SMEP or SMAP in real mode,
and real mode has basically no security mitigations at all.

PCID is an odd case.  I see no good reason to pin it, and pinning PCID
on prevents use of 32-bit mode.

Re: Linux-aspeed Digest, Vol 37, Issue 25

[Manikandan]

On Sat, Jun 20, 2020 at 04:41:13AM +1000, linux-aspeed-requ...@lists.ozlabs.org 
wrote:
> Send Linux-aspeed mailing list submissions to
>   linux-asp...@lists.ozlabs.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.ozlabs.org/listinfo/linux-aspeed
> or, via email, send a message with subject or body 'help' to
>   linux-aspeed-requ...@lists.ozlabs.org
> 
> You can reach the person managing the list at
>   linux-aspeed-ow...@lists.ozlabs.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-aspeed digest..."
> 
> 
> Today's Topics:
> 
>1. [PATCH v4] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
>   (Manikandan Elumalai)
>2. Re: [PATCH v4] hwmon:(adm1275) Enable adm1278
>   ADM1278_TEMP1_EN (Guenter Roeck)
>3. [PATCH v4] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
>   (Manikandan Elumalai)
>4. Re:  [PATCH v4] hwmon:(adm1275) Enable adm1278
>   ADM1278_TEMP1_EN (Milton Miller II)
>5. Re: [PATCH v4] hwmon:(adm1275) Enable adm1278
>   ADM1278_TEMP1_EN (Guenter Roeck)
> 
> 
> --
> 
> Message: 1
> Date: Fri, 19 Jun 2020 20:18:53 +0530
> From: Manikandan Elumalai 
> To: Guenter Roeck , Jean Delvare
>   , linux-hw...@vger.kernel.org,
>   linux-kernel@vger.kernel.org
> Cc: saipsdas...@fb.com, patric...@fb.com, vijaykhe...@fb.com,
>   linux-asp...@lists.ozlabs.org, open...@lists.ozlabs.org,
>   manikanda...@hcl.com
> Subject: [PATCH v4] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN
> Message-ID: <20200619144853.GA18271@cnn>
> Content-Type: text/plain; charset=us-ascii
> 
> The adm1278 temp attribute need it for openbmc platform .
> This feature not enabled by default, so PMON_CONFIG needs to enable it.
> 
> v4:
> ---
> Reported-by: kernel test robot 
> v3:
> 
> fix invalid signed-off.
> removed checkpath warnings.
> write ADM1278_TEMP1_EN and ADM1278_VOUT_EN conf in single line operation.
> v2:
> 
> add Signed-off-by.
> removed ADM1278_TEMP1_EN check.
> 
> Signed-off-by: Manikandan Elumalai 
> ---
>  drivers/hwmon/pmbus/adm1275.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
> index 5caa37fb..d4e1925 100644
> --- a/drivers/hwmon/pmbus/adm1275.c
> +++ b/drivers/hwmon/pmbus/adm1275.c
> @@ -666,11 +666,12 @@ static int adm1275_probe(struct i2c_client *client,
>   tindex = 3;
>  
>   info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
> - PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>  
> - /* Enable VOUT if not enabled (it is disabled by default) */
> - if (!(config & ADM1278_VOUT_EN)) {
> - config |= ADM1278_VOUT_EN;
> + /* Enable VOUT & TEMP1 if not enabled (disabled by default) */
> + if ((config & (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)) != 
> (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)) {
> + config |= ADM1278_VOUT_EN | ADM1278_TEMP1_EN;
>   ret = i2c_smbus_write_byte_data(client,
>   ADM1275_PMON_CONFIG,
>   config);
> @@ -681,9 +682,6 @@ static int adm1275_probe(struct i2c_client *client,
>   }
>   }
>  
> - if (config & ADM1278_TEMP1_EN)
> - info->func[0] |=
> - PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>   if (config & ADM1278_VIN_EN)
>   info->func[0] |= PMBUS_HAVE_VIN;
>   break;
> -- 
> 2.7.4
> 
> 
> 
> --
> 
> Message: 2
> Date: Fri, 19 Jun 2020 08:38:32 -0700
> From: Guenter Roeck 
> To: Manikandan Elumalai 
> Cc: Jean Delvare , linux-hw...@vger.kernel.org,
>   linux-kernel@vger.kernel.org, saipsdas...@fb.com, patric...@fb.com,
>   vijaykhe...@fb.com, linux-asp...@lists.ozlabs.org,
>   open...@lists.ozlabs.org, manikanda...@hcl.com
> Subject: Re: [PATCH v4] hwmon:(adm1275) Enable adm1278
>   ADM1278_TEMP1_EN
> Message-ID: <20200619153832.ga57...@roeck-us.net>
> Content-Type: text/plain; charset=us-ascii
> 
> On Fri, Jun 19, 2020 at 08:18:53PM +0530, Manikandan Elumalai wrote:
> > The adm1278 temp attribute need it for openbmc platform .
> > This feature not enabled by default, so PMON_CONFIG needs to enable it.
> > 
> > v4:
> > ---
> > Reported-by: kernel test robot 
> > v3:
> > 
> > fix invalid signed-off.
> > removed checkpath warnings.
> > write ADM1278_TEMP1_EN and ADM1278_VOUT_EN conf in single line operation.
> > v2:
> > 
> > add Signed-off-by.
> > removed ADM1278_TEMP1_EN check.
> > 
> > 

[tip:x86/urgent] BUILD SUCCESS bb5570ad3b54e7930997aec76ab68256d5236d94

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/urgent
branch HEAD: bb5570ad3b54e7930997aec76ab68256d5236d94  x86/asm/64: Align start 
of __clear_user() loop to 16-bytes

elapsed time: 723m

configs tested: 114
configs skipped: 98

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

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arcvdk_hs38_defconfig
armspear6xx_defconfig
csky allyesconfig
mips tb0226_defconfig
sh  r7780mp_defconfig
s390 allyesconfig
sh  defconfig
arm   mainstone_defconfig
m68k   m5475evb_defconfig
powerpc  g5_defconfig
mips  pistachio_defconfig
armtrizeps4_defconfig
arm davinci_all_defconfig
nios2 3c120_defconfig
mips   ip27_defconfig
powerpc  ep88xc_defconfig
m68kmvme16x_defconfig
mipsqi_lb60_defconfig
arm s5pv210_defconfig
x86_64  defconfig
arc  alldefconfig
s390  allnoconfig
arcnsimosci_defconfig
h8300allmodconfig
sh   j2_defconfig
arm   h5000_defconfig
i386  allnoconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
nds32   defconfig
nds32 allnoconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a002-20200619
i386 randconfig-a006-20200619
i386 randconfig-a001-20200619
i386 randconfig-a004-20200619
i386 randconfig-a005-20200619
i386 randconfig-a003-20200619
i386 randconfig-a011-20200619
i386 randconfig-a015-20200619
i386 randconfig-a014-20200619
i386 randconfig-a013-20200619
i386 randconfig-a016-20200619
i386 randconfig-a012-20200619
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64

[PATCH v5] hwmon:(adm1275) Enable adm1278 ADM1278_TEMP1_EN

[Manikandan Elumalai]

The adm1278 temp attribute need it for openbmc platform .
This feature not enabled by default, so PMON_CONFIG needs to enable it.

Signed-off-by: Manikandan Elumalai 
---
---v5 -align commit and change log. 
---v4 -Reported-by: kernel test robot 
---v3 -fix invalid signed-off.
---   -removed checkpath warnings.
---   -write ADM1278_TEMP1_EN and ADM1278_VOUT_EN conf in single line 
operation.
---v2 -add Signed-off-by.
---   -removed ADM1278_TEMP1_EN check.
---
---
 drivers/hwmon/pmbus/adm1275.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c
index 5caa37fb..d4e1925 100644
--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -666,11 +666,12 @@ static int adm1275_probe(struct i2c_client *client,
tindex = 3;
 
info->func[0] |= PMBUS_HAVE_PIN | PMBUS_HAVE_STATUS_INPUT |
-   PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT;
+   PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
+   PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
 
-   /* Enable VOUT if not enabled (it is disabled by default) */
-   if (!(config & ADM1278_VOUT_EN)) {
-   config |= ADM1278_VOUT_EN;
+   /* Enable VOUT & TEMP1 if not enabled (disabled by default) */
+   if ((config & (ADM1278_VOUT_EN | ADM1278_TEMP1_EN)) != 
(ADM1278_VOUT_EN | ADM1278_TEMP1_EN)) {
+   config |= ADM1278_VOUT_EN | ADM1278_TEMP1_EN;
ret = i2c_smbus_write_byte_data(client,
ADM1275_PMON_CONFIG,
config);
@@ -681,9 +682,6 @@ static int adm1275_probe(struct i2c_client *client,
}
}
 
-   if (config & ADM1278_TEMP1_EN)
-   info->func[0] |=
-   PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
if (config & ADM1278_VIN_EN)
info->func[0] |= PMBUS_HAVE_VIN;
break;
-- 
2.7.4

Re: [PATCH] sparse: use the _Generic() version of __unqual_scalar_typeof()

[kernel test robot]

Hi Luc,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.8-rc1 next-20200618]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Luc-Van-Oostenryck/sparse-use-the-_Generic-version-of-__unqual_scalar_typeof/20200619-062703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
1b5044021070efa3259f3e9548dc35d1eb6aa844
config: i386-randconfig-m021-20200620 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0

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

New smatch warnings:
kernel/sched/debug.c:965 proc_sched_show_task() warn: inconsistent indenting

Old smatch warnings:
include/linux/sched/clock.h:84 local_clock() warn: ignoring unreachable code.

vim +965 kernel/sched/debug.c

43ae34cb4cd650d kernel/sched_debug.c Ingo Molnar2007-07-09  963  
43ae34cb4cd650d kernel/sched_debug.c Ingo Molnar2007-07-09  964 
{
29d7b90c1503574 kernel/sched_debug.c Ingo Molnar2008-11-16 @965 
unsigned int this_cpu = raw_smp_processor_id();
43ae34cb4cd650d kernel/sched_debug.c Ingo Molnar2007-07-09  966 
u64 t0, t1;
43ae34cb4cd650d kernel/sched_debug.c Ingo Molnar2007-07-09  967  
29d7b90c1503574 kernel/sched_debug.c Ingo Molnar2008-11-16  968 
t0 = cpu_clock(this_cpu);
29d7b90c1503574 kernel/sched_debug.c Ingo Molnar2008-11-16  969 
t1 = cpu_clock(this_cpu);
9e3bf9469c29f7e kernel/sched/debug.c Valentin Schneider 2020-02-26  970 
__PS("clock-delta", t1-t0);
43ae34cb4cd650d kernel/sched_debug.c Ingo Molnar2007-07-09  971 
}
b32e86b4301e345 kernel/sched/debug.c Ingo Molnar2013-10-07  972  
b32e86b4301e345 kernel/sched/debug.c Ingo Molnar2013-10-07  973 
sched_show_numa(p, m);
43ae34cb4cd650d kernel/sched_debug.c Ingo Molnar2007-07-09  974  }
43ae34cb4cd650d kernel/sched_debug.c Ingo Molnar2007-07-09  975  

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


.config.gz
Description: application/gzip

ERROR: modpost: "riscv_time_val" undefined!

[kernel test robot]

Hi Christoph,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4333a9b0b67bb4e8bcd91bdd80da80b0ec151162
commit: c3f896dcf1e47959aca4f8e6ac9537b478949126 mm: switch the test_vmalloc 
module to use __vmalloc_node
date:   2 weeks ago
config: riscv-randconfig-c003-20200620 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0

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

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "riscv_time_val" [drivers/video/fbdev/udlfb.ko] undefined!

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


.config.gz
Description: application/gzip

[RFC PATCH] display/drm/bridge: tc358775_parse_dt() can be static

[kernel test robot]

Signed-off-by: kernel test robot 
---
 tc358775.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358775.c 
b/drivers/gpu/drm/bridge/tc358775.c
index 87af3271b63521..88a45e86eae334 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -502,7 +502,7 @@ static int tc_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
 }
 
-int tc358775_parse_dt(struct device_node *np, struct tc_data *tc)
+static int tc358775_parse_dt(struct device_node *np, struct tc_data *tc)
 {
struct device_node *endpoint;
struct device_node *parent;

Re: [PATCH 4.9 000/128] 4.9.228-rc1 review

[Daniel Díaz]

Hello!

On 6/19/20 9:31 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.9.228 release.
There are 128 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.228-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.9.228-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: d0cfa25033bfd364a10be2446d64517b9deb0691
git describe: v4.9.227-129-gd0cfa25033bf
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.227-129-gd0cfa25033bf

No regressions (compared to build v4.9.227)

No fixes (compared to build v4.9.227)

Ran 30512 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance

Greetings!

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

--
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.14 000/190] 4.14.185-rc1 review

[Daniel Díaz]

Hello!

On 6/19/20 9:30 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.14.185 release.
There are 190 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.185-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.14.185-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: e26bcff6a5af4b6e19e350a39e88637307e07eb8
git describe: v4.14.184-191-ge26bcff6a5af
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.184-191-ge26bcff6a5af

No regressions (compared to build v4.14.184)

No fixes (compared to build v4.14.184)

Ran 34182 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance

Greetings!

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

--
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.19 000/267] 4.19.129-rc1 review

[Daniel Díaz]

Hello!

On 6/19/20 9:29 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.19.129 release.
There are 267 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.129-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.129-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: a00c59b6375644f707a3554536d03d4ecaf17c05
git describe: v4.19.128-268-ga00c59b63756
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.128-268-ga00c59b63756

No regressions (compared to build v4.19.128)

No fixes (compared to build v4.19.128)

Ran 34131 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance

Greetings!

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

--
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 5.7 000/376] 5.7.5-rc1 review

[Daniel Díaz]

Hello!

On 6/19/20 9:28 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.7.5 release.
There are 376 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.5-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.7.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.7.5-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.7.y
git commit: 19411dc6b06179bc55c542f1be520764cdcd3aac
git describe: v5.7.2-542-g19411dc6b061
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.7-oe/build/v5.7.2-542-g19411dc6b061

No regressions (compared to build v5.7.3)

No fixes (compared to build v5.7.3)

Ran 37628 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* network-basic-tests
* perf
* v4l2-compliance

Greetings!

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


--
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH v5 2/2] phy: bcm63xx-usbh: Add BCM63xx USBH driver

[Florian Fainelli]

On 6/19/2020 3:00 AM, Álvaro Fernández Rojas wrote:
> Add BCM63xx USBH PHY driver for BMIPS.
> 
> Signed-off-by: Álvaro Fernández Rojas 

Reviewed-by: Florian Fainelli 

This looks great, thanks Alvaro!
-- 
Florian

Re: [PATCH] scsi: ufs-mediatek: Make ufs_mtk_wait_link_state as static function

[Martin K. Petersen]

On Tue, 16 Jun 2020 17:51:20 +0800, Stanley Chu wrote:

> Fix build warning reported by kernel test robot:
> Make ufs_mtk_wait_link_state() as static functon.
> 
> Warning:
> >> drivers/scsi/ufs/ufs-mediatek.c:181:5: warning: no previous prototype
> >> for 'ufs_mtk_wait_link_state' [-Wmissing-prototypes]

Applied to 5.9/scsi-queue, thanks!

[1/1] scsi: ufs-mediatek: Make ufs_mtk_wait_link_state static
  https://git.kernel.org/mkp/scsi/c/9a3cd470f8e3

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH 2/2] tracing: Fix event trigger to accept redundant spaces

[Masami Hiramatsu]

Fix the event trigger to accept redundant spaces in
the trigger input.

For example, these return -EINVAL

echo " traceon" > events/ftrace/print/trigger
echo "traceon  if common_pid == 0" > events/ftrace/print/trigger
echo "disable_event:kmem:kmalloc " > events/ftrace/print/trigger

But these are hard to find what is wrong.

To fix this issue, use skip_spaces() to remove spaces
in front of actual tokens, and set NULL if there is no
token.

Fixes: 85f2b08268c0 ("tracing: Add basic event trigger framework")
Cc: sta...@vger.kernel.org
Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/trace_events_trigger.c |   21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_events_trigger.c 
b/kernel/trace/trace_events_trigger.c
index 3a74736da363..f725802160c0 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -216,11 +216,17 @@ static int event_trigger_regex_open(struct inode *inode, 
struct file *file)
 
 int trigger_process_regex(struct trace_event_file *file, char *buff)
 {
-   char *command, *next = buff;
+   char *command, *next;
struct event_command *p;
int ret = -EINVAL;
 
+   next = buff = skip_spaces(buff);
command = strsep(, ": \t");
+   if (next) {
+   next = skip_spaces(next);
+   if (!*next)
+   next = NULL;
+   }
command = (command[0] != '!') ? command : command + 1;
 
mutex_lock(_cmd_mutex);
@@ -630,8 +636,14 @@ event_trigger_callback(struct event_command *cmd_ops,
int ret;
 
/* separate the trigger from the filter (t:n [if filter]) */
-   if (param && isdigit(param[0]))
+   if (param && isdigit(param[0])) {
trigger = strsep(, " \t");
+   if (param) {
+   param = skip_spaces(param);
+   if (!*param)
+   param = NULL;
+   }
+   }
 
trigger_ops = cmd_ops->get_trigger_ops(cmd, trigger);
 
@@ -1368,6 +1380,11 @@ int event_enable_trigger_func(struct event_command 
*cmd_ops,
trigger = strsep(, " \t");
if (!trigger)
return -EINVAL;
+   if (param) {
+   param = skip_spaces(param);
+   if (!*param)
+   param = NULL;
+   }
 
system = strsep(, ":");
if (!trigger)

Re: [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump

[chenzhou]

Hi James, Rob,


On 2020/5/30 0:11, James Morse wrote:
> Hi guys,
>
> On 26/05/2020 22:18, Rob Herring wrote:
>> On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
>>> On 2020/5/21 21:29, Rob Herring wrote:
 On Thu, May 21, 2020 at 3:35 AM Chen Zhou  wrote:
> Add documentation for DT property used by arm64 kdump:
> linux,low-memory-range.
> "linux,low-memory-range" is an another memory region used for crash
> dump kernel devices.
> diff --git a/Documentation/devicetree/bindings/chosen.txt 
> b/Documentation/devicetree/bindings/chosen.txt
> index 45e79172a646..bfe6fb6976e6 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> +linux,low-memory-range
> +--
> +This property (arm64 only) holds a base address and size, describing a
> +limited region below 4G. Similar to "linux,usable-memory-range", it is
> +an another memory range which may be considered available for use by the
> +kernel.
 Why can't you just add a range to "linux,usable-memory-range"? It
 shouldn't be hard to figure out which part is below 4G.
>>> The comments from James:
>>> Won't this break if your kdump kernel doesn't know what the extra 
>>> parameters are?
>>> Or if it expects two ranges, but only gets one? These DT properties should 
>>> be treated as
>>> ABI between kernel versions, we can't really change it like this.
>>>
>>> I think the 'low' region is an optional-extra, that is never mapped by the 
>>> first kernel. I
>>> think the simplest thing to do is to add an 'linux,low-memory-range' that we
>>> memblock_add() after memblock_cap_memory_range() has been called.
>>> If its missing, or the new kernel doesn't know what its for, everything 
>>> keeps working.
>>
>> I don't think there's a compatibility issue here though. The current 
>> kernel doesn't care if the property is longer than 1 base+size. It only 
>> checks if the size is less than 1 base+size.
> Aha! I missed that.
>
>
>> And yes, we can rely on 
>> that implementation detail. It's only an ABI if an existing user 
>> notices.
>>
>> Now, if the low memory is listed first, then an older kdump kernel 
>> would get a different memory range. If that's a problem, then define 
>> that low memory goes last. 
> This first entry would need to be the 'crashkernel' range where the kdump 
> kernel is
> placed, otherwise an older kernel won't boot. The rest can be optional 
> extras, as long as
> we are tolerant of it being missing...
How about like this:

1. The low memory region remained as "Crash kernel (low)".
2. Userspace will find "Crash kernel" and "Crash kernel (low)" region in 
/proc/iomem,
and add "Crash kernel (low)" as the last range of property 
"linux,usable-memory-range".

Thanks,
Chen Zhou
>
> I'll try and look at the rest of this series on Monday,
>
>
> Thanks,
>
> James
>
> .
>

[PATCH 0/2] tracing: Fix config dependency and trigger parser

[Masami Hiramatsu]

Hi,

These are some fixes which I found recentry on ftrace.

 - Since the boot-time tracing synthetic event feature is decoupled
   from trigger recenty, it should use CONFIG_SYNTH_EVENT.
 - The parser of event trigger seems rejecting some redundant
   spaces. But it is hard users to find the wrong point. Such
   spaces should be accepted.

BTW, I also found the trigger parser accepts some inputs which
may not correctly formatted, e.g.

 # echo "traceon 1" > events/ftrace/print/trigger

(from the document, it must be "traceon:1")
But I think this does not decrease the usability.

Thank you,

---

Masami Hiramatsu (2):
  tracing/boot: Fix config dependency for synthedic event
  tracing: Fix event trigger to accept redundant spaces


 kernel/trace/trace_boot.c   |2 +-
 kernel/trace/trace_events_trigger.c |   21 +++--
 2 files changed, 20 insertions(+), 3 deletions(-)

--
Masami Hiramatsu (Linaro) 

Re: [PATCH] MIPS: Do not flush tlb when setting pmd entry

[maobibo]

On 06/17/2020 07:14 PM, Thomas Bogendoerfer wrote:
> On Tue, Jun 16, 2020 at 06:34:21PM +0800, maobibo wrote:
>>
>>
>> On 06/15/2020 06:14 PM, Thomas Bogendoerfer wrote:
>>> On Wed, Jun 03, 2020 at 05:42:13PM +0800, Bibo Mao wrote:
 Function set_pmd_at is to set pmd entry, if tlb entry need to
 be flushed, there exists pmdp_huge_clear_flush alike function
 before set_pmd_at is called. So it is not necessary to call
 flush_tlb_all in this function.
>>>
>>> have you checked all set_pmd_at() calls ? I found a few case where
>>> it's not clear to me, if tlb flushing is done... If you think this
>>> is still the right thing to do, please change arch/mips/mm/pgtable-32.c
>>> as well.
>> well, I will double check this and do more testing about thp and hugepage.
> 
> I was more concerned about
> 
> fs/dax.c
> fs/proc/task_mmu.c
> mm/rmap.c

I think that flush_tlb_all should not be called in function set_pmd_at
on mips platform. However update_mmu_cache_pmd() should be called __after__
set_pmd_at() function to update tlb entry at some places, it is another issue.
Here is my analysis in the three files where set_pmd_at is called.

in file fs/dax.c
--
if (pmdp) {
#ifdef CONFIG_FS_DAX_PMD
pmd_t pmd;

if (pfn != pmd_pfn(*pmdp))
goto unlock_pmd;  
if (!pmd_dirty(*pmdp) && !pmd_write(*pmdp))
goto unlock_pmd;

flush_cache_page(vma, address, pfn);
pmd = pmdp_invalidate(vma, address, pmdp);
pmd = pmd_wrprotect(pmd);
pmd = pmd_mkclean(pmd);
set_pmd_at(vma->vm_mm, address, pmdp, pmd);
unlock_pmd:  
#endif 
--
pmdp_invalidate is called here to flush pmd range already, it is not necessary
to flush pmd range in function set_pmd_at

--
if (!pmd_none(*(vmf->pmd))) {
spin_unlock(ptl);
goto fallback;
}

if (pgtable) {
pgtable_trans_huge_deposit(vma->vm_mm, vmf->pmd, pgtable);
mm_inc_nr_ptes(vma->vm_mm);
}
pmd_entry = mk_pmd(zero_page, vmf->vma->vm_page_prot);
pmd_entry = pmd_mkhuge(pmd_entry);
set_pmd_at(vmf->vma->vm_mm, pmd_addr, vmf->pmd, pmd_entry);
spin_unlock(ptl);
trace_dax_pmd_load_hole(inode, vmf, zero_page, *entry);
return VM_FAULT_NOPAGE;
--
pmd entry is none, does not need to flush pmd range


in file fs/proc/task_mmu.c
--
static inline void clear_soft_dirty_pmd(struct vm_area_struct *vma,
unsigned long addr, pmd_t *pmdp)
{
pmd_t old, pmd = *pmdp;

if (pmd_present(pmd)) {
/* See comment in change_huge_pmd() */
old = pmdp_invalidate(vma, addr, pmdp);
if (pmd_dirty(old))
pmd = pmd_mkdirty(pmd);
if (pmd_young(old))
pmd = pmd_mkyoung(pmd);

pmd = pmd_wrprotect(pmd);
pmd = pmd_clear_soft_dirty(pmd);

set_pmd_at(vma->vm_mm, addr, pmdp, pmd);
} else if (is_migration_entry(pmd_to_swp_entry(pmd))) {
pmd = pmd_swp_clear_soft_dirty(pmd);
set_pmd_at(vma->vm_mm, addr, pmdp, pmd);
}
}
--
At the first place where set_pmd_at is called, pmdp_invalidate is called to
flush pmd range. At the second place, on mips system 
pmd_swp_clear_soft_dirty(pmd)
is equal to pmd, pmd entry has no change, does not need to flush pmd range

in file linux/mm/rmap.c:
--
pmd_t *pmd = pvmw.pmd;
pmd_t entry;
  
if (!pmd_dirty(*pmd) && !pmd_write(*pmd))
continue;

flush_cache_page(vma, address, page_to_pfn(page));
entry = pmdp_invalidate(vma, address, pmd);
entry = pmd_wrprotect(entry);
entry = pmd_mkclean(entry);
set_pmd_at(vma->vm_mm, address, pmd, entry);
ret = 1;
--
pmdp_invalidate is called to flush pmd range, does not need to flush pmd range
again in function set_pmd_at.

> 
> Thomas.
> 

[PATCH 1/2] tracing/boot: Fix config dependency for synthedic event

[Masami Hiramatsu]

Since commit 726721a51838 ("tracing: Move synthetic events to
a separate file") decoupled synthetic event from histogram,
boot-time tracing also has to check CONFIG_SYNTH_EVENT instead
of CONFIG_HIST_TRIGGERS.

Fixes: 726721a51838 ("tracing: Move synthetic events to a separate file")
Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/trace_boot.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace_boot.c b/kernel/trace/trace_boot.c
index 9de29bb45a27..8b5490cb02bb 100644
--- a/kernel/trace/trace_boot.c
+++ b/kernel/trace/trace_boot.c
@@ -120,7 +120,7 @@ trace_boot_add_kprobe_event(struct xbc_node *node, const 
char *event)
 }
 #endif
 
-#ifdef CONFIG_HIST_TRIGGERS
+#ifdef CONFIG_SYNTH_EVENTS
 static int __init
 trace_boot_add_synth_event(struct xbc_node *node, const char *event)
 {

Re: [PATCH] serial: sh-sci: fix uninitialized variable warning

[Kees Cook]

On Thu, Jun 13, 2019 at 03:08:24PM -0300, Charles wrote:
> Avoid following compiler warning on uninitialized variable
> 
> In file included from ./include/linux/rwsem.h:16:0,
>  from ./include/linux/notifier.h:15,
>  from ./include/linux/clk.h:17,
>  from drivers/tty/serial/sh-sci.c:24:
> drivers/tty/serial/sh-sci.c: In function ‘sci_dma_rx_submit’:
> ./include/linux/spinlock.h:288:3: warning: ‘flags’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>_raw_spin_unlock_irqrestore(lock, flags); \
>^~~
> drivers/tty/serial/sh-sci.c:1353:16: note: ‘flags’ was declared here
>   unsigned long flags;
> ^
> 
> Signed-off-by: Charles Oliveira <18oliveira.char...@gmail.com>
> ---
>  drivers/tty/serial/sh-sci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index abc705716aa0..a6af73eaec11 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1350,7 +1350,7 @@ static int sci_dma_rx_submit(struct sci_port *s, bool 
> port_lock_held)
>  {
>   struct dma_chan *chan = s->chan_rx;
>   struct uart_port *port = >port;
> - unsigned long flags;
> + unsigned long uninitialized_var(flags);

akpm made this same change in -mm, and it's not the right
solution[1]. Please just initialize it to 0 if the compiler can't figure
it out. :)

-Kees

[1] https://lore.kernel.org/lkml/20200620033007.1444705-2-keesc...@chromium.org/

>   int i;
>  
>   for (i = 0; i < 2; i++) {
> -- 
> 2.11.0
> 

-- 
Kees Cook

[PATCH v2 05/16] rtlwifi: rtl8192cu: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just initialize this variable to NULL,
and avoid sending garbage by returning.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: dc0313f46664 ("rtlwifi: rtl8192cu: Add routine hw")
Reviewed-by: Nick Desaulniers 
Acked-by: Kalle Valo 
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index f070f25bb735..5b071b70bc08 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
@@ -592,7 +592,7 @@ static void _rtl92cu_init_chipn_one_out_ep_priority(struct 
ieee80211_hw *hw,
bool wmm_enable,
u8 queue_sel)
 {
-   u16 uninitialized_var(value);
+   u16 value;
 
switch (queue_sel) {
case TX_SELE_HQ:
@@ -606,7 +606,7 @@ static void _rtl92cu_init_chipn_one_out_ep_priority(struct 
ieee80211_hw *hw,
break;
default:
WARN_ON(1); /* Shall not reach here! */
-   break;
+   return;
}
_rtl92c_init_chipn_reg_priority(hw, value, value, value, value,
value, value);
-- 
2.25.1

[PATCH v2 02/16] x86/mm/numa: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], refactor code to avoid its need.

The original reason for its use here was to work around the #ifdef
being the only place the variable was used. This is better expressed
using IS_ENABLED() and a new code block where the variable can be used
unconditionally.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: 1e01979c8f50 ("x86, numa: Implement pfn -> nid mapping granularity 
check")
Signed-off-by: Kees Cook 
---
 arch/x86/mm/numa.c| 18 +-
 include/linux/page-flags-layout.h |  4 +++-
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 8ee952038c80..b05f45e5e8e2 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -543,7 +543,6 @@ static void __init numa_clear_kernel_node_hotplug(void)
 
 static int __init numa_register_memblks(struct numa_meminfo *mi)
 {
-   unsigned long uninitialized_var(pfn_align);
int i, nid;
 
/* Account for nodes with cpus and no memory */
@@ -571,15 +570,16 @@ static int __init numa_register_memblks(struct 
numa_meminfo *mi)
 * If sections array is gonna be used for pfn -> nid mapping, check
 * whether its granularity is fine enough.
 */
-#ifdef NODE_NOT_IN_PAGE_FLAGS
-   pfn_align = node_map_pfn_alignment();
-   if (pfn_align && pfn_align < PAGES_PER_SECTION) {
-   printk(KERN_WARNING "Node alignment %LuMB < min %LuMB, 
rejecting NUMA config\n",
-  PFN_PHYS(pfn_align) >> 20,
-  PFN_PHYS(PAGES_PER_SECTION) >> 20);
-   return -EINVAL;
+   if (IS_ENABLED(NODE_NOT_IN_PAGE_FLAGS)) {
+   unsigned long pfn_align = node_map_pfn_alignment();
+
+   if (pfn_align && pfn_align < PAGES_PER_SECTION) {
+   pr_warn("Node alignment %LuMB < min %LuMB, rejecting 
NUMA config\n",
+   PFN_PHYS(pfn_align) >> 20,
+   PFN_PHYS(PAGES_PER_SECTION) >> 20);
+   return -EINVAL;
+   }
}
-#endif
if (!numa_meminfo_cover_memory(mi))
return -EINVAL;
 
diff --git a/include/linux/page-flags-layout.h 
b/include/linux/page-flags-layout.h
index 71283739ffd2..e200eef6a7fd 100644
--- a/include/linux/page-flags-layout.h
+++ b/include/linux/page-flags-layout.h
@@ -98,9 +98,11 @@
 /*
  * We are going to use the flags for the page to node mapping if its in
  * there.  This includes the case where there is no node, so it is implicit.
+ * Note that this #define MUST have a value so that it can be tested with
+ * the IS_ENABLED() macro.
  */
 #if !(NODES_WIDTH > 0 || NODES_SHIFT == 0)
-#define NODE_NOT_IN_PAGE_FLAGS
+#define NODE_NOT_IN_PAGE_FLAGS 1
 #endif
 
 #if defined(CONFIG_NUMA_BALANCING) && LAST_CPUPID_WIDTH == 0
-- 
2.25.1

[PATCH v2 03/16] drbd: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just initialize this variable to NULL.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: a29728463b25 ("drbd: Backport the "events2" command")
Reviewed-by: Nick Desaulniers 
Signed-off-by: Kees Cook 
---
 drivers/block/drbd/drbd_state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/drbd/drbd_state.c b/drivers/block/drbd/drbd_state.c
index eeaa3b49b264..0067d328f0b5 100644
--- a/drivers/block/drbd/drbd_state.c
+++ b/drivers/block/drbd/drbd_state.c
@@ -1604,7 +1604,7 @@ static void broadcast_state_change(struct 
drbd_state_change *state_change)
unsigned int n_device, n_connection, n_peer_device, n_peer_devices;
void (*last_func)(struct sk_buff *, unsigned int, void *,
  enum drbd_notification_type) = NULL;
-   void *uninitialized_var(last_arg);
+   void *last_arg = NULL;
 
 #define HAS_CHANGED(state) ((state)[OLD] != (state)[NEW])
 #define FINAL_STATE_CHANGE(type) \
-- 
2.25.1

[PATCH v2 12/16] f2fs: Eliminate usage of uninitialized_var() macro

[Kees Cook]

From: Jason Yan 

This is an effort to eliminate the uninitialized_var() macro[1].

The use of this macro is the wrong solution because it forces off ANY
analysis by the compiler for a given variable. It even masks "unused
variable" warnings.

Quoted from Linus[2]:

"It's a horrible thing to use, in that it adds extra cruft to the
source code, and then shuts up a compiler warning (even the _reliable_
warnings from gcc)."

Fix it by remove this variable since it is not needed at all.

[1] https://github.com/KSPP/linux/issues/81
[2] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Suggested-by: Chao Yu 
Signed-off-by: Jason Yan 
Reviewed-by: Chao Yu 
Link: https://lore.kernel.org/r/20200615085132.166470-1-yanai...@huawei.com
Signed-off-by: Kees Cook 
---
 fs/f2fs/data.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 326c63879ddc..3753ba06531b 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2856,7 +2856,6 @@ static int f2fs_write_cache_pages(struct address_space 
*mapping,
};
 #endif
int nr_pages;
-   pgoff_t uninitialized_var(writeback_index);
pgoff_t index;
pgoff_t end;/* Inclusive */
pgoff_t done_index;
@@ -2875,8 +2874,7 @@ static int f2fs_write_cache_pages(struct address_space 
*mapping,
clear_inode_flag(mapping->host, FI_HOT_DATA);
 
if (wbc->range_cyclic) {
-   writeback_index = mapping->writeback_index; /* prev offset */
-   index = writeback_index;
+   index = mapping->writeback_index; /* prev offset */
end = -1;
} else {
index = wbc->range_start >> PAGE_SHIFT;
-- 
2.25.1

[PATCH v2 07/16] clk: st: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just remove this variable since it was
actually unused:

drivers/clk/st/clkgen-fsyn.c: In function ‘quadfs_set_rate’:
drivers/clk/st/clkgen-fsyn.c:793:6: warning: unused variable ‘i’ 
[-Wunused-variable]
  793 |  int i;
  |  ^

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: 5f7aa9071e93 ("clk: st: Support for QUADFS inside ClockGenB/C/D/E/F")
Signed-off-by: Kees Cook 
---
 drivers/clk/st/clkgen-fsyn.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/st/clkgen-fsyn.c b/drivers/clk/st/clkgen-fsyn.c
index a156bd0c6af7..f1adc858b590 100644
--- a/drivers/clk/st/clkgen-fsyn.c
+++ b/drivers/clk/st/clkgen-fsyn.c
@@ -790,7 +790,6 @@ static int quadfs_set_rate(struct clk_hw *hw, unsigned long 
rate,
struct st_clk_quadfs_fsynth *fs = to_quadfs_fsynth(hw);
struct stm_fs params;
long hwrate;
-   int uninitialized_var(i);
 
if (!rate || !parent_rate)
return -EINVAL;
-- 
2.25.1

[PATCH v2 06/16] ide: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just remove this variable since it was
actually unused:

drivers/ide/ide-taskfile.c:232:34: warning: unused variable 'flags' 
[-Wunused-variable]
unsigned long uninitialized_var(flags);
^

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: ce1e518190ea ("ide: don't disable interrupts during kmap_atomic()")
Reviewed-by: Nick Desaulniers 
Signed-off-by: Kees Cook 
---
 drivers/ide/ide-taskfile.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ide/ide-taskfile.c b/drivers/ide/ide-taskfile.c
index aab6a10435b6..a26f85ab58a9 100644
--- a/drivers/ide/ide-taskfile.c
+++ b/drivers/ide/ide-taskfile.c
@@ -229,7 +229,6 @@ void ide_pio_bytes(ide_drive_t *drive, struct ide_cmd *cmd,
ide_hwif_t *hwif = drive->hwif;
struct scatterlist *sg = hwif->sg_table;
struct scatterlist *cursg = cmd->cursg;
-   unsigned long uninitialized_var(flags);
struct page *page;
unsigned int offset;
u8 *buf;
-- 
2.25.1

[PATCH v2 08/16] spi: davinci: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just remove this variable since it was
actually unused:

drivers/spi/spi-davinci.c: In function ‘davinci_spi_bufs’:
drivers/spi/spi-davinci.c:579:11: warning: unused variable ‘rx_buf_count’ 
[-Wunused-variable]
  579 |  unsigned rx_buf_count;
  |   ^~~~

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: 048177ce3b39 ("spi: spi-davinci: convert to DMA engine API")
Reviewed-by: Nick Desaulniers 
Signed-off-by: Kees Cook 
---
 drivers/spi/spi-davinci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index f71c497393a6..f50c0c79cbdf 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -576,7 +576,6 @@ static int davinci_spi_bufs(struct spi_device *spi, struct 
spi_transfer *t)
u32 errors = 0;
struct davinci_spi_config *spicfg;
struct davinci_spi_platform_data *pdata;
-   unsigned uninitialized_var(rx_buf_count);
 
dspi = spi_master_get_devdata(spi->master);
pdata = >pdata;
-- 
2.25.1

[PATCH v2 09/16] clk: spear: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], initialize "i" to zero. The compiler
warning was not a false positive, since clk_pll_set_rate()'s call to
clk_pll_round_rate_index() will always fail (since "prate" is NULL), so
"i" was never being initialized.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: 7d4998f71b29 ("clk: SPEAr: Vco-pll: Fix compilation warning")
Signed-off-by: Kees Cook 
---
 drivers/clk/spear/clk-vco-pll.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/spear/clk-vco-pll.c b/drivers/clk/spear/clk-vco-pll.c
index c08dec30bfa6..fed194169666 100644
--- a/drivers/clk/spear/clk-vco-pll.c
+++ b/drivers/clk/spear/clk-vco-pll.c
@@ -147,7 +147,7 @@ static int clk_pll_set_rate(struct clk_hw *hw, unsigned 
long drate,
struct clk_pll *pll = to_clk_pll(hw);
struct pll_rate_tbl *rtbl = pll->vco->rtbl;
unsigned long flags = 0, val;
-   int uninitialized_var(i);
+   int i = 0;
 
clk_pll_round_rate_index(hw, drate, NULL, );
 
-- 
2.25.1

[PATCH v2 11/16] media: sur40: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just remove this variable since it was
actually unused:

drivers/input/touchscreen/sur40.c:459:6: warning: variable 'packet_id' set but 
not used [-Wunused-but-set-variable]
  459 |  u32 packet_id;
  |  ^

However, in keeping with the documentation desires outlined in commit
335abaea7a27 ("Input: sur40 - silence unnecessary noisy debug output"),
comment out the assignment instead of removing it.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: 335abaea7a27 ("Input: sur40 - silence unnecessary noisy debug output")
Signed-off-by: Kees Cook 
---
 drivers/input/touchscreen/sur40.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/input/touchscreen/sur40.c 
b/drivers/input/touchscreen/sur40.c
index 34d31c7ec8ba..620cdd7d214a 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -456,8 +456,6 @@ static void sur40_poll(struct input_dev *input)
 {
struct sur40_state *sur40 = input_get_drvdata(input);
int result, bulk_read, need_blobs, packet_blobs, i;
-   u32 uninitialized_var(packet_id);
-
struct sur40_header *header = >bulk_in_buffer->header;
struct sur40_blob *inblob = >bulk_in_buffer->blobs[0];
 
@@ -491,7 +489,7 @@ static void sur40_poll(struct input_dev *input)
if (need_blobs == -1) {
need_blobs = le16_to_cpu(header->count);
dev_dbg(sur40->dev, "need %d blobs\n", need_blobs);
-   packet_id = le32_to_cpu(header->packet_id);
+   /* packet_id = le32_to_cpu(header->packet_id); */
}
 
/*
-- 
2.25.1

[PATCH v2 14/16] checkpatch: Remove awareness of uninitialized_var() macro

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.

In preparation for removing[2] the[3] macro[4], partially revert
commit 16b7f3c89907 ("checkpatch: avoid warning about uninitialized_var()")
and remove all remaining mentions of uninitialized_var().

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Signed-off-by: Kees Cook 
---
 scripts/checkpatch.pl | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4c820607540b..60b737e222fe 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -840,7 +840,6 @@ our $FuncArg = 
qr{$Typecast{0,1}($LvalOrFunc|$Constant|$String)};
 our $declaration_macros = qr{(?x:

(?:$Storage\s+)?(?:[A-Z_][A-Z0-9]*_){0,2}(?:DEFINE|DECLARE)(?:_[A-Z0-9]+){1,6}\s*\(|
(?:$Storage\s+)?[HLP]?LIST_HEAD\s*\(|
-   (?:$Storage\s+)?${Type}\s+uninitialized_var\s*\(|
(?:SKCIPHER_REQUEST|SHASH_DESC|AHASH_REQUEST)_ON_STACK\s*\(
 )};
 
@@ -6330,8 +6329,7 @@ sub process {
if (defined $cond) {
substr($s, 0, length($cond), '');
}
-   if ($s =~ /^\s*;/ &&
-   $function_name ne 'uninitialized_var')
+   if ($s =~ /^\s*;/)
{
WARN("AVOID_EXTERNS",
 "externs should be avoided in .c files\n" 
.  $herecurr);
@@ -6350,17 +6348,13 @@ sub process {
}
 
 # check for function declarations that have arguments without identifier names
-# while avoiding uninitialized_var(x)
if (defined $stat &&
-   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*(?:($Ident)|\(\s*\*\s*$Ident\s*\))\s*\(\s*([^{]+)\s*\)\s*;/s
 &&
-   (!defined($1) ||
-(defined($1) && $1 ne "uninitialized_var")) &&
-$2 ne "void") {
-   my $args = trim($2);
+   $stat =~ 
/^.\s*(?:extern\s+)?$Type\s*(?:$Ident|\(\s*\*\s*$Ident\s*\))\s*\(\s*([^{]+)\s*\)\s*;/s
 &&
+   $1 ne "void") {
+   my $args = trim($1);
while ($args =~ 
m/\s*($Type\s*(?:$Ident|\(\s*\*\s*$Ident?\s*\)\s*$balanced_parens)?)/g) {
my $arg = trim($1);
-   if ($arg =~ /^$Type$/ &&
-   $arg !~ /enum\s+$Ident$/) {
+   if ($arg =~ /^$Type$/ && $arg !~ 
/enum\s+$Ident$/) {
WARN("FUNCTION_ARGUMENTS",
 "function definition argument 
'$arg' should also have an identifier name\n" . $herecurr);
}
-- 
2.25.1

[PATCH v2 13/16] mm/debug_vm_pgtable: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just initialize this variable to NULL.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: 399145f9eb6c ("mm/debug: add tests validating architecture page table 
helpers")
Signed-off-by: Kees Cook 
---
 mm/debug_vm_pgtable.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index e45623016aea..83c9e88a052a 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -307,7 +307,7 @@ static int __init debug_vm_pgtable(void)
phys_addr_t paddr;
unsigned long vaddr, pte_aligned, pmd_aligned;
unsigned long pud_aligned, p4d_aligned, pgd_aligned;
-   spinlock_t *uninitialized_var(ptl);
+   spinlock_t *ptl = NULL;
 
pr_info("Validating architecture page table helpers\n");
prot = vm_get_page_prot(VMFLAGS);
-- 
2.25.1

[PATCH v2 15/16] treewide: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.

I preparation for removing[2] the[3] macro[4], remove all remaining
needless uses with the following script:

git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
xargs perl -pi -e \
's/\buninitialized_var\(([^\)]+)\)/\1/g;
 s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'

drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
pathological white-space.

No outstanding warnings were found building allmodconfig with GCC 9.3.0
for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
alpha, and m68k.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Reviewed-by: Leon Romanovsky  # drivers/infiniband and 
mlx4/mlx5
Acked-by: Jason Gunthorpe  # IB
Acked-by: Kalle Valo  # wireless drivers
Reviewed-by: Chao Yu  # erofs
Signed-off-by: Kees Cook 
---
 arch/arm/mach-sa1100/assabet.c   |  2 +-
 arch/arm/mm/alignment.c  |  2 +-
 arch/ia64/kernel/process.c   |  2 +-
 arch/ia64/mm/discontig.c |  2 +-
 arch/ia64/mm/tlb.c   |  2 +-
 arch/mips/lib/dump_tlb.c |  2 +-
 arch/mips/mm/init.c  |  2 +-
 arch/mips/mm/tlb-r4k.c   |  6 +++---
 arch/powerpc/kvm/book3s_64_mmu_radix.c   |  2 +-
 arch/powerpc/kvm/powerpc.c   |  2 +-
 arch/powerpc/platforms/52xx/mpc52xx_pic.c|  2 +-
 arch/s390/kernel/smp.c   |  2 +-
 arch/x86/kernel/quirks.c | 10 +-
 arch/x86/kvm/mmu/mmu.c   |  2 +-
 arch/x86/kvm/mmu/paging_tmpl.h   |  2 +-
 arch/x86/kvm/x86.c   |  2 +-
 block/blk-merge.c|  2 +-
 drivers/acpi/acpi_pad.c  |  2 +-
 drivers/ata/libata-scsi.c|  2 +-
 drivers/atm/zatm.c   |  2 +-
 drivers/block/drbd/drbd_nl.c |  6 +++---
 drivers/block/rbd.c  |  2 +-
 drivers/clk/clk-gate.c   |  2 +-
 drivers/firewire/ohci.c  | 14 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c |  2 +-
 drivers/gpu/drm/drm_edid.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  6 +++---
 drivers/gpu/drm/i915/display/intel_fbc.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c  |  2 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c  |  4 ++--
 drivers/i2c/busses/i2c-rk3x.c|  2 +-
 drivers/ide/ide-acpi.c   |  2 +-
 drivers/ide/ide-atapi.c  |  2 +-
 drivers/ide/ide-io-std.c |  4 ++--
 drivers/ide/ide-io.c |  8 
 drivers/ide/ide-sysfs.c  |  2 +-
 drivers/ide/umc8672.c|  2 +-
 drivers/idle/intel_idle.c|  2 +-
 drivers/infiniband/core/uverbs_cmd.c |  4 ++--
 drivers/infiniband/hw/cxgb4/cm.c |  2 +-
 drivers/infiniband/hw/cxgb4/cq.c |  2 +-
 drivers/infiniband/hw/mlx4/qp.c  |  6 +++---
 drivers/infiniband/hw/mlx5/cq.c  |  6 +++---
 drivers/infiniband/hw/mlx5/devx.c|  2 +-
 drivers/infiniband/hw/mlx5/wr.c  |  2 +-
 drivers/infiniband/hw/mthca/mthca_qp.c   | 10 +-
 drivers/infiniband/sw/siw/siw_qp_rx.c|  2 +-
 drivers/input/serio/serio_raw.c  |  2 +-
 drivers/iommu/intel/iommu.c  |  2 +-
 drivers/md/dm-io.c   |  2 +-
 drivers/md/dm-ioctl.c|  2 +-
 drivers/md/dm-snap-persistent.c  |  2 +-
 drivers/md/dm-table.c|  2 +-
 drivers/md/dm-writecache.c   |  2 +-
 drivers/md/raid5.c   |  2 +-
 drivers/media/dvb-frontends/rtl2832.c|  2 +-
 drivers/media/tuners/qt1010.c|  4 ++--
 drivers/media/usb/gspca/vicam.c  |  2 +-
 drivers/media/usb/uvc/uvc_video.c|  8 
 

[PATCH v2 16/16] compiler: Remove uninitialized_var() macro

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.

As recommended[2] by[3] Linus[4], remove the macro. With the recent
change to disable -Wmaybe-uninitialized in v5.7 in commit 78a5255ffb6a
("Stop the ad-hoc games with -Wno-maybe-initialized"), this is likely
the best time to make this treewide change.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Suggested-by: Linus Torvalds 
Reviewed-by: Bart van Assche 
Reviewed-by: Miguel Ojeda 
Tested-by: Nathan Chancellor 
Tested-by: Sedat Dilek 
Signed-off-by: Kees Cook 
---
 include/linux/compiler-clang.h | 2 --
 include/linux/compiler-gcc.h   | 6 --
 tools/include/linux/compiler.h | 2 --
 tools/virtio/linux/kernel.h| 2 --
 4 files changed, 12 deletions(-)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index ee37256ec8bd..f2371b83aaf2 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -5,8 +5,6 @@
 
 /* Compiler specific definitions for Clang compiler */
 
-#define uninitialized_var(x) x = *(&(x))
-
 /* same as gcc, this was present in clang-2.6 so we can assume it works
  * with any version that can compile the kernel
  */
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 7dd4e0349ef3..84e099a87383 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -59,12 +59,6 @@
(typeof(ptr)) (__ptr + (off));  \
 })
 
-/*
- * A trick to suppress uninitialized variable warning without generating any
- * code
- */
-#define uninitialized_var(x) x = x
-
 #ifdef CONFIG_RETPOLINE
 #define __noretpoline __attribute__((__indirect_branch__("keep")))
 #endif
diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h
index 9f9002734e19..2f2f4082225e 100644
--- a/tools/include/linux/compiler.h
+++ b/tools/include/linux/compiler.h
@@ -111,8 +111,6 @@
 # define noinline
 #endif
 
-#define uninitialized_var(x) x = *(&(x))
-
 #include 
 
 /*
diff --git a/tools/virtio/linux/kernel.h b/tools/virtio/linux/kernel.h
index 6683b4a70b05..1e14ab967c11 100644
--- a/tools/virtio/linux/kernel.h
+++ b/tools/virtio/linux/kernel.h
@@ -109,8 +109,6 @@ static inline void free_page(unsigned long addr)
const typeof( ((type *)0)->member ) *__mptr = (ptr);\
(type *)( (char *)__mptr - offsetof(type,member) );})
 
-#define uninitialized_var(x) x = x
-
 # ifndef likely
 #  define likely(x)(__builtin_expect(!!(x), 1))
 # endif
-- 
2.25.1

[PATCH v2 10/16] KVM: PPC: Book3S PR: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just remove this variable since it was
actually unused:

arch/powerpc/kvm/book3s_pr.c:1832:16: warning: unused variable 'vrsave' 
[-Wunused-variable]
unsigned long vrsave;
  ^

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Suggested-by: Nathan Chancellor 
Fixes: f05ed4d56e9c ("KVM: PPC: Split out code from book3s.c into book3s_pr.c")
Signed-off-by: Kees Cook 
---
 arch/powerpc/kvm/book3s_pr.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index ef54f917bdaf..ed12dfbf9bb5 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1828,9 +1828,6 @@ static int kvmppc_vcpu_run_pr(struct kvm_vcpu *vcpu)
 {
struct kvm_run *run = vcpu->run;
int ret;
-#ifdef CONFIG_ALTIVEC
-   unsigned long uninitialized_var(vrsave);
-#endif
 
/* Check if we can run the vcpu at all */
if (!vcpu->arch.sane) {
-- 
2.25.1

[PATCH v2 01/16] docs: deprecated.rst: Add uninitialized_var()

[Kees Cook]

Nothing should be using this macro, and the entire idea of tricking the
compiler into silencing such warnings is a mistake.

Signed-off-by: Kees Cook 
---
 Documentation/process/deprecated.rst | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/process/deprecated.rst 
b/Documentation/process/deprecated.rst
index 652e2aa02a66..943a926ecbbb 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -51,6 +51,24 @@ to make sure their systems do not continue running in the 
face of
 "unreachable" conditions. (For example, see commits like `this one
 `_.)
 
+uninitialized_var()
+---
+For any compiler warnings about uninitialized variables, just add
+an initializer. Using the uninitialized_var() macro (or similar
+warning-silencing tricks) is dangerous as it papers over `real bugs
+`_
+(or can in the future), and suppresses unrelated compiler warnings
+(e.g. "unused variable"). If the compiler thinks it is uninitialized,
+either simply initialize the variable or make compiler changes. Keep in
+mind that in most cases, if an initialization is obviously redundant,
+the compiler's dead-store elimination pass will make sure there are no
+needless variable writes.
+
+As Linus has said, this macro
+`must 
`_
+`be 
`_
+`removed 
`_.
+
 open-coded arithmetic in allocator arguments
 
 Dynamic size calculations (especially multiplication) should not be
-- 
2.25.1

[PATCH v2 00/16] Remove uninitialized_var() macro

[Kees Cook]

v2:
- more special-cased fixes
- add reviews
v1: https://lore.kernel.org/lkml/20200603233203.1695403-1-keesc...@chromium.org

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.

As recommended[2] by[3] Linus[4], remove the macro.

Most of the 300 uses don't cause any warnings on gcc 9.3.0, so they're in
a single treewide commit in this series. A few others needed to actually
get cleaned up, and I broke those out into individual patches.

The tree is:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/uninit/macro

-Kees

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Jason Yan (1):
  f2fs: Eliminate usage of uninitialized_var() macro

Kees Cook (15):
  docs: deprecated.rst: Add uninitialized_var()
  x86/mm/numa: Remove uninitialized_var() usage
  drbd: Remove uninitialized_var() usage
  b43: Remove uninitialized_var() usage
  rtlwifi: rtl8192cu: Remove uninitialized_var() usage
  ide: Remove uninitialized_var() usage
  clk: st: Remove uninitialized_var() usage
  spi: davinci: Remove uninitialized_var() usage
  clk: spear: Remove uninitialized_var() usage
  KVM: PPC: Book3S PR: Remove uninitialized_var() usage
  media: sur40: Remove uninitialized_var() usage
  checkpatch: Remove awareness of uninitialized_var() macro
  treewide: Remove uninitialized_var() usage
  compiler: Remove uninitialized_var() macro
  mm/debug_vm_pgtable: Remove uninitialized_var() usage

 Documentation/process/deprecated.rst   | 18 ++
 arch/arm/mach-sa1100/assabet.c |  2 +-
 arch/arm/mm/alignment.c|  2 +-
 arch/ia64/kernel/process.c |  2 +-
 arch/ia64/mm/discontig.c   |  2 +-
 arch/ia64/mm/tlb.c |  2 +-
 arch/mips/lib/dump_tlb.c   |  2 +-
 arch/mips/mm/init.c|  2 +-
 arch/mips/mm/tlb-r4k.c |  6 +++---
 arch/powerpc/kvm/book3s_64_mmu_radix.c |  2 +-
 arch/powerpc/kvm/book3s_pr.c   |  3 ---
 arch/powerpc/kvm/powerpc.c |  2 +-
 arch/powerpc/platforms/52xx/mpc52xx_pic.c  |  2 +-
 arch/s390/kernel/smp.c |  2 +-
 arch/x86/kernel/quirks.c   | 10 +-
 arch/x86/kvm/mmu/mmu.c |  2 +-
 arch/x86/kvm/mmu/paging_tmpl.h |  2 +-
 arch/x86/kvm/x86.c |  2 +-
 arch/x86/mm/numa.c | 18 +-
 block/blk-merge.c  |  2 +-
 drivers/acpi/acpi_pad.c|  2 +-
 drivers/ata/libata-scsi.c  |  2 +-
 drivers/atm/zatm.c |  2 +-
 drivers/block/drbd/drbd_nl.c   |  6 +++---
 drivers/block/drbd/drbd_state.c|  2 +-
 drivers/block/rbd.c|  2 +-
 drivers/clk/clk-gate.c |  2 +-
 drivers/clk/spear/clk-vco-pll.c|  2 +-
 drivers/clk/st/clkgen-fsyn.c   |  1 -
 drivers/firewire/ohci.c| 14 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   |  2 +-
 drivers/gpu/drm/drm_edid.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  6 +++---
 drivers/gpu/drm/i915/display/intel_fbc.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_uncore.c|  2 +-
 .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c|  4 ++--
 drivers/i2c/busses/i2c-rk3x.c  |  2 +-
 drivers/ide/ide-acpi.c |  2 +-
 drivers/ide/ide-atapi.c|  2 +-
 drivers/ide/ide-io-std.c   |  4 ++--
 drivers/ide/ide-io.c   |  8 
 drivers/ide/ide-sysfs.c|  2 +-
 drivers/ide/ide-taskfile.c |  1 -
 drivers/ide/umc8672.c  |  2 +-
 drivers/idle/intel_idle.c  |  2 +-
 drivers/infiniband/core/uverbs_cmd.c   |  4 ++--
 drivers/infiniband/hw/cxgb4/cm.c   |  2 +-
 drivers/infiniband/hw/cxgb4/cq.c   |  2 +-
 drivers/infiniband/hw/mlx4/qp.c|  6 +++---
 drivers/infiniband/hw/mlx5/cq.c|  6 +++---
 drivers/infiniband/hw/mlx5/devx.c  |  2 +-
 drivers/infiniband/hw/mlx5/wr.c 

[PATCH v2 04/16] b43: Remove uninitialized_var() usage

[Kees Cook]

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2] this[3] macro[4], just initialize this variable to NULL.
No later NULL deref is possible due to the early returns outside of the
(phy->rev >= 7 && phy->rev < 19) case, which explicitly tests for NULL.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
[2] 
https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
[4] 
https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/

Fixes: 58619b14d106 ("b43: move under broadcom vendor directory")
Signed-off-by: Kees Cook 
---
 drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c 
b/drivers/net/wireless/broadcom/b43/phy_n.c
index c33b4235839d..46db91846007 100644
--- a/drivers/net/wireless/broadcom/b43/phy_n.c
+++ b/drivers/net/wireless/broadcom/b43/phy_n.c
@@ -4222,7 +4222,7 @@ static void b43_nphy_tx_gain_table_upload(struct 
b43_wldev *dev)
u32 rfpwr_offset;
u8 pga_gain, pad_gain;
int i;
-   const s16 *uninitialized_var(rf_pwr_offset_table);
+   const s16 *rf_pwr_offset_table = NULL;
 
table = b43_nphy_get_tx_gain_table(dev);
if (!table)
-- 
2.25.1

Re: [PATCH 1/1] Documentation:sysfs-ufs: Add WriteBooster documentation

[Martin K. Petersen]

On Tue, 9 Jun 2020 10:17:46 -0700, Asutosh Das wrote:

> Adds sysfs documentation for WriteBooster entries.

Applied to 5.9/scsi-queue, thanks!

[1/1] scsi: ufs: docs: Add WriteBooster documentation
  https://git.kernel.org/mkp/scsi/c/f51853fc0682

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2 0/2] scsi: remove scsi_sdb_cache

[Martin K. Petersen]

On Fri, 19 Jun 2020 17:41:15 +0200, Bean Huo wrote:

> Changelog:
> v1 -- v2:
> 1. split patch
> 2. fix more coding errors in the scsi_lib.c
> 
> Bean Huo (2):
>   scsi: remove scsi_sdb_cache
>   scsi: fix coding style errors in scsi_lib.c
> 
> [...]

Applied to 5.9/scsi-queue, thanks!

[1/2] scsi: core: Remove scsi_sdb_cache
  https://git.kernel.org/mkp/scsi/c/71df6fb976c3
[2/2] scsi: core: Fix formatting errors in scsi_lib.c
  https://git.kernel.org/mkp/scsi/c/4c7b4d63273d

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v2] arch: arm: imx6qdl-icore: Fix OTG_ID pin and sdcard detect

[Suniel Mahesh]

From: Michael Trimarchi 

The current pin muxing scheme muxes GPIO_1 pad for USB_OTG_ID
because of which when card is inserted, usb otg is enumerated
and the card is never detected.

[   64.492645] cfg80211: failed to load regulatory.db
[   64.492657] imx-sdma 20ec000.sdma: external firmware not found, using ROM 
firmware
[   76.343711] ci_hdrc ci_hdrc.0: EHCI Host Controller
[   76.349742] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 2
[   76.388862] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[   76.396650] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, 
bcdDevice= 5.08
[   76.405412] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   76.412763] usb usb2: Product: EHCI Host Controller
[   76.417666] usb usb2: Manufacturer: Linux 5.8.0-rc1-next-20200618 ehci_hcd
[   76.424623] usb usb2: SerialNumber: ci_hdrc.0
[   76.431755] hub 2-0:1.0: USB hub found
[   76.435862] hub 2-0:1.0: 1 port detected

The TRM mentions GPIO_1 pad should be muxed/assigned for card detect
and ENET_RX_ER pad for USB_OTG_ID for proper operation.

This patch fixes pin muxing as per TRM and is tested on a
i.Core 1.5 MX6 DL SOM.

[   22.449165] mmc0: host does not support reading read-only switch, assuming 
write-enable
[   22.459992] mmc0: new high speed SDHC card at address 0001
[   22.469725] mmcblk0: mmc0:0001 EB1QT 29.8 GiB
[   22.478856]  mmcblk0: p1 p2

Signed-off-by: Michael Trimarchi 
Signed-off-by: Suniel Mahesh 
---
Changes for v2:
- Changed patch description as suggested by Michael Trimarchi to make it
  more readable/understandable.
---
 arch/arm/boot/dts/imx6qdl-icore.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi 
b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index 756f3a9..12997da 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -397,7 +397,7 @@
 
pinctrl_usbotg: usbotggrp {
fsl,pins = <
-   MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+   MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x17059
>;
};
 
@@ -409,6 +409,7 @@
MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17070
MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17070
MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17070
+   MX6QDL_PAD_GPIO_1__GPIO1_IO01  0x1b0b0
>;
};
 
-- 
2.7.4

RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module

[Stephen Boyd]

Quoting Aisheng Dong (2020-06-17 18:58:51)
> > From: Anson Huang 
> > > > +obj-$(CONFIG_MXC_CLK_SCU) += mxc-clk-scu.o
> > >
> > > Like i.MX pinctrl, I'm not sure if it's really necessary to build core
> > > libraries as modules. Probably the simplest way is only building
> > > platform drivers part as module. And leave those core libraries built in 
> > > kernel.
> > > This may make the code a bit cleaner.
> > >
> > 
> > Will discuss this with Linaro guys about it, previous requirement I 
> > received is all
> > SoC specific modules need to be built as module.
> > 
> 
> Okay. AFAIK it's not conflict.
> You still make drivers into modules.
> Only difference is for those common libraries part, we don't convert them 
> into module
> Which is less meaningless.
>  

What is the benefit of making the core part of the SoC driver not a
module? From the module perspective it should be perfectly fine to make
it a module as well, and then depmod will sort out loading modules in
the right order.

This is for android right?

Re: [PATCH][next] scsi: ufs: ufs-exynos: fix spelling mistake "pa_granularty" -> "pa_granularity"

[Martin K. Petersen]

On Wed, 17 Jun 2020 09:49:11 +0100, Colin King wrote:

> There is a spelling mistake in a dev_warn message. Fix it.

Applied to 5.9/scsi-queue, thanks!

[1/1] scsi: ufs: ufs-exynos: Fix spelling mistake "pa_granularty" -> 
"pa_granularity"
  https://git.kernel.org/mkp/scsi/c/393403efc360

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH V2 1/9] clk: composite: Export clk_hw_register_composite()

[Stephen Boyd]

Quoting Anson Huang (2020-06-09 00:32:05)
> Export clk_hw_register_composite() to support user built as module.
> 
> ERROR: modpost: "clk_hw_register_composite" [drivers/clk/imx/mxc-clk.ko] 
> undefined!

Get rid of these messages below. We don't care that make modules failed.

> scripts/Makefile.modpost:111: recipe for target 'Module.symvers' failed
> make[1]: *** [Module.symvers] Error 1
> make[1]: *** Deleting file 'Module.symvers'
> Makefile:1384: recipe for target 'modules' failed
> make: *** [modules] Error 2
> 
> Signed-off-by: Anson Huang 

Otherwise

Reviewed-by: Stephen Boyd 

Re: [PATCH][next] net/sched: cls_u32: Use struct_size() in kzalloc()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Thu, 18 Jun 2020 09:53:42 -0500

> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH v2 2/2] soc: mediatek: devapc: add devapc-mt6873 driver

[Neal Liu]

Hi Chun-Kuang,

Thanks for your quick feedback.

On Sat, 2020-06-20 at 00:25 +0800, Chun-Kuang Hu wrote:
> Hi, Neal:
> 
> Neal Liu  於 2020年6月19日 週五 下午6:01寫道：
> >
> > MT6873 bus frabric provides TrustZone security support and data
> > protection to prevent slaves from being accessed by unexpected
> > masters.
> > The security violations are logged and sent to the processor for
> > further analysis or countermeasures.
> >
> > Any occurrence of security violation would raise an interrupt, and
> > it will be handled by devapc-mt6873 driver. The violation
> > information is printed in order to find the murderer.
> >
> > Signed-off-by: Neal Liu 
> > ---
> 
> [snip]
> 
> > +
> > +/*
> > + * mtk_devapc_pd_get - get devapc pd_types of register address.
> > + *
> > + * Returns the value of reg addr
> > + */
> > +static void __iomem *mtk_devapc_pd_get(struct mtk_devapc_context 
> > *devapc_ctx,
> > +  int slave_type,
> > +  enum DEVAPC_PD_REG_TYPE pd_reg_type,
> > +  u32 index)
> > +{
> > +   struct mtk_devapc_vio_info *vio_info = devapc_ctx->soc->vio_info;
> > +   u32 slave_type_num = devapc_ctx->soc->slave_type_num;
> > +   const u32 *devapc_pds = devapc_ctx->soc->devapc_pds;
> 
> devapc_pds = mt6873_devapc_pds;

Are you saying all platform related variables & functions should assign
& call it directly in this common flow?
I don't think it's a good idea to go backwards since we already extract
the common out of it.

> 
> 
> > +   void __iomem *reg;
> > +
> > +   if (!devapc_pds)
> 
> Never happen.
> 
> > +   return NULL;
> > +
> > +   if ((slave_type < slave_type_num &&
> > +index < vio_info->vio_mask_sta_num[slave_type]) &&
> > +   pd_reg_type < PD_REG_TYPE_NUM) {
> 
> Always true.
> 
> > +   reg = devapc_ctx->devapc_pd_base[slave_type] +
> > +   devapc_pds[pd_reg_type];
> > +
> > +   if (pd_reg_type == VIO_MASK || pd_reg_type == VIO_STA)
> > +   reg += 0x4 * index;
> > +
> > +   } else {
> > +   pr_err(PFX "Out Of Boundary, 
> > slave_type:0x%x/pd_reg_type:0x%x/index:0x%x\n",
> > +  slave_type, pd_reg_type, index);
> > +   return NULL;
> > +   }
> > +
> > +   return reg;
> > +}
> > +
> 
> [snip]
> 
> > +
> > +/*
> > + * start_devapc - initialize devapc status and start receiving interrupt
> > + *   while devapc violation is triggered.
> > + */
> > +static void start_devapc(struct mtk_devapc_context *devapc_ctx)
> > +{
> > +   u32 slave_type_num = devapc_ctx->soc->slave_type_num;
> > +   const struct mtk_device_info **device_info;
> > +   const struct mtk_device_num *ndevices;
> > +   void __iomem *pd_vio_shift_sta_reg;
> > +   void __iomem *pd_apc_con_reg;
> > +   int slave_type, i, vio_idx, index;
> > +   u32 vio_shift_sta;
> > +
> > +   ndevices = devapc_ctx->soc->ndevices;
> 
> ndevices = mtk6873_devices_num;
> 
> 
> > +
> > +   device_info = devapc_ctx->soc->device_info;
> > +
> > +   for (slave_type = 0; slave_type < slave_type_num; slave_type++) {
> > +   pd_apc_con_reg = mtk_devapc_pd_get(devapc_ctx, slave_type,
> > +  APC_CON, 0);
> > +   pd_vio_shift_sta_reg = mtk_devapc_pd_get(devapc_ctx, 
> > slave_type,
> > +VIO_SHIFT_STA, 0);
> > +
> > +   if (!pd_apc_con_reg || !pd_vio_shift_sta_reg || 
> > !device_info)
> > +   return;
> > +
> > +   /* Clear DEVAPC violation status */
> > +   writel(BIT(31), pd_apc_con_reg);
> > +
> > +   /* Clear violation shift status */
> > +   vio_shift_sta = readl(pd_vio_shift_sta_reg);
> > +   if (vio_shift_sta)
> > +   writel(vio_shift_sta, pd_vio_shift_sta_reg);
> > +
> > +   /* Clear type 2 violation status */
> > +   check_type2_vio_status(devapc_ctx, slave_type, _idx, 
> > );
> > +
> > +   /* Clear violation status */
> > +   for (i = 0; i < ndevices[slave_type].vio_slave_num; i++) {
> > +   vio_idx = device_info[slave_type][i].vio_index;
> > +   if ((check_vio_status(devapc_ctx, slave_type, 
> > vio_idx)
> > + == VIOLATION_TRIGGERED) &&
> > +clear_vio_status(devapc_ctx, slave_type,
> > + vio_idx)) {
> > +   pr_warn(PFX "Clear vio status failed, 
> > slave_type:0x%x, vio_index:0x%x\n",
> > +   slave_type, vio_idx);
> > +
> > +   index = i;
> > +   mtk_devapc_dump_vio_dbg(devapc_ctx, 
> > 

Re: [PATCH][next] taprio: Use struct_size() in kzalloc()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Thu, 18 Jun 2020 09:46:48 -0500

> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes. Also, remove unnecessary
> variable _size_.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied, thank you.

Re: [PATCH][next] tipc: Use struct_size() helper

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Thu, 18 Jun 2020 08:35:00 -0500

> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied, thank you.

[PATCH net-next 1/2] indirect_call_wrapper: extend indirect wrapper to support up to 4 calls

[Brian Vazquez]

There are many places where 2 annotations are not enough. This patch
adds INDIRECT_CALL_3 and INDIRECT_CALL_4 to cover such cases.

Signed-off-by: Brian Vazquez 
---
 include/linux/indirect_call_wrapper.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/indirect_call_wrapper.h 
b/include/linux/indirect_call_wrapper.h
index 00d7e8e919c6..54c02c84906a 100644
--- a/include/linux/indirect_call_wrapper.h
+++ b/include/linux/indirect_call_wrapper.h
@@ -23,6 +23,16 @@
likely(f == f2) ? f2(__VA_ARGS__) : \
  INDIRECT_CALL_1(f, f1, __VA_ARGS__);  \
})
+#define INDIRECT_CALL_3(f, f3, f2, f1, ...)
\
+   ({  
\
+   likely(f == f3) ? f3(__VA_ARGS__) : 
\
+ INDIRECT_CALL_2(f, f2, f1, __VA_ARGS__);  
\
+   })
+#define INDIRECT_CALL_4(f, f4, f3, f2, f1, ...)
\
+   ({  
\
+   likely(f == f4) ? f4(__VA_ARGS__) : 
\
+ INDIRECT_CALL_3(f, f3, f2, f1, __VA_ARGS__);  
\
+   })
 
 #define INDIRECT_CALLABLE_DECLARE(f)   f
 #define INDIRECT_CALLABLE_SCOPE
@@ -30,6 +40,8 @@
 #else
 #define INDIRECT_CALL_1(f, f1, ...) f(__VA_ARGS__)
 #define INDIRECT_CALL_2(f, f2, f1, ...) f(__VA_ARGS__)
+#define INDIRECT_CALL_3(f, f3, f2, f1, ...) f(__VA_ARGS__)
+#define INDIRECT_CALL_4(f, f4, f3, f2, f1, ...) f(__VA_ARGS__)
 #define INDIRECT_CALLABLE_DECLARE(f)
 #define INDIRECT_CALLABLE_SCOPEstatic
 #endif
-- 
2.27.0.111.gc72c7da667-goog

[PATCH net-next 2/2] ipv6: fib6: avoid indirect calls from fib6_rule_lookup

[Brian Vazquez]

It was reported that a considerable amount of cycles were spent on the
expensive indirect calls on fib6_rule_lookup. This patch introduces an
inline helper called pol_route_func that uses the indirect_call_wrappers
to avoid the indirect calls.

This patch saves around 50ns per call.

Performance was measured on the receiver by checking the amount of
syncookies that server was able to generate under a synflood load.

Traffic was generated using trafgen[1] which was pushing around 1Mpps on
a single queue. Receiver was using only one rx queue which help to
create a bottle neck and make the experiment rx-bounded.

These are the syncookies generated over 10s from the different runs:

Whithout the patch:
TcpExtSyncookiesSent35537490.0
TcpExtSyncookiesSent35508950.0
TcpExtSyncookiesSent35538450.0
TcpExtSyncookiesSent35410500.0
TcpExtSyncookiesSent35399210.0
TcpExtSyncookiesSent35576590.0
TcpExtSyncookiesSent35268120.0
TcpExtSyncookiesSent35361210.0
TcpExtSyncookiesSent35299630.0
TcpExtSyncookiesSent35363190.0

With the patch:
TcpExtSyncookiesSent36117860.0
TcpExtSyncookiesSent35966820.0
TcpExtSyncookiesSent36068780.0
TcpExtSyncookiesSent35995640.0
TcpExtSyncookiesSent36013040.0
TcpExtSyncookiesSent36092490.0
TcpExtSyncookiesSent36174370.0
TcpExtSyncookiesSent36087650.0
TcpExtSyncookiesSent36202050.0
TcpExtSyncookiesSent36018950.0

Without the patch the average is 354263 pkt/s or 2822 ns/pkt and with
the patch the average is 360738 pkt/s or 2772 ns/pkt which gives an
estimate of 50 ns per packet.

[1] http://netsniff-ng.org/

Reported-by: Eric Dumazet 
Signed-off-by: Brian Vazquez 
Cc: Luigi Rizzo 
---
 include/net/ip6_fib.h | 36 
 net/ipv6/fib6_rules.c |  9 ++---
 net/ipv6/ip6_fib.c|  3 ++-
 net/ipv6/route.c  |  8 
 4 files changed, 48 insertions(+), 8 deletions(-)

diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 3f615a29766e..0ff7e97216d4 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_IPV6_MULTIPLE_TABLES
 #define FIB6_TABLE_HASHSZ 256
@@ -552,6 +553,41 @@ struct bpf_iter__ipv6_route {
 };
 #endif
 
+INDIRECT_CALLABLE_DECLARE(struct rt6_info *ip6_pol_route_output(struct net 
*net,
+struct fib6_table *table,
+struct flowi6 *fl6,
+const struct sk_buff *skb,
+int flags));
+INDIRECT_CALLABLE_DECLARE(struct rt6_info *ip6_pol_route_input(struct net *net,
+struct fib6_table *table,
+struct flowi6 *fl6,
+const struct sk_buff *skb,
+int flags));
+INDIRECT_CALLABLE_DECLARE(struct rt6_info *__ip6_route_redirect(struct net 
*net,
+struct fib6_table *table,
+struct flowi6 *fl6,
+const struct sk_buff *skb,
+int flags));
+INDIRECT_CALLABLE_DECLARE(struct rt6_info *ip6_pol_route_lookup(struct net 
*net,
+struct fib6_table *table,
+struct flowi6 *fl6,
+const struct sk_buff *skb,
+int flags));
+static inline struct rt6_info *pol_lookup_func(pol_lookup_t lookup,
+   struct net *net,
+   struct fib6_table *table,
+   struct flowi6 *fl6,
+   const struct sk_buff *skb,
+   int flags)
+{
+   return INDIRECT_CALL_4(lookup,
+  ip6_pol_route_lookup,
+  ip6_pol_route_output,
+  ip6_pol_route_input,
+  __ip6_route_redirect,
+  net, table, fl6, skb, flags);
+}
+
 #ifdef CONFIG_IPV6_MULTIPLE_TABLES
 static inline bool fib6_has_custom_rules(const struct net *net)
 {
diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c
index fafe556d21e0..6053ef851555 

Re: [PATCH -next] macvlan: Fix memleak in macvlan_changelink_sources

[David Miller]

From: Zheng Bin 
Date: Thu, 18 Jun 2020 21:26:29 +0800

> macvlan_changelink_sources
>   if (addr)
> ret = macvlan_hash_add_source(vlan, addr)
>   nla_for_each_attr(nla, head, len, rem)
> ret = macvlan_hash_add_source(vlan, addr)
> -->If fail, need to free previous malloc memory
> 
> Fixes: 79cf79abce71 ("macvlan: add source mode")
> Signed-off-by: Zheng Bin 

Bug fixes should never be submitted against net-next.

They should instead be submitted against 'net'.

Thank you.

Re: [tip: sched/urgent] sched: Fix RANDSTRUCT build fail

[Kees Cook]

On Wed, Jun 10, 2020 at 10:34:16AM -, tip-bot2 for Peter Zijlstra wrote:
> The following commit has been merged into the sched/urgent branch of tip:
> 
> Commit-ID: bfb9fbe0f7e70ec5c8e51ee55b6968d4dff14456
> Gitweb:
> https://git.kernel.org/tip/bfb9fbe0f7e70ec5c8e51ee55b6968d4dff14456
> Author:Peter Zijlstra 
> AuthorDate:Wed, 10 Jun 2020 12:14:09 +02:00
> Committer: Peter Zijlstra 
> CommitterDate: Wed, 10 Jun 2020 12:30:19 +02:00
> 
> sched: Fix RANDSTRUCT build fail
> 
> As a temporary build fix, the proper cleanup needs more work.
> 
> Reported-by: Guenter Roeck 
> Reported-by: Eric Biggers 
> Suggested-by: Eric Biggers 
> Suggested-by: Kees Cook 
> Fixes: a148866489fb ("sched: Replace rq::wake_list")
> Signed-off-by: Peter Zijlstra (Intel) 

Hi, can this please get sent to Linus before -rc2? With a148866489fb in
-rc1, all the CI with the GCC plugins installed have been failing their
all*config builds. This entered -next 9 days ago (and fixed the -next
builds), but Linus's tree is still failing:

https://kernelci.org/build/mainline/branch/master/kernel/v5.8-rc1-226-g4333a9b0b67b/
...
https://kernelci.org/build/mainline/branch/master/kernel/v5.8-rc1/

Thanks!

-Kees

> ---
>  include/linux/sched.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 57a5ce9..59caeb9 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -653,8 +653,10 @@ struct task_struct {
>   unsigned intptrace;
>  
>  #ifdef CONFIG_SMP
> - struct llist_node   wake_entry;
> - unsigned intwake_entry_type;
> + struct {
> + struct llist_node   wake_entry;
> + unsigned intwake_entry_type;
> + };
>   int on_cpu;
>  #ifdef CONFIG_THREAD_INFO_IN_TASK
>   /* Current CPU: */

-- 
Kees Cook

Re: [PATCH] hwmon: (dell-smm) Add Latitude 5480 to fan control whitelist

[Jeffrey Lin]

On Fri, 19 Jun 2020 14:18:21 +0200
Pali Rohár  wrote:

>On Thursday 18 June 2020 21:55:29 Jeffrey Lin wrote:
>> This allows manual PWM control without the BIOS fighting back on Dell
>> Latitude 5480.
>> 
>> Signed-off-by: Jeffrey Lin   
>
>If it is working fine on your machine, you can add my:

Yes, the below patch works on my machine.  dmesg reports "dell_smm_hwmon:
enabling support for setting automatic/manual fan control" and writing 1 to
/sys/class/hwmon/hwmon4/pwm1_enable allows pwmconfig/fancontrol full control.

>
>Acked-by: Pali Rohár 
>
>> ---
>>  drivers/hwmon/dell-smm-hwmon.c | 8 
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
>> index 16be012a95ed..ec448f5f2dc3 100644
>> --- a/drivers/hwmon/dell-smm-hwmon.c
>> +++ b/drivers/hwmon/dell-smm-hwmon.c
>> @@ -1187,6 +1187,14 @@ static struct dmi_system_id
>> i8k_whitelist_fan_control[] __initdata = { },
>>  .driver_data = (void
>> *)_fan_control_data[I8K_FAN_34A3_35A3], },
>> +{
>> +.ident = "Dell Latitude 5480",
>> +.matches = {
>> +DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
>> +DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Latitude 5480"),
>> +},
>> +.driver_data = (void
>> *)_fan_control_data[I8K_FAN_34A3_35A3],
>> +},
>>  {
>>  .ident = "Dell Latitude E6440",
>>  .matches = {
>> -- 
>> 2.27.0
>>   



pgp2J7452rPbc.pgp
Description: OpenPGP digital signature

[PATCH] scsi: gdth: remove unnecessary iounmap()

[Jing Xiangfeng]

When initialization of ioremap() fails, it is not needed to do
iounmap(). Remove this iounmap.

Signed-off-by: Jing Xiangfeng 
---
 drivers/scsi/gdth.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index fe03410268e6..8f077d316e8b 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -639,7 +639,6 @@ static int gdth_init_pci(struct pci_dev *pdev, gdth_pci_str 
*pcistr,
 ha->brd = ioremap(pcistr->dpmem, sizeof(gdt6c_dpram_str));
 if (ha->brd == NULL) {
 printk("GDT-PCI: Initialization error (DPMEM remap error)\n");
-iounmap(ha->brd);
 return 0;
 }
 /* check and reset interface area */
-- 
2.17.1

Re: [PATCH v2] net: macb: undo operations in case of failure

[David Miller]

From: Claudiu Beznea 
Date: Thu, 18 Jun 2020 11:37:40 +0300

> Undo previously done operation in case macb_phylink_connect()
> fails. Since macb_reset_hw() is the 1st undo operation the
> napi_exit label was renamed to reset_hw.
> 
> Fixes: 7897b071ac3b ("net: macb: convert to phylink")
> Signed-off-by: Claudiu Beznea 

Applied and queued up for -stable, thank you.

Re: [PATCH 7/8] scsi: storvsc: Introduce the per-storvsc_device spinlock

[Martin K. Petersen]

Andrea,

>> This patch should go via the hyperv tree because a later patch is
>> dependent on it. It requires and ack from SCSI maintainers though.

Looks OK to me.

Acked-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH net] bridge: uapi: mrp: Fix MRP_PORT_ROLE

[David Miller]

Please send networking patches for review to net...@vger.kernel.org

Thank you.

Re: [PATCH net 0/3] rxrpc: Performance drop fix and other fixes

[David Miller]

From: David Howells 
Date: Thu, 18 Jun 2020 08:50:15 +0100

> 
> Here are three fixes for rxrpc:
> 
>  (1) Fix a trace symbol mapping.  It doesn't seem to let you map to "".
> 
>  (2) Fix the handling of the remote receive window size when it increases
>  beyond the size we can support for our transmit window.
> 
>  (3) Fix a performance drop caused by retransmitted packets being
>  accidentally marked as already ACK'd.
> 
> The patches are tagged here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-fixes-20200618

Pulled, thanks David.

[PATCH resend] net: cxgb4: fix return error value in t4_prep_fw

[Li Heng]

t4_prep_fw goto bye tag with positive return value when something
bad happened and which can not free resource in adap_init0.
so fix it to return negative value.

Fixes: 16e47624e76b ("cxgb4: Add new scheme to update T4/T5 firmware")
Reported-by: Hulk Robot 
Signed-off-by: Li Heng 
Signed-off-by: Jakub Kicinski 
---

resent with netdev cced

---
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c 
b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 2a3480f..9121cef 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -3493,7 +3493,7 @@ int t4_prep_fw(struct adapter *adap, struct fw_info 
*fw_info,
drv_fw = _info->fw_hdr;

/* Read the header of the firmware on the card */
-   ret = -t4_read_flash(adap, FLASH_FW_START,
+   ret = t4_read_flash(adap, FLASH_FW_START,
sizeof(*card_fw) / sizeof(uint32_t),
(uint32_t *)card_fw, 1);
if (ret == 0) {
@@ -3522,8 +3522,8 @@ int t4_prep_fw(struct adapter *adap, struct fw_info 
*fw_info,
   should_install_fs_fw(adap, card_fw_usable,
be32_to_cpu(fs_fw->fw_ver),
be32_to_cpu(card_fw->fw_ver))) {
-   ret = -t4_fw_upgrade(adap, adap->mbox, fw_data,
-fw_size, 0);
+   ret = t4_fw_upgrade(adap, adap->mbox, fw_data,
+   fw_size, 0);
if (ret != 0) {
dev_err(adap->pdev_dev,
"failed to install firmware: %d\n", ret);
@@ -3554,7 +3554,7 @@ int t4_prep_fw(struct adapter *adap, struct fw_info 
*fw_info,
FW_HDR_FW_VER_MICRO_G(c), FW_HDR_FW_VER_BUILD_G(c),
FW_HDR_FW_VER_MAJOR_G(k), FW_HDR_FW_VER_MINOR_G(k),
FW_HDR_FW_VER_MICRO_G(k), FW_HDR_FW_VER_BUILD_G(k));
-   ret = EINVAL;
+   ret = -EINVAL;
goto bye;
}

--
2.7.4

Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

[Rick Lindsley]

On 6/19/20 3:23 PM, Tejun Heo wrote:


Spending 5 minutes during boot creating sysfs objects doesn't seem like a
particularly good solution and I don't know whether anyone else would
experience similar issues. Again, not necessarily against improving the
scalability of kernfs code but the use case seems a bit out there.


Creating sysfs objects is not a new "solution".  We already do it, and it can 
take over an hour on a machine with 64TB of memory.  We're not *adding* this ... we're 
*improving* something that has been around for a long time.


They are used for hotplugging and partitioning memory. The size of the
segments (and thus the number of them) is dictated by the underlying
hardware.


This sounds so bad. There gotta be a better interface for that, right?


Again; this is not new.  Easily changing the state of devices by writing new 
values into kernfs is one of the reasons kernfs exists.

echo 0 > /sys/devices//system/memory/memory10374/online

and boom - you've taken memory chunk 10374 offline.

These changes are not just a whim.  I used lockstat to measure contention during boot.  
The addition of 250,000 "devices" in parallel created tremendous contention on 
the kernfs_mutex and, it appears, on one of the directories within it where memory nodes 
are created.  Using a mutex means that the details of that mutex must bounce around all 
the cpus ... did I mention 1500+ cpus?  A whole lot of thrash ...

These patches turn that mutex into a rw semaphore, and any thread checking for 
the mere existence of something can get by with a read lock. lockstat showed 
that about 90% of the mutex contentions were in a read path and only 10% in a 
write path.  Switching to a rw semaphore meant that 90% of the time there was 
no waiting and the thread proceeded with its caches intact.  Total time spent 
waiting on either read or write decreased by 75%, and should scale much better 
with subsequent hardware upgrades.

With contention on this particular data structure reduced, we saw thrash on 
related control structures decrease markedly too.  The contention for the 
lockref taken in dput dropped 66% and, likely due to reduced thrash, the time 
used waiting for that structure dropped 99%.

Rick

Re: [PATCH 0/6] Add Microchip MCP25XXFD CAN driver

[Manivannan Sadhasivam]

On Thu, Jun 18, 2020 at 02:25:33PM +0530, Manivannan Sadhasivam wrote:
> Hi,
> 
> On 0611, Marc Kleine-Budde wrote:
> > On 6/10/20 9:44 AM, Manivannan Sadhasivam wrote:
> > > Hello,
> > > 
> > > This series adds CAN network driver support for Microchip MCP25XXFD CAN
> > > Controller with MCP2517FD as the target controller version. This series is
> > > mostly inspired (or taken) from the previous iterations posted by Martin 
> > > Sperl.
> > > I've trimmed down the parts which are not necessary for the initial 
> > > version
> > > to ease review. Still the series is relatively huge but I hope to get some
> > > reviews (post -rcX ofc!).
> > > 
> > > Link to the origial series posted by Martin:
> > > https://www.spinics.net/lists/devicetree/msg284462.html
> > > 
> > > I've not changed the functionality much but done some considerable amount 
> > > of
> > > cleanups and also preserved the authorship of Martin for all the patches 
> > > he has
> > > posted earlier. This series has been tested on 96Boards RB3 platform by 
> > > myself
> > > and Martin has tested the previous version on Rpi3 with external MCP2517FD
> > > controller.
> > 
> > I initially started looking at Martin's driver and it was not using several
> > modern CAN driver infrastructures. I then posted some cleanup patches but 
> > Martin
> > was not working on the driver any more. Then I decided to rewrite the 
> > driver,
> > that is the one I'm hoping to mainline soon.
> > 
> 
> So how should we proceed from here? It is okay for me to work on adding some
> features and also fixing the issues you've reported so far. But I want to 
> reach
> a consensus before moving forward.
> 
> If you think that it makes sense to go with your set of patches, then I need 
> an
> estimate on when you'll post the first revision.
> 

Ping!

> > Can you give it a try?
> > 
> > https://github.com/marckleinebudde/linux/commits/v5.6-rpi/mcp25xxfd-20200607-41
> > 
> 
> Sure thing. Will do.
> 
> Thanks,
> Mani
> 
> > Marc
> > 
> > -- 
> > Pengutronix e.K. | Marc Kleine-Budde   |
> > Embedded Linux   | https://www.pengutronix.de  |
> > Vertretung West/Dortmund | Phone: +49-231-2826-924 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |

Re: [PATCH v1 4/4] of: platform: Batch fwnode parsing when adding all top level devices

[Saravana Kannan]

On Fri, Jun 19, 2020 at 1:07 PM Saravana Kannan  wrote:
>
> I think instead of deferred_probe_work_func() moving the device to the
> end of the dpm_list, I think the device probing successfully is what
> should move it to the end of the dpm_list. That way, the dpm_list is
> actually ordered by when the devices become functional and not the
> random order in DT or random probe order which can get pretty
> convoluted with multiple deferred probes. This feels right and will
> make suspend/resume more robust against DT ordering -- but I'm not
> sure what other wide ranging impact this has for other platforms.

Geert,

If you want to play around with a potential fix to test my hypothesis,
I think it's just adding this one line to driver_bound():

klist_add_tail(>p->knode_driver, >driver->p->klist_devices);
device_links_driver_bound(dev);
+device_pm_move_to_tail(dev);

device_pm_check_callbacks(dev);


-Saravana

Re: [PATCH v3 0/3] Add LT9611 DSI to HDMI bridge

[John Stultz]

On Wed, Jun 17, 2020 at 4:00 AM Vinod Koul  wrote:
>
> This series adds driver and bindings for Lontium LT9611 bridge chip which
> takes MIPI DSI as input and HDMI as output.
>
> This chip can be found in 96boards RB3 platform [1] commonly called DB845c.
>
> [1]: https://www.96boards.org/product/rb3-platform/
>
> Changes in v3:
>  - fix kbuild reported error
>  - rebase on v5.8-rc1
>
> Changes in v2:
>  - Add acks by Rob
>  - Fix comments reported by Emil and rename the file to lontium-lt9611.c
>  - Fix comments reported by Laurent on binding and driver
>  - Add HDMI audio support
>
> Vinod Koul (3):
>   dt-bindings: vendor-prefixes: Add Lontium vendor prefix
>   dt-bindings: display: bridge: Add documentation for LT9611
>   drm/bridge: Introduce LT9611 DSI to HDMI bridge

Hey Vinod,
  Thanks for pushing these!
I know same-company tags aren't super valuable, but I'm actively using
these patches for HDMI/audio support on the db845c w/ AOSP.

So for what it's worth, for the series:
Tested-by: John Stultz 

thanks
-john

Re: [PATCH V7 3/4] clk: qcom: Add DT bindings for ipq6018 apss clock controller

[Stephen Boyd]

Quoting Sivaprakash Murugesan (2020-06-06 03:55:06)
> Add dt-binding for ipq6018 apss clock controller
> 
> Signed-off-by: Sivaprakash Murugesan 
> ---

Please pick up Rob's tag when resending this.

KINDEST MESSAGE.

[Tofil Bama]

Dear,

My name is Mr Alif Tomar, I am the Bill and Exchange (assistant)
Manager of Bank of Africa Ouagadougou, Burkina Faso. In my department
I discovered an abandoned sum of eighteen million three hundred
thousand United State of American dollars (18.3MILLION USA DOLLARS) in
an account that belongs to one of our foreign customer who died in
airline that crashed on 4th October 2001.

Since I got information about his death I have been expecting his next
of kin to come over and claim his money because we can not release it
unless somebody applies for it as the next of kin or relation to the
deceased as indicated in our banking guidelines, but unfortunately we
learnt that all his supposed next of kin or relation died alongside
with him in the plane crash leaving nobody behind for the claim. It is
therefore upon this discovery that I decided to make this business
proposal to you and release the money to you as next of kin or
relation to the deceased for safety and subsequent disbursement since
nobody is coming for it and I don't want the money to go into the bank
treasury as unclaimed bill.

You will be entitled with 40% of the total sum while 60% will be for
me after which I will visit your Country to invest my own share when
the fund is successfully transferred into your account, Please I would
like you to keep this transaction confidential and as a top secret as
you may wish to know that I am a bank official.

Yours sincerely,
Mr Alif Tomar.

[PATCH v1 1/2] spi: spi-geni-qcom: Simplify setup_fifo_xfer()

[Stephen Boyd]

The definition of SPI_FULL_DUPLEX (3) is really SPI_TX_ONLY (1) ORed
with SPI_RX_ONLY (2). Let's drop the define and simplify the code here a
bit by collapsing the setting of 'm_cmd' into conditions that are the
same.

This is a non-functional change, just cleanup to consolidate code.

Reviewed-by: Douglas Anderson 
Signed-off-by: Stephen Boyd 
---
 drivers/spi/spi-geni-qcom.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 0c534d151370..d8f03ffb8594 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -51,7 +51,6 @@
 /* M_CMD OP codes for SPI */
 #define SPI_TX_ONLY1
 #define SPI_RX_ONLY2
-#define SPI_FULL_DUPLEX3
 #define SPI_TX_RX  7
 #define SPI_CS_ASSERT  8
 #define SPI_CS_DEASSERT9
@@ -353,12 +352,6 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
 
mas->tx_rem_bytes = 0;
mas->rx_rem_bytes = 0;
-   if (xfer->tx_buf && xfer->rx_buf)
-   m_cmd = SPI_FULL_DUPLEX;
-   else if (xfer->tx_buf)
-   m_cmd = SPI_TX_ONLY;
-   else if (xfer->rx_buf)
-   m_cmd = SPI_RX_ONLY;
 
spi_tx_cfg &= ~CS_TOGGLE;
 
@@ -369,12 +362,14 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
len &= TRANS_LEN_MSK;
 
mas->cur_xfer = xfer;
-   if (m_cmd & SPI_TX_ONLY) {
+   if (xfer->tx_buf) {
+   m_cmd |= SPI_TX_ONLY;
mas->tx_rem_bytes = xfer->len;
writel(len, se->base + SE_SPI_TX_TRANS_LEN);
}
 
-   if (m_cmd & SPI_RX_ONLY) {
+   if (xfer->rx_buf) {
+   m_cmd |= SPI_RX_ONLY;
writel(len, se->base + SE_SPI_RX_TRANS_LEN);
mas->rx_rem_bytes = xfer->len;
}
-- 
Sent by a computer, using git, on the internet

[PATCH v1 0/2] Some small spi geni cleanups

[Stephen Boyd]

To follow onto Doug's latest spi geni series[1] this simplifies and
reduces the code a little more.

[1] https://lore.kernel.org/r/20200618150626.237027-1-diand...@chromium.org

Stephen Boyd (2):
  spi: spi-geni-qcom: Simplify setup_fifo_xfer()
  spi: spi-geni-qcom: Don't set {tx,rx}_rem_bytes unnecessarily

 drivers/spi/spi-geni-qcom.c | 55 +
 1 file changed, 25 insertions(+), 30 deletions(-)


base-commit: 7ba9bdcb91f694b0eaf486a825afd9c2d99532b7
-- 
Sent by a computer, using git, on the internet

[PATCH v1 2/2] spi: spi-geni-qcom: Don't set {tx,rx}_rem_bytes unnecessarily

[Stephen Boyd]

We only need to test for these counters being non-zero when we see the
end of a transfer. If we're doing a CS change then they will already be
zero.  This implies that we don't need to set these to 0 if we're
cancelling an in flight transfer too, because we only care to test these
counters when the 'DONE' bit is set in the hardware and we've set them
to non-zero for a transfer.

This is a non-functional change, just cleanup to consolidate code.

Reviewed-by: Douglas Anderson 
Signed-off-by: Stephen Boyd 
---
 drivers/spi/spi-geni-qcom.c | 42 ++---
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index d8f03ffb8594..5b1dca1fff79 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -122,7 +122,6 @@ static void handle_fifo_timeout(struct spi_master *spi,
reinit_completion(>cancel_done);
writel(0, se->base + SE_GENI_TX_WATERMARK_REG);
mas->cur_xfer = NULL;
-   mas->tx_rem_bytes = mas->rx_rem_bytes = 0;
geni_se_cancel_m_cmd(se);
spin_unlock_irq(>lock);
 
@@ -513,29 +512,30 @@ static irqreturn_t geni_spi_isr(int irq, void *data)
if (mas->cur_xfer) {
spi_finalize_current_transfer(spi);
mas->cur_xfer = NULL;
+   /*
+* If this happens, then a CMD_DONE came before all the
+* Tx buffer bytes were sent out. This is unusual, log
+* this condition and disable the WM interrupt to
+* prevent the system from stalling due an interrupt
+* storm.
+*
+* If this happens when all Rx bytes haven't been
+* received, log the condition. The only known time
+* this can happen is if bits_per_word != 8 and some
+* registers that expect xfer lengths in num spi_words
+* weren't written correctly.
+*/
+   if (mas->tx_rem_bytes) {
+   writel(0, se->base + SE_GENI_TX_WATERMARK_REG);
+   dev_err(mas->dev, "Premature done. tx_rem = %d 
bpw%d\n",
+   mas->tx_rem_bytes, 
mas->cur_bits_per_word);
+   }
+   if (mas->rx_rem_bytes)
+   dev_err(mas->dev, "Premature done. rx_rem = %d 
bpw%d\n",
+   mas->rx_rem_bytes, 
mas->cur_bits_per_word);
} else {
complete(>cs_done);
}
-
-   /*
-* If this happens, then a CMD_DONE came before all the Tx
-* buffer bytes were sent out. This is unusual, log this
-* condition and disable the WM interrupt to prevent the
-* system from stalling due an interrupt storm.
-* If this happens when all Rx bytes haven't been received, log
-* the condition.
-* The only known time this can happen is if bits_per_word != 8
-* and some registers that expect xfer lengths in num spi_words
-* weren't written correctly.
-*/
-   if (mas->tx_rem_bytes) {
-   writel(0, se->base + SE_GENI_TX_WATERMARK_REG);
-   dev_err(mas->dev, "Premature done. tx_rem = %d bpw%d\n",
-   mas->tx_rem_bytes, mas->cur_bits_per_word);
-   }
-   if (mas->rx_rem_bytes)
-   dev_err(mas->dev, "Premature done. rx_rem = %d bpw%d\n",
-   mas->rx_rem_bytes, mas->cur_bits_per_word);
}
 
if (m_irq & M_CMD_CANCEL_EN)
-- 
Sent by a computer, using git, on the internet

Re: [PATCH 6/5] spi: spi-geni-qcom: Simplify setup_fifo_xfer()

[Stephen Boyd]

Quoting Doug Anderson (2020-06-18 17:40:59)
> On Thu, Jun 18, 2020 at 4:40 PM Stephen Boyd  wrote:
> > @@ -373,12 +366,14 @@ static void setup_fifo_xfer(struct spi_transfer *xfer,
> > len &= TRANS_LEN_MSK;
> >
> > mas->cur_xfer = xfer;
> > -   if (m_cmd & SPI_TX_ONLY) {
> > +   if (xfer->tx_buf) {
> > +   m_cmd |= SPI_TX_ONLY;
> > mas->tx_rem_bytes = xfer->len;
> > writel(len, se->base + SE_SPI_TX_TRANS_LEN);
> > }
> >
> > -   if (m_cmd & SPI_RX_ONLY) {
> > +   if (xfer->rx_buf) {
> > +   m_cmd |= SPI_RX_ONLY;
> 
> If you're going to touch this, could you change "SPI_TX_ONLY" to
> "SPI_TX_ENABLED" and "SPI_RX_ONLY" to 'SPI_RX_ENABLED".  It felt
> really weird to me that if you had full duplex you were setting
> "RX_ONLY" and "TX_ONLY".

I agree, except in the register documentation it is called "TX only",
"RX only" and "Full-Duplex". So I'd rather leave it alone.

> 
> Other than that, your change is nice and cleans things up a bit, so
> even if you don't do the extra cleanup:
> 
> Reviewed-by: Douglas Anderson 
> 
> 

Thanks.

Re: [PATCH] scsi: target: tcmu: Call flush_dcache_page() with proper page struct

[kernel test robot]

Hi Henry,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on scsi/for-next v5.8-rc1 next-20200618]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Henry-Willard/scsi-target-tcmu-Call-flush_dcache_page-with-proper-page-struct/20200620-024740
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=xtensa 

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

All warnings (new ones prefixed by >>, old ones prefixed by <<):

In file included from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from drivers/target/target_core_user.c:9:
include/linux/scatterlist.h: In function 'sg_set_buf':
arch/xtensa/include/asm/page.h:193:9: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
193 |  ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
| ^~
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
|  ^
include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
143 |  BUG_ON(!virt_addr_valid(buf));
|  ^~
arch/xtensa/include/asm/page.h:201:32: note: in expansion of macro 'pfn_valid'
201 | #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
|^
include/linux/scatterlist.h:143:10: note: in expansion of macro 
'virt_addr_valid'
143 |  BUG_ON(!virt_addr_valid(buf));
|  ^~~
In file included from ./arch/xtensa/include/generated/asm/bug.h:1,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/preempt.h:5,
from ./arch/xtensa/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from drivers/target/target_core_user.c:9:
include/linux/dma-mapping.h: In function 'dma_map_resource':
arch/xtensa/include/asm/page.h:193:9: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
193 |  ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
| ^~
include/asm-generic/bug.h:144:27: note: in definition of macro 'WARN_ON_ONCE'
144 |  int __ret_warn_once = !!(condition);|
   ^
include/linux/dma-mapping.h:352:19: note: in expansion of macro 'pfn_valid'
352 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
|   ^
In file included from include/linux/mm_types_task.h:16,
from include/linux/mm_types.h:5,
from include/linux/mmzone.h:21,
from include/linux/gfp.h:6,
from include/linux/umh.h:4,
from include/linux/kmod.h:9,
from include/linux/module.h:16,
from drivers/target/target_core_user.c:10:
drivers/target/target_core_user.c: In function 'tcmu_flush_dcache_range':
arch/xtensa/include/asm/page.h:193:9: warning: comparison of unsigned 
expression >= 0 is always true [-Wtype-limits]
193 |  ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
| ^~
arch/xtensa/include/asm/page.h:201:32: note: in expansion of macro 'pfn_valid'
201 | #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
|^
drivers/target/target_core_user.c:605:7: note: in expansion of macro 
'virt_addr_valid'
605 |   if (virt_addr_valid(start))
|   ^~~
>> drivers/target/target_core_user.c:600:15: warning: variable 'pg' set but not 
>> used [-Wunused-but-set-variable]
600 |  struct page *pg;
|   ^~

vim +/pg +600 drivers/target/target_core_user.c

   595  
   596  static inline void tcmu_flush_dcache_range(void *vaddr, size_t size)
   597  {
   598  unsigned long offset = offset_in_page(vaddr);
   599  void *start = vaddr - offset;
 > 600  struct page *pg;
   601  
   602  size = round_up(size+offset, PAGE_SIZE);
   603  
   604  while (size) {
   605  if (virt_addr_valid(start))
   606  pg = virt_to_page(start);
   607  else if (is_vmalloc_addr(start))
   608  pg = vmalloc_to_page(start);
   609  else
   610  break;
   611  
   612  flush_dcache_page(pg);
   613  

[PATCH V2] drivers/block: Use kobj_to_dev() API

[Wang Qing]

Use kobj_to_dev() API instead of container_of().

Signed-off-by: Wang Qing 
---
 drivers/block/virtio_blk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 9d21bf0..c808405
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -630,7 +630,7 @@ static struct attribute *virtblk_attrs[] = {
 static umode_t virtblk_attrs_are_visible(struct kobject *kobj,
struct attribute *a, int n)
 {
-   struct device *dev = container_of(kobj, struct device, kobj);
+   struct device *dev = kobj_to_dev(kobj);
struct gendisk *disk = dev_to_disk(dev);
struct virtio_blk *vblk = disk->private_data;
struct virtio_device *vdev = vblk->vdev;
-- 
2.7.4

[PATCH] platform/chrome: cros_ec_typec: Make configure_mux static

[Prashant Malani]

Since cros_typec_configure_mux() is only used in cros-ec-typec,
it should be marked static.

Fixes: 7e7def15fa4b ("platform/chrome: cros_ec_typec: Add USB mux control")
Reported-by: kernel test robot 
Signed-off-by: Prashant Malani 
---
 drivers/platform/chrome/cros_ec_typec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_typec.c 
b/drivers/platform/chrome/cros_ec_typec.c
index 509fc761906b..1df1386f32e4 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -428,9 +428,9 @@ static int cros_typec_enable_dp(struct cros_typec_data 
*typec,
return typec_mux_set(port->mux, >state);
 }
 
-int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
-uint8_t mux_flags,
-struct ec_response_usb_pd_control_v2 *pd_ctrl)
+static int cros_typec_configure_mux(struct cros_typec_data *typec, int 
port_num,
+   uint8_t mux_flags,
+   struct ec_response_usb_pd_control_v2 *pd_ctrl)
 {
struct cros_typec_port *port = typec->ports[port_num];
enum typec_orientation orientation;
-- 
2.27.0.111.gc72c7da667-goog

RE: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI

[Alim Akhtar]

Hi Kishon,

> -Original Message-
> From: Alim Akhtar 
> Sent: 11 June 2020 20:49
> To: 'Kishon Vijay Abraham I' ; 'Martin K. Petersen'
> > >>
> > >> Applied [1,2,3,4,5,9] to 5.9/scsi-queue. The series won't show up
> > >> in my
> > > public
> > >> tree until shortly after -rc1 is released.
> > >>
> > > Thanks Martin,
> > > Hi Rob and Kishon/Vinod
> > > Can you please pickup dt-bindings and PHY driver respectively?
> >
> > You might have CC'ed me only for the PHY patch. I don't have the
> > dt-bindings in my inbox. Care to re-send what's missing again? This
> > will be merged after -rc1 is tagged.
> >

-rc1 is out, I do not see phy driver patch in your tree[1] yet, let me know if 
I am looking into right tree.
[1] -> git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git

Thanks! 

> Sure, will re-send this series.
> 
> > Thanks
> > Kishon

Re: [PATCH] i2c: mediatek: Add to support continuous mode

[Qii Wang]

On Fri, 2020-06-19 at 16:06 +0800, Qiangming Xia wrote:
> From: "qiangming.xia" 
> 
> Mediatek i2c controller support for continuous mode,
> it allow to transfer once multiple writing messages of equal length.
> For example, a slave need write a serial of non-continuous
> offset range in chip,e.g. writing offset 0,offset 2 and offset 4.
> Normally, it need three times i2c write operation. However,it can
> use once transfer to finish it by using continuous mode.
> 
> Change-Id: If06991e3fd32867bdeaacf15bb24864d5c5904d0
> Signed-off-by: Qiangming Xia 
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 67 +
>  1 file changed, 67 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index deef69e56906..76ec65d869f6 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -97,6 +97,7 @@ enum mtk_trans_op {
>   I2C_MASTER_WR = 1,
>   I2C_MASTER_RD,
>   I2C_MASTER_WRRD,
> + I2C_MASTER_CONTINUOUS_WR,
>  };
>  
>  enum I2C_REGS_OFFSET {
> @@ -846,6 +847,9 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> struct i2c_msg *msgs,
>   OFFSET_TRANSFER_LEN);
>   }
>   mtk_i2c_writew(i2c, I2C_WRRD_TRANAC_VALUE, OFFSET_TRANSAC_LEN);
> + } else if (i2c->op == I2C_MASTER_CONTINUOUS_WR) {
> + mtk_i2c_writew(i2c, msgs->len / num, OFFSET_TRANSFER_LEN);
> + mtk_i2c_writew(i2c, num, OFFSET_TRANSAC_LEN);
>   } else {
>   mtk_i2c_writew(i2c, msgs->len, OFFSET_TRANSFER_LEN);
>   mtk_i2c_writew(i2c, num, OFFSET_TRANSAC_LEN);
> @@ -896,6 +900,23 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> struct i2c_msg *msgs,
>   writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
>   }
>  
> + writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
> + writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
> + } else if (i2c->op == I2C_MASTER_CONTINUOUS_WR) {
> + writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
> + writel(I2C_DMA_CON_TX, i2c->pdmabase + OFFSET_CON);
> + wpaddr = dma_map_single(i2c->dev, msgs->buf,
> + msgs->len, DMA_TO_DEVICE);
> + if (dma_mapping_error(i2c->dev, wpaddr)) {
> + kfree(msgs->buf);
> + return -ENOMEM;
> + }
> +
> + if (i2c->dev_comp->support_33bits) {
> + reg_4g_mode = mtk_i2c_set_4g_mode(wpaddr);
> + writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
> + }
> +
>   writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
>   writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
>   } else {
> @@ -979,6 +1000,11 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> struct i2c_msg *msgs,
>msgs->len, DMA_FROM_DEVICE);
>  
>   i2c_put_dma_safe_msg_buf(dma_rd_buf, msgs, true);
> + } else if (i2c->op == I2C_MASTER_CONTINUOUS_WR) {
> + dma_unmap_single(i2c->dev, wpaddr,
> +  msgs->len, DMA_TO_DEVICE);
> +
> + kfree(msgs->buf);
>   } else {
>   dma_unmap_single(i2c->dev, wpaddr, msgs->len,
>DMA_TO_DEVICE);
> @@ -1009,6 +1035,9 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
>  {
>   int ret;
>   int left_num = num;
> + int i, j;
> + u8 *dma_multi_wr_buf;
> + struct i2c_msg multi_msg[1];
>   struct mtk_i2c *i2c = i2c_get_adapdata(adap);
>  
>   ret = mtk_i2c_clock_enable(i2c);
> @@ -1025,6 +1054,44 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
>   }
>   }
>  
> + if (num > 1) {
> + for (i = 0; i < num - 1; i++) {
> + if (!(msgs[i].flags & I2C_M_RD) && !(msgs[i+1].flags &
> + I2C_M_RD) && (msgs[i].addr == msgs[i+1].addr)
> + && (msgs[i].len == msgs[i+1].len)) {

if these conditions are not met, Can these transfers work?
 
> + continue;
> + } else
> + break;
> + }
> + if (i >= num - 1) {
> + i2c->op = I2C_MASTER_CONTINUOUS_WR;
> + j = 0;
> + dma_multi_wr_buf = kzalloc(msgs->len * num, GFP_KERNEL);
> + if (!dma_multi_wr_buf) {
> + ret =  -ENOMEM;
> + goto err_exit;
> + }
> + multi_msg->addr  = msgs->addr;
> + multi_msg->len   = msgs->len * num;
> + multi_msg->buf   = dma_multi_wr_buf;
> + multi_msg->flags  = 0;
> +  

Re: [PATCH v2 3/3] mm/shuffle: remove dynamic reconfiguration

[Dan Williams]

On Fri, Jun 19, 2020 at 5:59 AM David Hildenbrand  wrote:
>
> Commit e900a918b098 ("mm: shuffle initial free memory to improve
> memory-side-cache utilization") promised "autodetection of a
> memory-side-cache (to be added in a follow-on patch)" over a year ago.
>
> The original series included patches [1], however, they were dropped
> during review [2] to be followed-up later.
>
> Due to lack of platforms that publish an HMAT, autodetection is currently
> not implemented. However, manual activation is actively used [3]. Let's
> simplify for now and re-add when really (ever?) needed.
>
> [1] 
> https://lkml.kernel.org/r/154510700291.1941238.817190985966612531.st...@dwillia2-desk3.amr.corp.intel.com
> [2] 
> https://lkml.kernel.org/r/154690326478.676627.103843791978176914.st...@dwillia2-desk3.amr.corp.intel.com
> [3] 
> https://lkml.kernel.org/r/CAPcyv4irwGUU2x+c6b4L=kbb1dnasnkaazd6ospyjl9kfsn...@mail.gmail.com
>
> Cc: Andrew Morton 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Huang Ying 
> Cc: Wei Yang 
> Cc: Mel Gorman 
> Cc: Dan Williams 
> Signed-off-by: David Hildenbrand 
> ---
>  mm/shuffle.c | 28 ++--
>  mm/shuffle.h | 17 -
>  2 files changed, 2 insertions(+), 43 deletions(-)
>
> diff --git a/mm/shuffle.c b/mm/shuffle.c
> index dd13ab851b3ee..9b5cd4b004b0f 100644
> --- a/mm/shuffle.c
> +++ b/mm/shuffle.c
> @@ -10,33 +10,11 @@
>  #include "shuffle.h"
>
>  DEFINE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
> -static unsigned long shuffle_state __ro_after_init;
> -
> -/*
> - * Depending on the architecture, module parameter parsing may run
> - * before, or after the cache detection. SHUFFLE_FORCE_DISABLE prevents,
> - * or reverts the enabling of the shuffle implementation. SHUFFLE_ENABLE
> - * attempts to turn on the implementation, but aborts if it finds
> - * SHUFFLE_FORCE_DISABLE already set.
> - */
> -__meminit void page_alloc_shuffle(enum mm_shuffle_ctl ctl)
> -{
> -   if (ctl == SHUFFLE_FORCE_DISABLE)
> -   set_bit(SHUFFLE_FORCE_DISABLE, _state);
> -
> -   if (test_bit(SHUFFLE_FORCE_DISABLE, _state)) {
> -   if (test_and_clear_bit(SHUFFLE_ENABLE, _state))
> -   static_branch_disable(_alloc_shuffle_key);
> -   } else if (ctl == SHUFFLE_ENABLE
> -   && !test_and_set_bit(SHUFFLE_ENABLE, _state))
> -   static_branch_enable(_alloc_shuffle_key);
> -}
>
>  static bool shuffle_param;
>  static int shuffle_show(char *buffer, const struct kernel_param *kp)
>  {
> -   return sprintf(buffer, "%c\n", test_bit(SHUFFLE_ENABLE, 
> _state)
> -   ? 'Y' : 'N');
> +   return sprintf(buffer, "%c\n", shuffle_param ? 'Y' : 'N');
>  }
>
>  static __meminit int shuffle_store(const char *val,
> @@ -47,9 +25,7 @@ static __meminit int shuffle_store(const char *val,
> if (rc < 0)
> return rc;
> if (shuffle_param)
> -   page_alloc_shuffle(SHUFFLE_ENABLE);
> -   else
> -   page_alloc_shuffle(SHUFFLE_FORCE_DISABLE);
> +   static_branch_enable(_alloc_shuffle_key);
> return 0;
>  }

Let's do proper input validation here and require 1 / 'true' to enable
shuffling and not also allow 0 to be an 'enable' value.

Other than that looks like the right move to me until end users or
distros start asking for the kernel to do this by default, I'm not
aware of any of those requests to date. People seem fine to set the
boot option.

After the above fixups you can add:

Acked-by: Dan Williams 

Re: [PATCH 06/26] mm/csky: Use general page fault accounting

[Guo Ren]

On Sat, Jun 20, 2020 at 12:05 AM Peter Xu  wrote:
>
> Use the general page fault accounting by passing regs into handle_mm_fault().
> It naturally solve the issue of multiple page fault accounting when page fault
> retry happened.
>
> CC: Guo Ren 
> CC: linux-c...@vger.kernel.org
> Signed-off-by: Peter Xu 
> ---
>  arch/csky/mm/fault.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/arch/csky/mm/fault.c b/arch/csky/mm/fault.c
> index b14f97d3cb15..a3e0aa3ebb79 100644
> --- a/arch/csky/mm/fault.c
> +++ b/arch/csky/mm/fault.c
> @@ -151,7 +151,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs, 
> unsigned long write,
>  * the fault.
>  */
> fault = handle_mm_fault(vma, address, write ? FAULT_FLAG_WRITE : 0,
> -   NULL);
> +   regs);
what's your kernel version ? （4th arg exsist ?）
/*
 * If for any reason at all we couldn't handle the fault,
 * make sure we exit gracefully rather than endlessly redo
 * the fault.
 */
fault = handle_mm_fault(vma, address, write ? FAULT_FLAG_WRITE : 0);
if (unlikely(fault & VM_FAULT_ERROR)) {



-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH v2 2/3] mm/memory_hotplug: document why shuffle_zone() is relevant

[Dan Williams]

On Fri, Jun 19, 2020 at 6:00 AM David Hildenbrand  wrote:
>
> It's not completely obvious why we have to shuffle the complete zone, as
> some sort of shuffling is already performed when onlining pages via
> __free_one_page(), placing MAX_ORDER-1 pages either to the head or the tail
> of the freelist. Let's document why we have to shuffle the complete zone
> when exposing larger, contiguous physical memory areas to the buddy.
>

How about?

Fixes: e900a918b098 ("mm: shuffle initial free memory to improve
memory-side-cache utilization")

...just like Patch1 since that original commit was missing the proper
commentary in the code?


> Cc: Andrew Morton 
> Cc: Alexander Duyck 
> Cc: Dan Williams 
> Cc: Michal Hocko 
> Signed-off-by: David Hildenbrand 
> ---
>  mm/memory_hotplug.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 9b34e03e730a4..a0d81d404823d 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -822,6 +822,14 @@ int __ref online_pages(unsigned long pfn, unsigned long 
> nr_pages,
> zone->zone_pgdat->node_present_pages += onlined_pages;
> pgdat_resize_unlock(zone->zone_pgdat, );
>
> +   /*
> +* When exposing larger, physically contiguous memory areas to the
> +* buddy, shuffling in the buddy (when freeing onlined pages, putting
> +* them either to the head or the tail of the freelist) is only 
> helpful
> +* for mainining the shuffle, but not for creating the initial 
> shuffle.

s/mainining/maintaining/

> +* Shuffle the whole zone to make sure the just onlined pages are
> +* properly distributed across the whole freelist.
> +*/
> shuffle_zone(zone);
>
> node_states_set_node(nid, );

Other than the above minor fixups you can add:

Acked-by: Dan Williams 

Re: kprobe: __blkdev_put probe is missed

[Masami Hiramatsu]

Hi Ming,

On Sat, 20 Jun 2020 07:28:20 +0800
Ming Lei  wrote:

> > 
> > Ah, after all it is as expected. With your kconfig, the kernel is
> > very agressively optimized.
> > 
> > $ objdump -dS vmlinux | less
> > ...
> > 81256dc3 <__blkdev_put>:
> > {
> > 81256dc3:   e8 98 85 df ff  callq  8104f360 
> > <__fentry__>
> > 81256dc8:   41 57   push   %r15
> > 81256dca:   41 56   push   %r14
> > 81256dcc:   41 55   push   %r13
> > ...
> > 81256f05:   75 02   jne81256f09 
> > <__blkdev_put+0x146>
> > struct block_device *victim = NULL;
> > 81256f07:   31 db   xor%ebx,%ebx
> > bdev->bd_contains = NULL;
> > 81256f09:   48 c7 45 60 00 00 00movq   $0x0,0x60(%rbp)
> > 81256f10:   00 
> > put_disk_and_module(disk);
> > 81256f11:   4c 89 f7mov%r14,%rdi
> > 81256f14:   e8 c6 3d 11 00  callq  8136acdf 
> > 
> > mutex_unlock(>bd_mutex);
> > 81256f19:   4c 89 ffmov%r15,%rdi
> > __blkdev_put(victim, mode, 1);
> > 81256f1c:   41 bc 01 00 00 00   mov$0x1,%r12d
> > mutex_unlock(>bd_mutex);
> > 81256f22:   e8 8d d7 48 00  callq  816e46b4 
> > 
> > bdput(bdev);
> > 81256f27:   48 89 efmov%rbp,%rdi
> > 81256f2a:   e8 f0 e9 ff ff  callq  8125591f 
> > 
> > if (victim)
> > 81256f2f:   48 85 dbtest   %rbx,%rbx
> > 81256f32:   74 08   je 81256f3c 
> > <__blkdev_put+0x179>
> > 81256f34:   48 89 ddmov%rbx,%rbp
> > 81256f37:   e9 b4 fe ff ff  jmpq   81256df0 
> > <__blkdev_put+0x2d> <<-THIS!!
> > }
> > 81256f3c:   48 8b 44 24 28  mov0x28(%rsp),%rax
> > 81256f41:   65 48 33 04 25 28 00xor%gs:0x28,%rax
> > 81256f48:   00 00 
> > 81256f4a:   74 05   je 81256f51 
> > <__blkdev_put+0x18e>
> > 81256f4c:   e8 5a 4e 48 00  callq  816dbdab 
> > <__stack_chk_fail>
> > 81256f51:   48 83 c4 30 add$0x30,%rsp
> > 81256f55:   5b  pop%rbx
> > 81256f56:   5d  pop%rbp
> > 81256f57:   41 5c   pop%r12
> > 81256f59:   41 5d   pop%r13
> > 81256f5b:   41 5e   pop%r14
> > 81256f5d:   41 5f   pop%r15
> > 81256f5f:   c3  retq   
> > 
> > 
> > As you can see, the nested __blkdev_put() is coverted to a loop.
> > If you put kprobe on __blkdev_put+0x2d, you'll see the event twice.
> 
> Thanks for your investigation.
> 
> Some trace tools can just trace on function entry, such as bcc, and some
> user script always trace on function entry.
> 
> I guess the issue should belong to kprobe implementation:
> 
> 1) __blkdev_put() is capable of being kprobed, so from user view, the
> probe on entry of __blkdev_put() should be triggered

Yes, it is correctly triggered.

> 
> 2) from implementation view, I understand exception should be trapped
> on the entry of __blkdev_put(), looks it isn't done.

No, it is correctly trapped the function entry address. The problem is
that the gcc optimized the nested function call into jump to the
beginning of function body (skip prologue).

Usually, a function is compiled as below

func() (1) the entry address (func:)
{  (2) the function prologue (setup stackframe)  
  int a(3) the beginning of function body 
   ...
  func()   (4) the nested function call

And in this case, the gcc optimized (4) into jump to (3) instead of
actual function call instruction. Thus, for the nested case (1) and
(2) are skipped.
 IOW, the code flow becomes
  (1)->(2)->(3)->(4)->(3)
 instead of 
  (1)->(2)->(3)->(4)->(1)->(2)->(3)

In this case, if we put a probe on (1) or (2), those are disappeared
in the nested call. Thus if you put a probe on (3) ('perf probe __blkdev_put:2')
you'll see the event twice.

Thank you,

-- 
Masami Hiramatsu 

Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps

[Williams, Dan J]

On Fri, 2020-06-19 at 14:59 +0200, David Hildenbrand wrote:
> Especially with memory hotplug, we can have offline sections (with a
> garbage memmap) and overlapping zones. We have to make sure to only
> touch initialized memmaps (online sections managed by the buddy) and
> that
> the zone matches, to not move pages between zones.
> 
> To test if this can actually happen, I added a simple
>   BUG_ON(page_zone(page_i) != page_zone(page_j));
> right before the swap. When hotplugging a 256M DIMM to a 4G x86-64 VM
> and
> onlining the first memory block "online_movable" and the second
> memory
> block "online_kernel", it will trigger the BUG, as both zones (NORMAL
> and MOVABLE) overlap.
> 
> This might result in all kinds of weird situations (e.g., double
> allocations, list corruptions, unmovable allocations ending up in the
> movable zone).
> 
> Fixes: e900a918b098 ("mm: shuffle initial free memory to improve
> memory-side-cache utilization")
> Acked-by: Michal Hocko 
> Cc: sta...@vger.kernel.org # v5.2+
> Cc: Andrew Morton 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Minchan Kim 
> Cc: Huang Ying 
> Cc: Wei Yang 
> Cc: Mel Gorman 
> Signed-off-by: David Hildenbrand 

Looks good to me.

Acked-by: Dan Williams 

Re: [PATCH v6 09/19] mm: memcg/slab: charge individual slab objects instead of pages

[Roman Gushchin]

On Fri, Jun 19, 2020 at 05:54:24PM -0700, Shakeel Butt wrote:
> On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
> >
> > Switch to per-object accounting of non-root slab objects.
> >
> > Charging is performed using obj_cgroup API in the pre_alloc hook.
> > Obj_cgroup is charged with the size of the object and the size
> > of metadata: as now it's the size of an obj_cgroup pointer.
> > If the amount of memory has been charged successfully, the actual
> > allocation code is executed. Otherwise, -ENOMEM is returned.
> >
> > In the post_alloc hook if the actual allocation succeeded,
> > corresponding vmstats are bumped and the obj_cgroup pointer is saved.
> > Otherwise, the charge is canceled.
> >
> > On the free path obj_cgroup pointer is obtained and used to uncharge
> > the size of the releasing object.
> >
> > Memcg and lruvec counters are now representing only memory used
> > by active slab objects and do not include the free space. The free
> > space is shared and doesn't belong to any specific cgroup.
> >
> > Global per-node slab vmstats are still modified from (un)charge_slab_page()
> > functions. The idea is to keep all slab pages accounted as slab pages
> > on system level.
> >
> > Signed-off-by: Roman Gushchin 
> > Reviewed-by: Vlastimil Babka 
> > ---
> [snip]
> > +
> > +static inline struct kmem_cache *memcg_slab_pre_alloc_hook(struct 
> > kmem_cache *s,
> > +   struct obj_cgroup **objcgp,
> > +   size_t objects, gfp_t flags)
> > +{
> > +   struct kmem_cache *cachep;
> > +
> > +   cachep = memcg_kmem_get_cache(s, objcgp);
> > +   if (is_root_cache(cachep))
> > +   return s;
> > +
> > +   if (obj_cgroup_charge(*objcgp, flags, objects * obj_full_size(s))) {
> > +   memcg_kmem_put_cache(cachep);
> 
> obj_cgroup_put(objcgp)? Or better to do that in memcg_kmem_put_cache().

Hm, you are right, it's a real issue. It's fixed later in the series by
"mm: memcg/slab: use a single set of kmem_caches for all accounted allocations"
though. Good catch!

I'll re-spin necessary patches to avoid it and ask Andrew to replace them.

Thank you!

drivers/gpu/drm/drm_gem_shmem_helper.c:540:22: error: incompatible types when assigning to type 'pgprot_t' {aka 'struct '} from type 'int'

[kernel test robot]

Hi Gerd,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4333a9b0b67bb4e8bcd91bdd80da80b0ec151162
commit: 0be895893607fb3447478d6e33dfb60644195a09 drm/shmem: switch shmem helper 
to _gem_object_funcs.mmap
date:   8 months ago
config: m68k-randconfig-r016-20200619 (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
git checkout 0be895893607fb3447478d6e33dfb60644195a09
# 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 >>):

   In file included from include/linux/file.h:9,
from include/linux/dma-buf.h:16,
from drivers/gpu/drm/drm_gem_shmem_helper.c:6:
   include/linux/scatterlist.h: In function 'sg_set_buf':
   arch/m68k/include/asm/page_no.h:33:50: warning: ordered comparison of 
pointer with null pointer [-Wextra]
  33 | #define virt_addr_valid(kaddr) (((void *)(kaddr) >= (void 
*)PAGE_OFFSET) && \
 |  ^~
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
  78 | # define unlikely(x) __builtin_expect(!!(x), 0)
 |  ^
   include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
 143 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~
   include/linux/scatterlist.h:143:10: note: in expansion of macro 
'virt_addr_valid'
 143 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~~
   drivers/gpu/drm/drm_gem_shmem_helper.c: In function 
'drm_gem_shmem_vmap_locked':
   drivers/gpu/drm/drm_gem_shmem_helper.c:261:17: error: implicit declaration 
of function 'pgprot_writecombine' [-Werror=implicit-function-declaration]
 261 | VM_MAP, pgprot_writecombine(PAGE_KERNEL));
 | ^~~
   drivers/gpu/drm/drm_gem_shmem_helper.c:261:17: error: incompatible type for 
argument 4 of 'vmap'
 261 | VM_MAP, pgprot_writecombine(PAGE_KERNEL));
 | ^~~~
 | |
 | int
   In file included from include/asm-generic/io.h:887,
from arch/m68k/include/asm/io.h:11,
from arch/m68k/include/asm/pgtable_no.h:14,
from arch/m68k/include/asm/pgtable.h:3,
from include/linux/mm.h:99,
from include/linux/scatterlist.h:8,
from include/linux/dma-buf.h:18,
from drivers/gpu/drm/drm_gem_shmem_helper.c:6:
   include/linux/vmalloc.h:119:14: note: expected 'pgprot_t' {aka 'struct 
'} but argument is of type 'int'
 119 | extern void *vmap(struct page **pages, unsigned int count,
 |  ^~~~
   drivers/gpu/drm/drm_gem_shmem_helper.c: In function 'drm_gem_shmem_mmap':
>> drivers/gpu/drm/drm_gem_shmem_helper.c:540:22: error: incompatible types 
>> when assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
 540 |  vma->vm_page_prot = 
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
 |  ^~~
   cc1: some warnings being treated as errors

vim +540 drivers/gpu/drm/drm_gem_shmem_helper.c

   513  
   514  /**
   515   * drm_gem_shmem_mmap - Memory-map a shmem GEM object
   516   * @obj: gem object
   517   * @vma: VMA for the area to be mapped
   518   *
   519   * This function implements an augmented version of the GEM DRM file 
mmap
   520   * operation for shmem objects. Drivers which employ the shmem helpers 
should
   521   * use this function as their _gem_object_funcs.mmap handler.
   522   *
   523   * Returns:
   524   * 0 on success or a negative error code on failure.
   525   */
   526  int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct 
vm_area_struct *vma)
   527  {
   528  struct drm_gem_shmem_object *shmem;
   529  int ret;
   530  
   531  shmem = to_drm_gem_shmem_obj(obj);
   532  
   533  ret = drm_gem_shmem_get_pages(shmem);
   534  if (ret) {
   535  drm_gem_vm_close(vma);
   536  return ret;
   537  }
   538  
   539  vma->vm_flags |= VM_IO | VM_MIXEDMAP | VM_DONTEXPAND | 
VM_DONTDUMP;
 > 540  vma->vm_page_prot = 
 > pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
   541  vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
   542  vma->vm_ops = _gem_shmem_vm_ops;
   543  
   544 

[GIT PULL] tracing: Tracing fixes for 5.8-rc1

[Steven Rostedt]

Linus,

A few fixes and small cleanups for tracing:

 - Have recordmcount work with > 64K sections (to support LTO)
 - kprobe RCU fixes
 - Correct a kprobe critical section with missing mutex
 - Remove redundant arch_disarm_kprobe() call
 - Fix lockup when kretprobe triggers within kprobe_flush_task()
 - Fix memory leak in fetch_op_data operations
 - Fix sleep in atomic in ftrace trace array sample code
 - Free up memory on failure in sample trace array code
 - Fix incorrect reporting of function_graph fields in format file
 - Fix quote within quote parsing in bootconfig
 - Fix return value of bootconfig tool
 - Add testcases for bootconfig tool
 - Fix maybe uninitialized warning in ftrace pid file code
 - Remove unused variable in tracing_iter_reset()
 - Fix some typos


Please pull the latest trace-v5.8-rc1 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v5.8-rc1

Tag SHA1: 51ce53ae395e2df3e879e63985e4c9a3b989c8f5
Head SHA1: 026bb845b0fff6dec91fe24511dad7d3067dc3ed


Jiri Olsa (1):
  kretprobe: Prevent triggering kretprobe from within kprobe_flush_task

Kaitao Cheng (1):
  ftrace: Fix maybe-uninitialized compiler warning

Kefeng Wang (2):
  sample-trace-array: Fix sleeping function called from invalid context
  sample-trace-array: Remove trace_array 'sample-instance'

Masami Hiramatsu (8):
  kprobes: Suppress the suspicious RCU warning on kprobes
  kprobes: Use non RCU traversal APIs on kprobe_tables if possible
  kprobes: Fix to protect kick_kprobe_optimizer() by kprobe_mutex
  kprobes: Remove redundant arch_disarm_kprobe() call
  proc/bootconfig: Fix to use correct quotes for value
  tools/bootconfig: Fix to use correct quotes for value
  tools/bootconfig: Fix to return 0 if succeeded to show the bootconfig
  tools/bootconfig: Add testcase for show-command and quotes test

Sami Tolvanen (1):
  recordmcount: support >64k sections

Steven Rostedt (VMware) (1):
  tracing: Make ftrace packed events have align of 1

Vamshi K Sthambamkadi (1):
  tracing/probe: Fix memleak in fetch_op_data operations

Wei Yang (1):
  trace: Fix typo in allocate_ftrace_ops()'s comment

YangHui (1):
  tracing: Remove unused event variable in tracing_iter_reset


 arch/x86/kernel/kprobes/core.c  | 16 ++
 fs/proc/bootconfig.c| 15 --
 include/linux/kprobes.h |  4 ++
 kernel/kprobes.c| 61 ++-
 kernel/trace/ftrace.c   | 12 -
 kernel/trace/trace.c|  3 +-
 kernel/trace/trace.h|  3 ++
 kernel/trace/trace_entries.h| 14 +++---
 kernel/trace/trace_export.c | 16 ++
 kernel/trace/trace_functions.c  |  2 +-
 kernel/trace/trace_probe.c  |  4 +-
 samples/ftrace/sample-trace-array.c | 24 ++---
 scripts/recordmcount.h  | 98 ++---
 tools/bootconfig/main.c | 24 +
 tools/bootconfig/test-bootconfig.sh | 10 
 15 files changed, 239 insertions(+), 67 deletions(-)
---
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 3bafe1bd4dc7..8a5ec10e95dc 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -753,16 +753,11 @@ asm(
 NOKPROBE_SYMBOL(kretprobe_trampoline);
 STACK_FRAME_NON_STANDARD(kretprobe_trampoline);
 
-static struct kprobe kretprobe_kprobe = {
-   .addr = (void *)kretprobe_trampoline,
-};
-
 /*
  * Called from kretprobe_trampoline
  */
 __used __visible void *trampoline_handler(struct pt_regs *regs)
 {
-   struct kprobe_ctlblk *kcb;
struct kretprobe_instance *ri = NULL;
struct hlist_head *head, empty_rp;
struct hlist_node *tmp;
@@ -772,16 +767,12 @@ __used __visible void *trampoline_handler(struct pt_regs 
*regs)
void *frame_pointer;
bool skipped = false;
 
-   preempt_disable();
-
/*
 * Set a dummy kprobe for avoiding kretprobe recursion.
 * Since kretprobe never run in kprobe handler, kprobe must not
 * be running at this point.
 */
-   kcb = get_kprobe_ctlblk();
-   __this_cpu_write(current_kprobe, _kprobe);
-   kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+   kprobe_busy_begin();
 
INIT_HLIST_HEAD(_rp);
kretprobe_hash_lock(current, , );
@@ -857,7 +848,7 @@ __used __visible void *trampoline_handler(struct pt_regs 
*regs)
__this_cpu_write(current_kprobe, >rp->kp);
ri->ret_addr = correct_ret_addr;
ri->rp->handler(ri, regs);
-   __this_cpu_write(current_kprobe, _kprobe);
+   __this_cpu_write(current_kprobe, _busy);
}
 
recycle_rp_inst(ri, _rp);
@@ -873,8 +864,7 @@ __used __visible void *trampoline_handler(struct pt_regs 
*regs)
 

Re: [RFC PATCH 0/1] dm-crypt excessive overhead

[Herbert Xu]

On Fri, Jun 19, 2020 at 02:39:39PM -0400, Mikulas Patocka wrote:
>
> I'm looking at this and I'd like to know why does the crypto API fail in 
> hard-irq context and why does it work in tasklet context. What's the exact 
> reason behind this?

You're not supposed to do any real work in IRQ handlers.  All
the substantial work should be postponed to softirq context.

Why do you need to do work in hard IRQ context?

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

Re: [PATCH v6 08/19] mm: memcg/slab: save obj_cgroup for non-root slab objects

[Roman Gushchin]

On Fri, Jun 19, 2020 at 05:16:02PM -0700, Shakeel Butt wrote:
> On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
> >
> > Store the obj_cgroup pointer in the corresponding place of
> > page->obj_cgroups for each allocated non-root slab object.
> > Make sure that each allocated object holds a reference to obj_cgroup.
> >
> > Objcg pointer is obtained from the memcg->objcg dereferencing
> > in memcg_kmem_get_cache() and passed from pre_alloc_hook to
> > post_alloc_hook. Then in case of successful allocation(s) it's
> > getting stored in the page->obj_cgroups vector.
> >
> > The objcg obtaining part look a bit bulky now, but it will be simplified
> > by next commits in the series.
> >
> > Signed-off-by: Roman Gushchin 
> > Reviewed-by: Vlastimil Babka 
> 
> One nit below otherwise:
> 
> Reviewed-by: Shakeel Butt 
> 
> > ---
> [snip]
> > +static inline void memcg_slab_post_alloc_hook(struct kmem_cache *s,
> > + struct obj_cgroup *objcg,
> > + size_t size, void **p)
> > +{
> > +   struct page *page;
> > +   unsigned long off;
> > +   size_t i;
> > +
> > +   for (i = 0; i < size; i++) {
> > +   if (likely(p[i])) {
> > +   page = virt_to_head_page(p[i]);
> > +   off = obj_to_index(s, page, p[i]);
> > +   obj_cgroup_get(objcg);
> > +   page_obj_cgroups(page)[off] = objcg;
> > +   }
> > +   }
> > +   obj_cgroup_put(objcg);
> 
> Nit: we get the objcg reference in memcg_kmem_get_cache(), doesn't it
> look cleaner to put that reference in memcg_kmem_put_cache() instead
> of here.

memcg_kmem_put_cache() will go away completely later in the series.

I know the code might look sub-optimal and messy on some stages,
but it's only because there is a big transition from the original
to the final state, and I don't wanna to increase intermediate diffs.

Please, take a look at the final result.

Re: [PATCH v6 11/19] mm: memcg/slab: move memcg_kmem_bypass() to memcontrol.h

[Shakeel Butt]

On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
>
> To make the memcg_kmem_bypass() function available outside of
> the memcontrol.c, let's move it to memcontrol.h. The function
> is small and nicely fits into static inline sort of functions.
>
> It will be used from the slab code.
>
> Signed-off-by: Roman Gushchin 
> Reviewed-by: Vlastimil Babka 

Reviewed-by: Shakeel Butt 

RE: [PATCH AUTOSEL 5.4 199/266] misc: xilinx-sdfec: improve get_user_pages_fast() error handling

[Dragan Cvetic]

Hi Sasha,

Thank you for the patch.


> -Original Message-
> From: Sasha Levin 
> Sent: Thursday 18 June 2020 02:15
> To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org
> Cc: John Hubbard ; Derek Kiernan ; 
> Dragan Cvetic ; Arnd
> Bergmann ; Greg Kroah-Hartman ; 
> Michal Simek ; linux-arm-
> ker...@lists.infradead.org; Sasha Levin 
> Subject: [PATCH AUTOSEL 5.4 199/266] misc: xilinx-sdfec: improve 
> get_user_pages_fast() error handling
> 
> From: John Hubbard 
> 
> [ Upstream commit 57343d51613227373759f5b0f2eede257fd4b82e ]
> 
> This fixes the case of get_user_pages_fast() returning a -errno.
> The result needs to be stored in a signed integer. And for safe
> signed/unsigned comparisons, it's best to keep everything signed.
> And get_user_pages_fast() also expects a signed value for number
> of pages to pin.
> 
> Therefore, change most relevant variables, from u32 to int. Leave
> "n" unsigned, for convenience in checking for overflow. And provide
> a WARN_ON_ONCE() and early return, if overflow occurs.
> 
> Also, as long as we're tidying up: rename the page array from page,
> to pages, in order to match the conventions used in most other call
> sites.
> 
> Fixes: 20ec628e8007e ("misc: xilinx_sdfec: Add ability to configure LDPC")
> Cc: Derek Kiernan 
> Cc: Dragan Cvetic 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Michal Simek 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: John Hubbard 
> Link: https://lore.kernel.org/r/20200527012628.1100649-2-jhubb...@nvidia.com
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/misc/xilinx_sdfec.c | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
> index 48ba7e02bed7..d4c14b617201 100644
> --- a/drivers/misc/xilinx_sdfec.c
> +++ b/drivers/misc/xilinx_sdfec.c
> @@ -602,10 +602,10 @@ static int xsdfec_table_write(struct xsdfec_dev 
> *xsdfec, u32 offset,
> const u32 depth)
>  {
>   u32 reg = 0;
> - u32 res;
> - u32 n, i;
> + int res, i, nr_pages;
> + u32 n;
>   u32 *addr = NULL;
> - struct page *page[MAX_NUM_PAGES];
> + struct page *pages[MAX_NUM_PAGES];
> 
>   /*
>* Writes that go beyond the length of
> @@ -622,15 +622,22 @@ static int xsdfec_table_write(struct xsdfec_dev 
> *xsdfec, u32 offset,
>   if ((len * XSDFEC_REG_WIDTH_JUMP) % PAGE_SIZE)
>   n += 1;
> 
> - res = get_user_pages_fast((unsigned long)src_ptr, n, 0, page);
> - if (res < n) {
> - for (i = 0; i < res; i++)
> - put_page(page[i]);
> + if (WARN_ON_ONCE(n > INT_MAX))
> + return -EINVAL;
> +
> + nr_pages = n;
> +
> + res = get_user_pages_fast((unsigned long)src_ptr, nr_pages, 0, pages);
> + if (res < nr_pages) {
> + if (res > 0) {
> + for (i = 0; i < res; i++)
> + put_page(pages[i]);
> + }
>   return -EINVAL;
>   }
> 
> - for (i = 0; i < n; i++) {
> - addr = kmap(page[i]);
> + for (i = 0; i < nr_pages; i++) {
> + addr = kmap(pages[i]);
>   do {
>   xsdfec_regwrite(xsdfec,
>   base_addr + ((offset + reg) *
> @@ -639,7 +646,7 @@ static int xsdfec_table_write(struct xsdfec_dev *xsdfec, 
> u32 offset,
>   reg++;
>   } while ((reg < len) &&
>((reg * XSDFEC_REG_WIDTH_JUMP) % PAGE_SIZE));
> - put_page(page[i]);
> + put_page(pages[i]);
>   }
>   return reg;
>  }
> --
> 2.25.1

Acked-by: Dragan Cvetic 

Regards
Dragan

[PATCH][next] sparc64: viohs: Use struct_size() helper

[Gustavo A. R. Silva]

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes. Also, remove unnecessary
variable _len_.

This code was detected with the help of Coccinelle and, audited and
fixed manually.

Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
Signed-off-by: Gustavo A. R. Silva 
---
 arch/sparc/kernel/viohs.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/viohs.c b/arch/sparc/kernel/viohs.c
index 7db5aabe9708..e27afd233bf5 100644
--- a/arch/sparc/kernel/viohs.c
+++ b/arch/sparc/kernel/viohs.c
@@ -428,7 +428,7 @@ static int process_dreg_info(struct vio_driver_state *vio,
 struct vio_dring_register *pkt)
 {
struct vio_dring_state *dr;
-   int i, len;
+   int i;
 
viodbg(HS, "GOT DRING_REG INFO ident[%llx] "
   "ndesc[%u] dsz[%u] opt[0x%x] ncookies[%u]\n",
@@ -482,9 +482,7 @@ static int process_dreg_info(struct vio_driver_state *vio,
   pkt->num_descr, pkt->descr_size, pkt->options,
   pkt->num_cookies);
 
-   len = (sizeof(*pkt) +
-  (dr->ncookies * sizeof(struct ldc_trans_cookie)));
-   if (send_ctrl(vio, >tag, len) < 0)
+   if (send_ctrl(vio, >tag, struct_size(pkt, cookies, dr->ncookies)) 
< 0)
goto send_nack;
 
vio->dr_state |= VIO_DR_STATE_RXREG;
-- 
2.27.0

Re: [PATCH V7 1/4] dt-bindings: clock: add ipq6018 a53 pll compatible

[Sivaprakash Murugesan]

On 6/20/2020 6:06 AM, Stephen Boyd wrote:

Quoting Sivaprakash Murugesan (2020-06-06 03:55:04)

cpus on ipq6018 are clocked by a53 pll, add device compatible for a53
pll found on ipq6018 devices.

Signed-off-by: Sivaprakash Murugesan 
---
[V7]
  * Addressed minor review comment from Rob
  .../devicetree/bindings/clock/qcom,a53pll.yaml | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml 
b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
index 20d2638..3161fab 100644
--- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
@@ -15,6 +15,7 @@ description:
  
  properties:

compatible:
+const: qcom,ipq6018-a53pll
  const: qcom,msm8916-a53pll
  
reg:

I'm getting this error when running dt binding check:

ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping
   in "", line 18, column 5
found duplicate key "const" with value "qcom,msm8916-a53pll" (original value: 
"qcom,ipq6018-a53pll")
   in "", line 19, column 5


This error started coming after updating the dt-schema version.

Guess I need to replace const with enum to get rid of this error.

will address this.

Re: kprobe: __blkdev_put probe is missed

[Steven Rostedt]

On Sat, 20 Jun 2020 07:28:20 +0800
Ming Lei  wrote:

> Thanks for your investigation.
> 
> Some trace tools can just trace on function entry, such as bcc, and some
> user script always trace on function entry.
> 
> I guess the issue should belong to kprobe implementation:

The issue is that kprobes is to dynamically add trace events into an
already compiled kernel. I'm guessing you would get the same result
from ftrace's function tracer. That's because the compiler has no idea
about what or where you intend to add these dynamically created trace
events (that's basically the point of kprobes). But if you add static
events (and this includes trace_printk()), the compiler knows about
them, because they exist at compile time, and will make sure they
execute the number of times the code shows it. But if you don't have
these events at compile time, the compiler is free to modify the code
in such a way it doesn't make sense if you add a probe at run time.

gdb suffers the same problem on user space debugging if you let the
compiler aggressively optimize the code. If you step through highly
optimized user space code with gdb, the position jumps all over the
place. This is basically the same effect.

> 
> 1) __blkdev_put() is capable of being kprobed, so from user view, the
> probe on entry of __blkdev_put() should be triggered
> 
> 2) from implementation view, I understand exception should be trapped
> on the entry of __blkdev_put(), looks it isn't done.

But it is done! But the compiler removed the second call and basically
just inlined it. So that entry no longer exists. When you added a
"trace_printk()" in there, the compiler is not allowed to skip that
trace call. But because there's nothing in here to tell the compiler
that it can't just remove the second call (which it did, and the kprobe
is just showing you what the compiler did!) then there's nothing
kprobes can do about it.

> 
> Correct me if the above is wrong, and is it possible to fix it in kprobe?

No.

-- Steve

Re: WARNING at switch_mm_irqs_off, followed by frozen machine

[Ilkka Prusi]

Hi,

On 18.6.2020 13.21, Peter Zijlstra wrote:

On Wed, Jun 17, 2020 at 02:32:39AM +0300, Ilkka Prusi wrote:

Hi,

Yesterday my computer with kernel version 5.7.2 was frozen badly enough that
hard reset was necessary (did not react to SysRq keys). Upon checking logs I
found following warning and information from the time just before resetting
it.

Computer has AMD Ryzen 7 2700, Asus B450 motherboard.

5.8-rc1 encountered BUG() and did not boot (iommu and smp_processor_id()
called from wrong context, I'll see if I can catch log somehow).

Since you're building your own kernels, can you make sure to always
have:

  - CONFIG_DEBUG_BUGVERBOSE=y
  - CONFIG_DEBUG_INFO=y

and then when reporting, run the thing through:

   ./scripts/decode_stacktrace.sh


Ok, thanks for letting me know, I'll try that.



And then pattern match that against my local defconfig build of
arch/x86/mm/tlb.o and pray my compiler did anyting like your
(unspecified) compiler.


Forgot to mention that, currently it is:

gcc (Debian 9.3.0-13) 9.3.0

I'll try your suggestions, sorry for not replying sooner.

--

 - Ilkka Prusi

[PATCH][next] perf/x86/intel/uncore: Use struct_size() in kzalloc_node()

[Gustavo A. R. Silva]

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes. Also, remove unnecessary
variable _size_.

This code was detected with the help of Coccinelle and, audited and
fixed manually.

Signed-off-by: Gustavo A. R. Silva 
---
 arch/x86/events/intel/uncore.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index cf76d6631afa..958c6baaf200 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -313,12 +313,10 @@ static void uncore_pmu_init_hrtimer(struct 
intel_uncore_box *box)
 static struct intel_uncore_box *uncore_alloc_box(struct intel_uncore_type 
*type,
 int node)
 {
-   int i, size, numshared = type->num_shared_regs ;
+   int i, numshared = type->num_shared_regs;
struct intel_uncore_box *box;
 
-   size = sizeof(*box) + numshared * sizeof(struct intel_uncore_extra_reg);
-
-   box = kzalloc_node(size, GFP_KERNEL, node);
+   box = kzalloc_node(struct_size(box, shared_regs, numshared), 
GFP_KERNEL, node);
if (!box)
return NULL;
 
-- 
2.27.0

Re: [PATCH v6 00/19] The new cgroup slab memory controller

[Roman Gushchin]

On Wed, Jun 17, 2020 at 03:31:10PM +0100, Mel Gorman wrote:
> On Wed, Jun 17, 2020 at 01:24:21PM +0200, Vlastimil Babka wrote:
> > > Not really.
> > > 
> > > Sharing a single set of caches adds some overhead to root- and 
> > > non-accounted
> > > allocations, which is something I've tried hard to avoid in my original 
> > > version.
> > > But I have to admit, it allows to simplify and remove a lot of code, and 
> > > here
> > > it's hard to argue with Johanness, who pushed on this design.
> > > 
> > > With performance testing it's not that easy, because it's not obvious what
> > > we wanna test. Obviously, per-object accounting is more expensive, and
> > > measuring something like 100 allocations and deallocations in a line 
> > > from
> > > a single kmem_cache will show a regression. But in the real world the 
> > > relative
> > > cost of allocations is usually low, and we can get some benefits from a 
> > > smaller
> > > working set and from having shared kmem_cache objects cache hot.
> > > Not speaking about some extra memory and the fragmentation reduction.
> > > 
> > > We've done an extensive testing of the original version in Facebook 
> > > production,
> > > and we haven't noticed any regressions so far. But I have to admit, we 
> > > were
> > > using an original version with two sets of kmem_caches.
> > > 
> > > If you have any specific tests in mind, I can definitely run them. Or if 
> > > you
> > > can help with the performance evaluation, I'll appreciate it a lot.
> > 
> > Jesper provided some pointers here [1], it would be really great if you 
> > could
> > run at least those microbenchmarks. With mmtests it's the major question of
> > which subset/profiles to run, maybe the referenced commits provide some 
> > hints,
> > or maybe Mel could suggest what he used to evaluate SLAB vs SLUB not so 
> > long ago.
> > 
> 
> Last time the list of mmtests configurations I used for a basic
> comparison were
> 
> db-pgbench-timed-ro-small-ext4
> db-pgbench-timed-ro-small-xfs
> io-dbench4-async-ext4
> io-dbench4-async-xfs
> io-bonnie-dir-async-ext4
> io-bonnie-dir-async-xfs
> io-bonnie-file-async-ext4
> io-bonnie-file-async-xfs
> io-fsmark-xfsrepair-xfs
> io-metadata-xfs
> network-netperf-unbound
> network-netperf-cross-node
> network-netperf-cross-socket
> network-sockperf-unbound
> network-netperf-unix-unbound
> network-netpipe
> network-tbench
> pagereclaim-shrinker-ext4
> scheduler-unbound
> scheduler-forkintensive
> workload-kerndevel-xfs
> workload-thpscale-madvhugepage-xfs
> workload-thpscale-xfs
> 
> Some were more valid than others in terms of doing an evaluation. I
> followed up later with a more comprehensive comparison but that was
> overkill.
> 
> Each time I did a slab/slub comparison in the past, I had to reverify
> the rate that kmem_cache_* functions were actually being called as the
> pattern can change over time even for the same workload.  A comparison
> gets more complicated when comparing cgroups as ideally there would be
> workloads running in multiple group but that gets complex and I think
> it's reasonable to just test the "basic" case without cgroups.

Thank you Mel for the suggestion!

I'll try to come up with some numbers soon. I guess networking tests
will be most interesting in this case.

Thanks!

Roman

Re: [PATCH v6 09/19] mm: memcg/slab: charge individual slab objects instead of pages

[Shakeel Butt]

On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin  wrote:
>
> Switch to per-object accounting of non-root slab objects.
>
> Charging is performed using obj_cgroup API in the pre_alloc hook.
> Obj_cgroup is charged with the size of the object and the size
> of metadata: as now it's the size of an obj_cgroup pointer.
> If the amount of memory has been charged successfully, the actual
> allocation code is executed. Otherwise, -ENOMEM is returned.
>
> In the post_alloc hook if the actual allocation succeeded,
> corresponding vmstats are bumped and the obj_cgroup pointer is saved.
> Otherwise, the charge is canceled.
>
> On the free path obj_cgroup pointer is obtained and used to uncharge
> the size of the releasing object.
>
> Memcg and lruvec counters are now representing only memory used
> by active slab objects and do not include the free space. The free
> space is shared and doesn't belong to any specific cgroup.
>
> Global per-node slab vmstats are still modified from (un)charge_slab_page()
> functions. The idea is to keep all slab pages accounted as slab pages
> on system level.
>
> Signed-off-by: Roman Gushchin 
> Reviewed-by: Vlastimil Babka 
> ---
[snip]
> +
> +static inline struct kmem_cache *memcg_slab_pre_alloc_hook(struct kmem_cache 
> *s,
> +   struct obj_cgroup **objcgp,
> +   size_t objects, gfp_t flags)
> +{
> +   struct kmem_cache *cachep;
> +
> +   cachep = memcg_kmem_get_cache(s, objcgp);
> +   if (is_root_cache(cachep))
> +   return s;
> +
> +   if (obj_cgroup_charge(*objcgp, flags, objects * obj_full_size(s))) {
> +   memcg_kmem_put_cache(cachep);

obj_cgroup_put(objcgp)? Or better to do that in memcg_kmem_put_cache().

> +   cachep = NULL;
> +   }
> +
> +   return cachep;
> +}
> +

Re: [PATCH 1/5] f2fs: fix to wait page writeback before update

[Chao Yu]

On 2020/6/20 6:47, Jaegeuk Kim wrote:
> On 06/19, Chao Yu wrote:
>> On 2020/6/19 13:49, Jaegeuk Kim wrote:
>>> On 06/19, Chao Yu wrote:
 Hi Jaegeuk,

 On 2020/6/19 7:59, Jaegeuk Kim wrote:
> Hi Chao,
>
> On 06/18, Chao Yu wrote:
>> to make page content stable for special device like raid.
>
> Could you elaborate the problem a bit?

 Some devices like raid5 wants page content to be stable, because
 it will calculate parity info based page content, if page is not
 stable, parity info could be corrupted, result in data inconsistency
 in stripe.
>>>
>>> I don't get the point, since those pages are brand new pages which were not
>>> modified before. If it's on writeback, we should not modify them regardless
>>> of whatever raid configuration. For example, f2fs_new_node_page() waits for
>>> writeback. Am I missing something?
>>
>> I think we should use f2fs_bug_on(, PageWriteback()) rather than
>> f2fs_wait_on_page_writeback() for brand new page which is allocated just now.
>> For other paths, we can keep rule that waiting for writeback before updating.
>>
>> How do you think?
>>
>> Thanks,
>>
>>>

 Thanks,

>
>>
>> Signed-off-by: Chao Yu 
>> ---
>>  fs/f2fs/dir.c  |  2 ++
>>  fs/f2fs/extent_cache.c | 18 +-
>>  fs/f2fs/f2fs.h |  2 +-
>>  fs/f2fs/file.c |  1 +
>>  fs/f2fs/inline.c   |  2 ++
>>  fs/f2fs/inode.c|  3 +--
>>  6 files changed, 16 insertions(+), 12 deletions(-)
>>
>> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
>> index d35976785e8c..91e86747a604 100644
>> --- a/fs/f2fs/dir.c
>> +++ b/fs/f2fs/dir.c
>> @@ -495,6 +495,8 @@ static int make_empty_dir(struct inode *inode,
>>  if (IS_ERR(dentry_page))
>>  return PTR_ERR(dentry_page);
>>  
>> +f2fs_bug_on(F2FS_I_SB(inode), PageWriteback(dentry_page));
>> +
>>  dentry_blk = page_address(dentry_page);
>>  
>>  make_dentry_ptr_block(NULL, , dentry_blk);
>> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
>> index e60078460ad1..686c68b98610 100644
>> --- a/fs/f2fs/extent_cache.c
>> +++ b/fs/f2fs/extent_cache.c
>> @@ -325,9 +325,10 @@ static void __drop_largest_extent(struct 
>> extent_tree *et,
>>  }
>>  
>>  /* return true, if inode page is changed */
>> -static bool __f2fs_init_extent_tree(struct inode *inode, struct 
>> f2fs_extent *i_ext)
>> +static void __f2fs_init_extent_tree(struct inode *inode, struct page 
>> *ipage)
>>  {
>>  struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
>> +struct f2fs_extent *i_ext = ipage ? _INODE(ipage)->i_ext : 
>> NULL;
>>  struct extent_tree *et;
>>  struct extent_node *en;
>>  struct extent_info ei;
>> @@ -335,16 +336,18 @@ static bool __f2fs_init_extent_tree(struct inode 
>> *inode, struct f2fs_extent *i_e
>>  if (!f2fs_may_extent_tree(inode)) {
>>  /* drop largest extent */
>>  if (i_ext && i_ext->len) {
>> +f2fs_wait_on_page_writeback(ipage, NODE, true, 
>> true);
>>  i_ext->len = 0;
>> -return true;
>> +set_page_dirty(ipage);
>> +return;
>>  }
>> -return false;
>> +return;
>>  }
>>  
>>  et = __grab_extent_tree(inode);
>>  
>>  if (!i_ext || !i_ext->len)
>> -return false;
>> +return;
>>  
>>  get_extent_info(, i_ext);
>>  
>> @@ -360,17 +363,14 @@ static bool __f2fs_init_extent_tree(struct inode 
>> *inode, struct f2fs_extent *i_e
>>  }
>>  out:
>>  write_unlock(>lock);
>> -return false;
>>  }
>>  
>> -bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent 
>> *i_ext)
>> +void f2fs_init_extent_tree(struct inode *inode, struct page *ipage)
>>  {
>> -bool ret =  __f2fs_init_extent_tree(inode, i_ext);
>> +__f2fs_init_extent_tree(inode, ipage);
>>  
>>  if (!F2FS_I(inode)->extent_tree)
>>  set_inode_flag(inode, FI_NO_EXTENT);
>> -
>> -return ret;
>>  }
>>  
>>  static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> index b35a50f4953c..326c12fa0da5 100644
>> --- a/fs/f2fs/f2fs.h
>> +++ b/fs/f2fs/f2fs.h
>> @@ -3795,7 +3795,7 @@ struct rb_entry *f2fs_lookup_rb_tree_ret(struct 
>> rb_root_cached *root,
>>  bool f2fs_check_rb_tree_consistence(struct f2fs_sb_info *sbi,
>>   

[PATCH][next] block: bio: Use struct_size() in kmalloc()

[Gustavo A. R. Silva]

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.

This code was detected with the help of Coccinelle and, audited and
fixed manually.

Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
Signed-off-by: Gustavo A. R. Silva 
---
 block/bio.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index a7366c02c9b5..fb5533416fa6 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -444,9 +444,7 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, unsigned int 
nr_iovecs,
if (nr_iovecs > UIO_MAXIOV)
return NULL;
 
-   p = kmalloc(sizeof(struct bio) +
-   nr_iovecs * sizeof(struct bio_vec),
-   gfp_mask);
+   p = kmalloc(struct_size(bio, bi_inline_vecs, nr_iovecs), 
gfp_mask);
front_pad = 0;
inline_vecs = nr_iovecs;
} else {
-- 
2.27.0

Re: [PATCH v3] IB/sa: Resolving use-after-free in ib_nl_send_msg

[Divya Indi]

Hi Jason,

Thanks for taking the time to review!

On 6/17/20 11:24 AM, Jason Gunthorpe wrote:
> On Tue, Jun 16, 2020 at 10:56:53AM -0700, Divya Indi wrote:
>> The other option might be to use GFP_NOWAIT conditionally ie
>> (only use GFP_NOWAIT when GFP_ATOMIC is not specified in gfp_mask else
>> use GFP_ATOMIC). Eventual goal being to not have a blocking memory 
>> allocation.
> This is probably safest for now, unless you can audit all callers and
> see if they can switch to GFP_NOWAIT as well

At present the callers with GFP_ATOMIC appear to be ipoib. Might not be
feasible to change them all to GFP_NOWAIT. 

Will incorporate the review comments and send out v3 early next week.

Thanks,
Divya

>
> Jason

Re: [V2 PATCH 2/3] dt-bindings: chosen: Document ima-kexec-buffer

[Thiago Jung Bauermann]

Prakhar Srivastava  writes:

> Integrity measurement architecture(IMA) validates if files
> have been accidentally or maliciously altered, both remotely and
> locally, appraise a file's measurement against a "good" value stored
> as an extended attribute, and enforce local file integrity.
>
> IMA also measures singatures of kernel and initrd during kexec along with
> the command line used for kexec.
> These measurements are critical to verify the seccurity posture of the OS.
>
> Resering memory and adding the memory information to a device tree node
> acts as the mechanism to carry over IMA measurement logs.
>
> Update devicetree documentation to reflect the addition of new property
> under the chosen node.

Thank you for writing this documentation patch. It's something I should
have done when I added the powerpc IMA kexec support.

You addressed Rob Herring's comments regarding the commit message, but
not the ones regarding the patch contents.

When posting a new version of the patches, make sure to address all
comments made so far. Addressing a comment doesn't necessarily mean
implementing the requested change. If you don't then you should at least
explain why you chose a different path.

I mention it because this has occurred before with this patch series,
and it's hard to make forward progress if review comments get ignored.

> ---
>  Documentation/devicetree/bindings/chosen.txt | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/chosen.txt 
> b/Documentation/devicetree/bindings/chosen.txt
> index 45e79172a646..a15f70c007ef 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -135,3 +135,20 @@ e.g.
>   linux,initrd-end = <0x8280>;
>   };
>  };
> +
> +linux,ima-kexec-buffer
> +--
> +
> +This property(currently used by powerpc, arm64) holds the memory range,

space before the parenthesis.

> +the address and the size, of the IMA measurement logs that are being carried

Maybe it's because English isn't my first language, but IMHO it's
clearer if "the address and the size" is between parentheses rather than
commas.

> +over to the kexec session.

I don't think there's a "kexec session", but I'm not sure what a good
term would be. "linux,booted-from-kexec" uses "new kernel" so perhaps
that's a good option to use instead of "kexec session".

> +
> +/ {
> + chosen {
> + linux,ima-kexec-buffer = <0x9 0x8200 0x0 0x8000>;
> + };
> +};
> +
> +This porperty does not represent real hardware, but the memory allocated for
> +carrying the IMA measurement logs. The address and the suze are expressed in
> +#address-cells and #size-cells, respectively of the root node.


--
Thiago Jung Bauermann
IBM Linux Technology Center