[PATCH] PCI: hotplug: fix null-ptr-dereferencd in cpcihp error path

[Tong Zhang]

There is an issue in the error path, which cpci_thread may remain NULL.
Calling kthread_stop(cpci_thread) will trigger a BUG().
It is better to check whether the thread is really created and started
before stop it.

[1.292859] BUG: kernel NULL pointer dereference, address: 0028
[1.293252] #PF: supervisor write access in kernel mode
[1.293533] #PF: error_code(0x0002) - not-present page
[1.295163] RIP: 0010:kthread_stop+0x22/0x170
[1.300491] Call Trace:
[1.300628]  cpci_hp_unregister_controller+0xf6/0x130
[1.300906]  zt5550_hc_init_one+0x27a/0x27f [cpcihp_zt5550]

Signed-off-by: Tong Zhang 
---
 drivers/pci/hotplug/cpci_hotplug_core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/hotplug/cpci_hotplug_core.c 
b/drivers/pci/hotplug/cpci_hotplug_core.c
index d0559d2faf50..b44da397d631 100644
--- a/drivers/pci/hotplug/cpci_hotplug_core.c
+++ b/drivers/pci/hotplug/cpci_hotplug_core.c
@@ -47,7 +47,7 @@ static atomic_t extracting;
 int cpci_debug;
 static struct cpci_hp_controller *controller;
 static struct task_struct *cpci_thread;
-static int thread_finished;
+static int thread_started;
 
 static int enable_slot(struct hotplug_slot *slot);
 static int disable_slot(struct hotplug_slot *slot);
@@ -447,7 +447,7 @@ event_thread(void *data)
msleep(500);
} else if (rc < 0) {
dbg("%s - error checking slots", __func__);
-   thread_finished = 1;
+   thread_started = 0;
goto out;
}
} while (atomic_read() && !kthread_should_stop());
@@ -479,7 +479,7 @@ poll_thread(void *data)
msleep(500);
} else if (rc < 0) {
dbg("%s - error checking slots", 
__func__);
-   thread_finished = 1;
+   thread_started = 0;
goto out;
}
} while (atomic_read() && 
!kthread_should_stop());
@@ -501,7 +501,7 @@ cpci_start_thread(void)
err("Can't start up our thread");
return PTR_ERR(cpci_thread);
}
-   thread_finished = 0;
+   thread_started = 1;
return 0;
 }
 
@@ -509,7 +509,7 @@ static void
 cpci_stop_thread(void)
 {
kthread_stop(cpci_thread);
-   thread_finished = 1;
+   thread_started = 0;
 }
 
 int
@@ -571,7 +571,7 @@ cpci_hp_unregister_controller(struct cpci_hp_controller 
*old_controller)
int status = 0;
 
if (controller) {
-   if (!thread_finished)
+   if (thread_started)
cpci_stop_thread();
if (controller->irq)
free_irq(controller->irq, controller->dev_id);
-- 
2.25.1

Re: [PATCH] staging: vchiq: Typo fixes

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/sepecific/specific/
s/comonent/component/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c 
b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index 9097bcbd67d8..06bca7be5203 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -432,7 +432,7 @@ buffer_from_host(struct vchiq_mmal_instance *instance,
m.u.buffer_from_host.buffer_header.pts = MMAL_TIME_UNKNOWN;
m.u.buffer_from_host.buffer_header.dts = MMAL_TIME_UNKNOWN;

-   /* clear buffer type sepecific data */
+   /* clear buffer type specific data */
memset(_from_host.buffer_header_type_specific, 0,
   sizeof(m.u.buffer_from_host.buffer_header_type_specific));

@@ -927,7 +927,7 @@ static int port_info_get(struct vchiq_mmal_instance 
*instance,
return ret;
}

-/* create comonent on vc */
+/* create component on vc */
static int create_component(struct vchiq_mmal_instance *instance,
struct vchiq_mmal_component *component,
const char *name)
--
2.31.0

Re: [PATCH V2] device_cgroup: A typo fix

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/acessed/accessed/


Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 

although I still don't care for the $Subject.



---
Changes from V1:
 Getting rid of unwanted comment delimeter addition
 Subject line missed propper commit subject labeling

security/device_cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 04375df52fc9..30b3083276df 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -409,7 +409,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup,
} else {
/*
 * new exception in the child will add more devices
-* that can be acessed, so it can't match any of
+* that can be accessed, so it can't match any of
 * parent's exceptions, even slightly
 */
match = match_exception_partial(_cgroup->exceptions,
--
2.20.1

Re: [PATCH] security: A typo fix

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/programers/programmers/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
security/lsm_audit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/lsm_audit.c b/security/lsm_audit.c
index 82ce14933513..ddcf572105be 100644
--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c
@@ -212,7 +212,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
char comm[sizeof(current->comm)];

/*
-* To keep stack sizes in check force programers to notice if they
+* To keep stack sizes in check force programmers to notice if they
 * start making this union too large!  See struct lsm_network_audit
 * as an example of how to deal with large data.
 */
--
2.20.1

Re: [PATCH next v1 1/3] printk: track/limit recursion

[Sergey Senozhatsky]

On (21/03/17 00:33), John Ogness wrote:
[..]
>  static inline void printk_delay(void)
> @@ -2040,11 +2105,13 @@ int vprintk_store(int facility, int level,
>   struct prb_reserved_entry e;
>   enum log_flags lflags = 0;
>   struct printk_record r;
> + unsigned long irqflags;
>   u16 trunc_msg_len = 0;
>   char prefix_buf[8];
>   u16 reserve_size;
>   va_list args2;
>   u16 text_len;
> + int ret = 0;
>   u64 ts_nsec;
>  
>   /*
> @@ -2055,6 +2122,9 @@ int vprintk_store(int facility, int level,
>*/
>   ts_nsec = local_clock();
>  
> + if (!printk_enter_irqsave())
> + return 0;

I guess it can be interesting to somehow signal us that we had printk()
recursion overflow, and how many messages we lost.

3 levels of recursion seem like reasonable limit, but I maybe wouldn't
mind one extra level. And maybe we could add some sort of message prefix
for high levels of recursion nesting (levels 3+), so that things should
not be normal will be on the radars and, possibly, will be reported.

-ss

[PATCH] scsi: sym53c8xx_2: Fix WARN_ON in __sym_mfree_dma

[Tong Zhang]

This fix is similar to b36522150e5b. The WARN_ON is triggered due to
irq being disabled while dma_free_coherent expect it enabled.

[1.501363] WARNING: CPU: 0 PID: 179 at kernel/dma/mapping.c:467 
dma_free_attrs+0x38/0x50
[1.503940] RIP: 0010:dma_free_attrs+0x38/0x50
[1.509138] Call Trace:
[1.509273]  ___free_dma_mem_cluster+0x60/0x90 [sym53c8xx]
[1.509570]  __sym_mfree+0xb2/0xd0 [sym53c8xx]
[1.509811]  __sym_mfree_dma+0x65/0xa0 [sym53c8xx]
[1.510070]  sym_hcb_free+0x8b/0x1e0 [sym53c8xx]
[1.510320]  sym_free_resources+0x5c/0x7e [sym53c8xx]
[1.510592]  sym2_probe.cold+0x3e3/0x555 [sym53c8xx]

Signed-off-by: Tong Zhang 
---
 drivers/scsi/sym53c8xx_2/sym_malloc.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/scsi/sym53c8xx_2/sym_malloc.c 
b/drivers/scsi/sym53c8xx_2/sym_malloc.c
index eb5c045c7c59..54ec7e7bf87f 100644
--- a/drivers/scsi/sym53c8xx_2/sym_malloc.c
+++ b/drivers/scsi/sym53c8xx_2/sym_malloc.c
@@ -321,20 +321,16 @@ void *__sym_calloc_dma(m_pool_ident_t dev_dmat, int size, 
char *name)
 
 void __sym_mfree_dma(m_pool_ident_t dev_dmat, void *m, int size, char *name)
 {
-   unsigned long flags;
m_pool_p mp;
 
-   spin_lock_irqsave(_lock, flags);
mp = ___get_dma_pool(dev_dmat);
if (!mp)
-   goto out;
+   return;
__sym_mfree(mp, m, size, name);
 #ifdef SYM_MEM_FREE_UNUSED
if (!mp->nump)
___del_dma_pool(mp);
 #endif
- out:
-   spin_unlock_irqrestore(_lock, flags);
 }
 
 /*
-- 
2.25.1

Re: [PATCH next v1 2/3] printk: remove safe buffers

[Sergey Senozhatsky]

On (21/03/17 00:33), John Ogness wrote:
[..]
>  void printk_nmi_direct_enter(void)
>  {
> @@ -324,27 +44,8 @@ void printk_nmi_direct_exit(void)
>   this_cpu_and(printk_context, ~PRINTK_NMI_DIRECT_CONTEXT_MASK);
>  }
>  
> -#else
> -
> -static __printf(1, 0) int vprintk_nmi(const char *fmt, va_list args)
> -{
> - return 0;
> -}
> -
>  #endif /* CONFIG_PRINTK_NMI */
>  
> -/*
> - * Lock-less printk(), to avoid deadlocks should the printk() recurse
> - * into itself. It uses a per-CPU buffer to store the message, just like
> - * NMI.
> - */
> -static __printf(1, 0) int vprintk_safe(const char *fmt, va_list args)
> -{
> - struct printk_safe_seq_buf *s = this_cpu_ptr(_print_seq);
> -
> - return printk_safe_log_store(s, fmt, args);
> -}
> -
>  /* Can be preempted by NMI. */
>  void __printk_safe_enter(void)
>  {
> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const char *fmt, va_list 
> args)
>* Use the main logbuf even in NMI. But avoid calling console
>* drivers that might have their own locks.
>*/
> - if ((this_cpu_read(printk_context) & PRINTK_NMI_DIRECT_CONTEXT_MASK)) {
> + if (this_cpu_read(printk_context) &
> + (PRINTK_NMI_DIRECT_CONTEXT_MASK |
> +  PRINTK_NMI_CONTEXT_MASK |
> +  PRINTK_SAFE_CONTEXT_MASK)) {

Do we need printk_nmi_direct_enter/exit() and PRINTK_NMI_DIRECT_CONTEXT_MASK?
Seems like all printk_safe() paths are now DIRECT - we store messages to the
prb, but don't call console drivers.

-ss

Re: [PATCH v1 2/2] iio: temperature: add driver support for ti tmp117

[Lars-Peter Clausen]

On 3/21/21 6:07 AM, Lars-Peter Clausen wrote:

On 3/20/21 7:45 AM, Puranjay Mohan wrote:

TMP117 is a Digital temperature sensor with integrated NV memory.

Add support for tmp117 driver in iio subsystem.

Datasheet:-https://www.ti.com/lit/gpn/tmp117

Signed-off-by: Puranjay Mohan 


This looks good to me. Just two small bits I overlooked during the 
first review, sorry for that.



+};
+
[...]
+static int tmp117_read_raw(struct iio_dev *indio_dev,
+    struct iio_chan_spec const *channel, int *val,
+    int *val2, long mask)
+{
+    struct tmp117_data *data = iio_priv(indio_dev);
+    u16 tmp, off;
+
+    switch (mask) {
+    case IIO_CHAN_INFO_RAW:
+    tmp = tmp117_read_reg(data, TMP117_REG_TEMP);
+    *val = tmp;

No need for tmp here. Just directly assign to val.


Actually thinking about this, does the current implementation work 
correctly for negative temperatures?


I think there are two options to fix it. Either cast to s16 or use the 
sign_extend32() function.


Have a look at how the tmp006 driver handles this. It is a good example, 
including the error checking. In general you should check if your I2C 
read failed and return an error in that case rather than a bogus value 
for the measurement. Same for when reading the calibration offset.


Another thing. IIO reports temperature values in milli degrees Celsius. 
I believe in the current implementation the scale is so that it will 
report in degrees Celsius instead.

[GIT PULL] Please pull powerpc/linux.git powerpc-5.12-4 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull some more powerpc fixes for 5.12:

The following changes since commit 0b736881c8f1a6cd912f7a9162b9e097b28c1c30:

  powerpc/traps: unrecoverable_exception() is not an interrupt handler 
(2021-03-12 11:02:12 +1100)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-5.12-4

for you to fetch changes up to cc7a0bb058b85ea03db87169c60c7cfdd5d34678:

  PCI: rpadlpar: Fix potential drc_name corruption in store functions 
(2021-03-17 13:48:07 +1100)

- --
powerpc fixes for 5.12 #4

Fix a possible stack corruption and subsequent DLPAR failure in the rpadlpar_io
PCI hotplug driver.

Two build fixes for uncommon configurations.

Thanks to Christophe Leroy, Tyrel Datwyler.

- --
Christophe Leroy (2):
  powerpc/vdso32: Add missing _restgpr_31_x to fix build failure
  powerpc: Force inlining of cpu_has_feature() to avoid build failure

Tyrel Datwyler (1):
  PCI: rpadlpar: Fix potential drc_name corruption in store functions


 arch/powerpc/include/asm/cpu_has_feature.h |  4 ++--
 arch/powerpc/kernel/vdso32/gettimeofday.S  | 11 +++
 drivers/pci/hotplug/rpadlpar_sysfs.c   | 14 ++
 3 files changed, 19 insertions(+), 10 deletions(-)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmBW1cQACgkQUevqPMjh
pYAhog/+KVrIL4frKx1m7bmM+FJ83heS20+F7i5yQWRovR2FdgYwwbIrtxNUKzRU
sNShwQbt9H6GVEGc12kusH5M+t6wGrHrYQ47kdkD6qhDTPfQzKXsoi5eWbgMkQnx
Hd3njqjzfGFEicmfp8l+1WmoWeYpL2MLR7E/KTtS/MYMq5Gsz2lZSMEsmXlAY5Cs
5lT8dBHdH0AX9krRJk9BzKrRqB0qjrK60/sg9oLJQ4sixeWaa+dSORnJq26jYV+n
MPyaNCWF3EUrs7BNyxfZOeFwAZ0FzRSBZrgIt6MNPreT/FaL6lo2McHHyQ9Ls5Qb
yPUmioNKLhXdtcU6AZ0+QOlQvyiGJ7xb3UTAbFFq8TifYHVS0v9srBkgfcvFHycc
yjDtdeTk18WB6NSDC8zVSc+Ut5q7WZa6RLKubiCPgd5DqDkpAKcYcTQSZZUgTb6Q
IyT7bwCBqW6Z5bNTsHhSZ+Ub06L6RLTQ1IfD4GXtqe16F1eeFlMOPCP2YzGUB6s9
IB7GQilliVtRZaFCGwYyVdZCHftHVdK5k7DV+3aImzPRYOKpL4YWwrBnDoqkccYs
Mhbw2YtO7oXSZ2yXGrsu/WF56QCDf6PFO5r28dvNFEi6qZWbfLEQQLZmv/0efFtC
Je1VKXKXCfuLD2VH02F8URZpzbg90dC8YRsTUpgSLCHgiGjEOcE=
=zfoH
-END PGP SIGNATURE-

Re: [PATCH] scsi: iscsi_tcp: Fix use-after-free when do get_host_param

[Wu Bo]

On 2021/3/20 17:08, Wu Bo wrote:

When logout of iscsi session, to do destroy session process,
tcp_sw_host->session is not set to NULL.
Get host parameters access to tcp_sw_host->session at the same time,
but the session has been released at this time.

[29844.848044] sd 2:0:0:1: [sdj] Synchronizing SCSI cache
[29844.923745] scsi 2:0:0:1: alua: Detached
[29844.927840] 
==
[29844.927861] BUG: KASAN: use-after-free in 
iscsi_sw_tcp_host_get_param+0xf4/0x218 [iscsi_tcp]
[29844.927864] Read of size 8 at addr 80002c0b8f68 by task iscsiadm/523945
[29844.927871] CPU: 1 PID: 523945 Comm: iscsiadm Kdump: loaded Not tainted 
4.19.90.kasan.aarch64
[29844.927873] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[29844.927875] Call trace:
[29844.927884]  dump_backtrace+0x0/0x270
[29844.927886]  show_stack+0x24/0x30
[29844.927895]  dump_stack+0xc4/0x120
[29844.927902]  print_address_description+0x68/0x278
[29844.927904]  kasan_report+0x20c/0x338
[29844.927906]  __asan_load8+0x88/0xb0
[29844.927910]  iscsi_sw_tcp_host_get_param+0xf4/0x218 [iscsi_tcp]
[29844.927932]  show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0x84/0xa0 
[scsi_transport_iscsi]
[29844.927938]  dev_attr_show+0x48/0x90
[29844.927943]  sysfs_kf_seq_show+0x100/0x1e0
[29844.927946]  kernfs_seq_show+0x88/0xa0
[29844.927949]  seq_read+0x164/0x748
[29844.927951]  kernfs_fop_read+0x204/0x308
[29844.927956]  __vfs_read+0xd4/0x2d8
[29844.927958]  vfs_read+0xa8/0x198
[29844.927960]  ksys_read+0xd0/0x180
[29844.927962]  __arm64_sys_read+0x4c/0x60
[29844.927966]  el0_svc_common+0xa8/0x230
[29844.927969]  el0_svc_handler+0xdc/0x138
[29844.927971]  el0_svc+0x10/0x218
[29844.928063] Freed by task 53358:
[29844.928066]  __kasan_slab_free+0x120/0x228
[29844.928068]  kasan_slab_free+0x10/0x18
[29844.928069]  kfree+0x98/0x278
[29844.928083]  iscsi_session_release+0x84/0xa0 [scsi_transport_iscsi]
[29844.928085]  device_release+0x4c/0x100
[29844.928089]  kobject_put+0xc4/0x288
[29844.928091]  put_device+0x24/0x30
[29844.928105]  iscsi_free_session+0x60/0x70 [scsi_transport_iscsi]
[29844.928112]  iscsi_session_teardown+0x134/0x158 [libiscsi]
[29844.928116]  iscsi_sw_tcp_session_destroy+0x7c/0xd8 [iscsi_tcp]
[29844.928129]  iscsi_if_rx+0x1538/0x1f00 [scsi_transport_iscsi]
[29844.928131]  netlink_unicast+0x338/0x3c8
[29844.928133]  netlink_sendmsg+0x51c/0x588
[29844.928135]  sock_sendmsg+0x74/0x98
[29844.928137]  ___sys_sendmsg+0x434/0x470
[29844.928139]  __sys_sendmsg+0xd4/0x148
[29844.928141]  __arm64_sys_sendmsg+0x50/0x60
[29844.928143]  el0_svc_common+0xa8/0x230
[29844.928146]  el0_svc_handler+0xdc/0x138
[29844.928147]  el0_svc+0x10/0x218
[29844.928148]
[29844.928150] The buggy address belongs to the object at 80002c0b8880#012 
which belongs to the cache kmalloc-2048 of size 2048
[29844.928153] The buggy address is located 1768 bytes inside of#012 2048-byte 
region [80002c0b8880, 80002c0b9080)
[29844.928154] The buggy address belongs to the page:
[29844.928158] page:7eb02e00 count:1 mapcount:0 
mapping:8000d8402600 index:0x0 compound_mapcount: 0
[29844.928902] flags: 0x7fffe008100(slab|head)
[29844.929215] raw: 07fffe008100 7e0003535e08 7e00024a9408 
8000d8402600
[29844.929217] raw:  000f000f 0001 

[29844.929219] page dumped because: kasan: bad access detected
[29844.929219]
[29844.929221] Memory state around the buggy address:
[29844.929223]  80002c0b8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[29844.929225]  80002c0b8e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[29844.929227] >80002c0b8f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[29844.929228]   ^
[29844.929230]  80002c0b8f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[29844.929232]  80002c0b9000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[29844.929232] 
==
[29844.929234] Disabling lock debugging due to kernel taint
[29844.969534] scsi host2: iSCSI Initiator over TCP/IP

Fixes: a79af8a64d39 ("[SCSI] iscsi_tcp: use iscsi_conn_get_addr_param libiscsi 
function")
Signed-off-by: Wu Bo 
Signed-off-by: WenChao Hao 
---
  drivers/scsi/iscsi_tcp.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index dd33ce0..98d782d 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -901,10 +901,12 @@ static void iscsi_sw_tcp_session_destroy(struct 
iscsi_cls_session *cls_session)
  {
struct Scsi_Host *shost = iscsi_session_to_shost(cls_session);
struct iscsi_session *session = cls_session->dd_data;
+   struct iscsi_sw_tcp_host *tcp_sw_host = iscsi_host_priv(shost);
  
  	if (WARN_ON_ONCE(session->leadconn))

return;
  
+	tcp_sw_host->session = NULL;

Re: [PATCH v1 2/2] iio: temperature: add driver support for ti tmp117

[Lars-Peter Clausen]

On 3/20/21 7:45 AM, Puranjay Mohan wrote:

TMP117 is a Digital temperature sensor with integrated NV memory.

Add support for tmp117 driver in iio subsystem.

Datasheet:-https://www.ti.com/lit/gpn/tmp117

Signed-off-by: Puranjay Mohan 


This looks good to me. Just two small bits I overlooked during the first 
review, sorry for that.



+};
+
[...]
+static int tmp117_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *channel, int *val,
+   int *val2, long mask)
+{
+   struct tmp117_data *data = iio_priv(indio_dev);
+   u16 tmp, off;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_RAW:
+   tmp = tmp117_read_reg(data, TMP117_REG_TEMP);
+   *val = tmp;

No need for tmp here. Just directly assign to val.

+   return IIO_VAL_INT;
+
+   case IIO_CHAN_INFO_CALIBBIAS:
+   off = tmp117_read_reg(data, TMP117_REG_TEMP_OFFSET);
+   *val = ((int16_t)off * (int32_t)TMP117_RESOLUTION) / 1000;
+   *val2 = ((int16_t)off * (int32_t)TMP117_RESOLUTION) % 1000;
+   return IIO_VAL_INT_PLUS_MICRO;
+
+   case IIO_CHAN_INFO_SCALE:
+   *val = 0;
+   *val2 = TMP117_SCALE;
+   return IIO_VAL_INT_PLUS_NANO;
+
+   default:
+   return -EINVAL;
+   }
+}
+
+static int tmp117_write_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *channel, int val,
+   int val2, long mask)
+{
+   struct tmp117_data *data = iio_priv(indio_dev);
+   u16 off;
+
+   switch (mask) {
+   case IIO_CHAN_INFO_CALIBBIAS:
+   off = ((val * 1000) + (val2 * 10))
+   / (int32_t)TMP117_RESOLUTION;


This needs some input validation. Writing a too large or too small value 
will cause an overflow/underflow and a bogus value will be written to 
the register.


You can either reject invalid values by returning -EINVAL or clamp them 
into the right range. Up to you how you want to handle this.



+   return tmp117_write_reg(data, TMP117_REG_TEMP_OFFSET, off);
+
+   default:
+   return -EINVAL;
+   }
+}

Re: [PATCH 1/1] x86/microcode: Check for offline CPUs before checking for microcode update

[Raj, Ashok]

On Sat, Mar 20, 2021 at 03:55:46PM +0100, Borislav Petkov wrote:
[snip]
> > microcode : 0x30
> > microcode : 0xde
> > microcode : 0x30
> > microcode : 0xde
> 
> Yeah, I'm looking at that check_online_cpus() thing and wondering why we
> even need that:
> 
> 0. So you have CPUs 1 and 3 offline.
> 1. We can update on the subset of cores which are online
> 2. If a core is offline and comes online, we have the hotplug notifier:
> 
> cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "x86/microcode:online",
>   mc_cpu_online, mc_cpu_down_prep);
> 
> which takes care of updating the microcode when that CPU comes online.
> 
> So unless your microcode folks don't come back with a real requirement
> why all CPUs must absolutely be online for a late update, then the
> proper fix is to get rid of check_online_cpus() altogether and update
> what's online and the rest will get updated when they come online.

Its true we update them during the online flow, but the core is still
behind compared to other cores. It still participates when it enters SMM,
or when running MCE for instance. Unless its in WAIT_FOR_SIPI state its
best to not leave a core behind when updating microcode.

-- 
Cheers,
Ashok

[Forgiveness is the attribute of the STRONG - Gandhi]

Re: ext4: stop inode update before return

[Theodore Ts'o]

On Sun, Jan 17, 2021 at 12:57:32AM -0800, Pan Bian wrote:
> The inode update should be stopped before returing the error code.
> 
> Signed-off-by: Pan Bian 

Thanks, applied.

- Ted

[PATCH] staging: vchiq: Typo fixes

[Bhaskar Chowdhury]

s/sepecific/specific/
s/comonent/component/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c 
b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
index 9097bcbd67d8..06bca7be5203 100644
--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
@@ -432,7 +432,7 @@ buffer_from_host(struct vchiq_mmal_instance *instance,
m.u.buffer_from_host.buffer_header.pts = MMAL_TIME_UNKNOWN;
m.u.buffer_from_host.buffer_header.dts = MMAL_TIME_UNKNOWN;

-   /* clear buffer type sepecific data */
+   /* clear buffer type specific data */
memset(_from_host.buffer_header_type_specific, 0,
   sizeof(m.u.buffer_from_host.buffer_header_type_specific));

@@ -927,7 +927,7 @@ static int port_info_get(struct vchiq_mmal_instance 
*instance,
return ret;
 }

-/* create comonent on vc */
+/* create component on vc */
 static int create_component(struct vchiq_mmal_instance *instance,
struct vchiq_mmal_component *component,
const char *name)
--
2.31.0

[PATCH V2] device_cgroup: A typo fix

[Bhaskar Chowdhury]

s/acessed/accessed/


Signed-off-by: Bhaskar Chowdhury 
---
 Changes from V1:
  Getting rid of unwanted comment delimeter addition
  Subject line missed propper commit subject labeling

 security/device_cgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 04375df52fc9..30b3083276df 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -409,7 +409,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup,
} else {
/*
 * new exception in the child will add more devices
-* that can be acessed, so it can't match any of
+* that can be accessed, so it can't match any of
 * parent's exceptions, even slightly
 */
match = match_exception_partial(_cgroup->exceptions,
--
2.20.1

arch/riscv/include/asm/page.h:133:62: error: 'max_mapnr' undeclared; did you mean

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   812da4d39463a060738008a46cfc9f775e4bfcf6
commit: 4f0e8eef772ee4438f304b2178bc28c958b6c13d riscv: Add numa support for 
riscv64 platform
date:   9 weeks ago
config: riscv-randconfig-r032-20210321 (attached as .config)
compiler: riscv64-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/torvalds/linux.git/commit/?id=4f0e8eef772ee4438f304b2178bc28c958b6c13d
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 4f0e8eef772ee4438f304b2178bc28c958b6c13d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=riscv 

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

All errors (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10,
from include/linux/delay.h:22,
from drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:9:
   include/linux/scatterlist.h: In function 'sg_set_buf':
>> arch/riscv/include/asm/page.h:133:62: error: 'max_mapnr' undeclared (first 
>> use in this function); did you mean 'set_max_mapnr'?
 133 |  (((pfn) >= ARCH_PFN_OFFSET) && (((pfn) - ARCH_PFN_OFFSET) < 
max_mapnr))
 |  
^
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
  78 | # define unlikely(x) __builtin_expect(!!(x), 0)
 |  ^
   include/linux/scatterlist.h:137:2: note: in expansion of macro 'BUG_ON'
 137 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~
   arch/riscv/include/asm/page.h:138:33: note: in expansion of macro 'pfn_valid'
 138 | #define virt_addr_valid(vaddr) (pfn_valid(virt_to_pfn(vaddr)))
 | ^
   include/linux/scatterlist.h:137:10: note: in expansion of macro 
'virt_addr_valid'
 137 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~~
   arch/riscv/include/asm/page.h:133:62: note: each undeclared identifier is 
reported only once for each function it appears in
 133 |  (((pfn) >= ARCH_PFN_OFFSET) && (((pfn) - ARCH_PFN_OFFSET) < 
max_mapnr))
 |  
^
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
  78 | # define unlikely(x) __builtin_expect(!!(x), 0)
 |  ^
   include/linux/scatterlist.h:137:2: note: in expansion of macro 'BUG_ON'
 137 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~
   arch/riscv/include/asm/page.h:138:33: note: in expansion of macro 'pfn_valid'
 138 | #define virt_addr_valid(vaddr) (pfn_valid(virt_to_pfn(vaddr)))
 | ^
   include/linux/scatterlist.h:137:10: note: in expansion of macro 
'virt_addr_valid'
 137 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~~
--
   In file included from include/linux/kernel.h:10,
from include/linux/delay.h:22,
from drivers/remoteproc/remoteproc_core.c:19:
   include/linux/scatterlist.h: In function 'sg_set_buf':
>> arch/riscv/include/asm/page.h:133:62: error: 'max_mapnr' undeclared (first 
>> use in this function); did you mean 'set_max_mapnr'?
 133 |  (((pfn) >= ARCH_PFN_OFFSET) && (((pfn) - ARCH_PFN_OFFSET) < 
max_mapnr))
 |  
^
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
  78 | # define unlikely(x) __builtin_expect(!!(x), 0)
 |  ^
   include/linux/scatterlist.h:137:2: note: in expansion of macro 'BUG_ON'
 137 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~
   arch/riscv/include/asm/page.h:138:33: note: in expansion of macro 'pfn_valid'
 138 | #define virt_addr_valid(vaddr) (pfn_valid(virt_to_pfn(vaddr)))
 | ^
   include/linux/scatterlist.h:137:10: note: in expansion of macro 
'virt_addr_valid'
 137 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~~
   arch/riscv/include/asm/page.h:133:62: note: each undeclared identifier is 
reported only once for each function it appears in
 133 |  (((pfn) >= ARCH_PFN_OFFSET) && (((pfn) - ARCH_PFN_OFFSET) < 
max_mapnr))
 |  
^
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
  78 | # define unlikely(x) 

Is s390's new generic-using syscall code actually correct?

[Andy Lutomirski]

Hi all-

I'm working on my kentry patchset, and I encountered:

commit 56e62a73702836017564eaacd5212e4d0fa1c01d
Author: Sven Schnelle 
Date:   Sat Nov 21 11:14:56 2020 +0100

s390: convert to generic entry

As part of this work, I was cleaning up the generic syscall helpers,
and I encountered the goodies in do_syscall() and __do_syscall().

I'm trying to wrap my head around the current code, and I'm rather confused.

1. syscall_exit_to_user_mode_work() does *all* the exit work, not just
the syscall exit work.  So a do_syscall() that gets called twice will
do the loopy part of the exit work (e.g. signal handling) twice.  Is
this intentional?  If so, why?

2. I don't understand how this PIF_SYSCALL_RESTART thing is supposed
to work.  Looking at the code in Linus' tree, if a signal is pending
and a syscall returns -ERESTARTSYS, the syscall will return back to
do_syscall().  The work (as in (1)) gets run, calling do_signal(),
which will notice -ERESTARTSYS and set PIF_SYSCALL_RESTART.
Presumably it will also push the signal frame onto the stack and aim
the return address at the svc instruction mentioned in the commit
message from "s390: convert to generic entry".  Then __do_syscall()
will turn interrupts back on and loop right back into do_syscall().
That seems incorrect.

Can you enlighten me?  My WIP tree is here:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/kentry

Here are my changes to s390, and I don't think they're really correct:


https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/diff/arch/s390/kernel/syscall.c?h=x86/kentry=58a459922be0fb8e0f17aeaebcb0ac8d0575a62c

[PATCH] security: A typo fix

[Bhaskar Chowdhury]

s/acessed/accessed/

Signed-off-by: Bhaskar Chowdhury 
---
  Two comment block delimiter automatically delete themselve and created
  themselves ..wondering..I hope that won't be problem,is it?
 security/device_cgroup.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 04375df52fc9..c2c052512472 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -404,14 +404,14 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup,
/*
 * new exception in the child doesn't matter, only
 * adding extra restrictions
-*/
+*/
return true;
} else {
/*
 * new exception in the child will add more devices
-* that can be acessed, so it can't match any of
+* that can be accessed, so it can't match any of
 * parent's exceptions, even slightly
-*/
+*/
match = match_exception_partial(_cgroup->exceptions,
refex->type,
refex->major,
--
2.20.1

[PATCH] security: A typo fix

[Bhaskar Chowdhury]

s/programers/programmers/

Signed-off-by: Bhaskar Chowdhury 
---
 security/lsm_audit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/lsm_audit.c b/security/lsm_audit.c
index 82ce14933513..ddcf572105be 100644
--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c
@@ -212,7 +212,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
char comm[sizeof(current->comm)];

/*
-* To keep stack sizes in check force programers to notice if they
+* To keep stack sizes in check force programmers to notice if they
 * start making this union too large!  See struct lsm_network_audit
 * as an example of how to deal with large data.
 */
--
2.20.1

[PATCH v2] swiotlb: Make SWIOTLB_NO_FORCE perform no allocation

[Florian Fainelli]

When SWIOTLB_NO_FORCE is used, there should really be no allocations of
default_nslabs to occur since we are not going to use those slabs. If a
platform was somehow setting swiotlb_no_force and a later call to
swiotlb_init() was to be made we would still be proceeding with
allocating the default SWIOTLB size (64MB), whereas if swiotlb=noforce
was set on the kernel command line we would have only allocated 2KB.

This would be inconsistent and the point of initializing default_nslabs
to 1, was intended to allocate the minimum amount of memory possible, so
simply remove that minimal allocation period.

Signed-off-by: Florian Fainelli 
---
Changes in v2:

- rebased against devel/for-linus-5.13
- updated commit message to reflect variable names

 kernel/dma/swiotlb.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 539c76beb52e..d20002a61546 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -83,12 +83,10 @@ setup_io_tlb_npages(char *str)
}
if (*str == ',')
++str;
-   if (!strcmp(str, "force")) {
+   if (!strcmp(str, "force"))
swiotlb_force = SWIOTLB_FORCE;
-   } else if (!strcmp(str, "noforce")) {
+   else if (!strcmp(str, "noforce"))
swiotlb_force = SWIOTLB_NO_FORCE;
-   default_nslabs = 1;
-   }
 
return 0;
 }
@@ -211,6 +209,9 @@ swiotlb_init(int verbose)
size_t bytes = PAGE_ALIGN(default_nslabs << IO_TLB_SHIFT);
void *tlb;
 
+   if (swiotlb_force == SWIOTLB_NO_FORCE)
+   return;
+
/* Get IO TLB memory from the low pages */
tlb = memblock_alloc_low(bytes, PAGE_SIZE);
if (!tlb)
-- 
2.25.1

[PATCH v2 0/1] Mediatek pinctrl patch

[Zhiyong Tao]

This series includes 1 patches:
1.add lock in mtk_rmw function.

Changes in patch v2:
1)add mutex lock init in "pinctrl-moore.c".

Zhiyong Tao (1):
  pinctrl: add lock in mtk_rmw function.

 drivers/pinctrl/mediatek/pinctrl-moore.c | 2 ++
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4 
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 ++
 drivers/pinctrl/mediatek/pinctrl-paris.c | 2 ++
 4 files changed, 10 insertions(+)

--
2.25.1

[PATCH] cap: Trivial spelling fixes throughout the file

[Bhaskar Chowdhury]

Mundane spelling fixes throughout the file.

Signed-off-by: Bhaskar Chowdhury 
---
 security/commoncap.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index 1c519c875217..d4bb6d619200 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct 
user_namespace *targ_ns,
if (ns->level <= cred->user_ns->level)
return -EPERM;

-   /*
+   /*
 * The owner of the user namespace in the parent of the
 * user namespace has all caps.
 */
@@ -842,7 +842,7 @@ static inline bool __is_setgid(struct cred *new, const 
struct cred *old)
  *   1) cap_effective has all caps
  *   2) we became root *OR* are were already root
  *   3) root is supposed to have all caps (SECURE_NOROOT)
- * Since this is just a normal root execing a process.
+ * Since this is just a normal root executing a process.
  *
  * Number 1 above might fail if you don't have a full bset, but I think
  * that is interesting information to audit.
@@ -1132,7 +1132,7 @@ int cap_task_fix_setuid(struct cred *new, const struct 
cred *old, int flags)
break;

case LSM_SETID_FS:
-   /* juggle the capabilties to follow FSUID changes, unless
+   /* juggle the capabilities to follow FSUID changes, unless
 * otherwise suppressed
 *
 * FIXME - is fsuser used for all CAP_FS_MASK capabilities?
@@ -1183,10 +1183,10 @@ static int cap_safe_nice(struct task_struct *p)
 }

 /**
- * cap_task_setscheduler - Detemine if scheduler policy change is permitted
+ * cap_task_setscheduler - Determine if scheduler policy change is permitted
  * @p: The task to affect
  *
- * Detemine if the requested scheduler policy change is permitted for the
+ * Determine if the requested scheduler policy change is permitted for the
  * specified task, returning 0 if permission is granted, -ve if denied.
  */
 int cap_task_setscheduler(struct task_struct *p)
@@ -1195,11 +1195,11 @@ int cap_task_setscheduler(struct task_struct *p)
 }

 /**
- * cap_task_ioprio - Detemine if I/O priority change is permitted
+ * cap_task_ioprio - Determine if I/O priority change is permitted
  * @p: The task to affect
  * @ioprio: The I/O priority to set
  *
- * Detemine if the requested I/O priority change is permitted for the specified
+ * Determine if the requested I/O priority change is permitted for the 
specified
  * task, returning 0 if permission is granted, -ve if denied.
  */
 int cap_task_setioprio(struct task_struct *p, int ioprio)
@@ -1208,11 +1208,11 @@ int cap_task_setioprio(struct task_struct *p, int 
ioprio)
 }

 /**
- * cap_task_ioprio - Detemine if task priority change is permitted
+ * cap_task_ioprio - Determine if task priority change is permitted
  * @p: The task to affect
  * @nice: The nice value to set
  *
- * Detemine if the requested task priority change is permitted for the
+ * Determine if the requested task priority change is permitted for the
  * specified task, returning 0 if permission is granted, -ve if denied.
  */
 int cap_task_setnice(struct task_struct *p, int nice)
--
2.20.1

[PATCH] pinctrl: add lock in mtk_rmw function.

[Zhiyong Tao]

When multiple threads operate on the same register resource
which include multiple pin, It will make the register resource
wrong to control. So we add lock to avoid the case.

Signed-off-by: Zhiyong Tao 
---
 drivers/pinctrl/mediatek/pinctrl-moore.c | 2 ++
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4 
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 ++
 drivers/pinctrl/mediatek/pinctrl-paris.c | 2 ++
 4 files changed, 10 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.c 
b/drivers/pinctrl/mediatek/pinctrl-moore.c
index 0fa7de43bc4c..f77921957f15 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.c
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.c
@@ -619,6 +619,8 @@ int mtk_moore_pinctrl_probe(struct platform_device *pdev,
 
hw->nbase = hw->soc->nbase_names;
 
+   mutex_init(>lock);
+
/* Copy from internal struct mtk_pin_desc to register to the core */
pins = devm_kmalloc_array(>dev, hw->soc->npins, sizeof(*pins),
  GFP_KERNEL);
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 72f17f26acd8..fcf7c34a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -58,10 +58,14 @@ void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 
mask, u32 set)
 {
u32 val;
 
+   mutex_lock(>lock);
+
val = mtk_r32(pctl, i, reg);
val &= ~mask;
val |= set;
mtk_w32(pctl, i, reg, val);
+
+   mutex_unlock(>lock);
 }
 
 static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index e2aae285b5fc..65eac708a3b3 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -251,6 +251,8 @@ struct mtk_pinctrl {
struct mtk_eint *eint;
struct mtk_pinctrl_group*groups;
const char  **grp_names;
+   /* lock pin's register resource to avoid multiple threads issue*/
+   struct mutex lock;
 };
 
 void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c 
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index da1f19288aa6..48e823f6d293 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -970,6 +970,8 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev,
 
hw->nbase = hw->soc->nbase_names;
 
+   mutex_init(>lock);
+
err = mtk_pctrl_build_state(pdev);
if (err) {
dev_err(>dev, "build state failed: %d\n", err);
-- 
2.18.0

[PATCH] RCU: some improvements to comments of tree.c

[Zhouyi Zhou]

During my study of RCU, I go through tree.c many times
and try to make some improvements to the comments.

Thanks a lot.

Signed-off-by: Zhouyi Zhou 
---
 kernel/rcu/tree.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index da6f5213fb74..50c6b8fd8d08 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -201,7 +201,7 @@ EXPORT_SYMBOL_GPL(rcu_get_gp_kthreads_prio);
  * the need for long delays to increase some race probabilities with the
  * need for fast grace periods to increase other race probabilities.
  */
-#define PER_RCU_NODE_PERIOD 3  /* Number of grace periods between delays. */
+#define PER_RCU_NODE_PERIOD 3  /* Number of grace periods between delays, for 
debug purpose. */
 
 /*
  * Compute the mask of online CPUs for the specified rcu_node structure.
@@ -835,9 +835,9 @@ void noinstr rcu_irq_exit(void)
 
 /**
  * rcu_irq_exit_preempt - Inform RCU that current CPU is exiting irq
- *   towards in kernel preemption
+ *   towards kernel preemption
  *
- * Same as rcu_irq_exit() but has a sanity check that scheduling is safe
+ * Same as rcu_irq_exit() but has some sanity checks that scheduling is safe
  * from RCU point of view. Invoked from return from interrupt before kernel
  * preemption.
  */
@@ -959,7 +959,7 @@ EXPORT_SYMBOL_GPL(rcu_idle_exit);
  */
 void noinstr rcu_user_exit(void)
 {
-   rcu_eqs_exit(1);
+   rcu_eqs_exit(true);
 }
 
 /**
@@ -1226,7 +1226,7 @@ EXPORT_SYMBOL_GPL(rcu_lockdep_current_cpu_online);
 #endif /* #if defined(CONFIG_PROVE_RCU) && defined(CONFIG_HOTPLUG_CPU) */
 
 /*
- * We are reporting a quiescent state on behalf of some other CPU, so
+ * We may reporting a quiescent state on behalf of some other CPU, so
  * it is our responsibility to check for and handle potential overflow
  * of the rcu_node ->gp_seq counter with respect to the rcu_data counters.
  * After all, the CPU might be in deep idle state, and thus executing no
@@ -1808,9 +1808,9 @@ static bool rcu_gp_init(void)
return false;
}
 
-   /* Advance to a new grace period and initialize state. */
-   record_gp_stall_check_time();
/* Record GP times before starting GP, hence rcu_seq_start(). */
+   record_gp_stall_check_time();
+   /* Advance to a new grace period and initialize state. */
rcu_seq_start(_state.gp_seq);
ASSERT_EXCLUSIVE_WRITER(rcu_state.gp_seq);
trace_rcu_grace_period(rcu_state.name, rcu_state.gp_seq, TPS("start"));
@@ -2630,7 +2630,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
  * state, for example, user mode or idle loop.  It also schedules RCU
  * core processing.  If the current grace period has gone on too long,
  * it will ask the scheduler to manufacture a context switch for the sole
- * purpose of providing a providing the needed quiescent state.
+ * purpose of providing the needed quiescent state.
  */
 void rcu_sched_clock_irq(int user)
 {
@@ -3260,7 +3260,7 @@ put_cached_bnode(struct kfree_rcu_cpu *krcp,
 
 /*
  * This function is invoked in workqueue context after a grace period.
- * It frees all the objects queued on ->bhead_free or ->head_free.
+ * It frees all the objects queued on ->bkvhead_free or ->head_free.
  */
 static void kfree_rcu_work(struct work_struct *work)
 {
@@ -3287,7 +3287,7 @@ static void kfree_rcu_work(struct work_struct *work)
krwp->head_free = NULL;
raw_spin_unlock_irqrestore(>lock, flags);
 
-   // Handle two first channels.
+   // Handle first two channels.
for (i = 0; i < FREE_N_CHANNELS; i++) {
for (; bkvhead[i]; bkvhead[i] = bnext) {
bnext = bkvhead[i]->next;
@@ -3530,7 +3530,7 @@ kvfree_call_rcu_add_ptr_to_bulk(struct kfree_rcu_cpu 
*krcp, void *ptr)
 
 /*
  * Queue a request for lazy invocation of appropriate free routine after a
- * grace period. Please note there are three paths are maintained, two are the
+ * grace period. Please note there are three paths maintained, two are the
  * main ones that use array of pointers interface and third one is emergency
  * one, that is used only when the main path can not be maintained temporary,
  * due to memory pressure.
@@ -3813,7 +3813,7 @@ EXPORT_SYMBOL_GPL(cond_synchronize_rcu);
 
 /*
  * Check to see if there is any immediate RCU-related work to be done by
- * the current CPU, returning 1 if so and zero otherwise.  The checks are
+ * the current CPU, returning 1 if so and 0 otherwise.  The checks are
  * in order of increasing expense: checks that can be carried out against
  * CPU-local state are performed first.  However, we must check for CPU
  * stalls first, else we might not get a chance.
@@ -4153,7 +4153,7 @@ int rcutree_online_cpu(unsigned int cpu)
 }
 
 /*
- * Near the beginning of the process.  The CPU is still very much alive
+ * Near the beginning of the offline process. The CPU is still very much alive
  * 

Bootconfig ..too many deep level of header file

[Bhaskar Chowdhury]

Hey, Masami

I was wondering why so many level of "deep nesting" of a particualr header
file like this one :

✔ ~/git-linux/linux/tools/bootconfig/include/linux [patch L|✔]
08:34 $ cat bootconfig.h
/* SPDX-License-Identifier: GPL-2.0 */
#ifndef _BOOTCONFIG_LINUX_BOOTCONFIG_H
#define _BOOTCONFIG_LINUX_BOOTCONFIG_H

#include "../../../../include/linux/bootconfig.h"

#endif

I am surely missing some basic stuff...but...anyway, I have taken a peek on 
other files in the same dir and none have the nesting like that(the include ../ 
...line)

Any specific reason? OR did you thought of keeping all the header file in one 
paplace(wildly guessing) ...


~Bhaskar

Re: [PATCH 4.19 0/8] 4.19.182-rc1 review

[Samuel Zou]

On 2021/3/19 20:18, Greg Kroah-Hartman wrote:

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

Responses should be made by Sun, 21 Mar 2021 12:17:37 +.
Anything received after that time might be too late.

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

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

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

thanks,

greg k-h



Tested on arm64 and x86 for 4.19.182-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-4.19.y
Version: 4.19.182-rc1
Commit: 7281e11121f6fb47ea1e757b7781c5c15e3781fe
Compiler: gcc version 7.3.0 (GCC)

arm64:

Testcase Result Summary:
total: 4688
passed: 4688
failed: 0
timeout: 0


x86:

Testcase Result Summary:
total: 4688
passed: 4688
failed: 0
timeout: 0


Tested-by: Hulk Robot 

Re: [PATCH 5.10 00/13] 5.10.25-rc1 review

[Samuel Zou]

On 2021/3/19 20:18, Greg Kroah-Hartman wrote:

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

Responses should be made by Sun, 21 Mar 2021 12:17:37 +.
Anything received after that time might be too late.

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

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

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

thanks,

greg k-h



Tested on arm64 and x86 for 5.10.25,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.10.y
Version: 5.10.25
Commit: 3ba56f490c7ab26974806f8c2f14fc49652efe10
Compiler: gcc version 7.3.0 (GCC)

arm64:

Testcase Result Summary:
total: 4721
passed: 4721
failed: 0
timeout: 0


x86:

Testcase Result Summary:
total: 4721
passed: 4721
failed: 0
timeout: 0


Tested-by: Hulk Robot 

Re: [PATCH 2/6] mfd: Initial commit of sy7636a

[Alistair Francis]

On Thu, Feb 4, 2021 at 5:31 AM Lee Jones  wrote:
>
> On Sat, 16 Jan 2021, Alistair Francis wrote:
>
> > Initial support for the Silergy SY7636A Power Management chip
> > driver.
>
> Please remove "driver", as this is not support for the driver, it *is*
> the driver which supports the chip.

Sorry for the long delay here.

I have addressed your comments.

>
> > Signed-off-by: Alistair Francis 
> > ---
> >  drivers/mfd/Kconfig |  10 ++
> >  drivers/mfd/Makefile|   2 +
> >  drivers/mfd/sy7636a.c   | 252 
> >  include/linux/mfd/sy7636a.h |  50 +++
> >  4 files changed, 314 insertions(+)
> >  create mode 100644 drivers/mfd/sy7636a.c
> >  create mode 100644 include/linux/mfd/sy7636a.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index bdfce7b15621..c8c62d92433c 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -1360,6 +1360,16 @@ config MFD_SYSCON
> > Select this option to enable accessing system control registers
> > via regmap.
> >
> > +config MFD_SY7636A
> > + tristate "Silergy SY7636A Power Management chip driver"
>
> Again, please remove the word "driver" here.
>
> > + select MFD_CORE
> > + select REGMAP_I2C
> > + select REGMAP_IRQ
> > + depends on I2C=y
> > + help
> > +   Select this option to enable support for the Silergy SY7636A
> > +   Power Management chip driver.
>
> And again.

I removed "driver" from all of these.

>
> >  config MFD_DAVINCI_VOICECODEC
> >   tristate
> >   select MFD_CORE
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 14fdb188af02..1fa1e635f506 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -265,6 +265,8 @@ obj-$(CONFIG_MFD_ROHM_BD718XX)+= rohm-bd718x7.o
> >  obj-$(CONFIG_MFD_STMFX)  += stmfx.o
> >  obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
> >
> > +obj-$(CONFIG_MFD_SY7636A)+= sy7636a.o
> > +
>
> Why does this have to be segregated?

Fixed

>
> >  obj-$(CONFIG_SGI_MFD_IOC3)   += ioc3.o
> >  obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o
> >  obj-$(CONFIG_MFD_INTEL_M10_BMC)   += intel-m10-bmc.o
> > diff --git a/drivers/mfd/sy7636a.c b/drivers/mfd/sy7636a.c
> > new file mode 100644
> > index ..39aac965d854
> > --- /dev/null
> > +++ b/drivers/mfd/sy7636a.c
> > @@ -0,0 +1,252 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * MFD driver for SY7636A chip
>
> "Parent driver".
>
> > + * Copyright (C) 2019 reMarkable AS - http://www.remarkable.com/
>
> This is quite out of date.  Please update.

I don't own this copyright, so I would rather not change it.

>
> > + * Author: Lars Ivar Miljeteig 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation version 2.
> > + *
> > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > + * kind, whether express or implied; without even the implied warranty
> > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
>
> This test is replaced by the SPDX header above.

Removed.

>
> > + * Based on the lp87565 driver by Keerthy 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +static const struct regmap_config sy7636a_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > +};
> > +
> > +static const struct mfd_cell sy7636a_cells[] = {
> > + { .name = "sy7636a-regulator", },
> > + { .name = "sy7636a-temperature", },
> > + { .name = "sy7636a-thermal", },
> > +};
> > +
> > +static const struct of_device_id of_sy7636a_match_table[] = {
> > + { .compatible = "silergy,sy7636a", },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, of_sy7636a_match_table);
>
> Please move this to where it is used i.e. at the bottom of the file.

Done.

>
> > +static const char * const states[] = {
> > + "no fault event",
> > + "UVP at VP rail",
> > + "UVP at VN rail",
> > + "UVP at VPOS rail",
> > + "UVP at VNEG rail",
> > + "UVP at VDDH rail",
> > + "UVP at VEE rail",
> > + "SCP at VP rail",
> > + "SCP at VN rail",
> > + "SCP at VPOS rail",
> > + "SCP at VNEG rail",
> > + "SCP at VDDH rail",
> > + "SCP at VEE rail",
> > + "SCP at V COM rail",
> > + "UVLO",
> > + "Thermal shutdown",
> > +};
> > +
> > +int get_vcom_voltage_mv(struct regmap *regmap)
> > +{
> > + int ret;
> > + unsigned int val, val_h;
> > +
> > + ret = regmap_read(regmap, SY7636A_REG_VCOM_ADJUST_CTRL_L, );
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_read(regmap, SY7636A_REG_VCOM_ADJUST_CTRL_H, _h);
> > + if (ret)
> > + return ret;
> > +
> > + val |= (val_h << 8);
>
> Please 

Re: [PATCH v3 net-next 12/12] net: ocelot: replay switchdev events when joining bridge

[kernel test robot]

Hi Vladimir,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
d773b7957e4fd7b732a163df0e59d31ad4237302
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/137a4ab1ff1eea04b979eb9adcad330fa14ede73
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
git checkout 137a4ab1ff1eea04b979eb9adcad330fa14ede73
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=m68k 

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

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

ERROR: modpost: "br_vlan_replay" [net/dsa/dsa_core.ko] undefined!
>> ERROR: modpost: "br_vlan_replay" [drivers/net/ethernet/mscc/mscc_ocelot.ko] 
>> undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH net-next 0/5] net: ipa: more configuration data updates

[patchwork-bot+netdevbpf]

Hello:

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

On Sat, 20 Mar 2021 10:57:02 -0500 you wrote:
> This series starts with two patches that should have been included
> in an earlier series.  With these in place, QSB settings are
> programmed from information found in the data files rather than
> being embedded in code.  Support is then added for reprenting
> another QSB property (supported for IPA v4.0+).
> 
> The third patch updates the definition of the sequencer type used
> for an endpoint.  Previously a set of 2-byte symbols with fairly
> long names defined the sequencer type, but now those are broken into
> 1-byte halves whose names are a little more informative.
> 
> [...]

Here is the summary with links:
  - [net-next,1/5] net: ipa: use configuration data for QSB settings
https://git.kernel.org/netdev/net-next/c/8a81efac9417
  - [net-next,2/5] net: ipa: implement MAX_READS_BEATS QSB data
https://git.kernel.org/netdev/net-next/c/b9aa0805ed31
  - [net-next,3/5] net: ipa: split sequencer type in two
https://git.kernel.org/netdev/net-next/c/8ee5df6598ff
  - [net-next,4/5] net: ipa: sequencer type is for TX endpoints only
https://git.kernel.org/netdev/net-next/c/1690d8a75d87
  - [net-next,5/5] net: ipa: update some comments in "ipa_data.h"
https://git.kernel.org/netdev/net-next/c/b259cc2a036f

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

Re: [PATCH] net: decnet: Fixed multiple coding style issues

[patchwork-bot+netdevbpf]

Hello:

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

On Sat, 20 Mar 2021 11:45:12 +0530 you wrote:
> Made changes to coding style as suggested by checkpatch.pl
> changes are of the type:
>   open brace '{' following struct go on the same line
>   do not use assignment in if condition
> 
> Signed-off-by: Sai Kalyaan Palla 
> 
> [...]

Here is the summary with links:
  - net: decnet: Fixed multiple coding style issues
https://git.kernel.org/netdev/net-next/c/b29648ad5b2a

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

Re: [PATCH] perf evlist: Mundane typo fix

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/explicitely/explicitly/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
tools/perf/builtin-top.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 3673c04d16b6..173ace43f845 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1607,7 +1607,7 @@ int cmd_top(int argc, const char **argv)
if (status) {
/*
 * Some arches do not provide a get_cpuid(), so just use 
pr_debug, otherwise
-* warn the user explicitely.
+* warn the user explicitly.
 */
eprintf(status == ENOSYS ? 1 : 0, verbose,
"Couldn't read the cpuid for this machine: %s\n",
--
2.30.1

Re: [PATCH] perf tools: Rudimentary typo fix

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/archictures/architectures/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
tools/perf/builtin-stat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 2e2e4a8345ea..5cc5eeae6ade 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1705,7 +1705,7 @@ static int add_default_attributes(void)
bzero(, sizeof(errinfo));
if (transaction_run) {
/* Handle -T as -M transaction. Once platform specific metrics
-* support has been added to the json files, all archictures
+* support has been added to the json files, all architectures
 * will use this approach. To determine transaction support
 * on an architecture test for such a metric name.
 */
--
2.30.1

Re: [PATCH v4 08/28] netfs: Provide readahead and readpage netfs helpers

[Matthew Wilcox]

On Wed, Mar 10, 2021 at 04:56:13PM +, David Howells wrote:
> +void netfs_readahead(struct readahead_control *ractl,
> +  const struct netfs_read_request_ops *ops,
> +  void *netfs_priv)
> +{
> + struct netfs_read_request *rreq;
> + struct page *page;
> + unsigned int debug_index = 0;
> +
> + _enter("%lx,%x", readahead_index(ractl), readahead_count(ractl));
> +
> + if (readahead_count(ractl) == 0)
> + goto cleanup;
> +
> + rreq = netfs_alloc_read_request(ops, netfs_priv, ractl->file);
> + if (!rreq)
> + goto cleanup;
> + rreq->mapping   = ractl->mapping;
> + rreq->start = readahead_pos(ractl);
> + rreq->len   = readahead_length(ractl);
> +
> + netfs_rreq_expand(rreq, ractl);
> +
> + atomic_set(>nr_rd_ops, 1);
> + do {
> + if (!netfs_rreq_submit_slice(rreq, _index))
> + break;
> +
> + } while (rreq->submitted < rreq->len);
> +
> + while ((page = readahead_page(ractl)))
> + put_page(page);

You don't need this pair of lines (unless I'm missing something).
read_pages() in mm/readahead.c puts the reference and unlocks any
pages which are not read by the readahead op.  Indeed, I think doing
this is buggy because you don't unlock the page.

> + /* If we decrement nr_rd_ops to 0, the ref belongs to us. */
> + if (atomic_dec_and_test(>nr_rd_ops))
> + netfs_rreq_assess(rreq, false);
> + return;
> +
> +cleanup:
> + if (netfs_priv)
> + ops->cleanup(ractl->mapping, netfs_priv);
> + return;
> +}
> +EXPORT_SYMBOL(netfs_readahead);

> +int netfs_readpage(struct file *file,
> +struct page *page,
> +const struct netfs_read_request_ops *ops,
> +void *netfs_priv)
> +{
> + struct netfs_read_request *rreq;
> + unsigned int debug_index = 0;
> + int ret;
> +
> + _enter("%lx", page->index);
> +
> + rreq = netfs_alloc_read_request(ops, netfs_priv, file);
> + if (!rreq) {
> + if (netfs_priv)
> + ops->cleanup(netfs_priv, page->mapping);
> + unlock_page(page);
> + return -ENOMEM;
> + }
> + rreq->mapping   = page->mapping;

FYI, this isn't going to work with swap-over-NFS.  You have to use
page_file_mapping().

> + rreq->start = page->index * PAGE_SIZE;

and page_index() here.

I rather dislike it that swap-over-NFS uses readpage which makes this
need to exist.  If somebody were to switch SWP_FS_OPS to using kiocbs,
some of this pain could go away.

Re: [PATCH v5 3/3] ARM: imx7d-remarkable2.dts: Initial device tree for reMarkable2

[Alistair Francis]

On Fri, Mar 19, 2021 at 9:06 AM Marco Felsch  wrote:
>
> Hi Alistair,
>
> the patch looks quite good only a few notes inline.
>
> PS: It would be cool to have a log to previous patch versions.

I'm not sure how I could add that, I will add a changelog for this
version though.

>
> On 21-03-15 22:27, Alistair Francis wrote:
>
> ...
>
> > + {
> > + status = "disabled";
> > +};
>
> Why do you disable the crypto subsystem?
>
> > +_apbh {
> > + status = "disabled";
> > +};
>
> Why do you disable this dma controller?
>
> > +
> > + {
> > + status = "okay";
> > +};
>
> This is the default state so you can drop this node.

You are right, these are all just left over from the vendor DT, I have
removed all 3.

Alistair

>
> Regards,
>   Marco

Re: [PATCH net-next] dsa: simplify Kconfig symbols and dependencies

[Florian Fainelli]

On 3/19/2021 8:46 AM, Alexander Lobakin wrote:
> 1. Remove CONFIG_HAVE_NET_DSA.
> 
> CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers
> should have selected CONFIG_NET_DSA manually.
> Currently, all drivers has explicit 'depends on NET_DSA', so this is
> no more needed.
> 
> 2. CONFIG_HAVE_NET_DSA dependencies became CONFIG_NET_DSA's ones.
> 
>  - dropped !S390 dependency which was introduced to be sure NET_DSA
>can select CONFIG_PHYLIB. DSA migrated to Phylink almost 3 years
>ago and the PHY library itself doesn't depend on !S390 since
>commit 870a2b5e4fcd ("phylib: remove !S390 dependeny from Kconfig");
>  - INET dependency is kept to be sure we can select NET_SWITCHDEV;
>  - NETDEVICES dependency is kept to be sure we can select PHYLINK.
> 
> 3. DSA drivers menu now depends on NET_DSA.
> 
> Instead on 'depends on NET_DSA' on every single driver, the entire
> menu now depends on it. This eliminates a lot of duplicated lines
> from Kconfig with no loss (when CONFIG_NET_DSA=m, drivers also can
> be only m or n).
> This also has a nice side effect that there's no more empty menu on
> configurations without DSA.
> 
> 4. Kbuild will now descend into 'drivers/net/dsa' only when
>CONFIG_NET_DSA is y or m.
> 
> This is safe since no objects inside this folder can be built without
> DSA core, as well as when CONFIG_NET_DSA=m, no objects can be
> built-in.
> 
> Signed-off-by: Alexander Lobakin 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v3 net-next 10/12] net: dsa: replay VLANs installed on port when joining the bridge

[kernel test robot]

Hi Vladimir,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
d773b7957e4fd7b732a163df0e59d31ad4237302
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/a9e40df7bd2130d087464f81ffd7ba798a99e320
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
git checkout a9e40df7bd2130d087464f81ffd7ba798a99e320
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=m68k 

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

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

>> ERROR: modpost: "br_vlan_replay" [net/dsa/dsa_core.ko] undefined!

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


.config.gz
Description: application/gzip

[PATCH] perf evlist: Mundane typo fix

[Bhaskar Chowdhury]

s/explicitely/explicitly/

Signed-off-by: Bhaskar Chowdhury 
---
 tools/perf/builtin-top.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 3673c04d16b6..173ace43f845 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1607,7 +1607,7 @@ int cmd_top(int argc, const char **argv)
if (status) {
/*
 * Some arches do not provide a get_cpuid(), so just use 
pr_debug, otherwise
-* warn the user explicitely.
+* warn the user explicitly.
 */
eprintf(status == ENOSYS ? 1 : 0, verbose,
"Couldn't read the cpuid for this machine: %s\n",
--
2.30.1

Re: [PATCH net-next] dsa: simplify Kconfig symbols and dependencies

[Vladimir Oltean]

On Fri, Mar 19, 2021 at 03:46:30PM +, Alexander Lobakin wrote:
> 1. Remove CONFIG_HAVE_NET_DSA.
>
> CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers
> should have selected CONFIG_NET_DSA manually.
> Currently, all drivers has explicit 'depends on NET_DSA', so this is
> no more needed.
>
> 2. CONFIG_HAVE_NET_DSA dependencies became CONFIG_NET_DSA's ones.
>
>  - dropped !S390 dependency which was introduced to be sure NET_DSA
>can select CONFIG_PHYLIB. DSA migrated to Phylink almost 3 years
>ago and the PHY library itself doesn't depend on !S390 since
>commit 870a2b5e4fcd ("phylib: remove !S390 dependeny from Kconfig");
>  - INET dependency is kept to be sure we can select NET_SWITCHDEV;
>  - NETDEVICES dependency is kept to be sure we can select PHYLINK.
>
> 3. DSA drivers menu now depends on NET_DSA.
>
> Instead on 'depends on NET_DSA' on every single driver, the entire
> menu now depends on it. This eliminates a lot of duplicated lines
> from Kconfig with no loss (when CONFIG_NET_DSA=m, drivers also can
> be only m or n).
> This also has a nice side effect that there's no more empty menu on
> configurations without DSA.
>
> 4. Kbuild will now descend into 'drivers/net/dsa' only when
>CONFIG_NET_DSA is y or m.
>
> This is safe since no objects inside this folder can be built without
> DSA core, as well as when CONFIG_NET_DSA=m, no objects can be
> built-in.
>
> Signed-off-by: Alexander Lobakin 
> ---

Thanks!

Reviewed-by: Vladimir Oltean 

Re: [PATCH v3 net-next 03/12] net: dsa: inherit the actual bridge port flags at join time

[kernel test robot]

Hi Vladimir,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
d773b7957e4fd7b732a163df0e59d31ad4237302
config: arm64-randconfig-r021-20210321 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
14696baaf4c43fe53f738bc292bbe169eed93d5d)
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 arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/3aac17167e3de0aeaf5287f9d586725bdc7495a5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
git checkout 3aac17167e3de0aeaf5287f9d586725bdc7495a5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

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

All warnings (new ones prefixed by >>):

>> net/dsa/port.c:167:5: warning: format specifies type 'int' but the argument 
>> has type 'unsigned long' [-Wformat]
   flags.val, err, ERR_PTR(err));
   ^
   include/linux/dev_printk.h:112:32: note: expanded from macro 'dev_err'
   _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
 ~~~ ^~~
   1 warning generated.


vim +167 net/dsa/port.c

   148  
   149  static void dsa_port_clear_brport_flags(struct dsa_port *dp,
   150  struct netlink_ext_ack *extack)
   151  {
   152  const unsigned long val = BR_FLOOD | BR_MCAST_FLOOD | 
BR_BCAST_FLOOD;
   153  const unsigned long mask = BR_LEARNING | BR_FLOOD | 
BR_MCAST_FLOOD |
   154 BR_BCAST_FLOOD;
   155  int flag, err;
   156  
   157  for_each_set_bit(flag, , 32) {
   158  struct switchdev_brport_flags flags = {0};
   159  
   160  flags.mask = BIT(flag);
   161  flags.val = val & BIT(flag);
   162  
   163  err = dsa_port_bridge_flags(dp, flags, extack);
   164  if (err && err != -EOPNOTSUPP)
   165  dev_err(dp->ds->dev,
   166  "failed to clear bridge port flag %d: 
%d (%pe)\n",
 > 167  flags.val, err, ERR_PTR(err));
   168  }
   169  }
   170  

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


.config.gz
Description: application/gzip

[PATCH] perf tools: Rudimentary typo fix

[Bhaskar Chowdhury]

s/archictures/architectures/

Signed-off-by: Bhaskar Chowdhury 
---
 tools/perf/builtin-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 2e2e4a8345ea..5cc5eeae6ade 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1705,7 +1705,7 @@ static int add_default_attributes(void)
bzero(, sizeof(errinfo));
if (transaction_run) {
/* Handle -T as -M transaction. Once platform specific metrics
-* support has been added to the json files, all archictures
+* support has been added to the json files, all architectures
 * will use this approach. To determine transaction support
 * on an architecture test for such a metric name.
 */
--
2.30.1

Re: [syzbot] WARNING in io_wq_put

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:1c273e10 Merge tag 'zonefs-5.12-rc4' of git://git.kernel.o..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13853506d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=c51293a9ca630f6d
dashboard link: https://syzkaller.appspot.com/bug?extid=77a738a6bc947bf639ca
compiler:   Debian clang version 11.0.1-2
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11ec259ed0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13acfa62d0

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

[ cut here ]
WARNING: CPU: 1 PID: 12892 at fs/io-wq.c:1064 io_wq_destroy fs/io-wq.c:1064 
[inline]
WARNING: CPU: 1 PID: 12892 at fs/io-wq.c:1064 io_wq_put+0x153/0x260 
fs/io-wq.c:1075
Modules linked in:
CPU: 1 PID: 12892 Comm: syz-executor789 Not tainted 5.12.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:io_wq_destroy fs/io-wq.c:1064 [inline]
RIP: 0010:io_wq_put+0x153/0x260 fs/io-wq.c:1075
Code: 8d e8 f1 5f f2 01 49 89 c4 41 83 fc 40 7d 4f e8 a3 e9 97 ff 42 80 7c 2d 
00 00 0f 85 77 ff ff ff e9 7a ff ff ff e8 8d e9 97 ff <0f> 0b eb b9 8d 6b ff 89 
ee 09 de bf ff ff ff ff e8 88 ed 97 ff 09
RSP: 0018:c9000a5efaa0 EFLAGS: 00010293
RAX: 81e11103 RBX: 888021873040 RCX: 88801fbb3880
RDX:  RSI:  RDI: 0040
RBP: 111004b3e480 R08: 81e1104e R09: ed1004b3e482
R10: ed1004b3e482 R11:  R12: 
R13: dc00 R14: 8880259f2400 R15: 888021873000
FS:  7f2407204700() GS:8880b9c0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 00480510 CR3: 2d9a1000 CR4: 001506f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 io_uring_clean_tctx fs/io_uring.c:8874 [inline]
 __io_uring_files_cancel+0xe11/0xe60 fs/io_uring.c:8939
 io_uring_files_cancel include/linux/io_uring.h:22 [inline]
 do_exit+0x258/0x2340 kernel/exit.c:780
 do_group_exit+0x168/0x2d0 kernel/exit.c:922
 get_signal+0x1734/0x1ef0 kernel/signal.c:2773
 arch_do_signal_or_restart+0x3c/0x610 arch/x86/kernel/signal.c:811
 handle_signal_work kernel/entry/common.c:147 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
 exit_to_user_mode_prepare+0xac/0x1e0 kernel/entry/common.c:208
 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
 syscall_exit_to_user_mode+0x26/0x70 kernel/entry/common.c:301
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x448c49
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 15 00 00 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 73 01 
c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:7f24072041f8 EFLAGS: 0246 ORIG_RAX: 01aa
RAX: 0302 RBX: 004cd508 RCX: 00448c49
RDX:  RSI: 0302 RDI: 0005
RBP: 004cd500 R08:  R09: 
R10:  R11: 0246 R12: 004cd50c
R13: 7ffc6fa9d1bf R14: 7f2407204300 R15: 00022000

[PATCH] ipv4/raw: support binding to nonlocal addresses

[Riccardo Paolo Bestetti]

Add support to inet raw sockets for binding to nonlocal addresses
through the IP_FREEBIND and IP_TRANSPARENT socket options, as well as
the ipv4.ip_nonlocal_bind kernel parameter.

Signed-off-by: Riccardo Paolo Bestetti 
---
 net/ipv4/raw.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 50a73178d63a..734c0332b54b 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -717,6 +717,7 @@ static int raw_bind(struct sock *sk, struct sockaddr 
*uaddr, int addr_len)
 {
struct inet_sock *inet = inet_sk(sk);
struct sockaddr_in *addr = (struct sockaddr_in *) uaddr;
+   struct net *net = sock_net(sk);
u32 tb_id = RT_TABLE_LOCAL;
int ret = -EINVAL;
int chk_addr_ret;
@@ -732,7 +733,8 @@ static int raw_bind(struct sock *sk, struct sockaddr 
*uaddr, int addr_len)
tb_id);
 
ret = -EADDRNOTAVAIL;
-   if (addr->sin_addr.s_addr && chk_addr_ret != RTN_LOCAL &&
+   if (!inet_can_nonlocal_bind(net, inet) &&
+   addr->sin_addr.s_addr && chk_addr_ret != RTN_LOCAL &&
chk_addr_ret != RTN_MULTICAST && chk_addr_ret != RTN_BROADCAST)
goto out;
inet->inet_rcv_saddr = inet->inet_saddr = addr->sin_addr.s_addr;
-- 
2.31.0

Re: [PATCH v7 4/4] arm64: dts: mt8192: add spmi node

[kernel test robot]

Hi Hsin-Hsiung,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v5.12-rc3]
[cannot apply to mediatek/for-next]
[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/Hsin-Hsiung-Wang/Add-SPMI-support-for-Mediatek-MT6873-8192-SoC-IC/20210314-020316
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-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/71e33d36a1be3e61a91ba8dfc7cfc8a1a47433eb
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Hsin-Hsiung-Wang/Add-SPMI-support-for-Mediatek-MT6873-8192-SoC-IC/20210314-020316
git checkout 71e33d36a1be3e61a91ba8dfc7cfc8a1a47433eb
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

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

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/mediatek/mt8192.dtsi:299.24-25 syntax error
   FATAL ERROR: Unable to parse input tree

---
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 v3 net-next 03/12] net: dsa: inherit the actual bridge port flags at join time

[kernel test robot]

Hi Vladimir,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
d773b7957e4fd7b732a163df0e59d31ad4237302
config: arm-mvebu_v5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-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/3aac17167e3de0aeaf5287f9d586725bdc7495a5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Vladimir-Oltean/Better-support-for-sandwiched-LAGs-with-bridge-and-DSA/20210321-063842
git checkout 3aac17167e3de0aeaf5287f9d586725bdc7495a5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

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

All warnings (new ones prefixed by >>):

   In file included from include/linux/device.h:15,
from include/linux/dma-mapping.h:7,
from include/linux/skbuff.h:31,
from include/net/net_namespace.h:39,
from include/linux/netdevice.h:37,
from include/linux/if_bridge.h:12,
from net/dsa/port.c:9:
   net/dsa/port.c: In function 'dsa_port_clear_brport_flags':
>> net/dsa/port.c:166:5: warning: format '%d' expects argument of type 'int', 
>> but argument 3 has type 'long unsigned int' [-Wformat=]
 166 | "failed to clear bridge port flag %d: %d (%pe)\n",
 | ^
   include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
  19 | #define dev_fmt(fmt) fmt
 |  ^~~
   net/dsa/port.c:165:4: note: in expansion of macro 'dev_err'
 165 |dev_err(dp->ds->dev,
 |^~~
   net/dsa/port.c:166:40: note: format string is defined here
 166 | "failed to clear bridge port flag %d: %d (%pe)\n",
 |   ~^
 ||
 |int
 |   %ld


vim +166 net/dsa/port.c

   148  
   149  static void dsa_port_clear_brport_flags(struct dsa_port *dp,
   150  struct netlink_ext_ack *extack)
   151  {
   152  const unsigned long val = BR_FLOOD | BR_MCAST_FLOOD | 
BR_BCAST_FLOOD;
   153  const unsigned long mask = BR_LEARNING | BR_FLOOD | 
BR_MCAST_FLOOD |
   154 BR_BCAST_FLOOD;
   155  int flag, err;
   156  
   157  for_each_set_bit(flag, , 32) {
   158  struct switchdev_brport_flags flags = {0};
   159  
   160  flags.mask = BIT(flag);
   161  flags.val = val & BIT(flag);
   162  
   163  err = dsa_port_bridge_flags(dp, flags, extack);
   164  if (err && err != -EOPNOTSUPP)
   165  dev_err(dp->ds->dev,
 > 166  "failed to clear bridge port flag %d: 
 > %d (%pe)\n",
   167  flags.val, err, ERR_PTR(err));
   168  }
   169  }
   170  

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


.config.gz
Description: application/gzip

Re: [PATCH 1/2] clk: zynqmp: pll: add set_pll_mode to check condition in zynqmp_pll_enable

[Laurent Pinchart]

Hi Quanyang,

Thank you for the patch.

On Fri, Mar 19, 2021 at 06:07:17PM +0800, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang 
> 
> If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever,
> we shouldn't skip invoking PM_CLOCK_ENABLE fn even though this
> pll has been enabled. In ATF implementation, it will only assign
> the mode to the variable (struct pm_pll *)pll->mode when handling
> IOCTL_SET_PLL_FRAC_MODE call. Invoking PM_CLOCK_ENABLE can force
> ATF send request to PWU to set the pll mode to PLL's register.
> 
> There is a scenario that happens in enabling VPLL_INT(clk_id:96):
> 1) VPLL_INT has been enabled during booting.
> 2) A driver calls clk_set_rate and according to the rate, the VPLL_INT
>should be set to FRAC mode. Then zynqmp_pll_set_mode is called
>to pass IOCTL_SET_PLL_FRAC_MODE to ATF. Note that at this point
>ATF just stores the mode to a variable.
> 3) This driver calls clk_prepare_enable and zynqmp_pll_enable is
>called to try to enable VPLL_INT pll. Because of 1), the function
>zynqmp_pll_enable just returns without doing anything after checking
>that this pll has been enabled.
> 
> In the scenario above, the pll mode of VPLL_INT will never be set
> successfully. So adding set_pll_mode to chec condition to fix it.

s/chec/check/

> Signed-off-by: Quanyang Wang 
> ---
>  drivers/clk/zynqmp/pll.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
> index 92f449ed38e5..f1e8f37d7f52 100644
> --- a/drivers/clk/zynqmp/pll.c
> +++ b/drivers/clk/zynqmp/pll.c
> @@ -14,10 +14,12 @@
>   * struct zynqmp_pll - PLL clock
>   * @hw:  Handle between common and hardware-specific interfaces
>   * @clk_id:  PLL clock ID
> + * @set_pll_mode:Whether an IOCTL_SET_PLL_FRAC_MODE request be sent to 
> ATF
>   */
>  struct zynqmp_pll {
>   struct clk_hw hw;
>   u32 clk_id;
> + bool set_pll_mode;
>  };
>  
>  #define to_zynqmp_pll(_hw)   container_of(_hw, struct zynqmp_pll, hw)
> @@ -81,6 +83,8 @@ static inline void zynqmp_pll_set_mode(struct clk_hw *hw, 
> bool on)
>   if (ret)
>   pr_warn_once("%s() PLL set frac mode failed for %s, ret = %d\n",
>__func__, clk_name, ret);
> + else
> + clk->set_pll_mode = true;
>  }
>  
>  /**
> @@ -240,9 +244,14 @@ static int zynqmp_pll_enable(struct clk_hw *hw)
>   u32 clk_id = clk->clk_id;
>   int ret;
>  
> - if (zynqmp_pll_is_enabled(hw))
> + /* Don't skip enabling clock if there is an IOCTL_SET_PLL_FRAC_MODE 
> request
> +  * that has been sent to ATF.
> +  */

Very small issue, multiline kerneldoc comments are supposed to start
with a '/*' on its own line:

/*
 * Don't skip enabling clock if there is an IOCTL_SET_PLL_FRAC_MODE
 * request that has been sent to ATF.
 */

> + if (zynqmp_pll_is_enabled(hw) && (!clk->set_pll_mode))
>   return 0;
>  
> + clk->set_pll_mode = false;
> +
>   ret = zynqmp_pm_clock_enable(clk_id);
>   if (ret)
>   pr_warn_once("%s() clock enable failed for %s, ret = %d\n",

This fixes the DPSUB clock issue, so

Tested-by: Laurent Pinchart 

I however wonder if this is the best solution. Shouldn't we instead fix
it on the ATF side, to program the hardware when zynqmp_pll_set_mode()
is called if the clock is already enabled ?

Just reading the code, I can immediately see another potential issue in
zynqmp_pll_set_mode(). The function is called from
zynqmp_pll_round_rate(), which seems completely wrong, as
zynqmp_pll_round_rate() is supposed to only perform rate calculation,
not program the hardware. Am I missing something, or does the PLL
implementation need to be reworked more extensively than this ?

-- 
Regards,

Laurent Pinchart

[tip:master] BUILD SUCCESS 2b7cc48df95a36ecb6dfec219ae1e1f1148e6dac

[kernel test robot]

 randconfig-a004-20210321
i386 randconfig-a001-20210321
i386 randconfig-a002-20210321
i386 randconfig-a006-20210321
i386 randconfig-a005-20210321
i386 randconfig-a004-20210320
i386 randconfig-a003-20210320
i386 randconfig-a001-20210320
i386 randconfig-a002-20210320
i386 randconfig-a006-20210320
i386 randconfig-a005-20210320
x86_64   randconfig-a002-20210321
x86_64   randconfig-a003-20210321
x86_64   randconfig-a006-20210321
x86_64   randconfig-a001-20210321
x86_64   randconfig-a005-20210321
x86_64   randconfig-a004-20210321
x86_64   randconfig-a012-20210320
x86_64   randconfig-a015-20210320
x86_64   randconfig-a013-20210320
x86_64   randconfig-a014-20210320
x86_64   randconfig-a016-20210320
x86_64   randconfig-a011-20210320
i386 randconfig-a014-20210320
i386 randconfig-a011-20210320
i386 randconfig-a015-20210320
i386 randconfig-a016-20210320
i386 randconfig-a013-20210320
i386 randconfig-a012-20210320
i386 randconfig-a014-20210321
i386 randconfig-a011-20210321
i386 randconfig-a015-20210321
i386 randconfig-a016-20210321
i386 randconfig-a013-20210321
i386 randconfig-a012-20210321
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a002-20210320
x86_64   randconfig-a003-20210320
x86_64   randconfig-a001-20210320
x86_64   randconfig-a006-20210320
x86_64   randconfig-a005-20210320
x86_64   randconfig-a004-20210320
x86_64   randconfig-a006-20210318
x86_64   randconfig-a001-20210318
x86_64   randconfig-a005-20210318
x86_64   randconfig-a002-20210318
x86_64   randconfig-a003-20210318
x86_64   randconfig-a004-20210318
x86_64   randconfig-a012-20210321
x86_64   randconfig-a015-20210321
x86_64   randconfig-a013-20210321
x86_64   randconfig-a014-20210321
x86_64   randconfig-a011-20210321
x86_64   randconfig-a016-20210321

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

[tip:x86/cpu] BUILD SUCCESS a331f5fdd36dba1ffb0239a4dfaaf1df91ff1aab

[kernel test robot]

 randconfig-a004-20210321
i386 randconfig-a001-20210321
i386 randconfig-a002-20210321
i386 randconfig-a006-20210321
i386 randconfig-a005-20210321
i386 randconfig-a004-20210320
i386 randconfig-a003-20210320
i386 randconfig-a001-20210320
i386 randconfig-a002-20210320
i386 randconfig-a006-20210320
i386 randconfig-a005-20210320
x86_64   randconfig-a002-20210321
x86_64   randconfig-a003-20210321
x86_64   randconfig-a006-20210321
x86_64   randconfig-a001-20210321
x86_64   randconfig-a005-20210321
x86_64   randconfig-a004-20210321
x86_64   randconfig-a012-20210320
x86_64   randconfig-a015-20210320
x86_64   randconfig-a013-20210320
x86_64   randconfig-a014-20210320
x86_64   randconfig-a016-20210320
x86_64   randconfig-a011-20210320
i386 randconfig-a014-20210320
i386 randconfig-a011-20210320
i386 randconfig-a015-20210320
i386 randconfig-a016-20210320
i386 randconfig-a013-20210320
i386 randconfig-a012-20210320
i386 randconfig-a014-20210321
i386 randconfig-a011-20210321
i386 randconfig-a015-20210321
i386 randconfig-a016-20210321
i386 randconfig-a013-20210321
i386 randconfig-a012-20210321
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a002-20210320
x86_64   randconfig-a003-20210320
x86_64   randconfig-a001-20210320
x86_64   randconfig-a006-20210320
x86_64   randconfig-a005-20210320
x86_64   randconfig-a004-20210320
x86_64   randconfig-a006-20210318
x86_64   randconfig-a001-20210318
x86_64   randconfig-a005-20210318
x86_64   randconfig-a002-20210318
x86_64   randconfig-a003-20210318
x86_64   randconfig-a004-20210318
x86_64   randconfig-a012-20210321
x86_64   randconfig-a015-20210321
x86_64   randconfig-a013-20210321
x86_64   randconfig-a014-20210321
x86_64   randconfig-a011-20210321
x86_64   randconfig-a016-20210321

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

[PATCH] arch: xtensa: fix kconfig dependency on FUTEX

[Julian Braha]

When HAVE_FUTEX_CMPXCHG is enabled, and FUTEX is disabled,
Kbuild gives the following warning:

WARNING: unmet direct dependencies detected for HAVE_FUTEX_CMPXCHG
  Depends on [n]: FUTEX [=n]
  Selected by [y]:
  - XTENSA [=y] && !MMU [=n]

This is because XTENSA selects HAVE_FUTEX_CMPXCHG,
without selecting or depending on FUTEX, despite
HAVE_FUTEX_CMPXCHG depending on FUTEX.

Signed-off-by: Julian Braha 
---
 arch/xtensa/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 9ad6b7b82707..a0d5f065d6b1 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -29,6 +29,7 @@ config XTENSA
select HAVE_DMA_CONTIGUOUS
select HAVE_EXIT_THREAD
select HAVE_FUNCTION_TRACER
+   select FUTEX if !MMU
select HAVE_FUTEX_CMPXCHG if !MMU
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_IRQ_TIME_ACCOUNTING
-- 
2.25.1

powerpc-linux-ld: warning: orphan section `.init.plt' from `drivers/net/ethernet/micrel/ks8851_common.o' being placed in section `.init.plt'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   812da4d39463a060738008a46cfc9f775e4bfcf6
commit: 797047f875b5463719cc70ba213eb691d453c946 net: ks8851: Implement 
Parallel bus operations
date:   10 months ago
config: powerpc-randconfig-c024-20210321 (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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797047f875b5463719cc70ba213eb691d453c946
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 797047f875b5463719cc70ba213eb691d453c946
# 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 warnings (new ones prefixed by >>):

>> powerpc-linux-ld: warning: orphan section `.init.plt' from 
>> `drivers/net/ethernet/micrel/ks8851_common.o' being placed in section 
>> `.init.plt'
>> powerpc-linux-ld: warning: orphan section `.init.plt' from 
>> `drivers/net/ethernet/micrel/ks8851_common.o' being placed in section 
>> `.init.plt'
>> powerpc-linux-ld: warning: orphan section `.init.plt' from 
>> `drivers/net/ethernet/micrel/ks8851_common.o' being placed in section 
>> `.init.plt'

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


.config.gz
Description: application/gzip

[tip: irq/urgent] genirq: Disable interrupts for force threaded handlers

[tip-bot2 for Thomas Gleixner]

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

Commit-ID: 81e2073c175b887398e5bca6c004efa89983f58d
Gitweb:
https://git.kernel.org/tip/81e2073c175b887398e5bca6c004efa89983f58d
Author:Thomas Gleixner 
AuthorDate:Wed, 17 Mar 2021 15:38:52 +01:00
Committer: Thomas Gleixner 
CommitterDate: Sun, 21 Mar 2021 00:17:52 +01:00

genirq: Disable interrupts for force threaded handlers

With interrupt force threading all device interrupt handlers are invoked
from kernel threads. Contrary to hard interrupt context the invocation only
disables bottom halfs, but not interrupts. This was an oversight back then
because any code like this will have an issue:

thread(irq_A)
  irq_handler(A)
spin_lock(>lock);

interrupt(irq_B)
  irq_handler(B)
spin_lock(>lock);

This has been triggered with networking (NAPI vs. hrtimers) and console
drivers where printk() happens from an interrupt which interrupted the
force threaded handler.

Now people noticed and started to change the spin_lock() in the handler to
spin_lock_irqsave() which affects performance or add IRQF_NOTHREAD to the
interrupt request which in turn breaks RT.

Fix the root cause and not the symptom and disable interrupts before
invoking the force threaded handler which preserves the regular semantics
and the usefulness of the interrupt force threading as a general debugging
tool.

For not RT this is not changing much, except that during the execution of
the threaded handler interrupts are delayed until the handler
returns. Vs. scheduling and softirq processing there is no difference.

For RT kernels there is no issue.

Fixes: 8d32a307e4fa ("genirq: Provide forced interrupt threading")
Reported-by: Johan Hovold 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Johan Hovold 
Acked-by: Sebastian Andrzej Siewior 
Link: https://lore.kernel.org/r/20210317143859.513307...@linutronix.de

---
 kernel/irq/manage.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index dec3f73..21ea370 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1142,11 +1142,15 @@ irq_forced_thread_fn(struct irq_desc *desc, struct 
irqaction *action)
irqreturn_t ret;
 
local_bh_disable();
+   if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+   local_irq_disable();
ret = action->thread_fn(action->irq, action->dev_id);
if (ret == IRQ_HANDLED)
atomic_inc(>threads_handled);
 
irq_finalize_oneshot(desc, action);
+   if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+   local_irq_enable();
local_bh_enable();
return ret;
 }

Re: [PATCH] watchdog: Fix a typo

[Guenter Roeck]

On 3/20/21 2:33 PM, Bhaskar Chowdhury wrote:
> s/parmeter/parameter/
> 
> Signed-off-by: Bhaskar Chowdhury 


Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/sl28cpld_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/sl28cpld_wdt.c b/drivers/watchdog/sl28cpld_wdt.c
> index a45047d8d9ab..2de93298475f 100644
> --- a/drivers/watchdog/sl28cpld_wdt.c
> +++ b/drivers/watchdog/sl28cpld_wdt.c
> @@ -164,7 +164,7 @@ static int sl28cpld_wdt_probe(struct platform_device 
> *pdev)
> 
>   /*
>* Initial timeout value, may be overwritten by device tree or module
> -  * parmeter in watchdog_init_timeout().
> +  * parameter in watchdog_init_timeout().
>*
>* Reading a zero here means that either the hardware has a default
>* value of zero (which is very unlikely and definitely a hardware
> --
> 2.26.2
> 

Re: [PATCH V4] clk: imx: Fix reparenting of UARTs not associated with stdout

[Adam Ford]

On Sun, Mar 14, 2021 at 4:40 AM Ahmad Fatoum  wrote:
>
> On 13.03.21 16:16, Ahmad Fatoum wrote:
> >> +/* i.MX boards use device trees now.  For build tests without CONFIG_OF, 
> >> do nothing */
> >> +#ifdef CONFIG_OF
> >>  if (imx_keep_uart_clocks) {
> >>  int i;
> >>
> >> -imx_uart_clocks = clks;
> >> -for (i = 0; imx_uart_clocks[i]; i++)
> >> -clk_prepare_enable(*imx_uart_clocks[i]);
> >> +imx_uart_clocks = kcalloc(clk_count, sizeof(struct clk *), 
> >> GFP_KERNEL);
> >> +
> >> +if (!of_stdout)
> >> +return;
> >
> > Memory leak. Just do if (imx_keep_uart_clocks && of_stdout)
>
> Please dismiss. I overlooked that you free it in a later initcall.

Abel,

Are you OK with this?  I also have a V5 posted [1] which does what
Ahmad suggested.

Either of these will fix reparenting issues, but I need this for
Bluetooth to operate correctly, because both beacon imx8mn and imx8mn
kits switch the UART parent to an 80MHz clock in order to run at
4Mbps.

thank you,

adam
>
> >>  static int __init imx_clk_disable_uart(void)
> >>  {
> >> -if (imx_keep_uart_clocks && imx_uart_clocks) {
> >> +if (imx_keep_uart_clocks && imx_enabled_uart_clocks) {
> >>  int i;
> >>
> >> -for (i = 0; imx_uart_clocks[i]; i++)
> >> -clk_disable_unprepare(*imx_uart_clocks[i]);
> >> +for (i = 0; i < imx_enabled_uart_clocks; i++) {
> >> +clk_disable_unprepare(imx_uart_clocks[i]);
> >> +clk_put(imx_uart_clocks[i]);
> >> +};
> >> +kfree(imx_uart_clocks);
> >>  }
>
> --
> Pengutronix e.K.   | |
> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCHSET 0/2] PF_IO_WORKER signal tweaks

[Jens Axboe]

On 3/20/21 1:18 PM, Linus Torvalds wrote:
> On Sat, Mar 20, 2021 at 10:51 AM Linus Torvalds
>  wrote:
>>
>> Alternatively, make it not use
>> CLONE_SIGHAND|CLONE_THREAD at all, but that would make it
>> unnecessarily allocate its own signal state, so that's "cleaner" but
>> not great either.
> 
> Thinking some more about that, it would be problematic for things like
> the resource counters too. They'd be much better shared.
> 
> Not adding it to the thread list etc might be clever, but feels a bit too 
> scary.

That would be my immediate concern - it might very well be the right long
term solution, but I'd be wary of doing it upfront and having weird fallout
due to it.

> So on the whole I think Jens' minor patches to just not have IO helper
> threads accept signals are probably the right thing to do.

I do think we should just go with those two - they are simple and
straight forward. I'm also totally fine replacing 2/2 with Eric's
variant if he prefers that, I've confirmed that it works fine for me as
well.

-- 
Jens Axboe

Re: [PATCHSET 0/2] PF_IO_WORKER signal tweaks

[Jens Axboe]

On 3/20/21 4:08 PM, Eric W. Biederman wrote:
> 
> Added criu because I just realized that io_uring (which can open files
> from an io worker thread) looks to require some special handling for
> stopping and freezing processes.  If not in the SIGSTOP case in the
> related cgroup freezer case.
> 
> Linus Torvalds  writes:
> 
>> On Sat, Mar 20, 2021 at 10:51 AM Linus Torvalds
>>  wrote:
>>>
>>> Alternatively, make it not use
>>> CLONE_SIGHAND|CLONE_THREAD at all, but that would make it
>>> unnecessarily allocate its own signal state, so that's "cleaner" but
>>> not great either.
>>
>> Thinking some more about that, it would be problematic for things like
>> the resource counters too. They'd be much better shared.
>>
>> Not adding it to the thread list etc might be clever, but feels a bit too 
>> scary.
>>
>> So on the whole I think Jens' minor patches to just not have IO helper
>> threads accept signals are probably the right thing to do.
> 
> The way I see it we have two options:
> 
> 1) Don't ask PF_IO_WORKERs to stop do_signal_stop and in
>task_join_group_stop.
> 
>The easiest comprehensive implementation looks like just
>updating task_set_jobctl_pending to treat PF_IO_WORKER
>as it treats PF_EXITING.
> 
> 2) Have the main loop of the kernel thread test for JOBCTL_STOP_PENDING
>and call into do_signal_stop.
> 
> It is a wee bit trickier to modify the io_workers to stop, but it does
> not look prohibitively difficult.
> 
> All of the work performed by the io worker is work scheduled via
> io_uring by the process being stopped.
> 
> - Is the amount of work performed by the io worker thread sufficiently
>   negligible that we don't care?
> 
> - Or is the amount of work performed by the io worker so great that it
>   becomes a way for an errant process to escape SIGSTOP?
> 
> As the code is all intermingled with the cgroup_freezer.  I am also
> wondering creating checkpoints needs additional stopping guarantees.

The work done is the same a syscall, basically. So it could be long
running and essentially not doing anything (eg read from a socket, no
data is there), or it's pretty short lived (eg read from a file, just
waiting on DMA).

This is outside of my domain of expertise, which is exactly why I added
you and Linus to make some calls on what the best approach here would
be. My two patches obviously go route #1 in terms of STOP. And fwiw,
I tested this:

> To solve the issue that SIGSTOP is simply broken right now I am totally
> fine with something like:
> 
> diff --git a/kernel/signal.c b/kernel/signal.c
> index ba4d1ef39a9e..cb9acdfb32fa 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -288,7 +288,8 @@ bool task_set_jobctl_pending(struct task_struct *task, 
> unsigned long mask)
>   JOBCTL_STOP_SIGMASK | JOBCTL_TRAPPING));
>   BUG_ON((mask & JOBCTL_TRAPPING) && !(mask & JOBCTL_PENDING_MASK));
>  
> - if (unlikely(fatal_signal_pending(task) || (task->flags & PF_EXITING)))
> + if (unlikely(fatal_signal_pending(task) ||
> +  (task->flags & (PF_EXITING | PF_IO_WORKER
>   return false;
>  
>   if (mask & JOBCTL_STOP_SIGMASK)

and can confirm it works fine for me with 2/2 reverted and this applied
instead.

> Which just keeps from creating unstoppable processes today.  I am just
> not convinced that is what we want as a long term solution.

How about we go with either my 2/2 or yours above to at least ensure we
don't leave workers looping as schedule() is a nop with sigpending? If
there's a longer timeline concern that "evading" SIGSTOP is a concern, I
have absolutely no qualms with making the IO threads participate. But
since it seems conceptually simple but with potentially lurking minor
issues, probably not the ideal approach for right now.

-- 
Jens Axboe

Re: [PATCH v4 3/3] mm: fs: Invalidate BH LRU during page migration

[Chris Goldsworthy]

On 2021-03-20 12:54, Matthew Wilcox wrote:

On Sat, Mar 20, 2021 at 10:20:09AM -0700, Minchan Kim wrote:

> > Tested-by: Oliver Sang 
> > Reported-by: kernel test robot 
> > Signed-off-by: Chris Goldsworthy 
> > Signed-off-by: Minchan Kim 
>
> The signoff chain ordering might mean that Chris was the primary author, but
> there is no From:him.  Please clarify?

He tried first version but was diffrent implementation since I
changed a lot. That's why I added his SoB even though current
implementaion is much different. So, maybe I am primary author?


Hey Minchan, let's have you as the primary author.

Maybe Chris is Reported-by: ?  And don't forget Laura Abbott as 
original
author of the patch Chris submitted.  I think she should be 
Reported-by:

as well, since there is no code from either of them in this version of
the patch.


Yes, let's have a Reported-by: from Laura. We can change my 
Signed-off-by to Reported-by: as well.


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

a Linux Foundation Collaborative Project

Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads

[Jens Axboe]

On 3/20/21 3:38 PM, Eric W. Biederman wrote:
> Linus Torvalds  writes:
> 
>> On Sat, Mar 20, 2021 at 9:19 AM Eric W. Biederman  
>> wrote:
>>>
>>> The creds should be reasonably in-sync with the rest of the threads.
>>
>> It's not about credentials (despite the -EPERM).
>>
>> It's about the fact that kernel threads cannot handle signals, and
>> then get caught in endless loops of "if (sigpending()) return
>> -EAGAIN".
>>
>> For a normal user thread, that "return -EAGAIN" (or whatever) will end
>> up returning an error to user space - and before it does that, it will
>> go through the "oh, returning to user space, so handle signal" path.
>> Which will clear sigpending etc.
>>
>> A thread that never returns to user space fundamentally cannot handle
>> this. The sigpending() stays on forever, the signal never gets
>> handled, the thread can't do anything.
>>
>> So delivering a signal to a kernel thread fundamentally cannot work
>> (although we do have some threads that explicitly see "oh, if I was
>> killed, I will exit" - think things like in-kernel nfsd etc).
> 
> I agree that getting a kernel thread to receive a signal is quite
> tricky.  But that is not what the patch affects.
> 
> The patch covers the case when instead of specifying the pid of the
> process to kill(2) someone specifies the tid of a thread.  Which implies
> that type is PIDTYPE_TGID, and in turn the signal is being placed on the
> t->signal->shared_pending queue.  Not the thread specific t->pending
> queue.
> 
> So my question is since the signal is delivered to the process as a
> whole why do we care if someone specifies the tid of a kernel thread,
> rather than the tid of a userspace thread?

Right, that's what this first patch does, and in all honesty, it's not
required like the 2/2 patch is. I do think it makes it more consistent,
though - the threads don't take signals, period. Allowing delivery from
eg kill(2) and then pass it to the owning task of the io_uring is
somewhat counterintuitive, and differs from earlier kernels where there
was no relationsship between that owning task and the async worker
thread.

That's why I think the patch DOES make sense. These threads may share a
personality with the owning task, but I don't think we should be able to
manipulate them from userspace at all. That includes SIGSTOP, of course,
but also regular signals.

Hence I do think we should do something like this.

-- 
Jens Axboe

Re: [PATCH] powerpc: epapr: A typo fix

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/parmeters/parameters/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
arch/powerpc/include/asm/epapr_hcalls.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/epapr_hcalls.h 
b/arch/powerpc/include/asm/epapr_hcalls.h
index c99ba08a408d..cdf3c6df5123 100644
--- a/arch/powerpc/include/asm/epapr_hcalls.h
+++ b/arch/powerpc/include/asm/epapr_hcalls.h
@@ -65,7 +65,7 @@
 * but the gcc inline assembly syntax does not allow us to specify registers
 * on the clobber list that are also on the input/output list.  Therefore,
 * the lists of clobbered registers depends on the number of register
- * parmeters ("+r" and "=r") passed to the hypercall.
+ * parameters ("+r" and "=r") passed to the hypercall.
 *
 * Each assembly block should use one of the HCALL_CLOBBERSx macros.  As a
 * general rule, 'x' is the number of parameters passed to the assembly
--
2.26.2

Re: [PATCH] watchdog: Fix a typo

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:


s/parmeter/parameter/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
drivers/watchdog/sl28cpld_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/sl28cpld_wdt.c b/drivers/watchdog/sl28cpld_wdt.c
index a45047d8d9ab..2de93298475f 100644
--- a/drivers/watchdog/sl28cpld_wdt.c
+++ b/drivers/watchdog/sl28cpld_wdt.c
@@ -164,7 +164,7 @@ static int sl28cpld_wdt_probe(struct platform_device *pdev)

/*
 * Initial timeout value, may be overwritten by device tree or module
-* parmeter in watchdog_init_timeout().
+* parameter in watchdog_init_timeout().
 *
 * Reading a zero here means that either the hardware has a default
 * value of zero (which is very unlikely and definitely a hardware
--
2.26.2

Re: [PATCH] drm/vmwgfx: Fix a typo

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/particuar/particular/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_so.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
index 7369dd86d3a9..6cd38e407145 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
@@ -33,7 +33,7 @@
 * The currently only reason we need to keep track of views is that if we
 * destroy a hardware surface, all views pointing to it must also be destroyed,
 * otherwise the device will error.
- * So in particuar if a surface is evicted, we must destroy all views pointing
+ * So in particular if a surface is evicted, we must destroy all views pointing
 * to it, and all context bindings of that view. Similarly we must restore
 * the view bindings, views and surfaces pointed to by the views when a
 * context is referenced in the command stream.
--
2.26.2

Re: [PATCH] docs: networking: Fix a typo

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/subsytem/subsystem/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
Documentation/networking/xfrm_device.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/networking/xfrm_device.rst 
b/Documentation/networking/xfrm_device.rst
index da1073acda96..01391dfd37d9 100644
--- a/Documentation/networking/xfrm_device.rst
+++ b/Documentation/networking/xfrm_device.rst
@@ -50,7 +50,7 @@ Callbacks to implement

The NIC driver offering ipsec offload will need to implement these
callbacks to make the offload available to the network stack's
-XFRM subsytem.  Additionally, the feature bits NETIF_F_HW_ESP and
+XFRM subsystem.  Additionally, the feature bits NETIF_F_HW_ESP and
NETIF_F_HW_ESP_TX_CSUM will signal the availability of the offload.


--
2.26.2

Re: [PATCH] nvme-fc: Few trivial spelling fixes

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/boundarys/boundaries/ . two different places
s/assocated/associated/
s/compeletion/completion/
s/tranferred/transferred/
s/subsytem/subsystem/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
include/linux/nvme-fc-driver.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/nvme-fc-driver.h b/include/linux/nvme-fc-driver.h
index 2a38f2b477a5..8624b0c6aace 100644
--- a/include/linux/nvme-fc-driver.h
+++ b/include/linux/nvme-fc-driver.h
@@ -441,7 +441,7 @@ struct nvme_fc_remote_port {
 * @dma_boundary:  indicates the dma address boundary where dma mappings
 *   will be split across.
 *   Value is Mandatory. Typical value is 0x to split across
- *   4Gig address boundarys
+ *   4Gig address boundaries
 *
 * @local_priv_sz: The LLDD sets this field to the amount of additional
 *   memory that it would like fc nvme layer to allocate on the LLDD's
@@ -608,7 +608,7 @@ enum {
 *
 * Structure used between LLDD and nvmet-fc layer to represent the exchange
 * context for a FC-NVME FCP I/O operation (e.g. a nvme sqe, the sqe-related
- * memory transfers, and its assocated cqe transfer).
+ * memory transfers, and its associated cqe transfer).
 *
 * The structure is allocated by the LLDD whenever a FCP CMD IU is received
 * from the FC link. The address of the structure is passed to the nvmet-fc
@@ -631,7 +631,7 @@ enum {
 *   When the structure is used for an FCP target operation, the nvmet-fc
 * layer will fully set the fields in order to specify the scattergather
 * list, the transfer length, as well as the done routine to be called
- * upon compeletion of the operation.  The nvmet-fc layer will also set a
+ * upon completion of the operation.  The nvmet-fc layer will also set a
 * private pointer for its own use in the done routine.
 *
 * Values set by the NVMET-FC layer prior to calling the LLDD fcp_op
@@ -640,7 +640,7 @@ enum {
 * @hwqid:Specifies the hw queue index (0..N-1, where N is the
 *max_hw_queues value from the LLD's nvmet_fc_target_template)
 *that the operation is to use.
- * @offset:   Indicates the DATA_OUT/DATA_IN payload offset to be tranferred.
+ * @offset:   Indicates the DATA_OUT/DATA_IN payload offset to be transferred.
 *Field is only valid on WRITEDATA, READDATA, or READDATA_RSP ops.
 * @timeout:  amount of time, in seconds, to wait for a response from the NVME
 *host. A value of 0 is an infinite wait.
@@ -718,7 +718,7 @@ enum {
 *
 * Fields with static values for the port. Initialized by the
 * port_info struct supplied to the registration call.
- * @port_num:  NVME-FC transport subsytem port number
+ * @port_num:  NVME-FC transport subsystem port number
 * @node_name: FC WWNN for the port
 * @port_name: FC WWPN for the port
 * @private:   pointer to memory allocated alongside the local port
@@ -919,7 +919,7 @@ struct nvmet_fc_target_port {
 * @dma_boundary:  indicates the dma address boundary where dma mappings
 *   will be split across.
 *   Value is Mandatory. Typical value is 0x to split across
- *   4Gig address boundarys
+ *   4Gig address boundaries
 *
 * @target_features: The LLDD sets bits in this field to correspond to
 *   optional features that are supported by the LLDD.
--
2.26.2

Re: [PATCH] driver core: Trivial typo fix

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:


s/subsytem/subsystem/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
include/linux/device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index ba660731bd25..a8ce0dc3b758 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -49,7 +49,7 @@ struct dev_iommu;
/**
 * struct subsys_interface - interfaces to device functions
 * @name:   name of the device function
- * @subsys: subsytem of the devices to attach to
+ * @subsys: subsystem of the devices to attach to
 * @node:   the list of functions registered at the subsystem
 * @add_dev:device hookup to device function handler
 * @remove_dev: device hookup to device function handler
--
2.26.2

[PATCH v3 net-next 12/12] net: ocelot: replay switchdev events when joining bridge

[Vladimir Oltean]

From: Vladimir Oltean 

The premise of this change is that the switchdev port attributes and
objects offloaded by ocelot might have been missed when we are joining
an already existing bridge port, such as a bonding interface.

The patch pulls these switchdev attributes and objects from the bridge,
on behalf of the 'bridge port' net device which might be either the
ocelot switch interface, or the bonding upper interface.

The ocelot_net.c belongs strictly to the switchdev ocelot driver, while
ocelot.c is part of a library shared with the DSA felix driver.
The ocelot_port_bridge_leave function (part of the common library) used
to call ocelot_port_vlan_filtering(false), something which is not
necessary for DSA, since the framework deals with that already there.
So we move this function to ocelot_switchdev_unsync, which is specific
to the switchdev driver.

The code movement described above makes ocelot_port_bridge_leave no
longer return an error code, so we change its type from int to void.

Signed-off-by: Vladimir Oltean 
---
Changes in v3:
Added -EOPNOTSUPP to br_mdb_replay and br_vlan_replay, which can be
compiled out.

 drivers/net/dsa/ocelot/felix.c |   4 +-
 drivers/net/ethernet/mscc/ocelot.c |  18 ++--
 drivers/net/ethernet/mscc/ocelot_net.c | 117 +
 include/soc/mscc/ocelot.h  |   6 +-
 4 files changed, 111 insertions(+), 34 deletions(-)

diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 628afb47b579..6b5442be0230 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -719,7 +719,9 @@ static int felix_bridge_join(struct dsa_switch *ds, int 
port,
 {
struct ocelot *ocelot = ds->priv;
 
-   return ocelot_port_bridge_join(ocelot, port, br);
+   ocelot_port_bridge_join(ocelot, port, br);
+
+   return 0;
 }
 
 static void felix_bridge_leave(struct dsa_switch *ds, int port,
diff --git a/drivers/net/ethernet/mscc/ocelot.c 
b/drivers/net/ethernet/mscc/ocelot.c
index ce57929ba3d1..1a36b416fd9b 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1514,34 +1514,28 @@ int ocelot_port_mdb_del(struct ocelot *ocelot, int port,
 }
 EXPORT_SYMBOL(ocelot_port_mdb_del);
 
-int ocelot_port_bridge_join(struct ocelot *ocelot, int port,
-   struct net_device *bridge)
+void ocelot_port_bridge_join(struct ocelot *ocelot, int port,
+struct net_device *bridge)
 {
struct ocelot_port *ocelot_port = ocelot->ports[port];
 
ocelot_port->bridge = bridge;
 
-   return 0;
+   ocelot_apply_bridge_fwd_mask(ocelot);
 }
 EXPORT_SYMBOL(ocelot_port_bridge_join);
 
-int ocelot_port_bridge_leave(struct ocelot *ocelot, int port,
-struct net_device *bridge)
+void ocelot_port_bridge_leave(struct ocelot *ocelot, int port,
+ struct net_device *bridge)
 {
struct ocelot_port *ocelot_port = ocelot->ports[port];
struct ocelot_vlan pvid = {0}, native_vlan = {0};
-   int ret;
 
ocelot_port->bridge = NULL;
 
-   ret = ocelot_port_vlan_filtering(ocelot, port, false);
-   if (ret)
-   return ret;
-
ocelot_port_set_pvid(ocelot, port, pvid);
ocelot_port_set_native_vlan(ocelot, port, native_vlan);
-
-   return 0;
+   ocelot_apply_bridge_fwd_mask(ocelot);
 }
 EXPORT_SYMBOL(ocelot_port_bridge_leave);
 
diff --git a/drivers/net/ethernet/mscc/ocelot_net.c 
b/drivers/net/ethernet/mscc/ocelot_net.c
index d1376f7b34fd..36f32a4d9b0f 100644
--- a/drivers/net/ethernet/mscc/ocelot_net.c
+++ b/drivers/net/ethernet/mscc/ocelot_net.c
@@ -1117,47 +1117,126 @@ static int ocelot_port_obj_del(struct net_device *dev,
return ret;
 }
 
+static void ocelot_inherit_brport_flags(struct ocelot *ocelot, int port,
+   struct net_device *brport_dev)
+{
+   struct switchdev_brport_flags flags = {0};
+   int flag;
+
+   flags.mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
+
+   for_each_set_bit(flag, , 32)
+   if (br_port_flag_is_set(brport_dev, BIT(flag)))
+   flags.val |= BIT(flag);
+
+   ocelot_port_bridge_flags(ocelot, port, flags);
+}
+
+static void ocelot_clear_brport_flags(struct ocelot *ocelot, int port)
+{
+   struct switchdev_brport_flags flags;
+
+   flags.mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
+   flags.val = flags.mask & ~BR_LEARNING;
+
+   ocelot_port_bridge_flags(ocelot, port, flags);
+}
+
+static int ocelot_switchdev_sync(struct ocelot *ocelot, int port,
+struct net_device *brport_dev,
+struct net_device *bridge_dev,
+struct netlink_ext_ack *extack)
+{
+   clock_t ageing_time;
+   u8 stp_state;
+   int err;
+
+   

[PATCH v3 net-next 11/12] net: ocelot: call ocelot_netdevice_bridge_join when joining a bridged LAG

[Vladimir Oltean]

From: Vladimir Oltean 

Similar to the DSA situation, ocelot supports LAG offload but treats
this scenario improperly:

ip link add br0 type bridge
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0

We do the same thing as we do there, which is to simulate a 'bridge join'
on 'lag join', if we detect that the bonding upper has a bridge upper.

Again, same as DSA, ocelot supports software fallback for LAG, and in
that case, we should avoid calling ocelot_netdevice_changeupper.

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

 drivers/net/ethernet/mscc/ocelot_net.c | 111 +++--
 1 file changed, 86 insertions(+), 25 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_net.c 
b/drivers/net/ethernet/mscc/ocelot_net.c
index c08164cd88f4..d1376f7b34fd 100644
--- a/drivers/net/ethernet/mscc/ocelot_net.c
+++ b/drivers/net/ethernet/mscc/ocelot_net.c
@@ -1117,10 +1117,15 @@ static int ocelot_port_obj_del(struct net_device *dev,
return ret;
 }
 
-static int ocelot_netdevice_bridge_join(struct ocelot *ocelot, int port,
-   struct net_device *bridge)
+static int ocelot_netdevice_bridge_join(struct net_device *dev,
+   struct net_device *bridge,
+   struct netlink_ext_ack *extack)
 {
+   struct ocelot_port_private *priv = netdev_priv(dev);
+   struct ocelot_port *ocelot_port = >port;
+   struct ocelot *ocelot = ocelot_port->ocelot;
struct switchdev_brport_flags flags;
+   int port = priv->chip_port;
int err;
 
flags.mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
@@ -1135,10 +1140,14 @@ static int ocelot_netdevice_bridge_join(struct ocelot 
*ocelot, int port,
return 0;
 }
 
-static int ocelot_netdevice_bridge_leave(struct ocelot *ocelot, int port,
+static int ocelot_netdevice_bridge_leave(struct net_device *dev,
 struct net_device *bridge)
 {
+   struct ocelot_port_private *priv = netdev_priv(dev);
+   struct ocelot_port *ocelot_port = >port;
+   struct ocelot *ocelot = ocelot_port->ocelot;
struct switchdev_brport_flags flags;
+   int port = priv->chip_port;
int err;
 
flags.mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
@@ -1151,43 +1160,89 @@ static int ocelot_netdevice_bridge_leave(struct ocelot 
*ocelot, int port,
return err;
 }
 
-static int ocelot_netdevice_changeupper(struct net_device *dev,
-   struct netdev_notifier_changeupper_info 
*info)
+static int ocelot_netdevice_lag_join(struct net_device *dev,
+struct net_device *bond,
+struct netdev_lag_upper_info *info,
+struct netlink_ext_ack *extack)
 {
struct ocelot_port_private *priv = netdev_priv(dev);
struct ocelot_port *ocelot_port = >port;
struct ocelot *ocelot = ocelot_port->ocelot;
+   struct net_device *bridge_dev;
int port = priv->chip_port;
+   int err;
+
+   err = ocelot_port_lag_join(ocelot, port, bond, info);
+   if (err == -EOPNOTSUPP) {
+   NL_SET_ERR_MSG_MOD(extack, "Offloading not supported");
+   return 0;
+   }
+
+   bridge_dev = netdev_master_upper_dev_get(bond);
+   if (!bridge_dev || !netif_is_bridge_master(bridge_dev))
+   return 0;
+
+   err = ocelot_netdevice_bridge_join(dev, bridge_dev, extack);
+   if (err)
+   goto err_bridge_join;
+
+   return 0;
+
+err_bridge_join:
+   ocelot_port_lag_leave(ocelot, port, bond);
+   return err;
+}
+
+static int ocelot_netdevice_lag_leave(struct net_device *dev,
+ struct net_device *bond)
+{
+   struct ocelot_port_private *priv = netdev_priv(dev);
+   struct ocelot_port *ocelot_port = >port;
+   struct ocelot *ocelot = ocelot_port->ocelot;
+   struct net_device *bridge_dev;
+   int port = priv->chip_port;
+
+   ocelot_port_lag_leave(ocelot, port, bond);
+
+   bridge_dev = netdev_master_upper_dev_get(bond);
+   if (!bridge_dev || !netif_is_bridge_master(bridge_dev))
+   return 0;
+
+   return ocelot_netdevice_bridge_leave(dev, bridge_dev);
+}
+
+static int ocelot_netdevice_changeupper(struct net_device *dev,
+   struct netdev_notifier_changeupper_info 
*info)
+{
+   struct netlink_ext_ack *extack;
int err = 0;
 
+   extack = netdev_notifier_info_to_extack(>info);
+
if (netif_is_bridge_master(info->upper_dev)) {
-   if (info->linking) {
-   err = ocelot_netdevice_bridge_join(ocelot, port,
-  info->upper_dev);
-   } else {
-   

[PATCH v3 net-next 10/12] net: dsa: replay VLANs installed on port when joining the bridge

[Vladimir Oltean]

From: Vladimir Oltean 

Currently this simple setup:

ip link add br0 type bridge vlan_filtering 1
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0

will not work because the bridge has created the PVID in br_add_if ->
nbp_vlan_init, and it has notified switchdev of the existence of VLAN 1,
but that was too early, since swp0 was not yet a lower of bond0, so it
had no reason to act upon that notification.

Signed-off-by: Vladimir Oltean 
---
Changes in v3:
Made the br_vlan_replay shim return -EOPNOTSUPP.

 include/linux/if_bridge.h | 10 ++
 net/bridge/br_vlan.c  | 71 +++
 net/dsa/port.c|  6 
 3 files changed, 87 insertions(+)

diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index b564c4486a45..2cc35038a8ca 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -111,6 +111,8 @@ int br_vlan_get_pvid_rcu(const struct net_device *dev, u16 
*p_pvid);
 int br_vlan_get_proto(const struct net_device *dev, u16 *p_proto);
 int br_vlan_get_info(const struct net_device *dev, u16 vid,
 struct bridge_vlan_info *p_vinfo);
+int br_vlan_replay(struct net_device *br_dev, struct net_device *dev,
+  struct notifier_block *nb, struct netlink_ext_ack *extack);
 #else
 static inline bool br_vlan_enabled(const struct net_device *dev)
 {
@@ -137,6 +139,14 @@ static inline int br_vlan_get_info(const struct net_device 
*dev, u16 vid,
 {
return -EINVAL;
 }
+
+static inline int br_vlan_replay(struct net_device *br_dev,
+struct net_device *dev,
+struct notifier_block *nb,
+struct netlink_ext_ack *extack)
+{
+   return -EOPNOTSUPP;
+}
 #endif
 
 #if IS_ENABLED(CONFIG_BRIDGE)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 8829f621b8ec..45a4eac1b217 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -1751,6 +1751,77 @@ void br_vlan_notify(const struct net_bridge *br,
kfree_skb(skb);
 }
 
+static int br_vlan_replay_one(struct notifier_block *nb,
+ struct net_device *dev,
+ struct switchdev_obj_port_vlan *vlan,
+ struct netlink_ext_ack *extack)
+{
+   struct switchdev_notifier_port_obj_info obj_info = {
+   .info = {
+   .dev = dev,
+   .extack = extack,
+   },
+   .obj = >obj,
+   };
+   int err;
+
+   err = nb->notifier_call(nb, SWITCHDEV_PORT_OBJ_ADD, _info);
+   return notifier_to_errno(err);
+}
+
+int br_vlan_replay(struct net_device *br_dev, struct net_device *dev,
+  struct notifier_block *nb, struct netlink_ext_ack *extack)
+{
+   struct net_bridge_vlan_group *vg;
+   struct net_bridge_vlan *v;
+   struct net_bridge_port *p;
+   struct net_bridge *br;
+   int err = 0;
+   u16 pvid;
+
+   ASSERT_RTNL();
+
+   if (!netif_is_bridge_master(br_dev))
+   return -EINVAL;
+
+   if (!netif_is_bridge_master(dev) && !netif_is_bridge_port(dev))
+   return -EINVAL;
+
+   if (netif_is_bridge_master(dev)) {
+   br = netdev_priv(dev);
+   vg = br_vlan_group(br);
+   p = NULL;
+   } else {
+   p = br_port_get_rtnl(dev);
+   if (WARN_ON(!p))
+   return -EINVAL;
+   vg = nbp_vlan_group(p);
+   br = p->br;
+   }
+
+   if (!vg)
+   return 0;
+
+   pvid = br_get_pvid(vg);
+
+   list_for_each_entry(v, >vlan_list, vlist) {
+   struct switchdev_obj_port_vlan vlan = {
+   .obj.orig_dev = dev,
+   .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
+   .flags = br_vlan_flags(v, pvid),
+   .vid = v->vid,
+   };
+
+   if (!br_vlan_should_use(v))
+   continue;
+
+   br_vlan_replay_one(nb, dev, , extack);
+   if (err)
+   return err;
+   }
+
+   return err;
+}
 /* check if v_curr can enter a range ending in range_end */
 bool br_vlan_can_enter_range(const struct net_bridge_vlan *v_curr,
 const struct net_bridge_vlan *range_end)
diff --git a/net/dsa/port.c b/net/dsa/port.c
index d21a511f1e16..84775e253ee8 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -209,6 +209,12 @@ static int dsa_port_switchdev_sync(struct dsa_port *dp,
if (err && err != -EOPNOTSUPP)
return err;
 
+   err = br_vlan_replay(br, brport_dev,
+_slave_switchdev_blocking_notifier,
+extack);
+   if (err && err != -EOPNOTSUPP)
+   return err;
+
return 0;
 }
 
-- 
2.25.1

[PATCH v3 net-next 09/12] net: dsa: replay port and local fdb entries when joining the bridge

[Vladimir Oltean]

From: Vladimir Oltean 

When a DSA port joins a LAG that already had an FDB entry pointing to it:

ip link set bond0 master br0
bridge fdb add dev bond0 00:01:02:03:04:05 master static
ip link set swp0 master bond0

the DSA port will have no idea that this FDB entry is there, because it
missed the switchdev event emitted at its creation.

Ido Schimmel pointed this out during a discussion about challenges with
switchdev offloading of stacked interfaces between the physical port and
the bridge, and recommended to just catch that condition and deny the
CHANGEUPPER event:
https://lore.kernel.org/netdev/20210210105949.gb287...@shredder.lan/

But in fact, we might need to deal with the hard thing anyway, which is
to replay all FDB addresses relevant to this port, because it isn't just
static FDB entries, but also local addresses (ones that are not
forwarded but terminated by the bridge). There, we can't just say 'oh
yeah, there was an upper already so I'm not joining that'.

So, similar to the logic for replaying MDB entries, add a function that
must be called by individual switchdev drivers and replays local FDB
entries as well as ones pointing towards a bridge port. This time, we
use the atomic switchdev notifier block, since that's what FDB entries
expect for some reason.

Reported-by: Ido Schimmel 
Signed-off-by: Vladimir Oltean 
---
Changes in v3:
Made the br_fdb_replay shim return -EOPNOTSUPP.

 include/linux/if_bridge.h |  9 +++
 include/net/switchdev.h   |  1 +
 net/bridge/br_fdb.c   | 52 +++
 net/dsa/dsa_priv.h|  1 +
 net/dsa/port.c|  4 +++
 net/dsa/slave.c   |  2 +-
 6 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index f6472969bb44..b564c4486a45 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -147,6 +147,8 @@ void br_fdb_clear_offload(const struct net_device *dev, u16 
vid);
 bool br_port_flag_is_set(const struct net_device *dev, unsigned long flag);
 u8 br_port_get_stp_state(const struct net_device *dev);
 clock_t br_get_ageing_time(struct net_device *br_dev);
+int br_fdb_replay(struct net_device *br_dev, struct net_device *dev,
+ struct notifier_block *nb);
 #else
 static inline struct net_device *
 br_fdb_find_port(const struct net_device *br_dev,
@@ -175,6 +177,13 @@ static inline clock_t br_get_ageing_time(struct net_device 
*br_dev)
 {
return 0;
 }
+
+static inline int br_fdb_replay(struct net_device *br_dev,
+   struct net_device *dev,
+   struct notifier_block *nb)
+{
+   return -EOPNOTSUPP;
+}
 #endif
 
 #endif
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index b7fc7d0f54e2..7688ec572757 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -205,6 +205,7 @@ struct switchdev_notifier_info {
 
 struct switchdev_notifier_fdb_info {
struct switchdev_notifier_info info; /* must be first */
+   struct list_head list;
const unsigned char *addr;
u16 vid;
u8 added_by_user:1,
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index b7490237f3fc..49125cc196ac 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -726,6 +726,58 @@ static inline size_t fdb_nlmsg_size(void)
+ nla_total_size(sizeof(u8)); /* NFEA_ACTIVITY_NOTIFY */
 }
 
+static int br_fdb_replay_one(struct notifier_block *nb,
+struct net_bridge_fdb_entry *fdb,
+struct net_device *dev)
+{
+   struct switchdev_notifier_fdb_info item;
+   int err;
+
+   item.addr = fdb->key.addr.addr;
+   item.vid = fdb->key.vlan_id;
+   item.added_by_user = test_bit(BR_FDB_ADDED_BY_USER, >flags);
+   item.offloaded = test_bit(BR_FDB_OFFLOADED, >flags);
+   item.info.dev = dev;
+
+   err = nb->notifier_call(nb, SWITCHDEV_FDB_ADD_TO_DEVICE, );
+   return notifier_to_errno(err);
+}
+
+int br_fdb_replay(struct net_device *br_dev, struct net_device *dev,
+ struct notifier_block *nb)
+{
+   struct net_bridge_fdb_entry *fdb;
+   struct net_bridge *br;
+   int err = 0;
+
+   if (!netif_is_bridge_master(br_dev))
+   return -EINVAL;
+
+   if (!netif_is_bridge_port(dev))
+   return -EINVAL;
+
+   br = netdev_priv(br_dev);
+
+   rcu_read_lock();
+
+   hlist_for_each_entry_rcu(fdb, >fdb_list, fdb_node) {
+   struct net_device *dst_dev;
+
+   dst_dev = fdb->dst ? fdb->dst->dev : br->dev;
+   if (dst_dev != br_dev && dst_dev != dev)
+   continue;
+
+   err = br_fdb_replay_one(nb, fdb, dst_dev);
+   if (err)
+   break;
+   }
+
+   rcu_read_unlock();
+
+   return err;
+}
+EXPORT_SYMBOL(br_fdb_replay);
+
 static void fdb_notify(struct net_bridge *br,
  

[PATCH v3 net-next 08/12] net: dsa: replay port and host-joined mdb entries when joining the bridge

[Vladimir Oltean]

From: Vladimir Oltean 

I have udhcpcd in my system and this is configured to bring interfaces
up as soon as they are created.

I create a bridge as follows:

ip link add br0 type bridge

As soon as I create the bridge and udhcpcd brings it up, I also have
avahi which automatically starts sending IPv6 packets to advertise some
local services, and because of that, the br0 bridge joins the following
IPv6 groups due to the code path detailed below:

33:33:ff:6d:c1:9c vid 0
33:33:00:00:00:6a vid 0
33:33:00:00:00:fb vid 0

br_dev_xmit
-> br_multicast_rcv
   -> br_ip6_multicast_add_group
  -> __br_multicast_add_group
 -> br_multicast_host_join
-> br_mdb_notify

This is all fine, but inside br_mdb_notify we have br_mdb_switchdev_host
hooked up, and switchdev will attempt to offload the host joined groups
to an empty list of ports. Of course nobody offloads them.

Then when we add a port to br0:

ip link set swp0 master br0

the bridge doesn't replay the host-joined MDB entries from br_add_if,
and eventually the host joined addresses expire, and a switchdev
notification for deleting it is emitted, but surprise, the original
addition was already completely missed.

The strategy to address this problem is to replay the MDB entries (both
the port ones and the host joined ones) when the new port joins the
bridge, similar to what vxlan_fdb_replay does (in that case, its FDB can
be populated and only then attached to a bridge that you offload).
However there are 2 possibilities: the addresses can be 'pushed' by the
bridge into the port, or the port can 'pull' them from the bridge.

Considering that in the general case, the new port can be really late to
the party, and there may have been many other switchdev ports that
already received the initial notification, we would like to avoid
delivering duplicate events to them, since they might misbehave. And
currently, the bridge calls the entire switchdev notifier chain, whereas
for replaying it should just call the notifier block of the new guy.
But the bridge doesn't know what is the new guy's notifier block, it
just knows where the switchdev notifier chain is. So for simplification,
we make this a driver-initiated pull for now, and the notifier block is
passed as an argument.

To emulate the calling context for mdb objects (deferred and put on the
blocking notifier chain), we must iterate under RCU protection through
the bridge's mdb entries, queue them, and only call them once we're out
of the RCU read-side critical section.

Suggested-by: Ido Schimmel 
Signed-off-by: Vladimir Oltean 
---
Changes in v3:
- Removed the implication that avahi is crap from the commit message.
- Made the br_mdb_replay shim return -EOPNOTSUPP.

 include/linux/if_bridge.h |  9 +
 net/bridge/br_mdb.c   | 84 +++
 net/dsa/dsa_priv.h|  2 +
 net/dsa/port.c|  6 +++
 net/dsa/slave.c   |  2 +-
 5 files changed, 102 insertions(+), 1 deletion(-)

diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index ebd16495459c..f6472969bb44 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -69,6 +69,8 @@ bool br_multicast_has_querier_anywhere(struct net_device 
*dev, int proto);
 bool br_multicast_has_querier_adjacent(struct net_device *dev, int proto);
 bool br_multicast_enabled(const struct net_device *dev);
 bool br_multicast_router(const struct net_device *dev);
+int br_mdb_replay(struct net_device *br_dev, struct net_device *dev,
+ struct notifier_block *nb, struct netlink_ext_ack *extack);
 #else
 static inline int br_multicast_list_adjacent(struct net_device *dev,
 struct list_head *br_ip_list)
@@ -93,6 +95,13 @@ static inline bool br_multicast_router(const struct 
net_device *dev)
 {
return false;
 }
+static inline int br_mdb_replay(struct net_device *br_dev,
+   struct net_device *dev,
+   struct notifier_block *nb,
+   struct netlink_ext_ack *extack)
+{
+   return -EOPNOTSUPP;
+}
 #endif
 
 #if IS_ENABLED(CONFIG_BRIDGE) && IS_ENABLED(CONFIG_BRIDGE_VLAN_FILTERING)
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index 8846c5bcd075..23973186094c 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -506,6 +506,90 @@ static void br_mdb_complete(struct net_device *dev, int 
err, void *priv)
kfree(priv);
 }
 
+static int br_mdb_replay_one(struct notifier_block *nb, struct net_device *dev,
+struct net_bridge_mdb_entry *mp, int obj_id,
+struct net_device *orig_dev,
+struct netlink_ext_ack *extack)
+{
+   struct switchdev_notifier_port_obj_info obj_info = {
+   .info = {
+   .dev = dev,
+   .extack = extack,
+   },
+   };
+   struct 

[PATCH v3 net-next 07/12] net: dsa: sync ageing time when joining the bridge

[Vladimir Oltean]

From: Vladimir Oltean 

The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:

sysfs/ioctl/netlink
-> br_set_ageing_time
   -> __set_ageing_time

therefore not at bridge port creation time, so:
(a) drivers had to hardcode the initial value for the address ageing time,
because they didn't get any notification
(b) that hardcoded value can be out of sync, if the user changes the
ageing time before enslaving the port to the bridge

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

 include/linux/if_bridge.h |  6 ++
 net/bridge/br_stp.c   | 13 +
 net/dsa/port.c| 10 ++
 3 files changed, 29 insertions(+)

diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 920d3a02cc68..ebd16495459c 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -137,6 +137,7 @@ struct net_device *br_fdb_find_port(const struct net_device 
*br_dev,
 void br_fdb_clear_offload(const struct net_device *dev, u16 vid);
 bool br_port_flag_is_set(const struct net_device *dev, unsigned long flag);
 u8 br_port_get_stp_state(const struct net_device *dev);
+clock_t br_get_ageing_time(struct net_device *br_dev);
 #else
 static inline struct net_device *
 br_fdb_find_port(const struct net_device *br_dev,
@@ -160,6 +161,11 @@ static inline u8 br_port_get_stp_state(const struct 
net_device *dev)
 {
return BR_STATE_DISABLED;
 }
+
+static inline clock_t br_get_ageing_time(struct net_device *br_dev)
+{
+   return 0;
+}
 #endif
 
 #endif
diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index 86b5e05d3f21..3dafb6143cff 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
@@ -639,6 +639,19 @@ int br_set_ageing_time(struct net_bridge *br, clock_t 
ageing_time)
return 0;
 }
 
+clock_t br_get_ageing_time(struct net_device *br_dev)
+{
+   struct net_bridge *br;
+
+   if (!netif_is_bridge_master(br_dev))
+   return 0;
+
+   br = netdev_priv(br_dev);
+
+   return jiffies_to_clock_t(br->ageing_time);
+}
+EXPORT_SYMBOL_GPL(br_get_ageing_time);
+
 /* called under bridge lock */
 void __br_set_topology_change(struct net_bridge *br, unsigned char val)
 {
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 124f8bb21204..95e6f2861290 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -173,6 +173,7 @@ static int dsa_port_switchdev_sync(struct dsa_port *dp,
 {
struct net_device *brport_dev = dsa_port_to_bridge_port(dp);
struct net_device *br = dp->bridge_dev;
+   clock_t ageing_time;
u8 stp_state;
int err;
 
@@ -193,6 +194,11 @@ static int dsa_port_switchdev_sync(struct dsa_port *dp,
if (err && err != -EOPNOTSUPP)
return err;
 
+   ageing_time = br_get_ageing_time(br);
+   err = dsa_port_ageing_time(dp, ageing_time);
+   if (err && err != -EOPNOTSUPP)
+   return err;
+
return 0;
 }
 
@@ -222,6 +228,10 @@ static void dsa_port_switchdev_unsync(struct dsa_port *dp)
 * allow this in standalone mode too.
 */
dsa_port_mrouter(dp->cpu_dp, true, NULL);
+
+   /* Ageing time may be global to the switch chip, so don't change it
+* here because we have no good reason (or value) to change it to.
+*/
 }
 
 int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br,
-- 
2.25.1

[PATCH v3 net-next 06/12] net: dsa: sync multicast router state when joining the bridge

[Vladimir Oltean]

From: Vladimir Oltean 

Make sure that the multicast router setting of the bridge is picked up
correctly by DSA when joining, regardless of whether there are
sandwiched interfaces or not. The SWITCHDEV_ATTR_ID_BRIDGE_MROUTER port
attribute is only emitted from br_mc_router_state_change.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
---
Changes in v3:
None.

 net/dsa/port.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/net/dsa/port.c b/net/dsa/port.c
index 3f938c253c99..124f8bb21204 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -189,6 +189,10 @@ static int dsa_port_switchdev_sync(struct dsa_port *dp,
if (err && err != -EOPNOTSUPP)
return err;
 
+   err = dsa_port_mrouter(dp->cpu_dp, br_multicast_router(br), extack);
+   if (err && err != -EOPNOTSUPP)
+   return err;
+
return 0;
 }
 
@@ -212,6 +216,12 @@ static void dsa_port_switchdev_unsync(struct dsa_port *dp)
dsa_port_set_state_now(dp, BR_STATE_FORWARDING);
 
/* VLAN filtering is handled by dsa_switch_bridge_leave */
+
+   /* Some drivers treat the notification for having a local multicast
+* router by allowing multicast to be flooded to the CPU, so we should
+* allow this in standalone mode too.
+*/
+   dsa_port_mrouter(dp->cpu_dp, true, NULL);
 }
 
 int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br,
-- 
2.25.1

[PATCH v3 net-next 05/12] net: dsa: sync up VLAN filtering state when joining the bridge

[Vladimir Oltean]

From: Vladimir Oltean 

This is the same situation as for other switchdev port attributes: if we
join an already-created bridge port, such as a bond master interface,
then we can miss the initial switchdev notification emitted by the
bridge for this port.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
---
Changes in v3:
None.

 net/dsa/port.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2ecdc824ea66..3f938c253c99 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -172,6 +172,7 @@ static int dsa_port_switchdev_sync(struct dsa_port *dp,
   struct netlink_ext_ack *extack)
 {
struct net_device *brport_dev = dsa_port_to_bridge_port(dp);
+   struct net_device *br = dp->bridge_dev;
u8 stp_state;
int err;
 
@@ -184,6 +185,10 @@ static int dsa_port_switchdev_sync(struct dsa_port *dp,
if (err && err != -EOPNOTSUPP)
return err;
 
+   err = dsa_port_vlan_filtering(dp, br, extack);
+   if (err && err != -EOPNOTSUPP)
+   return err;
+
return 0;
 }
 
@@ -205,6 +210,8 @@ static void dsa_port_switchdev_unsync(struct dsa_port *dp)
 * so allow it to be in BR_STATE_FORWARDING to be kept functional
 */
dsa_port_set_state_now(dp, BR_STATE_FORWARDING);
+
+   /* VLAN filtering is handled by dsa_switch_bridge_leave */
 }
 
 int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br,
-- 
2.25.1

[PATCH v3 net-next 04/12] net: dsa: sync up with bridge port's STP state when joining

[Vladimir Oltean]

From: Vladimir Oltean 

It may happen that we have the following topology:

ip link add br0 type bridge stp_state 1
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0
ip link set swp1 master bond0

STP decides that it should put bond0 into the BLOCKING state, and
that's that. The ports that are actively listening for the switchdev
port attributes emitted for the bond0 bridge port (because they are
offloading it) and have the honor of seeing that switchdev port
attribute can react to it, so we can program swp0 and swp1 into the
BLOCKING state.

But if then we do:

ip link set swp2 master bond0

then as far as the bridge is concerned, nothing has changed: it still
has one bridge port. But this new bridge port will not see any STP state
change notification and will remain FORWARDING, which is how the
standalone code leaves it in.

Add a function to the bridge which retrieves the current STP state, such
that drivers can synchronize to it when they may have missed switchdev
events.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
---
Changes in v3:
None.

 include/linux/if_bridge.h |  6 ++
 net/bridge/br_stp.c   | 14 ++
 net/dsa/port.c|  7 +++
 3 files changed, 27 insertions(+)

diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index b979005ea39c..920d3a02cc68 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -136,6 +136,7 @@ struct net_device *br_fdb_find_port(const struct net_device 
*br_dev,
__u16 vid);
 void br_fdb_clear_offload(const struct net_device *dev, u16 vid);
 bool br_port_flag_is_set(const struct net_device *dev, unsigned long flag);
+u8 br_port_get_stp_state(const struct net_device *dev);
 #else
 static inline struct net_device *
 br_fdb_find_port(const struct net_device *br_dev,
@@ -154,6 +155,11 @@ br_port_flag_is_set(const struct net_device *dev, unsigned 
long flag)
 {
return false;
 }
+
+static inline u8 br_port_get_stp_state(const struct net_device *dev)
+{
+   return BR_STATE_DISABLED;
+}
 #endif
 
 #endif
diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index 21c6781906aa..86b5e05d3f21 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
@@ -64,6 +64,20 @@ void br_set_state(struct net_bridge_port *p, unsigned int 
state)
}
 }
 
+u8 br_port_get_stp_state(const struct net_device *dev)
+{
+   struct net_bridge_port *p;
+
+   ASSERT_RTNL();
+
+   p = br_port_get_rtnl(dev);
+   if (!p)
+   return BR_STATE_DISABLED;
+
+   return p->state;
+}
+EXPORT_SYMBOL_GPL(br_port_get_stp_state);
+
 /* called under bridge lock */
 struct net_bridge_port *br_get_port(struct net_bridge *br, u16 port_no)
 {
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 8dbc6e0db30c..2ecdc824ea66 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -171,12 +171,19 @@ static void dsa_port_clear_brport_flags(struct dsa_port 
*dp,
 static int dsa_port_switchdev_sync(struct dsa_port *dp,
   struct netlink_ext_ack *extack)
 {
+   struct net_device *brport_dev = dsa_port_to_bridge_port(dp);
+   u8 stp_state;
int err;
 
err = dsa_port_inherit_brport_flags(dp, extack);
if (err)
return err;
 
+   stp_state = br_port_get_stp_state(brport_dev);
+   err = dsa_port_set_state(dp, stp_state);
+   if (err && err != -EOPNOTSUPP)
+   return err;
+
return 0;
 }
 
-- 
2.25.1

[PATCH v3 net-next 01/12] net: dsa: call dsa_port_bridge_join when joining a LAG that is already in a bridge

[Vladimir Oltean]

From: Vladimir Oltean 

DSA can properly detect and offload this sequence of operations:

ip link add br0 type bridge
ip link add bond0 type bond
ip link set swp0 master bond0
ip link set bond0 master br0

But not this one:

ip link add br0 type bridge
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0

Actually the second one is more complicated, due to the elapsed time
between the enslavement of bond0 and the offloading of it via swp0, a
lot of things could have happened to the bond0 bridge port in terms of
switchdev objects (host MDBs, VLANs, altered STP state etc). So this is
a bit of a can of worms, and making sure that the DSA port's state is in
sync with this already existing bridge port is handled in the next
patches.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
---
Changes in v3:
None.

 net/dsa/port.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/net/dsa/port.c b/net/dsa/port.c
index c9c6d7ab3f47..d39262a9fe0e 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -249,17 +249,31 @@ int dsa_port_lag_join(struct dsa_port *dp, struct 
net_device *lag,
.lag = lag,
.info = uinfo,
};
+   struct net_device *bridge_dev;
int err;
 
dsa_lag_map(dp->ds->dst, lag);
dp->lag_dev = lag;
 
err = dsa_port_notify(dp, DSA_NOTIFIER_LAG_JOIN, );
-   if (err) {
-   dp->lag_dev = NULL;
-   dsa_lag_unmap(dp->ds->dst, lag);
-   }
+   if (err)
+   goto err_lag_join;
 
+   bridge_dev = netdev_master_upper_dev_get(lag);
+   if (!bridge_dev || !netif_is_bridge_master(bridge_dev))
+   return 0;
+
+   err = dsa_port_bridge_join(dp, bridge_dev);
+   if (err)
+   goto err_bridge_join;
+
+   return 0;
+
+err_bridge_join:
+   dsa_port_notify(dp, DSA_NOTIFIER_LAG_LEAVE, );
+err_lag_join:
+   dp->lag_dev = NULL;
+   dsa_lag_unmap(dp->ds->dst, lag);
return err;
 }
 
-- 
2.25.1

[PATCH v3 net-next 03/12] net: dsa: inherit the actual bridge port flags at join time

[Vladimir Oltean]

From: Vladimir Oltean 

DSA currently assumes that the bridge port starts off with this
constellation of bridge port flags:

- learning on
- unicast flooding on
- multicast flooding on
- broadcast flooding on

just by virtue of code copy-pasta from the bridge layer (new_nbp).
This was a simple enough strategy thus far, because the 'bridge join'
moment always coincided with the 'bridge port creation' moment.

But with sandwiched interfaces, such as:

 br0
  |
bond0
  |
 swp0

it may happen that the user has had time to change the bridge port flags
of bond0 before enslaving swp0 to it. In that case, swp0 will falsely
assume that the bridge port flags are those determined by new_nbp, when
in fact this can happen:

ip link add br0 type bridge
ip link add bond0 type bond
ip link set bond0 master br0
ip link set bond0 type bridge_slave learning off
ip link set swp0 master br0

Now swp0 has learning enabled, bond0 has learning disabled. Not nice.

Fix this by "dumpster diving" through the actual bridge port flags with
br_port_flag_is_set, at bridge join time.

We use this opportunity to split dsa_port_change_brport_flags into two
distinct functions called dsa_port_inherit_brport_flags and
dsa_port_clear_brport_flags, now that the implementation for the two
cases is no longer similar.

Signed-off-by: Vladimir Oltean 
---
Changes in v3:
Rewrote dsa_port_clear_brport_flags to at least catch errors, and to use
the same "for" loop structure as dsa_port_inherit_brport_flags.

 net/dsa/port.c | 125 -
 1 file changed, 83 insertions(+), 42 deletions(-)

diff --git a/net/dsa/port.c b/net/dsa/port.c
index fcbe5b1545b8..8dbc6e0db30c 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -122,26 +122,82 @@ void dsa_port_disable(struct dsa_port *dp)
rtnl_unlock();
 }
 
-static void dsa_port_change_brport_flags(struct dsa_port *dp,
-bool bridge_offload)
+static int dsa_port_inherit_brport_flags(struct dsa_port *dp,
+struct netlink_ext_ack *extack)
 {
-   struct switchdev_brport_flags flags;
-   int flag;
+   const unsigned long mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD |
+  BR_BCAST_FLOOD;
+   struct net_device *brport_dev = dsa_port_to_bridge_port(dp);
+   int flag, err;
 
-   flags.mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
-   if (bridge_offload)
-   flags.val = flags.mask;
-   else
-   flags.val = flags.mask & ~BR_LEARNING;
+   for_each_set_bit(flag, , 32) {
+   struct switchdev_brport_flags flags = {0};
 
-   for_each_set_bit(flag, , 32) {
-   struct switchdev_brport_flags tmp;
+   flags.mask = BIT(flag);
 
-   tmp.val = flags.val & BIT(flag);
-   tmp.mask = BIT(flag);
+   if (br_port_flag_is_set(brport_dev, BIT(flag)))
+   flags.val = BIT(flag);
 
-   dsa_port_bridge_flags(dp, tmp, NULL);
+   err = dsa_port_bridge_flags(dp, flags, extack);
+   if (err && err != -EOPNOTSUPP)
+   return err;
}
+
+   return 0;
+}
+
+static void dsa_port_clear_brport_flags(struct dsa_port *dp,
+   struct netlink_ext_ack *extack)
+{
+   const unsigned long val = BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
+   const unsigned long mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD |
+  BR_BCAST_FLOOD;
+   int flag, err;
+
+   for_each_set_bit(flag, , 32) {
+   struct switchdev_brport_flags flags = {0};
+
+   flags.mask = BIT(flag);
+   flags.val = val & BIT(flag);
+
+   err = dsa_port_bridge_flags(dp, flags, extack);
+   if (err && err != -EOPNOTSUPP)
+   dev_err(dp->ds->dev,
+   "failed to clear bridge port flag %d: %d 
(%pe)\n",
+   flags.val, err, ERR_PTR(err));
+   }
+}
+
+static int dsa_port_switchdev_sync(struct dsa_port *dp,
+  struct netlink_ext_ack *extack)
+{
+   int err;
+
+   err = dsa_port_inherit_brport_flags(dp, extack);
+   if (err)
+   return err;
+
+   return 0;
+}
+
+/* Configure the port for standalone mode (no address learning, flood
+ * everything, BR_STATE_FORWARDING, etc).
+ * The bridge only emits SWITCHDEV_ATTR_ID_PORT_* events when the user
+ * requests it through netlink or sysfs, but not automatically at port
+ * join or leave, so we need to handle resetting the brport flags ourselves.
+ * But we even prefer it that way, because otherwise, some setups might never
+ * get the notification they need, for example, when a port leaves a LAG that
+ * offloads the bridge, it becomes standalone, but as far as the bridge is
+ * concerned, no 

[PATCH v3 net-next 00/12] Better support for sandwiched LAGs with bridge and DSA

[Vladimir Oltean]

From: Vladimir Oltean 

The objective of this series is to make LAG uppers on top of switchdev
ports work regardless of which order we link interfaces to their masters
(first make the port join the LAG, then the LAG join the bridge, or the
other way around).

There was a design decision to be made in patches 2-4 on whether we
should adopt the "push" model (which attempts to solve the problem
centrally, in the bridge layer) where the driver just calls:

  switchdev_bridge_port_offloaded(brport_dev,
  _notifier_block,
  _notifier_block,
  extack);

and the bridge just replays the entire collection of switchdev port
attributes and objects that it has, in some predefined order and with
some predefined error handling logic;


or the "pull" model (which attempts to solve the problem by giving the
driver the rope to hang itself), where the driver, apart from calling:

  switchdev_bridge_port_offloaded(brport_dev, extack);

has the task of "dumpster diving" (as Tobias puts it) through the bridge
attributes and objects by itself, by calling:

  - br_vlan_replay
  - br_fdb_replay
  - br_mdb_replay
  - br_vlan_enabled
  - br_port_flag_is_set
  - br_port_get_stp_state
  - br_multicast_router
  - br_get_ageing_time

(not necessarily all of them, and not necessarily in this order, and
with driver-defined error handling).

Even though I'm not in love myself with the "pull" model, I chose it
because there is a fundamental trick with replaying switchdev events
like this:

ip link add br0 type bridge
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0 <- this will replay the objects once for
 the bond0 bridge port, and the swp0
 switchdev port will process them
ip link set swp1 master bond0 <- this will replay the objects again for
 the bond0 bridge port, and the swp1
 switchdev port will see them, but swp0
 will see them for the second time now

Basically I believe that it is implementation defined whether the driver
wants to error out on switchdev objects seen twice on a port, and the
bridge should not enforce a certain model for that. For example, for FDB
entries added to a bonding interface, the underling switchdev driver
might have an abstraction for just that: an FDB entry pointing towards a
logical (as opposed to physical) port. So when the second port joins the
bridge, it doesn't realy need to replay FDB entries, since there is
already at least one hardware port which has been receiving those
events, and the FDB entries don't need to be added a second time to the
same logical port.
In the other corner, we have the drivers that handle switchdev port
attributes on a LAG as individual switchdev port attributes on physical
ports (example: VLAN filtering). In fact, the switchdev_handle_port_attr_set
helper facilitates this: it is a fan-out from a single orig_dev towards
multiple lowers that pass the check_cb().
But that's the point: switchdev_handle_port_attr_set is just a helper
which the driver _opts_ to use. The bridge can't enforce the "push"
model, because that would assume that all drivers handle port attributes
in the same way, which is probably false.

For this reason, I preferred to go with the "pull" mode for this patch
set. Just to see how bad it is for other switchdev drivers to copy-paste
this logic, I added the pull support to ocelot too, and I think it's
pretty manageable.

Vladimir Oltean (12):
  net: dsa: call dsa_port_bridge_join when joining a LAG that is already
in a bridge
  net: dsa: pass extack to dsa_port_{bridge,lag}_join
  net: dsa: inherit the actual bridge port flags at join time
  net: dsa: sync up with bridge port's STP state when joining
  net: dsa: sync up VLAN filtering state when joining the bridge
  net: dsa: sync multicast router state when joining the bridge
  net: dsa: sync ageing time when joining the bridge
  net: dsa: replay port and host-joined mdb entries when joining the
bridge
  net: dsa: replay port and local fdb entries when joining the bridge
  net: dsa: replay VLANs installed on port when joining the bridge
  net: ocelot: call ocelot_netdevice_bridge_join when joining a bridged
LAG
  net: ocelot: replay switchdev events when joining bridge

 drivers/net/dsa/ocelot/felix.c |   4 +-
 drivers/net/ethernet/mscc/ocelot.c |  18 +--
 drivers/net/ethernet/mscc/ocelot_net.c | 208 +
 include/linux/if_bridge.h  |  40 +
 include/net/switchdev.h|   1 +
 include/soc/mscc/ocelot.h  |   6 +-
 net/bridge/br_fdb.c|  52 +++
 net/bridge/br_mdb.c|  84 ++
 net/bridge/br_stp.c|  27 
 net/bridge/br_vlan.c   |  71 +
 

[PATCH v3 net-next 02/12] net: dsa: pass extack to dsa_port_{bridge,lag}_join

[Vladimir Oltean]

From: Vladimir Oltean 

This is a pretty noisy change that was broken out of the larger change
for replaying switchdev attributes and objects at bridge join time,
which is when these extack objects are actually used.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
---
Changes in v3:
None.

 net/dsa/dsa_priv.h | 6 --
 net/dsa/port.c | 8 +---
 net/dsa/slave.c| 7 +--
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 4c43c5406834..b8778c5d8529 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -181,12 +181,14 @@ int dsa_port_enable_rt(struct dsa_port *dp, struct 
phy_device *phy);
 int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy);
 void dsa_port_disable_rt(struct dsa_port *dp);
 void dsa_port_disable(struct dsa_port *dp);
-int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br);
+int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br,
+struct netlink_ext_ack *extack);
 void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br);
 int dsa_port_lag_change(struct dsa_port *dp,
struct netdev_lag_lower_state_info *linfo);
 int dsa_port_lag_join(struct dsa_port *dp, struct net_device *lag_dev,
- struct netdev_lag_upper_info *uinfo);
+ struct netdev_lag_upper_info *uinfo,
+ struct netlink_ext_ack *extack);
 void dsa_port_lag_leave(struct dsa_port *dp, struct net_device *lag_dev);
 int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering,
struct netlink_ext_ack *extack);
diff --git a/net/dsa/port.c b/net/dsa/port.c
index d39262a9fe0e..fcbe5b1545b8 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -144,7 +144,8 @@ static void dsa_port_change_brport_flags(struct dsa_port 
*dp,
}
 }
 
-int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
+int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br,
+struct netlink_ext_ack *extack)
 {
struct dsa_notifier_bridge_info info = {
.tree_index = dp->ds->dst->index,
@@ -241,7 +242,8 @@ int dsa_port_lag_change(struct dsa_port *dp,
 }
 
 int dsa_port_lag_join(struct dsa_port *dp, struct net_device *lag,
- struct netdev_lag_upper_info *uinfo)
+ struct netdev_lag_upper_info *uinfo,
+ struct netlink_ext_ack *extack)
 {
struct dsa_notifier_lag_info info = {
.sw_index = dp->ds->index,
@@ -263,7 +265,7 @@ int dsa_port_lag_join(struct dsa_port *dp, struct 
net_device *lag,
if (!bridge_dev || !netif_is_bridge_master(bridge_dev))
return 0;
 
-   err = dsa_port_bridge_join(dp, bridge_dev);
+   err = dsa_port_bridge_join(dp, bridge_dev, extack);
if (err)
goto err_bridge_join;
 
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 992fcab4b552..1ff48be476bb 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1976,11 +1976,14 @@ static int dsa_slave_changeupper(struct net_device *dev,
 struct netdev_notifier_changeupper_info *info)
 {
struct dsa_port *dp = dsa_slave_to_port(dev);
+   struct netlink_ext_ack *extack;
int err = NOTIFY_DONE;
 
+   extack = netdev_notifier_info_to_extack(>info);
+
if (netif_is_bridge_master(info->upper_dev)) {
if (info->linking) {
-   err = dsa_port_bridge_join(dp, info->upper_dev);
+   err = dsa_port_bridge_join(dp, info->upper_dev, extack);
if (!err)
dsa_bridge_mtu_normalization(dp);
err = notifier_from_errno(err);
@@ -1991,7 +1994,7 @@ static int dsa_slave_changeupper(struct net_device *dev,
} else if (netif_is_lag_master(info->upper_dev)) {
if (info->linking) {
err = dsa_port_lag_join(dp, info->upper_dev,
-   info->upper_info);
+   info->upper_info, extack);
if (err == -EOPNOTSUPP) {
NL_SET_ERR_MSG_MOD(info->info.extack,
   "Offloading not supported");
-- 
2.25.1

Re: [PATCH] xfs: Rudimentary typo fixes

[Randy Dunlap]

On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:



s/filesytem/filesystem/
s/instrumention/instrumentation/

Signed-off-by: Bhaskar Chowdhury 


Acked-by: Randy Dunlap 



---
fs/xfs/xfs_log_recover.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
index 97f31308de03..ffa4f6f2f31e 100644
--- a/fs/xfs/xfs_log_recover.c
+++ b/fs/xfs/xfs_log_recover.c
@@ -2736,7 +2736,7 @@ xlog_recover_process_one_iunlink(
 * of log space.
 *
 * This behaviour is bad for latency on single CPU and non-preemptible kernels,
- * and can prevent other filesytem work (such as CIL pushes) from running. This
+ * and can prevent other filesystem work (such as CIL pushes) from running. 
This
 * can lead to deadlocks if the recovery process runs out of log reservation
 * space. Hence we need to yield the CPU when there is other kernel work
 * scheduled on this CPU to ensure other scheduled work can run without undue
@@ -3404,7 +3404,7 @@ xlog_recover(

/*
 * Delay log recovery if the debug hook is set. This is debug
-* instrumention to coordinate simulation of I/O failures with
+* instrumentation to coordinate simulation of I/O failures with
 * log recovery.
 */
if (xfs_globals.log_recovery_delay) {
--
2.26.2

Re: [PATCH v24 09/10] fs/ntfs3: Add NTFS3 in fs/Kconfig and fs/Makefile

[Oleksandr Natalenko]

On Fri, Mar 19, 2021 at 09:52:09PM +0300, Konstantin Komarov wrote:
> This adds NTFS3 in fs/Kconfig and fs/Makefile
> 
> Signed-off-by: Konstantin Komarov 
> ---
>  fs/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/Kconfig b/fs/Kconfig
> index a55bda4233bb..f61330e4efc0 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -145,6 +145,7 @@ menu "DOS/FAT/EXFAT/NT Filesystems"
>  source "fs/fat/Kconfig"
>  source "fs/exfat/Kconfig"
>  source "fs/ntfs/Kconfig"
> +source "fs/ntfs3/Kconfig"
>  
>  endmenu
>  endif # BLOCK
> -- 
> 2.25.4
> 

It seems fs/Makefile modification has been dropped from this patch for
some reason. Mistake?

-- 
  Oleksandr Natalenko (post-factum)

[PATCH v2 3/3] ALSA: rme9652: don't disable if not enabled

[Tong Zhang]

rme9652 wants to disable a not enabled pci device, which makes kernel
throw a warning. Make sure the device is enabled before calling disable.

[1.751595] snd_rme9652 :00:03.0: disabling already-disabled device
[1.751605] WARNING: CPU: 0 PID: 174 at drivers/pci/pci.c:2146 
pci_disable_device+0x91/0xb0
[1.759968] Call Trace:
[1.760145]  snd_rme9652_card_free+0x76/0xa0 [snd_rme9652]
[1.760434]  release_card_device+0x4b/0x80 [snd]
[1.760679]  device_release+0x3b/0xa0
[1.760874]  kobject_put+0x94/0x1b0
[1.761059]  put_device+0x13/0x20
[1.761235]  snd_card_free+0x61/0x90 [snd]
[1.761454]  snd_rme9652_probe+0x3be/0x700 [snd_rme9652]

Signed-off-by: Tong Zhang 
---
 sound/pci/rme9652/rme9652.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/pci/rme9652/rme9652.c b/sound/pci/rme9652/rme9652.c
index 4df992e846f2..f9c9b8a80797 100644
--- a/sound/pci/rme9652/rme9652.c
+++ b/sound/pci/rme9652/rme9652.c
@@ -1728,10 +1728,10 @@ static int snd_rme9652_free(struct snd_rme9652 *rme9652)
if (rme9652->irq >= 0)
free_irq(rme9652->irq, (void *)rme9652);
iounmap(rme9652->iobase);
-   if (rme9652->port)
+   if (rme9652->port) {
pci_release_regions(rme9652->pci);
-
-   pci_disable_device(rme9652->pci);
+   pci_disable_device(rme9652->pci);
+  }
return 0;
 }
 
@@ -2454,8 +2454,10 @@ static int snd_rme9652_create(struct snd_card *card,
 
spin_lock_init(>lock);
 
-   if ((err = pci_request_regions(pci, "rme9652")) < 0)
+   if ((err = pci_request_regions(pci, "rme9652")) < 0) {
+   pci_disable_device(pci);
return err;
+   }
rme9652->port = pci_resource_start(pci, 0);
rme9652->iobase = ioremap(rme9652->port, RME9652_IO_EXTENT);
if (rme9652->iobase == NULL) {
-- 
2.25.1

[PATCH v2 2/3] ALSA: hdspm: don't disable if not enabled

[Tong Zhang]

hdspm wants to disable a not enabled pci device, which makes kernel
throw a warning. Make sure the device is enabled before calling disable.

[1.786391] snd_hdspm :00:03.0: disabling already-disabled device
[1.786400] WARNING: CPU: 0 PID: 182 at drivers/pci/pci.c:2146 
pci_disable_device+0x91/0xb0
[1.795181] Call Trace:
[1.795320]  snd_hdspm_card_free+0x58/0xa0 [snd_hdspm]
[1.795595]  release_card_device+0x4b/0x80 [snd]
[1.795860]  device_release+0x3b/0xa0
[1.796072]  kobject_put+0x94/0x1b0
[1.796260]  put_device+0x13/0x20
[1.796438]  snd_card_free+0x61/0x90 [snd]
[1.796659]  snd_hdspm_probe+0x97b/0x1440 [snd_hdspm]

Signed-off-by: Tong Zhang 
---
 sound/pci/rme9652/hdspm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c
index 8d900c132f0f..af3898c88bba 100644
--- a/sound/pci/rme9652/hdspm.c
+++ b/sound/pci/rme9652/hdspm.c
@@ -6582,8 +6582,10 @@ static int snd_hdspm_create(struct snd_card *card,
pci_set_master(hdspm->pci);
 
err = pci_request_regions(pci, "hdspm");
-   if (err < 0)
+   if (err < 0) {
+   pci_disable_device(pci);
return err;
+   }
 
hdspm->port = pci_resource_start(pci, 0);
io_extent = pci_resource_len(pci, 0);
@@ -6880,10 +6882,10 @@ static int snd_hdspm_free(struct hdspm * hdspm)
kfree(hdspm->mixer);
iounmap(hdspm->iobase);
 
-   if (hdspm->port)
+   if (hdspm->port) {
pci_release_regions(hdspm->pci);
-
-   pci_disable_device(hdspm->pci);
+   pci_disable_device(hdspm->pci);
+   }
return 0;
 }
 
-- 
2.25.1

[PATCH v2 0/3] ALSA: hdsp and hdspm, don't disable device if not enabled

[Tong Zhang]

This series fixes issues in hdsp and hdspm. The drivers in question want
to disable a device that is not enabled on error path.

v2: add fix to rme9652

Tong Zhang (3):
  ALSA: hdsp: don't disable if not enabled
  ALSA: hdspm: don't disable if not enabled
  ALSA: rme9652: don't disable if not enabled

 sound/pci/rme9652/hdsp.c| 10 ++
 sound/pci/rme9652/hdspm.c   | 10 ++
 sound/pci/rme9652/rme9652.c | 10 ++
 3 files changed, 18 insertions(+), 12 deletions(-)

-- 
2.25.1

[PATCH v2 1/3] ALSA: hdsp: don't disable if not enabled

[Tong Zhang]

hdsp wants to disable a not enabled pci device, which makes kernel
throw a warning. Make sure the device is enabled before calling disable.

[1.758292] snd_hdsp :00:03.0: disabling already-disabled device
[1.758327] WARNING: CPU: 0 PID: 180 at drivers/pci/pci.c:2146 
pci_disable_device+0x91/0xb0
[1.766985] Call Trace:
[1.767121]  snd_hdsp_card_free+0x94/0xf0 [snd_hdsp]
[1.767388]  release_card_device+0x4b/0x80 [snd]
[1.767639]  device_release+0x3b/0xa0
[1.767838]  kobject_put+0x94/0x1b0
[1.768027]  put_device+0x13/0x20
[1.768207]  snd_card_free+0x61/0x90 [snd]
[1.768430]  snd_hdsp_probe+0x524/0x5e0 [snd_hdsp]

Signed-off-by: Tong Zhang 
---
 sound/pci/rme9652/hdsp.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c
index 4cf879c42dc4..d9879a5bd60e 100644
--- a/sound/pci/rme9652/hdsp.c
+++ b/sound/pci/rme9652/hdsp.c
@@ -5285,8 +5285,10 @@ static int snd_hdsp_create(struct snd_card *card,
 
pci_set_master(hdsp->pci);
 
-   if ((err = pci_request_regions(pci, "hdsp")) < 0)
+   if ((err = pci_request_regions(pci, "hdsp")) < 0) {
+   pci_disable_device(pci);
return err;
+   }
hdsp->port = pci_resource_start(pci, 0);
if ((hdsp->iobase = ioremap(hdsp->port, HDSP_IO_EXTENT)) == NULL) {
dev_err(hdsp->card->dev, "unable to remap region 0x%lx-0x%lx\n",
@@ -5387,10 +5389,10 @@ static int snd_hdsp_free(struct hdsp *hdsp)
vfree(hdsp->fw_uploaded);
iounmap(hdsp->iobase);
 
-   if (hdsp->port)
+   if (hdsp->port) {
pci_release_regions(hdsp->pci);
-
-   pci_disable_device(hdsp->pci);
+   pci_disable_device(hdsp->pci);
+   }
return 0;
 }
 
-- 
2.25.1

Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state

[Andy Lutomirski]

On Sat, Mar 20, 2021 at 3:13 PM Thomas Gleixner  wrote:
>
> On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
> > +
> > +/* Update MSR IA32_XFD with xfirstuse_not_detected() if needed. */
> > +static inline void xdisable_switch(struct fpu *prev, struct fpu *next)
> > +{
> > + if (!static_cpu_has(X86_FEATURE_XFD) || !xfirstuse_enabled())
> > + return;
> > +
> > + if (unlikely(prev->state_mask != next->state_mask))
> > + xdisable_setbits(xfirstuse_not_detected(next));
> > +}
>
> So this is invoked on context switch. Toggling bit 18 of MSR_IA32_XFD
> when it does not match. The spec document says:
>
>   "System software may disable use of Intel AMX by clearing XCR0[18:17], by
>clearing CR4.OSXSAVE, or by setting IA32_XFD[18]. It is recommended that
>system software initialize AMX state (e.g., by executing TILERELEASE)
>before doing so. This is because maintaining AMX state in a
>non-initialized state may have negative power and performance
>implications."
>
> I'm not seeing anything related to this. Is this a recommendation
> which can be ignored or is that going to be duct taped into the code
> base once the first user complains about slowdowns of their non AMX
> workloads on that machine?

I have an obnoxious question: do we really want to use the XFD mechanism?

Right now, glibc, and hence most user space code, blindly uses
whatever random CPU features are present for no particularly good
reason, which means that all these features get stuck in the XINUSE=1
state, even if there is no code whatsoever in the process that
benefits.  AVX512 is bad enough as we're seeing right now.  AMX will
be much worse if this happens.

We *could* instead use XCR0 and require an actual syscall to enable
it.  We could even then play games like requiring whomever enables the
feature to allocate memory for the state save area for signals, and
signal delivery could save the state and disable the feature, this
preventing the signal frame from blowing up to 8 or 12 or who knows
how many kB.

--Andy

[PATCH] sched/fair: remove redundant test_idle_cores for non-smt

[Barry Song]

update_idle_core() is only done for the case of sched_smt_present.
but test_idle_cores() is done for all machines even those without
smt.
this could contribute to up 8%+ hackbench performance loss on a
machine like kunpeng 920 which has no smt. this patch removes the
redundant test_idle_cores() for non-smt machines.

we run the below hackbench with different -g parameter from 2 to
14, for each different g, we run the command 10 times and get the
average time:
$ numactl -N 0 hackbench -p -T -l 2 -g $1

hackbench will report the time which is needed to complete a certain
number of messages transmissions between a certain number of tasks,
for example:
$ numactl -N 0 hackbench -p -T -l 2 -g 10
Running in threaded mode with 10 groups using 40 file descriptors each
(== 400 tasks)
Each sender will pass 2 messages of 100 bytes

The below is the result of hackbench w/ and w/o this patch:
g=2  4 6   8  10 12  14
w/o: 1.8151 3.8499 5.5142 7.2491 9.0340 10.7345 12.0929
w/ : 1.8428 3.7436 5.4501 6.9522 8.2882  9.9535 11.3367
  +4.1%  +8.3%  +7.3%   +6.3%

Signed-off-by: Barry Song 
---
 kernel/sched/fair.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2e2ab1e..de42a32 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6038,9 +6038,11 @@ static inline bool test_idle_cores(int cpu, bool def)
 {
struct sched_domain_shared *sds;
 
-   sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
-   if (sds)
-   return READ_ONCE(sds->has_idle_cores);
+   if (static_branch_likely(_smt_present)) {
+   sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
+   if (sds)
+   return READ_ONCE(sds->has_idle_cores);
+   }
 
return def;
 }
-- 
1.8.3.1

[PATCH 2/2] ALSA: hdspm: don't disable if not enabled

[Tong Zhang]

hdspm wants to disable a not enabled pci device, which makes kernel
throw a warning. Make sure the device is enabled before calling disable.

[1.786391] snd_hdspm :00:03.0: disabling already-disabled device
[1.786400] WARNING: CPU: 0 PID: 182 at drivers/pci/pci.c:2146 
pci_disable_device+0x91/0xb0
[1.795181] Call Trace:
[1.795320]  snd_hdspm_card_free+0x58/0xa0 [snd_hdspm]
[1.795595]  release_card_device+0x4b/0x80 [snd]
[1.795860]  device_release+0x3b/0xa0
[1.796072]  kobject_put+0x94/0x1b0
[1.796260]  put_device+0x13/0x20
[1.796438]  snd_card_free+0x61/0x90 [snd]
[1.796659]  snd_hdspm_probe+0x97b/0x1440 [snd_hdspm]

Signed-off-by: Tong Zhang 
---
 sound/pci/rme9652/hdspm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c
index 8d900c132f0f..af3898c88bba 100644
--- a/sound/pci/rme9652/hdspm.c
+++ b/sound/pci/rme9652/hdspm.c
@@ -6582,8 +6582,10 @@ static int snd_hdspm_create(struct snd_card *card,
pci_set_master(hdspm->pci);
 
err = pci_request_regions(pci, "hdspm");
-   if (err < 0)
+   if (err < 0) {
+   pci_disable_device(pci);
return err;
+   }
 
hdspm->port = pci_resource_start(pci, 0);
io_extent = pci_resource_len(pci, 0);
@@ -6880,10 +6882,10 @@ static int snd_hdspm_free(struct hdspm * hdspm)
kfree(hdspm->mixer);
iounmap(hdspm->iobase);
 
-   if (hdspm->port)
+   if (hdspm->port) {
pci_release_regions(hdspm->pci);
-
-   pci_disable_device(hdspm->pci);
+   pci_disable_device(hdspm->pci);
+   }
return 0;
 }
 
-- 
2.25.1

[PATCH 1/2] ALSA: hdsp: don't disable if not enabled

[Tong Zhang]

hdsp wants to disable a not enabled pci device, which makes kernel
throw a warning. Make sure the device is enabled before calling disable.

[1.758292] snd_hdsp :00:03.0: disabling already-disabled device
[1.758327] WARNING: CPU: 0 PID: 180 at drivers/pci/pci.c:2146 
pci_disable_device+0x91/0xb0
[1.766985] Call Trace:
[1.767121]  snd_hdsp_card_free+0x94/0xf0 [snd_hdsp]
[1.767388]  release_card_device+0x4b/0x80 [snd]
[1.767639]  device_release+0x3b/0xa0
[1.767838]  kobject_put+0x94/0x1b0
[1.768027]  put_device+0x13/0x20
[1.768207]  snd_card_free+0x61/0x90 [snd]
[1.768430]  snd_hdsp_probe+0x524/0x5e0 [snd_hdsp]

Signed-off-by: Tong Zhang 
---
 sound/pci/rme9652/hdsp.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c
index 4cf879c42dc4..d9879a5bd60e 100644
--- a/sound/pci/rme9652/hdsp.c
+++ b/sound/pci/rme9652/hdsp.c
@@ -5285,8 +5285,10 @@ static int snd_hdsp_create(struct snd_card *card,
 
pci_set_master(hdsp->pci);
 
-   if ((err = pci_request_regions(pci, "hdsp")) < 0)
+   if ((err = pci_request_regions(pci, "hdsp")) < 0) {
+   pci_disable_device(pci);
return err;
+   }
hdsp->port = pci_resource_start(pci, 0);
if ((hdsp->iobase = ioremap(hdsp->port, HDSP_IO_EXTENT)) == NULL) {
dev_err(hdsp->card->dev, "unable to remap region 0x%lx-0x%lx\n",
@@ -5387,10 +5389,10 @@ static int snd_hdsp_free(struct hdsp *hdsp)
vfree(hdsp->fw_uploaded);
iounmap(hdsp->iobase);
 
-   if (hdsp->port)
+   if (hdsp->port) {
pci_release_regions(hdsp->pci);
-
-   pci_disable_device(hdsp->pci);
+   pci_disable_device(hdsp->pci);
+   }
return 0;
 }
 
-- 
2.25.1

[PATCH 0/2] ALSA: hdsp and hdspm, don't disable device if not enabled

[Tong Zhang]

This series fixes issues in hdsp and hdspm. The drivers in question want
to disable a device that is not enabled on error path.

Tong Zhang (2):
  ALSA: hdsp: don't disable if not enabled
  ALSA: hdspm: don't disable if not enabled

 sound/pci/rme9652/hdsp.c  | 10 ++
 sound/pci/rme9652/hdspm.c | 10 ++
 2 files changed, 12 insertions(+), 8 deletions(-)

-- 
2.25.1

Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state

[Thomas Gleixner]

On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
> +
> +/* Update MSR IA32_XFD with xfirstuse_not_detected() if needed. */
> +static inline void xdisable_switch(struct fpu *prev, struct fpu *next)
> +{
> + if (!static_cpu_has(X86_FEATURE_XFD) || !xfirstuse_enabled())
> + return;
> +
> + if (unlikely(prev->state_mask != next->state_mask))
> + xdisable_setbits(xfirstuse_not_detected(next));
> +}

So this is invoked on context switch. Toggling bit 18 of MSR_IA32_XFD
when it does not match. The spec document says:

  "System software may disable use of Intel AMX by clearing XCR0[18:17], by
   clearing CR4.OSXSAVE, or by setting IA32_XFD[18]. It is recommended that
   system software initialize AMX state (e.g., by executing TILERELEASE)
   before doing so. This is because maintaining AMX state in a
   non-initialized state may have negative power and performance
   implications."

I'm not seeing anything related to this. Is this a recommendation
which can be ignored or is that going to be duct taped into the code
base once the first user complains about slowdowns of their non AMX
workloads on that machine?

Thanks,

tglx

Re: [PATCH 2/3] clocksource/drivers/timer-ti-dm: Remove extra of_node_put()

[Daniel Lezcano]

On 08/03/2021 16:26, Tony Lindgren wrote:
> Hi,
> 
> * Tony Lindgren  [210305 07:58]:
>> * Grygorii Strashko  [210304 20:56]:
>>>
>>>
>>> On 04/03/2021 09:21, Tony Lindgren wrote:
 We have of_translate_address() already do of_node_put() as needed.
 I probably looked at __of_translate_address() earlier by accident
 that of_translate_address() uses.
>>>
>>> I do not see of_node_put() in of_translate_address() and
>>>  __of_translate_address() is doing of_node_get(dev);
>>> ?
>>
>> Oh right.. this is confusing.. Yeah we can ignore this patch.
>> We should have the use count set for only the system timer(s)
>> we claim.
> 
> Daniel, would you like me to repost this series with this patch dropped?

No, it is ok. I will take care of not picking it.

Thanks
  -- Daniel



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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 1/2] perf daemon: Force waipid for all session on SIGCHLD delivery

[Jiri Olsa]

If we don't process SIGCHLD before another comes, we will
see just one SIGCHLD as a result. In this case current code
will miss exit notification for a session and wait forever.

Adding extra waitpid check for all sessions when SIGCHLD
is received, to make sure we don't miss any session exit.

Also fix close condition for signal_fd.

Reported-by: Ian Rogers 
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-daemon.c | 50 +
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c
index ace8772a4f03..4697493842f5 100644
--- a/tools/perf/builtin-daemon.c
+++ b/tools/perf/builtin-daemon.c
@@ -402,35 +402,42 @@ static pid_t handle_signalfd(struct daemon *daemon)
int status;
pid_t pid;
 
+   /*
+* Take signal fd data as pure signal notification and check all
+* the sessions state. The reason is that multiple signals can get
+* coalesced in kernel and we can receive only single signal even
+* if multiple SIGCHLD were generated.
+*/
err = read(daemon->signal_fd, , sizeof(struct signalfd_siginfo));
-   if (err != sizeof(struct signalfd_siginfo))
+   if (err != sizeof(struct signalfd_siginfo)) {
+   pr_err("failed to read signal fd\n");
return -1;
+   }
 
list_for_each_entry(session, >sessions, list) {
+   if (session->pid == -1)
+   continue;
 
-   if (session->pid != (int) si.ssi_pid)
+   pid = waitpid(session->pid, , WNOHANG);
+   if (pid <= 0)
continue;
 
-   pid = waitpid(session->pid, , 0);
-   if (pid == session->pid) {
-   if (WIFEXITED(status)) {
-   pr_info("session '%s' exited, status=%d\n",
-   session->name, WEXITSTATUS(status));
-   } else if (WIFSIGNALED(status)) {
-   pr_info("session '%s' killed (signal %d)\n",
-   session->name, WTERMSIG(status));
-   } else if (WIFSTOPPED(status)) {
-   pr_info("session '%s' stopped (signal %d)\n",
-   session->name, WSTOPSIG(status));
-   } else {
-   pr_info("session '%s' Unexpected status 
(0x%x)\n",
-   session->name, status);
-   }
+   if (WIFEXITED(status)) {
+   pr_info("session '%s' exited, status=%d\n",
+   session->name, WEXITSTATUS(status));
+   } else if (WIFSIGNALED(status)) {
+   pr_info("session '%s' killed (signal %d)\n",
+   session->name, WTERMSIG(status));
+   } else if (WIFSTOPPED(status)) {
+   pr_info("session '%s' stopped (signal %d)\n",
+   session->name, WSTOPSIG(status));
+   } else {
+   pr_info("session '%s' Unexpected status (0x%x)\n",
+   session->name, status);
}
 
session->state = KILL;
session->pid = -1;
-   return pid;
}
 
return 0;
@@ -443,7 +450,6 @@ static int daemon_session__wait(struct daemon_session 
*session, struct daemon *d
.fd = daemon->signal_fd,
.events = POLLIN,
};
-   pid_t wpid = 0, pid = session->pid;
time_t start;
 
start = time(NULL);
@@ -452,7 +458,7 @@ static int daemon_session__wait(struct daemon_session 
*session, struct daemon *d
int err = poll(, 1, 1000);
 
if (err > 0) {
-   wpid = handle_signalfd(daemon);
+   handle_signalfd(daemon);
} else if (err < 0) {
perror("failed: poll\n");
return -1;
@@ -460,7 +466,7 @@ static int daemon_session__wait(struct daemon_session 
*session, struct daemon *d
 
if (start + secs < time(NULL))
return -1;
-   } while (wpid != pid);
+   } while (session->pid != -1);
 
return 0;
 }
@@ -1344,7 +1350,7 @@ static int __cmd_start(struct daemon *daemon, struct 
option parent_options[],
close(sock_fd);
if (conf_fd != -1)
close(conf_fd);
-   if (conf_fd != -1)
+   if (signal_fd != -1)
close(signal_fd);
 
pr_info("daemon exited\n");
-- 
2.30.2

[PATCH 2/2] perf daemon: Return from kill functions

[Jiri Olsa]

We should return correctly and warn in both daemon_session__kill
and daemon__kill functions after we tried everything to kill
sessions. Current code will keep on looping and wait.

Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-daemon.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c
index 4697493842f5..7c4a9d424a64 100644
--- a/tools/perf/builtin-daemon.c
+++ b/tools/perf/builtin-daemon.c
@@ -908,7 +908,9 @@ static void daemon_session__kill(struct daemon_session 
*session,
daemon_session__signal(session, SIGKILL);
break;
default:
-   break;
+   pr_err("failed to wait for session %s\n",
+  session->name);
+   return;
}
how++;
 
@@ -961,7 +963,8 @@ static void daemon__kill(struct daemon *daemon)
daemon__signal(daemon, SIGKILL);
break;
default:
-   break;
+   pr_err("failed to wait for sessions\n");
+   return;
}
how++;
 
-- 
2.30.2

Re: [PATCHSET 0/2] PF_IO_WORKER signal tweaks

[Eric W. Biederman]

Added criu because I just realized that io_uring (which can open files
from an io worker thread) looks to require some special handling for
stopping and freezing processes.  If not in the SIGSTOP case in the
related cgroup freezer case.

Linus Torvalds  writes:

> On Sat, Mar 20, 2021 at 10:51 AM Linus Torvalds
>  wrote:
>>
>> Alternatively, make it not use
>> CLONE_SIGHAND|CLONE_THREAD at all, but that would make it
>> unnecessarily allocate its own signal state, so that's "cleaner" but
>> not great either.
>
> Thinking some more about that, it would be problematic for things like
> the resource counters too. They'd be much better shared.
>
> Not adding it to the thread list etc might be clever, but feels a bit too 
> scary.
>
> So on the whole I think Jens' minor patches to just not have IO helper
> threads accept signals are probably the right thing to do.

The way I see it we have two options:

1) Don't ask PF_IO_WORKERs to stop do_signal_stop and in
   task_join_group_stop.

   The easiest comprehensive implementation looks like just
   updating task_set_jobctl_pending to treat PF_IO_WORKER
   as it treats PF_EXITING.

2) Have the main loop of the kernel thread test for JOBCTL_STOP_PENDING
   and call into do_signal_stop.

It is a wee bit trickier to modify the io_workers to stop, but it does
not look prohibitively difficult.

All of the work performed by the io worker is work scheduled via
io_uring by the process being stopped.

- Is the amount of work performed by the io worker thread sufficiently
  negligible that we don't care?

- Or is the amount of work performed by the io worker so great that it
  becomes a way for an errant process to escape SIGSTOP?

As the code is all intermingled with the cgroup_freezer.  I am also
wondering creating checkpoints needs additional stopping guarantees.


To solve the issue that SIGSTOP is simply broken right now I am totally
fine with something like:

diff --git a/kernel/signal.c b/kernel/signal.c
index ba4d1ef39a9e..cb9acdfb32fa 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -288,7 +288,8 @@ bool task_set_jobctl_pending(struct task_struct *task, 
unsigned long mask)
JOBCTL_STOP_SIGMASK | JOBCTL_TRAPPING));
BUG_ON((mask & JOBCTL_TRAPPING) && !(mask & JOBCTL_PENDING_MASK));
 
-   if (unlikely(fatal_signal_pending(task) || (task->flags & PF_EXITING)))
+   if (unlikely(fatal_signal_pending(task) ||
+(task->flags & (PF_EXITING | PF_IO_WORKER
return false;
 
if (mask & JOBCTL_STOP_SIGMASK)



Which just keeps from creating unstoppable processes today.  I am just
not convinced that is what we want as a long term solution.

Eric

Re: [PATCH v3][next] xfs: Replace one-element arrays with flexible-array members

[Darrick J. Wong]

On Sat, Mar 20, 2021 at 03:20:55PM -0500, Gustavo A. R. Silva wrote:
> 
> 
> On 3/20/21 15:17, Darrick J. Wong wrote:
>  Below are the results of running xfstests for groups shutdown and log
>  with the following configuration in local.config:
> 
>  export TEST_DEV=/dev/sda3
>  export TEST_DIR=/mnt/test
>  export SCRATCH_DEV=/dev/sda4
>  export SCRATCH_MNT=/mnt/scratch
> 
>  The size for both partitions /dev/sda3 and /dev/sda4 is 25GB.
> >>>
> >>> Looks good to me, will toss it at my fstests cloud and see if anything
> >>> shakes out.  Thanks for cleaning up this goofy thorn-pile!
> >>
> >> Great. It's been fun to work on this. :p
> > 
> > Did you run the /entire/ fstests suite?  With this patch applied to
> > 5.12-rc2, I keep seeing list corruption assertions about an hour into
> 
> Nope; I run xfstests 'shutdown' and 'log' groups on 5.11.0, only.
> 
> How do you run the entire fstests?
> Could you give me some pointers?

./check -g all

(instead of "./check -g shutdown")

> > the test run, and usually on some test that heavily exercises allocating
> > and deleting file extents.  I'll try to look at this patch more closely
> > next week, but I figured I should let you know early, on the off chance
> > something sticks out to you.
> 
> OK. I'll go run my tests on 5.12-rc2.
> 
> Should I run the entire xfstests, too?

Yes, please.

--D

> Thanks
> --
> Gustavo

[PATCH] powerpc: epapr: A typo fix

[Bhaskar Chowdhury]

s/parmeters/parameters/

Signed-off-by: Bhaskar Chowdhury 
---
 arch/powerpc/include/asm/epapr_hcalls.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/epapr_hcalls.h 
b/arch/powerpc/include/asm/epapr_hcalls.h
index c99ba08a408d..cdf3c6df5123 100644
--- a/arch/powerpc/include/asm/epapr_hcalls.h
+++ b/arch/powerpc/include/asm/epapr_hcalls.h
@@ -65,7 +65,7 @@
  * but the gcc inline assembly syntax does not allow us to specify registers
  * on the clobber list that are also on the input/output list.  Therefore,
  * the lists of clobbered registers depends on the number of register
- * parmeters ("+r" and "=r") passed to the hypercall.
+ * parameters ("+r" and "=r") passed to the hypercall.
  *
  * Each assembly block should use one of the HCALL_CLOBBERSx macros.  As a
  * general rule, 'x' is the number of parameters passed to the assembly
--
2.26.2

Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads

[Eric W. Biederman]

Linus Torvalds  writes:

> On Sat, Mar 20, 2021 at 9:19 AM Eric W. Biederman  
> wrote:
>>
>> The creds should be reasonably in-sync with the rest of the threads.
>
> It's not about credentials (despite the -EPERM).
>
> It's about the fact that kernel threads cannot handle signals, and
> then get caught in endless loops of "if (sigpending()) return
> -EAGAIN".
>
> For a normal user thread, that "return -EAGAIN" (or whatever) will end
> up returning an error to user space - and before it does that, it will
> go through the "oh, returning to user space, so handle signal" path.
> Which will clear sigpending etc.
>
> A thread that never returns to user space fundamentally cannot handle
> this. The sigpending() stays on forever, the signal never gets
> handled, the thread can't do anything.
>
> So delivering a signal to a kernel thread fundamentally cannot work
> (although we do have some threads that explicitly see "oh, if I was
> killed, I will exit" - think things like in-kernel nfsd etc).

I agree that getting a kernel thread to receive a signal is quite
tricky.  But that is not what the patch affects.

The patch covers the case when instead of specifying the pid of the
process to kill(2) someone specifies the tid of a thread.  Which implies
that type is PIDTYPE_TGID, and in turn the signal is being placed on the
t->signal->shared_pending queue.  Not the thread specific t->pending
queue.

So my question is since the signal is delivered to the process as a
whole why do we care if someone specifies the tid of a kernel thread,
rather than the tid of a userspace thread?

Eric

[PATCH] watchdog: Fix a typo

[Bhaskar Chowdhury]

s/parmeter/parameter/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/watchdog/sl28cpld_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/sl28cpld_wdt.c b/drivers/watchdog/sl28cpld_wdt.c
index a45047d8d9ab..2de93298475f 100644
--- a/drivers/watchdog/sl28cpld_wdt.c
+++ b/drivers/watchdog/sl28cpld_wdt.c
@@ -164,7 +164,7 @@ static int sl28cpld_wdt_probe(struct platform_device *pdev)

/*
 * Initial timeout value, may be overwritten by device tree or module
-* parmeter in watchdog_init_timeout().
+* parameter in watchdog_init_timeout().
 *
 * Reading a zero here means that either the hardware has a default
 * value of zero (which is very unlikely and definitely a hardware
--
2.26.2

Re: Linux 5.10.25

[Jamie Heilman]

[ugh, resent with the lkml headers unbroken, sorry about the dupe]

Greg Kroah-Hartman wrote:
> J. Bruce Fields (2):
>   Revert "nfsd4: remove check_conflicting_opens warning"
>   Revert "nfsd4: a client's own opens needn't prevent delegations"

Hrm, just got this when I udpated my nfs server (32bit Via EPIA system)
from 5.10.20 to 5.10.25:

[   49.225914] NFSD: Using UMH upcall client tracking operations.
[   49.231919] NFSD: starting 90-second grace period (net f036)
[   50.036973] [ cut here ]
[   50.041771] WARNING: CPU: 0 PID: 2284 at fs/nfsd/nfs4state.c:4968 
nfsd4_process_open2+0xf9c/0x1170 [nfsd]
[   50.051434] Modules linked in: md5 cpufreq_conservative cpufreq_userspace 
cpufreq_powersave cpufreq_ondemand autofs4 quota_v2 quota_tree nfsd auth_rpcgss 
nfs lockd grace nfs_ssc fscache sunrpc xt_mark cls_fw sch_htb iptable_nat 
xt_nat nf_nat ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_multiport iptable_mangle 
xt_state xt_conntrack nf_conntrack nf_defrag_ipv4 nf_log_ipv4 nf_log_common 
xt_LOG xt_limit iptable_filter ip_tables x_tables nhpoly1305 chacha_generic 
libchacha adiantum libpoly1305 dm_crypt dm_mod snd_hda_codec_via 
snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep 
snd_hda_core snd_pcm snd_timer snd via_rhine psmouse soundcore mii via_agp sg 
via_velocity evdev agpgart
[   50.113386] CPU: 0 PID: 2284 Comm: nfsd Tainted: GT 5.10.25 
#1
[   50.120669] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To 
be filled by O.E.M., BIOS 080014  06/01/2009
[   50.131652] EIP: nfsd4_process_open2+0xf9c/0x1170 [nfsd]
[   50.137036] Code: 04 88 45 a4 88 07 8b 45 a0 8d 78 49 8b 45 84 8d 70 01 e9 
2b f8 ff ff c7 45 9c 00 00 00 00 31 ff bb 00 00 27 67 e9 04 f6 ff ff <0f> 0b e9 
a0 f5 ff ff 0f b6 d4 0f a3 15 94 3f 23 f8 0f 83 b1 fd ff
[   50.155866] EAX:  EBX: 82da25b0 ECX: 830c0920 EDX: 
[   50.162187] ESI: 82da25b0 EDI: 82da55a0 EBP: 8310be68 ESP: 8310bddc
[   50.168507] DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068 EFLAGS: 00010246
[   50.175338] CR0: 80050033 CR2: 00551e50 CR3: 03222000 CR4: 06b0
[   50.181654] Call Trace:
[   50.184165]  ? inode_permission+0x17/0xc0
[   50.188289]  nfsd4_open+0x429/0x910 [nfsd]
[   50.192483]  ? nfsd4_encode_operation+0x185/0x1e0 [nfsd]
[   50.197900]  ? nfsd4_rename+0x1a0/0x1a0 [nfsd]
[   50.202439]  nfsd4_proc_compound+0x457/0x6c0 [nfsd]
[   50.207419]  nfsd_dispatch+0xdc/0x1a0 [nfsd]
[   50.211816]  svc_process_common+0x38a/0x650 [sunrpc]
[   50.216880]  ? svc_xprt_do_enqueue+0xd7/0xe0 [sunrpc]
[   50.222017]  ? svc_xprt_received+0x5d/0xf0 [sunrpc]
[   50.227000]  ? nfsd_svc+0x300/0x300 [nfsd]
[   50.231190]  svc_process+0xa9/0xf0 [sunrpc]
[   50.235468]  nfsd+0xcd/0x120 [nfsd]
[   50.239025]  kthread+0xe1/0x100
[   50.242259]  ? nfsd_destroy+0x50/0x50 [nfsd]
[   50.246588]  ? kthread_create_on_node+0x30/0x30
[   50.251165]  ret_from_fork+0x1c/0x28
[   50.254789] ---[ end trace 171bde4774bc9795 ]---

Can't readily reproduce it though, so likely a race condition or
something that requires more state buildup than I have after a few
minutes of uptime.  Kernel config at
http://audible.transient.net/~jamie/k/nfsd.config-5.10.25 in case you
think this worth more investigation.

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Re: [PATCH v4 18/22] x86/fpu/amx: Define AMX state components and have it used for boot-time checks

[Thomas Gleixner]

On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
>  
> +static void check_xtile_data_against_struct(int size)
> +{
> + u32 max_palid, palid, state_size;
> + u32 eax, ebx, ecx, edx;
> + u16 max_tile;
> +
> + /*
> +  * Check the maximum palette id:
> +  *   eax: the highest numbered palette subleaf.
> +  */
> + cpuid_count(TILE_CPUID, 0, _palid, , , );
> +
> + /*
> +  * Cross-check each tile size and find the maximum
> +  * number of supported tiles.
> +  */
> + for (palid = 1, max_tile = 0; palid <= max_palid; palid++) {
> + u16 tile_size, max;
> +
> + /*
> +  * Check the tile size info:
> +  *   eax[31:16]:  bytes per title
> +  *   ebx[31:16]:  the max names (or max number of tiles)
> +  */
> + cpuid_count(TILE_CPUID, palid, , , , );
> + tile_size = eax >> 16;
> + max = ebx >> 16;
> +
> + if (WARN_ONCE(tile_size != sizeof(struct xtile_data),
> +   "%s: struct is %zu bytes, cpu xtile %d bytes\n",
> +   __stringify(XFEATURE_XTILE_DATA),
> +   sizeof(struct xtile_data), tile_size))
> + __xstate_dump_leaves();
> +
> + if (max > max_tile)
> + max_tile = max;
> + }
> +
> + state_size = sizeof(struct xtile_data) * max_tile;
> + if (WARN_ONCE(size != state_size,
> +   "%s: calculated size is %u bytes, cpu state %d bytes\n",
> +   __stringify(XFEATURE_XTILE_DATA), state_size, size))
> + __xstate_dump_leaves();

So we have 2 warnings which complain about inconsistent state and that's
it? Why has this absolutely no consequences? We just keep stuff enabled
and jug along, right?

Which one of the two states is correct? Why don't we just disable that
muck and be done with it to play it safe?

Failing to execute some workload by saying NO due to inconsistency is
far more useful than taking the chance of potential silent data
corruption.

Thanks,

tglx

Re: [PATCH v5] coccinelle: misc: add minmax script

[Julia Lawall]

On Tue, 9 Mar 2021, Denis Efremov wrote:

> Check for opencoded min(), max() implementations.
>
> Signed-off-by: Denis Efremov 

Applied, thanks.

julia

> ---
> Changes in v2:
>  - <... ...> instead of ... when any
>  - org mode reports fixed
>  - patch rule to drop excessive ()
> Changes in v3:
>  - "depends on patch && (pmax || pmaxif || pmin || pminif)" fixed
> Changes in v4:
>  - refarmatting rule removed
>  - () brackets added to the patch rules to omit excessive ones
>  - org/report prints changed to cycle (for p0 in p: ...)
> Changes in v5:
>  - parentheses droppped in pminif and pmaxif rules (max_val = x ...)
>
>  scripts/coccinelle/misc/minmax.cocci | 206 +++
>  1 file changed, 206 insertions(+)
>  create mode 100644 scripts/coccinelle/misc/minmax.cocci
>
> diff --git a/scripts/coccinelle/misc/minmax.cocci 
> b/scripts/coccinelle/misc/minmax.cocci
> new file mode 100644
> index ..eccdd3eb3452
> --- /dev/null
> +++ b/scripts/coccinelle/misc/minmax.cocci
> @@ -0,0 +1,206 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +///
> +/// Check for opencoded min(), max() implementations.
> +/// Generated patches sometimes require adding a cast to fix compile warning.
> +/// Warnings/patches scope intentionally limited to a function body.
> +///
> +// Confidence: Medium
> +// Copyright: (C) 2021 Denis Efremov ISPRAS
> +// Options: --no-includes --include-headers
> +//
> +// Keywords: min, max
> +//
> +
> +
> +virtual report
> +virtual org
> +virtual context
> +virtual patch
> +
> +@rmax depends on !patch@
> +identifier func;
> +expression x, y;
> +binary operator cmp = {>, >=};
> +position p;
> +@@
> +
> +func(...)
> +{
> + <...
> +*((x) cmp@p (y) ? (x) : (y))
> + ...>
> +}
> +
> +@rmaxif depends on !patch@
> +identifier func;
> +expression x, y;
> +expression max_val;
> +binary operator cmp = {>, >=};
> +position p;
> +@@
> +
> +func(...)
> +{
> + <...
> +*if ((x) cmp@p (y)) {
> +*max_val = (x);
> +*} else {
> +*max_val = (y);
> +*}
> + ...>
> +}
> +
> +@rmin depends on !patch@
> +identifier func;
> +expression x, y;
> +binary operator cmp = {<, <=};
> +position p;
> +@@
> +
> +func(...)
> +{
> + <...
> +*((x) cmp@p (y) ? (x) : (y))
> + ...>
> +}
> +
> +@rminif depends on !patch@
> +identifier func;
> +expression x, y;
> +expression min_val;
> +binary operator cmp = {<, <=};
> +position p;
> +@@
> +
> +func(...)
> +{
> + <...
> +*if ((x) cmp@p (y)) {
> +*min_val = (x);
> +*} else {
> +*min_val = (y);
> +*}
> + ...>
> +}
> +
> +@pmax depends on patch@
> +identifier func;
> +expression x, y;
> +binary operator cmp = {>=, >};
> +@@
> +
> +func(...)
> +{
> + <...
> +-((x) cmp (y) ? (x) : (y))
> ++max(x, y)
> + ...>
> +}
> +
> +@pmaxif depends on patch@
> +identifier func;
> +expression x, y;
> +expression max_val;
> +binary operator cmp = {>=, >};
> +@@
> +
> +func(...)
> +{
> + <...
> +-if ((x) cmp (y)) {
> +-max_val = x;
> +-} else {
> +-max_val = y;
> +-}
> ++max_val = max(x, y);
> + ...>
> +}
> +
> +@pmin depends on patch@
> +identifier func;
> +expression x, y;
> +binary operator cmp = {<=, <};
> +@@
> +
> +func(...)
> +{
> + <...
> +-((x) cmp (y) ? (x) : (y))
> ++min(x, y)
> + ...>
> +}
> +
> +@pminif depends on patch@
> +identifier func;
> +expression x, y;
> +expression min_val;
> +binary operator cmp = {<=, <};
> +@@
> +
> +func(...)
> +{
> + <...
> +-if ((x) cmp (y)) {
> +-min_val = x;
> +-} else {
> +-min_val = y;
> +-}
> ++min_val = min(x, y);
> + ...>
> +}
> +
> +@script:python depends on report@
> +p << rmax.p;
> +@@
> +
> +for p0 in p:
> + coccilib.report.print_report(p0, "WARNING opportunity for max()")
> +
> +@script:python depends on org@
> +p << rmax.p;
> +@@
> +
> +for p0 in p:
> + coccilib.org.print_todo(p0, "WARNING opportunity for max()")
> +
> +@script:python depends on report@
> +p << rmaxif.p;
> +@@
> +
> +for p0 in p:
> + coccilib.report.print_report(p0, "WARNING opportunity for max()")
> +
> +@script:python depends on org@
> +p << rmaxif.p;
> +@@
> +
> +for p0 in p:
> + coccilib.org.print_todo(p0, "WARNING opportunity for max()")
> +
> +@script:python depends on report@
> +p << rmin.p;
> +@@
> +
> +for p0 in p:
> + coccilib.report.print_report(p0, "WARNING opportunity for min()")
> +
> +@script:python depends on org@
> +p << rmin.p;
> +@@
> +
> +for p0 in p:
> + coccilib.org.print_todo(p0, "WARNING opportunity for min()")
> +
> +@script:python depends on report@
> +p << rminif.p;
> +@@
> +
> +for p0 in p:
> + coccilib.report.print_report(p0, "WARNING opportunity for min()")
> +
> +@script:python depends on org@
> +p << rminif.p;
> +@@
> +
> +for p0 in p:
> + coccilib.org.print_todo(p0, "WARNING opportunity for min()")
> --
> 2.26.2
>
>

Re: [PATCH v4 19/22] x86/fpu/amx: Enable the AMX feature in 64-bit mode

[Thomas Gleixner]

On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:

> In 64-bit mode, include the AMX state components in
> XFEATURE_MASK_USER_SUPPORTED.
>
> The XFD feature will be used to dynamically expand the xstate per-task
> buffer on the first use.

This patch touches absolutely nothing XFD related. What's the message
here?

Thanks,

tglx