Re: [4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[Greg KH]

On Fri, Jul 20, 2018 at 03:36:41PM -0700, Nick Desaulniers wrote:
> native_save_fl() is marked static inline, but by using it as
> a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
> 
> paravirt's use of native_save_fl() also requires that no GPRs other than
> %rax are clobbered.
> 
> Compilers have different heuristics which they use to emit stack guard
> code, the emittance of which can break paravirt's callee saved assumption
> by clobbering %rcx.
> 
> Marking a function definition extern inline means that if this version
> cannot be inlined, then the out-of-line version will be preferred. By
> having the out-of-line version be implemented in assembly, it cannot be
> instrumented with a stack protector, which might violate custom calling
> conventions that code like paravirt rely on.
> 
> The semantics of extern inline has changed since gnu89. This means that
> folks using GCC versions >= 5.1 may see symbol redefinition errors at
> link time for subdirs that override KBUILD_CFLAGS (making the C standard
> used implicit) regardless of this patch. This has been cleaned up
> earlier in the patch set, but is left as a note in the commit message
> for future travelers.
> 
> Reports:
> https://lkml.org/lkml/2018/5/7/534
> https://github.com/ClangBuiltLinux/linux/issues/16
> 
> Discussion:
> https://bugs.llvm.org/show_bug.cgi?id=37512
> https://lkml.org/lkml/2018/5/24/1371
> 
> Thanks to the many folks that participated in the discussion.
> 
> Acked-by: Juergen Gross 
> Debugged-by: Alistair Strachan 
> Debugged-by: Matthias Kaehlcke 
> Reported-by: Sedat Dilek 
> Signed-off-by: Nick Desaulniers 
> Suggested-by: Arnd Bergmann 
> Suggested-by: H. Peter Anvin 
> Suggested-by: Tom Stellar 
> Tested-by: Sedat Dilek 
> ---
> Backport for 4.4. 4.4 is missing commit 784d5699eddc "x86: move exports to
> actual definitions" which doesn't apply cleanly, and not really worth
> backporting IMO. It's simpler to change this patch from upstream:
> + #include 
> rather than
> + #include 

Yeah, that makes sense, thanks for the backport.  I'll queue it up after
the next round of stable kernels comes out in a few days.

greg k-h

Re: [4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[Greg KH]

On Fri, Jul 20, 2018 at 03:36:41PM -0700, Nick Desaulniers wrote:
> native_save_fl() is marked static inline, but by using it as
> a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.
> 
> paravirt's use of native_save_fl() also requires that no GPRs other than
> %rax are clobbered.
> 
> Compilers have different heuristics which they use to emit stack guard
> code, the emittance of which can break paravirt's callee saved assumption
> by clobbering %rcx.
> 
> Marking a function definition extern inline means that if this version
> cannot be inlined, then the out-of-line version will be preferred. By
> having the out-of-line version be implemented in assembly, it cannot be
> instrumented with a stack protector, which might violate custom calling
> conventions that code like paravirt rely on.
> 
> The semantics of extern inline has changed since gnu89. This means that
> folks using GCC versions >= 5.1 may see symbol redefinition errors at
> link time for subdirs that override KBUILD_CFLAGS (making the C standard
> used implicit) regardless of this patch. This has been cleaned up
> earlier in the patch set, but is left as a note in the commit message
> for future travelers.
> 
> Reports:
> https://lkml.org/lkml/2018/5/7/534
> https://github.com/ClangBuiltLinux/linux/issues/16
> 
> Discussion:
> https://bugs.llvm.org/show_bug.cgi?id=37512
> https://lkml.org/lkml/2018/5/24/1371
> 
> Thanks to the many folks that participated in the discussion.
> 
> Acked-by: Juergen Gross 
> Debugged-by: Alistair Strachan 
> Debugged-by: Matthias Kaehlcke 
> Reported-by: Sedat Dilek 
> Signed-off-by: Nick Desaulniers 
> Suggested-by: Arnd Bergmann 
> Suggested-by: H. Peter Anvin 
> Suggested-by: Tom Stellar 
> Tested-by: Sedat Dilek 
> ---
> Backport for 4.4. 4.4 is missing commit 784d5699eddc "x86: move exports to
> actual definitions" which doesn't apply cleanly, and not really worth
> backporting IMO. It's simpler to change this patch from upstream:
> + #include 
> rather than
> + #include 

Yeah, that makes sense, thanks for the backport.  I'll queue it up after
the next round of stable kernels comes out in a few days.

greg k-h

Re: [4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[Greg KH]

On Fri, Jul 20, 2018 at 05:06:07PM -0700, Nick Desaulniers wrote:
> On Fri, Jul 20, 2018 at 5:04 PM kbuild test robot  wrote:
> >
> > Hi Nick,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on tip/x86/core]
> > [cannot apply to v4.18-rc5 next-20180720]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Nick-Desaulniers/x86-paravirt-make-native_save_fl-extern-inline/20180721-073112
> > config: i386-tinyconfig (attached as .config)
> > compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=i386
> >
> > All errors (new ones prefixed by >>):
> >
> >arch/x86/kernel/irqflags.S: Assembler messages:
> > >> arch/x86/kernel/irqflags.S:22: Error: bad register name `%_ASM_ARG1'
> >
> > vim +22 arch/x86/kernel/irqflags.S
> >
> > 16
> > 17  /*
> > 18   * void native_restore_fl(unsigned long flags)
> > 19   * %eax/%rdi: flags
> > 20   */
> > 21  ENTRY(native_restore_fl)
> >   > 22  push %_ASM_ARG1
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> 
> oops, probably should not have cc'ed vger.kernel.org for a patch meant
> for stable.

sta...@vger.kernel.org is the right address, you did it correct.  I
think 0-day just got a bit trigger-happy on this one for some reason,
don't worry about it.

thanks,

greg k-h

Re: [4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[Greg KH]

On Fri, Jul 20, 2018 at 05:06:07PM -0700, Nick Desaulniers wrote:
> On Fri, Jul 20, 2018 at 5:04 PM kbuild test robot  wrote:
> >
> > Hi Nick,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on tip/x86/core]
> > [cannot apply to v4.18-rc5 next-20180720]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Nick-Desaulniers/x86-paravirt-make-native_save_fl-extern-inline/20180721-073112
> > config: i386-tinyconfig (attached as .config)
> > compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=i386
> >
> > All errors (new ones prefixed by >>):
> >
> >arch/x86/kernel/irqflags.S: Assembler messages:
> > >> arch/x86/kernel/irqflags.S:22: Error: bad register name `%_ASM_ARG1'
> >
> > vim +22 arch/x86/kernel/irqflags.S
> >
> > 16
> > 17  /*
> > 18   * void native_restore_fl(unsigned long flags)
> > 19   * %eax/%rdi: flags
> > 20   */
> > 21  ENTRY(native_restore_fl)
> >   > 22  push %_ASM_ARG1
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> 
> oops, probably should not have cc'ed vger.kernel.org for a patch meant
> for stable.

sta...@vger.kernel.org is the right address, you did it correct.  I
think 0-day just got a bit trigger-happy on this one for some reason,
don't worry about it.

thanks,

greg k-h

Does Linux kernel 4.18-rc5 have drivers for IEEE 802.11AC Wave 2 USB Wireless Adapters?

[Turritopsis Dohrnii Teo En Ming]

Good morning from Singapore,

Does Linux kernel 4.18-rc5 have drivers for IEEE 802.11AC Wave 2 USB Wireless 
Adapters?

I noted that Linux usually has poor support for USB Wireless AC Adapters.

Thank you. 
 
 ===BEGIN SIGNATURE=== 
Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 30 Oct 2017 
[1] https://tdtemcerts.wordpress.com/ 
[2] http://tdtemcerts.blogspot.sg/ 
[3] https://www.scribd.com/user/270125049/Teo-En-Ming 
===END SIGNATURE=== 

Does Linux kernel 4.18-rc5 have drivers for IEEE 802.11AC Wave 2 USB Wireless Adapters?

[Turritopsis Dohrnii Teo En Ming]

Good morning from Singapore,

Does Linux kernel 4.18-rc5 have drivers for IEEE 802.11AC Wave 2 USB Wireless 
Adapters?

I noted that Linux usually has poor support for USB Wireless AC Adapters.

Thank you. 
 
 ===BEGIN SIGNATURE=== 
Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 30 Oct 2017 
[1] https://tdtemcerts.wordpress.com/ 
[2] http://tdtemcerts.blogspot.sg/ 
[3] https://www.scribd.com/user/270125049/Teo-En-Ming 
===END SIGNATURE=== 

Re: [PATCH] ASoC: da7219: Allow pdata to specify a VDDIO

[kbuild test robot]

Hi Daniel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Kurtz/ASoC-da7219-Allow-pdata-to-specify-a-VDDIO/20180721-082411
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
for-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   sound/soc/codecs/da7219.c:440:44: sparse: cast to restricted __le16
   sound/soc/codecs/da7219.c:461:13: sparse: incorrect type in assignment 
(different base types) @@expected unsigned short [unsigned] [usertype] val 
@@got  short [unsigned] [usertype] val @@
   sound/soc/codecs/da7219.c:461:13:expected unsigned short [unsigned] 
[usertype] val
   sound/soc/codecs/da7219.c:461:13:got restricted __le16 [usertype] 

   sound/soc/codecs/da7219.c:817:57: sparse: dubious: x & !y
   sound/soc/codecs/da7219.c:1427:16: sparse: incorrect type in assignment 
(different base types) @@expected unsigned short [unsigned] [usertype] 
offset @@got  short [unsigned] [usertype] offset @@
   sound/soc/codecs/da7219.c:1427:16:expected unsigned short [unsigned] 
[usertype] offset
   sound/soc/codecs/da7219.c:1427:16:got restricted __le16 [usertype] 

>> sound/soc/codecs/da7219.c:1637:61: sparse: incorrect type in argument 3 
>> (different base types) @@expected char const **val @@got uchar const 
>> **val @@
   sound/soc/codecs/da7219.c:1637:61:expected char const **val
   sound/soc/codecs/da7219.c:1637:61:got unsigned int *
   sound/soc/codecs/da7219.c: In function 'da7219_fw_to_pdata':
   sound/soc/codecs/da7219.c:1637:53: error: passing argument 3 of 
'device_property_read_string' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 if (!device_property_read_string(dev, "dlg,vddio", _val32))
^
   In file included from include/linux/acpi.h:28:0,
from sound/soc/codecs/da7219.c:14:
   include/linux/property.h:49:5: note: expected 'const char **' but argument 
is of type 'u32 * {aka unsigned int *}'
int device_property_read_string(struct device *dev, const char *propname,
^~~
   cc1: some warnings being treated as errors

vim +1637 sound/soc/codecs/da7219.c

  1607  
  1608  static struct da7219_pdata *da7219_fw_to_pdata(struct snd_soc_component 
*component)
  1609  {
  1610  struct device *dev = component->dev;
  1611  struct da7219_pdata *pdata;
  1612  const char *of_str;
  1613  u32 of_val32;
  1614  
  1615  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
  1616  if (!pdata)
  1617  return NULL;
  1618  
  1619  pdata->wakeup_source = device_property_read_bool(dev, 
"wakeup-source");
  1620  
  1621  pdata->dai_clks_name = "da7219-dai-clks";
  1622  if (device_property_read_string(dev, "clock-output-names",
  1623  >dai_clks_name))
  1624  dev_warn(dev, "Using default clk name: %s\n",
  1625   pdata->dai_clks_name);
  1626  
  1627  if (device_property_read_u32(dev, "dlg,micbias-lvl", _val32) 
>= 0)
  1628  pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, 
of_val32);
  1629  else
  1630  pdata->micbias_lvl = DA7219_MICBIAS_2_2V;
  1631  
  1632  if (!device_property_read_string(dev, "dlg,mic-amp-in-sel", 
_str))
  1633  pdata->mic_amp_in_sel = da7219_fw_mic_amp_in_sel(dev, 
of_str);
  1634  else
  1635  pdata->mic_amp_in_sel = DA7219_MIC_AMP_IN_SEL_DIFF;
  1636  
> 1637  if (!device_property_read_string(dev, "dlg,vddio", _val32))
  1638  pdata->vddio = of_val32;
  1639  
  1640  return pdata;
  1641  }
  1642  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH] ASoC: da7219: Allow pdata to specify a VDDIO

[kbuild test robot]

Hi Daniel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Kurtz/ASoC-da7219-Allow-pdata-to-specify-a-VDDIO/20180721-082411
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
for-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   sound/soc/codecs/da7219.c:440:44: sparse: cast to restricted __le16
   sound/soc/codecs/da7219.c:461:13: sparse: incorrect type in assignment 
(different base types) @@expected unsigned short [unsigned] [usertype] val 
@@got  short [unsigned] [usertype] val @@
   sound/soc/codecs/da7219.c:461:13:expected unsigned short [unsigned] 
[usertype] val
   sound/soc/codecs/da7219.c:461:13:got restricted __le16 [usertype] 

   sound/soc/codecs/da7219.c:817:57: sparse: dubious: x & !y
   sound/soc/codecs/da7219.c:1427:16: sparse: incorrect type in assignment 
(different base types) @@expected unsigned short [unsigned] [usertype] 
offset @@got  short [unsigned] [usertype] offset @@
   sound/soc/codecs/da7219.c:1427:16:expected unsigned short [unsigned] 
[usertype] offset
   sound/soc/codecs/da7219.c:1427:16:got restricted __le16 [usertype] 

>> sound/soc/codecs/da7219.c:1637:61: sparse: incorrect type in argument 3 
>> (different base types) @@expected char const **val @@got uchar const 
>> **val @@
   sound/soc/codecs/da7219.c:1637:61:expected char const **val
   sound/soc/codecs/da7219.c:1637:61:got unsigned int *
   sound/soc/codecs/da7219.c: In function 'da7219_fw_to_pdata':
   sound/soc/codecs/da7219.c:1637:53: error: passing argument 3 of 
'device_property_read_string' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 if (!device_property_read_string(dev, "dlg,vddio", _val32))
^
   In file included from include/linux/acpi.h:28:0,
from sound/soc/codecs/da7219.c:14:
   include/linux/property.h:49:5: note: expected 'const char **' but argument 
is of type 'u32 * {aka unsigned int *}'
int device_property_read_string(struct device *dev, const char *propname,
^~~
   cc1: some warnings being treated as errors

vim +1637 sound/soc/codecs/da7219.c

  1607  
  1608  static struct da7219_pdata *da7219_fw_to_pdata(struct snd_soc_component 
*component)
  1609  {
  1610  struct device *dev = component->dev;
  1611  struct da7219_pdata *pdata;
  1612  const char *of_str;
  1613  u32 of_val32;
  1614  
  1615  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
  1616  if (!pdata)
  1617  return NULL;
  1618  
  1619  pdata->wakeup_source = device_property_read_bool(dev, 
"wakeup-source");
  1620  
  1621  pdata->dai_clks_name = "da7219-dai-clks";
  1622  if (device_property_read_string(dev, "clock-output-names",
  1623  >dai_clks_name))
  1624  dev_warn(dev, "Using default clk name: %s\n",
  1625   pdata->dai_clks_name);
  1626  
  1627  if (device_property_read_u32(dev, "dlg,micbias-lvl", _val32) 
>= 0)
  1628  pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, 
of_val32);
  1629  else
  1630  pdata->micbias_lvl = DA7219_MICBIAS_2_2V;
  1631  
  1632  if (!device_property_read_string(dev, "dlg,mic-amp-in-sel", 
_str))
  1633  pdata->mic_amp_in_sel = da7219_fw_mic_amp_in_sel(dev, 
of_str);
  1634  else
  1635  pdata->mic_amp_in_sel = DA7219_MIC_AMP_IN_SEL_DIFF;
  1636  
> 1637  if (!device_property_read_string(dev, "dlg,vddio", _val32))
  1638  pdata->vddio = of_val32;
  1639  
  1640  return pdata;
  1641  }
  1642  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH] arch/h8300: modify ffs(), fls() etc. functions to return int

[Randy Dunlap]

From: Randy Dunlap 

Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
printk format build warning.  This is due to hexagon's ffs() being
coded as returning long instead of int.

Fix the printk format warning by changing all of hexagon's ffx() and
flx() functions to return int instead of long.  The variables that
they return are already int instead of long.

../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument 
of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]


There are no ffx() or flx() allmodconfig build errors after making this
change.

Signed-off-by: Randy Dunlap 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
---
 arch/hexagon/include/asm/bitops.h |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- linux-next-20180717.orig/arch/hexagon/include/asm/bitops.h
+++ linux-next-20180717/arch/hexagon/include/asm/bitops.h
@@ -194,7 +194,7 @@ static inline int __test_bit(int nr, con
  *
  * Undefined if no zero exists, so code should check against ~0UL first.
  */
-static inline long ffz(int x)
+static inline int ffz(int x)
 {
int r;
 
@@ -211,7 +211,7 @@ static inline long ffz(int x)
  * This is defined the same way as ffs.
  * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
  */
-static inline long fls(int x)
+static inline int fls(int x)
 {
int r;
 
@@ -232,7 +232,7 @@ static inline long fls(int x)
  * the libc and compiler builtin ffs routines, therefore
  * differs in spirit from the above ffz (man ffs).
  */
-static inline long ffs(int x)
+static inline int ffs(int x)
 {
int r;
 
@@ -254,7 +254,7 @@ static inline long ffs(int x)
  * bits_per_long assumed to be 32
  * numbering starts at 0 I think (instead of 1 like ffs)
  */
-static inline unsigned long __ffs(unsigned long word)
+static inline int __ffs(unsigned long word)
 {
int num;
 
@@ -272,7 +272,7 @@ static inline unsigned long __ffs(unsign
  * Undefined if no set bit exists, so code should check against 0 first.
  * bits_per_long assumed to be 32
  */
-static inline unsigned long __fls(unsigned long word)
+static inline int __fls(unsigned long word)
 {
int num;
 

[PATCH] arch/h8300: modify ffs(), fls() etc. functions to return int

[Randy Dunlap]

From: Randy Dunlap 

Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
printk format build warning.  This is due to hexagon's ffs() being
coded as returning long instead of int.

Fix the printk format warning by changing all of hexagon's ffx() and
flx() functions to return int instead of long.  The variables that
they return are already int instead of long.

../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument 
of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]


There are no ffx() or flx() allmodconfig build errors after making this
change.

Signed-off-by: Randy Dunlap 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
---
 arch/hexagon/include/asm/bitops.h |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- linux-next-20180717.orig/arch/hexagon/include/asm/bitops.h
+++ linux-next-20180717/arch/hexagon/include/asm/bitops.h
@@ -194,7 +194,7 @@ static inline int __test_bit(int nr, con
  *
  * Undefined if no zero exists, so code should check against ~0UL first.
  */
-static inline long ffz(int x)
+static inline int ffz(int x)
 {
int r;
 
@@ -211,7 +211,7 @@ static inline long ffz(int x)
  * This is defined the same way as ffs.
  * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
  */
-static inline long fls(int x)
+static inline int fls(int x)
 {
int r;
 
@@ -232,7 +232,7 @@ static inline long fls(int x)
  * the libc and compiler builtin ffs routines, therefore
  * differs in spirit from the above ffz (man ffs).
  */
-static inline long ffs(int x)
+static inline int ffs(int x)
 {
int r;
 
@@ -254,7 +254,7 @@ static inline long ffs(int x)
  * bits_per_long assumed to be 32
  * numbering starts at 0 I think (instead of 1 like ffs)
  */
-static inline unsigned long __ffs(unsigned long word)
+static inline int __ffs(unsigned long word)
 {
int num;
 
@@ -272,7 +272,7 @@ static inline unsigned long __ffs(unsign
  * Undefined if no set bit exists, so code should check against 0 first.
  * bits_per_long assumed to be 32
  */
-static inline unsigned long __fls(unsigned long word)
+static inline int __fls(unsigned long word)
 {
int num;
 

Re: [PATCH] ASoC: da7219: Allow pdata to specify a VDDIO

[kbuild test robot]

Hi Daniel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Kurtz/ASoC-da7219-Allow-pdata-to-specify-a-VDDIO/20180721-082411
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
for-next
config: i386-randconfig-sb0-07210849 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   sound/soc//codecs/da7219.c: In function 'da7219_fw_to_pdata':
>> sound/soc//codecs/da7219.c:1637:53: warning: passing argument 3 of 
>> 'device_property_read_string' from incompatible pointer type
 if (!device_property_read_string(dev, "dlg,vddio", _val32))
^
   In file included from include/linux/acpi.h:28:0,
from sound/soc//codecs/da7219.c:14:
   include/linux/property.h:49:5: note: expected 'const char **' but argument 
is of type 'u32 *'
int device_property_read_string(struct device *dev, const char *propname,
^

vim +/device_property_read_string +1637 sound/soc//codecs/da7219.c

  1607  
  1608  static struct da7219_pdata *da7219_fw_to_pdata(struct snd_soc_component 
*component)
  1609  {
  1610  struct device *dev = component->dev;
  1611  struct da7219_pdata *pdata;
  1612  const char *of_str;
  1613  u32 of_val32;
  1614  
  1615  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
  1616  if (!pdata)
  1617  return NULL;
  1618  
  1619  pdata->wakeup_source = device_property_read_bool(dev, 
"wakeup-source");
  1620  
  1621  pdata->dai_clks_name = "da7219-dai-clks";
  1622  if (device_property_read_string(dev, "clock-output-names",
  1623  >dai_clks_name))
  1624  dev_warn(dev, "Using default clk name: %s\n",
  1625   pdata->dai_clks_name);
  1626  
  1627  if (device_property_read_u32(dev, "dlg,micbias-lvl", _val32) 
>= 0)
  1628  pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, 
of_val32);
  1629  else
  1630  pdata->micbias_lvl = DA7219_MICBIAS_2_2V;
  1631  
  1632  if (!device_property_read_string(dev, "dlg,mic-amp-in-sel", 
_str))
  1633  pdata->mic_amp_in_sel = da7219_fw_mic_amp_in_sel(dev, 
of_str);
  1634  else
  1635  pdata->mic_amp_in_sel = DA7219_MIC_AMP_IN_SEL_DIFF;
  1636  
> 1637  if (!device_property_read_string(dev, "dlg,vddio", _val32))
  1638  pdata->vddio = of_val32;
  1639  
  1640  return pdata;
  1641  }
  1642  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] ASoC: da7219: Allow pdata to specify a VDDIO

[kbuild test robot]

Hi Daniel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Kurtz/ASoC-da7219-Allow-pdata-to-specify-a-VDDIO/20180721-082411
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
for-next
config: i386-randconfig-sb0-07210849 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   sound/soc//codecs/da7219.c: In function 'da7219_fw_to_pdata':
>> sound/soc//codecs/da7219.c:1637:53: warning: passing argument 3 of 
>> 'device_property_read_string' from incompatible pointer type
 if (!device_property_read_string(dev, "dlg,vddio", _val32))
^
   In file included from include/linux/acpi.h:28:0,
from sound/soc//codecs/da7219.c:14:
   include/linux/property.h:49:5: note: expected 'const char **' but argument 
is of type 'u32 *'
int device_property_read_string(struct device *dev, const char *propname,
^

vim +/device_property_read_string +1637 sound/soc//codecs/da7219.c

  1607  
  1608  static struct da7219_pdata *da7219_fw_to_pdata(struct snd_soc_component 
*component)
  1609  {
  1610  struct device *dev = component->dev;
  1611  struct da7219_pdata *pdata;
  1612  const char *of_str;
  1613  u32 of_val32;
  1614  
  1615  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
  1616  if (!pdata)
  1617  return NULL;
  1618  
  1619  pdata->wakeup_source = device_property_read_bool(dev, 
"wakeup-source");
  1620  
  1621  pdata->dai_clks_name = "da7219-dai-clks";
  1622  if (device_property_read_string(dev, "clock-output-names",
  1623  >dai_clks_name))
  1624  dev_warn(dev, "Using default clk name: %s\n",
  1625   pdata->dai_clks_name);
  1626  
  1627  if (device_property_read_u32(dev, "dlg,micbias-lvl", _val32) 
>= 0)
  1628  pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, 
of_val32);
  1629  else
  1630  pdata->micbias_lvl = DA7219_MICBIAS_2_2V;
  1631  
  1632  if (!device_property_read_string(dev, "dlg,mic-amp-in-sel", 
_str))
  1633  pdata->mic_amp_in_sel = da7219_fw_mic_amp_in_sel(dev, 
of_str);
  1634  else
  1635  pdata->mic_amp_in_sel = DA7219_MIC_AMP_IN_SEL_DIFF;
  1636  
> 1637  if (!device_property_read_string(dev, "dlg,vddio", _val32))
  1638  pdata->vddio = of_val32;
  1639  
  1640  return pdata;
  1641  }
  1642  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] arch/h8300: fix kernel/dma.c build warning

[Randy Dunlap]

From: Randy Dunlap 

Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
to unsigned long to match the function parameter type.

../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of 
'gen_pool_add' makes integer from pointer without a cast [enabled by default]
../include/linux/genalloc.h:112:19: note: expected 'long unsigned int' but 
argument is of type 'void *'

Signed-off-by: Randy Dunlap 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
---
 arch/hexagon/kernel/dma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180717.orig/arch/hexagon/kernel/dma.c
+++ linux-next-20180717/arch/hexagon/kernel/dma.c
@@ -47,7 +47,7 @@ void *arch_dma_alloc(struct device *dev,
panic("Can't create %s() memory pool!", __func__);
else
gen_pool_add(coherent_pool,
-   pfn_to_virt(max_low_pfn),
+   (unsigned long)pfn_to_virt(max_low_pfn),
hexagon_coherent_pool_size, -1);
}
 

[PATCH] arch/h8300: fix kernel/dma.c build warning

[Randy Dunlap]

From: Randy Dunlap 

Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
to unsigned long to match the function parameter type.

../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of 
'gen_pool_add' makes integer from pointer without a cast [enabled by default]
../include/linux/genalloc.h:112:19: note: expected 'long unsigned int' but 
argument is of type 'void *'

Signed-off-by: Randy Dunlap 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
---
 arch/hexagon/kernel/dma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180717.orig/arch/hexagon/kernel/dma.c
+++ linux-next-20180717/arch/hexagon/kernel/dma.c
@@ -47,7 +47,7 @@ void *arch_dma_alloc(struct device *dev,
panic("Can't create %s() memory pool!", __func__);
else
gen_pool_add(coherent_pool,
-   pfn_to_virt(max_low_pfn),
+   (unsigned long)pfn_to_virt(max_low_pfn),
hexagon_coherent_pool_size, -1);
}
 

Re: [PATCH v2 08/12] sched/core: uclamp: extend cpu's cgroup controller

[Suren Baghdasaryan]

On Fri, Jul 20, 2018 at 7:37 PM, Suren Baghdasaryan  wrote:
> On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
>  wrote:
>> The cgroup's CPU controller allows to assign a specified (maximum)
>> bandwidth to the tasks of a group. However this bandwidth is defined and
>> enforced only on a temporal base, without considering the actual
>> frequency a CPU is running on. Thus, the amount of computation completed
>> by a task within an allocated bandwidth can be very different depending
>> on the actual frequency the CPU is running that task.
>> The amount of computation can be affected also by the specific CPU a
>> task is running on, especially when running on asymmetric capacity
>> systems like Arm's big.LITTLE.
>>
>> With the availability of schedutil, the scheduler is now able
>> to drive frequency selections based on actual task utilization.
>> Moreover, the utilization clamping support provides a mechanism to
>> bias the frequency selection operated by schedutil depending on
>> constraints assigned to the tasks currently RUNNABLE on a CPU.
>>
>> Give the above mechanisms, it is now possible to extend the cpu
>> controller to specify what is the minimum (or maximum) utilization which
>> a task is expected (or allowed) to generate.
>> Constraints on minimum and maximum utilization allowed for tasks in a
>> CPU cgroup can improve the control on the actual amount of CPU bandwidth
>> consumed by tasks.
>>
>> Utilization clamping constraints are useful not only to bias frequency
>> selection, when a task is running, but also to better support certain
>> scheduler decisions regarding task placement. For example, on
>> asymmetric capacity systems, a utilization clamp value can be
>> conveniently used to enforce important interactive tasks on more capable
>> CPUs or to run low priority and background tasks on more energy
>> efficient CPUs.
>>
>> The ultimate goal of utilization clamping is thus to enable:
>>
>> - boosting: by selecting an higher capacity CPU and/or higher execution
>> frequency for small tasks which are affecting the user
>> interactive experience.
>>
>> - capping: by selecting more energy efficiency CPUs or lower execution
>>frequency, for big tasks which are mainly related to
>>background activities, and thus without a direct impact on
>>the user experience.
>>
>> Thus, a proper extension of the cpu controller with utilization clamping
>> support will make this controller even more suitable for integration
>> with advanced system management software (e.g. Android).
>> Indeed, an informed user-space can provide rich information hints to the
>> scheduler regarding the tasks it's going to schedule.
>>
>> This patch extends the CPU controller by adding a couple of new
>> attributes, util_min and util_max, which can be used to enforce task's
>> utilization boosting and capping. Specifically:
>>
>> - util_min: defines the minimum utilization which should be considered,
>> e.g. when schedutil selects the frequency for a CPU while a
>> task in this group is RUNNABLE.
>> i.e. the task will run at least at a minimum frequency which
>> corresponds to the min_util utilization
>>
>> - util_max: defines the maximum utilization which should be considered,
>> e.g. when schedutil selects the frequency for a CPU while a
>> task in this group is RUNNABLE.
>> i.e. the task will run up to a maximum frequency which
>> corresponds to the max_util utilization
>>
>> These attributes:
>>
>> a) are available only for non-root nodes, both on default and legacy
>>hierarchies
>> b) do not enforce any constraints and/or dependency between the parent
>>and its child nodes, thus relying on the delegation model and
>>permission settings defined by the system management software
>> c) allow to (eventually) further restrict task-specific clamps defined
>>via sched_setattr(2)
>>
>> This patch provides the basic support to expose the two new attributes
>> and to validate their run-time updates.
>>
>> Signed-off-by: Patrick Bellasi 
>> Cc: Ingo Molnar 
>> Cc: Peter Zijlstra 
>> Cc: Tejun Heo 
>> Cc: Rafael J. Wysocki 
>> Cc: Viresh Kumar 
>> Cc: Todd Kjos 
>> Cc: Joel Fernandes 
>> Cc: Juri Lelli 
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux...@vger.kernel.org
>> ---
>>  Documentation/admin-guide/cgroup-v2.rst |  25 
>>  init/Kconfig|  22 +++
>>  kernel/sched/core.c | 186 
>>  kernel/sched/sched.h|   5 +
>>  4 files changed, 238 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
>> b/Documentation/admin-guide/cgroup-v2.rst
>> index 8a2c52d5c53b..328c011cc105 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -904,6 +904,12 @@ controller implements weight and absolute bandwidth 

Re: [PATCH v2 08/12] sched/core: uclamp: extend cpu's cgroup controller

[Suren Baghdasaryan]

On Fri, Jul 20, 2018 at 7:37 PM, Suren Baghdasaryan  wrote:
> On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
>  wrote:
>> The cgroup's CPU controller allows to assign a specified (maximum)
>> bandwidth to the tasks of a group. However this bandwidth is defined and
>> enforced only on a temporal base, without considering the actual
>> frequency a CPU is running on. Thus, the amount of computation completed
>> by a task within an allocated bandwidth can be very different depending
>> on the actual frequency the CPU is running that task.
>> The amount of computation can be affected also by the specific CPU a
>> task is running on, especially when running on asymmetric capacity
>> systems like Arm's big.LITTLE.
>>
>> With the availability of schedutil, the scheduler is now able
>> to drive frequency selections based on actual task utilization.
>> Moreover, the utilization clamping support provides a mechanism to
>> bias the frequency selection operated by schedutil depending on
>> constraints assigned to the tasks currently RUNNABLE on a CPU.
>>
>> Give the above mechanisms, it is now possible to extend the cpu
>> controller to specify what is the minimum (or maximum) utilization which
>> a task is expected (or allowed) to generate.
>> Constraints on minimum and maximum utilization allowed for tasks in a
>> CPU cgroup can improve the control on the actual amount of CPU bandwidth
>> consumed by tasks.
>>
>> Utilization clamping constraints are useful not only to bias frequency
>> selection, when a task is running, but also to better support certain
>> scheduler decisions regarding task placement. For example, on
>> asymmetric capacity systems, a utilization clamp value can be
>> conveniently used to enforce important interactive tasks on more capable
>> CPUs or to run low priority and background tasks on more energy
>> efficient CPUs.
>>
>> The ultimate goal of utilization clamping is thus to enable:
>>
>> - boosting: by selecting an higher capacity CPU and/or higher execution
>> frequency for small tasks which are affecting the user
>> interactive experience.
>>
>> - capping: by selecting more energy efficiency CPUs or lower execution
>>frequency, for big tasks which are mainly related to
>>background activities, and thus without a direct impact on
>>the user experience.
>>
>> Thus, a proper extension of the cpu controller with utilization clamping
>> support will make this controller even more suitable for integration
>> with advanced system management software (e.g. Android).
>> Indeed, an informed user-space can provide rich information hints to the
>> scheduler regarding the tasks it's going to schedule.
>>
>> This patch extends the CPU controller by adding a couple of new
>> attributes, util_min and util_max, which can be used to enforce task's
>> utilization boosting and capping. Specifically:
>>
>> - util_min: defines the minimum utilization which should be considered,
>> e.g. when schedutil selects the frequency for a CPU while a
>> task in this group is RUNNABLE.
>> i.e. the task will run at least at a minimum frequency which
>> corresponds to the min_util utilization
>>
>> - util_max: defines the maximum utilization which should be considered,
>> e.g. when schedutil selects the frequency for a CPU while a
>> task in this group is RUNNABLE.
>> i.e. the task will run up to a maximum frequency which
>> corresponds to the max_util utilization
>>
>> These attributes:
>>
>> a) are available only for non-root nodes, both on default and legacy
>>hierarchies
>> b) do not enforce any constraints and/or dependency between the parent
>>and its child nodes, thus relying on the delegation model and
>>permission settings defined by the system management software
>> c) allow to (eventually) further restrict task-specific clamps defined
>>via sched_setattr(2)
>>
>> This patch provides the basic support to expose the two new attributes
>> and to validate their run-time updates.
>>
>> Signed-off-by: Patrick Bellasi 
>> Cc: Ingo Molnar 
>> Cc: Peter Zijlstra 
>> Cc: Tejun Heo 
>> Cc: Rafael J. Wysocki 
>> Cc: Viresh Kumar 
>> Cc: Todd Kjos 
>> Cc: Joel Fernandes 
>> Cc: Juri Lelli 
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux...@vger.kernel.org
>> ---
>>  Documentation/admin-guide/cgroup-v2.rst |  25 
>>  init/Kconfig|  22 +++
>>  kernel/sched/core.c | 186 
>>  kernel/sched/sched.h|   5 +
>>  4 files changed, 238 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
>> b/Documentation/admin-guide/cgroup-v2.rst
>> index 8a2c52d5c53b..328c011cc105 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -904,6 +904,12 @@ controller implements weight and absolute bandwidth 

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

[Sinan Kaya]

On 7/20/2018 1:01 PM, Bjorn Helgaas wrote:

On Tue, Jul 10, 2018 at 02:30:11PM -0400, Sinan Kaya wrote:

On Mon, Jul 9, 2018 at 12:00 PM, Lukas Wunner  wrote:

On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:

On 7/8/18, Lukas Wunner  wrote:

On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:

My solution doesn't help if link down interrupt is observed
before the AER or DPC services.


If pciehp gets an interrupt quicker than dpc/aer, it will (at
least with my patches) remove all devices, check if the
presence bit is set, and if so, try to bring the slot up
again.


Hotplug driver should only observe a link down interrupt. Link
would come up in response to a secondary bus reset initiated by
the AER driver.


PCIe hotplug doesn't have separate Link Down and Link Up
interrupts, there is only a Link State *Changed* event.


Can you point me to the code that would bring up the link in hp
code?


I was referring to the situation with my recently posted pciehp
patches applied, in particular patch [21/32] ("PCI: pciehp: Become
resilient to missed events"):
https://patchwork.ozlabs.org/patch/930389/

When I get a presence or link changed event, I turn the slot off.
That includes removing all devices in the slot.  Because even if
the slot is still occupied or link is up, there was definitely a
change and the safe behavior is to assume that the card in the
slot is now a different one than before.


We do have a bit of mess unfortunately. Error handling and hotplug
drivers do not play nicely with each other.

When hotplug driver observes a link down, we are not checking if the
link down happened because user really wanted to remove a card or if
it was because it was originated by an error handling service such
as AER/DPC.

I'm thinking that we could potentially check if a hotplug event is
pending at the entrance of fatal error handling. If it is pending,
we could poll until the status bit clears. That should flush the
link down event.

Even then, link down indication of hotplug seem to turn off slot
power and LED.

If AER/DPC service runs after the hotplug driver, link won't come
back up as the power to the slot is turned off.

I'd like to hear about Bjorn's opinion before we throw something
else into this problem.


You guys know way more about this than I do.

I think the separation of AER/DPC/pciehp into separate drivers is
somewhat artificial because there are many interdependencies.  The
driver model doesn't apply very well because there's only one
underlying piece of hardware, which forces us to use the portdrv as
sort of a multiplexer.  The fact that portdrv claims these bridges
also means normal drivers (e.g., for performance counters) can't use
the usual model.

All that is to say that if integrating these services more tightly
would help solve this problem, I'd be open to that.


I was looking at how to destroy the portdrv for a while. It looks like
a much more bigger task to be honest. There are multiple levels of
abstractions in the code as you highlighted.

My patch solves the problem if AER interrupt happens before the hotplug
interrupt. We are masking the data link layer active interrupt. So,
AER/DPC can perform their link operations without hotplug driver race.

We need to figure out how to gracefully return inside hotplug driver
if link down happened and there is an error pending.

My first question is why hotplug driver is reacting to the link event
if there was not an actual device insertion/removal.

Would it help to keep track of presence changed interrupts since last
link event?

IF counter is 0 and device is present, hotplug driver bails out
silently as an example.



Bjorn

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

[Sinan Kaya]

On 7/20/2018 1:01 PM, Bjorn Helgaas wrote:

On Tue, Jul 10, 2018 at 02:30:11PM -0400, Sinan Kaya wrote:

On Mon, Jul 9, 2018 at 12:00 PM, Lukas Wunner  wrote:

On Mon, Jul 09, 2018 at 08:48:44AM -0600, Sinan Kaya wrote:

On 7/8/18, Lukas Wunner  wrote:

On Tue, Jul 03, 2018 at 11:43:26AM -0400, Sinan Kaya wrote:

My solution doesn't help if link down interrupt is observed
before the AER or DPC services.


If pciehp gets an interrupt quicker than dpc/aer, it will (at
least with my patches) remove all devices, check if the
presence bit is set, and if so, try to bring the slot up
again.


Hotplug driver should only observe a link down interrupt. Link
would come up in response to a secondary bus reset initiated by
the AER driver.


PCIe hotplug doesn't have separate Link Down and Link Up
interrupts, there is only a Link State *Changed* event.


Can you point me to the code that would bring up the link in hp
code?


I was referring to the situation with my recently posted pciehp
patches applied, in particular patch [21/32] ("PCI: pciehp: Become
resilient to missed events"):
https://patchwork.ozlabs.org/patch/930389/

When I get a presence or link changed event, I turn the slot off.
That includes removing all devices in the slot.  Because even if
the slot is still occupied or link is up, there was definitely a
change and the safe behavior is to assume that the card in the
slot is now a different one than before.


We do have a bit of mess unfortunately. Error handling and hotplug
drivers do not play nicely with each other.

When hotplug driver observes a link down, we are not checking if the
link down happened because user really wanted to remove a card or if
it was because it was originated by an error handling service such
as AER/DPC.

I'm thinking that we could potentially check if a hotplug event is
pending at the entrance of fatal error handling. If it is pending,
we could poll until the status bit clears. That should flush the
link down event.

Even then, link down indication of hotplug seem to turn off slot
power and LED.

If AER/DPC service runs after the hotplug driver, link won't come
back up as the power to the slot is turned off.

I'd like to hear about Bjorn's opinion before we throw something
else into this problem.


You guys know way more about this than I do.

I think the separation of AER/DPC/pciehp into separate drivers is
somewhat artificial because there are many interdependencies.  The
driver model doesn't apply very well because there's only one
underlying piece of hardware, which forces us to use the portdrv as
sort of a multiplexer.  The fact that portdrv claims these bridges
also means normal drivers (e.g., for performance counters) can't use
the usual model.

All that is to say that if integrating these services more tightly
would help solve this problem, I'd be open to that.


I was looking at how to destroy the portdrv for a while. It looks like
a much more bigger task to be honest. There are multiple levels of
abstractions in the code as you highlighted.

My patch solves the problem if AER interrupt happens before the hotplug
interrupt. We are masking the data link layer active interrupt. So,
AER/DPC can perform their link operations without hotplug driver race.

We need to figure out how to gracefully return inside hotplug driver
if link down happened and there is an error pending.

My first question is why hotplug driver is reacting to the link event
if there was not an actual device insertion/removal.

Would it help to keep track of presence changed interrupts since last
link event?

IF counter is 0 and device is present, hotplug driver bails out
silently as an example.



Bjorn

Re: [patch v4] mm, oom: fix unnecessary killing of additional processes

[Tetsuo Handa]

On 2018/07/21 7:13, David Rientjes wrote:
>>> mutex_lock(_lock);
>>> __oom_reap_task_mm(mm);
>>> mutex_unlock(_lock);
>>
>> I don't like holding oom_lock for full teardown of an mm, for an OOM 
>> victim's mm
>> might have multiple TB memory which could take long time.
>>
> 
> This patch does not involve deltas for oom_lock here, it can certainly be 
> changed on top of this patch.  I'm not attempting to address any oom_lock 
> issue here.  It should pose no roadblock for you.

You can't apply "[patch v4] mm, oom: fix unnecessary killing of additional 
processes"
because Michal's patch which removes oom_lock serialization was added to -mm 
tree.

> 
> I only propose this patch now since it fixes millions of processes being 
> oom killed unnecessarily, it was in -mm before a NACK for the most trivial 
> fixes that have now been squashed into it, and is actually tested.
> 

But I still refuse your patch because you do not test my approach.

>>
>>> -#define MAX_OOM_REAP_RETRIES 10
>>>  static void oom_reap_task(struct task_struct *tsk)
>>>  {
>>> -   int attempts = 0;
>>> struct mm_struct *mm = tsk->signal->oom_mm;
>>>  
>>> -   /* Retry the down_read_trylock(mmap_sem) a few times */
>>> -   while (attempts++ < MAX_OOM_REAP_RETRIES && !oom_reap_task_mm(tsk, mm))
>>> -   schedule_timeout_idle(HZ/10);
>>> +   /*
>>> +* If this mm has either been fully unmapped, or the oom reaper has
>>> +* given up on it, nothing left to do except drop the refcount.
>>> +*/
>>> +   if (test_bit(MMF_OOM_SKIP, >flags))
>>> +   goto drop;
>>>  
>>> -   if (attempts <= MAX_OOM_REAP_RETRIES ||
>>> -   test_bit(MMF_OOM_SKIP, >flags))
>>> -   goto done;
>>> +   /*
>>> +* If this mm has already been reaped, doing so again will not likely
>>> +* free additional memory.
>>> +*/
>>> +   if (!test_bit(MMF_UNSTABLE, >flags))
>>> +   oom_reap_task_mm(tsk, mm);
>>
>> This is still wrong. If preempted immediately after set_bit(MMF_UNSTABLE, 
>> >flags) from
>> __oom_reap_task_mm() from exit_mmap(), oom_reap_task() can give up before 
>> reclaiming any memory.
> 
> If there is a single thread holding onto the mm and has reached 
> exit_mmap() and is in the process of starting oom reaping itself, there's 
> no advantage to the oom reaper trying to oom reap it.

You might worry about situations where __oom_reap_task_mm() is a no-op.
But that is not always true. There is no point with emitting

  pr_info("oom_reaper: unable to reap pid:%d (%s)\n", ...);
  debug_show_all_locks();

noise and doing

  set_bit(MMF_OOM_SKIP, >flags);

because exit_mmap() will not release oom_lock until __oom_reap_task_mm()
completes. That is, except extra noise, there is no difference with
current behavior which sets set_bit(MMF_OOM_SKIP, >flags) after
returning from __oom_reap_task_mm().

>The thread in 
> exit_mmap() will take care of it, __oom_reap_task_mm() does not block and 
> oom_free_timeout_ms allows for enough time for that memory freeing to 
> occur.  The oom reaper will not set MMF_OOM_SKIP until the timeout has 
> expired.

Again, there is no point with emitting the noise.
And, the oom_lock serialization will be removed before your patch.

> 
> As I said before, you could make a case for extending the timeout once 
> MMF_UNSTABLE has been set.  It practice, we haven't encountered a case 
> where that matters.  But that's trivial to do if you would prefer.
> 

Again, I don't think that
"[patch v4] mm, oom: fix unnecessary killing of additional processes" can be
merged.



On 2018/07/21 7:19, David Rientjes wrote:
> On Sat, 21 Jul 2018, Tetsuo Handa wrote:
> 
>> Why [PATCH 2/2] in https://marc.info/?l=linux-mm=153119509215026=4 does 
>> not
>> solve your problem?
>>
> 
> Such an invasive patch, and completely rewrites the oom reaper.  I now 
> fully understand your frustration with the cgroup aware oom killer being 
> merged into -mm without any roadmap to actually being merged.  I agree 
> with you that it should be dropped, not sure why it has not been since 
> there is no active review on the proposed patchset from four months ago, 
> posted twice, that fixes the issues with it, or those patches being merged 
> so the damn thing can actually make progress.
> 

I'm not frustrated with the cgroup aware oom killer. I'm frustrated with
the fact that you keep ignoring my approach as "such an invasive patch"
without actually testing it.

At least, you can test up to my [PATCH 1/2] whether the cgroup aware oom killer
can be rebased on top of Michal's patches and my [PATCH 1/2].

Re: [patch v4] mm, oom: fix unnecessary killing of additional processes

[Tetsuo Handa]

On 2018/07/21 7:13, David Rientjes wrote:
>>> mutex_lock(_lock);
>>> __oom_reap_task_mm(mm);
>>> mutex_unlock(_lock);
>>
>> I don't like holding oom_lock for full teardown of an mm, for an OOM 
>> victim's mm
>> might have multiple TB memory which could take long time.
>>
> 
> This patch does not involve deltas for oom_lock here, it can certainly be 
> changed on top of this patch.  I'm not attempting to address any oom_lock 
> issue here.  It should pose no roadblock for you.

You can't apply "[patch v4] mm, oom: fix unnecessary killing of additional 
processes"
because Michal's patch which removes oom_lock serialization was added to -mm 
tree.

> 
> I only propose this patch now since it fixes millions of processes being 
> oom killed unnecessarily, it was in -mm before a NACK for the most trivial 
> fixes that have now been squashed into it, and is actually tested.
> 

But I still refuse your patch because you do not test my approach.

>>
>>> -#define MAX_OOM_REAP_RETRIES 10
>>>  static void oom_reap_task(struct task_struct *tsk)
>>>  {
>>> -   int attempts = 0;
>>> struct mm_struct *mm = tsk->signal->oom_mm;
>>>  
>>> -   /* Retry the down_read_trylock(mmap_sem) a few times */
>>> -   while (attempts++ < MAX_OOM_REAP_RETRIES && !oom_reap_task_mm(tsk, mm))
>>> -   schedule_timeout_idle(HZ/10);
>>> +   /*
>>> +* If this mm has either been fully unmapped, or the oom reaper has
>>> +* given up on it, nothing left to do except drop the refcount.
>>> +*/
>>> +   if (test_bit(MMF_OOM_SKIP, >flags))
>>> +   goto drop;
>>>  
>>> -   if (attempts <= MAX_OOM_REAP_RETRIES ||
>>> -   test_bit(MMF_OOM_SKIP, >flags))
>>> -   goto done;
>>> +   /*
>>> +* If this mm has already been reaped, doing so again will not likely
>>> +* free additional memory.
>>> +*/
>>> +   if (!test_bit(MMF_UNSTABLE, >flags))
>>> +   oom_reap_task_mm(tsk, mm);
>>
>> This is still wrong. If preempted immediately after set_bit(MMF_UNSTABLE, 
>> >flags) from
>> __oom_reap_task_mm() from exit_mmap(), oom_reap_task() can give up before 
>> reclaiming any memory.
> 
> If there is a single thread holding onto the mm and has reached 
> exit_mmap() and is in the process of starting oom reaping itself, there's 
> no advantage to the oom reaper trying to oom reap it.

You might worry about situations where __oom_reap_task_mm() is a no-op.
But that is not always true. There is no point with emitting

  pr_info("oom_reaper: unable to reap pid:%d (%s)\n", ...);
  debug_show_all_locks();

noise and doing

  set_bit(MMF_OOM_SKIP, >flags);

because exit_mmap() will not release oom_lock until __oom_reap_task_mm()
completes. That is, except extra noise, there is no difference with
current behavior which sets set_bit(MMF_OOM_SKIP, >flags) after
returning from __oom_reap_task_mm().

>The thread in 
> exit_mmap() will take care of it, __oom_reap_task_mm() does not block and 
> oom_free_timeout_ms allows for enough time for that memory freeing to 
> occur.  The oom reaper will not set MMF_OOM_SKIP until the timeout has 
> expired.

Again, there is no point with emitting the noise.
And, the oom_lock serialization will be removed before your patch.

> 
> As I said before, you could make a case for extending the timeout once 
> MMF_UNSTABLE has been set.  It practice, we haven't encountered a case 
> where that matters.  But that's trivial to do if you would prefer.
> 

Again, I don't think that
"[patch v4] mm, oom: fix unnecessary killing of additional processes" can be
merged.



On 2018/07/21 7:19, David Rientjes wrote:
> On Sat, 21 Jul 2018, Tetsuo Handa wrote:
> 
>> Why [PATCH 2/2] in https://marc.info/?l=linux-mm=153119509215026=4 does 
>> not
>> solve your problem?
>>
> 
> Such an invasive patch, and completely rewrites the oom reaper.  I now 
> fully understand your frustration with the cgroup aware oom killer being 
> merged into -mm without any roadmap to actually being merged.  I agree 
> with you that it should be dropped, not sure why it has not been since 
> there is no active review on the proposed patchset from four months ago, 
> posted twice, that fixes the issues with it, or those patches being merged 
> so the damn thing can actually make progress.
> 

I'm not frustrated with the cgroup aware oom killer. I'm frustrated with
the fact that you keep ignoring my approach as "such an invasive patch"
without actually testing it.

At least, you can test up to my [PATCH 1/2] whether the cgroup aware oom killer
can be rebased on top of Michal's patches and my [PATCH 1/2].

Re: [RFT 00/10] pinctrl: samsung: Remove ugly hack for sharing eint_wakeup_mask

[Tomasz Figa]

Hi Krzysztof,

2018年7月20日(金) 1:01 Krzysztof Kozlowski :
>
> Hi All,
>
> Tests
> =
> This is both request for comments and requests for tests. Only basic
> tests were done, including suspend to RAM on Odroid U3 (Exynos4412)
> with max7768 RTC wakeup. Please kindly test it with devices capable of
> suspending and resuming. I am mostly thinking about S5Pv210-based (Aria),
> Trats, Trats2 and TM2 (Exynos5433). Existing platforms should not be
> broken however changing external interrupt wakeup mask was not done
> on Exynos5433.
>
>
> Description
> ===
> The Exynos/S5Pv210 machine suspend code needs to write the external
> interrupt mask during suspend.  The mask is controlled by pin controller
> driver: the exynos_wkup_irq_set_wake() in IRQ chip for these wakeup
> interrupts.
>
> Therefore pinctrl driver code exposed an exynos_get_eint_wake_mask()
> function which was later used as an extern in machine code.
>
> This is quite ugly way of combining driver and machine code,
> not portable triggering Sparse and GCC warnings.
>
>
> This might break suspend capability S5Pv210 on with older DTBs (thus
> breaks DTB compatibility), however:
> 1. just "might" because in case of using older DTB, the wakeup mask
>will not be changed during suspend and default reset value (all
>interrupts non-masked) should work,
> 2. mainline support for S5Pv210 with DTB is limited and suspend
>to RAM already might be broken.

We probably should also add that it's highly unlikely that anyone
using S5PV210 actually uses a standalone DTB, since those systems
normally predated DT support in bootloaders and workarounds such as
chainloading or appended DTB are normally used.

>
>
> Dependencies
> 
> 1. The first seven patches should be taken through one tree,
>preferably samsung-pinctrl,
> 2. The DTS patch (7/10) for S5Pv210 should go into next cycle,
> 3. The remaining patches (8-10) should go after all previous,
>so probably another release cycle.
>
>
> Best regards,
> Krzysztof
>
>
> Krzysztof Kozlowski (10):
>   pinctrl: samsung: Define suspend and resume callbacks for all banks
> and SoCs
>   pinctrl: samsung: Document suspend and resume members
>   pinctrl: samsung: Document hidden requirement about one external
> wakeup
>   pinctrl: samsung: Add dedicated compatible for S5Pv210 wakeup
> interrupts
>   ARM: exynos: Define EINT_WAKEUP_MASK registers for S5Pv210 and
> Exynos5433
>   pinctrl: samsung: Write external interrupt mask
>   ARM: dts: s5pv210: Switch to S5Pv210 specific pinctrl wakeup
> compatible
>   ARM: s5pv210: Remove legacy setting of external wakeup interrupts
>   ARM: exynos: Remove legacy setting of external wakeup interrupts
>   pinctrl: samsung: Remove legacy API for handling external wakeup
> interrupts mask
>
>  .../bindings/pinctrl/samsung-pinctrl.txt   | 11 ++-
>  arch/arm/boot/dts/s5pv210.dtsi |  2 +-
>  arch/arm/mach-exynos/common.h  |  2 -
>  arch/arm/mach-exynos/suspend.c | 16 +++--
>  arch/arm/mach-s5pv210/common.h |  1 -
>  arch/arm/mach-s5pv210/pm.c | 16 +++--
>  drivers/pinctrl/samsung/pinctrl-exynos-arm.c   | 16 +
>  drivers/pinctrl/samsung/pinctrl-exynos.c   | 78 
> +++---
>  drivers/pinctrl/samsung/pinctrl-samsung.h  | 11 +++
>  include/linux/soc/samsung/exynos-regs-pmu.h|  8 ++-
>  10 files changed, 136 insertions(+), 25 deletions(-)

Looking through the series, the idea seems to be very reasonable, so:

Acked-by: Tomasz Figa 

Thanks for cleaning this up!

Best regards,
Tomasz

Re: [RFT 00/10] pinctrl: samsung: Remove ugly hack for sharing eint_wakeup_mask

[Tomasz Figa]

Hi Krzysztof,

2018年7月20日(金) 1:01 Krzysztof Kozlowski :
>
> Hi All,
>
> Tests
> =
> This is both request for comments and requests for tests. Only basic
> tests were done, including suspend to RAM on Odroid U3 (Exynos4412)
> with max7768 RTC wakeup. Please kindly test it with devices capable of
> suspending and resuming. I am mostly thinking about S5Pv210-based (Aria),
> Trats, Trats2 and TM2 (Exynos5433). Existing platforms should not be
> broken however changing external interrupt wakeup mask was not done
> on Exynos5433.
>
>
> Description
> ===
> The Exynos/S5Pv210 machine suspend code needs to write the external
> interrupt mask during suspend.  The mask is controlled by pin controller
> driver: the exynos_wkup_irq_set_wake() in IRQ chip for these wakeup
> interrupts.
>
> Therefore pinctrl driver code exposed an exynos_get_eint_wake_mask()
> function which was later used as an extern in machine code.
>
> This is quite ugly way of combining driver and machine code,
> not portable triggering Sparse and GCC warnings.
>
>
> This might break suspend capability S5Pv210 on with older DTBs (thus
> breaks DTB compatibility), however:
> 1. just "might" because in case of using older DTB, the wakeup mask
>will not be changed during suspend and default reset value (all
>interrupts non-masked) should work,
> 2. mainline support for S5Pv210 with DTB is limited and suspend
>to RAM already might be broken.

We probably should also add that it's highly unlikely that anyone
using S5PV210 actually uses a standalone DTB, since those systems
normally predated DT support in bootloaders and workarounds such as
chainloading or appended DTB are normally used.

>
>
> Dependencies
> 
> 1. The first seven patches should be taken through one tree,
>preferably samsung-pinctrl,
> 2. The DTS patch (7/10) for S5Pv210 should go into next cycle,
> 3. The remaining patches (8-10) should go after all previous,
>so probably another release cycle.
>
>
> Best regards,
> Krzysztof
>
>
> Krzysztof Kozlowski (10):
>   pinctrl: samsung: Define suspend and resume callbacks for all banks
> and SoCs
>   pinctrl: samsung: Document suspend and resume members
>   pinctrl: samsung: Document hidden requirement about one external
> wakeup
>   pinctrl: samsung: Add dedicated compatible for S5Pv210 wakeup
> interrupts
>   ARM: exynos: Define EINT_WAKEUP_MASK registers for S5Pv210 and
> Exynos5433
>   pinctrl: samsung: Write external interrupt mask
>   ARM: dts: s5pv210: Switch to S5Pv210 specific pinctrl wakeup
> compatible
>   ARM: s5pv210: Remove legacy setting of external wakeup interrupts
>   ARM: exynos: Remove legacy setting of external wakeup interrupts
>   pinctrl: samsung: Remove legacy API for handling external wakeup
> interrupts mask
>
>  .../bindings/pinctrl/samsung-pinctrl.txt   | 11 ++-
>  arch/arm/boot/dts/s5pv210.dtsi |  2 +-
>  arch/arm/mach-exynos/common.h  |  2 -
>  arch/arm/mach-exynos/suspend.c | 16 +++--
>  arch/arm/mach-s5pv210/common.h |  1 -
>  arch/arm/mach-s5pv210/pm.c | 16 +++--
>  drivers/pinctrl/samsung/pinctrl-exynos-arm.c   | 16 +
>  drivers/pinctrl/samsung/pinctrl-exynos.c   | 78 
> +++---
>  drivers/pinctrl/samsung/pinctrl-samsung.h  | 11 +++
>  include/linux/soc/samsung/exynos-regs-pmu.h|  8 ++-
>  10 files changed, 136 insertions(+), 25 deletions(-)

Looking through the series, the idea seems to be very reasonable, so:

Acked-by: Tomasz Figa 

Thanks for cleaning this up!

Best regards,
Tomasz

Re: [PATCH v2 08/12] sched/core: uclamp: extend cpu's cgroup controller

[Suren Baghdasaryan]

On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
 wrote:
> The cgroup's CPU controller allows to assign a specified (maximum)
> bandwidth to the tasks of a group. However this bandwidth is defined and
> enforced only on a temporal base, without considering the actual
> frequency a CPU is running on. Thus, the amount of computation completed
> by a task within an allocated bandwidth can be very different depending
> on the actual frequency the CPU is running that task.
> The amount of computation can be affected also by the specific CPU a
> task is running on, especially when running on asymmetric capacity
> systems like Arm's big.LITTLE.
>
> With the availability of schedutil, the scheduler is now able
> to drive frequency selections based on actual task utilization.
> Moreover, the utilization clamping support provides a mechanism to
> bias the frequency selection operated by schedutil depending on
> constraints assigned to the tasks currently RUNNABLE on a CPU.
>
> Give the above mechanisms, it is now possible to extend the cpu
> controller to specify what is the minimum (or maximum) utilization which
> a task is expected (or allowed) to generate.
> Constraints on minimum and maximum utilization allowed for tasks in a
> CPU cgroup can improve the control on the actual amount of CPU bandwidth
> consumed by tasks.
>
> Utilization clamping constraints are useful not only to bias frequency
> selection, when a task is running, but also to better support certain
> scheduler decisions regarding task placement. For example, on
> asymmetric capacity systems, a utilization clamp value can be
> conveniently used to enforce important interactive tasks on more capable
> CPUs or to run low priority and background tasks on more energy
> efficient CPUs.
>
> The ultimate goal of utilization clamping is thus to enable:
>
> - boosting: by selecting an higher capacity CPU and/or higher execution
> frequency for small tasks which are affecting the user
> interactive experience.
>
> - capping: by selecting more energy efficiency CPUs or lower execution
>frequency, for big tasks which are mainly related to
>background activities, and thus without a direct impact on
>the user experience.
>
> Thus, a proper extension of the cpu controller with utilization clamping
> support will make this controller even more suitable for integration
> with advanced system management software (e.g. Android).
> Indeed, an informed user-space can provide rich information hints to the
> scheduler regarding the tasks it's going to schedule.
>
> This patch extends the CPU controller by adding a couple of new
> attributes, util_min and util_max, which can be used to enforce task's
> utilization boosting and capping. Specifically:
>
> - util_min: defines the minimum utilization which should be considered,
> e.g. when schedutil selects the frequency for a CPU while a
> task in this group is RUNNABLE.
> i.e. the task will run at least at a minimum frequency which
> corresponds to the min_util utilization
>
> - util_max: defines the maximum utilization which should be considered,
> e.g. when schedutil selects the frequency for a CPU while a
> task in this group is RUNNABLE.
> i.e. the task will run up to a maximum frequency which
> corresponds to the max_util utilization
>
> These attributes:
>
> a) are available only for non-root nodes, both on default and legacy
>hierarchies
> b) do not enforce any constraints and/or dependency between the parent
>and its child nodes, thus relying on the delegation model and
>permission settings defined by the system management software
> c) allow to (eventually) further restrict task-specific clamps defined
>via sched_setattr(2)
>
> This patch provides the basic support to expose the two new attributes
> and to validate their run-time updates.
>
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Tejun Heo 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Todd Kjos 
> Cc: Joel Fernandes 
> Cc: Juri Lelli 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  Documentation/admin-guide/cgroup-v2.rst |  25 
>  init/Kconfig|  22 +++
>  kernel/sched/core.c | 186 
>  kernel/sched/sched.h|   5 +
>  4 files changed, 238 insertions(+)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
> b/Documentation/admin-guide/cgroup-v2.rst
> index 8a2c52d5c53b..328c011cc105 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -904,6 +904,12 @@ controller implements weight and absolute bandwidth 
> limit models for
>  normal scheduling policy and absolute bandwidth allocation model for
>  realtime scheduling policy.
>
> +Cycles distribution is based, by 

Re: [PATCH v2 08/12] sched/core: uclamp: extend cpu's cgroup controller

[Suren Baghdasaryan]

On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
 wrote:
> The cgroup's CPU controller allows to assign a specified (maximum)
> bandwidth to the tasks of a group. However this bandwidth is defined and
> enforced only on a temporal base, without considering the actual
> frequency a CPU is running on. Thus, the amount of computation completed
> by a task within an allocated bandwidth can be very different depending
> on the actual frequency the CPU is running that task.
> The amount of computation can be affected also by the specific CPU a
> task is running on, especially when running on asymmetric capacity
> systems like Arm's big.LITTLE.
>
> With the availability of schedutil, the scheduler is now able
> to drive frequency selections based on actual task utilization.
> Moreover, the utilization clamping support provides a mechanism to
> bias the frequency selection operated by schedutil depending on
> constraints assigned to the tasks currently RUNNABLE on a CPU.
>
> Give the above mechanisms, it is now possible to extend the cpu
> controller to specify what is the minimum (or maximum) utilization which
> a task is expected (or allowed) to generate.
> Constraints on minimum and maximum utilization allowed for tasks in a
> CPU cgroup can improve the control on the actual amount of CPU bandwidth
> consumed by tasks.
>
> Utilization clamping constraints are useful not only to bias frequency
> selection, when a task is running, but also to better support certain
> scheduler decisions regarding task placement. For example, on
> asymmetric capacity systems, a utilization clamp value can be
> conveniently used to enforce important interactive tasks on more capable
> CPUs or to run low priority and background tasks on more energy
> efficient CPUs.
>
> The ultimate goal of utilization clamping is thus to enable:
>
> - boosting: by selecting an higher capacity CPU and/or higher execution
> frequency for small tasks which are affecting the user
> interactive experience.
>
> - capping: by selecting more energy efficiency CPUs or lower execution
>frequency, for big tasks which are mainly related to
>background activities, and thus without a direct impact on
>the user experience.
>
> Thus, a proper extension of the cpu controller with utilization clamping
> support will make this controller even more suitable for integration
> with advanced system management software (e.g. Android).
> Indeed, an informed user-space can provide rich information hints to the
> scheduler regarding the tasks it's going to schedule.
>
> This patch extends the CPU controller by adding a couple of new
> attributes, util_min and util_max, which can be used to enforce task's
> utilization boosting and capping. Specifically:
>
> - util_min: defines the minimum utilization which should be considered,
> e.g. when schedutil selects the frequency for a CPU while a
> task in this group is RUNNABLE.
> i.e. the task will run at least at a minimum frequency which
> corresponds to the min_util utilization
>
> - util_max: defines the maximum utilization which should be considered,
> e.g. when schedutil selects the frequency for a CPU while a
> task in this group is RUNNABLE.
> i.e. the task will run up to a maximum frequency which
> corresponds to the max_util utilization
>
> These attributes:
>
> a) are available only for non-root nodes, both on default and legacy
>hierarchies
> b) do not enforce any constraints and/or dependency between the parent
>and its child nodes, thus relying on the delegation model and
>permission settings defined by the system management software
> c) allow to (eventually) further restrict task-specific clamps defined
>via sched_setattr(2)
>
> This patch provides the basic support to expose the two new attributes
> and to validate their run-time updates.
>
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Tejun Heo 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Todd Kjos 
> Cc: Joel Fernandes 
> Cc: Juri Lelli 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  Documentation/admin-guide/cgroup-v2.rst |  25 
>  init/Kconfig|  22 +++
>  kernel/sched/core.c | 186 
>  kernel/sched/sched.h|   5 +
>  4 files changed, 238 insertions(+)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
> b/Documentation/admin-guide/cgroup-v2.rst
> index 8a2c52d5c53b..328c011cc105 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -904,6 +904,12 @@ controller implements weight and absolute bandwidth 
> limit models for
>  normal scheduling policy and absolute bandwidth allocation model for
>  realtime scheduling policy.
>
> +Cycles distribution is based, by 

[lkp-robot] [confidence: ] e181ae0c5d [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at 00000000

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

commit e181ae0c5db9544de9c53239eb22bc012ce75033
Author: Pavel Tatashin 
AuthorDate: Sat Jul 14 09:15:07 2018 -0400
Commit: Linus Torvalds 
CommitDate: Sat Jul 14 11:02:20 2018 -0700

mm: zero unavailable pages before memmap init

We must zero struct pages for memory that is not backed by physical
memory, or kernel does not have access to.

Recently, there was a change which zeroed all memmap for all holes in
e820.  Unfortunately, it introduced a bug that is discussed here:

  https://www.spinics.net/lists/linux-mm/msg156764.html

Linus, also saw this bug on his machine, and confirmed that reverting
commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into
memblock.reserved") fixes the issue.

The problem is that we incorrectly zero some struct pages after they
were setup.

The fix is to zero unavailable struct pages prior to initializing of
struct pages.

A more detailed fix should come later that would avoid double zeroing
cases: one in __init_single_page(), the other one in
zero_resv_unavail().

Fixes: 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into 
memblock.reserved")
Signed-off-by: Pavel Tatashin 
Signed-off-by: Linus Torvalds 

2db39a2f49  Merge branch 'i2c/for-current' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
e181ae0c5d  mm: zero unavailable pages before memmap init
28c20cc73b  Merge tag 'drm-fixes-2018-07-20' of 
git://anongit.freedesktop.org/drm/drm
89cf553533  Add linux-next specific files for 20180720
+--++++---+
|  | 2db39a2f49 
| e181ae0c5d | 28c20cc73b | next-20180720 |
+--++++---+
| boot_successes   | 77 
| 0  | 24 | 59|
| boot_failures| 0  
| 13 | 0  | 12|
| BUG:unable_to_handle_kernel  | 0  
| 13 ||   |
| Oops:#[##]   | 0  
| 13 ||   |
| EIP:zero_resv_unavail| 0  
| 13 ||   |
| Kernel_panic-not_syncing:Fatal_exception | 0  
| 13 ||   |
| Kernel_panic-not_syncing:Fatal_exception]| 0  
| 13 ||   |
| invoked_oom-killer:gfp_mask=0x   | 0  
| 0  | 0  | 10|
| Mem-Info | 0  
| 0  | 0  | 11|
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0  
| 0  | 0  | 9 |
| BUG:soft_lockup-CPU##stuck_for#s | 0  
| 0  | 0  | 1 |
| EIP:_raw_spin_unlock_irqrestore  | 0  
| 0  | 0  | 1 |
| Kernel_panic-not_syncing:softlockup:hung_tasks   | 0  
| 0  | 0  | 1 |
| Out_of_memory:Kill_process   | 0  
| 0  | 0  | 3 |
+--++++---+

[0.00]   Normal   [mem 0x0100-0x0ffd1fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x0ffd1fff]
[0.00] BUG: unable to handle kernel NULL pointer dereference at 
[0.00] *pde =  
[0.00] Oops: 0002 [#1]
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.18.0-rc4-00148-ge181ae0 #2
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[0.00] EIP: zero_resv_unavail+0x92/0xed
[0.00] Code: 00 00 c1 e9 0c 39 ca 73 2e 89 d1 81 e1 00 fc ff ff 3b 0d 
c8 29 25 82 73 18 8b 3d c4 29 25 82 b9 09 00 00 00 01 df 83 04 24 01  ab 83 
54 24 04 00 42 83 c3 24 eb c1 6a 00 56 31 c9 55 68 48 9a 
[0.00] EAX:  EBX:  ECX: 0009 EDX: 
[0.00] ESI: 81

[lkp-robot] [confidence: ] e181ae0c5d [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at 00000000

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

commit e181ae0c5db9544de9c53239eb22bc012ce75033
Author: Pavel Tatashin 
AuthorDate: Sat Jul 14 09:15:07 2018 -0400
Commit: Linus Torvalds 
CommitDate: Sat Jul 14 11:02:20 2018 -0700

mm: zero unavailable pages before memmap init

We must zero struct pages for memory that is not backed by physical
memory, or kernel does not have access to.

Recently, there was a change which zeroed all memmap for all holes in
e820.  Unfortunately, it introduced a bug that is discussed here:

  https://www.spinics.net/lists/linux-mm/msg156764.html

Linus, also saw this bug on his machine, and confirmed that reverting
commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into
memblock.reserved") fixes the issue.

The problem is that we incorrectly zero some struct pages after they
were setup.

The fix is to zero unavailable struct pages prior to initializing of
struct pages.

A more detailed fix should come later that would avoid double zeroing
cases: one in __init_single_page(), the other one in
zero_resv_unavail().

Fixes: 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into 
memblock.reserved")
Signed-off-by: Pavel Tatashin 
Signed-off-by: Linus Torvalds 

2db39a2f49  Merge branch 'i2c/for-current' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
e181ae0c5d  mm: zero unavailable pages before memmap init
28c20cc73b  Merge tag 'drm-fixes-2018-07-20' of 
git://anongit.freedesktop.org/drm/drm
89cf553533  Add linux-next specific files for 20180720
+--++++---+
|  | 2db39a2f49 
| e181ae0c5d | 28c20cc73b | next-20180720 |
+--++++---+
| boot_successes   | 77 
| 0  | 24 | 59|
| boot_failures| 0  
| 13 | 0  | 12|
| BUG:unable_to_handle_kernel  | 0  
| 13 ||   |
| Oops:#[##]   | 0  
| 13 ||   |
| EIP:zero_resv_unavail| 0  
| 13 ||   |
| Kernel_panic-not_syncing:Fatal_exception | 0  
| 13 ||   |
| Kernel_panic-not_syncing:Fatal_exception]| 0  
| 13 ||   |
| invoked_oom-killer:gfp_mask=0x   | 0  
| 0  | 0  | 10|
| Mem-Info | 0  
| 0  | 0  | 11|
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0  
| 0  | 0  | 9 |
| BUG:soft_lockup-CPU##stuck_for#s | 0  
| 0  | 0  | 1 |
| EIP:_raw_spin_unlock_irqrestore  | 0  
| 0  | 0  | 1 |
| Kernel_panic-not_syncing:softlockup:hung_tasks   | 0  
| 0  | 0  | 1 |
| Out_of_memory:Kill_process   | 0  
| 0  | 0  | 3 |
+--++++---+

[0.00]   Normal   [mem 0x0100-0x0ffd1fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x0ffd1fff]
[0.00] BUG: unable to handle kernel NULL pointer dereference at 
[0.00] *pde =  
[0.00] Oops: 0002 [#1]
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.18.0-rc4-00148-ge181ae0 #2
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[0.00] EIP: zero_resv_unavail+0x92/0xed
[0.00] Code: 00 00 c1 e9 0c 39 ca 73 2e 89 d1 81 e1 00 fc ff ff 3b 0d 
c8 29 25 82 73 18 8b 3d c4 29 25 82 b9 09 00 00 00 01 df 83 04 24 01  ab 83 
54 24 04 00 42 83 c3 24 eb c1 6a 00 56 31 c9 55 68 48 9a 
[0.00] EAX:  EBX:  ECX: 0009 EDX: 
[0.00] ESI: 81

[PATCH] tools/lib/api/fs/fs.c: Fix misuse of strncpy()

[Ben Hutchings]

gcc 8 reports:

In function 'fs__env_override',
inlined from 'fs__get_mountpoint' at fs/fs.c:228:6:
fs/fs.c:222:2: error: 'strncpy' specified bound 4096 equals destination size 
[-Werror=stringop-truncation]
  strncpy(fs->path, override_path, sizeof(fs->path));
  ^~

I'm not convinced it makes sense to truncate the copied string here,
but since we're already doing so let's ensure it's still null-
terminated.  Use strlcpy() instead.

Signed-off-by: Ben Hutchings 
Cc: sta...@vger.kernel.org
---
 tools/lib/api/fs/fs.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "fs.h"
 #include "debug-internal.h"
@@ -219,7 +220,7 @@ static bool fs__env_override(struct fs *
return false;
 
fs->found = true;
-   strncpy(fs->path, override_path, sizeof(fs->path));
+   strlcpy(fs->path, override_path, sizeof(fs->path));
return true;
 }
 


signature.asc
Description: Digital signature

[PATCH] tools/lib/api/fs/fs.c: Fix misuse of strncpy()

[Ben Hutchings]

gcc 8 reports:

In function 'fs__env_override',
inlined from 'fs__get_mountpoint' at fs/fs.c:228:6:
fs/fs.c:222:2: error: 'strncpy' specified bound 4096 equals destination size 
[-Werror=stringop-truncation]
  strncpy(fs->path, override_path, sizeof(fs->path));
  ^~

I'm not convinced it makes sense to truncate the copied string here,
but since we're already doing so let's ensure it's still null-
terminated.  Use strlcpy() instead.

Signed-off-by: Ben Hutchings 
Cc: sta...@vger.kernel.org
---
 tools/lib/api/fs/fs.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "fs.h"
 #include "debug-internal.h"
@@ -219,7 +220,7 @@ static bool fs__env_override(struct fs *
return false;
 
fs->found = true;
-   strncpy(fs->path, override_path, sizeof(fs->path));
+   strlcpy(fs->path, override_path, sizeof(fs->path));
return true;
 }
 


signature.asc
Description: Digital signature

Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3

[陈华才]

Hi, Paul,
 
SFB can improve the memory bandwidth as much as 30%, and we are planning to 
enable SFB by default. So, we want to control cpu_relax() under 
CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT.

Huacai
 
-- Original --
From:  "Paul Burton";
Date:  Fri, Jul 20, 2018 05:15 AM
To:  "Huacai Chen"; 
Cc:  "Ralf Baechle"; "James Hogan"; 
"linux-mips"; "Fuxin Zhang"; 
"wuzhangjin"; "stable"; "Alan 
Stern"; "Andrea 
Parri"; "Will Deacon"; 
"Peter Zijlstra"; "Boqun Feng"; 
"Nicholas Piggin"; "David Howells"; 
"Jade Alglave"; "Luc Maranget"; 
"Paul E. McKenney"; "Akira 
Yokosawa"; "LKML"; 
Subject:  Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3

 
Hi Huacai,

On Wed, Jul 18, 2018 at 09:15:46AM +0800, Huacai Chen wrote:
> >> diff --git a/arch/mips/include/asm/processor.h 
> >> b/arch/mips/include/asm/processor.h
> >> index af34afb..a8c4a3a 100644
> >> --- a/arch/mips/include/asm/processor.h
> >> +++ b/arch/mips/include/asm/processor.h
> >> @@ -386,7 +386,17 @@ unsigned long get_wchan(struct task_struct *p);
> >>  #define KSTK_ESP(tsk) (task_pt_regs(tsk)->regs[29])
> >>  #define KSTK_STATUS(tsk) (task_pt_regs(tsk)->cp0_status)
> >>
> >> +#ifdef CONFIG_CPU_LOONGSON3
> >> +/*
> >> + * Loongson-3's SFB (Store-Fill-Buffer) may get starved when stuck in a 
> >> read
> >> + * loop. Since spin loops of any kind should have a cpu_relax() in them, 
> >> force
> >> + * a Store-Fill-Buffer flush from cpu_relax() such that any pending 
> >> writes will
> >> + * become available as expected.
> >> + */
> >
> > I think "may starve writes" or "may queue writes indefinitely" would be
> > clearer than "may get starved".
>
> Need I change the comment and resend? Or you change the comment and get 
> merged?

I'm happy to fix up the comment - but have a couple more questions.

Looking into the history, would it be fair to say that this is only a
problem after commit 1e820da3c9af ("MIPS: Loongson-3: Introduce
CONFIG_LOONGSON3_ENHANCEMENT") when CONFIG_LOONGSON3_ENHANCEMENT=y,
which adds code to enable the SFB?

If so would it make sense to use CONFIG_LOONGSON3_ENHANCEMENT to select
the use of smp_mb()?

How much does performance gain does enabling the SFB give you? Would it
be reasonable to just disable it, rather than using this workaround?

Thanks,
Paul

Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3

[陈华才]

Hi, Paul,
 
SFB can improve the memory bandwidth as much as 30%, and we are planning to 
enable SFB by default. So, we want to control cpu_relax() under 
CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT.

Huacai
 
-- Original --
From:  "Paul Burton";
Date:  Fri, Jul 20, 2018 05:15 AM
To:  "Huacai Chen"; 
Cc:  "Ralf Baechle"; "James Hogan"; 
"linux-mips"; "Fuxin Zhang"; 
"wuzhangjin"; "stable"; "Alan 
Stern"; "Andrea 
Parri"; "Will Deacon"; 
"Peter Zijlstra"; "Boqun Feng"; 
"Nicholas Piggin"; "David Howells"; 
"Jade Alglave"; "Luc Maranget"; 
"Paul E. McKenney"; "Akira 
Yokosawa"; "LKML"; 
Subject:  Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3

 
Hi Huacai,

On Wed, Jul 18, 2018 at 09:15:46AM +0800, Huacai Chen wrote:
> >> diff --git a/arch/mips/include/asm/processor.h 
> >> b/arch/mips/include/asm/processor.h
> >> index af34afb..a8c4a3a 100644
> >> --- a/arch/mips/include/asm/processor.h
> >> +++ b/arch/mips/include/asm/processor.h
> >> @@ -386,7 +386,17 @@ unsigned long get_wchan(struct task_struct *p);
> >>  #define KSTK_ESP(tsk) (task_pt_regs(tsk)->regs[29])
> >>  #define KSTK_STATUS(tsk) (task_pt_regs(tsk)->cp0_status)
> >>
> >> +#ifdef CONFIG_CPU_LOONGSON3
> >> +/*
> >> + * Loongson-3's SFB (Store-Fill-Buffer) may get starved when stuck in a 
> >> read
> >> + * loop. Since spin loops of any kind should have a cpu_relax() in them, 
> >> force
> >> + * a Store-Fill-Buffer flush from cpu_relax() such that any pending 
> >> writes will
> >> + * become available as expected.
> >> + */
> >
> > I think "may starve writes" or "may queue writes indefinitely" would be
> > clearer than "may get starved".
>
> Need I change the comment and resend? Or you change the comment and get 
> merged?

I'm happy to fix up the comment - but have a couple more questions.

Looking into the history, would it be fair to say that this is only a
problem after commit 1e820da3c9af ("MIPS: Loongson-3: Introduce
CONFIG_LOONGSON3_ENHANCEMENT") when CONFIG_LOONGSON3_ENHANCEMENT=y,
which adds code to enable the SFB?

If so would it make sense to use CONFIG_LOONGSON3_ENHANCEMENT to select
the use of smp_mb()?

How much does performance gain does enabling the SFB give you? Would it
be reasonable to just disable it, rather than using this workaround?

Thanks,
Paul

Re: [PATCH 4/7] arm64: dts: Add Tegra186 sdmmc pinctrl voltage states

[kbuild test robot]

Hi Aapo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Aapo-Vienamo/Tegra-SDHCI-enable-1-8-V-signaling-on-Tegar210-and-Tegra186/20180721-043249
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
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
GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   In file included from arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi:2:0,
from arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts:6:
>> arch/arm64/boot/dts/nvidia/tegra186.dtsi:7:10: fatal error: 
>> dt-bindings/pinctrl/pinctrl-tegra-io-pad.h: No such file or directory
#include 
 ^~~~
   compilation terminated.

vim +7 arch/arm64/boot/dts/nvidia/tegra186.dtsi

   > 7  #include 
 8  #include 
 9  #include 
10  #include 
11  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 4/7] arm64: dts: Add Tegra186 sdmmc pinctrl voltage states

[kbuild test robot]

Hi Aapo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Aapo-Vienamo/Tegra-SDHCI-enable-1-8-V-signaling-on-Tegar210-and-Tegra186/20180721-043249
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
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
GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   In file included from arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi:2:0,
from arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts:6:
>> arch/arm64/boot/dts/nvidia/tegra186.dtsi:7:10: fatal error: 
>> dt-bindings/pinctrl/pinctrl-tegra-io-pad.h: No such file or directory
#include 
 ^~~~
   compilation terminated.

vim +7 arch/arm64/boot/dts/nvidia/tegra186.dtsi

   > 7  #include 
 8  #include 
 9  #include 
10  #include 
11  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 07/12] sched/core: uclamp: enforce last task UCLAMP_MAX

[Suren Baghdasaryan]

Hi Patrick,

On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
 wrote:
> When a util_max clamped task sleeps, its clamp constraints are removed
> from the CPU. However, the blocked utilization on that CPU can still be
> higher than the max clamp value enforced while that task was running.
> This max clamp removal when a CPU is going to be idle could thus allow
> unwanted CPU frequency increases, right while the task is not running.
>
> This can happen, for example, where there is another (smaller) task
> running on a different CPU of the same frequency domain.
> In this case, when we aggregates the utilization of all the CPUs in a

typo: we aggregate

> shared frequency domain, schedutil can still see the full non clamped
> blocked utilization of all the CPUs and thus eventually increase the
> frequency.
>
> Let's fix this by using:
>
>uclamp_cpu_put_id(UCLAMP_MAX)
>   uclamp_cpu_update(last_clamp_value)
>
> to detect when a CPU has no more RUNNABLE clamped tasks and to flag this
> condition. Thus, while a CPU is idle, we can still enforce the last used
> clamp value for it.
>
> To the contrary, we do not track any UCLAMP_MIN since, while a CPU is
> idle, we don't want to enforce any minimum frequency
> Indeed, we relay just on blocked load decay to smoothly reduce the

typo: We rely

> frequency.
>
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Todd Kjos 
> Cc: Joel Fernandes 
> Cc: Juri Lelli 
> Cc: Dietmar Eggemann 
> Cc: Morten Rasmussen 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  kernel/sched/core.c  | 30 ++
>  kernel/sched/sched.h |  2 ++
>  2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b2424eea7990..0cb6e0aa4faa 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -930,7 +930,8 @@ uclamp_group_find(int clamp_id, unsigned int clamp_value)
>   * For the specified clamp index, this method computes the new CPU 
> utilization
>   * clamp to use until the next change on the set of RUNNABLE tasks on that 
> CPU.
>   */
> -static inline void uclamp_cpu_update(struct rq *rq, int clamp_id)
> +static inline void uclamp_cpu_update(struct rq *rq, int clamp_id,
> +unsigned int last_clamp_value)
>  {
> struct uclamp_group *uc_grp = >uclamp.group[clamp_id][0];
> int max_value = UCLAMP_NONE;
> @@ -948,6 +949,19 @@ static inline void uclamp_cpu_update(struct rq *rq, int 
> clamp_id)
> if (max_value >= SCHED_CAPACITY_SCALE)
> break;
> }
> +
> +   /*
> +* Just for the UCLAMP_MAX value, in case there are no RUNNABLE
> +* task, we keep the CPU clamped to the last task's clamp value.
> +* This avoids frequency spikes to MAX when one CPU, with an high
> +* blocked utilization, sleeps and another CPU, in the same frequency
> +* domain, do not see anymore the clamp on the first CPU.
> +*/
> +   if (clamp_id == UCLAMP_MAX && max_value == UCLAMP_NONE) {
> +   rq->uclamp.flags |= UCLAMP_FLAG_IDLE;
> +   max_value = last_clamp_value;
> +   }
> +
> rq->uclamp.value[clamp_id] = max_value;
>  }
>
> @@ -977,13 +991,21 @@ static inline void uclamp_cpu_get_id(struct task_struct 
> *p,
> uc_grp = >uclamp.group[clamp_id][0];
> uc_grp[group_id].tasks += 1;
>
> +   /* Force clamp update on idle exit */
> +   uc_cpu = >uclamp;
> +   clamp_value = p->uclamp[clamp_id].value;
> +   if (unlikely(uc_cpu->flags & UCLAMP_FLAG_IDLE)) {

The condition below is not needed because UCLAMP_FLAG_IDLE is set only
for UCLAMP_MAX clamp_id, therefore the above condition already covers
the one below.

> +   if (clamp_id == UCLAMP_MAX)
> +   uc_cpu->flags &= ~UCLAMP_FLAG_IDLE;
> +   uc_cpu->value[clamp_id] = clamp_value;
> +   return;
> +   }
> +
> /*
>  * If this is the new max utilization clamp value, then we can update
>  * straight away the CPU clamp value. Otherwise, the current CPU clamp
>  * value is still valid and we are done.
>  */
> -   uc_cpu = >uclamp;
> -   clamp_value = p->uclamp[clamp_id].value;
> if (uc_cpu->value[clamp_id] < clamp_value)
> uc_cpu->value[clamp_id] = clamp_value;
>  }
> @@ -1028,7 +1050,7 @@ static inline void uclamp_cpu_put_id(struct task_struct 
> *p,
> uc_cpu = >uclamp;
> clamp_value = uc_grp[group_id].value;
> if (clamp_value >= uc_cpu->value[clamp_id])
> -   uclamp_cpu_update(rq, clamp_id);
> +   uclamp_cpu_update(rq, clamp_id, clamp_value);
>  }
>
>  /**
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 1207add36478..7e4f10c507b7 100644
> --- a/kernel/sched/sched.h
> +++ 

Re: [PATCH v2 07/12] sched/core: uclamp: enforce last task UCLAMP_MAX

[Suren Baghdasaryan]

Hi Patrick,

On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
 wrote:
> When a util_max clamped task sleeps, its clamp constraints are removed
> from the CPU. However, the blocked utilization on that CPU can still be
> higher than the max clamp value enforced while that task was running.
> This max clamp removal when a CPU is going to be idle could thus allow
> unwanted CPU frequency increases, right while the task is not running.
>
> This can happen, for example, where there is another (smaller) task
> running on a different CPU of the same frequency domain.
> In this case, when we aggregates the utilization of all the CPUs in a

typo: we aggregate

> shared frequency domain, schedutil can still see the full non clamped
> blocked utilization of all the CPUs and thus eventually increase the
> frequency.
>
> Let's fix this by using:
>
>uclamp_cpu_put_id(UCLAMP_MAX)
>   uclamp_cpu_update(last_clamp_value)
>
> to detect when a CPU has no more RUNNABLE clamped tasks and to flag this
> condition. Thus, while a CPU is idle, we can still enforce the last used
> clamp value for it.
>
> To the contrary, we do not track any UCLAMP_MIN since, while a CPU is
> idle, we don't want to enforce any minimum frequency
> Indeed, we relay just on blocked load decay to smoothly reduce the

typo: We rely

> frequency.
>
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Todd Kjos 
> Cc: Joel Fernandes 
> Cc: Juri Lelli 
> Cc: Dietmar Eggemann 
> Cc: Morten Rasmussen 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  kernel/sched/core.c  | 30 ++
>  kernel/sched/sched.h |  2 ++
>  2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b2424eea7990..0cb6e0aa4faa 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -930,7 +930,8 @@ uclamp_group_find(int clamp_id, unsigned int clamp_value)
>   * For the specified clamp index, this method computes the new CPU 
> utilization
>   * clamp to use until the next change on the set of RUNNABLE tasks on that 
> CPU.
>   */
> -static inline void uclamp_cpu_update(struct rq *rq, int clamp_id)
> +static inline void uclamp_cpu_update(struct rq *rq, int clamp_id,
> +unsigned int last_clamp_value)
>  {
> struct uclamp_group *uc_grp = >uclamp.group[clamp_id][0];
> int max_value = UCLAMP_NONE;
> @@ -948,6 +949,19 @@ static inline void uclamp_cpu_update(struct rq *rq, int 
> clamp_id)
> if (max_value >= SCHED_CAPACITY_SCALE)
> break;
> }
> +
> +   /*
> +* Just for the UCLAMP_MAX value, in case there are no RUNNABLE
> +* task, we keep the CPU clamped to the last task's clamp value.
> +* This avoids frequency spikes to MAX when one CPU, with an high
> +* blocked utilization, sleeps and another CPU, in the same frequency
> +* domain, do not see anymore the clamp on the first CPU.
> +*/
> +   if (clamp_id == UCLAMP_MAX && max_value == UCLAMP_NONE) {
> +   rq->uclamp.flags |= UCLAMP_FLAG_IDLE;
> +   max_value = last_clamp_value;
> +   }
> +
> rq->uclamp.value[clamp_id] = max_value;
>  }
>
> @@ -977,13 +991,21 @@ static inline void uclamp_cpu_get_id(struct task_struct 
> *p,
> uc_grp = >uclamp.group[clamp_id][0];
> uc_grp[group_id].tasks += 1;
>
> +   /* Force clamp update on idle exit */
> +   uc_cpu = >uclamp;
> +   clamp_value = p->uclamp[clamp_id].value;
> +   if (unlikely(uc_cpu->flags & UCLAMP_FLAG_IDLE)) {

The condition below is not needed because UCLAMP_FLAG_IDLE is set only
for UCLAMP_MAX clamp_id, therefore the above condition already covers
the one below.

> +   if (clamp_id == UCLAMP_MAX)
> +   uc_cpu->flags &= ~UCLAMP_FLAG_IDLE;
> +   uc_cpu->value[clamp_id] = clamp_value;
> +   return;
> +   }
> +
> /*
>  * If this is the new max utilization clamp value, then we can update
>  * straight away the CPU clamp value. Otherwise, the current CPU clamp
>  * value is still valid and we are done.
>  */
> -   uc_cpu = >uclamp;
> -   clamp_value = p->uclamp[clamp_id].value;
> if (uc_cpu->value[clamp_id] < clamp_value)
> uc_cpu->value[clamp_id] = clamp_value;
>  }
> @@ -1028,7 +1050,7 @@ static inline void uclamp_cpu_put_id(struct task_struct 
> *p,
> uc_cpu = >uclamp;
> clamp_value = uc_grp[group_id].value;
> if (clamp_value >= uc_cpu->value[clamp_id])
> -   uclamp_cpu_update(rq, clamp_id);
> +   uclamp_cpu_update(rq, clamp_id, clamp_value);
>  }
>
>  /**
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 1207add36478..7e4f10c507b7 100644
> --- a/kernel/sched/sched.h
> +++ 

Re: [PATCH] ASoC: da7219: Allow pdata to specify a VDDIO

[kbuild test robot]

Hi Daniel,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on asoc/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Kurtz/ASoC-da7219-Allow-pdata-to-specify-a-VDDIO/20180721-082411
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
for-next
config: x86_64-randconfig-x011-201828 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   sound/soc/codecs/da7219.c: In function 'da7219_fw_to_pdata':
>> sound/soc/codecs/da7219.c:1637:53: error: passing argument 3 of 
>> 'device_property_read_string' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 if (!device_property_read_string(dev, "dlg,vddio", _val32))
^
   In file included from include/linux/acpi.h:28:0,
from sound/soc/codecs/da7219.c:14:
   include/linux/property.h:49:5: note: expected 'const char **' but argument 
is of type 'u32 * {aka unsigned int *}'
int device_property_read_string(struct device *dev, const char *propname,
^~~
   cc1: some warnings being treated as errors

vim +/device_property_read_string +1637 sound/soc/codecs/da7219.c

  1607  
  1608  static struct da7219_pdata *da7219_fw_to_pdata(struct snd_soc_component 
*component)
  1609  {
  1610  struct device *dev = component->dev;
  1611  struct da7219_pdata *pdata;
  1612  const char *of_str;
  1613  u32 of_val32;
  1614  
  1615  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
  1616  if (!pdata)
  1617  return NULL;
  1618  
  1619  pdata->wakeup_source = device_property_read_bool(dev, 
"wakeup-source");
  1620  
  1621  pdata->dai_clks_name = "da7219-dai-clks";
  1622  if (device_property_read_string(dev, "clock-output-names",
  1623  >dai_clks_name))
  1624  dev_warn(dev, "Using default clk name: %s\n",
  1625   pdata->dai_clks_name);
  1626  
  1627  if (device_property_read_u32(dev, "dlg,micbias-lvl", _val32) 
>= 0)
  1628  pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, 
of_val32);
  1629  else
  1630  pdata->micbias_lvl = DA7219_MICBIAS_2_2V;
  1631  
  1632  if (!device_property_read_string(dev, "dlg,mic-amp-in-sel", 
_str))
  1633  pdata->mic_amp_in_sel = da7219_fw_mic_amp_in_sel(dev, 
of_str);
  1634  else
  1635  pdata->mic_amp_in_sel = DA7219_MIC_AMP_IN_SEL_DIFF;
  1636  
> 1637  if (!device_property_read_string(dev, "dlg,vddio", _val32))
  1638  pdata->vddio = of_val32;
  1639  
  1640  return pdata;
  1641  }
  1642  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] ASoC: da7219: Allow pdata to specify a VDDIO

[kbuild test robot]

Hi Daniel,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on asoc/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Kurtz/ASoC-da7219-Allow-pdata-to-specify-a-VDDIO/20180721-082411
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
for-next
config: x86_64-randconfig-x011-201828 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   sound/soc/codecs/da7219.c: In function 'da7219_fw_to_pdata':
>> sound/soc/codecs/da7219.c:1637:53: error: passing argument 3 of 
>> 'device_property_read_string' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 if (!device_property_read_string(dev, "dlg,vddio", _val32))
^
   In file included from include/linux/acpi.h:28:0,
from sound/soc/codecs/da7219.c:14:
   include/linux/property.h:49:5: note: expected 'const char **' but argument 
is of type 'u32 * {aka unsigned int *}'
int device_property_read_string(struct device *dev, const char *propname,
^~~
   cc1: some warnings being treated as errors

vim +/device_property_read_string +1637 sound/soc/codecs/da7219.c

  1607  
  1608  static struct da7219_pdata *da7219_fw_to_pdata(struct snd_soc_component 
*component)
  1609  {
  1610  struct device *dev = component->dev;
  1611  struct da7219_pdata *pdata;
  1612  const char *of_str;
  1613  u32 of_val32;
  1614  
  1615  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
  1616  if (!pdata)
  1617  return NULL;
  1618  
  1619  pdata->wakeup_source = device_property_read_bool(dev, 
"wakeup-source");
  1620  
  1621  pdata->dai_clks_name = "da7219-dai-clks";
  1622  if (device_property_read_string(dev, "clock-output-names",
  1623  >dai_clks_name))
  1624  dev_warn(dev, "Using default clk name: %s\n",
  1625   pdata->dai_clks_name);
  1626  
  1627  if (device_property_read_u32(dev, "dlg,micbias-lvl", _val32) 
>= 0)
  1628  pdata->micbias_lvl = da7219_fw_micbias_lvl(dev, 
of_val32);
  1629  else
  1630  pdata->micbias_lvl = DA7219_MICBIAS_2_2V;
  1631  
  1632  if (!device_property_read_string(dev, "dlg,mic-amp-in-sel", 
_str))
  1633  pdata->mic_amp_in_sel = da7219_fw_mic_amp_in_sel(dev, 
of_str);
  1634  else
  1635  pdata->mic_amp_in_sel = DA7219_MIC_AMP_IN_SEL_DIFF;
  1636  
> 1637  if (!device_property_read_string(dev, "dlg,vddio", _val32))
  1638  pdata->vddio = of_val32;
  1639  
  1640  return pdata;
  1641  }
  1642  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

mmotm 2018-07-20-17-49 uploaded

[akpm]

The mm-of-the-moment snapshot 2018-07-20-17-49 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.18-rc5:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* mm-memblock-add-missing-include-linux-bootmemh.patch
* mm-fix-vma_is_anonymous-false-positives.patch
* mm-fix-vma_is_anonymous-false-positives-fix.patch
* mm-fix-vma_is_anonymous-false-positives-v2.patch
* mm-fix-vma_is_anonymous-false-positives-v2-fix.patch
* maintainers-update-e-mail-address.patch
* fat-fix-memory-allocation-failure-handling-of-match_strdup.patch
* thp-fix-data-loss-when-splitting-a-file-pmd.patch
* mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch
* kvm-mm-account-shadow-page-tables-to-kmemcg.patch
* memcg-remove-memcg_cgroup-id-from-idr-on-mem_cgroup_css_alloc-failure.patch
* slub-track-number-of-slabs-irrespective-of-config_slub_debug.patch
* kasan-only-select-slub_debug-with-sysfs=y.patch
* mm-disallow-mapping-that-conflict-for-devm_memremap_pages.patch
* ipc-sem-prevent-queuestatus-tearing-in-semop.patch
* mm-fix-exports-that-inadvertently-make-put_page-export_symbol_gpl.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* dax-remove-vm_mixedmap-for-fsdax-and-device-dax.patch
* prctl-add-pr_et_pdeathsig_proc.patch
* firewire-use-64-bit-time_t-based-interfaces.patch
* ufs-use-ktime_get_real_seconds-for-sb-and-cg-timestamps.patch
* ntfs-use-timespec64-directly-for-timestamp-conversion.patch
* hpfs-extend-gmt_to_local-conversion-to-64-bit-times.patch
* spdxcheck-work-with-current-head-licenses-directory.patch
* scripts-add-python-3-compatibility-to-spdxcheckpy.patch
* ntfs-dont-disable-interrupts-during-kmap_atomic.patch
* ntfs-aops-remove-vla-usage.patch
* ntfs-decompress-remove-vla-usage.patch
* ntfs-mft-remove-vla-usage.patch
* sh-make-use-of-for_each_node_by_type.patch
* h8300-correct-signature-of-test_bit.patch
* ocfs2-return-erofs-when-filesystem-becomes-read-only.patch
* ocfs2-return-erofs-when-filesystem-becomes-read-only-checkpatch-fixes.patch
* ocfs2-clean-up-some-unnecessary-code.patch
* ocfs2-make-several-functions-and-variables-static-and-some-const.patch
* ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch
* ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery.patch
* ocfs2-dont-use-iocb-when-eiocbqueued-returns.patch
* ocfs2-fix-a-misuse-a-of-brelse-after-failing-ocfs2_check_dir_entry.patch
* ocfs2-dont-put-and-assigning-null-to-bh-allocated-outside.patch
* ocfs2-dlmglue-clean-up-timestamp-handling.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
* dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch
* 

mmotm 2018-07-20-17-49 uploaded

[akpm]

The mm-of-the-moment snapshot 2018-07-20-17-49 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.18-rc5:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* mm-memblock-add-missing-include-linux-bootmemh.patch
* mm-fix-vma_is_anonymous-false-positives.patch
* mm-fix-vma_is_anonymous-false-positives-fix.patch
* mm-fix-vma_is_anonymous-false-positives-v2.patch
* mm-fix-vma_is_anonymous-false-positives-v2-fix.patch
* maintainers-update-e-mail-address.patch
* fat-fix-memory-allocation-failure-handling-of-match_strdup.patch
* thp-fix-data-loss-when-splitting-a-file-pmd.patch
* mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch
* kvm-mm-account-shadow-page-tables-to-kmemcg.patch
* memcg-remove-memcg_cgroup-id-from-idr-on-mem_cgroup_css_alloc-failure.patch
* slub-track-number-of-slabs-irrespective-of-config_slub_debug.patch
* kasan-only-select-slub_debug-with-sysfs=y.patch
* mm-disallow-mapping-that-conflict-for-devm_memremap_pages.patch
* ipc-sem-prevent-queuestatus-tearing-in-semop.patch
* mm-fix-exports-that-inadvertently-make-put_page-export_symbol_gpl.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* dax-remove-vm_mixedmap-for-fsdax-and-device-dax.patch
* prctl-add-pr_et_pdeathsig_proc.patch
* firewire-use-64-bit-time_t-based-interfaces.patch
* ufs-use-ktime_get_real_seconds-for-sb-and-cg-timestamps.patch
* ntfs-use-timespec64-directly-for-timestamp-conversion.patch
* hpfs-extend-gmt_to_local-conversion-to-64-bit-times.patch
* spdxcheck-work-with-current-head-licenses-directory.patch
* scripts-add-python-3-compatibility-to-spdxcheckpy.patch
* ntfs-dont-disable-interrupts-during-kmap_atomic.patch
* ntfs-aops-remove-vla-usage.patch
* ntfs-decompress-remove-vla-usage.patch
* ntfs-mft-remove-vla-usage.patch
* sh-make-use-of-for_each_node_by_type.patch
* h8300-correct-signature-of-test_bit.patch
* ocfs2-return-erofs-when-filesystem-becomes-read-only.patch
* ocfs2-return-erofs-when-filesystem-becomes-read-only-checkpatch-fixes.patch
* ocfs2-clean-up-some-unnecessary-code.patch
* ocfs2-make-several-functions-and-variables-static-and-some-const.patch
* ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch
* ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery.patch
* ocfs2-dont-use-iocb-when-eiocbqueued-returns.patch
* ocfs2-fix-a-misuse-a-of-brelse-after-failing-ocfs2_check_dir_entry.patch
* ocfs2-dont-put-and-assigning-null-to-bh-allocated-outside.patch
* ocfs2-dlmglue-clean-up-timestamp-handling.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
* dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch
* 

[PATCH 2/2] Add support for CPCAP regulators on Tegra devices.

[Peter Geis]

Added support for the CPCAP power management regulator functions on
Tegra devices.
Added sw2_sw4 value tables, which provide power to the Tegra core and
aux devices.
Added the Tegra init tables and device tree compatibility match.

Signed-off-by: Peter Geis 
---
 .../bindings/regulator/cpcap-regulator.txt|  1 +
 drivers/regulator/cpcap-regulator.c   | 80 +++
 2 files changed, 81 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt 
b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt

index 675f4437ce92..3e2d33ab1731 100644
--- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
@@ -4,6 +4,7 @@ Motorola CPCAP PMIC voltage regulators
 Requires node properties:
 - "compatible" value one of:
 "motorola,cpcap-regulator"
+"motorola,tegra-cpcap-regulator"
 "motorola,mapphone-cpcap-regulator"

 Required regulator properties:
diff --git a/drivers/regulator/cpcap-regulator.c 
b/drivers/regulator/cpcap-regulator.c

index c0b1e04bd90f..cb3774be445d 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -412,6 +412,82 @@ static struct cpcap_regulator omap4_regulators[] = {
{ /* sentinel */ },
 };

+static struct cpcap_regulator tegra_regulators[] = {
+   CPCAP_REG(SW1, CPCAP_REG_S1C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW1_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+   CPCAP_REG(SW2, CPCAP_REG_S2C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW2_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x800, 0, 120),
+   CPCAP_REG(SW3, CPCAP_REG_S3C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW3_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+   CPCAP_REG(SW4, CPCAP_REG_S4C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW4_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x900, 0, 100),
+   CPCAP_REG(SW5, CPCAP_REG_S5C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW5_SEL, sw5_val_tbl,
+ 0x2a, 0, 0, 0x22, 0, 0),
+   CPCAP_REG(SW6, CPCAP_REG_S6C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW6_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+   CPCAP_REG(VCAM, CPCAP_REG_VCAMC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VCAM_SEL, vcam_val_tbl,
+ 0x87, 0x30, 4, 0x7, 0, 420),
+   CPCAP_REG(VCSI, CPCAP_REG_VCSIC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VCSI_SEL, vcsi_val_tbl,
+ 0x47, 0x10, 4, 0x7, 0, 350),
+   CPCAP_REG(VDAC, CPCAP_REG_VDACC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VDAC_SEL, vdac_val_tbl,
+ 0x87, 0x30, 4, 0x3, 0, 420),
+   CPCAP_REG(VDIG, CPCAP_REG_VDIGC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VDIG_SEL, vdig_val_tbl,
+ 0x87, 0x30, 4, 0x5, 0, 420),
+   CPCAP_REG(VFUSE, CPCAP_REG_VFUSEC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VFUSE_SEL, vfuse_val_tbl,
+ 0x80, 0xf, 0, 0x80, 0, 420),
+   CPCAP_REG(VHVIO, CPCAP_REG_VHVIOC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VHVIO_SEL, vhvio_val_tbl,
+ 0x17, 0, 0, 0x2, 0, 0),
+   CPCAP_REG(VSDIO, CPCAP_REG_VSDIOC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VSDIO_SEL, vsdio_val_tbl,
+ 0x87, 0x38, 3, 0x2, 0, 420),
+   CPCAP_REG(VPLL, CPCAP_REG_VPLLC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VPLL_SEL, vpll_val_tbl,
+ 0x43, 0x18, 3, 0x1, 0, 420),
+   CPCAP_REG(VRF1, CPCAP_REG_VRF1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF1_SEL, vrf1_val_tbl,
+ 0xac, 0x2, 1, 0xc, 0, 10),
+   CPCAP_REG(VRF2, CPCAP_REG_VRF2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF2_SEL, vrf2_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 10),
+   CPCAP_REG(VRFREF, CPCAP_REG_VRFREFC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRFREF_SEL, vrfref_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+   CPCAP_REG(VWLAN1, CPCAP_REG_VWLAN1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN1_SEL, vwlan1_val_tbl,
+ 0x47, 0x10, 4, 0x5, 0, 420),
+   CPCAP_REG(VWLAN2, CPCAP_REG_VWLAN2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN2_SEL, vwlan2_val_tbl,
+ 0x20c, 0xc0, 6, 0x8, 0, 420),
+   CPCAP_REG(VSIM, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0x, vsim_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+   CPCAP_REG(VSIMCARD, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0x, vsimcard_val_tbl,
+ 0x1e80, 0x8, 3, 0x1e00, 0, 420),
+   CPCAP_REG(VVIB, CPCAP_REG_VVIBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VVIB_SEL, vvib_val_tbl,
+ 0x1, 0xc, 2, 0, 0x1, 500),
+   CPCAP_REG(VUSB, CPCAP_REG_VUSBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VUSB_SEL, vusb_val_tbl,
+ 0x11c, 

[PATCH 2/2] Add support for CPCAP regulators on Tegra devices.

[Peter Geis]

Added support for the CPCAP power management regulator functions on
Tegra devices.
Added sw2_sw4 value tables, which provide power to the Tegra core and
aux devices.
Added the Tegra init tables and device tree compatibility match.

Signed-off-by: Peter Geis 
---
 .../bindings/regulator/cpcap-regulator.txt|  1 +
 drivers/regulator/cpcap-regulator.c   | 80 +++
 2 files changed, 81 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt 
b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt

index 675f4437ce92..3e2d33ab1731 100644
--- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
@@ -4,6 +4,7 @@ Motorola CPCAP PMIC voltage regulators
 Requires node properties:
 - "compatible" value one of:
 "motorola,cpcap-regulator"
+"motorola,tegra-cpcap-regulator"
 "motorola,mapphone-cpcap-regulator"

 Required regulator properties:
diff --git a/drivers/regulator/cpcap-regulator.c 
b/drivers/regulator/cpcap-regulator.c

index c0b1e04bd90f..cb3774be445d 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -412,6 +412,82 @@ static struct cpcap_regulator omap4_regulators[] = {
{ /* sentinel */ },
 };

+static struct cpcap_regulator tegra_regulators[] = {
+   CPCAP_REG(SW1, CPCAP_REG_S1C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW1_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+   CPCAP_REG(SW2, CPCAP_REG_S2C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW2_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x800, 0, 120),
+   CPCAP_REG(SW3, CPCAP_REG_S3C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW3_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+   CPCAP_REG(SW4, CPCAP_REG_S4C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW4_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x900, 0, 100),
+   CPCAP_REG(SW5, CPCAP_REG_S5C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW5_SEL, sw5_val_tbl,
+ 0x2a, 0, 0, 0x22, 0, 0),
+   CPCAP_REG(SW6, CPCAP_REG_S6C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW6_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+   CPCAP_REG(VCAM, CPCAP_REG_VCAMC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VCAM_SEL, vcam_val_tbl,
+ 0x87, 0x30, 4, 0x7, 0, 420),
+   CPCAP_REG(VCSI, CPCAP_REG_VCSIC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VCSI_SEL, vcsi_val_tbl,
+ 0x47, 0x10, 4, 0x7, 0, 350),
+   CPCAP_REG(VDAC, CPCAP_REG_VDACC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VDAC_SEL, vdac_val_tbl,
+ 0x87, 0x30, 4, 0x3, 0, 420),
+   CPCAP_REG(VDIG, CPCAP_REG_VDIGC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VDIG_SEL, vdig_val_tbl,
+ 0x87, 0x30, 4, 0x5, 0, 420),
+   CPCAP_REG(VFUSE, CPCAP_REG_VFUSEC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VFUSE_SEL, vfuse_val_tbl,
+ 0x80, 0xf, 0, 0x80, 0, 420),
+   CPCAP_REG(VHVIO, CPCAP_REG_VHVIOC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VHVIO_SEL, vhvio_val_tbl,
+ 0x17, 0, 0, 0x2, 0, 0),
+   CPCAP_REG(VSDIO, CPCAP_REG_VSDIOC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VSDIO_SEL, vsdio_val_tbl,
+ 0x87, 0x38, 3, 0x2, 0, 420),
+   CPCAP_REG(VPLL, CPCAP_REG_VPLLC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VPLL_SEL, vpll_val_tbl,
+ 0x43, 0x18, 3, 0x1, 0, 420),
+   CPCAP_REG(VRF1, CPCAP_REG_VRF1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF1_SEL, vrf1_val_tbl,
+ 0xac, 0x2, 1, 0xc, 0, 10),
+   CPCAP_REG(VRF2, CPCAP_REG_VRF2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF2_SEL, vrf2_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 10),
+   CPCAP_REG(VRFREF, CPCAP_REG_VRFREFC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRFREF_SEL, vrfref_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+   CPCAP_REG(VWLAN1, CPCAP_REG_VWLAN1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN1_SEL, vwlan1_val_tbl,
+ 0x47, 0x10, 4, 0x5, 0, 420),
+   CPCAP_REG(VWLAN2, CPCAP_REG_VWLAN2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN2_SEL, vwlan2_val_tbl,
+ 0x20c, 0xc0, 6, 0x8, 0, 420),
+   CPCAP_REG(VSIM, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0x, vsim_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+   CPCAP_REG(VSIMCARD, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0x, vsimcard_val_tbl,
+ 0x1e80, 0x8, 3, 0x1e00, 0, 420),
+   CPCAP_REG(VVIB, CPCAP_REG_VVIBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VVIB_SEL, vvib_val_tbl,
+ 0x1, 0xc, 2, 0, 0x1, 500),
+   CPCAP_REG(VUSB, CPCAP_REG_VUSBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VUSB_SEL, vusb_val_tbl,
+ 0x11c, 

[PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.

[Peter Geis]

SW2 and SW4 use a shared table to provide voltage to the cpu core and
devices on Tegra hardware.
Added this table to the cpcap regulator driver as the first step to
supporting this device on Tegra.

Signed-off-by: Peter Geis 
---
 drivers/regulator/cpcap-regulator.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/regulator/cpcap-regulator.c 
b/drivers/regulator/cpcap-regulator.c

index bd910fe123d9..c0b1e04bd90f 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -271,6 +271,29 @@ static struct regulator_ops cpcap_regulator_ops = {
 };

 static const unsigned int unknown_val_tbl[] = { 0, };
+static const unsigned int sw2_sw4_val_tbl[] = { 612500, 625000, 637500,
+   65, 662500, 675000,
+   687500, 70, 712500,
+   725000, 737500, 75,
+   762500, 775000, 787500,
+   80, 812500, 825000,
+   837500, 85, 862500,
+   875000, 887500, 90,
+   912500, 925000, 937500,
+   95, 962500, 975000,
+   987500, 100, 1012500,
+   1025000, 1037500, 105,
+   1062500, 1075000, 1087500,
+   110, 1112500, 1125000,
+   1137500, 115, 1162500,
+   1175000, 1187500, 120,
+   1212500, 1225000, 1237500,
+   125, 1262500, 1275000,
+   1287500, 130, 1312500,
+   1325000, 1337500, 135,
+   1362500, 1375000, 1387500,
+   140, 1412500, 1425000,
+   1437500, 145, 
1462500, };

 static const unsigned int sw5_val_tbl[] = { 0, 505, };
 static const unsigned int vcam_val_tbl[] = { 260, 270, 280,
 290, };
--
2.17.1

[PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.

[Peter Geis]

SW2 and SW4 use a shared table to provide voltage to the cpu core and
devices on Tegra hardware.
Added this table to the cpcap regulator driver as the first step to
supporting this device on Tegra.

Signed-off-by: Peter Geis 
---
 drivers/regulator/cpcap-regulator.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/regulator/cpcap-regulator.c 
b/drivers/regulator/cpcap-regulator.c

index bd910fe123d9..c0b1e04bd90f 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -271,6 +271,29 @@ static struct regulator_ops cpcap_regulator_ops = {
 };

 static const unsigned int unknown_val_tbl[] = { 0, };
+static const unsigned int sw2_sw4_val_tbl[] = { 612500, 625000, 637500,
+   65, 662500, 675000,
+   687500, 70, 712500,
+   725000, 737500, 75,
+   762500, 775000, 787500,
+   80, 812500, 825000,
+   837500, 85, 862500,
+   875000, 887500, 90,
+   912500, 925000, 937500,
+   95, 962500, 975000,
+   987500, 100, 1012500,
+   1025000, 1037500, 105,
+   1062500, 1075000, 1087500,
+   110, 1112500, 1125000,
+   1137500, 115, 1162500,
+   1175000, 1187500, 120,
+   1212500, 1225000, 1237500,
+   125, 1262500, 1275000,
+   1287500, 130, 1312500,
+   1325000, 1337500, 135,
+   1362500, 1375000, 1387500,
+   140, 1412500, 1425000,
+   1437500, 145, 
1462500, };

 static const unsigned int sw5_val_tbl[] = { 0, 505, };
 static const unsigned int vcam_val_tbl[] = { 260, 270, 280,
 290, };
--
2.17.1

[PATCH 0/2] Add support for cpcap regulators on Tegra devices.

[Peter Geis]

Good Evening,

The CPCAP regulator driver can support various devices, but currently 
only supports Omap4 devices.
Adds the sw2 and sw4 voltage tables, which power the Tegra core, and a 
DT match for the Tegra device.

Tested on the Motorola Xoom MZ602.

Peter Geis (2):
  Add sw2_sw4 voltage table to cpcap regulator.
  Add support for CPCAP regulators on Tegra devices.

 .../bindings/regulator/cpcap-regulator.txt|   1 +
 drivers/regulator/cpcap-regulator.c   | 103 ++
 2 files changed, 104 insertions(+)

--
2.17.1

[PATCH 0/2] Add support for cpcap regulators on Tegra devices.

[Peter Geis]

Good Evening,

The CPCAP regulator driver can support various devices, but currently 
only supports Omap4 devices.
Adds the sw2 and sw4 voltage tables, which power the Tegra core, and a 
DT match for the Tegra device.

Tested on the Motorola Xoom MZ602.

Peter Geis (2):
  Add sw2_sw4 voltage table to cpcap regulator.
  Add support for CPCAP regulators on Tegra devices.

 .../bindings/regulator/cpcap-regulator.txt|   1 +
 drivers/regulator/cpcap-regulator.c   | 103 ++
 2 files changed, 104 insertions(+)

--
2.17.1

Re: [PATCH v2 02/12] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups

[Suren Baghdasaryan]

Hi Patrick,

On Fri, Jul 20, 2018 at 8:11 AM, Patrick Bellasi
 wrote:
> Hi Suren,
> thanks for the review, all good point... some more comments follow
> inline.
>
> On 19-Jul 16:51, Suren Baghdasaryan wrote:
>> On Mon, Jul 16, 2018 at 1:28 AM, Patrick Bellasi
>>  wrote:
>
> [...]
>
>> > +/**
>> > + * uclamp_group_available: checks if a clamp group is available
>> > + * @clamp_id: the utilization clamp index (i.e. min or max clamp)
>> > + * @group_id: the group index in the given clamp_id
>> > + *
>> > + * A clamp group is not free if there is at least one SE which is sing a 
>> > clamp
>>
>> Did you mean to say "single clamp"?
>
> No, it's "...at least one SE which is USING a clamp value..."
>
>> > + * value mapped on the specified clamp_id. These SEs are reference 
>> > counted by
>> > + * the se_count of a uclamp_map entry.
>> > + *
>> > + * Return: true if there are no SE's mapped on the specified clamp
>> > + * index and group
>> > + */
>> > +static inline bool uclamp_group_available(int clamp_id, int group_id)
>> > +{
>> > +   struct uclamp_map *uc_map = _maps[clamp_id][0];
>> > +
>> > +   return (uc_map[group_id].value == UCLAMP_NONE);
>>
>> The usage of UCLAMP_NONE is very confusing to me. It was not used at
>> all in the patch where it was introduced [1/12], here it's used as a
>> clamp value and in uclamp_group_find() it's used as group_id. Please
>> clarify the usage.
>
> Yes, it's meant to represent a "clamp not valid" condition, whatever
> it's a "clamp group" or a "clamp value"... perhaps the name can be
> improved.
>
>> I also feel UCLAMP_NONE does not really belong to
>> the uclamp_id enum because other elements there are indexes in
>> uclamp_maps and this one is a special value.
>
> Right, it looks a bit misplaced, I agree. I think I tried to set it
> using a #define but there was some issues I don't remember now...
> Anyway, I'll give it another go...
>
>
>> IMHO if both *group_id*
>> and *value* need a special value (-1) to represent
>> unused/uninitialized entry it would be better to use different
>> constants. Maybe UCLAMP_VAL_NONE and UCLAMP_GROUP_NONE?
>
> Yes, maybe we can use a
>
>#define UCLAMP_NOT_VALID -1
>
> and get rid the confusing enum entry.
>
> Will update it on v3.
>

Sounds good to me.

>> > +}
>
> [...]
>
>> > +/**
>> > + * uclamp_group_find: finds the group index of a utilization clamp group
>> > + * @clamp_id: the utilization clamp index (i.e. min or max clamping)
>> > + * @clamp_value: the utilization clamping value lookup for
>> > + *
>> > + * Verify if a group has been assigned to a certain clamp value and return
>> > + * its index to be used for accounting.
>> > + *
>> > + * Since only a limited number of utilization clamp groups are allowed, 
>> > if no
>> > + * groups have been assigned for the specified value, a new group is 
>> > assigned
>> > + * if possible. Otherwise an error is returned, meaning that an 
>> > additional clamp
>> > + * value is not (currently) supported.
>> > + */
>> > +static int
>> > +uclamp_group_find(int clamp_id, unsigned int clamp_value)
>> > +{
>> > +   struct uclamp_map *uc_map = _maps[clamp_id][0];
>> > +   int free_group_id = UCLAMP_NONE;
>> > +   unsigned int group_id = 0;
>> > +
>> > +   for ( ; group_id <= CONFIG_UCLAMP_GROUPS_COUNT; ++group_id) {
>> > +   /* Keep track of first free clamp group */
>> > +   if (uclamp_group_available(clamp_id, group_id)) {
>> > +   if (free_group_id == UCLAMP_NONE)
>> > +   free_group_id = group_id;
>> > +   continue;
>> > +   }
>> > +   /* Return index of first group with same clamp value */
>> > +   if (uc_map[group_id].value == clamp_value)
>> > +   return group_id;
>> > +   }
>> > +   /* Default to first free clamp group */
>> > +   if (group_id > CONFIG_UCLAMP_GROUPS_COUNT)
>>
>> Is the condition above needed? I think it's always true if you got here.
>> Also AFAIKT after the for loop you can just do:
>>
>> return (free_group_id != UCLAMP_NONE) ? free_group_id : -ENOSPC;
>
> Yes, you right... the code above can be simplified!
>
>>
>> > +   group_id = free_group_id;
>> > +   /* All clamp group already track different clamp values */
>> > +   if (group_id == UCLAMP_NONE)
>> > +   return -ENOSPC;
>> > +   return group_id;
>> > +}
>
> [...]
>
>> > +static inline void uclamp_group_put(int clamp_id, int group_id)
>> > +{
>> > +   struct uclamp_map *uc_map = _maps[clamp_id][0];
>> > +   unsigned long flags;
>> > +
>> > +   /* Ignore SE's not yet attached */
>> > +   if (group_id == UCLAMP_NONE)
>> > +   return;
>> > +
>> > +   /* Remove SE from this clamp group */
>> > +   raw_spin_lock_irqsave(_map[group_id].se_lock, flags);
>> > +   uc_map[group_id].se_count -= 1;
>>
>> If uc_map[group_id].se_count was 0 before decrement you 

Re: [PATCH v2 02/12] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups

[Suren Baghdasaryan]

Hi Patrick,

On Fri, Jul 20, 2018 at 8:11 AM, Patrick Bellasi
 wrote:
> Hi Suren,
> thanks for the review, all good point... some more comments follow
> inline.
>
> On 19-Jul 16:51, Suren Baghdasaryan wrote:
>> On Mon, Jul 16, 2018 at 1:28 AM, Patrick Bellasi
>>  wrote:
>
> [...]
>
>> > +/**
>> > + * uclamp_group_available: checks if a clamp group is available
>> > + * @clamp_id: the utilization clamp index (i.e. min or max clamp)
>> > + * @group_id: the group index in the given clamp_id
>> > + *
>> > + * A clamp group is not free if there is at least one SE which is sing a 
>> > clamp
>>
>> Did you mean to say "single clamp"?
>
> No, it's "...at least one SE which is USING a clamp value..."
>
>> > + * value mapped on the specified clamp_id. These SEs are reference 
>> > counted by
>> > + * the se_count of a uclamp_map entry.
>> > + *
>> > + * Return: true if there are no SE's mapped on the specified clamp
>> > + * index and group
>> > + */
>> > +static inline bool uclamp_group_available(int clamp_id, int group_id)
>> > +{
>> > +   struct uclamp_map *uc_map = _maps[clamp_id][0];
>> > +
>> > +   return (uc_map[group_id].value == UCLAMP_NONE);
>>
>> The usage of UCLAMP_NONE is very confusing to me. It was not used at
>> all in the patch where it was introduced [1/12], here it's used as a
>> clamp value and in uclamp_group_find() it's used as group_id. Please
>> clarify the usage.
>
> Yes, it's meant to represent a "clamp not valid" condition, whatever
> it's a "clamp group" or a "clamp value"... perhaps the name can be
> improved.
>
>> I also feel UCLAMP_NONE does not really belong to
>> the uclamp_id enum because other elements there are indexes in
>> uclamp_maps and this one is a special value.
>
> Right, it looks a bit misplaced, I agree. I think I tried to set it
> using a #define but there was some issues I don't remember now...
> Anyway, I'll give it another go...
>
>
>> IMHO if both *group_id*
>> and *value* need a special value (-1) to represent
>> unused/uninitialized entry it would be better to use different
>> constants. Maybe UCLAMP_VAL_NONE and UCLAMP_GROUP_NONE?
>
> Yes, maybe we can use a
>
>#define UCLAMP_NOT_VALID -1
>
> and get rid the confusing enum entry.
>
> Will update it on v3.
>

Sounds good to me.

>> > +}
>
> [...]
>
>> > +/**
>> > + * uclamp_group_find: finds the group index of a utilization clamp group
>> > + * @clamp_id: the utilization clamp index (i.e. min or max clamping)
>> > + * @clamp_value: the utilization clamping value lookup for
>> > + *
>> > + * Verify if a group has been assigned to a certain clamp value and return
>> > + * its index to be used for accounting.
>> > + *
>> > + * Since only a limited number of utilization clamp groups are allowed, 
>> > if no
>> > + * groups have been assigned for the specified value, a new group is 
>> > assigned
>> > + * if possible. Otherwise an error is returned, meaning that an 
>> > additional clamp
>> > + * value is not (currently) supported.
>> > + */
>> > +static int
>> > +uclamp_group_find(int clamp_id, unsigned int clamp_value)
>> > +{
>> > +   struct uclamp_map *uc_map = _maps[clamp_id][0];
>> > +   int free_group_id = UCLAMP_NONE;
>> > +   unsigned int group_id = 0;
>> > +
>> > +   for ( ; group_id <= CONFIG_UCLAMP_GROUPS_COUNT; ++group_id) {
>> > +   /* Keep track of first free clamp group */
>> > +   if (uclamp_group_available(clamp_id, group_id)) {
>> > +   if (free_group_id == UCLAMP_NONE)
>> > +   free_group_id = group_id;
>> > +   continue;
>> > +   }
>> > +   /* Return index of first group with same clamp value */
>> > +   if (uc_map[group_id].value == clamp_value)
>> > +   return group_id;
>> > +   }
>> > +   /* Default to first free clamp group */
>> > +   if (group_id > CONFIG_UCLAMP_GROUPS_COUNT)
>>
>> Is the condition above needed? I think it's always true if you got here.
>> Also AFAIKT after the for loop you can just do:
>>
>> return (free_group_id != UCLAMP_NONE) ? free_group_id : -ENOSPC;
>
> Yes, you right... the code above can be simplified!
>
>>
>> > +   group_id = free_group_id;
>> > +   /* All clamp group already track different clamp values */
>> > +   if (group_id == UCLAMP_NONE)
>> > +   return -ENOSPC;
>> > +   return group_id;
>> > +}
>
> [...]
>
>> > +static inline void uclamp_group_put(int clamp_id, int group_id)
>> > +{
>> > +   struct uclamp_map *uc_map = _maps[clamp_id][0];
>> > +   unsigned long flags;
>> > +
>> > +   /* Ignore SE's not yet attached */
>> > +   if (group_id == UCLAMP_NONE)
>> > +   return;
>> > +
>> > +   /* Remove SE from this clamp group */
>> > +   raw_spin_lock_irqsave(_map[group_id].se_lock, flags);
>> > +   uc_map[group_id].se_count -= 1;
>>
>> If uc_map[group_id].se_count was 0 before decrement you 

Re: [PATCH -next 0/2] fs/epoll: loosen irq safety when possible

[Davidlohr Bueso]

On Fri, 20 Jul 2018, Andrew Morton wrote:


Did you try measuring it on bare hardware?


I did and wasn't expecting much difference.

For a 2-socket 40-core (ht) IvyBridge on a few workloads, unfortunately
I don't have a xen environment and the results for Xen I do have (which numbers
are in patch 1) I don't have the actual workload, so cannot compare them 
directly.

1) Different configurations were used for a epoll_wait (pipes io) microbench
(http://linux-scalability.org/epoll/epoll-test.c) and shows around a 7-10%
improvement in overall total number of times the epoll_wait() loops when using
both regular and nested epolls, so very raw numbers, but measurable nonetheless.

# threads   vanilla dirty
1   1677717 1805587
2   1660510 1854064
4   1610184 1805484
8   1577696 1751222
16  1568837 1725299
32  1291532 1378463
64   752584  787368

Note that stddev is pretty small.

2) Another pipe test, which shows no real measurable improvement.
(http://www.xmailserver.org/linux-patches/pipetest.c)


>
>I'd have more confidence if we had some warning mechanism if we run
>spin_lock_irq() when IRQs are disabled, which is probably-a-bug.  But
>afaict we don't have that.  Probably for good reasons - I wonder what
>they are?


Well ignored ;)

We could open-code it locally.  Add a couple of
WARN_ON_ONCE(irqs_disabled())?  That might need re-benchmarking with
Xen but surely just reading the thing isn't too expensive?


I agree, I'll see what I can come up with and also ask the customer to test
in his setup. Bare metal would also need some new numbers I guess.

Thanks,
Davidlohr

Re: [PATCH -next 0/2] fs/epoll: loosen irq safety when possible

[Davidlohr Bueso]

On Fri, 20 Jul 2018, Andrew Morton wrote:


Did you try measuring it on bare hardware?


I did and wasn't expecting much difference.

For a 2-socket 40-core (ht) IvyBridge on a few workloads, unfortunately
I don't have a xen environment and the results for Xen I do have (which numbers
are in patch 1) I don't have the actual workload, so cannot compare them 
directly.

1) Different configurations were used for a epoll_wait (pipes io) microbench
(http://linux-scalability.org/epoll/epoll-test.c) and shows around a 7-10%
improvement in overall total number of times the epoll_wait() loops when using
both regular and nested epolls, so very raw numbers, but measurable nonetheless.

# threads   vanilla dirty
1   1677717 1805587
2   1660510 1854064
4   1610184 1805484
8   1577696 1751222
16  1568837 1725299
32  1291532 1378463
64   752584  787368

Note that stddev is pretty small.

2) Another pipe test, which shows no real measurable improvement.
(http://www.xmailserver.org/linux-patches/pipetest.c)


>
>I'd have more confidence if we had some warning mechanism if we run
>spin_lock_irq() when IRQs are disabled, which is probably-a-bug.  But
>afaict we don't have that.  Probably for good reasons - I wonder what
>they are?


Well ignored ;)

We could open-code it locally.  Add a couple of
WARN_ON_ONCE(irqs_disabled())?  That might need re-benchmarking with
Xen but surely just reading the thing isn't too expensive?


I agree, I'll see what I can come up with and also ask the customer to test
in his setup. Bare metal would also need some new numbers I guess.

Thanks,
Davidlohr

Re: [PATCH 3/7] arm64: dts: Add Tegra210 sdmmc pinctrl voltage states

[kbuild test robot]

Hi Aapo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Aapo-Vienamo/Tegra-SDHCI-enable-1-8-V-signaling-on-Tegar210-and-Tegra186/20180721-043249
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
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
GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   In file included from arch/arm64/boot/dts/nvidia/tegra210-p2530.dtsi:2:0,
from arch/arm64/boot/dts/nvidia/tegra210-p2371-.dts:4:
>> arch/arm64/boot/dts/nvidia/tegra210.dtsi:6:10: fatal error: 
>> dt-bindings/pinctrl/pinctrl-tegra-io-pad.h: No such file or directory
#include 
 ^~~~
   compilation terminated.

vim +6 arch/arm64/boot/dts/nvidia/tegra210.dtsi

   > 6  #include 
 7  #include 
 8  #include 
 9  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 3/7] arm64: dts: Add Tegra210 sdmmc pinctrl voltage states

[kbuild test robot]

Hi Aapo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Aapo-Vienamo/Tegra-SDHCI-enable-1-8-V-signaling-on-Tegar210-and-Tegra186/20180721-043249
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
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
GCC_VERSION=7.2.0 make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   In file included from arch/arm64/boot/dts/nvidia/tegra210-p2530.dtsi:2:0,
from arch/arm64/boot/dts/nvidia/tegra210-p2371-.dts:4:
>> arch/arm64/boot/dts/nvidia/tegra210.dtsi:6:10: fatal error: 
>> dt-bindings/pinctrl/pinctrl-tegra-io-pad.h: No such file or directory
#include 
 ^~~~
   compilation terminated.

vim +6 arch/arm64/boot/dts/nvidia/tegra210.dtsi

   > 6  #include 
 7  #include 
 8  #include 
 9  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] ASoC: da7219: Allow pdata to specify a VDDIO

[Daniel Kurtz]

Some systems do not have software controllable regulators driving the
DA7219's supplies, nor can they use device tree to create "always-on fixed
regulators" to easily pretend like they do.

On these systems the call to devm_regulator_bulk_get() just creates
a set of dummy registers.  Calling regulator_get_voltage() on a dummy
regulator just returns -EINVAL, in which case the DA7219 is always set up
to use the default VDDIO voltage range of 2.5-3.6V.

Provide a new device property to let such systems specify a different
VDDIO if needed (e.g., 1.8V).

Signed-off-by: Daniel Kurtz 
---

This patch tries to solve the same problem as in the following patches,
but does so in a way that doesn't require registering fixed regulators in
the audio machine-driver:
  https://patchwork.kernel.org/patch/10531097 & 10531099
  https://patchwork.kernel.org/patch/10536023/

 include/sound/da7219.h|  2 ++
 sound/soc/codecs/da7219.c | 19 +--
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/include/sound/da7219.h b/include/sound/da7219.h
index 1bfcb16f2d10ab..16ab125ad4adbf 100644
--- a/include/sound/da7219.h
+++ b/include/sound/da7219.h
@@ -38,6 +38,8 @@ struct da7219_pdata {
 
const char *dai_clks_name;
 
+   u32 vddio;
+
/* Mic */
enum da7219_micbias_voltage micbias_lvl;
enum da7219_mic_amp_in_sel mic_amp_in_sel;
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index 980a6a8bf56d38..d8f202c57f958d 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -1634,6 +1634,9 @@ static struct da7219_pdata *da7219_fw_to_pdata(struct 
snd_soc_component *compone
else
pdata->mic_amp_in_sel = DA7219_MIC_AMP_IN_SEL_DIFF;
 
+   if (!device_property_read_string(dev, "dlg,vddio", _val32))
+   pdata->vddio = of_val32;
+
return pdata;
 }
 
@@ -1717,8 +1720,12 @@ static int da7219_handle_supplies(struct 
snd_soc_component *component)
/* Determine VDDIO voltage provided */
vddio = da7219->supplies[DA7219_SUPPLY_VDDIO].consumer;
ret = regulator_get_voltage(vddio);
+   /* If regulator_get_voltage() fails, try to use vddio from pdata. */
+   if (ret < 0 && da7219->pdata)
+   ret = da7219->pdata->vddio;
if (ret < 120)
-   dev_warn(component->dev, "Invalid VDDIO voltage\n");
+   dev_warn(component->dev, "Invalid VDDIO voltage: %d mV\n",
+ret);
else if (ret < 280)
io_voltage_lvl = DA7219_IO_VOLTAGE_LEVEL_1_2V_2_8V;
 
@@ -1872,6 +1879,11 @@ static int da7219_probe(struct snd_soc_component 
*component)
mutex_init(>ctrl_lock);
mutex_init(>pll_lock);
 
+   /* Handle DT/ACPI/Platform data */
+   da7219->pdata = dev_get_platdata(component->dev);
+   if (!da7219->pdata)
+   da7219->pdata = da7219_fw_to_pdata(component);
+
/* Regulator configuration */
ret = da7219_handle_supplies(component);
if (ret)
@@ -1897,11 +1909,6 @@ static int da7219_probe(struct snd_soc_component 
*component)
break;
}
 
-   /* Handle DT/ACPI/Platform data */
-   da7219->pdata = dev_get_platdata(component->dev);
-   if (!da7219->pdata)
-   da7219->pdata = da7219_fw_to_pdata(component);
-
da7219_handle_pdata(component);
 
/* Check if MCLK provided */
-- 
2.18.0.233.g985f88cf7e-goog

[PATCH] ASoC: da7219: Allow pdata to specify a VDDIO

[Daniel Kurtz]

Some systems do not have software controllable regulators driving the
DA7219's supplies, nor can they use device tree to create "always-on fixed
regulators" to easily pretend like they do.

On these systems the call to devm_regulator_bulk_get() just creates
a set of dummy registers.  Calling regulator_get_voltage() on a dummy
regulator just returns -EINVAL, in which case the DA7219 is always set up
to use the default VDDIO voltage range of 2.5-3.6V.

Provide a new device property to let such systems specify a different
VDDIO if needed (e.g., 1.8V).

Signed-off-by: Daniel Kurtz 
---

This patch tries to solve the same problem as in the following patches,
but does so in a way that doesn't require registering fixed regulators in
the audio machine-driver:
  https://patchwork.kernel.org/patch/10531097 & 10531099
  https://patchwork.kernel.org/patch/10536023/

 include/sound/da7219.h|  2 ++
 sound/soc/codecs/da7219.c | 19 +--
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/include/sound/da7219.h b/include/sound/da7219.h
index 1bfcb16f2d10ab..16ab125ad4adbf 100644
--- a/include/sound/da7219.h
+++ b/include/sound/da7219.h
@@ -38,6 +38,8 @@ struct da7219_pdata {
 
const char *dai_clks_name;
 
+   u32 vddio;
+
/* Mic */
enum da7219_micbias_voltage micbias_lvl;
enum da7219_mic_amp_in_sel mic_amp_in_sel;
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index 980a6a8bf56d38..d8f202c57f958d 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -1634,6 +1634,9 @@ static struct da7219_pdata *da7219_fw_to_pdata(struct 
snd_soc_component *compone
else
pdata->mic_amp_in_sel = DA7219_MIC_AMP_IN_SEL_DIFF;
 
+   if (!device_property_read_string(dev, "dlg,vddio", _val32))
+   pdata->vddio = of_val32;
+
return pdata;
 }
 
@@ -1717,8 +1720,12 @@ static int da7219_handle_supplies(struct 
snd_soc_component *component)
/* Determine VDDIO voltage provided */
vddio = da7219->supplies[DA7219_SUPPLY_VDDIO].consumer;
ret = regulator_get_voltage(vddio);
+   /* If regulator_get_voltage() fails, try to use vddio from pdata. */
+   if (ret < 0 && da7219->pdata)
+   ret = da7219->pdata->vddio;
if (ret < 120)
-   dev_warn(component->dev, "Invalid VDDIO voltage\n");
+   dev_warn(component->dev, "Invalid VDDIO voltage: %d mV\n",
+ret);
else if (ret < 280)
io_voltage_lvl = DA7219_IO_VOLTAGE_LEVEL_1_2V_2_8V;
 
@@ -1872,6 +1879,11 @@ static int da7219_probe(struct snd_soc_component 
*component)
mutex_init(>ctrl_lock);
mutex_init(>pll_lock);
 
+   /* Handle DT/ACPI/Platform data */
+   da7219->pdata = dev_get_platdata(component->dev);
+   if (!da7219->pdata)
+   da7219->pdata = da7219_fw_to_pdata(component);
+
/* Regulator configuration */
ret = da7219_handle_supplies(component);
if (ret)
@@ -1897,11 +1909,6 @@ static int da7219_probe(struct snd_soc_component 
*component)
break;
}
 
-   /* Handle DT/ACPI/Platform data */
-   da7219->pdata = dev_get_platdata(component->dev);
-   if (!da7219->pdata)
-   da7219->pdata = da7219_fw_to_pdata(component);
-
da7219_handle_pdata(component);
 
/* Check if MCLK provided */
-- 
2.18.0.233.g985f88cf7e-goog

Re: [4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[Nick Desaulniers]

On Fri, Jul 20, 2018 at 5:04 PM kbuild test robot  wrote:
>
> Hi Nick,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on tip/x86/core]
> [cannot apply to v4.18-rc5 next-20180720]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Nick-Desaulniers/x86-paravirt-make-native_save_fl-extern-inline/20180721-073112
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>arch/x86/kernel/irqflags.S: Assembler messages:
> >> arch/x86/kernel/irqflags.S:22: Error: bad register name `%_ASM_ARG1'
>
> vim +22 arch/x86/kernel/irqflags.S
>
> 16
> 17  /*
> 18   * void native_restore_fl(unsigned long flags)
> 19   * %eax/%rdi: flags
> 20   */
> 21  ENTRY(native_restore_fl)
>   > 22  push %_ASM_ARG1
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

oops, probably should not have cc'ed vger.kernel.org for a patch meant
for stable.

-- 
Thanks,
~Nick Desaulniers

Re: [4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[Nick Desaulniers]

On Fri, Jul 20, 2018 at 5:04 PM kbuild test robot  wrote:
>
> Hi Nick,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on tip/x86/core]
> [cannot apply to v4.18-rc5 next-20180720]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Nick-Desaulniers/x86-paravirt-make-native_save_fl-extern-inline/20180721-073112
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>arch/x86/kernel/irqflags.S: Assembler messages:
> >> arch/x86/kernel/irqflags.S:22: Error: bad register name `%_ASM_ARG1'
>
> vim +22 arch/x86/kernel/irqflags.S
>
> 16
> 17  /*
> 18   * void native_restore_fl(unsigned long flags)
> 19   * %eax/%rdi: flags
> 20   */
> 21  ENTRY(native_restore_fl)
>   > 22  push %_ASM_ARG1
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

oops, probably should not have cc'ed vger.kernel.org for a patch meant
for stable.

-- 
Thanks,
~Nick Desaulniers

Re: [4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[kbuild test robot]

Hi Nick,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/x86/core]
[cannot apply to v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nick-Desaulniers/x86-paravirt-make-native_save_fl-extern-inline/20180721-073112
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/irqflags.S: Assembler messages:
>> arch/x86/kernel/irqflags.S:22: Error: bad register name `%_ASM_ARG1'

vim +22 arch/x86/kernel/irqflags.S

16  
17  /*
18   * void native_restore_fl(unsigned long flags)
19   * %eax/%rdi: flags
20   */
21  ENTRY(native_restore_fl)
  > 22  push %_ASM_ARG1

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[kbuild test robot]

Hi Nick,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/x86/core]
[cannot apply to v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nick-Desaulniers/x86-paravirt-make-native_save_fl-extern-inline/20180721-073112
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/irqflags.S: Assembler messages:
>> arch/x86/kernel/irqflags.S:22: Error: bad register name `%_ASM_ARG1'

vim +22 arch/x86/kernel/irqflags.S

16  
17  /*
18   * void native_restore_fl(unsigned long flags)
19   * %eax/%rdi: flags
20   */
21  ENTRY(native_restore_fl)
  > 22  push %_ASM_ARG1

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] mm: thp: remove use_zero_page sysfs knob

[Yang Shi]

On 7/20/18 2:06 PM, Kirill A. Shutemov wrote:

On Sat, Jul 21, 2018 at 02:13:50AM +0800, Yang Shi wrote:

By digging into the original review, it looks use_zero_page sysfs knob
was added to help ease-of-testing and give user a way to mitigate
refcounting overhead.

It has been a few years since the knob was added at the first place, I
think we are confident that it is stable enough. And, since commit
6fcb52a56ff60 ("thp: reduce usage of huge zero page's atomic counter"),
it looks refcounting overhead has been reduced significantly.

Other than the above, the value of the knob is always 1 (enabled by
default), I'm supposed very few people turn it off by default.

So, it sounds not worth to still keep this knob around.

I don't think that having the knob around is huge maintenance burden.
And since it helped to workaround a security bug relative recently I would
rather keep it.


I agree to keep it for a while to let that security bug cool down, 
however, if there is no user anymore, it sounds pointless to still keep 
a dead knob.

Re: [PATCH] mm: thp: remove use_zero_page sysfs knob

[Yang Shi]

On 7/20/18 2:06 PM, Kirill A. Shutemov wrote:

On Sat, Jul 21, 2018 at 02:13:50AM +0800, Yang Shi wrote:

By digging into the original review, it looks use_zero_page sysfs knob
was added to help ease-of-testing and give user a way to mitigate
refcounting overhead.

It has been a few years since the knob was added at the first place, I
think we are confident that it is stable enough. And, since commit
6fcb52a56ff60 ("thp: reduce usage of huge zero page's atomic counter"),
it looks refcounting overhead has been reduced significantly.

Other than the above, the value of the knob is always 1 (enabled by
default), I'm supposed very few people turn it off by default.

So, it sounds not worth to still keep this knob around.

I don't think that having the knob around is huge maintenance burden.
And since it helped to workaround a security bug relative recently I would
rather keep it.


I agree to keep it for a while to let that security bug cool down, 
however, if there is no user anymore, it sounds pointless to still keep 
a dead knob.

Re: [PATCH] mm: thp: remove use_zero_page sysfs knob

[Yang Shi]

On 7/20/18 2:05 PM, David Rientjes wrote:

On Fri, 20 Jul 2018, Yang Shi wrote:


We disable the huge zero page through this interface, there were issues
related to the huge zero page shrinker (probably best to never free a
per-node huge zero page after allocated) and CVE-2017-1000405 for huge
dirty COW.

Thanks for the information. It looks the CVE has been resolved by commit
a8f97366452ed491d13cf1e44241bc0b5740b1f0 ("mm, thp: Do not make page table
dirty unconditionally in touch_p[mu]d()"), which is in 4.15 already.


For users who run kernels earlier than 4.15 they may choose to mitigate
the CVE by using this tunable.  It's not something we permanently need to
have, but it may likely be too early.


Yes, it might be good to keep it around for a while.




What was the shrinker related issue? I'm supposed it has been resolved, right?


The huge zero page can be reclaimed under memory pressure and, if it is,
it is attempted to be allocted again with gfp flags that attempt memory
compaction that can become expensive.  If we are constantly under memory
pressure, it gets freed and reallocated millions of times always trying to
compact memory both directly and by kicking kcompactd in the background.


Even though we don't use huge zero page, we may also run into the 
similar issue under memory pressure. Just save the cost of calling huge 
zero page shrinker, but actually its cost sound not high.




It likely should also be per node.

Re: [PATCH] mm: thp: remove use_zero_page sysfs knob

[Yang Shi]

On 7/20/18 2:05 PM, David Rientjes wrote:

On Fri, 20 Jul 2018, Yang Shi wrote:


We disable the huge zero page through this interface, there were issues
related to the huge zero page shrinker (probably best to never free a
per-node huge zero page after allocated) and CVE-2017-1000405 for huge
dirty COW.

Thanks for the information. It looks the CVE has been resolved by commit
a8f97366452ed491d13cf1e44241bc0b5740b1f0 ("mm, thp: Do not make page table
dirty unconditionally in touch_p[mu]d()"), which is in 4.15 already.


For users who run kernels earlier than 4.15 they may choose to mitigate
the CVE by using this tunable.  It's not something we permanently need to
have, but it may likely be too early.


Yes, it might be good to keep it around for a while.




What was the shrinker related issue? I'm supposed it has been resolved, right?


The huge zero page can be reclaimed under memory pressure and, if it is,
it is attempted to be allocted again with gfp flags that attempt memory
compaction that can become expensive.  If we are constantly under memory
pressure, it gets freed and reallocated millions of times always trying to
compact memory both directly and by kicking kcompactd in the background.


Even though we don't use huge zero page, we may also run into the 
similar issue under memory pressure. Just save the cost of calling huge 
zero page shrinker, but actually its cost sound not high.




It likely should also be per node.

Re: [RFC][PATCH 07/11] signal: Deliver group signals via PIDTYPE_TGID not PIDTYPE_PID

[Eric W. Biederman]

Oleg Nesterov  writes:

> On 07/17, Oleg Nesterov wrote:
>>
>> And, I didn't mention this yesterday, but probably the next 08/11 patch can
>> have the same problem. But this is a bit more complicated because 
>> send_sigio()
>> uses the same "type" both for do_each_pid_task() and as an argument passed to
>> do_send_sig_info().
>
> perhaps it can simply do
>
>   if (type <= PIDTYPE_TGID) {
>   rcu_read_lock();
>   p = pid_task(pid, PIDTYPE_PID);
>   send_sigio_to_task(p, fown, fd, band, type);
>   rcu_read_unlock();
>   } else {
>   read_lock(_lock);
>   do_each_pid_task(pid, type, p) {
>   send_sigio_to_task(p, fown, fd, band, type);
>   } while_each_pid_task(pid, type, p);
>   read_unlock(_lock);
>   }
>
> this way we also avoid tasklist_lock in F_OWNER_TID/F_OWNER_PID case.

I like that.  I updated that code in a different way but that looks
more elegant and I think I will incoporate it.

> To clarify, it is not that I think any sane application can do
> fcntl(F_OWNER_PID, thread_tid) but still this is a user-visible change
> we can easily avoid.

Agreed.

I do think 

Eric

Re: [RFC][PATCH 07/11] signal: Deliver group signals via PIDTYPE_TGID not PIDTYPE_PID

[Eric W. Biederman]

Oleg Nesterov  writes:

> On 07/17, Oleg Nesterov wrote:
>>
>> And, I didn't mention this yesterday, but probably the next 08/11 patch can
>> have the same problem. But this is a bit more complicated because 
>> send_sigio()
>> uses the same "type" both for do_each_pid_task() and as an argument passed to
>> do_send_sig_info().
>
> perhaps it can simply do
>
>   if (type <= PIDTYPE_TGID) {
>   rcu_read_lock();
>   p = pid_task(pid, PIDTYPE_PID);
>   send_sigio_to_task(p, fown, fd, band, type);
>   rcu_read_unlock();
>   } else {
>   read_lock(_lock);
>   do_each_pid_task(pid, type, p) {
>   send_sigio_to_task(p, fown, fd, band, type);
>   } while_each_pid_task(pid, type, p);
>   read_unlock(_lock);
>   }
>
> this way we also avoid tasklist_lock in F_OWNER_TID/F_OWNER_PID case.

I like that.  I updated that code in a different way but that looks
more elegant and I think I will incoporate it.

> To clarify, it is not that I think any sane application can do
> fcntl(F_OWNER_PID, thread_tid) but still this is a user-visible change
> we can easily avoid.

Agreed.

I do think 

Eric

Re: [PATCH V2] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[kbuild test robot]

Hi Girish,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on spi/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dilip-Kota/spi-spi-geni-qcom-Add-SPI-driver-support-for-GENI-based-QUP/20180721-034916
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
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
GCC_VERSION=8.1.0 make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/spi/spi-geni-qcom.c:11:
   drivers/spi/spi-geni-qcom.c: In function 
'spi_geni_prepare_transfer_hardware':
>> include/linux/qcom-geni-se.h:238:9: error: 'version' undeclared (first use 
>> in this function); did you mean 'vm_region'?
 step = version & HW_VER_STEP_MASK; \
^~~
   drivers/spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~
   include/linux/qcom-geni-se.h:238:9: note: each undeclared identifier is 
reported only once for each function it appears in
 step = version & HW_VER_STEP_MASK; \
^~~
   drivers/spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~
--
   In file included from drivers//spi/spi-geni-qcom.c:11:
   drivers//spi/spi-geni-qcom.c: In function 
'spi_geni_prepare_transfer_hardware':
>> include/linux/qcom-geni-se.h:238:9: error: 'version' undeclared (first use 
>> in this function); did you mean 'vm_region'?
 step = version & HW_VER_STEP_MASK; \
^~~
   drivers//spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~
   include/linux/qcom-geni-se.h:238:9: note: each undeclared identifier is 
reported only once for each function it appears in
 step = version & HW_VER_STEP_MASK; \
^~~
   drivers//spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~

vim +238 include/linux/qcom-geni-se.h

eddac5af Karthikeyan Ramasubramanian 2018-03-30  231  
eddac5af Karthikeyan Ramasubramanian 2018-03-30  232  #define 
geni_se_get_wrapper_version(se, major, minor, step) do { \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  233u32 ver; \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  234  \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  235ver = 
geni_se_get_qup_hw_version(se); \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  236major = (ver & 
HW_VER_MAJOR_MASK) >> HW_VER_MAJOR_SHFT; \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  237minor = (ver & 
HW_VER_MINOR_MASK) >> HW_VER_MINOR_SHFT; \
eddac5af Karthikeyan Ramasubramanian 2018-03-30 @238step = version & 
HW_VER_STEP_MASK; \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  239  } while (0)
eddac5af Karthikeyan Ramasubramanian 2018-03-30  240  

:: The code at line 238 was first introduced by commit
:: eddac5af06546d2e7a0730e3dc02dde3dc91098a soc: qcom: Add GENI based QUP 
Wrapper driver

:: TO: Karthikeyan Ramasubramanian 
:: CC: Andy Gross 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH V2] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[kbuild test robot]

Hi Girish,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on spi/for-next]
[also build test ERROR on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dilip-Kota/spi-spi-geni-qcom-Add-SPI-driver-support-for-GENI-based-QUP/20180721-034916
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
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
GCC_VERSION=8.1.0 make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/spi/spi-geni-qcom.c:11:
   drivers/spi/spi-geni-qcom.c: In function 
'spi_geni_prepare_transfer_hardware':
>> include/linux/qcom-geni-se.h:238:9: error: 'version' undeclared (first use 
>> in this function); did you mean 'vm_region'?
 step = version & HW_VER_STEP_MASK; \
^~~
   drivers/spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~
   include/linux/qcom-geni-se.h:238:9: note: each undeclared identifier is 
reported only once for each function it appears in
 step = version & HW_VER_STEP_MASK; \
^~~
   drivers/spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~
--
   In file included from drivers//spi/spi-geni-qcom.c:11:
   drivers//spi/spi-geni-qcom.c: In function 
'spi_geni_prepare_transfer_hardware':
>> include/linux/qcom-geni-se.h:238:9: error: 'version' undeclared (first use 
>> in this function); did you mean 'vm_region'?
 step = version & HW_VER_STEP_MASK; \
^~~
   drivers//spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~
   include/linux/qcom-geni-se.h:238:9: note: each undeclared identifier is 
reported only once for each function it appears in
 step = version & HW_VER_STEP_MASK; \
^~~
   drivers//spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~

vim +238 include/linux/qcom-geni-se.h

eddac5af Karthikeyan Ramasubramanian 2018-03-30  231  
eddac5af Karthikeyan Ramasubramanian 2018-03-30  232  #define 
geni_se_get_wrapper_version(se, major, minor, step) do { \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  233u32 ver; \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  234  \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  235ver = 
geni_se_get_qup_hw_version(se); \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  236major = (ver & 
HW_VER_MAJOR_MASK) >> HW_VER_MAJOR_SHFT; \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  237minor = (ver & 
HW_VER_MINOR_MASK) >> HW_VER_MINOR_SHFT; \
eddac5af Karthikeyan Ramasubramanian 2018-03-30 @238step = version & 
HW_VER_STEP_MASK; \
eddac5af Karthikeyan Ramasubramanian 2018-03-30  239  } while (0)
eddac5af Karthikeyan Ramasubramanian 2018-03-30  240  

:: The code at line 238 was first introduced by commit
:: eddac5af06546d2e7a0730e3dc02dde3dc91098a soc: qcom: Add GENI based QUP 
Wrapper driver

:: TO: Karthikeyan Ramasubramanian 
:: CC: Andy Gross 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/2] pinctrl/amd: use byte access to clear irq/wake status bits

[Daniel Kurtz]

Hi Daniel,

On Tue, Jul 17, 2018 at 6:30 AM Daniel Drake  wrote:
>
> On Mon, Jul 16, 2018 at 7:57 PM, Daniel Kurtz  wrote:
> > Commit 6afb10267c1692 ("pinctrl/amd: fix masking of GPIO interrupts")
> > changed to the clearing of interrupt status bits to a RMW in a critical
> > section.  This works, but is a bit overkill.
> >
> > The relevant interrupt/wake status bits are in the Most Significant Byte
> > of a 32-bit word.  These two are the only write-able bits in this byte.
>
> I don't have the hardware to test this any more, and I also don't have
> any docs to double if those are really the only writable bits, but
> looking at the existing driver code it does seem to be the case.
>
> I think you should retain the comment noting that the value of the
> register may have changed since it was read just a few lines above
> (and hence explaining more precisely why we make the special effort
> just to modify the MSB), just in case there is further rework of this
> code in future and we end up walking into the same trap. It was one of
> those issues that took a frustratingly long time to figure out...

Sounds reasonable.  How about:

-   /* Clear interrupt.
-* We must read the pin register again, in case the
-* value was changed while executing
-* generic_handle_irq() above.
+   /*
+* Write-1-to-clear irq/wake status bits in MSByte.
+* All other bits in this byte are read-only.
+* This avoids modifying the lower 24-bits
because they may have
+*  changed while executing generic_handle_irq() above.
 */


>
> Thanks
> Daniel

Re: [PATCH 2/2] pinctrl/amd: use byte access to clear irq/wake status bits

[Daniel Kurtz]

Hi Daniel,

On Tue, Jul 17, 2018 at 6:30 AM Daniel Drake  wrote:
>
> On Mon, Jul 16, 2018 at 7:57 PM, Daniel Kurtz  wrote:
> > Commit 6afb10267c1692 ("pinctrl/amd: fix masking of GPIO interrupts")
> > changed to the clearing of interrupt status bits to a RMW in a critical
> > section.  This works, but is a bit overkill.
> >
> > The relevant interrupt/wake status bits are in the Most Significant Byte
> > of a 32-bit word.  These two are the only write-able bits in this byte.
>
> I don't have the hardware to test this any more, and I also don't have
> any docs to double if those are really the only writable bits, but
> looking at the existing driver code it does seem to be the case.
>
> I think you should retain the comment noting that the value of the
> register may have changed since it was read just a few lines above
> (and hence explaining more precisely why we make the special effort
> just to modify the MSB), just in case there is further rework of this
> code in future and we end up walking into the same trap. It was one of
> those issues that took a frustratingly long time to figure out...

Sounds reasonable.  How about:

-   /* Clear interrupt.
-* We must read the pin register again, in case the
-* value was changed while executing
-* generic_handle_irq() above.
+   /*
+* Write-1-to-clear irq/wake status bits in MSByte.
+* All other bits in this byte are read-only.
+* This avoids modifying the lower 24-bits
because they may have
+*  changed while executing generic_handle_irq() above.
 */


>
> Thanks
> Daniel

Re: [PATCH V2] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Doug Anderson]

Hi,

On Fri, Jul 20, 2018 at 3:53 PM, Doug Anderson  wrote:
>> +   mas->oversampling = 1;
>> +   /* Transmit an entire FIFO worth of data per IRQ */
>> +   mas->tx_wm = 1;
>> +   geni_se_get_wrapper_version(se, major, minor, step);
>
> In v1 Stephen said:
>
>> Drop extra parenthesis.
>
> I'll further add that I'd prefer it if you based your series atop
>  which changes the
> prototype here.

Whoops.  Extra parenthesis was actually referring to the line below
this one, AKA:


> +   if ((major == 1) && (minor == 0))
> +   mas->oversampling = 2;

...that still applies.  ...but then ignore my comment suggesting that
you base your series atop Stephen's.  You already did that.  Certainly
you should mention somewhere in your email that your patch is based on
his.


-Doug

Re: [PATCH V2] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Doug Anderson]

Hi,

On Fri, Jul 20, 2018 at 3:53 PM, Doug Anderson  wrote:
>> +   mas->oversampling = 1;
>> +   /* Transmit an entire FIFO worth of data per IRQ */
>> +   mas->tx_wm = 1;
>> +   geni_se_get_wrapper_version(se, major, minor, step);
>
> In v1 Stephen said:
>
>> Drop extra parenthesis.
>
> I'll further add that I'd prefer it if you based your series atop
>  which changes the
> prototype here.

Whoops.  Extra parenthesis was actually referring to the line below
this one, AKA:


> +   if ((major == 1) && (minor == 0))
> +   mas->oversampling = 2;

...that still applies.  ...but then ignore my comment suggesting that
you base your series atop Stephen's.  You already did that.  Certainly
you should mention somewhere in your email that your patch is based on
his.


-Doug

Re: RCU nocb list not reclaiming causing OOM

[Paul E. McKenney]

On Fri, Jul 20, 2018 at 11:05:52PM +, David Chen wrote:
> Hi Paul,
> 
> We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too
> large, and not getting reclaimed, causing the system to OOM.
> 
> Printing the culprit rcu_sched_data:
> 
>   nocb_q_count = {
> counter = 32369635
>   },
>   nocb_follower_head = 0x88ae901c0a00,
>   nocb_follower_tail = 0x88af1538b8d8,
>   nocb_kthread = 0x88b06d29,
> 
> As you can see here, the nocb_follower_head is not empty, so in theory, the
> nocb_kthread shouldn't go to sleep. However, if dump the stack of the kthread:
> 
> crash> bt 0x88b06d29
> PID: 21 TASK: 88b06d29  CPU: 3   COMMAND: "rcuos/1"
>  #0 [afc9020b7dc0] __schedule at 8d8789dc
>  #1 [afc9020b7e38] schedule at 8d878e76
>  #2 [afc9020b7e50] rcu_nocb_kthread at 8d112337
>  #3 [afc9020b7ec8] kthread at 8d0c6ce7
>  #4 [afc9020b7f50] ret_from_fork at 8d87d755
> 
> And if we dis the address at 8d112337:
> 
> /usr/src/debug/kernel-4.9.37/linux-4.9.37-29.nutanix.07142017.el7.centos.x86_64/kernel/rcu/tree_plugin.h:
>  2106
> 0x8d11232d :  test   %rax,%rax
> 0x8d112330 :  jne0x8d112355 
> 
> 0x8d112332 :  callq  0x8d878e40 
> 
> 0x8d112337 :  lea-0x40(%rbp),%rsi
> 
> So the kthread is blocked at swait_event_interruptible in the 
> nocb_follower_wait.
> This contradict with the fact that nocb_follower_head was not empty. So I
> wonder if this is caused by the lack of memory barrier in the place shown 
> below.
> If the head is set to NULL after doing xchg, it will overwrite the head set
> by leader. This caused the kthread to sleep the next iteration, and the leader
> won't wake him up as the tail doesn't point to head.
> 
> Please tell me what do you think.
> 
> Thanks,
> David
> 
> diff -ru linux-4.9.37.orig/kernel/rcu/tree_plugin.h 
> linux-4.9.37/kernel/rcu/tree_plugin.h
> --- linux-4.9.37.orig/kernel/rcu/tree_plugin.h2017-07-12 
> 06:42:41.0 -0700
> +++ linux-4.9.37/kernel/rcu/tree_plugin.h 2018-07-20 15:25:57.311206343 
> -0700
> @@ -2149,6 +2149,7 @@
>   BUG_ON(!list);
>   trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu, "WokeNonEmpty");
>   WRITE_ONCE(rdp->nocb_follower_head, NULL);
> + smp_mb();
>   tail = xchg(>nocb_follower_tail, >nocb_follower_head);

The xchg() operation implies full memory barriers both before and after,
so adding the smp_mb() before would have no effect.

But let me take a look at post-4.9 changes to this code...

I suggest trying out the following commit:

6b5fc3a13318 ("rcu: Add memory barriers for NOCB leader wakeup")

If that one doesn't help, the following might be worth trying, but probably
a lot harder to backport:

8be6e1b15c54 ("rcu: Use timer as backstop for NOCB deferred wakeups")

Please let me know how it goes!

Thanx, Paul



commit 6b5fc3a1331810db407c9e0e673dc1837afdc9d0
Author: Paul E. McKenney 
Date:   Fri Apr 28 20:11:09 2017 -0700

rcu: Add memory barriers for NOCB leader wakeup

Wait/wakeup operations do not guarantee ordering on their own.  Instead,
either locking or memory barriers are required.  This commit therefore
adds memory barriers to wake_nocb_leader() and nocb_leader_wait().

Signed-off-by: Paul E. McKenney 
Tested-by: Krister Johansen 
Cc:  # 4.6.x

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 0b1042545116..573fbe9640a0 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1810,6 +1810,7 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool 
force)
if (READ_ONCE(rdp_leader->nocb_leader_sleep) || force) {
/* Prior smp_mb__after_atomic() orders against prior enqueue. */
WRITE_ONCE(rdp_leader->nocb_leader_sleep, false);
+   smp_mb(); /* ->nocb_leader_sleep before swake_up(). */
swake_up(_leader->nocb_wq);
}
 }
@@ -2064,6 +2065,7 @@ static void nocb_leader_wait(struct rcu_data *my_rdp)
 * nocb_gp_head, where they await a grace period.
 */
gotcbs = false;
+   smp_mb(); /* wakeup before ->nocb_head reads. */
for (rdp = my_rdp; rdp; rdp = rdp->nocb_next_follower) {
rdp->nocb_gp_head = READ_ONCE(rdp->nocb_head);
if (!rdp->nocb_gp_head)

Re: RCU nocb list not reclaiming causing OOM

[Paul E. McKenney]

On Fri, Jul 20, 2018 at 11:05:52PM +, David Chen wrote:
> Hi Paul,
> 
> We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too
> large, and not getting reclaimed, causing the system to OOM.
> 
> Printing the culprit rcu_sched_data:
> 
>   nocb_q_count = {
> counter = 32369635
>   },
>   nocb_follower_head = 0x88ae901c0a00,
>   nocb_follower_tail = 0x88af1538b8d8,
>   nocb_kthread = 0x88b06d29,
> 
> As you can see here, the nocb_follower_head is not empty, so in theory, the
> nocb_kthread shouldn't go to sleep. However, if dump the stack of the kthread:
> 
> crash> bt 0x88b06d29
> PID: 21 TASK: 88b06d29  CPU: 3   COMMAND: "rcuos/1"
>  #0 [afc9020b7dc0] __schedule at 8d8789dc
>  #1 [afc9020b7e38] schedule at 8d878e76
>  #2 [afc9020b7e50] rcu_nocb_kthread at 8d112337
>  #3 [afc9020b7ec8] kthread at 8d0c6ce7
>  #4 [afc9020b7f50] ret_from_fork at 8d87d755
> 
> And if we dis the address at 8d112337:
> 
> /usr/src/debug/kernel-4.9.37/linux-4.9.37-29.nutanix.07142017.el7.centos.x86_64/kernel/rcu/tree_plugin.h:
>  2106
> 0x8d11232d :  test   %rax,%rax
> 0x8d112330 :  jne0x8d112355 
> 
> 0x8d112332 :  callq  0x8d878e40 
> 
> 0x8d112337 :  lea-0x40(%rbp),%rsi
> 
> So the kthread is blocked at swait_event_interruptible in the 
> nocb_follower_wait.
> This contradict with the fact that nocb_follower_head was not empty. So I
> wonder if this is caused by the lack of memory barrier in the place shown 
> below.
> If the head is set to NULL after doing xchg, it will overwrite the head set
> by leader. This caused the kthread to sleep the next iteration, and the leader
> won't wake him up as the tail doesn't point to head.
> 
> Please tell me what do you think.
> 
> Thanks,
> David
> 
> diff -ru linux-4.9.37.orig/kernel/rcu/tree_plugin.h 
> linux-4.9.37/kernel/rcu/tree_plugin.h
> --- linux-4.9.37.orig/kernel/rcu/tree_plugin.h2017-07-12 
> 06:42:41.0 -0700
> +++ linux-4.9.37/kernel/rcu/tree_plugin.h 2018-07-20 15:25:57.311206343 
> -0700
> @@ -2149,6 +2149,7 @@
>   BUG_ON(!list);
>   trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu, "WokeNonEmpty");
>   WRITE_ONCE(rdp->nocb_follower_head, NULL);
> + smp_mb();
>   tail = xchg(>nocb_follower_tail, >nocb_follower_head);

The xchg() operation implies full memory barriers both before and after,
so adding the smp_mb() before would have no effect.

But let me take a look at post-4.9 changes to this code...

I suggest trying out the following commit:

6b5fc3a13318 ("rcu: Add memory barriers for NOCB leader wakeup")

If that one doesn't help, the following might be worth trying, but probably
a lot harder to backport:

8be6e1b15c54 ("rcu: Use timer as backstop for NOCB deferred wakeups")

Please let me know how it goes!

Thanx, Paul



commit 6b5fc3a1331810db407c9e0e673dc1837afdc9d0
Author: Paul E. McKenney 
Date:   Fri Apr 28 20:11:09 2017 -0700

rcu: Add memory barriers for NOCB leader wakeup

Wait/wakeup operations do not guarantee ordering on their own.  Instead,
either locking or memory barriers are required.  This commit therefore
adds memory barriers to wake_nocb_leader() and nocb_leader_wait().

Signed-off-by: Paul E. McKenney 
Tested-by: Krister Johansen 
Cc:  # 4.6.x

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 0b1042545116..573fbe9640a0 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1810,6 +1810,7 @@ static void wake_nocb_leader(struct rcu_data *rdp, bool 
force)
if (READ_ONCE(rdp_leader->nocb_leader_sleep) || force) {
/* Prior smp_mb__after_atomic() orders against prior enqueue. */
WRITE_ONCE(rdp_leader->nocb_leader_sleep, false);
+   smp_mb(); /* ->nocb_leader_sleep before swake_up(). */
swake_up(_leader->nocb_wq);
}
 }
@@ -2064,6 +2065,7 @@ static void nocb_leader_wait(struct rcu_data *my_rdp)
 * nocb_gp_head, where they await a grace period.
 */
gotcbs = false;
+   smp_mb(); /* wakeup before ->nocb_head reads. */
for (rdp = my_rdp; rdp; rdp = rdp->nocb_next_follower) {
rdp->nocb_gp_head = READ_ONCE(rdp->nocb_head);
if (!rdp->nocb_gp_head)

Re: [RFC][PATCH 07/11] signal: Deliver group signals via PIDTYPE_TGID not PIDTYPE_PID

[Eric W. Biederman]

Linus Torvalds  writes:

> On Mon, Jul 16, 2018 at 7:50 AM Eric W. Biederman  
> wrote:
>>
>> In practice since glibc does not make thread id's available I don't
>> expect anyone relies on this behavior.  Since no one relies on it we
>> can change it without creating a regression.
>
> Actually, there's a really obvious case where this simply isn't true.
>
> Just imagine you're a MIS person or a developer, doing "ps -eLf" to
> see what's going on, and want to kill one thread. Either because you
> see that one thread using all CPU, or because you are the developer
> and you know what's up.
>
> Those thread ID's are exported trivially.

True.  Which makes all of this shell script visible.  So someone may
have done something with this functionality.

I have just gone through all of my patches and updated them to ensure
that everything has the same behavior when selecting processes as it does
today.  So this will not be an issue with the next version this patch series.



I am going to come back to this as there are some really nasty corner
cases in the current kernel.  Primarily that we can send signals through
a zombie thread group leader and it can have unchangable credentials
completely out of sync with the credentials on the other threads.

Eric

Re: [RFC][PATCH 07/11] signal: Deliver group signals via PIDTYPE_TGID not PIDTYPE_PID

[Eric W. Biederman]

Linus Torvalds  writes:

> On Mon, Jul 16, 2018 at 7:50 AM Eric W. Biederman  
> wrote:
>>
>> In practice since glibc does not make thread id's available I don't
>> expect anyone relies on this behavior.  Since no one relies on it we
>> can change it without creating a regression.
>
> Actually, there's a really obvious case where this simply isn't true.
>
> Just imagine you're a MIS person or a developer, doing "ps -eLf" to
> see what's going on, and want to kill one thread. Either because you
> see that one thread using all CPU, or because you are the developer
> and you know what's up.
>
> Those thread ID's are exported trivially.

True.  Which makes all of this shell script visible.  So someone may
have done something with this functionality.

I have just gone through all of my patches and updated them to ensure
that everything has the same behavior when selecting processes as it does
today.  So this will not be an issue with the next version this patch series.



I am going to come back to this as there are some really nasty corner
cases in the current kernel.  Primarily that we can send signals through
a zombie thread group leader and it can have unchangable credentials
completely out of sync with the credentials on the other threads.

Eric

RCU nocb list not reclaiming causing OOM

[David Chen]

Hi Paul,

We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too
large, and not getting reclaimed, causing the system to OOM.

Printing the culprit rcu_sched_data:

  nocb_q_count = {
counter = 32369635
  },
  nocb_follower_head = 0x88ae901c0a00,
  nocb_follower_tail = 0x88af1538b8d8,
  nocb_kthread = 0x88b06d29,

As you can see here, the nocb_follower_head is not empty, so in theory, the
nocb_kthread shouldn't go to sleep. However, if dump the stack of the kthread:

crash> bt 0x88b06d29
PID: 21 TASK: 88b06d29  CPU: 3   COMMAND: "rcuos/1"
 #0 [afc9020b7dc0] __schedule at 8d8789dc
 #1 [afc9020b7e38] schedule at 8d878e76
 #2 [afc9020b7e50] rcu_nocb_kthread at 8d112337
 #3 [afc9020b7ec8] kthread at 8d0c6ce7
 #4 [afc9020b7f50] ret_from_fork at 8d87d755

And if we dis the address at 8d112337:

/usr/src/debug/kernel-4.9.37/linux-4.9.37-29.nutanix.07142017.el7.centos.x86_64/kernel/rcu/tree_plugin.h:
 2106
0x8d11232d :  test   %rax,%rax
0x8d112330 :  jne0x8d112355 

0x8d112332 :  callq  0x8d878e40 

0x8d112337 :  lea-0x40(%rbp),%rsi

So the kthread is blocked at swait_event_interruptible in the 
nocb_follower_wait.
This contradict with the fact that nocb_follower_head was not empty. So I
wonder if this is caused by the lack of memory barrier in the place shown below.
If the head is set to NULL after doing xchg, it will overwrite the head set
by leader. This caused the kthread to sleep the next iteration, and the leader
won't wake him up as the tail doesn't point to head.

Please tell me what do you think.

Thanks,
David

diff -ru linux-4.9.37.orig/kernel/rcu/tree_plugin.h 
linux-4.9.37/kernel/rcu/tree_plugin.h
--- linux-4.9.37.orig/kernel/rcu/tree_plugin.h  2017-07-12 06:42:41.0 
-0700
+++ linux-4.9.37/kernel/rcu/tree_plugin.h   2018-07-20 15:25:57.311206343 
-0700
@@ -2149,6 +2149,7 @@
BUG_ON(!list);
trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu, "WokeNonEmpty");
WRITE_ONCE(rdp->nocb_follower_head, NULL);
+   smp_mb();
tail = xchg(>nocb_follower_tail, >nocb_follower_head);
 
/* Each pass through the following loop invokes a callback. */

RCU nocb list not reclaiming causing OOM

[David Chen]

Hi Paul,

We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too
large, and not getting reclaimed, causing the system to OOM.

Printing the culprit rcu_sched_data:

  nocb_q_count = {
counter = 32369635
  },
  nocb_follower_head = 0x88ae901c0a00,
  nocb_follower_tail = 0x88af1538b8d8,
  nocb_kthread = 0x88b06d29,

As you can see here, the nocb_follower_head is not empty, so in theory, the
nocb_kthread shouldn't go to sleep. However, if dump the stack of the kthread:

crash> bt 0x88b06d29
PID: 21 TASK: 88b06d29  CPU: 3   COMMAND: "rcuos/1"
 #0 [afc9020b7dc0] __schedule at 8d8789dc
 #1 [afc9020b7e38] schedule at 8d878e76
 #2 [afc9020b7e50] rcu_nocb_kthread at 8d112337
 #3 [afc9020b7ec8] kthread at 8d0c6ce7
 #4 [afc9020b7f50] ret_from_fork at 8d87d755

And if we dis the address at 8d112337:

/usr/src/debug/kernel-4.9.37/linux-4.9.37-29.nutanix.07142017.el7.centos.x86_64/kernel/rcu/tree_plugin.h:
 2106
0x8d11232d :  test   %rax,%rax
0x8d112330 :  jne0x8d112355 

0x8d112332 :  callq  0x8d878e40 

0x8d112337 :  lea-0x40(%rbp),%rsi

So the kthread is blocked at swait_event_interruptible in the 
nocb_follower_wait.
This contradict with the fact that nocb_follower_head was not empty. So I
wonder if this is caused by the lack of memory barrier in the place shown below.
If the head is set to NULL after doing xchg, it will overwrite the head set
by leader. This caused the kthread to sleep the next iteration, and the leader
won't wake him up as the tail doesn't point to head.

Please tell me what do you think.

Thanks,
David

diff -ru linux-4.9.37.orig/kernel/rcu/tree_plugin.h 
linux-4.9.37/kernel/rcu/tree_plugin.h
--- linux-4.9.37.orig/kernel/rcu/tree_plugin.h  2017-07-12 06:42:41.0 
-0700
+++ linux-4.9.37/kernel/rcu/tree_plugin.h   2018-07-20 15:25:57.311206343 
-0700
@@ -2149,6 +2149,7 @@
BUG_ON(!list);
trace_rcu_nocb_wake(rdp->rsp->name, rdp->cpu, "WokeNonEmpty");
WRITE_ONCE(rdp->nocb_follower_head, NULL);
+   smp_mb();
tail = xchg(>nocb_follower_tail, >nocb_follower_head);
 
/* Each pass through the following loop invokes a callback. */

Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

[Andrew Morton]

On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara  wrote:

> On Thu 19-07-18 16:17:26, Chengguang Xu wrote:
> > When we try to truncate read count in generic_file_buffered_read(),
> > should deliver (sb->s_maxbytes - offset) as maximum count not
> > sb->s_maxbytes itself.
> > 
> > Signed-off-by: Chengguang Xu 
> 
> Looks good to me. You can add:
> 
> Reviewed-by: Jan Kara 

Yup.

What are the runtime effects of this bug?

Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

[Andrew Morton]

On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara  wrote:

> On Thu 19-07-18 16:17:26, Chengguang Xu wrote:
> > When we try to truncate read count in generic_file_buffered_read(),
> > should deliver (sb->s_maxbytes - offset) as maximum count not
> > sb->s_maxbytes itself.
> > 
> > Signed-off-by: Chengguang Xu 
> 
> Looks good to me. You can add:
> 
> Reviewed-by: Jan Kara 

Yup.

What are the runtime effects of this bug?

Re: [PATCH V2] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Doug Anderson]

>Hi,

On Fri, Jul 20, 2018 at 4:50 AM, Dilip Kota  wrote:
> From: Girish Mahadevan 
>
> This driver supports GENI based SPI Controller in the Qualcomm SOCs. The
> Qualcomm Generic Interface (GENI) is a programmable module supporting a
> wide range of serial interfaces including SPI. This driver supports SPI
> operations using FIFO mode of transfer.
>
> Change-Id: Ib2c7feba5a2fc4015bc83319b233b4356f7d3190
> Signed-off-by: Girish Mahadevan 
> Signed-off-by: Karthikeyan Ramasubramanian 
> Signed-off-by: Sagar Dharia 
> Signed-off-by: Girish Mahadevan 

Why is Girish here twice?  That doesn't seem right.  This is also an
awful lot of Signed-off-by tags.  Did they all contribute code here?
v1 of this patch only had girish.


> Reviewed-by: Rob Herring 

Rob may have reviewed the bindings, but that doesn't mean he's happy
with the code.  I'd suggest removing his Reviewed-by


> Reviewed-by: Stephen Boyd 

Are you certain that Stephen provided his Reviewed-by?  I don't see
it.  ...and, as you can see below, it seems like you ignored most of
Stephen's comments on v1.



> Signed-off-by: Dilip Kota 
> ---

I would have expected some version history here to say what changed
from v1 to v2.  See my comments on the cover letter and consider using
patman  to
help you.


> +config SPI_QCOM_GENI
> +   tristate "Qualcomm SPI controller with QUP interface"

On v1 Stephen Boyd said:

> This is the same help text as the SPI_QUP config up above. Please make
> it different somehow by adding GENI or something like that instead of
> QUP?

More explicitly, please change the line to:
  tristate "Qualcomm SPI controller with GENI interface"


> +   depends on QCOM_GENI_SE
> +   help
> + This driver supports GENI serial engine based SPI controller in
> + master mode on the Qualcomm Technologies Inc.'s SoCs. If you say
> + yes to this option, support will be included for the built-in SPI

On v1 Stephen Boyd said:

> Drop "built-in"?


> +struct spi_geni_master {
> +   struct geni_se se;
> +   int irq;
> +   struct device *dev;
> +   int rx_fifo_depth;
> +   int tx_fifo_depth;
> +   int tx_fifo_width;
> +   int tx_wm;

In v1 Stephen said:

> All of these can be unsigned ints?


> +   bool setup;
> +   u32 cur_speed_hz;
> +   int cur_word_len;

In v1 Stephen said:

> unsigned?


> +   unsigned int tx_rem_bytes;
> +   unsigned int rx_rem_bytes;
> +   struct spi_transfer *cur_xfer;
> +   struct completion xfer_done;
> +   int oversampling;

In v1 Stephen said:

> unsigned?


> +static int get_spi_clk_cfg(u32 speed_hz, struct spi_geni_master *mas,

In v1 Stephen said:

> Why a u32? And not unsigned int?


> +   if (ret) {
> +   dev_err(mas->dev, "%s: Failed(%d) to find src clk for 0x%x\n",
> +   __func__, ret, speed_hz);

In v1 Stephen said:

> Frequency Hz printed in hex? I am not a hex computer! I hope!

...I'll further add that printing __func__ is generally discouraged
for dev_xx printouts.  They've already got the device name and that
together with the string should be enough.  Remove it.


> +static void spi_setup_word_len(struct spi_geni_master *mas, u32 mode,

In v1 Stephen said:

> mode is only u16 in spi_device struct. Maybe it would be better to pass
> the spi_device struct here and then pick out the mode from there.


> +static int setup_fifo_params(struct spi_device *spi_slv,
> +   struct spi_master *spi)
> +{
> +   struct spi_geni_master *mas = spi_master_get_devdata(spi);
> +   struct geni_se *se = >se;
> +   u16 mode = spi_slv->mode;
> +   u32 loopback_cfg = readl_relaxed(se->base + SE_SPI_LOOPBACK);
> +   u32 cpol = readl_relaxed(se->base + SE_SPI_CPOL);
> +   u32 cpha = readl_relaxed(se->base + SE_SPI_CPHA);
> +   u32 demux_sel = 0;
> +   u32 demux_output_inv = 0;
> +   u32 clk_sel = 0;
> +   u32 m_clk_cfg = 0;
> +   int ret = 0;

In v1 Stephen said:

> Don't initialize variables and then overwrite them.


> +   demux_sel = spi_slv->chip_select;
> +   mas->cur_speed_hz = spi_slv->max_speed_hz;

In v1 Stephen said:

> Why can't you use clk_get_rate() instead? Or call clk_set_rate() with
> the rate you want the master clk to run at and then divide that down
> from there?

...there was a bunch of arguments here and I'm not sure I followed all
of them, but the net-net is that there should be no rate at the
controller level.  Each SPI slave should request its rate and that
should take effect for each transfer.  Basically just honor the rate
of the transfer in setup_fifo_xfer and be done with it.


> +   mas->cur_word_len = spi_slv->bits_per_word;
> +
> +   ret = get_spi_clk_cfg(mas->cur_speed_hz, mas, , );
> +   if (ret) {
> +   dev_err(mas->dev, "Err setting clks ret(%d) for %d\n",
> +

Re: [PATCH V2] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Doug Anderson]

>Hi,

On Fri, Jul 20, 2018 at 4:50 AM, Dilip Kota  wrote:
> From: Girish Mahadevan 
>
> This driver supports GENI based SPI Controller in the Qualcomm SOCs. The
> Qualcomm Generic Interface (GENI) is a programmable module supporting a
> wide range of serial interfaces including SPI. This driver supports SPI
> operations using FIFO mode of transfer.
>
> Change-Id: Ib2c7feba5a2fc4015bc83319b233b4356f7d3190
> Signed-off-by: Girish Mahadevan 
> Signed-off-by: Karthikeyan Ramasubramanian 
> Signed-off-by: Sagar Dharia 
> Signed-off-by: Girish Mahadevan 

Why is Girish here twice?  That doesn't seem right.  This is also an
awful lot of Signed-off-by tags.  Did they all contribute code here?
v1 of this patch only had girish.


> Reviewed-by: Rob Herring 

Rob may have reviewed the bindings, but that doesn't mean he's happy
with the code.  I'd suggest removing his Reviewed-by


> Reviewed-by: Stephen Boyd 

Are you certain that Stephen provided his Reviewed-by?  I don't see
it.  ...and, as you can see below, it seems like you ignored most of
Stephen's comments on v1.



> Signed-off-by: Dilip Kota 
> ---

I would have expected some version history here to say what changed
from v1 to v2.  See my comments on the cover letter and consider using
patman  to
help you.


> +config SPI_QCOM_GENI
> +   tristate "Qualcomm SPI controller with QUP interface"

On v1 Stephen Boyd said:

> This is the same help text as the SPI_QUP config up above. Please make
> it different somehow by adding GENI or something like that instead of
> QUP?

More explicitly, please change the line to:
  tristate "Qualcomm SPI controller with GENI interface"


> +   depends on QCOM_GENI_SE
> +   help
> + This driver supports GENI serial engine based SPI controller in
> + master mode on the Qualcomm Technologies Inc.'s SoCs. If you say
> + yes to this option, support will be included for the built-in SPI

On v1 Stephen Boyd said:

> Drop "built-in"?


> +struct spi_geni_master {
> +   struct geni_se se;
> +   int irq;
> +   struct device *dev;
> +   int rx_fifo_depth;
> +   int tx_fifo_depth;
> +   int tx_fifo_width;
> +   int tx_wm;

In v1 Stephen said:

> All of these can be unsigned ints?


> +   bool setup;
> +   u32 cur_speed_hz;
> +   int cur_word_len;

In v1 Stephen said:

> unsigned?


> +   unsigned int tx_rem_bytes;
> +   unsigned int rx_rem_bytes;
> +   struct spi_transfer *cur_xfer;
> +   struct completion xfer_done;
> +   int oversampling;

In v1 Stephen said:

> unsigned?


> +static int get_spi_clk_cfg(u32 speed_hz, struct spi_geni_master *mas,

In v1 Stephen said:

> Why a u32? And not unsigned int?


> +   if (ret) {
> +   dev_err(mas->dev, "%s: Failed(%d) to find src clk for 0x%x\n",
> +   __func__, ret, speed_hz);

In v1 Stephen said:

> Frequency Hz printed in hex? I am not a hex computer! I hope!

...I'll further add that printing __func__ is generally discouraged
for dev_xx printouts.  They've already got the device name and that
together with the string should be enough.  Remove it.


> +static void spi_setup_word_len(struct spi_geni_master *mas, u32 mode,

In v1 Stephen said:

> mode is only u16 in spi_device struct. Maybe it would be better to pass
> the spi_device struct here and then pick out the mode from there.


> +static int setup_fifo_params(struct spi_device *spi_slv,
> +   struct spi_master *spi)
> +{
> +   struct spi_geni_master *mas = spi_master_get_devdata(spi);
> +   struct geni_se *se = >se;
> +   u16 mode = spi_slv->mode;
> +   u32 loopback_cfg = readl_relaxed(se->base + SE_SPI_LOOPBACK);
> +   u32 cpol = readl_relaxed(se->base + SE_SPI_CPOL);
> +   u32 cpha = readl_relaxed(se->base + SE_SPI_CPHA);
> +   u32 demux_sel = 0;
> +   u32 demux_output_inv = 0;
> +   u32 clk_sel = 0;
> +   u32 m_clk_cfg = 0;
> +   int ret = 0;

In v1 Stephen said:

> Don't initialize variables and then overwrite them.


> +   demux_sel = spi_slv->chip_select;
> +   mas->cur_speed_hz = spi_slv->max_speed_hz;

In v1 Stephen said:

> Why can't you use clk_get_rate() instead? Or call clk_set_rate() with
> the rate you want the master clk to run at and then divide that down
> from there?

...there was a bunch of arguments here and I'm not sure I followed all
of them, but the net-net is that there should be no rate at the
controller level.  Each SPI slave should request its rate and that
should take effect for each transfer.  Basically just honor the rate
of the transfer in setup_fifo_xfer and be done with it.


> +   mas->cur_word_len = spi_slv->bits_per_word;
> +
> +   ret = get_spi_clk_cfg(mas->cur_speed_hz, mas, , );
> +   if (ret) {
> +   dev_err(mas->dev, "Err setting clks ret(%d) for %d\n",
> +

Re: [PATCH V2] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[kbuild test robot]

Hi Girish,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on spi/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dilip-Kota/spi-spi-geni-qcom-Add-SPI-driver-support-for-GENI-based-QUP/20180721-034916
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from drivers/spi/spi-geni-qcom.c:11:0:
   drivers/spi/spi-geni-qcom.c: In function 
'spi_geni_prepare_transfer_hardware':
   include/linux/qcom-geni-se.h:238:9: error: 'version' undeclared (first use 
in this function); did you mean 'vm_region'?
 step = version & HW_VER_STEP_MASK; \
^
>> drivers/spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
>> 'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~
   include/linux/qcom-geni-se.h:238:9: note: each undeclared identifier is 
reported only once for each function it appears in
 step = version & HW_VER_STEP_MASK; \
^
>> drivers/spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
>> 'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~

vim +/geni_se_get_wrapper_version +256 drivers/spi/spi-geni-qcom.c

   233  
   234  static int spi_geni_prepare_transfer_hardware(struct spi_master *spi)
   235  {
   236  struct spi_geni_master *mas = spi_master_get_devdata(spi);
   237  struct geni_se *se = >se;
   238  
   239  if (!mas->setup) {
   240  int proto = geni_se_read_proto(se);
   241  unsigned int major;
   242  unsigned int minor;
   243  unsigned int step;
   244  
   245  if (proto != GENI_SE_SPI) {
   246  dev_err(mas->dev, "Invalid proto %d\n", proto);
   247  return -ENXIO;
   248  }
   249  mas->tx_fifo_depth = geni_se_get_tx_fifo_depth(se);
   250  mas->rx_fifo_depth = geni_se_get_rx_fifo_depth(se);
   251  mas->tx_fifo_width = geni_se_get_tx_fifo_width(se);
   252  geni_se_init(se, 0x0, (mas->tx_fifo_depth - 2));
   253  mas->oversampling = 1;
   254  /* Transmit an entire FIFO worth of data per IRQ */
   255  mas->tx_wm = 1;
 > 256  geni_se_get_wrapper_version(se, major, minor, step);
   257  if ((major == 1) && (minor == 0))
   258  mas->oversampling = 2;
   259  mas->setup = 1;
   260  }
   261  return 0;
   262  }
   263  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH V2] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[kbuild test robot]

Hi Girish,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on spi/for-next]
[also build test WARNING on v4.18-rc5 next-20180720]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dilip-Kota/spi-spi-geni-qcom-Add-SPI-driver-support-for-GENI-based-QUP/20180721-034916
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from drivers/spi/spi-geni-qcom.c:11:0:
   drivers/spi/spi-geni-qcom.c: In function 
'spi_geni_prepare_transfer_hardware':
   include/linux/qcom-geni-se.h:238:9: error: 'version' undeclared (first use 
in this function); did you mean 'vm_region'?
 step = version & HW_VER_STEP_MASK; \
^
>> drivers/spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
>> 'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~
   include/linux/qcom-geni-se.h:238:9: note: each undeclared identifier is 
reported only once for each function it appears in
 step = version & HW_VER_STEP_MASK; \
^
>> drivers/spi/spi-geni-qcom.c:256:3: note: in expansion of macro 
>> 'geni_se_get_wrapper_version'
  geni_se_get_wrapper_version(se, major, minor, step);
  ^~~

vim +/geni_se_get_wrapper_version +256 drivers/spi/spi-geni-qcom.c

   233  
   234  static int spi_geni_prepare_transfer_hardware(struct spi_master *spi)
   235  {
   236  struct spi_geni_master *mas = spi_master_get_devdata(spi);
   237  struct geni_se *se = >se;
   238  
   239  if (!mas->setup) {
   240  int proto = geni_se_read_proto(se);
   241  unsigned int major;
   242  unsigned int minor;
   243  unsigned int step;
   244  
   245  if (proto != GENI_SE_SPI) {
   246  dev_err(mas->dev, "Invalid proto %d\n", proto);
   247  return -ENXIO;
   248  }
   249  mas->tx_fifo_depth = geni_se_get_tx_fifo_depth(se);
   250  mas->rx_fifo_depth = geni_se_get_rx_fifo_depth(se);
   251  mas->tx_fifo_width = geni_se_get_tx_fifo_width(se);
   252  geni_se_init(se, 0x0, (mas->tx_fifo_depth - 2));
   253  mas->oversampling = 1;
   254  /* Transmit an entire FIFO worth of data per IRQ */
   255  mas->tx_wm = 1;
 > 256  geni_se_get_wrapper_version(se, major, minor, step);
   257  if ((major == 1) && (minor == 0))
   258  mas->oversampling = 2;
   259  mas->setup = 1;
   260  }
   261  return 0;
   262  }
   263  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] mips: mm: Discard ioremap_cacheable_cow() method

[Paul Burton]

Hi Serge,

On Fri, Jul 20, 2018 at 11:14:27PM +0300, Serge Semin wrote:
> This macro substitution is the shortcut to map cacheable IO memory
> with coherent and write-back attributes. Since it is entirely unused
> by kernel, lets just remove it.
> 
> Signed-off-by: Serge Semin 
> Suggested-by: Christoph Hellwig 
> CC: Paul Burton 
> Cc: James Hogan 
> Cc: Ralf Baechle 
> Cc: Sinan Kaya 
> Cc: Huacai Chen 
> Cc: sergey.se...@t-platforms.ru
> Cc: linux-m...@linux-mips.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/mips/include/asm/io.h | 7 ---
>  1 file changed, 7 deletions(-)

Applied to mips-next for 4.19, thanks!

Paul

Re: [PATCH] mips: mm: Discard ioremap_cacheable_cow() method

[Paul Burton]

Hi Serge,

On Fri, Jul 20, 2018 at 11:14:27PM +0300, Serge Semin wrote:
> This macro substitution is the shortcut to map cacheable IO memory
> with coherent and write-back attributes. Since it is entirely unused
> by kernel, lets just remove it.
> 
> Signed-off-by: Serge Semin 
> Suggested-by: Christoph Hellwig 
> CC: Paul Burton 
> Cc: James Hogan 
> Cc: Ralf Baechle 
> Cc: Sinan Kaya 
> Cc: Huacai Chen 
> Cc: sergey.se...@t-platforms.ru
> Cc: linux-m...@linux-mips.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/mips/include/asm/io.h | 7 ---
>  1 file changed, 7 deletions(-)

Applied to mips-next for 4.19, thanks!

Paul

Re: [PATCH v3 0/3] i2c: at91: slave mode support

[Wolfram Sang]

> [Ludovic Desroches]
> Changes in v3:
>  - rebase (cherry-pick was enough)

Thanks for the rebase. I wonder, though, I recall to had more
complicated issues. However...

>  - fix checkpatch errors
>  - tests:
>- hangs with a SAMA5D4 (master and slave on different busses) after about
>100 transfers. It's the firs time I do this test.
>- some mismatches with a SAMA5D4 as slave and a SAMA5D2 as master
>I don't know if it's a regression. I don't remember having seen this
>behavior previously.
>I think it's worth taking those patches even if there are some possible
>bugs. It'll allow to get more people using it and so to consolidate the
>slave mode support.

I really want to see those patches go upstream, too. But I am also not a
big fan of delivering the user something with known issues. Especially
not when they affect the main feature to be added. My rationale here is
that someone who is able to fix the issues remaining will also be able
to pick up and apply patches.

Maybe, maybe if it was to be enabled by a special
I2C_AT91_SLAVE_EXPERIMANTEL symbol with lots of explanations. I need to
think twice about that, though.

Speaking of Kconfig, I think this series needs to place a

select I2C_SLAVE

somewhere.



signature.asc
Description: PGP signature

Re: [PATCH v3 0/3] i2c: at91: slave mode support

[Wolfram Sang]

> [Ludovic Desroches]
> Changes in v3:
>  - rebase (cherry-pick was enough)

Thanks for the rebase. I wonder, though, I recall to had more
complicated issues. However...

>  - fix checkpatch errors
>  - tests:
>- hangs with a SAMA5D4 (master and slave on different busses) after about
>100 transfers. It's the firs time I do this test.
>- some mismatches with a SAMA5D4 as slave and a SAMA5D2 as master
>I don't know if it's a regression. I don't remember having seen this
>behavior previously.
>I think it's worth taking those patches even if there are some possible
>bugs. It'll allow to get more people using it and so to consolidate the
>slave mode support.

I really want to see those patches go upstream, too. But I am also not a
big fan of delivering the user something with known issues. Especially
not when they affect the main feature to be added. My rationale here is
that someone who is able to fix the issues remaining will also be able
to pick up and apply patches.

Maybe, maybe if it was to be enabled by a special
I2C_AT91_SLAVE_EXPERIMANTEL symbol with lots of explanations. I need to
think twice about that, though.

Speaking of Kconfig, I think this series needs to place a

select I2C_SLAVE

somewhere.



signature.asc
Description: PGP signature

[4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[Nick Desaulniers]

native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.

paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.

Compilers have different heuristics which they use to emit stack guard
code, the emittance of which can break paravirt's callee saved assumption
by clobbering %rcx.

Marking a function definition extern inline means that if this version
cannot be inlined, then the out-of-line version will be preferred. By
having the out-of-line version be implemented in assembly, it cannot be
instrumented with a stack protector, which might violate custom calling
conventions that code like paravirt rely on.

The semantics of extern inline has changed since gnu89. This means that
folks using GCC versions >= 5.1 may see symbol redefinition errors at
link time for subdirs that override KBUILD_CFLAGS (making the C standard
used implicit) regardless of this patch. This has been cleaned up
earlier in the patch set, but is left as a note in the commit message
for future travelers.

Reports:
https://lkml.org/lkml/2018/5/7/534
https://github.com/ClangBuiltLinux/linux/issues/16

Discussion:
https://bugs.llvm.org/show_bug.cgi?id=37512
https://lkml.org/lkml/2018/5/24/1371

Thanks to the many folks that participated in the discussion.

Acked-by: Juergen Gross 
Debugged-by: Alistair Strachan 
Debugged-by: Matthias Kaehlcke 
Reported-by: Sedat Dilek 
Signed-off-by: Nick Desaulniers 
Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Tom Stellar 
Tested-by: Sedat Dilek 
---
Backport for 4.4. 4.4 is missing commit 784d5699eddc "x86: move exports to
actual definitions" which doesn't apply cleanly, and not really worth
backporting IMO. It's simpler to change this patch from upstream:
+ #include 
rather than
+ #include 

 arch/x86/include/asm/irqflags.h |  2 +-
 arch/x86/kernel/Makefile|  1 +
 arch/x86/kernel/irqflags.S  | 26 ++
 3 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/irqflags.S

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index b77f5edb03b0..0056bc945cd1 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -8,7 +8,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+extern inline unsigned long native_save_fl(void)
 {
unsigned long flags;
 
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index b1b78ffe01d0..7947cee61f61 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -41,6 +41,7 @@ obj-y += alternative.o i8253.o pci-nommu.o 
hw_breakpoint.o
 obj-y  += tsc.o tsc_msr.o io_delay.o rtc.o
 obj-y  += pci-iommu_table.o
 obj-y  += resource.o
+obj-y  += irqflags.o
 
 obj-y  += process.o
 obj-y  += fpu/
diff --git a/arch/x86/kernel/irqflags.S b/arch/x86/kernel/irqflags.S
new file mode 100644
index ..3817eb748eb4
--- /dev/null
+++ b/arch/x86/kernel/irqflags.S
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+#include 
+#include 
+
+/*
+ * unsigned long native_save_fl(void)
+ */
+ENTRY(native_save_fl)
+   pushf
+   pop %_ASM_AX
+   ret
+ENDPROC(native_save_fl)
+EXPORT_SYMBOL(native_save_fl)
+
+/*
+ * void native_restore_fl(unsigned long flags)
+ * %eax/%rdi: flags
+ */
+ENTRY(native_restore_fl)
+   push %_ASM_ARG1
+   popf
+   ret
+ENDPROC(native_restore_fl)
+EXPORT_SYMBOL(native_restore_fl)
-- 
2.18.0.233.g985f88cf7e-goog

[4.4 STABLE BACKPORT] x86: paravirt: make native_save_fl extern inline

[Nick Desaulniers]

native_save_fl() is marked static inline, but by using it as
a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.

paravirt's use of native_save_fl() also requires that no GPRs other than
%rax are clobbered.

Compilers have different heuristics which they use to emit stack guard
code, the emittance of which can break paravirt's callee saved assumption
by clobbering %rcx.

Marking a function definition extern inline means that if this version
cannot be inlined, then the out-of-line version will be preferred. By
having the out-of-line version be implemented in assembly, it cannot be
instrumented with a stack protector, which might violate custom calling
conventions that code like paravirt rely on.

The semantics of extern inline has changed since gnu89. This means that
folks using GCC versions >= 5.1 may see symbol redefinition errors at
link time for subdirs that override KBUILD_CFLAGS (making the C standard
used implicit) regardless of this patch. This has been cleaned up
earlier in the patch set, but is left as a note in the commit message
for future travelers.

Reports:
https://lkml.org/lkml/2018/5/7/534
https://github.com/ClangBuiltLinux/linux/issues/16

Discussion:
https://bugs.llvm.org/show_bug.cgi?id=37512
https://lkml.org/lkml/2018/5/24/1371

Thanks to the many folks that participated in the discussion.

Acked-by: Juergen Gross 
Debugged-by: Alistair Strachan 
Debugged-by: Matthias Kaehlcke 
Reported-by: Sedat Dilek 
Signed-off-by: Nick Desaulniers 
Suggested-by: Arnd Bergmann 
Suggested-by: H. Peter Anvin 
Suggested-by: Tom Stellar 
Tested-by: Sedat Dilek 
---
Backport for 4.4. 4.4 is missing commit 784d5699eddc "x86: move exports to
actual definitions" which doesn't apply cleanly, and not really worth
backporting IMO. It's simpler to change this patch from upstream:
+ #include 
rather than
+ #include 

 arch/x86/include/asm/irqflags.h |  2 +-
 arch/x86/kernel/Makefile|  1 +
 arch/x86/kernel/irqflags.S  | 26 ++
 3 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/irqflags.S

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index b77f5edb03b0..0056bc945cd1 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -8,7 +8,7 @@
  * Interrupt control:
  */
 
-static inline unsigned long native_save_fl(void)
+extern inline unsigned long native_save_fl(void)
 {
unsigned long flags;
 
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index b1b78ffe01d0..7947cee61f61 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -41,6 +41,7 @@ obj-y += alternative.o i8253.o pci-nommu.o 
hw_breakpoint.o
 obj-y  += tsc.o tsc_msr.o io_delay.o rtc.o
 obj-y  += pci-iommu_table.o
 obj-y  += resource.o
+obj-y  += irqflags.o
 
 obj-y  += process.o
 obj-y  += fpu/
diff --git a/arch/x86/kernel/irqflags.S b/arch/x86/kernel/irqflags.S
new file mode 100644
index ..3817eb748eb4
--- /dev/null
+++ b/arch/x86/kernel/irqflags.S
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include 
+#include 
+#include 
+
+/*
+ * unsigned long native_save_fl(void)
+ */
+ENTRY(native_save_fl)
+   pushf
+   pop %_ASM_AX
+   ret
+ENDPROC(native_save_fl)
+EXPORT_SYMBOL(native_save_fl)
+
+/*
+ * void native_restore_fl(unsigned long flags)
+ * %eax/%rdi: flags
+ */
+ENTRY(native_restore_fl)
+   push %_ASM_ARG1
+   popf
+   ret
+ENDPROC(native_restore_fl)
+EXPORT_SYMBOL(native_restore_fl)
-- 
2.18.0.233.g985f88cf7e-goog

Re: [PATCH] i2c: aspeed: Adjust spinlock scope in the irq handler

[Wolfram Sang]

On Mon, Jul 02, 2018 at 02:40:11PM -0700, Jae Hyun Yoo wrote:
> This patch adjusts spinlock scope to make it wrap the whole irq
> handler using a single lock/unlock which covers both master and
> slave handlers.
> 
> Signed-off-by: Jae Hyun Yoo 

Applied to for-next, thanks!

Not related to these patches, but there is an issue found with sparse:

drivers/i2c/busses/i2c-aspeed.c:875:38: warning: incorrect type in assignment 
(different modifiers)
drivers/i2c/busses/i2c-aspeed.c:875:38:expected unsigned int ( 
*get_clk_reg_val )( ... )
drivers/i2c/busses/i2c-aspeed.c:875:38:got void const *const data

Maybe someone wants to have a go at this...



signature.asc
Description: PGP signature

Re: [PATCH] i2c: aspeed: Adjust spinlock scope in the irq handler

[Wolfram Sang]

On Mon, Jul 02, 2018 at 02:40:11PM -0700, Jae Hyun Yoo wrote:
> This patch adjusts spinlock scope to make it wrap the whole irq
> handler using a single lock/unlock which covers both master and
> slave handlers.
> 
> Signed-off-by: Jae Hyun Yoo 

Applied to for-next, thanks!

Not related to these patches, but there is an issue found with sparse:

drivers/i2c/busses/i2c-aspeed.c:875:38: warning: incorrect type in assignment 
(different modifiers)
drivers/i2c/busses/i2c-aspeed.c:875:38:expected unsigned int ( 
*get_clk_reg_val )( ... )
drivers/i2c/busses/i2c-aspeed.c:875:38:got void const *const data

Maybe someone wants to have a go at this...



signature.asc
Description: PGP signature

RFC on OTi-2108 USB Data Link cable driver implementation

[Urja Rannikko]

Hi,

This device presents itself as an USB CD Drive, and extends that
"metaphor" (kinda) to how it transfers data (= ethernet frames in our
case) between hosts. That is one SCSI vendor command (0xD8) over
bulk-only mass-storage is used to poll whether data is available and
another one (0xD9) is used to transfer the data. Yes, this is not good
but the hardware is what it is.

The question is, if i were to implement a driver for this, which is
the better option:
1) Make a driver that (ab)uses the kernel SCSI and usb mass storage
drivers to do the transfers.
or
2) Make a driver that contains a minimal set of usb mass storage bulk
transfer code to do what is needed for this device.

If you answer 1, I'd like to know the appropriate API layer to hook
into, and how to probe for the device and such...

Second case is in many ways much simpler (though I'm not sure if i
need to detach the mass storage driver from the device in some way),
but duplicates some amount of code.

Please CC me in any replies to this thread.

Extra context information:
I bought this device for cheap expecting it to work as an usb network
cable in linux. It doesn't, but if i have the spare cycles i might
just make it happen. I found a driver online for windows 7 that makes
it present the cable as a "virtual" network card, and I was able to
capture usb traces from that already. The usb ID is 0ea0:2108, though
the windows driver also supports some other OTi host-to-host chips
(like the apparently newer 2208) so maybe one day a linux driver might
too...

-- 
Urja Rannikko

RFC on OTi-2108 USB Data Link cable driver implementation

[Urja Rannikko]

Hi,

This device presents itself as an USB CD Drive, and extends that
"metaphor" (kinda) to how it transfers data (= ethernet frames in our
case) between hosts. That is one SCSI vendor command (0xD8) over
bulk-only mass-storage is used to poll whether data is available and
another one (0xD9) is used to transfer the data. Yes, this is not good
but the hardware is what it is.

The question is, if i were to implement a driver for this, which is
the better option:
1) Make a driver that (ab)uses the kernel SCSI and usb mass storage
drivers to do the transfers.
or
2) Make a driver that contains a minimal set of usb mass storage bulk
transfer code to do what is needed for this device.

If you answer 1, I'd like to know the appropriate API layer to hook
into, and how to probe for the device and such...

Second case is in many ways much simpler (though I'm not sure if i
need to detach the mass storage driver from the device in some way),
but duplicates some amount of code.

Please CC me in any replies to this thread.

Extra context information:
I bought this device for cheap expecting it to work as an usb network
cable in linux. It doesn't, but if i have the spare cycles i might
just make it happen. I found a driver online for windows 7 that makes
it present the cable as a "virtual" network card, and I was able to
capture usb traces from that already. The usb ID is 0ea0:2108, though
the windows driver also supports some other OTi host-to-host chips
(like the apparently newer 2208) so maybe one day a linux driver might
too...

-- 
Urja Rannikko

Re: [RFC] x86, tsc: Add kcmdline args for skipping tsc calibration sequences

[patrickg]

Sorry for the delay.  Expect another large delay if you have any questions.  
I'm pretty heavily context switching.

I wanted to double check to make sure that I wasn't mis-documenting and 
mis-remembering things.

On 07/13/2018 07:40 PM, Brown, Len wrote:
> We disabled CPUID-based TSC calibration on SKX in December for several 
> reasons.
> If you still have it enabled, you need this patch:
> 
> commit b511203093489eb1829cb4de86e8214752205ac6
> x86/tsc: Fix erroneous TSC rate on Skylake Xeon
So, yeah.  I tested against mainline RHEL-alike elrepo builds before and I 
still saw the TSC running faster.

I've also tested against 3.10.0-862.6.3 which has those patches backported.

> 
> If you are referring to another platform that has CPUID-TSC calibration...
> it should still work on an over-clocked system.  Over-clocked platforms should
> use exactly the same reference crystal as non-overclocked platforms, but 
> should
> modify the crystal/core multiplier.   If you are changing the reference
> crystal, then I believe you are using an un-supported hardware configuration,
> and my ability to support you is limited.
FYI for reference this is SKX Server.  Specifically the `gold` series procs.

Now; I'm not sure if we happen to be doing something strange in regards to 
changing the ref crystal.  I'll need to poke at them to figure that out.

I'm working on building something up with a lot of verbosity so that I can see 
if perhaps something is happening or not happening in an expected way.

Re: [RFC] x86, tsc: Add kcmdline args for skipping tsc calibration sequences

[patrickg]

Sorry for the delay.  Expect another large delay if you have any questions.  
I'm pretty heavily context switching.

I wanted to double check to make sure that I wasn't mis-documenting and 
mis-remembering things.

On 07/13/2018 07:40 PM, Brown, Len wrote:
> We disabled CPUID-based TSC calibration on SKX in December for several 
> reasons.
> If you still have it enabled, you need this patch:
> 
> commit b511203093489eb1829cb4de86e8214752205ac6
> x86/tsc: Fix erroneous TSC rate on Skylake Xeon
So, yeah.  I tested against mainline RHEL-alike elrepo builds before and I 
still saw the TSC running faster.

I've also tested against 3.10.0-862.6.3 which has those patches backported.

> 
> If you are referring to another platform that has CPUID-TSC calibration...
> it should still work on an over-clocked system.  Over-clocked platforms should
> use exactly the same reference crystal as non-overclocked platforms, but 
> should
> modify the crystal/core multiplier.   If you are changing the reference
> crystal, then I believe you are using an un-supported hardware configuration,
> and my ability to support you is limited.
FYI for reference this is SKX Server.  Specifically the `gold` series procs.

Now; I'm not sure if we happen to be doing something strange in regards to 
changing the ref crystal.  I'll need to poke at them to figure that out.

I'm working on building something up with a lot of verbosity so that I can see 
if perhaps something is happening or not happening in an expected way.

Re: [PATCH] i2c: aspeed: Add newline characters into message printings.

[Wolfram Sang]

On Mon, Jul 02, 2018 at 02:13:59PM -0700, Jae Hyun Yoo wrote:
> There are some log printing without a newline character. This
> patch adds the missing newline characters.
> 
> Signed-off-by: Jae Hyun Yoo 

Applied to for-next, thanks!



signature.asc
Description: PGP signature

Re: [PATCH] i2c: aspeed: Add newline characters into message printings.

[Wolfram Sang]

On Mon, Jul 02, 2018 at 02:13:59PM -0700, Jae Hyun Yoo wrote:
> There are some log printing without a newline character. This
> patch adds the missing newline characters.
> 
> Signed-off-by: Jae Hyun Yoo 

Applied to for-next, thanks!



signature.asc
Description: PGP signature

Re: [PATCH] i2c: aspeed: Fix initial values of master and slave state

[Wolfram Sang]

On Mon, Jul 02, 2018 at 02:20:28PM -0700, Jae Hyun Yoo wrote:
> This patch changes the order of enum aspeed_i2c_master_state and
> enum aspeed_i2c_slave_state defines to make their initial value to
> ASPEED_I2C_MASTER_INACTIVE and ASPEED_I2C_SLAVE_STOP respectively.
> In case of multi-master use, if a slave data comes ahead of the
> first master xfer, master_state starts from an invalid state so
> this change fixes the issue.
> 
> Signed-off-by: Jae Hyun Yoo 

Applied to for-next, thanks!



signature.asc
Description: PGP signature

Re: [PATCH] i2c: aspeed: Fix initial values of master and slave state

[Wolfram Sang]

On Mon, Jul 02, 2018 at 02:20:28PM -0700, Jae Hyun Yoo wrote:
> This patch changes the order of enum aspeed_i2c_master_state and
> enum aspeed_i2c_slave_state defines to make their initial value to
> ASPEED_I2C_MASTER_INACTIVE and ASPEED_I2C_SLAVE_STOP respectively.
> In case of multi-master use, if a slave data comes ahead of the
> first master xfer, master_state starts from an invalid state so
> this change fixes the issue.
> 
> Signed-off-by: Jae Hyun Yoo 

Applied to for-next, thanks!



signature.asc
Description: PGP signature

Re: [PATCH 1/3] perf/core: Make sure the ring-buffer is mapped in all page-tables

[Andy Lutomirski]

> On Jul 20, 2018, at 11:37 AM, Joerg Roedel  wrote:
> 
>> On Fri, Jul 20, 2018 at 12:32:10PM -0700, Andy Lutomirski wrote:
>> I'm just reading your changelog, and you said the PMDs are no longer
>> shared between the page tables.  So this presumably means that
>> vmalloc_fault() no longer actually works correctly on PTI systems.  I
>> didn't read the code to figure out *why* it doesn't work, but throwing
>> random vmalloc_sync_all() calls around is wrong.
> 
> Hmm, so the whole point of vmalloc_fault() fault is to sync changes from
> swapper_pg_dir to process page-tables when the relevant parts of the
> kernel page-table are not shared, no?
> 
> That is also the reason we don't see this on 64 bit, because there these
> parts *are* shared.
> 
> So with that reasoning vmalloc_fault() works as designed, except that
> a warning is issued when it's happens in the NMI path. That warning comes
> from
> 
>ebc8827f75954 x86: Barf when vmalloc and kmemcheck faults happen in NMI
> 
> which went into 2.6.37 and was added because the NMI handler were not
> nesting-safe back then. Reason probably was that the handler on 64 bit
> has to use an IST stack and a nested NMI would overwrite the stack of
> the upper handler.  We don't have this problem on 32 bit as a nested NMI
> will not do another stack-switch there.
> 

Thanks for digging!  The problem was presumably that vmalloc_fault() will IRET 
and re-enable NMIs on the way out.  But we’ve supported page faults on user 
memory in NMI handlers on 32-bit and 64-bit for quite a while, and it’s fine 
now.

I would remove the warning, re-test, and revert the other patch.

The one case we can’t handle in vmalloc_fault() is a fault on a stack access. I 
don’t expect this to be a problem for PTI. It was a problem for 
CONFIG_VMAP_STACK, though.

> I am not sure about 64 bit, but there is a lot of assembly magic to make
> NMIs nesting-safe, so I guess the problem should be gone there too.
> 
> 
> Regards,
> 
>Joerg

Re: [PATCH 1/3] perf/core: Make sure the ring-buffer is mapped in all page-tables

[Andy Lutomirski]

> On Jul 20, 2018, at 11:37 AM, Joerg Roedel  wrote:
> 
>> On Fri, Jul 20, 2018 at 12:32:10PM -0700, Andy Lutomirski wrote:
>> I'm just reading your changelog, and you said the PMDs are no longer
>> shared between the page tables.  So this presumably means that
>> vmalloc_fault() no longer actually works correctly on PTI systems.  I
>> didn't read the code to figure out *why* it doesn't work, but throwing
>> random vmalloc_sync_all() calls around is wrong.
> 
> Hmm, so the whole point of vmalloc_fault() fault is to sync changes from
> swapper_pg_dir to process page-tables when the relevant parts of the
> kernel page-table are not shared, no?
> 
> That is also the reason we don't see this on 64 bit, because there these
> parts *are* shared.
> 
> So with that reasoning vmalloc_fault() works as designed, except that
> a warning is issued when it's happens in the NMI path. That warning comes
> from
> 
>ebc8827f75954 x86: Barf when vmalloc and kmemcheck faults happen in NMI
> 
> which went into 2.6.37 and was added because the NMI handler were not
> nesting-safe back then. Reason probably was that the handler on 64 bit
> has to use an IST stack and a nested NMI would overwrite the stack of
> the upper handler.  We don't have this problem on 32 bit as a nested NMI
> will not do another stack-switch there.
> 

Thanks for digging!  The problem was presumably that vmalloc_fault() will IRET 
and re-enable NMIs on the way out.  But we’ve supported page faults on user 
memory in NMI handlers on 32-bit and 64-bit for quite a while, and it’s fine 
now.

I would remove the warning, re-test, and revert the other patch.

The one case we can’t handle in vmalloc_fault() is a fault on a stack access. I 
don’t expect this to be a problem for PTI. It was a problem for 
CONFIG_VMAP_STACK, though.

> I am not sure about 64 bit, but there is a lot of assembly magic to make
> NMIs nesting-safe, so I guess the problem should be gone there too.
> 
> 
> Regards,
> 
>Joerg

Re: [patch v3] mm, oom: fix unnecessary killing of additional processes

[David Rientjes]

On Sat, 21 Jul 2018, Tetsuo Handa wrote:

> Why [PATCH 2/2] in https://marc.info/?l=linux-mm=153119509215026=4 does 
> not
> solve your problem?
> 

Such an invasive patch, and completely rewrites the oom reaper.  I now 
fully understand your frustration with the cgroup aware oom killer being 
merged into -mm without any roadmap to actually being merged.  I agree 
with you that it should be dropped, not sure why it has not been since 
there is no active review on the proposed patchset from four months ago, 
posted twice, that fixes the issues with it, or those patches being merged 
so the damn thing can actually make progress.

Re: [patch v3] mm, oom: fix unnecessary killing of additional processes

[David Rientjes]

On Sat, 21 Jul 2018, Tetsuo Handa wrote:

> Why [PATCH 2/2] in https://marc.info/?l=linux-mm=153119509215026=4 does 
> not
> solve your problem?
> 

Such an invasive patch, and completely rewrites the oom reaper.  I now 
fully understand your frustration with the cgroup aware oom killer being 
merged into -mm without any roadmap to actually being merged.  I agree 
with you that it should be dropped, not sure why it has not been since 
there is no active review on the proposed patchset from four months ago, 
posted twice, that fixes the issues with it, or those patches being merged 
so the damn thing can actually make progress.