[tip:irq/core] BUILD SUCCESS 559db8c7e6ed1f24baf7264a6966ee4f051c6446

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
irq/core
branch HEAD: 559db8c7e6ed1f24baf7264a6966ee4f051c6446  Merge tag 'irqchip-5.11' 
of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

elapsed time: 725m

configs tested: 123
configs skipped: 3

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc  tqm8xx_defconfig
sh  defconfig
parisc  defconfig
m68km5407c3_defconfig
armvexpress_defconfig
sh shx3_defconfig
nios2alldefconfig
sh  polaris_defconfig
m68kmvme16x_defconfig
openriscdefconfig
mipsqi_lb60_defconfig
arm   tegra_defconfig
mips  rm200_defconfig
sh   j2_defconfig
powerpc pseries_defconfig
mipsbcm63xx_defconfig
mipsnlm_xlp_defconfig
powerpc  pcm030_defconfig
m68k  atari_defconfig
mips  loongson3_defconfig
powerpcamigaone_defconfig
powerpc   ebony_defconfig
x86_64  defconfig
alphaallyesconfig
mips  maltasmvp_defconfig
arc nsimosci_hs_smp_defconfig
powerpc mpc832x_mds_defconfig
powerpc   currituck_defconfig
arm  pxa910_defconfig
arm  imote2_defconfig
sh   allmodconfig
powerpc  bamboo_defconfig
mips   rs90_defconfig
shapsh4ad0a_defconfig
riscv allnoconfig
powerpc mpc8315_rdb_defconfig
mips tb0287_defconfig
powerpc  cm5200_defconfig
mipsmaltaup_defconfig
ia64  gensparse_defconfig
armmulti_v7_defconfig
powerpc powernv_defconfig
shsh7763rdp_defconfig
armrealview_defconfig
mips  maltaaprp_defconfig
arm   aspeed_g4_defconfig
nios2 3c120_defconfig
sh  urquell_defconfig
mips   ip27_defconfig
riscvnommu_virt_defconfig
sparc64  alldefconfig
pariscgeneric-32bit_defconfig
cskydefconfig
arm   multi_v4t_defconfig
sh ecovec24_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
alpha   defconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a003-20201213
x86_64   randconfig-a006-20201213
x86_64   randconfig-a002-20201213
x86_64   randconfig-a005-20201213
x86_64   randconfig-a004-20201213
x86_64   randconfig-a001-20201213
i386 randconfig-a001-20201213
i386 randconfig-a004-20201213
i386 randconfig-a003-20201213
i386 randconfig-a002-20201213
i386  

x86_32: CONFIG_PHYSICAL_START problem

[Randy Dunlap]

background:

I was trying to debug a MIPS build error, but it wasn't MIPS-specific,
so I did this, using the MIPS .config file:

make ARCH=i386 O=xx32 olddefconfig

Little to my knowledge, this came up with
CONFIG_PHYSICAL_START=0x8100

Then I built the i386 kernel, and got this message:
ld: kernel image bigger than KERNEL_IMAGE_SIZE

so I promptly changed many =y drivers etc. to =m
and still got the same ld error message.

Well, it must be something else, he said.

I tracked it down to this large value of CONFIG_PHYSICAL_START
and changed it back to its default value, then the kernel
built with no problems.

So far I haven't been able to track the chain of values/changes
that involve PHYSICAL_START, __PAGE_OFFSET, LOAD_OFFSET, etc.

Anyway, I would like to see PHYSICAL_START limited to some
acceptable range of values in arch/x86/Kconfig,
or at a minimum, a little bit better error message coming
from arch/x86/kernel/vmlinux.lds.S:

. = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
   "kernel image bigger than KERNEL_IMAGE_SIZE");

so maybe:

. = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
   "kernel image bigger than KERNEL_IMAGE_SIZE or load address is too 
large");
(or start address)

Comments?

thanks.
-- 
~Randy
Reported-by: Randy Dunlap 

[tip:master] BUILD SUCCESS dc780fed5a1be01ece7e0d5588337340a642183c

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  master
branch HEAD: dc780fed5a1be01ece7e0d5588337340a642183c  Merge branch 'core/entry'

elapsed time: 720m

configs tested: 151
configs skipped: 3

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc  tqm8xx_defconfig
sh  defconfig
parisc  defconfig
m68km5407c3_defconfig
armvexpress_defconfig
sh shx3_defconfig
nios2alldefconfig
sh  polaris_defconfig
m68kmvme16x_defconfig
openriscdefconfig
mipsqi_lb60_defconfig
arm   tegra_defconfig
armmvebu_v5_defconfig
powerpc wii_defconfig
armcerfcube_defconfig
mipsnlm_xlr_defconfig
armspear3xx_defconfig
nds32alldefconfig
powerpcamigaone_defconfig
mips  fuloong2e_defconfig
mips  bmips_stb_defconfig
arm  footbridge_defconfig
mips  ath79_defconfig
mips  rm200_defconfig
sh   j2_defconfig
powerpc pseries_defconfig
mipsbcm63xx_defconfig
mipsnlm_xlp_defconfig
powerpc ps3_defconfig
mips   ip28_defconfig
arm   stm32_defconfig
m68k   sun3_defconfig
armmulti_v7_defconfig
powerpc  mpc885_ads_defconfig
arm davinci_all_defconfig
shedosk7705_defconfig
sh   se7724_defconfig
arm   imx_v6_v7_defconfig
powerpc tqm8540_defconfig
mips  loongson3_defconfig
arm  simpad_defconfig
powerpc  pcm030_defconfig
m68k  atari_defconfig
powerpc   ebony_defconfig
x86_64  defconfig
alphaallyesconfig
mips  maltasmvp_defconfig
arc nsimosci_hs_smp_defconfig
powerpc mpc832x_mds_defconfig
powerpc   currituck_defconfig
arm  pxa910_defconfig
arm  imote2_defconfig
powerpc  ep88xc_defconfig
riscv   defconfig
sh sh7710voipgw_defconfig
mips   lemote2f_defconfig
sh   allmodconfig
powerpc  bamboo_defconfig
mips   rs90_defconfig
shapsh4ad0a_defconfig
riscv allnoconfig
powerpc mpc8315_rdb_defconfig
mips tb0287_defconfig
powerpc  cm5200_defconfig
mipsmaltaup_defconfig
ia64  gensparse_defconfig
powerpc powernv_defconfig
shsh7763rdp_defconfig
armrealview_defconfig
mips  maltaaprp_defconfig
mips rt305x_defconfig
h8300   h8s-sim_defconfig
m68k  amiga_defconfig
ia64  tiger_defconfig
arm   aspeed_g4_defconfig
nios2 3c120_defconfig
sh  urquell_defconfig
mips   ip27_defconfig
riscvnommu_virt_defconfig
sparc64  alldefconfig
pariscgeneric-32bit_defconfig
arm   multi_v4t_defconfig
sh ecovec24_defconfig
cskydefconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
alpha 

[tip:timers/core] BUILD SUCCESS a3356a079da268cd35460d9bfe052c74383e179b

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
timers/core
branch HEAD: a3356a079da268cd35460d9bfe052c74383e179b  ntp: Fix build error

elapsed time: 720m

configs tested: 155
configs skipped: 3

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc  tqm8xx_defconfig
sh  defconfig
parisc  defconfig
m68km5407c3_defconfig
armvexpress_defconfig
sh shx3_defconfig
nios2alldefconfig
sh  polaris_defconfig
m68kmvme16x_defconfig
openriscdefconfig
mipsqi_lb60_defconfig
arm   tegra_defconfig
armmvebu_v5_defconfig
powerpc wii_defconfig
armcerfcube_defconfig
mipsnlm_xlr_defconfig
armspear3xx_defconfig
nds32alldefconfig
powerpcamigaone_defconfig
mips  fuloong2e_defconfig
mips  bmips_stb_defconfig
arm  footbridge_defconfig
mips  ath79_defconfig
mips  rm200_defconfig
sh   j2_defconfig
powerpc pseries_defconfig
mipsbcm63xx_defconfig
mipsnlm_xlp_defconfig
powerpc ps3_defconfig
mips   ip28_defconfig
arm   stm32_defconfig
m68k   sun3_defconfig
armmulti_v7_defconfig
powerpc  mpc885_ads_defconfig
arm davinci_all_defconfig
shedosk7705_defconfig
armshmobile_defconfig
powerpc linkstation_defconfig
shapsh4ad0a_defconfig
arc   tb10x_defconfig
riscv allnoconfig
armmulti_v5_defconfig
sh   se7724_defconfig
arm   imx_v6_v7_defconfig
powerpc tqm8540_defconfig
mips  loongson3_defconfig
arm  simpad_defconfig
powerpc  pcm030_defconfig
m68k  atari_defconfig
powerpc   ebony_defconfig
x86_64  defconfig
alphaallyesconfig
mips  maltasmvp_defconfig
arc nsimosci_hs_smp_defconfig
powerpc mpc832x_mds_defconfig
powerpc   currituck_defconfig
arm  pxa910_defconfig
arm  imote2_defconfig
powerpc  ep88xc_defconfig
riscv   defconfig
sh sh7710voipgw_defconfig
mips   lemote2f_defconfig
sh   allmodconfig
powerpc  bamboo_defconfig
mips   rs90_defconfig
powerpc mpc8315_rdb_defconfig
mips tb0287_defconfig
powerpc  cm5200_defconfig
mipsmaltaup_defconfig
ia64  gensparse_defconfig
powerpc powernv_defconfig
shsh7763rdp_defconfig
armrealview_defconfig
mips  maltaaprp_defconfig
mips rt305x_defconfig
h8300   h8s-sim_defconfig
m68k  amiga_defconfig
ia64  tiger_defconfig
arm   aspeed_g4_defconfig
nios2 3c120_defconfig
sh  urquell_defconfig
mips   ip27_defconfig
riscvnommu_virt_defconfig
sparc64  alldefconfig
pariscgeneric-32bit_defconfig
arm   multi_v4t_defconfig
sh ecovec24_defconfig
cskydefconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32

[PATCH] spi: spi-qcom-qspi: Use irq trigger flags from firmware

[Stephen Boyd]

We don't need to force this to be trigger high here, as the firmware
properly configures the irq flags already. Drop it to save a line.

Cc: Douglas Anderson 
Cc: Rajendra Nayak 
Cc: Mukesh Kumar Savaliya 
Cc: Akash Asthana 
Signed-off-by: Stephen Boyd 
---
 drivers/spi/spi-qcom-qspi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/spi/spi-qcom-qspi.c b/drivers/spi/spi-qcom-qspi.c
index 5eed88af6899..8e70f5e63e0b 100644
--- a/drivers/spi/spi-qcom-qspi.c
+++ b/drivers/spi/spi-qcom-qspi.c
@@ -516,8 +516,7 @@ static int qcom_qspi_probe(struct platform_device *pdev)
ret = platform_get_irq(pdev, 0);
if (ret < 0)
goto exit_probe_master_put;
-   ret = devm_request_irq(dev, ret, qcom_qspi_irq,
-   IRQF_TRIGGER_HIGH, dev_name(dev), ctrl);
+   ret = devm_request_irq(dev, ret, qcom_qspi_irq, 0, dev_name(dev), ctrl);
if (ret) {
dev_err(dev, "Failed to request irq %d\n", ret);
goto exit_probe_master_put;

base-commit: b65054597872ce3aefbc6a666385eabdf9e288da
-- 
https://chromeos.dev

Re: [PATCH v11] ARM: uncompress: Validate start of physical memory against passed DTB

[Stephen Boyd]

Quoting Geert Uytterhoeven (2020-12-10 01:32:01)
> diff --git a/arch/arm/boot/compressed/fdt_check_mem_start.c 
> b/arch/arm/boot/compressed/fdt_check_mem_start.c
> new file mode 100644
> index ..e58c3a79c8a31ec4
> --- /dev/null
> +++ b/arch/arm/boot/compressed/fdt_check_mem_start.c
> @@ -0,0 +1,131 @@
[...]
> +
> +static uint64_t get_val(const fdt32_t *cells, uint32_t ncells)
> +{
> +   uint64_t r = 0;

This assignment is unnecessary?

> +
> +   r = fdt32_ld(cells);
> +   if (ncells > 1)
> +   r = (r << 32) | fdt32_ld(cells + 1);
> +
> +   return r;

Re: [PATCH v6 01/11] firmware: raspberrypi: Keep count of all consumers

[Stephen Boyd]

Quoting Nicolas Saenz Julienne (2020-12-11 08:47:50)
> When unbinding the firmware device we need to make sure it has no
> consumers left. Otherwise we'd leave them with a firmware handle
> pointing at freed memory.
> 
> Keep a reference count of all consumers and introduce rpi_firmware_put()
> which will permit automatically decrease the reference count upon
> unbinding consumer drivers.
> 
> Suggested-by: Uwe Kleine-König 
> Signed-off-by: Nicolas Saenz Julienne 
> Reviewed-by: Florian Fainelli 
> 
> ---

Reviewed-by: Stephen Boyd 

Re: [PATCH v6 03/11] clk: bcm: rpi: Release firmware handle on unbind

[Stephen Boyd]

Quoting Nicolas Saenz Julienne (2020-12-11 08:47:52)
> Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
> interface when unbinding the device.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> Reviewed-by: Florian Fainelli 
> ---

Acked-by: Stephen Boyd 

Re: [PATCH v8 1/2] PCI/ERR: Call pci_bus_reset() before calling ->slot_reset() callback

[Kuppuswamy, Sathyanarayanan]

On 10/26/20 12:37 PM, Kuppuswamy Sathyanarayanan wrote:

Currently if report_error_detected() or report_mmio_enabled()
functions requests PCI_ERS_RESULT_NEED_RESET, current
pcie_do_recovery() implementation does not do the requested
explicit device reset, but instead just calls the
report_slot_reset() on all affected devices. Notifying about the
reset via report_slot_reset() without doing the actual device
reset is incorrect. So call pci_bus_reset() before triggering
->slot_reset() callback.

Gentle ping! Any comments on this patch set?


Signed-off-by: Kuppuswamy Sathyanarayanan 

Reviewed-by: Sinan Kaya 
Reviewed-by: Ashok Raj 
---
  Changes since v7:
   * Rebased on top of v5.10-rc1.

  Changes since v6:
   * None.

  Changes since v5:
   * Added Ashok's Reviewed-by tag.

  Changes since v4:
   * Added check for pci_reset_bus() return value.

  drivers/pci/pcie/err.c | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index c543f419d8f9..315a4d559c4c 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -152,6 +152,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
  {
pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
struct pci_bus *bus;
+   int ret;
  
  	/*

 * Error recovery runs on all subordinates of the first downstream port.
@@ -181,11 +182,12 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
}
  
  	if (status == PCI_ERS_RESULT_NEED_RESET) {

-   /*
-* TODO: Should call platform-specific
-* functions to reset slot before calling
-* drivers' slot_reset callbacks?
-*/
+   ret = pci_reset_bus(dev);
+   if (ret < 0) {
+   pci_err(dev, "Failed to reset %d\n", ret);
+   status = PCI_ERS_RESULT_DISCONNECT;
+   goto failed;
+   }
status = PCI_ERS_RESULT_RECOVERED;
pci_dbg(dev, "broadcast slot_reset message\n");
pci_walk_bus(bus, report_slot_reset, );



--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK

[Miguel Ojeda]

On Sat, Dec 12, 2020 at 5:18 PM Guenter Roeck  wrote:
>
> This patch results in:
>
> arch/sh/kernel/cpu/sh4a/smp-shx3.c: In function 'shx3_prepare_cpus':
> arch/sh/kernel/cpu/sh4a/smp-shx3.c:76:3: error: ignoring return value of 
> 'request_irq' declared with attribute 'warn_unused_result'
>
> when building sh:defconfig. Checking for calls to request_irq()
> suggests that there will be other similar errors in various builds.
> Reverting the patch fixes the problem.

Which ones? From a quick grep and some filtering I could only find one
file with wrong usage apart from this one:

drivers/net/ethernet/lantiq_etop.c:
request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
drivers/net/ethernet/lantiq_etop.c:
request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);

Of course, this does not cover other functions, but it means there
aren't many issues and/or people building the code if nobody complains
within a few weeks. So I think we can fix them as they come.

Cheers,
Miguel

Re: [PATCH v3 0/3] Support wakeup methods of Atmel maXTouch controllers

[Dmitry Torokhov]

On Sat, Dec 12, 2020 at 10:54:35AM +0300, Dmitry Osipenko wrote:
> Hello,
> 
> 12.12.2020 05:43, Dmitry Torokhov пишет:
> > Hi Dmitry,
> > 
> > On Mon, Dec 07, 2020 at 12:22:14AM +0300, Dmitry Osipenko wrote:
> >> Some Atmel maXTouch controllers, like mXT1386 and mXT3432S1 for example,
> >> have a WAKE line that needs to be asserted in order to wake controller
> >> from a deep sleep, otherwise it will be unusable. This series implements
> >> support for the wakeup methods in accordance to the mXT1386 datasheet [1],
> >> see page 29 (chapter "5.8 WAKE Line").
> >>
> >> The mXT1386 is a widely used controller found on many older Android tablet
> >> devices. Touchscreen on Acer A500 tablet now works properly after this
> >> series.
> > 
> > I am trying to understand how your controller is configured on that
> > system. Could you please enable all debug messages in the driver and
> > post the logs? I am a bit confused why the controller needs to be woken
> > up twice in mxt_start() given that according to the spec it is supposed
> > to stay up for 2 seconds after successful I2C transfer...
> 
> From the page 30 in the datasheet:
> 
> "Note that when the mXT1386 is sent into deep sleep mode, it goes to
> sleep immediately. In this case the two-second timeout does not apply
> until the WAKE pin is asserted."
> 
> The debug log seems confirm that quote:
> 
> ...
> [ 1.196404] Family: 160 Variant: 0 Firmware V1.0.AA Objects: 18
> [ 1.196572] T37 Start:118 Size:130 Instances:1 Report IDs:0-0
> [ 1.196586] T44 Start:248 Size:1 Instances:1 Report IDs:0-0
> [ 1.196597] T5 Start:249 Size:9 Instances:1 Report IDs:0-0
> [ 1.196608] T6 Start:258 Size:6 Instances:1 Report IDs:1-1
> [ 1.196617] T38 Start:264 Size:64 Instances:1 Report IDs:0-0
> [ 1.196628] T7 Start:328 Size:3 Instances:1 Report IDs:0-0
> [ 1.196638] T8 Start:331 Size:10 Instances:1 Report IDs:0-0
> [ 1.196648] T9 Start:341 Size:34 Instances:1 Report IDs:2-17
> [ 1.196658] T15 Start:375 Size:11 Instances:2 Report IDs:18-19
> [ 1.196668] T18 Start:397 Size:2 Instances:1 Report IDs:0-0
> [ 1.196678] T22 Start:399 Size:17 Instances:1 Report IDs:20-20
> [ 1.196688] T24 Start:416 Size:19 Instances:1 Report IDs:21-24
> [ 1.196698] T25 Start:435 Size:14 Instances:1 Report IDs:25-25
> [ 1.196708] T27 Start:449 Size:7 Instances:1 Report IDs:26-26
> [ 1.196718] T28 Start:456 Size:6 Instances:1 Report IDs:27-27
> [ 1.196728] T40 Start:462 Size:5 Instances:1 Report IDs:0-0
> [ 1.196738] T41 Start:467 Size:6 Instances:1 Report IDs:0-0
> [ 1.196748] T43 Start:473 Size:6 Instances:1 Report IDs:0-0
> [ 1.196852] Direct firmware load for maxtouch.cfg failed with error -2
> [ 1.197305] T6 Config Checksum: 0x8D7459
> [ 1.197318] T6 Status 0x90 RESET CAL
> [ 1.197543] Initialized power cfg: ACTV 10, IDLE 50
> [ 1.198387] Touchscreen size X1279Y799
> ...
> [ 1.211686] T6 Status 0x00 OK
> ...
> [15.576573] Set T7 ACTV:10 IDLE:50
> [15.592142] T6 Status 0x10 CAL
> [15.597920] T6 Status 0x00 OK
> [15.604846] Set T7 ACTV:0 IDLE:0
> [15.831477] waking up controller
> [15.862912] Set T7 ACTV:10 IDLE:50
> [15.872783] Set T7 ACTV:0 IDLE:0

Thank you for the logs. I am confused where these calls to put the
controller into deep sleep are coming from. Does something constantly
open and close input device? Do you have any additional patches? We
definitely do not issue deep sleep request in mxt_start(). Do you mind
putting dump_stack() into mxt_set_t7_power_cfg() to see where the calls
are coming from?

I also do not see additional "waking up controller" messages after
requesting the chip via T7 to be configured to be active, which I'd
expected to see if we indeed needed to wake it up again for T6 to
succeed.

Thanks.

-- 
Dmitry

[GIT PULL] auxdisplay for v5.11

[Miguel Ojeda]

Hi Linus,

This time there have been quite a few changes in auxdisplay thanks to
a refactor by Lars Poeschel to share code in order to introduce a new driver.

I am sending these earlier than usual. Please also note I am using
a different email address than usual, too.

Cheers,
Miguel

The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891:

  Linux 5.10-rc2 (2020-11-01 14:43:51 -0800)

are available in the Git repository at:

  https://github.com/ojeda/linux.git tags/auxdisplay-for-linus-v5.11

for you to fetch changes up to 351dcacc6d774258be9fec6f51c14f8ff38243f6:

  auxdisplay: panel: Remove redundant charlcd_ops structures (2020-11-16 
17:13:37 +0100)


A bigger set of changes than usual for auxdisplay:

  - Significant refactor work to make charlcd independent
of device, i.e. hd44780 (Lars Poeschel)

  - New driver: lcd2s (Lars Poeschel)

  - Fixes on top of the rework while being tested in -next
(Lars Poeschel, Dan Carpenter and kernel test robot)


Dan Carpenter (1):
  auxdisplay: fix use after free in lcd2s_i2c_remove()

Lars Poeschel (28):
  auxdisplay: Use an enum for charlcd backlight on/off ops
  auxdisplay: Introduce hd44780_common.[ch]
  auxdisplay: Move hwidth and bwidth to struct hd44780_common
  auxdisplay: Move ifwidth to struct hd44780_common
  auxdisplay: Move write_data pointer to hd44780_common
  auxdisplay: Move write_cmd pointers to hd44780 drivers
  auxdisplay: Move addr out of charlcd_priv
  auxdisplay: hd44780_common_print
  auxdisplay: provide hd44780_common_gotoxy
  auxdisplay: add home to charlcd_ops
  auxdisplay: Move clear_display to hd44780_common
  auxdisplay: make charlcd_backlight visible to hd44780_common
  auxdisplay: Make use of enum for backlight on / off
  auxdisplay: Move init_display to hd44780_common
  auxdisplay: implement various hd44780_common_ functions
  auxdisplay: cleanup unnecessary hd44780 code in charlcd
  auxdisplay: Move char redefine code to hd44780_common
  auxdisplay: Call charlcd_backlight in place
  auxdisplay: hd44780_common: Reduce clear_display timeout
  auxdisplay: hd44780: Remove clear_fast
  auxdisplay: charlcd: replace last device specific stuff
  auxdisplay: Change gotoxy calling interface
  auxdisplay: charlcd: Do not print chars at end of line
  auxdisplay: lcd2s DT binding doc
  auxdisplay: add a driver for lcd2s character display
  auxdisplay: hd44780_common: Fix build error
  auxdisplay: panel: Fix missing print function pointer
  auxdisplay: panel: Remove redundant charlcd_ops structures

kernel test robot (1):
  auxdisplay: fix platform_no_drv_owner.cocci warnings

 .../bindings/auxdisplay/modtronix,lcd2s.yaml   |  58 +++
 .../devicetree/bindings/vendor-prefixes.yaml   |   2 +
 drivers/auxdisplay/Kconfig |  33 +-
 drivers/auxdisplay/Makefile|   2 +
 drivers/auxdisplay/charlcd.c   | 412 ++---
 drivers/auxdisplay/charlcd.h   |  86 -
 drivers/auxdisplay/hd44780.c   | 120 --
 drivers/auxdisplay/hd44780_common.c| 361 ++
 drivers/auxdisplay/hd44780_common.h|  33 ++
 drivers/auxdisplay/lcd2s.c | 402 
 drivers/auxdisplay/panel.c | 173 -
 11 files changed, 1218 insertions(+), 464 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml
 create mode 100644 drivers/auxdisplay/hd44780_common.c
 create mode 100644 drivers/auxdisplay/hd44780_common.h
 create mode 100644 drivers/auxdisplay/lcd2s.c

Re: [PATCH v2 net-next 6/6] net: dsa: ocelot: request DSA to fix up lack of address learning on CPU port

[Florian Fainelli]

On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> Given the following setup:
> 
> ip link add br0 type bridge
> ip link set eno0 master br0
> ip link set swp0 master br0
> ip link set swp1 master br0
> ip link set swp2 master br0
> ip link set swp3 master br0
> 
> Currently, packets received on a DSA slave interface (such as swp0)
> which should be routed by the software bridge towards a non-switch port
> (such as eno0) are also flooded towards the other switch ports (swp1,
> swp2, swp3) because the destination is unknown to the hardware switch.
> 
> This patch addresses the issue by monitoring the addresses learnt by the
> software bridge on eno0, and adding/deleting them as static FDB entries
> on the CPU port accordingly.
> 
> Signed-off-by: Vladimir Oltean 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v2 net-next 5/6] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors

[Florian Fainelli]

On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> Some DSA switches (and not only) cannot learn source MAC addresses from
> packets injected from the CPU. They only perform hardware address
> learning from inbound traffic.
> 
> This can be problematic when we have a bridge spanning some DSA switch
> ports and some non-DSA ports (which we'll call "foreign interfaces" from
> DSA's perspective).
> 
> There are 2 classes of problems created by the lack of learning on
> CPU-injected traffic:
> - excessive flooding, due to the fact that DSA treats those addresses as
>   unknown
> - the risk of stale routes, which can lead to temporary packet loss
> 
> To illustrate the second class, consider the following situation, which
> is common in production equipment (wireless access points, where there
> is a WLAN interface and an Ethernet switch, and these form a single
> bridging domain).
> 
>  AP 1:
>  ++
>  |  br0   |
>  ++
>  ++ ++ ++ ++ ++
>  |swp0| |swp1| |swp2| |swp3| |wlan0   |
>  ++ ++ ++ ++ ++
>|   ^^
>|   ||
>|   ||
>|Client A  Client B
>|
>|
>|
>  ++ ++ ++ ++ ++
>  |swp0| |swp1| |swp2| |swp3| |wlan0   |
>  ++ ++ ++ ++ ++
>  ++
>  |  br0   |
>  ++
>  AP 2
> 
> - br0 of AP 1 will know that Clients A and B are reachable via wlan0
> - the hardware fdb of a DSA switch driver today is not kept in sync with
>   the software entries on other bridge ports, so it will not know that
>   clients A and B are reachable via the CPU port UNLESS the hardware
>   switch itself performs SA learning from traffic injected from the CPU.
>   Nonetheless, a substantial number of switches don't.
> - the hardware fdb of the DSA switch on AP 2 may autonomously learn that
>   Client A and B are reachable through swp0. Therefore, the software br0
>   of AP 2 also may or may not learn this. In the example we're
>   illustrating, some Ethernet traffic has been going on, and br0 from AP
>   2 has indeed learnt that it can reach Client B through swp0.
> 
> One of the wireless clients, say Client B, disconnects from AP 1 and
> roams to AP 2. The topology now looks like this:
> 
>  AP 1:
>  ++
>  |  br0   |
>  ++
>  ++ ++ ++ ++ ++
>  |swp0| |swp1| |swp2| |swp3| |wlan0   |
>  ++ ++ ++ ++ ++
>|^
>||
>| Client A
>|
>|
>| Client B
>||
>|v
>  ++ ++ ++ ++ ++
>  |swp0| |swp1| |swp2| |swp3| |wlan0   |
>  ++ ++ ++ ++ ++
>  ++
>  |  br0   |
>  ++
>  AP 2
> 
> - br0 of AP 1 still knows that Client A is reachable via wlan0 (no change)
> - br0 of AP 1 will (possibly) know that Client B has left wlan0. There
>   are cases where it might never find out though. Either way, DSA today
>   does not process that notification in any way.
> - the hardware FDB of the DSA switch on AP 1 may learn autonomously that
>   Client B can be reached via swp0, if it receives any packet with
>   Client 1's source MAC address over Ethernet.
> - the hardware 

[PATCH] kvm: don't lose the higher 32 bits of tlbs_dirty

[Lai Jiangshan]

From: Lai Jiangshan 

In kvm_mmu_notifier_invalidate_range_start(), tlbs_dirty is used as:
need_tlb_flush |= kvm->tlbs_dirty;
with need_tlb_flush's type being int and tlbs_dirty's type being long.

It means that tlbs_dirty is always used as int and the higher 32 bits
is useless. We can just change need_tlb_flush's type to long to
make full use of tlbs_dirty.

Signed-off-by: Lai Jiangshan 
---
 virt/kvm/kvm_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2541a17ff1c4..4e519a517e9f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -470,7 +470,8 @@ static int kvm_mmu_notifier_invalidate_range_start(struct 
mmu_notifier *mn,
const struct mmu_notifier_range *range)
 {
struct kvm *kvm = mmu_notifier_to_kvm(mn);
-   int need_tlb_flush = 0, idx;
+   long need_tlb_flush = 0;
+   int idx;
 
idx = srcu_read_lock(>srcu);
spin_lock(>mmu_lock);
-- 
2.19.1.6.gb485710b

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

[Ian Kent]

On Fri, 2020-12-11 at 10:17 +0800, Ian Kent wrote:
> On Fri, 2020-12-11 at 10:01 +0800, Ian Kent wrote:
> > > For the patches, there is a mutex_lock in kn->attr_mutex, as
> > > Tejun
> > > mentioned here 
> > > (https://lore.kernel.org/lkml/x8fe0cmu+aq1g...@mtj.duckdns.org/),
> > > maybe a global 
> > > rwsem for kn->iattr will be better??
> > 
> > I wasn't sure about that, IIRC a spin lock could be used around the
> > initial check and checked again at the end which would probably
> > have
> > been much faster but much less conservative and a bit more ugly so
> > I just went the conservative path since there was so much change
> > already.
> 
> Sorry, I hadn't looked at Tejun's reply yet and TBH didn't remember
> it.
> 
> Based on what Tejun said it sounds like that needs work.

Those attribute handling patches were meant to allow taking the rw
sem read lock instead of the write lock for kernfs_refresh_inode()
updates, with the added locking to protect the inode attributes
update since it's called from the VFS both with and without the
inode lock.

Looking around it looks like kernfs_iattrs() is called from multiple
places without a node database lock at all.

I'm thinking that, to keep my proposed change straight forward
and on topic, I should just leave kernfs_refresh_inode() taking
the node db write lock for now and consider the attributes handling
as a separate change. Once that's done we could reconsider what's
needed to use the node db read lock in kernfs_refresh_inode().

It will reduce the effectiveness of the series but it would make
this change much more complicated, and is somewhat off-topic, and
could hamper the chances of reviewers spotting problem with it.

Ian

Re: [PATCH v2 net-next 2/6] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work

[Florian Fainelli]

On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> Currently DSA doesn't add FDB entries on the CPU port, because it only
> does so through switchdev, which is associated with a net_device, and
> there are none of those for the CPU port.
> 
> But actually FDB addresses on the CPU port have some use cases of their
> own, if the switchdev operations are initiated from within the DSA
> layer. There is just one problem with the existing code: it passes a
> structure in dsa_switchdev_event_work which was retrieved directly from
> switchdev, so it contains a net_device. We need to generalize the
> contents to something that covers the CPU port as well: the "ds, port"
> tuple is fine for that.
> 
> Note that the new procedure for notifying the successful FDB offload is
> inspired from the rocker model.
> 
> Also, nothing was being done if added_by_user was false. Let's check for
> that a lot earlier, and don't actually bother to schedule the worker
> for nothing.
> 
> Signed-off-by: Vladimir Oltean 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v2 net-next 3/6] net: dsa: move switchdev event implementation under the same switch/case statement

[Florian Fainelli]

On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> We'll need to start listening to SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE
> events even for interfaces where dsa_slave_dev_check returns false, so
> we need that check inside the switch-case statement for SWITCHDEV_FDB_*.
> 
> This movement also avoids a useless allocation / free of switchdev_work
> on the untreated "default event" case.
> 
> Signed-off-by: Vladimir Oltean 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v2 net-next 4/6] net: dsa: exit early in dsa_slave_switchdev_event if we can't program the FDB

[Florian Fainelli]

On 12/12/2020 6:40 PM, Vladimir Oltean wrote:
> Right now, the following would happen for a switch driver that does not
> implement .port_fdb_add or .port_fdb_del.
> 
> dsa_slave_switchdev_event returns NOTIFY_OK and schedules:
> -> dsa_slave_switchdev_event_work
>-> dsa_port_fdb_add
>   -> dsa_port_notify(DSA_NOTIFIER_FDB_ADD)
>  -> dsa_switch_fdb_add
> -> if (!ds->ops->port_fdb_add) return -EOPNOTSUPP;
>-> an error is printed with dev_dbg, and
>   dsa_fdb_offload_notify(switchdev_work) is not called.
> 
> We can avoid scheduling the worker for nothing and say NOTIFY_OK.

Not sure if this comment is intended to describe what is being added,
only if you have to respin, should this be NOTIFY_DONE?

> Because we don't call dsa_fdb_offload_notify, the static FDB entry will
> remain just in the software bridge.
> 
> Signed-off-by: Vladimir Oltean 

Reviewed-by: Florian Fainelli 
-- 
Florian

INFO: task can't die in irqentry_exit (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:14240d4c Add linux-next specific files for 20201210
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=137b0f9b50
kernel config:  https://syzkaller.appspot.com/x/.config?x=6dbe20fdaa5aaebe
dashboard link: https://syzkaller.appspot.com/bug?extid=b3c4057ecb552e754f4a
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=176d128750
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1236046b50

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b3c4057ecb552e754...@syzkaller.appspotmail.com

INFO: task syz-executor349:9910 can't die for more than 143 seconds.
task:syz-executor349 state:R  running task stack:27536 pid: 9910 ppid:  
8512 flags:0x4006
Call Trace:
 context_switch kernel/sched/core.c:4325 [inline]
 __schedule+0x8eb/0x21b0 kernel/sched/core.c:5076
 preempt_schedule_irq+0x4e/0x90 kernel/sched/core.c:5338
 irqentry_exit_cond_resched kernel/entry/common.c:393 [inline]
 irqentry_exit_cond_resched kernel/entry/common.c:385 [inline]
 irqentry_exit+0x7a/0xa0 kernel/entry/common.c:423
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:628
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/irqflags.h:85 [inline]
RIP: 0010:lock_acquire kernel/locking/lockdep.c:5440 [inline]
RIP: 0010:lock_acquire+0x2c7/0x750 kernel/locking/lockdep.c:5402
Code: 48 c7 c7 00 9c 6b 89 48 83 c4 20 e8 83 49 be 07 b8 ff ff ff ff 65 0f c1 
05 c6 e3 a9 7e 83 f8 01 0f 85 40 03 00 00 ff 34 24 9d  3a fe ff ff 65 ff 05 
2d d2 a9 7e 48 8b 05 a6 51 11 0c e8 a1 3e
RSP: 0018:c9000a90f7c8 EFLAGS: 0246
RAX: 0001 RBX: 192001521efb RCX: 0001
RDX: 1110053f47f1 RSI:  RDI: 
RBP:  R08:  R09: 8f4fe767
R10: fbfff1e9fcec R11:  R12: 0002
R13: 8b78f120 R14:  R15: 
 rcu_lock_acquire include/linux/rcupdate.h:255 [inline]
 rcu_read_lock include/linux/rcupdate.h:644 [inline]
 inet_twsk_purge+0x112/0x810 net/ipv4/inet_timewait_sock.c:268
 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:190
 setup_net+0x508/0x850 net/core/net_namespace.c:365
 copy_net_ns+0x376/0x7b0 net/core/net_namespace.c:483
 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
 copy_namespaces+0x3e5/0x4d0 kernel/nsproxy.c:179
 copy_process+0x2aa7/0x6fe0 kernel/fork.c:2103
 kernel_clone+0xe7/0xad0 kernel/fork.c:2465
 __do_sys_clone+0xc8/0x110 kernel/fork.c:2582
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x44c9c9
RSP: 002b:7f1b22b4fce8 EFLAGS: 0246 ORIG_RAX: 0038
RAX: ffda RBX: 006e3c68 RCX: 0044c9c9
RDX:  RSI:  RDI: e1004d7c
RBP: 006e3c60 R08:  R09: 
R10:  R11: 0246 R12: 006e3c6c
R13: 7fffa37c4aef R14: 7f1b22b509c0 R15: 0001

Showing all locks held in the system:
4 locks held by kworker/u4:0/9:
 #0: 888140baf138 ((wq_completion)netns){+.+.}-{0:0}, at: arch_atomic64_set 
arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: 888140baf138 ((wq_completion)netns){+.+.}-{0:0}, at: atomic64_set 
include/asm-generic/atomic-instrumented.h:856 [inline]
 #0: 888140baf138 ((wq_completion)netns){+.+.}-{0:0}, at: atomic_long_set 
include/asm-generic/atomic-long.h:41 [inline]
 #0: 888140baf138 ((wq_completion)netns){+.+.}-{0:0}, at: set_work_data 
kernel/workqueue.c:616 [inline]
 #0: 888140baf138 ((wq_completion)netns){+.+.}-{0:0}, at: 
set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
 #0: 888140baf138 ((wq_completion)netns){+.+.}-{0:0}, at: 
process_one_work+0x871/0x1630 kernel/workqueue.c:2246
 #1: c9ce7da8 (net_cleanup_work){+.+.}-{0:0}, at: 
process_one_work+0x8a5/0x1630 kernel/workqueue.c:2250
 #2: 8d0bcb50 (pernet_ops_rwsem){}-{3:3}, at: 
cleanup_net+0x9b/0xb10 net/core/net_namespace.c:566
 #3: 8b799728 (rcu_state.exp_mutex){+.+.}-{3:3}, at: exp_funnel_lock 
kernel/rcu/tree_exp.h:290 [inline]
 #3: 8b799728 (rcu_state.exp_mutex){+.+.}-{3:3}, at: 
synchronize_rcu_expedited+0x4ff/0x620 kernel/rcu/tree_exp.h:836
1 lock held by khungtaskd/1661:
 #0: 8b78f120 (rcu_read_lock){}-{1:2}, at: 
debug_show_all_locks+0x53/0x28c kernel/locking/lockdep.c:6254
2 locks held by kworker/0:3/3202:
1 lock held by in:imklog/8197:
 #0: 888018541c70 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 
fs/file.c:923
2 locks held by kworker/0:2/8489:
 #0: 88801087c538 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: 
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: 88801087c538 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: atomic64_set 

Re: [PATCH v2] dt-bindings: leds: Document commonly used LED triggers

[Leizhen (ThunderTown)]

On 2020/12/13 10:39, Leizhen (ThunderTown) wrote:
> 
> 
> On 2020/12/10 16:24, Manivannan Sadhasivam wrote:
>> This commit documents the LED triggers used commonly in the SoCs. Not
>> all triggers are documented as some of them are very application specific.
>> Most of the triggers documented here are currently used in devicetrees
>> of many SoCs.
>>
>> While at it, let's also sort the triggers in ascending order.
>>
>> Signed-off-by: Manivannan Sadhasivam 
>> ---
>>
>> Changes in v2:
>>
>> * Added more triggers, fixed the regex
>> * Sorted triggers in ascending order
>>
>>  .../devicetree/bindings/leds/common.yaml  | 78 ++-
>>  1 file changed, 60 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.yaml 
>> b/Documentation/devicetree/bindings/leds/common.yaml
>> index f1211e7045f1..3c2e2208c1da 100644
>> --- a/Documentation/devicetree/bindings/leds/common.yaml
>> +++ b/Documentation/devicetree/bindings/leds/common.yaml
>> @@ -79,24 +79,66 @@ properties:
>>the LED.
>>  $ref: /schemas/types.yaml#definitions/string
>>  
>> -enum:
>> -# LED will act as a back-light, controlled by the framebuffer system
>> -  - backlight
>> -# LED will turn on (but for leds-gpio see "default-state" property 
>> in
>> -# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
>> -  - default-on
>> -# LED "double" flashes at a load average based rate
>> -  - heartbeat
>> -# LED indicates disk activity
>> -  - disk-activity
>> -# LED indicates IDE disk activity (deprecated), in new 
>> implementations
>> -# use "disk-activity"
>> -  - ide-disk
>> -# LED flashes at a fixed, configurable rate
>> -  - timer
>> -# LED alters the brightness for the specified duration with one 
>> software
>> -# timer (requires "led-pattern" property)
>> -  - pattern
>> +oneOf:
>> +  - items:
>> +  - enum:
>> +# LED indicates mic mute state
>> +  - audio-micmute
>> +# LED indicates audio mute state
>> +  - audio-mute
>> +# LED will act as a back-light, controlled by the 
>> framebuffer system
>> +  - backlight
>> +# LED indicates bluetooth power state
>> +  - bluetooth-power
>> +# LED indicates activity of all CPUs
>> +  - cpu
>> +# LED will turn on (but for leds-gpio see "default-state" 
>> property in
>> +# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
>> +  - default-on
>> +# LED indicates disk activity
>> +  - disk-activity
>> +# LED indicates disk read activity
>> +  - disk-read
>> +# LED indicates disk write activity
>> +  - disk-write
>> +# LED indicates camera flash state
>> +  - flash
>> +# LED "double" flashes at a load average based rate
>> +  - heartbeat
>> +# LED indicates IDE disk activity (deprecated), in new 
>> implementations
>> +# use "disk-activity"
>> +  - ide-disk
>> +# LED indicates MTD memory activity
>> +  - mtd
>> +# LED indicates NAND memory activity (deprecated),
>> +# in new implementations use "mtd"
>> +  - nand-disk
>> +# No trigger assigned to the LED. This is the default mode
>> +# if trigger is absent
>> +  - none
>> +# LED alters the brightness for the specified duration with 
>> one software
>> +# timer (requires "led-pattern" property)
>> +  - pattern
>> +# LED flashes at a fixed, configurable rate
>> +  - timer
>> +# LED indicates camera torch state
>> +  - torch
>> +# LED indicates USB gadget activity
>> +  - usb-gadget
>> +# LED indicates USB host activity
>> +  - usb-host
>> +  - items:
>> +# LED indicates activity of [N]th CPU
>> +  - pattern: "^cpu[0-9]{1,2}$"
>> +  - items:
>> +# LED indicates power status of [N]th Bluetooth HCI device
>> +  - pattern: "^hci[0-9]{1,2}-power$"
>> +  - items:
>> +# LED indicates [N]th MMC storage activity
>> +  - pattern: "^mmc[0-9]{1,2}$"
>> +  - items:
>> +# LED indicates [N]th WLAN Tx activity
>> +  - pattern: "^phy[0-9]{1,2}tx$"
> 
> Only the last three are not listed:
> phy0rx
> ir-power-click
> ir-user-click

I don't know if you're familiar with these two triggers. You can also
consider leaving it to the owner of the corresponding module to update.
Because I just found out there are a lot of unlisted triggers on arm32.

> 
> And the first 

[PATCH v2 net-next 2/6] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work

[Vladimir Oltean]

Currently DSA doesn't add FDB entries on the CPU port, because it only
does so through switchdev, which is associated with a net_device, and
there are none of those for the CPU port.

But actually FDB addresses on the CPU port have some use cases of their
own, if the switchdev operations are initiated from within the DSA
layer. There is just one problem with the existing code: it passes a
structure in dsa_switchdev_event_work which was retrieved directly from
switchdev, so it contains a net_device. We need to generalize the
contents to something that covers the CPU port as well: the "ds, port"
tuple is fine for that.

Note that the new procedure for notifying the successful FDB offload is
inspired from the rocker model.

Also, nothing was being done if added_by_user was false. Let's check for
that a lot earlier, and don't actually bother to schedule the worker
for nothing.

Signed-off-by: Vladimir Oltean 
---
Changes in v2:
Small cosmetic changes (reverse Christmas notation)

 net/dsa/dsa_priv.h |  12 ++
 net/dsa/slave.c| 101 +++--
 2 files changed, 63 insertions(+), 50 deletions(-)

diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 7c96aae9062c..c04225f74929 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -73,6 +73,18 @@ struct dsa_notifier_mtu_info {
int mtu;
 };
 
+struct dsa_switchdev_event_work {
+   struct dsa_switch *ds;
+   int port;
+   struct work_struct work;
+   unsigned long event;
+   /* Specific for SWITCHDEV_FDB_ADD_TO_DEVICE and
+* SWITCHDEV_FDB_DEL_TO_DEVICE
+*/
+   unsigned char addr[ETH_ALEN];
+   u16 vid;
+};
+
 struct dsa_slave_priv {
/* Copy of CPU port xmit for faster access in slave transmit hot path */
struct sk_buff *(*xmit)(struct sk_buff *skb,
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 4a0498bf6c65..5079308a0206 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -2047,72 +2047,63 @@ static int dsa_slave_netdevice_event(struct 
notifier_block *nb,
return NOTIFY_DONE;
 }
 
-struct dsa_switchdev_event_work {
-   struct work_struct work;
-   struct switchdev_notifier_fdb_info fdb_info;
-   struct net_device *dev;
-   unsigned long event;
-};
+static void
+dsa_fdb_offload_notify(struct dsa_switchdev_event_work *switchdev_work)
+{
+   struct dsa_switch *ds = switchdev_work->ds;
+   struct switchdev_notifier_fdb_info info;
+   struct dsa_port *dp;
+
+   if (!dsa_is_user_port(ds, switchdev_work->port))
+   return;
+
+   info.addr = switchdev_work->addr;
+   info.vid = switchdev_work->vid;
+   info.offloaded = true;
+   dp = dsa_to_port(ds, switchdev_work->port);
+   call_switchdev_notifiers(SWITCHDEV_FDB_OFFLOADED,
+dp->slave, , NULL);
+}
 
 static void dsa_slave_switchdev_event_work(struct work_struct *work)
 {
struct dsa_switchdev_event_work *switchdev_work =
container_of(work, struct dsa_switchdev_event_work, work);
-   struct net_device *dev = switchdev_work->dev;
-   struct switchdev_notifier_fdb_info *fdb_info;
-   struct dsa_port *dp = dsa_slave_to_port(dev);
+   struct dsa_switch *ds = switchdev_work->ds;
+   struct dsa_port *dp;
int err;
 
+   dp = dsa_to_port(ds, switchdev_work->port);
+
rtnl_lock();
switch (switchdev_work->event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE:
-   fdb_info = _work->fdb_info;
-   if (!fdb_info->added_by_user)
-   break;
-
-   err = dsa_port_fdb_add(dp, fdb_info->addr, fdb_info->vid);
+   err = dsa_port_fdb_add(dp, switchdev_work->addr,
+  switchdev_work->vid);
if (err) {
-   netdev_dbg(dev, "fdb add failed err=%d\n", err);
+   dev_dbg(ds->dev, "port %d fdb add failed err=%d\n",
+   dp->index, err);
break;
}
-   fdb_info->offloaded = true;
-   call_switchdev_notifiers(SWITCHDEV_FDB_OFFLOADED, dev,
-_info->info, NULL);
+   dsa_fdb_offload_notify(switchdev_work);
break;
 
case SWITCHDEV_FDB_DEL_TO_DEVICE:
-   fdb_info = _work->fdb_info;
-   if (!fdb_info->added_by_user)
-   break;
-
-   err = dsa_port_fdb_del(dp, fdb_info->addr, fdb_info->vid);
+   err = dsa_port_fdb_del(dp, switchdev_work->addr,
+  switchdev_work->vid);
if (err) {
-   netdev_dbg(dev, "fdb del failed err=%d\n", err);
-   dev_close(dev);
+   dev_dbg(ds->dev, "port %d fdb del failed err=%d\n",
+   dp->index, err);
+

[PATCH v2 net-next 3/6] net: dsa: move switchdev event implementation under the same switch/case statement

[Vladimir Oltean]

We'll need to start listening to SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE
events even for interfaces where dsa_slave_dev_check returns false, so
we need that check inside the switch-case statement for SWITCHDEV_FDB_*.

This movement also avoids a useless allocation / free of switchdev_work
on the untreated "default event" case.

Signed-off-by: Vladimir Oltean 
---
Changes in v2:
None.

 net/dsa/slave.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 5079308a0206..99907e76770b 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -2116,31 +2116,29 @@ static int dsa_slave_switchdev_event(struct 
notifier_block *unused,
struct dsa_port *dp;
int err;
 
-   if (event == SWITCHDEV_PORT_ATTR_SET) {
+   switch (event) {
+   case SWITCHDEV_PORT_ATTR_SET:
err = switchdev_handle_port_attr_set(dev, ptr,
 dsa_slave_dev_check,
 dsa_slave_port_attr_set);
return notifier_from_errno(err);
-   }
-
-   if (!dsa_slave_dev_check(dev))
-   return NOTIFY_DONE;
+   case SWITCHDEV_FDB_ADD_TO_DEVICE:
+   case SWITCHDEV_FDB_DEL_TO_DEVICE:
+   if (!dsa_slave_dev_check(dev))
+   return NOTIFY_DONE;
 
-   dp = dsa_slave_to_port(dev);
+   dp = dsa_slave_to_port(dev);
 
-   switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC);
-   if (!switchdev_work)
-   return NOTIFY_BAD;
+   switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC);
+   if (!switchdev_work)
+   return NOTIFY_BAD;
 
-   INIT_WORK(_work->work,
- dsa_slave_switchdev_event_work);
-   switchdev_work->ds = dp->ds;
-   switchdev_work->port = dp->index;
-   switchdev_work->event = event;
+   INIT_WORK(_work->work,
+ dsa_slave_switchdev_event_work);
+   switchdev_work->ds = dp->ds;
+   switchdev_work->port = dp->index;
+   switchdev_work->event = event;
 
-   switch (event) {
-   case SWITCHDEV_FDB_ADD_TO_DEVICE:
-   case SWITCHDEV_FDB_DEL_TO_DEVICE:
fdb_info = ptr;
 
if (!fdb_info->added_by_user) {
@@ -2153,13 +2151,12 @@ static int dsa_slave_switchdev_event(struct 
notifier_block *unused,
switchdev_work->vid = fdb_info->vid;
 
dev_hold(dev);
+   dsa_schedule_work(_work->work);
break;
default:
-   kfree(switchdev_work);
return NOTIFY_DONE;
}
 
-   dsa_schedule_work(_work->work);
return NOTIFY_OK;
 }
 
-- 
2.25.1

[PATCH v2 net-next 5/6] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors

[Vladimir Oltean]

Some DSA switches (and not only) cannot learn source MAC addresses from
packets injected from the CPU. They only perform hardware address
learning from inbound traffic.

This can be problematic when we have a bridge spanning some DSA switch
ports and some non-DSA ports (which we'll call "foreign interfaces" from
DSA's perspective).

There are 2 classes of problems created by the lack of learning on
CPU-injected traffic:
- excessive flooding, due to the fact that DSA treats those addresses as
  unknown
- the risk of stale routes, which can lead to temporary packet loss

To illustrate the second class, consider the following situation, which
is common in production equipment (wireless access points, where there
is a WLAN interface and an Ethernet switch, and these form a single
bridging domain).

 AP 1:
 ++
 |  br0   |
 ++
 ++ ++ ++ ++ ++
 |swp0| |swp1| |swp2| |swp3| |wlan0   |
 ++ ++ ++ ++ ++
   |   ^^
   |   ||
   |   ||
   |Client A  Client B
   |
   |
   |
 ++ ++ ++ ++ ++
 |swp0| |swp1| |swp2| |swp3| |wlan0   |
 ++ ++ ++ ++ ++
 ++
 |  br0   |
 ++
 AP 2

- br0 of AP 1 will know that Clients A and B are reachable via wlan0
- the hardware fdb of a DSA switch driver today is not kept in sync with
  the software entries on other bridge ports, so it will not know that
  clients A and B are reachable via the CPU port UNLESS the hardware
  switch itself performs SA learning from traffic injected from the CPU.
  Nonetheless, a substantial number of switches don't.
- the hardware fdb of the DSA switch on AP 2 may autonomously learn that
  Client A and B are reachable through swp0. Therefore, the software br0
  of AP 2 also may or may not learn this. In the example we're
  illustrating, some Ethernet traffic has been going on, and br0 from AP
  2 has indeed learnt that it can reach Client B through swp0.

One of the wireless clients, say Client B, disconnects from AP 1 and
roams to AP 2. The topology now looks like this:

 AP 1:
 ++
 |  br0   |
 ++
 ++ ++ ++ ++ ++
 |swp0| |swp1| |swp2| |swp3| |wlan0   |
 ++ ++ ++ ++ ++
   |^
   ||
   | Client A
   |
   |
   | Client B
   ||
   |v
 ++ ++ ++ ++ ++
 |swp0| |swp1| |swp2| |swp3| |wlan0   |
 ++ ++ ++ ++ ++
 ++
 |  br0   |
 ++
 AP 2

- br0 of AP 1 still knows that Client A is reachable via wlan0 (no change)
- br0 of AP 1 will (possibly) know that Client B has left wlan0. There
  are cases where it might never find out though. Either way, DSA today
  does not process that notification in any way.
- the hardware FDB of the DSA switch on AP 1 may learn autonomously that
  Client B can be reached via swp0, if it receives any packet with
  Client 1's source MAC address over Ethernet.
- the hardware FDB of the DSA switch on AP 2 still thinks that Client B
  can be reached via swp0. It does not know that it has roamed to wlan0,
  because it doesn't perform SA learning from the CPU port.

Now Client A contacts Client B.

[PATCH v2 net-next 6/6] net: dsa: ocelot: request DSA to fix up lack of address learning on CPU port

[Vladimir Oltean]

Given the following setup:

ip link add br0 type bridge
ip link set eno0 master br0
ip link set swp0 master br0
ip link set swp1 master br0
ip link set swp2 master br0
ip link set swp3 master br0

Currently, packets received on a DSA slave interface (such as swp0)
which should be routed by the software bridge towards a non-switch port
(such as eno0) are also flooded towards the other switch ports (swp1,
swp2, swp3) because the destination is unknown to the hardware switch.

This patch addresses the issue by monitoring the addresses learnt by the
software bridge on eno0, and adding/deleting them as static FDB entries
on the CPU port accordingly.

Signed-off-by: Vladimir Oltean 
---
Changes in v2:
Patch is new.

 drivers/net/dsa/ocelot/felix.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 7dc230677b78..bf48f2e86bcf 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -629,6 +629,7 @@ static int felix_setup(struct dsa_switch *ds)
 
ds->mtu_enforcement_ingress = true;
ds->configure_vlan_while_not_filtering = true;
+   ds->learning_broken_on_cpu_port = true;
 
return 0;
 }
-- 
2.25.1

[PATCH v2 net-next 4/6] net: dsa: exit early in dsa_slave_switchdev_event if we can't program the FDB

[Vladimir Oltean]

Right now, the following would happen for a switch driver that does not
implement .port_fdb_add or .port_fdb_del.

dsa_slave_switchdev_event returns NOTIFY_OK and schedules:
-> dsa_slave_switchdev_event_work
   -> dsa_port_fdb_add
  -> dsa_port_notify(DSA_NOTIFIER_FDB_ADD)
 -> dsa_switch_fdb_add
-> if (!ds->ops->port_fdb_add) return -EOPNOTSUPP;
   -> an error is printed with dev_dbg, and
  dsa_fdb_offload_notify(switchdev_work) is not called.

We can avoid scheduling the worker for nothing and say NOTIFY_OK.
Because we don't call dsa_fdb_offload_notify, the static FDB entry will
remain just in the software bridge.

Signed-off-by: Vladimir Oltean 
---
Changes in v2:
Patch is new.

 net/dsa/slave.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 99907e76770b..53d9d2ea9369 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -2129,6 +2129,9 @@ static int dsa_slave_switchdev_event(struct 
notifier_block *unused,
 
dp = dsa_slave_to_port(dev);
 
+   if (!dp->ds->ops->port_fdb_add || !dp->ds->ops->port_fdb_del)
+   return NOTIFY_DONE;
+
switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC);
if (!switchdev_work)
return NOTIFY_BAD;
-- 
2.25.1

[PATCH v2 net-next 1/6] net: bridge: notify switchdev of disappearance of old FDB entry upon migration

[Vladimir Oltean]

Currently the bridge emits atomic switchdev notifications for
dynamically learnt FDB entries. Monitoring these notifications works
wonders for switchdev drivers that want to keep their hardware FDB in
sync with the bridge's FDB.

For example station A wants to talk to station B in the diagram below,
and we are concerned with the behavior of the bridge on the DUT device:

   DUT
 +-+
 | br0 |
 | +--+ +--+ +--+ +--+ |
 | |  | |  | |  | |  | |
 | | swp0 | | swp1 | | swp2 | | eth0 | |
 +-+
  ||  |
  Station A|  |
   |  |
 +--+--+--++--+--+--+
 |  |  |  ||  |  |  |
 |  | swp0 |  ||  | swp0 |  |
 Another |  +--+  ||  +--+  | Another
  switch | br0|| br0| switch
 |  +--+  ||  +--+  |
 |  |  |  ||  |  |  |
 |  | swp1 |  ||  | swp1 |  |
 +--+--+--++--+--+--+
  |
  Station B

Interfaces swp0, swp1, swp2 are handled by a switchdev driver that has
the following property: frames injected from its control interface bypass
the internal address analyzer logic, and therefore, this hardware does
not learn from the source address of packets transmitted by the network
stack through it. So, since bridging between eth0 (where Station B is
attached) and swp0 (where Station A is attached) is done in software,
the switchdev hardware will never learn the source address of Station B.
So the traffic towards that destination will be treated as unknown, i.e.
flooded.

This is where the bridge notifications come in handy. When br0 on the
DUT sees frames with Station B's MAC address on eth0, the switchdev
driver gets these notifications and can install a rule to send frames
towards Station B's address that are incoming from swp0, swp1, swp2,
only towards the control interface. This is all switchdev driver private
business, which the notification makes possible.

All is fine until someone unplugs Station B's cable and moves it to the
other switch:

   DUT
 +-+
 | br0 |
 | +--+ +--+ +--+ +--+ |
 | |  | |  | |  | |  | |
 | | swp0 | | swp1 | | swp2 | | eth0 | |
 +-+
  ||  |
  Station A|  |
   |  |
 +--+--+--++--+--+--+
 |  |  |  ||  |  |  |
 |  | swp0 |  ||  | swp0 |  |
 Another |  +--+  ||  +--+  | Another
  switch | br0|| br0| switch
 |  +--+  ||  +--+  |
 |  |  |  ||  |  |  |
 |  | swp1 |  ||  | swp1 |  |
 +--+--+--++--+--+--+
   |
   Station B

Luckily for the use cases we care about, Station B is noisy enough that
the DUT hears it (on swp1 this time). swp1 receives the frames and
delivers them to the bridge, who enters the unlikely path in br_fdb_update
of updating an existing entry. It moves the entry in the software bridge
to swp1 and emits an addition notification towards that.

As far as the switchdev driver is concerned, all that it needs to ensure
is that traffic between Station A and Station B is not forever broken.
If it does nothing, then the stale rule to send frames for Station B
towards the control interface remains in place. But Station B is no
longer reachable via the control interface, but via a port that can
offload the bridge port learning attribute. It's just that the port is
prevented from learning this address, since the rule overrides FDB
updates. So the rule needs to go. The question is via what mechanism.

It sure would be possible for this switchdev driver to keep track of all
addresses which are sent to the control interface, and then also listen
for bridge notifier events on its own ports, searching for the ones that
have a MAC address which was previously sent to the control interface.
But this is cumbersome and inefficient. Instead, with one small change,
the bridge could notify of the address deletion from the old port, in a
symmetrical manner with how it did for the insertion. Then the switchdev
driver would not be required to monitor learn/forget events for its own
ports. It could just delete the rule towards the control interface upon
bridge entry migration. This would make hardware address learning be
possible again. Then it would take a few more packets until the hardware
and software FDB would be in sync again.

Signed-off-by: Vladimir Oltean 
---
Changes in v2:
Patch is new.

 net/bridge/br_fdb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/bridge/br_fdb.c 

[PATCH v2 net-next 0/6] Offload software learnt bridge addresses to DSA

[Vladimir Oltean]

This small series tries to make DSA behave a bit more sanely when
bridged with "foreign" (non-DSA) interfaces. When a station A connected
to a DSA switch port needs to talk to another station B connected to a
non-DSA port through the Linux bridge, DSA must explicitly add a route
for station B towards its CPU port. It cannot rely on hardware address
learning for that.

Initial RFC was posted here:
https://www.spinics.net/lists/netdev/msg698169.html

Vladimir Oltean (6):
  net: bridge: notify switchdev of disappearance of old FDB entry upon
migration
  net: dsa: don't use switchdev_notifier_fdb_info in
dsa_switchdev_event_work
  net: dsa: move switchdev event implementation under the same
switch/case statement
  net: dsa: exit early in dsa_slave_switchdev_event if we can't program
the FDB
  net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign
bridge neighbors
  net: dsa: ocelot: request DSA to fix up lack of address learning on
CPU port

 drivers/net/dsa/ocelot/felix.c |   1 +
 include/net/dsa.h  |   5 +
 net/bridge/br_fdb.c|   1 +
 net/dsa/dsa_priv.h |  12 +++
 net/dsa/slave.c| 167 +
 5 files changed, 124 insertions(+), 62 deletions(-)

-- 
2.25.1

Re: [PATCH v2] dt-bindings: leds: Document commonly used LED triggers

[Leizhen (ThunderTown)]

On 2020/12/10 16:24, Manivannan Sadhasivam wrote:
> This commit documents the LED triggers used commonly in the SoCs. Not
> all triggers are documented as some of them are very application specific.
> Most of the triggers documented here are currently used in devicetrees
> of many SoCs.
> 
> While at it, let's also sort the triggers in ascending order.
> 
> Signed-off-by: Manivannan Sadhasivam 
> ---
> 
> Changes in v2:
> 
> * Added more triggers, fixed the regex
> * Sorted triggers in ascending order
> 
>  .../devicetree/bindings/leds/common.yaml  | 78 ++-
>  1 file changed, 60 insertions(+), 18 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.yaml 
> b/Documentation/devicetree/bindings/leds/common.yaml
> index f1211e7045f1..3c2e2208c1da 100644
> --- a/Documentation/devicetree/bindings/leds/common.yaml
> +++ b/Documentation/devicetree/bindings/leds/common.yaml
> @@ -79,24 +79,66 @@ properties:
>the LED.
>  $ref: /schemas/types.yaml#definitions/string
>  
> -enum:
> -# LED will act as a back-light, controlled by the framebuffer system
> -  - backlight
> -# LED will turn on (but for leds-gpio see "default-state" property in
> -# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> -  - default-on
> -# LED "double" flashes at a load average based rate
> -  - heartbeat
> -# LED indicates disk activity
> -  - disk-activity
> -# LED indicates IDE disk activity (deprecated), in new 
> implementations
> -# use "disk-activity"
> -  - ide-disk
> -# LED flashes at a fixed, configurable rate
> -  - timer
> -# LED alters the brightness for the specified duration with one 
> software
> -# timer (requires "led-pattern" property)
> -  - pattern
> +oneOf:
> +  - items:
> +  - enum:
> +# LED indicates mic mute state
> +  - audio-micmute
> +# LED indicates audio mute state
> +  - audio-mute
> +# LED will act as a back-light, controlled by the 
> framebuffer system
> +  - backlight
> +# LED indicates bluetooth power state
> +  - bluetooth-power
> +# LED indicates activity of all CPUs
> +  - cpu
> +# LED will turn on (but for leds-gpio see "default-state" 
> property in
> +# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> +  - default-on
> +# LED indicates disk activity
> +  - disk-activity
> +# LED indicates disk read activity
> +  - disk-read
> +# LED indicates disk write activity
> +  - disk-write
> +# LED indicates camera flash state
> +  - flash
> +# LED "double" flashes at a load average based rate
> +  - heartbeat
> +# LED indicates IDE disk activity (deprecated), in new 
> implementations
> +# use "disk-activity"
> +  - ide-disk
> +# LED indicates MTD memory activity
> +  - mtd
> +# LED indicates NAND memory activity (deprecated),
> +# in new implementations use "mtd"
> +  - nand-disk
> +# No trigger assigned to the LED. This is the default mode
> +# if trigger is absent
> +  - none
> +# LED alters the brightness for the specified duration with 
> one software
> +# timer (requires "led-pattern" property)
> +  - pattern
> +# LED flashes at a fixed, configurable rate
> +  - timer
> +# LED indicates camera torch state
> +  - torch
> +# LED indicates USB gadget activity
> +  - usb-gadget
> +# LED indicates USB host activity
> +  - usb-host
> +  - items:
> +# LED indicates activity of [N]th CPU
> +  - pattern: "^cpu[0-9]{1,2}$"
> +  - items:
> +# LED indicates power status of [N]th Bluetooth HCI device
> +  - pattern: "^hci[0-9]{1,2}-power$"
> +  - items:
> +# LED indicates [N]th MMC storage activity
> +  - pattern: "^mmc[0-9]{1,2}$"
> +  - items:
> +# LED indicates [N]th WLAN Tx activity
> +  - pattern: "^phy[0-9]{1,2}tx$"

Only the last three are not listed:
phy0rx
ir-power-click
ir-user-click

And the first one is easily supported by:
-# LED indicates [N]th WLAN Tx activity
-  - pattern: "^phy[0-9]{1,2}tx$"
+# LED indicates [N]th WLAN Tx/Rx activity
+  - pattern: "^phy[0-9]{1,2}(tx|rx)$"

Tested-by: Zhen Lei 

>  
>led-pattern:
>  description: |
> 

[tip:efi/core 9/12] drivers/firmware/efi/capsule.c:15:10: fatal error: asm/efi.h: No such file or directory

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi/core
head:   54649911f31b6e7c2a79a1426ca98259139e4c35
commit: 4dbe44fb538c59a4adae5abfa9ded2f310250315 [9/12] efi: capsule: clean 
scatter-gather entries from the D-cache
config: ia64-randconfig-r011-20201213 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=4dbe44fb538c59a4adae5abfa9ded2f310250315
git remote add tip 
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
git fetch --no-tags tip efi/core
git checkout 4dbe44fb538c59a4adae5abfa9ded2f310250315
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=ia64 

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

All errors (new ones prefixed by >>):

>> drivers/firmware/efi/capsule.c:15:10: fatal error: asm/efi.h: No such file 
>> or directory
  15 | #include 
 |  ^~~
   compilation terminated.

vim +15 drivers/firmware/efi/capsule.c

 9  
10  #include 
11  #include 
12  #include 
13  #include 
14  #include 
  > 15  #include 
16  #include 
17  

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


.config.gz
Description: application/gzip

[tip:x86/urgent] BUILD SUCCESS 0d07c0ec4381f630c801539c79ad8dcc627f6e4a

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
x86/urgent
branch HEAD: 0d07c0ec4381f630c801539c79ad8dcc627f6e4a  x86/kprobes: Fix 
optprobe to detect INT3 padding correctly

elapsed time: 722m

configs tested: 91
configs skipped: 6

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
armspear6xx_defconfig
arm  iop32x_defconfig
sh  lboxre2_defconfig
arm socfpga_defconfig
arm  moxart_defconfig
arc defconfig
arm s3c6400_defconfig
mips cu1000-neo_defconfig
nios2 10m50_defconfig
pariscgeneric-64bit_defconfig
armmvebu_v5_defconfig
powerpc  bamboo_defconfig
powerpc ppa8548_defconfig
xtensa virt_defconfig
xtensageneric_kc705_defconfig
powerpc  g5_defconfig
m68k   bvme6000_defconfig
xtensa   allyesconfig
arm mv78xx0_defconfig
sh  sh7785lcr_32bit_defconfig
arm  simpad_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a001-20201212
i386 randconfig-a004-20201212
i386 randconfig-a003-20201212
i386 randconfig-a002-20201212
i386 randconfig-a005-20201212
i386 randconfig-a006-20201212
x86_64   randconfig-a016-20201212
x86_64   randconfig-a013-20201212
x86_64   randconfig-a015-20201212
x86_64   randconfig-a014-20201212
x86_64   randconfig-a011-20201212
i386 randconfig-a014-20201212
i386 randconfig-a013-20201212
i386 randconfig-a012-20201212
i386 randconfig-a011-20201212
i386 randconfig-a016-20201212
i386 randconfig-a015-20201212
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

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

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

Re: [PATCH AUTOSEL 5.7 03/30] ima: extend boot_aggregate with kernel measurements

[Mimi Zohar]

On Fri, 2020-12-11 at 09:46 -0800, James Bottomley wrote:
> On Fri, 2020-12-11 at 06:01 -0500, Mimi Zohar wrote:
> > On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:
> > > On 2020-11-29 08:17:38, Mimi Zohar wrote:
> > > > Hi Sasha,
> > > > 
> > > > On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote:
> > > > > On Wed, Jul 08, 2020 at 12:13:13PM -0400, Mimi Zohar wrote:
> > > > > > Hi Sasha,
> > > > > > 
> > > > > > On Wed, 2020-07-08 at 11:40 -0400, Sasha Levin wrote:
> > > > > > > From: Maurizio Drocco 
> > > > > > > 
> > > > > > > [ Upstream commit 20c59ce010f84300f6c655d32db2610d3433f85c
> > > > > > > ]
> > > > > > > 
> > > > > > > Registers 8-9 are used to store measurements of the kernel
> > > > > > > and its command line (e.g., grub2 bootloader with tpm
> > > > > > > module enabled). IMA should include them in the boot
> > > > > > > aggregate. Registers 8-9 should be only included in non-
> > > > > > > SHA1 digests to avoid ambiguity.
> > > > > > 
> > > > > > Prior to Linux 5.8, the SHA1 template data hashes were padded
> > > > > > before being extended into the TPM.  Support for calculating
> > > > > > and extending the per TPM bank template data digests is only
> > > > > > being upstreamed in Linux 5.8.
> > > > > > 
> > > > > > How will attestation servers know whether to include PCRs 8 &
> > > > > > 9 in the the boot_aggregate calculation?  Now, there is a
> > > > > > direct relationship between the template data SHA1 padded
> > > > > > digest not including PCRs 8 & 9, and the new per TPM bank
> > > > > > template data digest including them.
> > > > > 
> > > > > Got it, I'll drop it then, thank you!
> > > > 
> > > > After re-thinking this over, I realized that the attestation
> > > > server can verify the "boot_aggregate" based on the quoted PCRs
> > > > without knowing whether padded SHA1 hashes or per TPM bank hash
> > > > values were extended into the TPM[1], but non-SHA1 boot aggregate
> > > > values [2] should always include PCRs 8 & 9.
> > > 
> > > I'm still not clear on how an attestation server would know to
> > > include PCRs 8 and 9 after this change came through a stable kernel
> > > update. It doesn't seem like something appropriate for stable since
> > > it requires code changes to attestation servers to handle the
> > > change.
> > > 
> > > I know this has already been released in some stable releases, so
> > > I'm too late, but perhaps I'm missing something.
> > 
> > The point of adding PCRs 8 & 9 only to non-SHA1 boot_aggregate values
> > was to avoid affecting existing attestation servers.  The intention
> > was when attestation servers added support for the non-sha1
> > boot_aggregate values, they'd also include PCRs 8 & 9.  The existing
> > SHA1 boot_aggregate value remains PCRs 0 - 7.
> > 
> > To prevent this or something similar from happening again, what
> > should have been the proper way of including PCRs 8 & 9?
> 
> Just to be pragmatic: this is going to happen again.  Shim is already
> measuring the Mok variables through PCR 14, so if we want an accurate
> boot aggregate, we're going to have to include PCR 14 as well (or
> persuade shim to measure through a PCR we're already including, which
> isn't impossible since I think shim should be measuring the Mok
> variables using the EV_EFI_VARIABLE_DRIVER_CONFIG event and, since it
> affects secure boot policy, that does argue it should be measured
> through PCR 7).

Ok.   Going forward, it sounds like we need to define a new
"boot_aggregate" record.  One that contains a version number and PCR
mask.

Mimi

Re: [PATCH v3] driver core: platform: don't oops in platform_shutdown() on unbound devices

[Guenter Roeck]

On Sun, Dec 13, 2020 at 02:55:33AM +0300, Dmitry Baryshkov wrote:
> On shutdown the driver core calls the bus' shutdown callback also for
> unbound devices. A driver's shutdown callback however is only called for
> devices bound to this driver. Commit 9c30921fe799 ("driver core:
> platform: use bus_type functions") changed the platform bus from driver
> callbacks to bus callbacks, so the shutdown function must be prepared to
> be called without a driver. Add the corresponding check in the shutdown
> function.
> 
> Signed-off-by: Dmitry Baryshkov 
> Fixes: 9c30921fe799 ("driver core: platform: use bus_type functions")

Tested-by: Guenter Roeck 

> ---
>  drivers/base/platform.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 0358dc3ea3ad..e9477e0bbca5 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1351,9 +1351,13 @@ static int platform_remove(struct device *_dev)
>  
>  static void platform_shutdown(struct device *_dev)
>  {
> - struct platform_driver *drv = to_platform_driver(_dev->driver);
>   struct platform_device *dev = to_platform_device(_dev);
> + struct platform_driver *drv;
> +
> + if (!_dev->driver)
> + return;
>  
> + drv = to_platform_driver(_dev->driver);
>   if (drv->shutdown)
>   drv->shutdown(dev);
>  }
> -- 
> 2.29.2
> 

Re: [PATCH v9 4/8] IMA: add policy rule to measure critical data

[Tushar Sugandhi]

On 2020-12-12 11:20 a.m., Tyler Hicks wrote:

On 2020-12-12 10:02:47, Tushar Sugandhi wrote:

A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer. The policy rule should ensure the buffer
would get measured only when the policy rule allows the action. The
policy rule should also support the necessary constraints (flags etc.)
for integrity critical buffer data measurements.

Add a policy rule to define the constraints for restricting integrity
critical data measurements.

Signed-off-by: Tushar Sugandhi 


This looks nice. Thanks for the changes!

Reviewed-by: Tyler Hicks 

Tyler


Thanks for the detailed review on this series Tyler.
We really appreciate it.

~Tushar

Re: [PATCH v9 5/8] IMA: limit critical data measurement based on a label

[Tushar Sugandhi]

On 2020-12-12 11:20 a.m., Tyler Hicks wrote:

On 2020-12-12 10:02:48, Tushar Sugandhi wrote:

System administrators should be able to limit which kernel subsystems
they want to measure the critical data for. To enable that, an IMA policy
condition to choose specific kernel subsystems is needed. This policy
condition would constrain the measurement of the critical data based on
a label for the given subsystems.

Add a new IMA policy condition - "data_source:=" to the IMA func
CRITICAL_DATA to allow measurement of various kernel subsystems. This
policy condition would enable the system administrators to restrict the
measurement to the labels listed in "data_source:=".

Limit the measurement to the labels that are specified in the IMA
policy - CRITICAL_DATA+"data_source:=". If "data_sources:=" is not
provided with the func CRITICAL_DATA, the data from all the
supported kernel subsystems is measured.

Signed-off-by: Tushar Sugandhi 


Reviewed-by: Tyler Hicks 

Tyler


Thanks again Tyler.

~Tushar

[PATCH] ASoC: dapm: remove widget from dirty list on free

[Thomas Hebb]

A widget's "dirty" list_head, much like its "list" list_head, eventually
chains back to a list_head on the snd_soc_card itself. This means that
the list can stick around even after the widget (or all widgets) have
been freed. Currently, however, widgets that are in the dirty list when
freed remain there, corrupting the entire list and leading to memory
errors and undefined behavior when the list is next accessed or
modified.

I encountered this issue when a component failed to probe relatively
late in snd_soc_bind_card(), causing it to bail out and call
soc_cleanup_card_resources(), which eventually called
snd_soc_dapm_free() with widgets that were still dirty from when they'd
been added.

Fixes: db432b414e20 ("ASoC: Do DAPM power checks only for widgets changed since 
last run")
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Hebb 
---

 sound/soc/soc-dapm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 7f87b449f950..148c095df27b 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -2486,6 +2486,7 @@ void snd_soc_dapm_free_widget(struct snd_soc_dapm_widget 
*w)
enum snd_soc_dapm_direction dir;
 
list_del(>list);
+   list_del(>dirty);
/*
 * remove source and sink paths associated to this widget.
 * While removing the path, remove reference to it from both
-- 
2.29.2

Re: [PATCH net-next] net: x25: Remove unimplemented X.25-over-LLC code stubs

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Tue,  8 Dec 2020 19:33:46 -0800 you wrote:
> According to the X.25 documentation, there was a plan to implement
> X.25-over-802.2-LLC. It never finished but left various code stubs in the
> X.25 code. At this time it is unlikely that it would ever finish so it
> may be better to remove those code stubs.
> 
> Also change the documentation to make it clear that this is not a ongoing
> plan anymore. Change words like "will" to "could", "would", etc.
> 
> [...]

Here is the summary with links:
  - [net-next] net: x25: Remove unimplemented X.25-over-LLC code stubs
https://git.kernel.org/netdev/net-next/c/13458ffe0a95

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH v2, 04/17] drm/mediatek: add component OVL_2L2

[Chun-Kuang Hu]

Hi, Yongqiang:

Yongqiang Niu  於 2020年12月12日 週六 下午12:12寫道：
>
> This patch add component OVL_2L2

Break drm part and soc part into different patches.

Regards,
Chun-Kuang.

>
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
>  include/linux/soc/mediatek/mtk-mmsys.h  | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 8eba44b..8938554 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -403,6 +403,7 @@ struct mtk_ddp_comp_match {
> [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL,   1, NULL },
> [DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, NULL },
> [DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, NULL },
> +   [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, NULL },
> [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM,   0, NULL },
> [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM,   1, NULL },
> [DDP_COMPONENT_PWM2]= { MTK_DISP_PWM,   2, NULL },
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 4b6c514..42476c2 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -29,6 +29,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL_2L0,
> DDP_COMPONENT_OVL_2L1,
> +   DDP_COMPONENT_OVL_2L2,
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH] thermal/core: Make 'forced_passive' as obsolete candidate

[Matthew Garrett]

On Sun, Dec 13, 2020 at 12:39:26AM +0100, Daniel Lezcano wrote:
> On 12/12/2020 21:08, Matthew Garrett wrote:
> > Anything that provides a trip point that has no active notifications and
> > doesn't provide any information that tells the kernel to poll it.
> 
> I'm not able to create a setup as you describe working correctly with
> the forced passive trip point.
> 
> The forced passive trip can not be detected as there is no comparison
> with the defined temperature in the thermal_zone_device_update() function.

The logic seems to be in the step_wise thermal governor. I'm not sure
why it would be used in thermal_zone_device_update() - the entire point
is that we don't get updates from the device?
 
> If my analysis is correct, this 'feature' is broken since years, more
> than 8 years to be exact and nobody complained.

I've no problem with it being removed if there are no users, but in that
case the justification should be rewritten - ACPI table updates aren't a
complete replacement for the functionality offered (and can't be used if
the lockdown LSM is being used in any case).

APPLY FOR LOAN AND FUNDING

[GLOBAL SERVIEC FINANCE]

Apply for Loan, Investment Funding or Project/Contract Funding .We finance 
contracts, Projects, Business and Companies. We also deal on 24karat Gold with 
99.9% purity.
We issue loans at 2% interest rate within duration of 10 - 20years.Funding 
occurs within 2 to 3 working days after documentation is completed.
visit our website @: https://globalserviecfinance.ltd

Send us the following details via our email(supp...@globalserviecfinance.ltd) 
or Whatsapp  447393128740  if you are Interested :

Full Name:
Email:..
Phone no:...
Address:.
Occupation:...
Whatsapp no:..

Regards.
Marketing Team
Email: supp...@globalserviecfinance.ltd
Website: https://globalserviecfinance.ltd
WhatsApp No:  (  447393128740)

Re: [PATCH] lib/find_bit_bench: fix the unmatched iterations cnt

[Yun Levi]

> Can you please welcome those people to join the discussion? What exactly
> confuses them? What is their usecase? Will they be satisfied if we add
> the comment pointing that we count _iterations_, not number of bits?

> Again, we count iterations, not the number of set bits. If you are able to
> demonstrate that this test counts iterations wrongly, I'll happily
> accept the fix.

What I want to ask people is that question
is it much better to have the same iteration on the same bitmap
regardless of the find_next_bit and find_last_bit.
At my first thought the benchmark is much easier to be compared if
they have the same iteration count
regardless of situation.
What I mentioned as "confused" is people think one more time when
unmatched iteration happens,
(divide time by iteration for getting a benchmark..)
I don't point out the iteration is wrong but ask if it is much better
to have the same iteration count on the
same bitmap regardless of find_next_bit and find_last_bit to be compared easier.

> This change adds useless check against overflow on each iteration.
> Except that, nothing is changed. We don't need this change, right?

it is coming from my misunderstanding it should count the number of bits.
You're right it adds useless checks thank you.

Thanks.
Levi.







On Sun, Dec 13, 2020 at 3:56 AM Yury Norov  wrote:
>
> On Fri, Dec 11, 2020 at 4:09 PM Yun Levi  wrote:
> >
> > > I didn't understand why is so (I mean "same", I think you rather talking 
> > > about
> > > same order of amount of itterations).
> >
> > Yes. That's what I want to talk about. Thanks!
> >
> > > Can you provide before and after to compare?
> >
> > I tested when the bitmap's 0 bit is set only. and below are before and
> > after results.
> >
> > before:
> >   Start testing find_bit() with random-filled bitmap
> > [  +0.000481] find_next_bit:8966 ns,  2 iterations
> > [  +0.001739] find_next_zero_bit:1726335 ns, 327679 iterations
> > [  +0.20] find_last_bit:7428 ns,  1 iterations
> > [  +0.17] find_first_bit:   5523 ns,  2 iterations
> > [  +0.22] find_next_and_bit:9643 ns,  1 iterations
> > [  +0.07]
> >   Start testing find_bit() with sparse bitmap
> > [  +0.41] find_next_bit:   16343 ns,656 iterations
> > [  +0.001943] find_next_zero_bit:1928324 ns, 327025 iterations
> > [  +0.29] find_last_bit:   14398 ns,656 iterations
> > [  +0.000725] find_first_bit: 711383 ns,656 iterations
> > [  +0.22] find_next_and_bit:9581 ns,  1 iterations
> >
> > after:
> > [Dec12 08:25]
> >   Start testing find_bit() with random-filled bitmap
> > [  +0.000687] find_next_bit:   11079 ns,  1 iterations
> > [  +0.002156] find_next_zero_bit:2055752 ns, 327679 iterations
> > [  +0.22] find_last_bit:8052 ns,  1 iterations
> > [  +0.20] find_first_bit:   6270 ns,  1 iterations
> > [  +0.24] find_next_and_bit:9519 ns,  0 iterations
> > [  +0.07]
> >   Start testing find_bit() with sparse bitmap
> > [  +0.47] find_next_bit:   18389 ns,655 iterations
> > [  +0.001807] find_next_zero_bit:1793314 ns, 327025 iterations
> > [  +0.27] find_last_bit:   13600 ns,655 iterations
> > [  +0.000604] find_first_bit: 591173 ns,655 iterations
> > [  +0.23] find_next_and_bit:9392 ns,  0 iterations
>
> > find_next_and_bit:9392 ns,  0 iterations
>
> This is definitely wrong. The test simply says that it has parsed the bitmap
> without actually parsing it. Bollocks.
>
> > >I think it's not that important, because the difference is not measurable.
> > > But if this part raises questions, I have nothing against aligning 
> > > numbers.
> > Right it's not that important, But if the amount of iteration value is
> > not same to the same bitmap,
> > makes people confused when they run the test cases. so I just fix.
>
> Can you please welcome those people to join the discussion? What exactly
> confuses them? What is their usecase? Will they be satisfied if we add
> the comment pointing that we count _iterations_, not number of bits?
>
> > > What for this check against ++cnt? I doubt that the counter can overflow.
> > This test case suppose the bitmap size is 327680 (4096UL * 8 * 10)
> > So I think there is no case that the counter can overflow in the testcase.
> >
> > >> time = ktime_get() - time;
> > >> pr_err("find_first_bit: %18llu ns, %6ld\n", time, cnt);
> > > Why this?
> > Sorry, I don't catch what you are saying.
> > Could you tell me in detail?
>
> This change adds useless check against overflow on each iteration.
> Except that, nothing is changed. We don't need 

Re: [PATCH] power: supply: Fix a typo in warning message

[Sebastian Reichel]

Hi,

On Sat, Dec 05, 2020 at 10:25:32AM +0900, Masanari Iida wrote:
> This patch fix a warning messages in power_supply_sysfs.c
> 
> Signed-off-by: Masanari Iida 
> ---

Thanks, queued.

-- Sebastian

>  drivers/power/supply/power_supply_sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/supply/power_supply_sysfs.c 
> b/drivers/power/supply/power_supply_sysfs.c
> index a616b9d8f43c..92dd63171193 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -402,7 +402,7 @@ void power_supply_init_attrs(struct device_type *dev_type)
>   struct device_attribute *attr;
>  
>   if (!power_supply_attrs[i].prop_name) {
> - pr_warn("%s: Property %d skipped because is is missing 
> from power_supply_attrs\n",
> + pr_warn("%s: Property %d skipped because it is missing 
> from power_supply_attrs\n",
>   __func__, i);
>   sprintf(power_supply_attrs[i].attr_name, "_err_%d", i);
>   } else {
> -- 
> 2.25.0
> 


signature.asc
Description: PGP signature

[PATCH v3] driver core: platform: don't oops in platform_shutdown() on unbound devices

[Dmitry Baryshkov]

On shutdown the driver core calls the bus' shutdown callback also for
unbound devices. A driver's shutdown callback however is only called for
devices bound to this driver. Commit 9c30921fe799 ("driver core:
platform: use bus_type functions") changed the platform bus from driver
callbacks to bus callbacks, so the shutdown function must be prepared to
be called without a driver. Add the corresponding check in the shutdown
function.

Signed-off-by: Dmitry Baryshkov 
Fixes: 9c30921fe799 ("driver core: platform: use bus_type functions")
---
 drivers/base/platform.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 0358dc3ea3ad..e9477e0bbca5 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1351,9 +1351,13 @@ static int platform_remove(struct device *_dev)
 
 static void platform_shutdown(struct device *_dev)
 {
-   struct platform_driver *drv = to_platform_driver(_dev->driver);
struct platform_device *dev = to_platform_device(_dev);
+   struct platform_driver *drv;
+
+   if (!_dev->driver)
+   return;
 
+   drv = to_platform_driver(_dev->driver);
if (drv->shutdown)
drv->shutdown(dev);
 }
-- 
2.29.2

Re: [PATCH v5 2/3] Documentation: DT: binding documentation for regulator-poweroff

[Sebastian Reichel]

Hi,

On Fri, Dec 11, 2020 at 04:14:44PM +0100, Michael Klein wrote:
> Add devicetree binding documentation for regulator-poweroff driver.
> 
> Signed-off-by: Michael Klein 
> ---

Thanks, queued.

-- Sebastian

>  .../power/reset/regulator-poweroff.yaml   | 37 +++
>  1 file changed, 37 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml 
> b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml
> new file mode 100644
> index ..03bd1fa5a623
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/reset/regulator-poweroff.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Force-disable power regulator to turn the power off.
> +
> +maintainers:
> +  - Michael Klein 
> +
> +description: |
> +  When the power-off handler is called, a power regulator is disabled by
> +  calling regulator_force_disable(). If the power is still on and the
> +  CPU still running after a 3000ms delay, a warning is emitted.
> +
> +properties:
> +  compatible:
> +const: "regulator-poweroff"
> +
> +  cpu-supply:
> +description:
> +  regulator to disable on power-down
> +
> +required:
> +  - compatible
> +  - cpu-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +regulator-poweroff {
> +compatible = "regulator-poweroff";
> +cpu-supply = <_vcc1v2>;
> +};
> +...
> -- 
> 2.29.2
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


signature.asc
Description: PGP signature

Re: [PATCH v5 1/3] power: reset: new driver regulator-poweroff

[Sebastian Reichel]

Hi,

On Fri, Dec 11, 2020 at 04:14:43PM +0100, Michael Klein wrote:
> This driver registers a pm_power_off function to turn off the board
> by force-disabling a devicetree-defined regulator.
> 
> Signed-off-by: Michael Klein 
> ---

Thanks, queued.

-- Sebastian

>  drivers/power/reset/Kconfig  |  7 ++
>  drivers/power/reset/Makefile |  1 +
>  drivers/power/reset/regulator-poweroff.c | 82 
>  3 files changed, 90 insertions(+)
>  create mode 100644 drivers/power/reset/regulator-poweroff.c
> 
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index d55b3727e00e..b22c4fdb2561 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -177,6 +177,13 @@ config POWER_RESET_QNAP
>  
> Say Y if you have a QNAP NAS.
>  
> +config POWER_RESET_REGULATOR
> + bool "Regulator subsystem power-off driver"
> + depends on OF && REGULATOR
> + help
> +   This driver supports turning off your board by disabling a
> +   power regulator defined in the devicetree.
> +
>  config POWER_RESET_RESTART
>   bool "Restart power-off driver"
>   help
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index c51eceba9ea3..9dc49d3a57ff 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_POWER_RESET_OCELOT_RESET) += ocelot-reset.o
>  obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
>  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
> +obj-$(CONFIG_POWER_RESET_REGULATOR) += regulator-poweroff.o
>  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
>  obj-$(CONFIG_POWER_RESET_ST) += st-poweroff.o
>  obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
> diff --git a/drivers/power/reset/regulator-poweroff.c 
> b/drivers/power/reset/regulator-poweroff.c
> new file mode 100644
> index ..f697088e0ad1
> --- /dev/null
> +++ b/drivers/power/reset/regulator-poweroff.c
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Force-disables a regulator to power down a device
> + *
> + * Michael Klein 
> + *
> + * Copyright (C) 2020 Michael Klein
> + *
> + * Based on the gpio-poweroff driver.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TIMEOUT_MS 3000
> +
> +/*
> + * Hold configuration here, cannot be more than one instance of the driver
> + * since pm_power_off itself is global.
> + */
> +static struct regulator *cpu_regulator;
> +
> +static void regulator_poweroff_do_poweroff(void)
> +{
> + if (cpu_regulator && regulator_is_enabled(cpu_regulator))
> + regulator_force_disable(cpu_regulator);
> +
> + /* give it some time */
> + mdelay(TIMEOUT_MS);
> +
> + WARN_ON(1);
> +}
> +
> +static int regulator_poweroff_probe(struct platform_device *pdev)
> +{
> + /* If a pm_power_off function has already been added, leave it alone */
> + if (pm_power_off != NULL) {
> + dev_err(>dev,
> + "%s: pm_power_off function already registered\n",
> + __func__);
> + return -EBUSY;
> + }
> +
> + cpu_regulator = devm_regulator_get(>dev, "cpu");
> + if (IS_ERR(cpu_regulator))
> + return PTR_ERR(cpu_regulator);
> +
> + pm_power_off = _poweroff_do_poweroff;
> + return 0;
> +}
> +
> +static int regulator_poweroff_remove(__maybe_unused struct platform_device 
> *pdev)
> +{
> + if (pm_power_off == _poweroff_do_poweroff)
> + pm_power_off = NULL;
> +
> + return 0;
> +}
> +
> +static const struct of_device_id of_regulator_poweroff_match[] = {
> + { .compatible = "regulator-poweroff", },
> + {},
> +};
> +
> +static struct platform_driver regulator_poweroff_driver = {
> + .probe = regulator_poweroff_probe,
> + .remove = regulator_poweroff_remove,
> + .driver = {
> + .name = "poweroff-regulator",
> + .of_match_table = of_regulator_poweroff_match,
> + },
> +};
> +
> +module_platform_driver(regulator_poweroff_driver);
> +
> +MODULE_AUTHOR("Michael Klein ");
> +MODULE_DESCRIPTION("Regulator poweroff driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:poweroff-regulator");
> -- 
> 2.29.2
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


signature.asc
Description: PGP signature

Re: [PATCH] thermal/core: Make 'forced_passive' as obsolete candidate

[Daniel Lezcano]

On 12/12/2020 21:08, Matthew Garrett wrote:
> On Sat, Dec 12, 2020 at 10:11:31AM +0100, Daniel Lezcano wrote:
>> On 12/12/2020 04:50, Matthew Garrett wrote:
>>> Yes - what's the reason to do so?
>>
>> I'm cleaning up the thermal core code, so questioning every old ABI.
>>
>>> The code isn't specific to ACPI,
>>> so being able to override ACPI tables doesn't seem to justify it.
>>
>> I agree, the code is no specific to ACPI.
>>
>> What non-ACPI architecture, without device tree or platform data would
>> need the 'passive' option today ?
> 
> Anything that provides a trip point that has no active notifications and
> doesn't provide any information that tells the kernel to poll it.

I'm not able to create a setup as you describe working correctly with
the forced passive trip point.

The forced passive trip can not be detected as there is no comparison
with the defined temperature in the thermal_zone_device_update() function.

The commit 0c01ebbfd3caf1 may be responsible of this.

If my analysis is correct, this 'feature' is broken since years, more
than 8 years to be exact and nobody complained.

If I'm right, we can remove this feature directly.


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v4] net/ipv4/inet_fragment: Batch fqdir destroy works

[Jakub Kicinski]

On Fri, 11 Dec 2020 15:36:53 +0100 Eric Dumazet wrote:
> On Fri, Dec 11, 2020 at 12:24 PM SeongJae Park  wrote:
> > From: SeongJae Park 
> >
> > On a few of our systems, I found frequent 'unshare(CLONE_NEWNET)' calls
> > make the number of active slab objects including 'sock_inode_cache' type
> > rapidly and continuously increase.  As a result, memory pressure occurs.
> 
> Reviewed-by: Eric Dumazet 
> 
> Jakub or David might change the patch title, no need to resend.

"inet: frags: batch fqdir destroy works" it is.

Applied, thanks!

Re: [PATCH] net: bcmgenet: Fix a resource leak in an error handling path in the probe functin

[Florian Fainelli]

On 12/12/2020 10:20 AM, Christophe JAILLET wrote:
> If the 'register_netdev()' call fails, we must undo a previous
> 'bcmgenet_mii_init()' call.
> 
> Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")> Signed-off-by: 
> Christophe JAILLET 

Acked-by: Florian Fainelli 

> ---
> The missing 'bcmgenet_mii_exit()' call is added here, instead of in the
> error handling path in order to avoid some goto spaghetti code.

Yes that makes sense, thanks!
-- 
Florian

Re: [PATCH] nfc: s3fwrn5: let core configure the interrupt trigger

[Jakub Kicinski]

On Thu, 10 Dec 2020 22:18:24 +0100 Krzysztof Kozlowski wrote:
> If interrupt trigger is not set when requesting the interrupt, the core
> will take care of reading trigger type from Devicetree.  There is no
> point to do it in the driver.
> 
> Signed-off-by: Krzysztof Kozlowski 

Applied, thank you!

Re: [PATCH v2] driver core: platform: don't oops in platform_shutdown() on unbound devices

[Uwe Kleine-König]

Hello Dmitry,

On Sun, Dec 13, 2020 at 12:38:32AM +0300, Dmitry Baryshkov wrote:
> Platform code stopped checking if the device is bound to the actual
> platform driver, thus calling non-existing drv->shutdown(). Verify that
> _dev->driver is not NULL before calling shutdown callback.

I'd write:

On shutdown the driver core calls the bus' shutdown callback also for
unbound devices. A driver's shutdown callback however is only called for
devices bound to this driver. Commit 9c30921fe799 ("driver core:
platform: use bus_type functions") changed the platform bus from driver
callbacks to bus callbacks, so the shutdown function must be prepared to
be called without a driver. Add the corresponding check in the
shutdown function.

With that adding the backtrace isn't necessary (and the patch is fine).

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] dt-bindings: regulator: add pf8x00 PMIC

[Adrien Grassein]

Hello,

Le ven. 11 déc. 2020 à 15:04, Mark Brown  a écrit :
>
> On Thu, Dec 10, 2020 at 11:16:28PM +0100, Adrien Grassein wrote:
> > Add a devicetree binding documentation for the pf8x00 regulator driver.
>
> Please don't send new patches in reply to old threads, it makes it hard
> to keep track of what is going on.

Sorry. Should I create a new mail each time I send a new version of the patch?

>
> > +  regulator-name:
> > +pattern: "^ldo[1-4]$"
> > +description:
> > +  should be ldo1", ..., "ldo4"
>
> This is part of the generic regulator binding and since it's for board
> specific usage it should not be constrained by the chip binding.

Ok.
>
> > +  nxp,vselect-en:
> > +$ref: /schemas/types.yaml#definitions/flag
> > +description:
> > +  Only available for ldo2. When specified, use the VSELECT
> > +  input pin of the chip to control the output voltage of the
> > +  ldo02 regulator. (3.3V if VSELECT is LOW, 1.8V if HIGH).
>
> How is VSELECT used without a binding specifying some mechanism for
> control?

I think that VSELECT input should be controlled by the sub system that
uses it (via maybe a GPIO).
On my board, it's directly controlled by another chip (so without a GPIO).

>
> > +  nxp,ilim-microamp:
> > +$ref: /schemas/types.yaml#definitions/uint32
> > +minimum: 2100
> > +maximum: 4500
> > +default: 2100
> > +enum: [ 2100, 2600, 3000, 4500 ]
> > +description:
> > +  Defines the maximum current delivered by the regulator in 
> > microamp.
>
> Instead of implementing a custom property this should use the already
> existing properties for current limits, this is a common thing for
> hardware to have so we shouldn't have custom bindings.  We'll need to
> relax the check the code currently has for a non-zero minimum limit but
> otherwise everything should already be there.

Ok I now use "regulator-max-microamp" property from the regulator that
acts like my property.
I was wrong with the default value. I re-read the documentation and
the default value is stored in OTP
memory. So if someone skipped this property, it's OK to not send any value.


Thanks again,
Regards,

WARNING in yurex_write/usb_submit_urb

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:a256e240 usb: phy: convert comma to semicolon
git tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=14c2cef350
kernel config:  https://syzkaller.appspot.com/x/.config?x=e267dbb5fea6c8b3
dashboard link: https://syzkaller.appspot.com/bug?extid=e87ebe0f7913f71f2ea5
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e87ebe0f7913f71f2...@syzkaller.appspotmail.com

[ cut here ]
URB dfe6f349 submitted while active
WARNING: CPU: 1 PID: 25254 at drivers/usb/core/urb.c:378 
usb_submit_urb+0x1228/0x14e0 drivers/usb/core/urb.c:378
Modules linked in:
CPU: 1 PID: 25254 Comm: syz-executor.0 Not tainted 5.10.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:usb_submit_urb+0x1228/0x14e0 drivers/usb/core/urb.c:378
Code: 89 de e8 8b 24 bd fd 84 db 0f 85 da f4 ff ff e8 2e 2c bd fd 4c 89 fe 48 
c7 c7 c0 63 41 86 c6 05 33 ea b0 04 01 e8 63 2d f3 01 <0f> 0b e9 b8 f4 ff ff c7 
44 24 14 01 00 00 00 e9 6f f5 ff ff 41 bd
RSP: 0018:c900129e7cb8 EFLAGS: 00010282
RAX:  RBX:  RCX: 
RDX: 0004 RSI: 8128f483 RDI: f5200253cf89
RBP: 19200253cfa9 R08: 0001 R09: 8881f6b1ff5b
R10:  R11:  R12: 888101ccbc00
R13: fff0 R14: 888101ccbce8 R15: 8881050ce400
FS:  7f9fd94dd700() GS:8881f6b0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2740 CR3: 0001135b7000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 yurex_write+0x3f4/0x840 drivers/usb/misc/yurex.c:494
 vfs_write+0x28e/0x9e0 fs/read_write.c:603
 ksys_write+0x12d/0x250 fs/read_write.c:658
 do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45e159
Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f9fd94dcc68 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 0003 RCX: 0045e159
RDX: 0001 RSI: 2740 RDI: 0003
RBP: 0119bfc0 R08:  R09: 
R10:  R11: 0246 R12: 0119bf8c
R13: 7ffc06103bcf R14: 7f9fd94dd9c0 R15: 0119bf8c


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[PATCH] drm/rockchip: dsi: remove extra component_del() call

[Thomas Hebb]

commit cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support") added
this devcnt field and call to component_del(). However, these both
appear to be erroneous changes left over from an earlier version of the
patch. In the version merged, nothing ever modifies devcnt, meaning
component_del() runs unconditionally and in addition to the
component_del() calls in dw_mipi_dsi_rockchip_host_detach(). The second
call fails to delete anything and produces a warning in dmesg.

If we look at the previous version of the patch[1], however, we see that
it had logic to calculate devcnt and call component_add() in certain
situations. This was removed in v6, and the fact that the deletion code
was not appears to have been an oversight.

[1] 
https://patchwork.kernel.org/project/dri-devel/patch/20180821140515.22246-8-he...@sntech.de/

Fixes: cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support")
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Hebb 
---

 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 542dcf7eddd6..ce044db8c97e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -243,7 +243,6 @@ struct dw_mipi_dsi_rockchip {
struct dw_mipi_dsi *dmd;
const struct rockchip_dw_dsi_chip_data *cdata;
struct dw_mipi_dsi_plat_data pdata;
-   int devcnt;
 };
 
 struct dphy_pll_parameter_map {
@@ -1121,9 +1120,6 @@ static int dw_mipi_dsi_rockchip_remove(struct 
platform_device *pdev)
 {
struct dw_mipi_dsi_rockchip *dsi = platform_get_drvdata(pdev);
 
-   if (dsi->devcnt == 0)
-   component_del(dsi->dev, _mipi_dsi_rockchip_ops);
-
dw_mipi_dsi_remove(dsi->dmd);
 
return 0;
-- 
2.29.2

arch/sh/kernel/dwarf.c:411:24: sparse: sparse: incorrect type in argument 1 (different address spaces)

[kernel test robot]

Hi Luc,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   7b1b868e1d9156484ccce9bf11122c053de82617
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for 
__chk_{user,io}_ptr()
date:   4 months ago
config: sh-randconfig-s032-20201213 (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-179-ga00755aa-dirty
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5fc436f06eef54ef512ea55a9db8eb9f2e76959
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e5fc436f06eef54ef512ea55a9db8eb9f2e76959
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sh 

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


"sparse warnings: (new ones prefixed by >>)"
   arch/sh/kernel/dwarf.c:248:17: sparse: sparse: incorrect type in argument 1 
(different address spaces) @@ expected void const volatile [noderef] 
__iomem *ptr @@ got unsigned long *val @@
   arch/sh/kernel/dwarf.c:248:17: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:248:17: sparse: got unsigned long *val
   arch/sh/kernel/dwarf.c:347:18: sparse: sparse: symbol 'dwarf_lookup_fde' was 
not declared. Should it be static?
>> arch/sh/kernel/dwarf.c:411:24: sparse: sparse: incorrect type in argument 1 
>> (different address spaces) @@ expected void const volatile [noderef] 
>> __iomem *ptr @@ got unsigned char * @@
   arch/sh/kernel/dwarf.c:411:24: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:411:24: sparse: got unsigned char *
>> arch/sh/kernel/dwarf.c:676:38: sparse: sparse: incorrect type in argument 1 
>> (different base types) @@ expected void const volatile [noderef] __iomem 
>> *ptr @@ got unsigned long [assigned] addr @@
   arch/sh/kernel/dwarf.c:676:38: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:676:38: sparse: got unsigned long [assigned] addr
   arch/sh/kernel/dwarf.c:708:30: sparse: sparse: incorrect type in argument 1 
(different base types) @@ expected void const volatile [noderef] __iomem 
*ptr @@ got unsigned long [assigned] addr @@
   arch/sh/kernel/dwarf.c:708:30: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:708:30: sparse: got unsigned long [assigned] addr
   arch/sh/kernel/dwarf.c:775:43: sparse: sparse: incorrect type in argument 1 
(different address spaces) @@ expected void const volatile [noderef] 
__iomem *ptr @@ got void *[assigned] p @@
   arch/sh/kernel/dwarf.c:775:43: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:775:43: sparse: got void *[assigned] p
>> arch/sh/kernel/dwarf.c:156:24: sparse: sparse: incorrect type in argument 1 
>> (different address spaces) @@ expected void const volatile [noderef] 
>> __iomem *ptr @@ got char *addr @@
   arch/sh/kernel/dwarf.c:156:24: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:156:24: sparse: got char *addr
>> arch/sh/kernel/dwarf.c:156:24: sparse: sparse: incorrect type in argument 1 
>> (different address spaces) @@ expected void const volatile [noderef] 
>> __iomem *ptr @@ got char *addr @@
   arch/sh/kernel/dwarf.c:156:24: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:156:24: sparse: got char *addr
>> arch/sh/kernel/dwarf.c:156:24: sparse: sparse: incorrect type in argument 1 
>> (different address spaces) @@ expected void const volatile [noderef] 
>> __iomem *ptr @@ got char *addr @@
   arch/sh/kernel/dwarf.c:156:24: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:156:24: sparse: got char *addr
>> arch/sh/kernel/dwarf.c:156:24: sparse: sparse: incorrect type in argument 1 
>> (different address spaces) @@ expected void const volatile [noderef] 
>> __iomem *ptr @@ got char *addr @@
   arch/sh/kernel/dwarf.c:156:24: sparse: expected void const volatile 
[noderef] __iomem *ptr
   arch/sh/kernel/dwarf.c:156:24: sparse: got char *addr
>> arch/sh/kernel/dwarf.c:156:24: sparse: sparse: incorrect type in argument 1 
>> (different address spaces) @@ expected void const volatile [noderef] 
>> __iomem *ptr @@ got char *addr @@
   arch/sh/kernel/dwarf.c:156:24: sparse: expected void const volatile 

Re: [PATCH 1/1] net: Fix use of proc_fs

[Jakub Kicinski]

On Sat, 12 Dec 2020 23:39:20 +0200 Yonatan Linik wrote:
> On Sat, Dec 12, 2020 at 9:48 PM Jakub Kicinski  wrote:
> >
> > On Fri, 11 Dec 2020 18:37:49 +0200 Yonatan Linik wrote:  
> > > proc_fs was used, in af_packet, without a surrounding #ifdef,
> > > although there is no hard dependency on proc_fs.
> > > That caused the initialization of the af_packet module to fail
> > > when CONFIG_PROC_FS=n.
> > >
> > > Specifically, proc_create_net() was used in af_packet.c,
> > > and when it fails, packet_net_init() returns -ENOMEM.
> > > It will always fail when the kernel is compiled without proc_fs,
> > > because, proc_create_net() for example always returns NULL.
> > >
> > > The calling order that starts in af_packet.c is as follows:
> > > packet_init()
> > > register_pernet_subsys()
> > > register_pernet_operations()
> > > __register_pernet_operations()
> > > ops_init()
> > > ops->init() (packet_net_ops.init=packet_net_init())
> > > proc_create_net()
> > >
> > > It worked in the past because register_pernet_subsys()'s return value
> > > wasn't checked before this Commit 36096f2f4fa0 ("packet: Fix error path in
> > > packet_init.").
> > > It always returned an error, but was not checked before, so everything
> > > was working even when CONFIG_PROC_FS=n.
> > >
> > > The fix here is simply to add the necessary #ifdef.
> > >
> > > Signed-off-by: Yonatan Linik   
> >
> > Hm, I'm guessing you hit this on a kernel upgrade of a real system?  
> 
> Yeah, suddenly using socket with AF_PACKET didn't work,
> so I checked what happened.
> 
> > It seems like all callers to proc_create_net (and friends) interpret
> > NULL as an error, but only handful is protected by an ifdef.  
> 
> I guess where there is no ifdef,
> there should be a hard dependency on procfs,
> using depends on in the Kconfig.
> Maybe that's not the case everywhere it should be.

You're right, on a closer look most of the places have a larger #ifdef
block (which my grep didn't catch) or are under Kconfig. Of those I
checked only TLS looks wrong (good job me) - would you care to fix that
one as well, or should I?

> > I checked a few and none of them cares about the proc_dir_entry pointer
> > that gets returned. Should we perhaps rework the return values of the
> > function so that we can return success if !CONFIG_PROC_FS without
> > having to yield a pointer?  
> 
> Sometimes the pointer returned is used,
> for example in drivers/acpi/button.c.
> Are you suggesting returning a bool while
> having the pointer as an out parameter?
> Because that would still be problematic where the pointer is used.

Ack, I was only thinking of changing proc_create_net* but as you
rightly pointed out most callers already deal with the problem, 
so maybe it's not worth refactoring.

> > Obviously we can apply this fix so we can backport to 5.4 if you need
> > it. I think the ifdef is fine, since it's what other callers have.
> 
> It would be great to apply this where the problem exists,
> I believe this applies to other versions as well.

Will do. Linus is likely to cut the final 5.11 release on Sunday, so
it needs to wait until next week for process reasons but it won't get
lost. For the record:

Fixes: 36096f2f4fa0 ("packet: Fix error path in packet_init")

RE: [PATCH 3/3] kbuild: rewrite ld-version.sh in shell script

[David Laight]

From: Masahiro Yamada
> Sent: 12 December 2020 16:55
> 
> This script was written in awk in spite of the file extension '.sh'.
> Rewrite it as a shell script.
...
> +#
> +# Usage: $ ./scripts/ld-version.sh ld
> +#
> +# Print the linker version of `ld' in a 5 or 6-digit form
> +# such as `23501' for GNU ld 2.35.1 etc.
> +
> +first_line="$($* --version | head -n 1)"
> +
> +if ! ( echo $first_line | grep -q "GNU ld"); then
> + echo 0
> + exit 1
> +fi
> +
> +# Distributions may append an extra string like 2.35-15.fc33
> +# Take the part that consists of numbers and dots.
> +VERSION=$(echo $first_line | sed 's/.* \([^ ]*\)$/\1/' | sed 
> 's/^\(^[0-9.]*\).*/\1/')
> +MAJOR=$(echo $VERSION | cut -d . -f 1)
> +MINOR=$(echo $VERSION | cut -d . -f 2)
> +PATCHLEVEL=$(echo $VERSION | cut -d . -f 3)
> +printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL


H.
You've managed to convert an awk script into something that requires
sh, head, grep, sed (twice), and cut (thrice).
Plus (probably) a few sub-shells.

It is quite ease to do it all in all in the shell.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH 3/3] kbuild: rewrite ld-version.sh in shell script

[kernel test robot]

Hi Masahiro,

I love your patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on kbuild/for-next arm64/for-next/core linus/master 
v5.10-rc7 next-20201211]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Masahiro-Yamada/kbuild-do-not-use-scripts-ld-version-sh-for-checking-spatch-version/20201213-010621
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-amigaone_defconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/0eab60f5e1f804528a4d0dd9566cb30f62242d22
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Masahiro-Yamada/kbuild-do-not-use-scripts-ld-version-sh-for-checking-spatch-version/20201213-010621
git checkout 0eab60f5e1f804528a4d0dd9566cb30f62242d22
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

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

All errors (new ones prefixed by >>):

   /bin/sh: 1: [: -ge: unexpected operator
>> /bin/sh: 1: [: -lt: unexpected operator

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


.config.gz
Description: application/gzip

Re: [PATCH] net: qlcnic: remove casting dma_alloc_coherent

[Jakub Kicinski]

On Fri, 11 Dec 2020 08:59:20 + Xu Wang wrote:
> Remove casting the values returned by dma_alloc_coherent.
> 
> Signed-off-by: Xu Wang 

This patch does not apply to net-next, please rebase against:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/

if you want it to be applied to the networking tree.

[PATCH v2] driver core: platform: don't oops in platform_shutdown() on unbound devices

[Dmitry Baryshkov]

Platform code stopped checking if the device is bound to the actual
platform driver, thus calling non-existing drv->shutdown(). Verify that
_dev->driver is not NULL before calling shutdown callback.

[   57.832972] platform 3d6a000.gmu: shutdown
[   57.837778] Unable to handle kernel paging request at virtual address 
ffe8
[   57.846391] Mem abort info:
[   57.849704]   ESR = 0x9604
[   57.853286]   EC = 0x25: DABT (current EL), IL = 32 bits
[   57.859177]   SET = 0, FnV = 0
[   57.862751]   EA = 0, S1PTW = 0
[   57.866415] Data abort info:
[   57.869801]   ISV = 0, ISS = 0x0004
[   57.874171]   CM = 0, WnR = 0
[   57.877634] swapper pgtable: 4k pages, 48-bit VAs, pgdp=a1646000
[   57.884937] [ffe8] pgd=, p4d=
[   57.892323] Internal error: Oops: 9604 [#1] PREEMPT SMP
[   57.898471] Modules linked in:
[   57.902022] CPU: 7 PID: 387 Comm: reboot Tainted: GW  
5.10.0-rc7-next-20201211-13328-gb9e15b9c1940-dirty #1270
[   57.914043] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[   57.921340] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[   57.927930] pc : platform_shutdown+0x8/0x34
[   57.932661] lr : device_shutdown+0x158/0x32c
[   57.937483] sp : 800010773c70
[   57.941319] x29: 800010773c70 x28: 14f80c41c600
[   57.947208] x27:  x26: 14f80129c490
[   57.953100] x25: aa6264ece398 x24: 0008
[   57.958990] x23: aa62655be030 x22: aa6265671600
[   57.964875] x21: 14f80122b010 x20: 14f80129c410
[   57.970765] x19: 14f80129c418 x18: 0030
[   57.976665] x17:  x16: 0001
[   57.982590] x15: 0004 x14: 019f
[   57.988478] x13:  x12: 
[   57.994394] x11:  x10: 09b0
[   58.000297] x9 : 800010773920 x8 : 14f80c41d010
[   58.006205] x7 : 14f976ff59c0 x6 : 0192
[   58.012112] x5 :  x4 : 14f976feb920
[   58.018023] x3 : 14f976ff2878 x2 : 
[   58.023940] x1 :  x0 : 14f80129c410
[   58.029871] Call trace:
[   58.032849]  platform_shutdown+0x8/0x34
[   58.037256]  kernel_restart+0x40/0xa0
[   58.041485]  __do_sys_reboot+0x228/0x250
[   58.045975]  __arm64_sys_reboot+0x28/0x34
[   58.050571]  el0_svc_common+0x7c/0x1a0
[   58.054886]  do_el0_svc+0x28/0x94
[   58.058754]  el0_svc+0x14/0x20
[   58.062371]  el0_sync_handler+0x1a4/0x1b0
[   58.066951]  el0_sync+0x174/0x180
[   58.070822] Code: d503201f d503201f d503245f f9403401 (f85e8021)
[   58.077532] ---[ end trace 26b521c0dca4c8d0 ]---

Signed-off-by: Dmitry Baryshkov 
Fixes: 9c30921fe799 ("driver core: platform: use bus_type functions")
---
 drivers/base/platform.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 0358dc3ea3ad..e9477e0bbca5 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1351,9 +1351,13 @@ static int platform_remove(struct device *_dev)
 
 static void platform_shutdown(struct device *_dev)
 {
-   struct platform_driver *drv = to_platform_driver(_dev->driver);
struct platform_device *dev = to_platform_device(_dev);
+   struct platform_driver *drv;
+
+   if (!_dev->driver)
+   return;
 
+   drv = to_platform_driver(_dev->driver);
if (drv->shutdown)
drv->shutdown(dev);
 }
-- 
2.29.2

Re: [PATCH 1/1] net: Fix use of proc_fs

[Yonatan Linik]

On Sat, Dec 12, 2020 at 9:48 PM Jakub Kicinski  wrote:
>
> On Fri, 11 Dec 2020 18:37:49 +0200 Yonatan Linik wrote:
> > proc_fs was used, in af_packet, without a surrounding #ifdef,
> > although there is no hard dependency on proc_fs.
> > That caused the initialization of the af_packet module to fail
> > when CONFIG_PROC_FS=n.
> >
> > Specifically, proc_create_net() was used in af_packet.c,
> > and when it fails, packet_net_init() returns -ENOMEM.
> > It will always fail when the kernel is compiled without proc_fs,
> > because, proc_create_net() for example always returns NULL.
> >
> > The calling order that starts in af_packet.c is as follows:
> > packet_init()
> > register_pernet_subsys()
> > register_pernet_operations()
> > __register_pernet_operations()
> > ops_init()
> > ops->init() (packet_net_ops.init=packet_net_init())
> > proc_create_net()
> >
> > It worked in the past because register_pernet_subsys()'s return value
> > wasn't checked before this Commit 36096f2f4fa0 ("packet: Fix error path in
> > packet_init.").
> > It always returned an error, but was not checked before, so everything
> > was working even when CONFIG_PROC_FS=n.
> >
> > The fix here is simply to add the necessary #ifdef.
> >
> > Signed-off-by: Yonatan Linik 
>
> Hm, I'm guessing you hit this on a kernel upgrade of a real system?

Yeah, suddenly using socket with AF_PACKET didn't work,
so I checked what happened.

> It seems like all callers to proc_create_net (and friends) interpret
> NULL as an error, but only handful is protected by an ifdef.

I guess where there is no ifdef,
there should be a hard dependency on procfs,
using depends on in the Kconfig.
Maybe that's not the case everywhere it should be.

>
> I checked a few and none of them cares about the proc_dir_entry pointer
> that gets returned. Should we perhaps rework the return values of the
> function so that we can return success if !CONFIG_PROC_FS without
> having to yield a pointer?

Sometimes the pointer returned is used,
for example in drivers/acpi/button.c.
Are you suggesting returning a bool while
having the pointer as an out parameter?
Because that would still be problematic where the pointer is used.

>
> Obviously we can apply this fix so we can backport to 5.4 if you need
> it. I think the ifdef is fine, since it's what other callers have.
>

It would be great to apply this where the problem exists,
I believe this applies to other versions as well.

-- 
Yonatan Linik

Re: [PATCH 3/3] driver core: platform: use bus_type functions

[Uwe Kleine-König]

Hi Marek,

On Fri, Dec 11, 2020 at 05:12:16PM +0100, Marek Szyprowski wrote:
> On 19.11.2020 13:46, Uwe Kleine-König wrote:
> > +static void platform_shutdown(struct device *_dev)
> > +{
> > +   struct platform_driver *drv = to_platform_driver(_dev->driver);
> > +   struct platform_device *dev = to_platform_device(_dev);
> > +
> > +   if (drv->shutdown)
> > +   drv->shutdown(dev);
> > +}
> 
> This will be called on unbound devices, what causes crash (observed on 
> today's linux-next):
> 
> Will now restart.
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address fff4
> pgd = 289f4b67
> [fff4] *pgd=6841, *pte=, *ppte=
> Internal error: Oops: 27 [#1] SMP ARM
> Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite 
> brcmfmac sha256_generic libsha256 sha256_arm cfg80211 brcmutil 
> panel_samsung_s6e8aa0 s5p_csi
> CPU: 0 PID: 1715 Comm: reboot Not tainted 
> 5.10.0-rc7-next-20201211-00069-g1e8aa883315f #9935
> Hardware name: Samsung Exynos (Flattened Device Tree)
> PC is at platform_shutdown+0x8/0x18
> LR is at device_shutdown+0x18c/0x25c
> ...
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Control: 10c5387d  Table: 4348404a  DAC: 0051
> Process reboot (pid: 1715, stack limit = 0xd050391e)
> Stack: (0xc3405e60 to 0xc3406000)
> [] (platform_shutdown) from [] 
> (device_shutdown+0x18c/0x25c)
> [] (device_shutdown) from [] (kernel_restart+0xc/0x68)
> [] (kernel_restart) from [] 
> (__do_sys_reboot+0x154/0x1f0)
> [] (__do_sys_reboot) from [] (ret_fast_syscall+0x0/0x58)
> Exception stack(0xc3405fa8 to 0xc3405ff0)
> ...
> ---[ end trace f39e94d5d6fd45bf ]---

Dmitry Baryshkov already proposed a fix, see
https://lore.kernel.org/r/20201212011426.163071-1-dmitry.barysh...@linaro.org

I expect a v2 soon.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH] driver core: platform: don't oops on unbound devices

[Uwe Kleine-König]

Hello Dmitry,

On Sat, Dec 12, 2020 at 11:49:26PM +0300, Dmitry Baryshkov wrote:
> On Sat, 12 Dec 2020 at 18:39, Uwe Kleine-König
>  wrote:
> > On Sat, Dec 12, 2020 at 12:41:32PM +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Dec 12, 2020 at 04:14:26AM +0300, Dmitry Baryshkov wrote:
> > > > Platform code stopped checking if the device is bound to the actual
> > > > platform driver, thus calling non-existing drv->shutdown(). Verify that
> > > > _dev->driver is not NULL before calling remove/shutdown callbacks.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov 
> > > > Fixes: 9c30921fe799 ("driver core: platform: use bus_type functions")
> > > > ---
> > > >  drivers/base/platform.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > > > index 0358dc3ea3ad..93f44e69b472 100644
> > > > --- a/drivers/base/platform.c
> > > > +++ b/drivers/base/platform.c
> > > > @@ -1342,7 +1342,7 @@ static int platform_remove(struct device *_dev)
> > > > struct platform_device *dev = to_platform_device(_dev);
> > > > int ret = 0;
> > > >
> > > > -   if (drv->remove)
> > > > +   if (_dev->driver && drv->remove)
> > > > ret = drv->remove(dev);
> > > > dev_pm_domain_detach(_dev, true);
> > >
> > > I don't object to this, but it always feels odd to be doing pointer math
> > > on a NULL value, wait until the static-checkers get ahold of this and
> > > you get crazy emails saying you are crashing the kernel (hint, they are
> > > broken).
> >
> > I think you refer to the line
> >
> > struct platform_driver *drv = to_platform_driver(_dev->driver);
> >
> > which when _dev->driver is NULL results in drv being something really
> > big?!
> 
> Yes. To remove pointer math on NULL value I can move the check for
> _dev->driver before calculating drv.

Yeah, that would be good.

> > Accoding to my understanding platform_remove() shouldn't be called if
> > the device isn't bound to a driver.
> >
> > > But, I don't see why this check is needed?  If a driver is not bound to
> > > a device, shouldn't this whole function just not be called?  Or error
> > > out at the top?
> > >
> > > Uwe, I'd really like your review/ack of this before taking it.
> >
> > So I agree and have the same question. So I wonder: @Dmitry, did you see
> > a crash? When did it happen?
> 
> The crash happens in the platform_shutdown() function, which gets
> called for unbound devices after commit 9c30921fe ("driver core:
> platform: use bus_type functions").
> I can include crash trace into v2.

Ah, now I understood. I didn't look too closely on your patch, only on
what Greg quoted. So you added a check to platform_remove (which should
be unnecessary) and to platform_shutdown (where I agree the check is
necessary).

> I added a check to platform_remove() as a safety measure. All current
> calls for dev->bus->remove() in dd.c seem to happen only when
> dev->driver is set, but I thought that it might be a good check. I can
> drop it if you'd like.

Yes, I'd like you to drop this. .remove isn't called for devices without
drivers.

Best regards and thanks for cleaning up after me,
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [GIT PULL] SCSI fixes for 5.10-rc7

[pr-tracker-bot]

The pull request you sent on Sat, 12 Dec 2020 11:32:54 -0800:

> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

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

Thank you!

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

Re: [PULL REQUEST] i2c for 5.10

[pr-tracker-bot]

The pull request you sent on Sat, 12 Dec 2020 19:30:46 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current

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

Thank you!

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

Re: [PATCH v2] proc: Allow pid_revalidate() during LOOKUP_RCU

[Matthew Wilcox]

On Thu, Dec 03, 2020 at 04:02:12PM -0800, Stephen Brennan wrote:
> -void pid_update_inode(struct task_struct *task, struct inode *inode)
> +static int do_pid_update_inode(struct task_struct *task, struct inode *inode,
> +unsigned int flags)

I'm really nitpicking here, but this function only _updates_ the inode
if flags says it should.  So I was thinking something like this
(compile tested only).

I'd really appreocate feedback from someone like Casey or Stephen on
what they need for their security modules.

diff --git a/fs/proc/base.c b/fs/proc/base.c
index b362523a9829..771f330bfce7 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1968,6 +1968,25 @@ void pid_update_inode(struct task_struct *task, struct 
inode *inode)
security_task_to_inode(task, inode);
 }
 
+/* See if we can avoid the above call.  Assumes RCU lock held */
+static bool inode_needs_pid_update(struct task_struct *task,
+   const struct inode *inode)
+{
+   kuid_t uid;
+   kgid_t gid;
+
+   if (inode->i_mode & (S_ISUID | S_ISGID))
+   return true;
+   task_dump_owner(task, inode->i_mode, , );
+   if (!uid_eq(uid, inode->i_uid) || !gid_eq(gid, inode->i_gid))
+   return true;
+   /*
+* XXX: Do we need to call the security system here to see if
+* there's a pending update?
+*/
+   return false;
+}
+
 /*
  * Rewrite the inode's ownerships here because the owning task may have
  * performed a setuid(), etc.
@@ -1978,8 +1997,15 @@ static int pid_revalidate(struct dentry *dentry, 
unsigned int flags)
struct inode *inode;
struct task_struct *task;
 
-   if (flags & LOOKUP_RCU)
+   if (flags & LOOKUP_RCU) {
+   inode = d_inode_rcu(dentry);
+   task = pid_task(proc_pid(inode), PIDTYPE_PID);
+   if (!task)
+   return 0;
+   if (!inode_needs_pid_update(task, inode))
+   return 1;
return -ECHILD;
+   }
 
inode = d_inode(dentry);
task = get_proc_task(inode);

Re: [PATCH 3/3] kbuild: rewrite ld-version.sh in shell script

[kernel test robot]

Hi Masahiro,

I love your patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on kbuild/for-next arm64/for-next/core linus/master 
v5.10-rc7 next-20201211]
[cannot apply to mmarek/misc]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Masahiro-Yamada/kbuild-do-not-use-scripts-ld-version-sh-for-checking-spatch-version/20201213-010621
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc64-randconfig-r014-20201213 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
84c09ab44599ece409e4e19761288ddf796fceec)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/0eab60f5e1f804528a4d0dd9566cb30f62242d22
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Masahiro-Yamada/kbuild-do-not-use-scripts-ld-version-sh-for-checking-spatch-version/20201213-010621
git checkout 0eab60f5e1f804528a4d0dd9566cb30f62242d22
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 
ARCH=powerpc64 

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

All errors (new ones prefixed by >>):

>> /bin/sh: 1: [: -ge: unexpected operator
   /bin/sh: 1: [: -lt: unexpected operator
--
>> /bin/sh: 1: [: -ge: unexpected operator
--
>> /bin/sh: 1: [: -ge: unexpected operator

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


.config.gz
Description: application/gzip

Re: [PATCH] driver core: platform: don't oops on unbound devices

[Dmitry Baryshkov]

Hello,

On Sat, 12 Dec 2020 at 18:39, Uwe Kleine-König
 wrote:
>
> Hello,
>
> On Sat, Dec 12, 2020 at 12:41:32PM +0100, Greg Kroah-Hartman wrote:
> > On Sat, Dec 12, 2020 at 04:14:26AM +0300, Dmitry Baryshkov wrote:
> > > Platform code stopped checking if the device is bound to the actual
> > > platform driver, thus calling non-existing drv->shutdown(). Verify that
> > > _dev->driver is not NULL before calling remove/shutdown callbacks.
> > >
> > > Signed-off-by: Dmitry Baryshkov 
> > > Fixes: 9c30921fe799 ("driver core: platform: use bus_type functions")
> > > ---
> > >  drivers/base/platform.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > > index 0358dc3ea3ad..93f44e69b472 100644
> > > --- a/drivers/base/platform.c
> > > +++ b/drivers/base/platform.c
> > > @@ -1342,7 +1342,7 @@ static int platform_remove(struct device *_dev)
> > > struct platform_device *dev = to_platform_device(_dev);
> > > int ret = 0;
> > >
> > > -   if (drv->remove)
> > > +   if (_dev->driver && drv->remove)
> > > ret = drv->remove(dev);
> > > dev_pm_domain_detach(_dev, true);
> >
> > I don't object to this, but it always feels odd to be doing pointer math
> > on a NULL value, wait until the static-checkers get ahold of this and
> > you get crazy emails saying you are crashing the kernel (hint, they are
> > broken).
>
> I think you refer to the line
>
> struct platform_driver *drv = to_platform_driver(_dev->driver);
>
> which when _dev->driver is NULL results in drv being something really
> big?!

Yes. To remove pointer math on NULL value I can move the check for
_dev->driver before calculating drv.

>
> Accoding to my understanding platform_remove() shouldn't be called if
> the device isn't bound to a driver.
>
> > But, I don't see why this check is needed?  If a driver is not bound to
> > a device, shouldn't this whole function just not be called?  Or error
> > out at the top?
> >
> > Uwe, I'd really like your review/ack of this before taking it.
>
> So I agree and have the same question. So I wonder: @Dmitry, did you see
> a crash? When did it happen?

The crash happens in the platform_shutdown() function, which gets
called for unbound devices after commit 9c30921fe ("driver core:
platform: use bus_type functions").
I can include crash trace into v2.

I added a check to platform_remove() as a safety measure. All current
calls for dev->bus->remove() in dd.c seem to happen only when
dev->driver is set, but I thought that it might be a good check. I can
drop it if you'd like.


>
> For one of the bus types I changed recently
> (arch/powerpc/platforms/ps3/system-bus.c) the bus's shutdown function
> does:
>
> if (drv->shutdown)
> drv->shutdown(dev);
> else if (drv->remove) {
> dev_dbg(>core, ...
> drv->remove(dev);
> } ...
>
> but for the platform bus I'm not aware that remove is used in absence of
> a shutdown callback.
>
> Relevant callers of bus->remove are all in drivers/base/dd.c, and for
> all of them dev->driver should be set.
>
> I look forward to an explaination about why this patch was created.

Here is an explanation: the 3d6a.gmu device is not bound to a
driver, causing a crash during reboot.

[   57.832972] platform 3d6a000.gmu: shutdown
[   57.837778] Unable to handle kernel paging request at virtual
address ffe8
[   57.846391] Mem abort info:
[   57.849704]   ESR = 0x9604
[   57.853286]   EC = 0x25: DABT (current EL), IL = 32 bits
[   57.859177]   SET = 0, FnV = 0
[   57.862751]   EA = 0, S1PTW = 0
[   57.866415] Data abort info:
[   57.869801]   ISV = 0, ISS = 0x0004
[   57.874171]   CM = 0, WnR = 0
[   57.877634] swapper pgtable: 4k pages, 48-bit VAs, pgdp=a1646000
[   57.884937] [ffe8] pgd=, p4d=
[   57.892323] Internal error: Oops: 9604 [#1] PREEMPT SMP
[   57.898471] Modules linked in:
[   57.902022] CPU: 7 PID: 387 Comm: reboot Tainted: GW
 5.10.0-rc7-next-20201211-13328-gb9e15b9c1940-dirty #1270
[   57.914043] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[   57.921340] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[   57.927930] pc : platform_shutdown+0x8/0x34
[   57.932661] lr : device_shutdown+0x158/0x32c
[   57.937483] sp : 800010773c70
[   57.941319] x29: 800010773c70 x28: 14f80c41c600
[   57.947208] x27:  x26: 14f80129c490
[   57.953100] x25: aa6264ece398 x24: 0008
[   57.958990] x23: aa62655be030 x22: aa6265671600
[   57.964875] x21: 14f80122b010 x20: 14f80129c410
[   57.970765] x19: 14f80129c418 x18: 0030
[   57.976665] x17:  x16: 0001
[   57.982590] x15: 0004 x14: 019f
[   57.988478] x13:  x12: 
[   57.994394] x11:  x10: 

[PATCH] remoteproc: Create a separate workqueue for recovery tasks

[Rishabh Bhatnagar]

Create an unbound high priority workqueue for recovery tasks.
Recovery time is an important parameter for a subsystem and there
might be situations where multiple subsystems crash around the same
time. Scheduling into an unbound workqueue increases parallelization
and avoids time impact. Also creating a high priority workqueue
will utilize separate worker threads with higher nice values than
normal ones.

Signed-off-by: Rishabh Bhatnagar 
---
 drivers/remoteproc/remoteproc_core.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 46c2937..8fd8166 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -48,6 +48,8 @@ static DEFINE_MUTEX(rproc_list_mutex);
 static LIST_HEAD(rproc_list);
 static struct notifier_block rproc_panic_nb;
 
+static struct workqueue_struct *rproc_wq;
+
 typedef int (*rproc_handle_resource_t)(struct rproc *rproc,
 void *, int offset, int avail);
 
@@ -2475,7 +2477,7 @@ void rproc_report_crash(struct rproc *rproc, enum 
rproc_crash_type type)
rproc->name, rproc_crash_to_string(type));
 
/* create a new task to handle the error */
-   schedule_work(>crash_handler);
+   queue_work(rproc_wq, >crash_handler);
 }
 EXPORT_SYMBOL(rproc_report_crash);
 
@@ -2520,6 +2522,10 @@ static void __exit rproc_exit_panic(void)
 
 static int __init remoteproc_init(void)
 {
+   rproc_wq = alloc_workqueue("rproc_wq", WQ_UNBOUND | WQ_HIGHPRI, 0);
+   if (!rproc_wq)
+   return -ENOMEM;
+
rproc_init_sysfs();
rproc_init_debugfs();
rproc_init_cdev();
@@ -2536,6 +2542,7 @@ static void __exit remoteproc_exit(void)
rproc_exit_panic();
rproc_exit_debugfs();
rproc_exit_sysfs();
+   destroy_workqueue(rproc_wq);
 }
 module_exit(remoteproc_exit);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[net-next PATCH v3] tcp: Add logic to check for SYN w/ data in tcp_simple_retransmit

[Alexander Duyck]

From: Alexander Duyck 

There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame.

Normally a SYN frame should not be able to trigger a ICMP_TOOBIG or
ICMP_FRAG_NEEDED however in the case of fastopen we can have a frame that
makes use of the entire MSS. In the case of fastopen it does, and an
additional complication is that the retransmit queue doesn't contain the
original frames. As a result when tcp_simple_retransmit is called and
walks the list of frames in the queue it may not mark the frames as lost
because both the SYN and the data packet each individually are smaller than
the MSS size after the adjustment. This results in the socket being stalled
until the retransmit timer kicks in and forces the SYN frame out again
without the data attached.

In order to resolve this we can reduce the MSS the packets are compared
to in tcp_simple_retransmit to -1 for cases where we are still in the
TCP_SYN_SENT state for a fastopen socket. Doing this we will mark all of
the packets related to the fastopen SYN as lost.

Signed-off-by: Alexander Duyck 
---

v2: Changed logic to invalidate all retransmit queue frames if fastopen SYN
v3: Updated commit message to reflect actual solution in 3rd paragraph

 net/ipv4/tcp_input.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9e8a6c1aa019..e44327a39a1f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2688,7 +2688,22 @@ void tcp_simple_retransmit(struct sock *sk)
const struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
-   unsigned int mss = tcp_current_mss(sk);
+   int mss;
+
+   /* A fastopen SYN request is stored as two separate packets within
+* the retransmit queue, this is done by tcp_send_syn_data().
+* As a result simply checking the MSS of the frames in the queue
+* will not work for the SYN packet.
+*
+* Us being here is an indication of a path MTU issue so we can
+* assume that the fastopen SYN was lost and just mark all the
+* frames in the retransmit queue as lost. We will use an MSS of
+* -1 to mark all frames as lost, otherwise compute the current MSS.
+*/
+   if (tp->syn_data && sk->sk_state == TCP_SYN_SENT)
+   mss = -1;
+   else
+   mss = tcp_current_mss(sk);
 
skb_rbtree_walk(skb, >tcp_rtx_queue) {
if (tcp_skb_seglen(skb) > mss)

Re: [PATCH 3/3] kbuild: rewrite ld-version.sh in shell script

[kernel test robot]

Hi Masahiro,

I love your patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on kbuild/for-next arm64/for-next/core linus/master 
v5.10-rc7 next-20201211]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Masahiro-Yamada/kbuild-do-not-use-scripts-ld-version-sh-for-checking-spatch-version/20201213-010621
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-tqm8xx_defconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/0eab60f5e1f804528a4d0dd9566cb30f62242d22
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Masahiro-Yamada/kbuild-do-not-use-scripts-ld-version-sh-for-checking-spatch-version/20201213-010621
git checkout 0eab60f5e1f804528a4d0dd9566cb30f62242d22
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

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

All errors (new ones prefixed by >>):

>> /bin/sh: 1: [: -ge: unexpected operator
   /bin/sh: 1: [: -lt: unexpected operator
--
>> /bin/sh: 1: [: -ge: unexpected operator
--
>> /bin/sh: 1: [: -ge: unexpected operator

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


.config.gz
Description: application/gzip

Re: [PATCH] thermal/core: Make 'forced_passive' as obsolete candidate

[Matthew Garrett]

On Sat, Dec 12, 2020 at 10:11:31AM +0100, Daniel Lezcano wrote:
> On 12/12/2020 04:50, Matthew Garrett wrote:
> > Yes - what's the reason to do so?
> 
> I'm cleaning up the thermal core code, so questioning every old ABI.
> 
> > The code isn't specific to ACPI,
> > so being able to override ACPI tables doesn't seem to justify it.
> 
> I agree, the code is no specific to ACPI.
> 
> What non-ACPI architecture, without device tree or platform data would
> need the 'passive' option today ?

Anything that provides a trip point that has no active notifications and
doesn't provide any information that tells the kernel to poll it.

[net-next PATCH v2] tcp: Add logic to check for SYN w/ data in tcp_simple_retransmit

[Alexander Duyck]

From: Alexander Duyck 

There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame.

Normally a SYN frame should not be able to trigger a ICMP_TOOBIG or
ICMP_FRAG_NEEDED however in the case of fastopen we can have a frame that
makes use of the entire MSS. In the case of fastopen it does, and an
additional complication is that the retransmit queue doesn't contain the
original frames. As a result when tcp_simple_retransmit is called and
walks the list of frames in the queue it may not mark the frames as lost
because both the SYN and the data packet each individually are smaller than
the MSS size after the adjustment. This results in the socket being stalled
until the retransmit timer kicks in and forces the SYN frame out again
without the data attached.

In order to resolve this we can generate our best estimate for the original
packet size by detecting the fastopen SYN frame and then adding the
overhead for MAX_TCP_OPTION_SPACE and verifying if the SYN w/ data would
have exceeded the MSS. If so we can mark the frame as lost and retransmit
it.

Signed-off-by: Alexander Duyck 
---
 net/ipv4/tcp_input.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9e8a6c1aa019..e44327a39a1f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2688,7 +2688,22 @@ void tcp_simple_retransmit(struct sock *sk)
const struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
-   unsigned int mss = tcp_current_mss(sk);
+   int mss;
+
+   /* A fastopen SYN request is stored as two separate packets within
+* the retransmit queue, this is done by tcp_send_syn_data().
+* As a result simply checking the MSS of the frames in the queue
+* will not work for the SYN packet.
+*
+* Us being here is an indication of a path MTU issue so we can
+* assume that the fastopen SYN was lost and just mark all the
+* frames in the retransmit queue as lost. We will use an MSS of
+* -1 to mark all frames as lost, otherwise compute the current MSS.
+*/
+   if (tp->syn_data && sk->sk_state == TCP_SYN_SENT)
+   mss = -1;
+   else
+   mss = tcp_current_mss(sk);
 
skb_rbtree_walk(skb, >tcp_rtx_queue) {
if (tcp_skb_seglen(skb) > mss)

Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

[Thomas Gleixner]

On Sat, Dec 12 2020 at 13:26, Marco Elver wrote:
> On Thu, Mar 07, 2019 at 10:14AM +0100, Arnd Bergmann wrote:
>> -static void __init futex_detect_cmpxchg(void)
>> +static noinline void futex_detect_cmpxchg(void)
>>  {
>>  #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
>>  u32 curval;
>
> What ever happened to this patch?

It obviously fell through the cracks. 

> I'm seeing this again with the attached config + next-20201211 (for
> testing https://bugs.llvm.org/show_bug.cgi?id=48492). Had to apply this
> patch to build the kernel.

What really bothers me is to remove the __init from a function which is
clearly only used during init. And looking deeper it's simply a hack.

This function is only needed when an architecture has to runtime
discover whether the CPU supports it or not. ARM has unconditional
support for this, so the obvious thing to do is the below.

Thanks,

tglx
---
 arch/arm/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -86,6 +86,7 @@ config ARM
select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
select HAVE_FUNCTION_TRACER if !XIP_KERNEL
+   select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || 
CPU_V7)
select HAVE_IDE if PCI || ISA || PCMCIA

Re: [net-next PATCH] tcp: Add logic to check for SYN w/ data in tcp_simple_retransmit

[Alexander Duyck]

On Sat, Dec 12, 2020 at 11:07 AM Yuchung Cheng  wrote:
>
> On Sat, Dec 12, 2020 at 11:01 AM Alexander Duyck
>  wrote:
> >
> > On Sat, Dec 12, 2020 at 10:34 AM Yuchung Cheng  wrote:
> > >
> > > On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
> > >  wrote:
> > > >
> > > > From: Alexander Duyck 
> > > >
> > > > There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
> > > > message in the case of IPv6 or a fragmentation request in the case of
> > > > IPv4. This results in the socket stalling for a second or more as it 
> > > > does
> > > > not respond to the message by retransmitting the SYN frame.
> > > >
> > > > Normally a SYN frame should not be able to trigger a ICMP_TOOBIG or
> > > > ICMP_FRAG_NEEDED however in the case of fastopen we can have a frame 
> > > > that
> > > > makes use of the entire MSS. In the case of fastopen it does, and an
> > > > additional complication is that the retransmit queue doesn't contain the
> > > > original frames. As a result when tcp_simple_retransmit is called and
> > > > walks the list of frames in the queue it may not mark the frames as lost
> > > > because both the SYN and the data packet each individually are smaller 
> > > > than
> > > > the MSS size after the adjustment. This results in the socket being 
> > > > stalled
> > > > until the retransmit timer kicks in and forces the SYN frame out again
> > > > without the data attached.
> > > >
> > > > In order to resolve this we can generate our best estimate for the 
> > > > original
> > > > packet size by detecting the fastopen SYN frame and then adding the
> > > > overhead for MAX_TCP_OPTION_SPACE and verifying if the SYN w/ data would
> > > > have exceeded the MSS. If so we can mark the frame as lost and 
> > > > retransmit
> > > > it.
> > > >
> > > > Signed-off-by: Alexander Duyck 
> > > > ---
> > > >  net/ipv4/tcp_input.c |   30 +++---
> > > >  1 file changed, 27 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > > > index 9e8a6c1aa019..79375b58de84 100644
> > > > --- a/net/ipv4/tcp_input.c
> > > > +++ b/net/ipv4/tcp_input.c
> > > > @@ -2686,11 +2686,35 @@ static void tcp_mtup_probe_success(struct sock 
> > > > *sk)
> > > >  void tcp_simple_retransmit(struct sock *sk)
> > > >  {
> > > > const struct inet_connection_sock *icsk = inet_csk(sk);
> > > > +   struct sk_buff *skb = tcp_rtx_queue_head(sk);
> > > > struct tcp_sock *tp = tcp_sk(sk);
> > > > -   struct sk_buff *skb;
> > > > -   unsigned int mss = tcp_current_mss(sk);
> > > > +   unsigned int mss;
> > > > +
> > > > +   /* A fastopen SYN request is stored as two separate packets 
> > > > within
> > > > +* the retransmit queue, this is done by tcp_send_syn_data().
> > > > +* As a result simply checking the MSS of the frames in the 
> > > > queue
> > > > +* will not work for the SYN packet. So instead we must make a 
> > > > best
> > > > +* effort attempt by validating the data frame with the mss size
> > > > +* that would be computed now by tcp_send_syn_data and comparing
> > > > +* that against the data frame that would have been included 
> > > > with
> > > > +* the SYN.
> > > > +*/
> > > > +   if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_SYN && tp->syn_data) {
> > > > +   struct sk_buff *syn_data = skb_rb_next(skb);
> > > > +
> > > > +   mss = tcp_mtu_to_mss(sk, icsk->icsk_pmtu_cookie) +
> > > > + tp->tcp_header_len - sizeof(struct tcphdr) -
> > > > + MAX_TCP_OPTION_SPACE;
> > > nice comment! The original syn_data mss needs to be inferred which is
> > > a hassle to get right. my sense is path-mtu issue is enough to warrant
> > > they are lost.
> > > I suggest simply mark syn & its data lost if tcp_simple_retransmit is
> > > called during TFO handshake, i.e.
> > >
> > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > > index 62f7aabc7920..7f0c4f2947eb 100644
> > > --- a/net/ipv4/tcp_input.c
> > > +++ b/net/ipv4/tcp_input.c
> > > @@ -2864,7 +2864,8 @@ void tcp_simple_retransmit(struct sock *sk)
> > > unsigned int mss = tcp_current_mss(sk);
> > >
> > > skb_rbtree_walk(skb, >tcp_rtx_queue) {
> > > -   if (tcp_skb_seglen(skb) > mss)
> > > +   if (tcp_skb_seglen(skb) > mss ||
> > > +   (tp->syn_data && sk->sk_state == TCP_SYN_SENT))
> > > tcp_mark_skb_lost(sk, skb);
> > > }
> > >
> > > We have a TFO packetdrill test that verifies my suggested fix should
> > > trigger an immediate retransmit vs 1s wait.
> >
> > Okay, I will go that route, although I will still probably make one
> > minor cleanup. Instead of testing for syn_data and state per packet I
> > will probably keep the bit where I overwrite mss since it is only used
> > in the loop. What I can do is switch it from unsigned int to int since
> > technically 

[PATCH] leds: Use DEVICE_ATTR_{RW, RO, WO} macros

[Dwaipayan Ray]

Instead of open coding DEVICE_ATTR() defines, use the
DEVICE_ATTR_RW(), DEVICE_ATTR_WO(), and DEVICE_ATTR_RO()
macros intead.

This required a few functions to be renamed, but the functionality
itself is unchanged.

Note that this is compile tested only.

Cc: Greg Kroah-Hartman 
Cc: Dan Murphy 
Cc: Pavel Machek 
Cc: Lukas Bulwahn 
Cc: linux-l...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-kernel-ment...@lists.linuxfoundation.org
Signed-off-by: Dwaipayan Ray 
---
 drivers/leds/leds-blinkm.c| 24 
 drivers/leds/leds-lm3530.c| 10 +-
 drivers/leds/leds-lm355x.c|  8 
 drivers/leds/leds-lm3642.c| 16 
 drivers/leds/leds-max8997.c   | 12 ++--
 drivers/leds/leds-netxbig.c   | 12 ++--
 drivers/leds/leds-ss4200.c| 12 ++--
 drivers/leds/leds-wm831x-status.c | 12 ++--
 8 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/drivers/leds/leds-blinkm.c b/drivers/leds/leds-blinkm.c
index e11fe1788242..b4e1fdff4186 100644
--- a/drivers/leds/leds-blinkm.c
+++ b/drivers/leds/leds-blinkm.c
@@ -192,13 +192,13 @@ static int store_color_common(struct device *dev, const 
char *buf, int color)
return 0;
 }
 
-static ssize_t show_red(struct device *dev, struct device_attribute *attr,
+static ssize_t red_show(struct device *dev, struct device_attribute *attr,
char *buf)
 {
return show_color_common(dev, buf, RED);
 }
 
-static ssize_t store_red(struct device *dev, struct device_attribute *attr,
+static ssize_t red_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t count)
 {
int ret;
@@ -209,15 +209,15 @@ static ssize_t store_red(struct device *dev, struct 
device_attribute *attr,
return count;
 }
 
-static DEVICE_ATTR(red, S_IRUGO | S_IWUSR, show_red, store_red);
+static DEVICE_ATTR_RW(red);
 
-static ssize_t show_green(struct device *dev, struct device_attribute *attr,
+static ssize_t green_show(struct device *dev, struct device_attribute *attr,
  char *buf)
 {
return show_color_common(dev, buf, GREEN);
 }
 
-static ssize_t store_green(struct device *dev, struct device_attribute *attr,
+static ssize_t green_store(struct device *dev, struct device_attribute *attr,
   const char *buf, size_t count)
 {
 
@@ -229,15 +229,15 @@ static ssize_t store_green(struct device *dev, struct 
device_attribute *attr,
return count;
 }
 
-static DEVICE_ATTR(green, S_IRUGO | S_IWUSR, show_green, store_green);
+static DEVICE_ATTR_RW(green);
 
-static ssize_t show_blue(struct device *dev, struct device_attribute *attr,
+static ssize_t blue_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
return show_color_common(dev, buf, BLUE);
 }
 
-static ssize_t store_blue(struct device *dev, struct device_attribute *attr,
+static ssize_t blue_store(struct device *dev, struct device_attribute *attr,
  const char *buf, size_t count)
 {
int ret;
@@ -248,16 +248,16 @@ static ssize_t store_blue(struct device *dev, struct 
device_attribute *attr,
return count;
 }
 
-static DEVICE_ATTR(blue, S_IRUGO | S_IWUSR, show_blue, store_blue);
+static DEVICE_ATTR_RW(blue);
 
-static ssize_t show_test(struct device *dev, struct device_attribute *attr,
+static ssize_t test_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
return scnprintf(buf, PAGE_SIZE,
 "#Write into test to start test sequence!#\n");
 }
 
-static ssize_t store_test(struct device *dev, struct device_attribute *attr,
+static ssize_t test_store(struct device *dev, struct device_attribute *attr,
  const char *buf, size_t count)
 {
 
@@ -273,7 +273,7 @@ static ssize_t store_test(struct device *dev, struct 
device_attribute *attr,
return count;
 }
 
-static DEVICE_ATTR(test, S_IRUGO | S_IWUSR, show_test, store_test);
+static DEVICE_ATTR_RW(test);
 
 /* TODO: HSB, fade, timeadj, script ... */
 
diff --git a/drivers/leds/leds-lm3530.c b/drivers/leds/leds-lm3530.c
index 2f8362f6bf75..2db455efd4b1 100644
--- a/drivers/leds/leds-lm3530.c
+++ b/drivers/leds/leds-lm3530.c
@@ -346,8 +346,8 @@ static void lm3530_brightness_set(struct led_classdev 
*led_cdev,
}
 }
 
-static ssize_t lm3530_mode_get(struct device *dev,
-   struct device_attribute *attr, char *buf)
+static ssize_t mode_show(struct device *dev,
+struct device_attribute *attr, char *buf)
 {
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct lm3530_data *drvdata;
@@ -365,8 +365,8 @@ static ssize_t lm3530_mode_get(struct device *dev,
return len;
 }
 
-static ssize_t lm3530_mode_set(struct device *dev, struct device_attribute
-  *attr, 

Re: [PATCH 1/1] net: Fix use of proc_fs

[Jakub Kicinski]

On Fri, 11 Dec 2020 18:37:49 +0200 Yonatan Linik wrote:
> proc_fs was used, in af_packet, without a surrounding #ifdef,
> although there is no hard dependency on proc_fs.
> That caused the initialization of the af_packet module to fail
> when CONFIG_PROC_FS=n.
> 
> Specifically, proc_create_net() was used in af_packet.c,
> and when it fails, packet_net_init() returns -ENOMEM.
> It will always fail when the kernel is compiled without proc_fs,
> because, proc_create_net() for example always returns NULL.
> 
> The calling order that starts in af_packet.c is as follows:
> packet_init()
> register_pernet_subsys()
> register_pernet_operations()
> __register_pernet_operations()
> ops_init()
> ops->init() (packet_net_ops.init=packet_net_init())
> proc_create_net()
> 
> It worked in the past because register_pernet_subsys()'s return value
> wasn't checked before this Commit 36096f2f4fa0 ("packet: Fix error path in
> packet_init.").
> It always returned an error, but was not checked before, so everything
> was working even when CONFIG_PROC_FS=n.
> 
> The fix here is simply to add the necessary #ifdef.
> 
> Signed-off-by: Yonatan Linik 

Hm, I'm guessing you hit this on a kernel upgrade of a real system?
It seems like all callers to proc_create_net (and friends) interpret
NULL as an error, but only handful is protected by an ifdef.

I checked a few and none of them cares about the proc_dir_entry pointer
that gets returned. Should we perhaps rework the return values of the
function so that we can return success if !CONFIG_PROC_FS without
having to yield a pointer?

Obviously we can apply this fix so we can backport to 5.4 if you need
it. I think the ifdef is fine, since it's what other callers have.

> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 2b33e977a905..031f2b593720 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -4612,9 +4612,11 @@ static int __net_init packet_net_init(struct net *net)
>   mutex_init(>packet.sklist_lock);
>   INIT_HLIST_HEAD(>packet.sklist);
>  
> +#ifdef CONFIG_PROC_FS
>   if (!proc_create_net("packet", 0, net->proc_net, _seq_ops,
>   sizeof(struct seq_net_private)))
>   return -ENOMEM;
> +#endif /* CONFIG_PROC_FS */
>  
>   return 0;
>  }

[tip: irq/core] Merge tag 'irqchip-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

[tip-bot2 for Thomas Gleixner]

The following commit has been merged into the irq/core branch of tip:

Commit-ID: 559db8c7e6ed1f24baf7264a6966ee4f051c6446
Gitweb:
https://git.kernel.org/tip/559db8c7e6ed1f24baf7264a6966ee4f051c6446
Author:Thomas Gleixner 
AuthorDate:Sat, 12 Dec 2020 20:35:24 +01:00
Committer: Thomas Gleixner 
CommitterDate: Sat, 12 Dec 2020 20:35:24 +01:00

Merge tag 'irqchip-5.11' of 
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

Pull irqchip updates for 5.11 from Marc Zyngier:

 - Preliminary support for managed interrupts on platform devices
 - Correctly identify allocation of MSIs proxyied by another device
 - Remove the fasteoi IPI flow which has been proved useless
 - Generalise the Ocelot support to new SoCs
 - Improve GICv4.1 vcpu entry, matching the corresponding KVM optimisation
 - Work around spurious interrupts on Qualcomm PDC
 - Random fixes and cleanups

Link: https://lore.kernel.org/r/20201212135626.1479884-1-...@kernel.org
---

Re: [RFC] ravb: Add support for optional txc_refclk

[Adam Ford]

On Sat, Dec 12, 2020 at 11:55 AM Sergei Shtylyov
 wrote:
>
> Hello!
>
> On 12.12.2020 19:56, Adam Ford wrote:
>
> > The SoC expects the txv_refclk is provided, but if it is provided
> > by a programmable clock, there needs to be a way to get and enable
> > this clock to operate.  It needs to be optional since it's only
> > necessary for those with programmable clocks.
> >
> > Signed-off-by: Adam Ford 
> [...]
> > diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
> > b/drivers/net/ethernet/renesas/ravb_main.c
> > index bd30505fbc57..4c3f95923ef2 100644
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -2148,6 +2148,18 @@ static int ravb_probe(struct platform_device *pdev)
> >   goto out_release;
> >   }
> >
> > + priv->ref_clk = devm_clk_get(>dev, "txc_refclk");
>
> Why not devm_clk_get_optional()?

I am not that familiar with the clock API.  I'll look into that
function. It looks like it makes more sense.  I'll send a V2.

adam
>
> > + if (IS_ERR(priv->ref_clk)) {
> > + if (PTR_ERR(priv->ref_clk) == -EPROBE_DEFER) {
> > + /* for Probe defer return error */
> > + error = PTR_ERR(priv->ref_clk);
> > + goto out_release;
> > + }
> > + /* Ignore other errors since it's optional */
> > + } else {
> > + (void)clk_prepare_enable(priv->ref_clk);
> > + }
> > +
> >   ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
> >   ndev->min_mtu = ETH_MIN_MTU;
> >
>
> MBR, Sergei

Re: [PATCH v10 4/4] arm64: dts: sparx5: Add Sparx5 serdes driver node

[Andrew Lunn]

On Fri, Dec 11, 2020 at 10:05:41AM +0100, Steen Hegelund wrote:
> Add Sparx5 serdes driver node, and enable it generally for all
> reference boards.
> 
> Signed-off-by: Lars Povlsen 
> Signed-off-by: Steen Hegelund 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH RESEND net-next 1/2] dpaa2-eth: send a scatter-gather FD instead of realloc-ing

[Ioana Ciornei]

On Sat, Dec 12, 2020 at 04:58:56PM +0100, Jon Nettleton wrote:
> On Fri, Dec 11, 2020 at 5:56 PM Ioana Ciornei  wrote:
> >
> > On Fri, Dec 11, 2020 at 04:29:14PM +, Daniel Thompson wrote:
> > > On Fri, Dec 11, 2020 at 02:01:28PM +, Ioana Ciornei wrote:
> > > > On Thu, Dec 10, 2020 at 08:06:36PM +0200, Ioana Ciornei wrote:
> > > > > [Added also the netdev mailing list, I haven't heard of linux-netdev
> > > > > before but kept it]
> > > > >
> > > > > On Thu, Dec 10, 2020 at 05:31:56PM +, Daniel Thompson wrote:
> > > > > > Hi Ioana
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > >
> > > > > > On Mon, Jun 29, 2020 at 06:47:11PM +, Ioana Ciornei wrote:
> > > > > > > Instead of realloc-ing the skb on the Tx path when the provided 
> > > > > > > headroom
> > > > > > > is smaller than the HW requirements, create a Scatter/Gather frame
> > > > > > > descriptor with only one entry.
> > > > > > >
> > > > > > > Remove the '[drv] tx realloc frames' counter exposed previously 
> > > > > > > through
> > > > > > > ethtool since it is no longer used.
> > > > > > >
> > > > > > > Signed-off-by: Ioana Ciornei 
> > > > > > > ---
> > > > > >
> > > > > > I've been chasing down a networking regression on my LX2160A board
> > > > > > (Honeycomb LX2K based on CEx7 LX2160A COM) that first appeared in 
> > > > > > v5.9.
> > > > > >
> > > > > > It makes the board unreliable opening outbound connections meaning
> > > > > > things like `apt update` or `git fetch` often can't open the 
> > > > > > connection.
> > > > > > It does not happen all the time but is sufficient to make the boards
> > > > > > built-in networking useless for workstation use.
> > > > > >
> > > > > > The problem is strongly linked to warnings in the logs so I used the
> > > > > > warnings to bisect down to locate the cause of the regression and it
> > > > > > pinpointed this patch. I have confirmed that in both v5.9 and 
> > > > > > v5.10-rc7
> > > > > > that reverting this patch (and fixing up the merge issues) fixes the
> > > > > > regression and the warnings stop appearing.
> > > > > >
> > > > > > A typical example of the warning is below (io-pgtable-arm.c:281 is 
> > > > > > an
> > > > > > error path that I guess would cause dma_map_page_attrs() to return
> > > > > > an error):
> > > > > >
> > > > > > [  714.464927] WARNING: CPU: 13 PID: 0 at
> > > > > > drivers/iommu/io-pgtable-arm.c:281 __arm_lpae_map+0x2d4/0x30c
> > > > > > [  714.464930] Modules linked in: snd_seq_dummy(E) snd_hrtimer(E)
> > > > > > snd_seq(E) snd_seq_device(E) snd_timer(E) snd(E) soundcore(E) 
> > > > > > bridge(E)
> > > > > > stp(E) llc(E) rfkill(E) caam_jr(E) crypto_engine(E) rng_core(E)
> > > > > > joydev(E) evdev(E) dpaa2_caam(E) caamhash_desc(E) caamalg_desc(E)
> > > > > > authenc(E) libdes(E) dpaa2_console(E) ofpart(E) caam(E) sg(E) 
> > > > > > error(E)
> > > > > > lm90(E) at24(E) spi_nor(E) mtd(E) sbsa_gwdt(E) qoriq_thermal(E)
> > > > > > layerscape_edac_mod(E) qoriq_cpufreq(E) drm(E) fuse(E) configfs(E)
> > > > > > ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc32c_generic(E) 
> > > > > > crc16(E)
> > > > > > mbcache(E) jbd2(E) hid_generic(E) usbhid(E) hid(E) dm_crypt(E) 
> > > > > > dm_mod(E)
> > > > > > sd_mod(E) fsl_dpaa2_ptp(E) ptp_qoriq(E) fsl_dpaa2_eth(E)
> > > > > > xhci_plat_hcd(E) xhci_hcd(E) usbcore(E) aes_ce_blk(E) crypto_simd(E)
> > > > > > cryptd(E) aes_ce_cipher(E) ghash_ce(E) gf128mul(E) at803x(E) 
> > > > > > libaes(E)
> > > > > > fsl_mc_dpio(E) pcs_lynx(E) rtc_pcf2127(E) sha2_ce(E) phylink(E)
> > > > > > xgmac_mdio(E) regmap_spi(E) of_mdio(E) sha256_arm64(E)
> > > > > > i2c_mux_pca954x(E) fixed_phy(E) i2c_mux(E) sha1_ce(E) ptp(E) 
> > > > > > libphy(E)
> > > > > > [  714.465131]  pps_core(E) ahci_qoriq(E) libahci_platform(E) 
> > > > > > nvme(E)
> > > > > > libahci(E) nvme_core(E) t10_pi(E) libata(E) crc_t10dif(E)
> > > > > > crct10dif_generic(E) crct10dif_common(E) dwc3(E) scsi_mod(E) 
> > > > > > udc_core(E)
> > > > > > roles(E) ulpi(E) sdhci_of_esdhc(E) sdhci_pltfm(E) sdhci(E)
> > > > > > spi_nxp_fspi(E) i2c_imx(E) fixed(E)
> > > > > > [  714.465192] CPU: 13 PID: 0 Comm: swapper/13 Tainted: GW  
> > > > > >  E
> > > > > > 5.10.0-rc7-1-gba98d13279ca #52
> > > > > > [  714.465196] Hardware name: SolidRun LX2160A Honeycomb (DT)
> > > > > > [  714.465202] pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
> > > > > > [  714.465207] pc : __arm_lpae_map+0x2d4/0x30c
> > > > > > [  714.465211] lr : __arm_lpae_map+0x114/0x30c
> > > > > > [  714.465215] sp : 80001006b340
> > > > > > [  714.465219] x29: 80001006b340 x28: 002086538003
> > > > > > [  714.465227] x27: 0a20 x26: 1000
> > > > > > [  714.465236] x25: 0f44 x24: 0020adf8d000
> > > > > > [  714.465245] x23: 0001 x22: faeca000
> > > > > > [  714.465253] x21: 0003 x20: 19b60d64d200
> > > > > > [  714.465261] x19: 00ca x18: 
> > > > > > [  714.465270] x17: 

Re: [PATCH v10 3/4] phy: Add Sparx5 ethernet serdes PHY driver

[Andrew Lunn]

On Fri, Dec 11, 2020 at 10:05:40AM +0100, Steen Hegelund wrote:
> Add the Microchip Sparx5 ethernet serdes PHY driver for the 6G, 10G and 25G
> interfaces available in the Sparx5 SoC.
> 
> Signed-off-by: Bjarni Jonasson 
> Signed-off-by: Steen Hegelund 

Reviewed-by: Andrew Lunn 

Andrew

Re: common_interrupt: No irq handler for vector

[Thomas Gleixner]

On Fri, Dec 11 2020 at 13:41, Shuah Khan wrote:

> I am debugging __common_interrupt: 1.55 No irq handler for vector
> messages and noticed comments and code don't agree:

I bet that's on an AMD system with broken AGESA BIOS Good luck
debugging it :) BIOS updates are on the way so I'm told.

> arch/x86/kernel/apic/msi.c: msi_set_affinity() says:
>
>
>   * If the vector is in use then the installed device handler will
>   * denote it as spurious which is no harm as this is a rare event
>   * and interrupt handlers have to cope with spurious interrupts
>   * anyway. If the vector is unused, then it is marked so it won't
>   * trigger the 'No irq handler for vector' warning in
>   * common_interrupt().
>
> common_interrupt() prints message if vector is unused: VECTOR_UNUSED
>
> ack_APIC_irq();
>
> if (desc == VECTOR_UNUSED) {
>  pr_emerg_ratelimited("%s: %d.%u No irq handler for vector\n",
>__func__, smp_processor_id(), vector);
> }
>
> Something wrong here?

No. It's perfectly correct in the MSI code. See further down.

if (IS_ERR_OR_NULL(this_cpu_read(vector_irq[cfg->vector])))
this_cpu_write(vector_irq[cfg->vector], VECTOR_RETRIGGERED);

Thanks,

tglx

[GIT PULL] SCSI fixes for 5.10-rc7

[James Bottomley]

Five small fixes: four in drivers: hisi_sas: fix internal queue
timeout, be2iscsi: revert a prior fix causing problems, bnx2i: add
missing dependency, storvsc: late arriving revert of a problem fix, and
one in the core.  The core one is a minor change to stop paying
attention to the busy count when returning out of resources because
there's a race window where the queue might not restart due to missing
returning I/O.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Andrea Parri (Microsoft) (1):
  Revert "scsi: storvsc: Validate length of incoming packet in 
storvsc_on_channel_callback()"

Dan Carpenter (1):
  scsi: be2iscsi: Revert "Fix a theoretical leak in beiscsi_create_eqs()"

Ming Lei (1):
  scsi: core: Fix race between handling STS_RESOURCE and completion

Randy Dunlap (1):
  scsi: bnx2i: Requires MMU

Xiang Chen (1):
  scsi: hisi_sas: Select a suitable queue for internal I/Os

And the diffstat:

 drivers/scsi/be2iscsi/be_main.c| 4 ++--
 drivers/scsi/bnx2i/Kconfig | 1 +
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 6 ++
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 5 +
 drivers/scsi/scsi_lib.c| 3 +--
 drivers/scsi/storvsc_drv.c | 5 -
 6 files changed, 15 insertions(+), 9 deletions(-)

With full diff below.

James

---

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 202ba925c494..5c3513a4b450 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -3020,7 +3020,6 @@ static int beiscsi_create_eqs(struct beiscsi_hba *phba,
goto create_eq_error;
}
 
-   mem->dma = paddr;
mem->va = eq_vaddress;
ret = be_fill_queue(eq, phba->params.num_eq_entries,
sizeof(struct be_eq_entry), eq_vaddress);
@@ -3030,6 +3029,7 @@ static int beiscsi_create_eqs(struct beiscsi_hba *phba,
goto create_eq_error;
}
 
+   mem->dma = paddr;
ret = beiscsi_cmd_eq_create(>ctrl, eq,
BEISCSI_EQ_DELAY_DEF);
if (ret) {
@@ -3086,7 +3086,6 @@ static int beiscsi_create_cqs(struct beiscsi_hba *phba,
goto create_cq_error;
}
 
-   mem->dma = paddr;
ret = be_fill_queue(cq, phba->params.num_cq_entries,
sizeof(struct sol_cqe), cq_vaddress);
if (ret) {
@@ -3096,6 +3095,7 @@ static int beiscsi_create_cqs(struct beiscsi_hba *phba,
goto create_cq_error;
}
 
+   mem->dma = paddr;
ret = beiscsi_cmd_cq_create(>ctrl, cq, eq, false,
false, 0);
if (ret) {
diff --git a/drivers/scsi/bnx2i/Kconfig b/drivers/scsi/bnx2i/Kconfig
index 75ace2302fed..0cc06c2ce0b8 100644
--- a/drivers/scsi/bnx2i/Kconfig
+++ b/drivers/scsi/bnx2i/Kconfig
@@ -4,6 +4,7 @@ config SCSI_BNX2_ISCSI
depends on NET
depends on PCI
depends on (IPV6 || IPV6=n)
+   depends on MMU
select SCSI_ISCSI_ATTRS
select NETDEVICES
select ETHERNET
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index c8dd8588f800..274ccf18ce2d 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -452,6 +452,12 @@ static int hisi_sas_task_prep(struct sas_task *task,
blk_tag = blk_mq_unique_tag(scmd->request);
dq_index = blk_mq_unique_tag_to_hwq(blk_tag);
*dq_pointer = dq = _hba->dq[dq_index];
+   } else if (hisi_hba->shost->nr_hw_queues)  {
+   struct Scsi_Host *shost = hisi_hba->shost;
+   struct blk_mq_queue_map *qmap = 
>tag_set.map[HCTX_TYPE_DEFAULT];
+   int queue = qmap->mq_map[raw_smp_processor_id()];
+
+   *dq_pointer = dq = _hba->dq[queue];
} else {
*dq_pointer = dq = sas_dev->dq;
}
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 7133ca859b5e..960de375ce69 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -2452,6 +2452,11 @@ static int interrupt_init_v3_hw(struct hisi_hba 
*hisi_hba)
rc = -ENOENT;
goto free_irq_vectors;
}
+   cq->irq_mask = pci_irq_get_affinity(pdev, i + 
BASE_VECTORS_V3_HW);
+   if (!cq->irq_mask) {
+   dev_err(dev, "could not get cq%d irq affinity!\n", i);
+   return -ENOENT;
+   }
}
 
return 0;
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 

Re: [PATCH v10 2/4] phy: Add ethernet serdes configuration option

[Andrew Lunn]

On Fri, Dec 11, 2020 at 10:05:39AM +0100, Steen Hegelund wrote:
> Provide a new ethernet phy configuration structure, that
> allow PHYs used for ethernet to be configured with
> speed, media type and clock information.
> 
> Signed-off-by: Lars Povlsen 
> Signed-off-by: Steen Hegelund 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH v10 1/4] dt-bindings: phy: Add sparx5-serdes bindings

[Andrew Lunn]

On Fri, Dec 11, 2020 at 10:05:38AM +0100, Steen Hegelund wrote:
> Document the Sparx5 ethernet serdes phy driver bindings.
> 
> Signed-off-by: Lars Povlsen 
> Signed-off-by: Steen Hegelund 
> Reviewed-by: Rob Herring 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH v9 5/8] IMA: limit critical data measurement based on a label

[Tyler Hicks]

On 2020-12-12 10:02:48, Tushar Sugandhi wrote:
> System administrators should be able to limit which kernel subsystems
> they want to measure the critical data for. To enable that, an IMA policy
> condition to choose specific kernel subsystems is needed. This policy
> condition would constrain the measurement of the critical data based on
> a label for the given subsystems.
> 
> Add a new IMA policy condition - "data_source:=" to the IMA func
> CRITICAL_DATA to allow measurement of various kernel subsystems. This
> policy condition would enable the system administrators to restrict the
> measurement to the labels listed in "data_source:=".
> 
> Limit the measurement to the labels that are specified in the IMA
> policy - CRITICAL_DATA+"data_source:=". If "data_sources:=" is not
> provided with the func CRITICAL_DATA, the data from all the
> supported kernel subsystems is measured.
> 
> Signed-off-by: Tushar Sugandhi 

Reviewed-by: Tyler Hicks 

Tyler

> ---
>  Documentation/ABI/testing/ima_policy |  2 ++
>  security/integrity/ima/ima_policy.c  | 37 +---
>  2 files changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/ima_policy 
> b/Documentation/ABI/testing/ima_policy
> index 6ec7daa87cba..0f4ee9e0a455 100644
> --- a/Documentation/ABI/testing/ima_policy
> +++ b/Documentation/ABI/testing/ima_policy
> @@ -52,6 +52,8 @@ Description:
>   template:= name of a defined IMA template type
>   (eg, ima-ng). Only valid when action is "measure".
>   pcr:= decimal value
> + data_source:= [label]
> + label:= a unique string used for grouping and limiting 
> critical data.
>  
> default policy:
>   # PROC_SUPER_MAGIC
> diff --git a/security/integrity/ima/ima_policy.c 
> b/security/integrity/ima/ima_policy.c
> index d45c2dbb6d45..fea996a9e26c 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -34,6 +34,7 @@
>  #define IMA_PCR  0x0100
>  #define IMA_FSNAME   0x0200
>  #define IMA_KEYRINGS 0x0400
> +#define IMA_DATA_SOURCE  0x0800
>  
>  #define UNKNOWN  0
>  #define MEASURE  0x0001  /* same as IMA_MEASURE */
> @@ -85,6 +86,7 @@ struct ima_rule_entry {
>   } lsm[MAX_LSM_RULES];
>   char *fsname;
>   struct ima_rule_opt_list *keyrings; /* Measure keys added to these 
> keyrings */
> + struct ima_rule_opt_list *data_source; /* Measure data from this source 
> */
>   struct ima_template_desc *template;
>  };
>  
> @@ -480,7 +482,11 @@ static bool ima_match_rule_data(struct ima_rule_entry 
> *rule,
>   opt_list = rule->keyrings;
>   break;
>   case CRITICAL_DATA:
> - return true;
> + if (!rule->data_source)
> + return true;
> +
> + opt_list = rule->data_source;
> + break;
>   default:
>   return false;
>   }
> @@ -925,7 +931,7 @@ enum {
>   Opt_uid_lt, Opt_euid_lt, Opt_fowner_lt,
>   Opt_appraise_type, Opt_appraise_flag,
>   Opt_permit_directio, Opt_pcr, Opt_template, Opt_keyrings,
> - Opt_err
> + Opt_data_source, Opt_err
>  };
>  
>  static const match_table_t policy_tokens = {
> @@ -962,6 +968,7 @@ static const match_table_t policy_tokens = {
>   {Opt_pcr, "pcr=%s"},
>   {Opt_template, "template=%s"},
>   {Opt_keyrings, "keyrings=%s"},
> + {Opt_data_source, "data_source=%s"},
>   {Opt_err, NULL}
>  };
>  
> @@ -1129,7 +1136,8 @@ static bool ima_validate_rule(struct ima_rule_entry 
> *entry)
>   if (entry->action & ~(MEASURE | DONT_MEASURE))
>   return false;
>  
> - if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR))
> + if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
> +  IMA_DATA_SOURCE))
>   return false;
>  
>   if (ima_rule_contains_lsm_cond(entry))
> @@ -1339,6 +1347,23 @@ static int ima_parse_rule(char *rule, struct 
> ima_rule_entry *entry)
>  
>   entry->flags |= IMA_KEYRINGS;
>   break;
> + case Opt_data_source:
> + ima_log_string(ab, "data_source", args[0].from);
> +
> + if (entry->data_source) {
> + result = -EINVAL;
> + break;
> + }
> +
> + entry->data_source = ima_alloc_rule_opt_list(args);
> + if (IS_ERR(entry->data_source)) {
> + result = PTR_ERR(entry->data_source);
> + entry->data_source = NULL;
> + break;
> + }
> +
> + entry->flags |= IMA_DATA_SOURCE;
> + break;
>   case 

Re: [PATCH v9 4/8] IMA: add policy rule to measure critical data

[Tyler Hicks]

On 2020-12-12 10:02:47, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows the action. The
> policy rule should also support the necessary constraints (flags etc.)
> for integrity critical buffer data measurements.
> 
> Add a policy rule to define the constraints for restricting integrity
> critical data measurements.
> 
> Signed-off-by: Tushar Sugandhi 

This looks nice. Thanks for the changes!

Reviewed-by: Tyler Hicks 

Tyler

> ---
>  Documentation/ABI/testing/ima_policy |  2 +-
>  security/integrity/ima/ima_policy.c  | 29 
>  2 files changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/ima_policy 
> b/Documentation/ABI/testing/ima_policy
> index e35263f97fc1..6ec7daa87cba 100644
> --- a/Documentation/ABI/testing/ima_policy
> +++ b/Documentation/ABI/testing/ima_policy
> @@ -32,7 +32,7 @@ Description:
>   func:= 
> [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK]MODULE_CHECK]
>   [FIRMWARE_CHECK]
>   [KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
> - [KEXEC_CMDLINE] [KEY_CHECK]
> + [KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
>   mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
>  [[^]MAY_EXEC]
>   fsmagic:= hex value
> diff --git a/security/integrity/ima/ima_policy.c 
> b/security/integrity/ima/ima_policy.c
> index a09d1a41a290..d45c2dbb6d45 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -479,6 +479,8 @@ static bool ima_match_rule_data(struct ima_rule_entry 
> *rule,
>  
>   opt_list = rule->keyrings;
>   break;
> + case CRITICAL_DATA:
> + return true;
>   default:
>   return false;
>   }
> @@ -515,13 +517,19 @@ static bool ima_match_rules(struct ima_rule_entry 
> *rule, struct inode *inode,
>  {
>   int i;
>  
> - if (func == KEY_CHECK) {
> - return (rule->flags & IMA_FUNC) && (rule->func == func) &&
> - ima_match_rule_data(rule, func_data, cred);
> - }
>   if ((rule->flags & IMA_FUNC) &&
>   (rule->func != func && func != POST_SETATTR))
>   return false;
> +
> + switch (func) {
> + case KEY_CHECK:
> + case CRITICAL_DATA:
> + return ((rule->func == func) &&
> + ima_match_rule_data(rule, func_data, cred));
> + default:
> + break;
> + }
> +
>   if ((rule->flags & IMA_MASK) &&
>   (rule->mask != mask && func != POST_SETATTR))
>   return false;
> @@ -1116,6 +1124,17 @@ static bool ima_validate_rule(struct ima_rule_entry 
> *entry)
>   if (ima_rule_contains_lsm_cond(entry))
>   return false;
>  
> + break;
> + case CRITICAL_DATA:
> + if (entry->action & ~(MEASURE | DONT_MEASURE))
> + return false;
> +
> + if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR))
> + return false;
> +
> + if (ima_rule_contains_lsm_cond(entry))
> + return false;
> +
>   break;
>   default:
>   return false;
> @@ -1248,6 +1267,8 @@ static int ima_parse_rule(char *rule, struct 
> ima_rule_entry *entry)
>   else if (IS_ENABLED(CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS) 
> &&
>strcmp(args[0].from, "KEY_CHECK") == 0)
>   entry->func = KEY_CHECK;
> + else if (strcmp(args[0].from, "CRITICAL_DATA") == 0)
> + entry->func = CRITICAL_DATA;
>   else
>   result = -EINVAL;
>   if (!result)
> -- 
> 2.17.1
> 

Re: [PATCH -next] platform: surface: fix non-PM_SLEEP build warnings

[Andy Shevchenko]

On Sat, Dec 12, 2020 at 7:05 PM Randy Dunlap  wrote:
> On 12/12/20 5:24 AM, Andy Shevchenko wrote:
> > On Fri, Dec 11, 2020 at 9:20 PM Randy Dunlap  wrote:

...

> >> +#ifdef CONFIG_PM_SLEEP
> >>  static int surface_gpe_suspend(struct device *dev)
> >
> > Perhaps __maybe_unused ?
>
> Yes, I am aware of that option.
> I don't know why it would be preferred though.

Here [1] is the rationale behind annotation vs. ifdeffery.

[1]: https://lore.kernel.org/patchwork/patch/732981/

-- 
With Best Regards,
Andy Shevchenko

Re: [net-next PATCH] tcp: Add logic to check for SYN w/ data in tcp_simple_retransmit

[Yuchung Cheng]

On Sat, Dec 12, 2020 at 11:01 AM Alexander Duyck
 wrote:
>
> On Sat, Dec 12, 2020 at 10:34 AM Yuchung Cheng  wrote:
> >
> > On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
> >  wrote:
> > >
> > > From: Alexander Duyck 
> > >
> > > There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
> > > message in the case of IPv6 or a fragmentation request in the case of
> > > IPv4. This results in the socket stalling for a second or more as it does
> > > not respond to the message by retransmitting the SYN frame.
> > >
> > > Normally a SYN frame should not be able to trigger a ICMP_TOOBIG or
> > > ICMP_FRAG_NEEDED however in the case of fastopen we can have a frame that
> > > makes use of the entire MSS. In the case of fastopen it does, and an
> > > additional complication is that the retransmit queue doesn't contain the
> > > original frames. As a result when tcp_simple_retransmit is called and
> > > walks the list of frames in the queue it may not mark the frames as lost
> > > because both the SYN and the data packet each individually are smaller 
> > > than
> > > the MSS size after the adjustment. This results in the socket being 
> > > stalled
> > > until the retransmit timer kicks in and forces the SYN frame out again
> > > without the data attached.
> > >
> > > In order to resolve this we can generate our best estimate for the 
> > > original
> > > packet size by detecting the fastopen SYN frame and then adding the
> > > overhead for MAX_TCP_OPTION_SPACE and verifying if the SYN w/ data would
> > > have exceeded the MSS. If so we can mark the frame as lost and retransmit
> > > it.
> > >
> > > Signed-off-by: Alexander Duyck 
> > > ---
> > >  net/ipv4/tcp_input.c |   30 +++---
> > >  1 file changed, 27 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > > index 9e8a6c1aa019..79375b58de84 100644
> > > --- a/net/ipv4/tcp_input.c
> > > +++ b/net/ipv4/tcp_input.c
> > > @@ -2686,11 +2686,35 @@ static void tcp_mtup_probe_success(struct sock 
> > > *sk)
> > >  void tcp_simple_retransmit(struct sock *sk)
> > >  {
> > > const struct inet_connection_sock *icsk = inet_csk(sk);
> > > +   struct sk_buff *skb = tcp_rtx_queue_head(sk);
> > > struct tcp_sock *tp = tcp_sk(sk);
> > > -   struct sk_buff *skb;
> > > -   unsigned int mss = tcp_current_mss(sk);
> > > +   unsigned int mss;
> > > +
> > > +   /* A fastopen SYN request is stored as two separate packets within
> > > +* the retransmit queue, this is done by tcp_send_syn_data().
> > > +* As a result simply checking the MSS of the frames in the queue
> > > +* will not work for the SYN packet. So instead we must make a 
> > > best
> > > +* effort attempt by validating the data frame with the mss size
> > > +* that would be computed now by tcp_send_syn_data and comparing
> > > +* that against the data frame that would have been included with
> > > +* the SYN.
> > > +*/
> > > +   if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_SYN && tp->syn_data) {
> > > +   struct sk_buff *syn_data = skb_rb_next(skb);
> > > +
> > > +   mss = tcp_mtu_to_mss(sk, icsk->icsk_pmtu_cookie) +
> > > + tp->tcp_header_len - sizeof(struct tcphdr) -
> > > + MAX_TCP_OPTION_SPACE;
> > nice comment! The original syn_data mss needs to be inferred which is
> > a hassle to get right. my sense is path-mtu issue is enough to warrant
> > they are lost.
> > I suggest simply mark syn & its data lost if tcp_simple_retransmit is
> > called during TFO handshake, i.e.
> >
> > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > index 62f7aabc7920..7f0c4f2947eb 100644
> > --- a/net/ipv4/tcp_input.c
> > +++ b/net/ipv4/tcp_input.c
> > @@ -2864,7 +2864,8 @@ void tcp_simple_retransmit(struct sock *sk)
> > unsigned int mss = tcp_current_mss(sk);
> >
> > skb_rbtree_walk(skb, >tcp_rtx_queue) {
> > -   if (tcp_skb_seglen(skb) > mss)
> > +   if (tcp_skb_seglen(skb) > mss ||
> > +   (tp->syn_data && sk->sk_state == TCP_SYN_SENT))
> > tcp_mark_skb_lost(sk, skb);
> > }
> >
> > We have a TFO packetdrill test that verifies my suggested fix should
> > trigger an immediate retransmit vs 1s wait.
>
> Okay, I will go that route, although I will still probably make one
> minor cleanup. Instead of testing for syn_data and state per packet I
> will probably keep the bit where I overwrite mss since it is only used
> in the loop. What I can do is switch it from unsigned int to int since
> technically tcp_current_mss and tcp_skb_seglen are both a signed int
> anyway. Then I can just set mss to -1 in the syn_data && TCP_SYN_SENT
> case. That way all of the frames in the ring should fail the check
> while only having to add one initial check outside the loop.
sounds good. I thought about that too but 

Re: [git pull] Input updates for v5.10-rc7

[pr-tracker-bot]

The pull request you sent on Fri, 11 Dec 2020 19:13:21 -0800:

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

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

Thank you!

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

Re: [GIT PULL] Final batch of KVM changes for Linux 5.10

[pr-tracker-bot]

The pull request you sent on Sat, 12 Dec 2020 10:53:42 -0500:

> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

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

Thank you!

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

Re: [GIT PULL] xen: branch for v5.10-rc8

[pr-tracker-bot]

The pull request you sent on Fri, 11 Dec 2020 09:53:09 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
> for-linus-5.10c-rc8-tag

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

Thank you!

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

Re: [GIT PULL] RISC-V Fixes for 5.10 (unless there's an rc8)

[pr-tracker-bot]

The pull request you sent on Fri, 11 Dec 2020 13:41:44 -0800 (PST):

> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
> tags/riscv-for-linus-5.10-rc8

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

Thank you!

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

Re: [net-next PATCH] tcp: Add logic to check for SYN w/ data in tcp_simple_retransmit

[Alexander Duyck]

On Sat, Dec 12, 2020 at 10:34 AM Yuchung Cheng  wrote:
>
> On Fri, Dec 11, 2020 at 5:28 PM Alexander Duyck
>  wrote:
> >
> > From: Alexander Duyck 
> >
> > There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
> > message in the case of IPv6 or a fragmentation request in the case of
> > IPv4. This results in the socket stalling for a second or more as it does
> > not respond to the message by retransmitting the SYN frame.
> >
> > Normally a SYN frame should not be able to trigger a ICMP_TOOBIG or
> > ICMP_FRAG_NEEDED however in the case of fastopen we can have a frame that
> > makes use of the entire MSS. In the case of fastopen it does, and an
> > additional complication is that the retransmit queue doesn't contain the
> > original frames. As a result when tcp_simple_retransmit is called and
> > walks the list of frames in the queue it may not mark the frames as lost
> > because both the SYN and the data packet each individually are smaller than
> > the MSS size after the adjustment. This results in the socket being stalled
> > until the retransmit timer kicks in and forces the SYN frame out again
> > without the data attached.
> >
> > In order to resolve this we can generate our best estimate for the original
> > packet size by detecting the fastopen SYN frame and then adding the
> > overhead for MAX_TCP_OPTION_SPACE and verifying if the SYN w/ data would
> > have exceeded the MSS. If so we can mark the frame as lost and retransmit
> > it.
> >
> > Signed-off-by: Alexander Duyck 
> > ---
> >  net/ipv4/tcp_input.c |   30 +++---
> >  1 file changed, 27 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > index 9e8a6c1aa019..79375b58de84 100644
> > --- a/net/ipv4/tcp_input.c
> > +++ b/net/ipv4/tcp_input.c
> > @@ -2686,11 +2686,35 @@ static void tcp_mtup_probe_success(struct sock *sk)
> >  void tcp_simple_retransmit(struct sock *sk)
> >  {
> > const struct inet_connection_sock *icsk = inet_csk(sk);
> > +   struct sk_buff *skb = tcp_rtx_queue_head(sk);
> > struct tcp_sock *tp = tcp_sk(sk);
> > -   struct sk_buff *skb;
> > -   unsigned int mss = tcp_current_mss(sk);
> > +   unsigned int mss;
> > +
> > +   /* A fastopen SYN request is stored as two separate packets within
> > +* the retransmit queue, this is done by tcp_send_syn_data().
> > +* As a result simply checking the MSS of the frames in the queue
> > +* will not work for the SYN packet. So instead we must make a best
> > +* effort attempt by validating the data frame with the mss size
> > +* that would be computed now by tcp_send_syn_data and comparing
> > +* that against the data frame that would have been included with
> > +* the SYN.
> > +*/
> > +   if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_SYN && tp->syn_data) {
> > +   struct sk_buff *syn_data = skb_rb_next(skb);
> > +
> > +   mss = tcp_mtu_to_mss(sk, icsk->icsk_pmtu_cookie) +
> > + tp->tcp_header_len - sizeof(struct tcphdr) -
> > + MAX_TCP_OPTION_SPACE;
> nice comment! The original syn_data mss needs to be inferred which is
> a hassle to get right. my sense is path-mtu issue is enough to warrant
> they are lost.
> I suggest simply mark syn & its data lost if tcp_simple_retransmit is
> called during TFO handshake, i.e.
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 62f7aabc7920..7f0c4f2947eb 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -2864,7 +2864,8 @@ void tcp_simple_retransmit(struct sock *sk)
> unsigned int mss = tcp_current_mss(sk);
>
> skb_rbtree_walk(skb, >tcp_rtx_queue) {
> -   if (tcp_skb_seglen(skb) > mss)
> +   if (tcp_skb_seglen(skb) > mss ||
> +   (tp->syn_data && sk->sk_state == TCP_SYN_SENT))
> tcp_mark_skb_lost(sk, skb);
> }
>
> We have a TFO packetdrill test that verifies my suggested fix should
> trigger an immediate retransmit vs 1s wait.

Okay, I will go that route, although I will still probably make one
minor cleanup. Instead of testing for syn_data and state per packet I
will probably keep the bit where I overwrite mss since it is only used
in the loop. What I can do is switch it from unsigned int to int since
technically tcp_current_mss and tcp_skb_seglen are both a signed int
anyway. Then I can just set mss to -1 in the syn_data && TCP_SYN_SENT
case. That way all of the frames in the ring should fail the check
while only having to add one initial check outside the loop.

[PATCH 2/9] KVM: arm64: Fix KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION read

[Eric Auger]

The doc says:
"The characteristics of a specific redistributor region can
 be read by presetting the index field in the attr data.
 Only valid for KVM_DEV_TYPE_ARM_VGIC_V3"

Unfortunately the existing code fails to read the input attr data
and thus the index always is 0.

Fixes: 04c110932225 ("KVM: arm/arm64: Implement 
KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION")
Cc: sta...@vger.kernel.org#v4.17+
Signed-off-by: Eric Auger 
---
 arch/arm64/kvm/vgic/vgic-kvm-device.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c 
b/arch/arm64/kvm/vgic/vgic-kvm-device.c
index 44419679f91a..2f66cf247282 100644
--- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
+++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
@@ -226,6 +226,9 @@ static int vgic_get_common_attr(struct kvm_device *dev,
u64 addr;
unsigned long type = (unsigned long)attr->attr;
 
+   if (copy_from_user(, uaddr, sizeof(addr)))
+   return -EFAULT;
+
r = kvm_vgic_addr(dev->kvm, type, , false);
if (r)
return (r == -ENODEV) ? -ENXIO : r;
-- 
2.21.3

[PATCH 1/9] KVM: arm64: vgic-v3: Fix some error codes when setting RDIST base

[Eric Auger]

KVM_DEV_ARM_VGIC_GRP_ADDR group doc says we should return
-EEXIST in case the base address of the redist is already set.
We currently return -EINVAL.

However we need to return -EINVAL in case a legacy REDIST address
is attempted to be set while REDIST_REGIONS were set. This case
is discriminated by looking at the count field.

Signed-off-by: Eric Auger 
---
 arch/arm64/kvm/vgic/vgic-mmio-v3.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c 
b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 15a6c98ee92f..8e8a862def76 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -792,8 +792,13 @@ static int vgic_v3_insert_redist_region(struct kvm *kvm, 
uint32_t index,
int ret;
 
/* single rdist region already set ?*/
-   if (!count && !list_empty(rd_regions))
-   return -EINVAL;
+   if (!count && !list_empty(rd_regions)) {
+   rdreg = list_last_entry(rd_regions,
+  struct vgic_redist_region, list);
+   if (rdreg->count)
+   return -EINVAL; /* Mixing REDIST and REDIST_REGION API 
*/
+   return -EEXIST;
+   }
 
/* cross the end of memory ? */
if (base + size < base)
-- 
2.21.3

Re: [PATCH] lib/find_bit_bench: fix the unmatched iterations cnt

[Yury Norov]

On Fri, Dec 11, 2020 at 4:09 PM Yun Levi  wrote:
>
> > I didn't understand why is so (I mean "same", I think you rather talking 
> > about
> > same order of amount of itterations).
>
> Yes. That's what I want to talk about. Thanks!
>
> > Can you provide before and after to compare?
>
> I tested when the bitmap's 0 bit is set only. and below are before and
> after results.
>
> before:
>   Start testing find_bit() with random-filled bitmap
> [  +0.000481] find_next_bit:8966 ns,  2 iterations
> [  +0.001739] find_next_zero_bit:1726335 ns, 327679 iterations
> [  +0.20] find_last_bit:7428 ns,  1 iterations
> [  +0.17] find_first_bit:   5523 ns,  2 iterations
> [  +0.22] find_next_and_bit:9643 ns,  1 iterations
> [  +0.07]
>   Start testing find_bit() with sparse bitmap
> [  +0.41] find_next_bit:   16343 ns,656 iterations
> [  +0.001943] find_next_zero_bit:1928324 ns, 327025 iterations
> [  +0.29] find_last_bit:   14398 ns,656 iterations
> [  +0.000725] find_first_bit: 711383 ns,656 iterations
> [  +0.22] find_next_and_bit:9581 ns,  1 iterations
>
> after:
> [Dec12 08:25]
>   Start testing find_bit() with random-filled bitmap
> [  +0.000687] find_next_bit:   11079 ns,  1 iterations
> [  +0.002156] find_next_zero_bit:2055752 ns, 327679 iterations
> [  +0.22] find_last_bit:8052 ns,  1 iterations
> [  +0.20] find_first_bit:   6270 ns,  1 iterations
> [  +0.24] find_next_and_bit:9519 ns,  0 iterations
> [  +0.07]
>   Start testing find_bit() with sparse bitmap
> [  +0.47] find_next_bit:   18389 ns,655 iterations
> [  +0.001807] find_next_zero_bit:1793314 ns, 327025 iterations
> [  +0.27] find_last_bit:   13600 ns,655 iterations
> [  +0.000604] find_first_bit: 591173 ns,655 iterations
> [  +0.23] find_next_and_bit:9392 ns,  0 iterations

> find_next_and_bit:9392 ns,  0 iterations

This is definitely wrong. The test simply says that it has parsed the bitmap
without actually parsing it. Bollocks.

> >I think it's not that important, because the difference is not measurable.
> > But if this part raises questions, I have nothing against aligning numbers.
> Right it's not that important, But if the amount of iteration value is
> not same to the same bitmap,
> makes people confused when they run the test cases. so I just fix.

Can you please welcome those people to join the discussion? What exactly
confuses them? What is their usecase? Will they be satisfied if we add
the comment pointing that we count _iterations_, not number of bits?

> > What for this check against ++cnt? I doubt that the counter can overflow.
> This test case suppose the bitmap size is 327680 (4096UL * 8 * 10)
> So I think there is no case that the counter can overflow in the testcase.
>
> >> time = ktime_get() - time;
> >> pr_err("find_first_bit: %18llu ns, %6ld\n", time, cnt);
> > Why this?
> Sorry, I don't catch what you are saying.
> Could you tell me in detail?

This change adds useless check against overflow on each iteration.
Except that, nothing is changed. We don't need this change, right?

> > Can you please confirm that for bitmap 0001,
> > test_find_{first,next,next_and}_bit reports cnt == 0, and
> > test_find_last_bit() reports 1?
> This happens because "test_find_first_bit" calls __clear_bit
> in case of bitmap 0001 (only 0 bit set), the test_find_first_bit will
> clear the 0 bit
> that makes no match with bitmap2 so it reports 0.
>
> In the view we need to call the find_last_bit or find_next_bit to know
> bitmap is empty so cnt should be the 1 in that case,
> I think it possible by initializing cnt as 1.

Again, we count iterations, not the number of set bits. If you are able to
demonstrate that this test counts iterations wrongly, I'll happily
accept the fix.
Otherwise NACK.

Yury

> > Do you experience the same problem with find_next_and_bit() as well?
> Nope, But compared to other test cases, I think it's better to
> integrate their format.
> Should I sustain the former one?
>
> On Sat, Dec 12, 2020 at 2:20 AM Yury Norov  wrote:
> >
> > On Fri, Dec 11, 2020 at 12:50 AM Levi Yun  wrote:
> > >
> > > We should have same iteration count when we walk the same bitmap
> > > regardless of using find_next_bit or find_last_b
> >
> > I think it's not that important, because the difference is not measurable.
> > But if this part raises questions, I have nothing against aligning numbers.
> >
> > > When we run the find_bit_benchmark.ko, we sometime get
> > > unmatched iterations count below:
> > >
> > >  Start testing 

[PATCH 5/9] KVM: arm: move has_run_once after the map_resources

[Eric Auger]

has_run_once is set to true at the beginning of
kvm_vcpu_first_run_init(). This generally is not an issue
except when exercising the code with KVM selftests. Indeed,
if kvm_vgic_map_resources() fails due to erroneous user settings,
has_run_once is set and this prevents from continuing
executing the test. This patch moves the assignment after the
kvm_vgic_map_resources().

Signed-off-by: Eric Auger 
---
 arch/arm64/kvm/arm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index c0ffb019ca8b..331fae6bff31 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -540,8 +540,6 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
if (!kvm_arm_vcpu_is_finalized(vcpu))
return -EPERM;
 
-   vcpu->arch.has_run_once = true;
-
if (likely(irqchip_in_kernel(kvm))) {
/*
 * Map the VGIC hardware resources before running a vcpu the
@@ -560,6 +558,8 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
static_branch_inc(_irqchip_in_use);
}
 
+   vcpu->arch.has_run_once = true;
+
ret = kvm_timer_enable(vcpu);
if (ret)
return ret;
-- 
2.21.3

[PATCH 7/9] KVM: arm64: Simplify argument passing to vgic_uaccess_[read|write]

[Eric Auger]

Instead of converting the vgic_io_device handle to a kvm_io_device
handled and then do the oppositive, pass a vgic_io_device pointer all
along the call chain.

Signed-off-by: Eric Auger 
---
 arch/arm64/kvm/vgic/vgic-mmio.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
index b2d73fc0d1ef..48c6067fc5ec 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio.c
@@ -938,10 +938,9 @@ vgic_get_mmio_region(struct kvm_vcpu *vcpu, struct 
vgic_io_device *iodev,
return region;
 }
 
-static int vgic_uaccess_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
+static int vgic_uaccess_read(struct kvm_vcpu *vcpu, struct vgic_io_device 
*iodev,
 gpa_t addr, u32 *val)
 {
-   struct vgic_io_device *iodev = kvm_to_vgic_iodev(dev);
const struct vgic_register_region *region;
struct kvm_vcpu *r_vcpu;
 
@@ -960,10 +959,9 @@ static int vgic_uaccess_read(struct kvm_vcpu *vcpu, struct 
kvm_io_device *dev,
return 0;
 }
 
-static int vgic_uaccess_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
+static int vgic_uaccess_write(struct kvm_vcpu *vcpu, struct vgic_io_device 
*iodev,
  gpa_t addr, const u32 *val)
 {
-   struct vgic_io_device *iodev = kvm_to_vgic_iodev(dev);
const struct vgic_register_region *region;
struct kvm_vcpu *r_vcpu;
 
@@ -986,9 +984,9 @@ int vgic_uaccess(struct kvm_vcpu *vcpu, struct 
vgic_io_device *dev,
 bool is_write, int offset, u32 *val)
 {
if (is_write)
-   return vgic_uaccess_write(vcpu, >dev, offset, val);
+   return vgic_uaccess_write(vcpu, dev, offset, val);
else
-   return vgic_uaccess_read(vcpu, >dev, offset, val);
+   return vgic_uaccess_read(vcpu, dev, offset, val);
 }
 
 static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
-- 
2.21.3

[PATCH 8/9] KVM: arm64: vgic-v3: Expose GICR_TYPER.Last for userspace

[Eric Auger]

Commit 23bde34771f1 ("KVM: arm64: vgic-v3: Drop the
reporting of GICR_TYPER.Last for userspace") temporarily fixed
a bug identified when attempting to access the GICR_TYPER
register before the redistributor region setting but dropped
the support of the LAST bit. This patch restores its
support (if the redistributor region was set) while keeping the
code safe.

Signed-off-by: Eric Auger 
---
 arch/arm64/kvm/vgic/vgic-mmio-v3.c | 7 ++-
 include/kvm/arm_vgic.h | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c 
b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 581f0f49..2f9ef6058f6e 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -277,6 +277,8 @@ static unsigned long vgic_uaccess_read_v3r_typer(struct 
kvm_vcpu *vcpu,
 gpa_t addr, unsigned int len)
 {
unsigned long mpidr = kvm_vcpu_get_mpidr_aff(vcpu);
+   struct vgic_cpu *vgic_cpu = >arch.vgic_cpu;
+   struct vgic_redist_region *rdreg = vgic_cpu->rdreg;
int target_vcpu_id = vcpu->vcpu_id;
u64 value;
 
@@ -286,7 +288,9 @@ static unsigned long vgic_uaccess_read_v3r_typer(struct 
kvm_vcpu *vcpu,
if (vgic_has_its(vcpu->kvm))
value |= GICR_TYPER_PLPIS;
 
-   /* reporting of the Last bit is not supported for userspace */
+   if (rdreg && (vgic_cpu->rdreg_index == (rdreg->free_index - 1)))
+   value |= GICR_TYPER_LAST;
+
return extract_bytes(value, addr & 7, len);
 }
 
@@ -714,6 +718,7 @@ int vgic_register_redist_iodev(struct kvm_vcpu *vcpu)
return -EINVAL;
 
vgic_cpu->rdreg = rdreg;
+   vgic_cpu->rdreg_index = rdreg->free_index;
 
rd_base = rdreg->base + rdreg->free_index * KVM_VGIC_V3_REDIST_SIZE;
 
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index a8d8fdcd3723..596c069263a7 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -322,6 +322,7 @@ struct vgic_cpu {
 */
struct vgic_io_device   rd_iodev;
struct vgic_redist_region *rdreg;
+   u32 rdreg_index;
 
/* Contains the attributes and gpa of the LPI pending tables. */
u64 pendbaser;
-- 
2.21.3