Re: [PATCH v6 3/9] riscv: locks: Introduce ticket-based spinlock implementation
On Wed, Mar 31, 2021 at 10:32 PM wrote:
>
> From: Guo Ren
>
> This patch introduces a ticket lock implementation for riscv, along the
> same lines as the implementation for arch/arm & arch/csky.
>
> We still use qspinlock as default.
>
> Signed-off-by: Guo Ren
> Cc: Peter Zijlstra
> Cc: Anup Patel
> Cc: Arnd Bergmann
> ---
> arch/riscv/Kconfig | 7 ++-
> arch/riscv/include/asm/spinlock.h | 84 +
> arch/riscv/include/asm/spinlock_types.h | 17 +
> 3 files changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 67cc65ba1ea1..34d0276f01d5 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -34,7 +34,7 @@ config RISCV
> select ARCH_WANT_FRAME_POINTERS
> select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
> select ARCH_USE_QUEUED_RWLOCKS
> - select ARCH_USE_QUEUED_SPINLOCKS
> + select ARCH_USE_QUEUED_SPINLOCKSif !RISCV_TICKET_LOCK
> select ARCH_USE_QUEUED_SPINLOCKS_XCHG32
> select CLONE_BACKWARDS
> select CLINT_TIMER if !MMU
> @@ -344,6 +344,11 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> def_bool y
> depends on NUMA
>
> +config RISCV_TICKET_LOCK
> + bool "Ticket-based spin-locking"
> + help
> + Say Y here to use ticket-based spin-locking.
> +
> config RISCV_ISA_C
> bool "Emit compressed instructions when building Linux"
> default y
> diff --git a/arch/riscv/include/asm/spinlock.h
> b/arch/riscv/include/asm/spinlock.h
> index a557de67a425..90b7eaa950cf 100644
> --- a/arch/riscv/include/asm/spinlock.h
> +++ b/arch/riscv/include/asm/spinlock.h
> @@ -7,7 +7,91 @@
> #ifndef _ASM_RISCV_SPINLOCK_H
> #define _ASM_RISCV_SPINLOCK_H
>
> +#ifdef CONFIG_RISCV_TICKET_LOCK
> +#ifdef CONFIG_32BIT
> +#define __ASM_SLLIW "slli\t"
> +#define __ASM_SRLIW "srli\t"
> +#else
> +#define __ASM_SLLIW "slliw\t"
> +#define __ASM_SRLIW "srliw\t"
> +#endif
> +
> +/*
> + * Ticket-based spin-locking.
> + */
> +static inline void arch_spin_lock(arch_spinlock_t *lock)
> +{
> + arch_spinlock_t lockval;
> + u32 tmp;
> +
> + asm volatile (
> + "1: lr.w%0, %2 \n"
> + " mv %1, %0 \n"
> + " addw%0, %0, %3 \n"
> + " sc.w%0, %0, %2 \n"
> + " bnez%0, 1b \n"
> + : "=" (tmp), "=" (lockval), "+A" (lock->lock)
> + : "r" (1 << TICKET_NEXT)
> + : "memory");
It's could be optimized by amoadd.w with Anup advice, and I'll update
it in the next patchset version:
diff --git a/arch/riscv/include/asm/spinlock.h
b/arch/riscv/include/asm/spinlock.h
index 90b7eaa950cf..435286ad342b 100644
--- a/arch/riscv/include/asm/spinlock.h
+++ b/arch/riscv/include/asm/spinlock.h
@@ -22,15 +22,10 @@
static inline void arch_spin_lock(arch_spinlock_t *lock)
{
arch_spinlock_t lockval;
- u32 tmp;
asm volatile (
- "1: lr.w%0, %2 \n"
- " mv %1, %0 \n"
- " addw%0, %0, %3 \n"
- " sc.w%0, %0, %2 \n"
- " bnez%0, 1b \n"
- : "=" (tmp), "=" (lockval), "+A" (lock->lock)
+ " amoadd.w%0, %2, %1 \n"
+ : "=" (lockval), "+A" (lock->lock)
: "r" (1 << TICKET_NEXT)
: "memory");
> +
> + smp_cond_load_acquire(>tickets.owner,
> + VAL == lockval.tickets.next);
> +}
> +
> +static inline int arch_spin_trylock(arch_spinlock_t *lock)
> +{
> + u32 tmp, contended, res;
> +
> + do {
> + asm volatile (
> + " lr.w%0, %3 \n"
> + __ASM_SRLIW"%1, %0, %5 \n"
> + __ASM_SLLIW"%2, %0, %5 \n"
> + " or %1, %2, %1 \n"
> + " li %2, 0 \n"
> + " sub %1, %1, %0 \n"
> + " bnez%1, 1f \n"
> + " addw%0, %0, %4 \n"
> + " sc.w%2, %0, %3 \n"
> + "1: \n"
> + : "=" (tmp), "=" (contended), "=" (res),
> + "+A" (lock->lock)
> + : "r" (1 << TICKET_NEXT), "I" (TICKET_NEXT)
> + : "memory");
> + } while (res);
> +
> + if (!contended)
> + __atomic_acquire_fence();
> +
> + return !contended;
> +}
> +
> +static inline void arch_spin_unlock(arch_spinlock_t *lock)
> +{
> + smp_store_release(>tickets.owner, lock->tickets.owner + 1);
> +}
> +
> +static inline int arch_spin_value_unlocked(arch_spinlock_t lock)
> +{
> + return lock.tickets.owner == lock.tickets.next;
> +}
Re: [PATCH] RDMA/addr: potential uninitialized variable in ib_nl_process_good_ip_rsep()
On Mon, Apr 05, 2021 at 08:41:41AM +0300, Dan Carpenter wrote: > Could you send that and give me a reported-by? I'm going AFK for a > week. Sure, we will handle it. Thanks for the report. > > regards, > dan carpenter >
[PATCH rdma-next 8/8] net/rds: Move to client_supported callback
From: Parav Pandit
Use newly introduced client_supported() callback to avoid client
additional if the RDMA device is not of IB type or if it doesn't
support device memory extensions.
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
---
net/rds/ib.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/net/rds/ib.c b/net/rds/ib.c
index 24c9a9005a6f..bd2ff7d5a718 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -125,18 +125,23 @@ void rds_ib_dev_put(struct rds_ib_device *rds_ibdev)
queue_work(rds_wq, _ibdev->free_work);
}
-static int rds_ib_add_one(struct ib_device *device)
+static bool rds_client_supported(struct ib_device *device)
{
- struct rds_ib_device *rds_ibdev;
- int ret;
-
/* Only handle IB (no iWARP) devices */
if (device->node_type != RDMA_NODE_IB_CA)
- return -EOPNOTSUPP;
+ return false;
/* Device must support FRWR */
if (!(device->attrs.device_cap_flags & IB_DEVICE_MEM_MGT_EXTENSIONS))
- return -EOPNOTSUPP;
+ return false;
+
+ return true;
+}
+
+static int rds_ib_add_one(struct ib_device *device)
+{
+ struct rds_ib_device *rds_ibdev;
+ int ret;
rds_ibdev = kzalloc_node(sizeof(struct rds_ib_device), GFP_KERNEL,
ibdev_to_node(device));
@@ -288,7 +293,8 @@ static void rds_ib_remove_one(struct ib_device *device,
void *client_data)
struct ib_client rds_ib_client = {
.name = "rds_ib",
.add= rds_ib_add_one,
- .remove = rds_ib_remove_one
+ .remove = rds_ib_remove_one,
+ .is_supported = rds_client_supported,
};
static int rds_ib_conn_info_visitor(struct rds_connection *conn,
--
2.30.2
[PATCH rdma-next 4/8] IB/core: Skip device which doesn't have necessary capabilities
From: Parav Pandit
If device doesn't have multicast capability, avoid client registration
for it. This saves 16Kbytes of memory for a RDMA device consist of 128
ports.
If device doesn't support subnet administration, avoid client
registration for it. This saves 8Kbytes of memory for a RDMA device
consist of 128 ports.
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/multicast.c | 15 ++-
drivers/infiniband/core/sa_query.c | 15 ++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/multicast.c
b/drivers/infiniband/core/multicast.c
index a5dd4b7a74bc..8c81acc24e3e 100644
--- a/drivers/infiniband/core/multicast.c
+++ b/drivers/infiniband/core/multicast.c
@@ -44,11 +44,13 @@
static int mcast_add_one(struct ib_device *device);
static void mcast_remove_one(struct ib_device *device, void *client_data);
+static bool mcast_client_supported(struct ib_device *device);
static struct ib_client mcast_client = {
.name = "ib_multicast",
.add= mcast_add_one,
- .remove = mcast_remove_one
+ .remove = mcast_remove_one,
+ .is_supported = mcast_client_supported,
};
static struct ib_sa_client sa_client;
@@ -816,6 +818,17 @@ static void mcast_event_handler(struct ib_event_handler
*handler,
}
}
+static bool mcast_client_supported(struct ib_device *device)
+{
+ u32 i;
+
+ rdma_for_each_port(device, i) {
+ if (rdma_cap_ib_mcast(device, i))
+ return true;
+ }
+ return false;
+}
+
static int mcast_add_one(struct ib_device *device)
{
struct mcast_device *dev;
diff --git a/drivers/infiniband/core/sa_query.c
b/drivers/infiniband/core/sa_query.c
index 9a4a49c37922..7e00e24d9423 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -176,11 +176,13 @@ static const struct nla_policy
ib_nl_policy[LS_NLA_TYPE_MAX] = {
static int ib_sa_add_one(struct ib_device *device);
static void ib_sa_remove_one(struct ib_device *device, void *client_data);
+static bool ib_sa_client_supported(struct ib_device *device);
static struct ib_client sa_client = {
.name = "sa",
.add= ib_sa_add_one,
- .remove = ib_sa_remove_one
+ .remove = ib_sa_remove_one,
+ .is_supported = ib_sa_client_supported,
};
static DEFINE_XARRAY_FLAGS(queries, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);
@@ -2293,6 +2295,17 @@ static void ib_sa_event(struct ib_event_handler *handler,
}
}
+static bool ib_sa_client_supported(struct ib_device *device)
+{
+ unsigned int i;
+
+ rdma_for_each_port(device, i) {
+ if (rdma_cap_ib_sa(device, i))
+ return true;
+ }
+ return false;
+}
+
static int ib_sa_add_one(struct ib_device *device)
{
struct ib_sa_device *sa_dev;
--
2.30.2
[PATCH rdma-next 5/8] IB/IPoIB: Skip device which doesn't have InfiniBand port
From: Parav Pandit
Skip RDMA device which doesn't have InfiniBand ports using newly
introduced client_supported() callback.
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 8f769ebaacc6..b02c10dea242 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -93,6 +93,7 @@ static struct net_device *ipoib_get_net_dev_by_params(
struct ib_device *dev, u32 port, u16 pkey,
const union ib_gid *gid, const struct sockaddr *addr,
void *client_data);
+static bool ipoib_client_supported(struct ib_device *device);
static int ipoib_set_mac(struct net_device *dev, void *addr);
static int ipoib_ioctl(struct net_device *dev, struct ifreq *ifr,
int cmd);
@@ -102,6 +103,7 @@ static struct ib_client ipoib_client = {
.add= ipoib_add_one,
.remove = ipoib_remove_one,
.get_net_dev_by_params = ipoib_get_net_dev_by_params,
+ .is_supported = ipoib_client_supported,
};
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG
@@ -2530,6 +2532,17 @@ static struct net_device *ipoib_add_port(const char
*format,
return ERR_PTR(-ENOMEM);
}
+static bool ipoib_client_supported(struct ib_device *device)
+{
+ u32 i;
+
+ rdma_for_each_port(device, i) {
+ if (rdma_protocol_ib(device, i))
+ return true;
+ }
+ return false;
+}
+
static int ipoib_add_one(struct ib_device *device)
{
struct list_head *dev_list;
--
2.30.2
[PATCH rdma-next 6/8] IB/opa_vnic: Move to client_supported callback
From: Parav Pandit
Move to newly introduced client_supported callback
Avoid client registration using newly introduced helper callback if the
IB device doesn't have OPA VNIC capability.
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c
b/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c
index cecf0f7cadf9..58658eba97dd 100644
--- a/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c
+++ b/drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c
@@ -121,6 +121,7 @@ static struct ib_client opa_vnic_client = {
.name = opa_vnic_driver_name,
.add= opa_vnic_vema_add_one,
.remove = opa_vnic_vema_rem_one,
+ .is_supported = rdma_cap_opa_vnic,
};
/**
@@ -993,9 +994,6 @@ static int opa_vnic_vema_add_one(struct ib_device *device)
struct opa_vnic_ctrl_port *cport;
int rc, size = sizeof(*cport);
- if (!rdma_cap_opa_vnic(device))
- return -EOPNOTSUPP;
-
size += device->phys_port_cnt * sizeof(struct opa_vnic_vema_port);
cport = kzalloc(size, GFP_KERNEL);
if (!cport)
--
2.30.2
[PATCH rdma-next 7/8] net/smc: Move to client_supported callback
From: Parav Pandit
Use newly introduced client_supported() callback to avoid client
additional if the RDMA device is not of IB type.
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
---
net/smc/smc_ib.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c
index 6b65c5d1f957..f7186d9d1299 100644
--- a/net/smc/smc_ib.c
+++ b/net/smc/smc_ib.c
@@ -767,6 +767,11 @@ void smc_ib_ndev_change(struct net_device *ndev, unsigned
long event)
mutex_unlock(_ib_devices.mutex);
}
+static bool smc_client_supported(struct ib_device *ibdev)
+{
+ return ibdev->node_type == RDMA_NODE_IB_CA;
+}
+
/* callback function for ib_register_client() */
static int smc_ib_add_dev(struct ib_device *ibdev)
{
@@ -774,9 +779,6 @@ static int smc_ib_add_dev(struct ib_device *ibdev)
u8 port_cnt;
int i;
- if (ibdev->node_type != RDMA_NODE_IB_CA)
- return -EOPNOTSUPP;
-
smcibdev = kzalloc(sizeof(*smcibdev), GFP_KERNEL);
if (!smcibdev)
return -ENOMEM;
@@ -840,6 +842,7 @@ static struct ib_client smc_ib_client = {
.name = "smc_ib",
.add= smc_ib_add_dev,
.remove = smc_ib_remove_dev,
+ .is_supported = smc_client_supported,
};
int __init smc_ib_register_client(void)
--
2.30.2
[PATCH rdma-next 1/8] RDMA/core: Check if client supports IB device or not
From: Parav Pandit
RDMA devices are of different transport(iWarp, IB, RoCE) and have
different attributes.
Not all clients are interested in all type of devices.
Implement a generic callback that each IB client can implement to decide
if client add() or remove() should be done by the IB core or not for a
given IB device, client combination.
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/device.c | 3 +++
include/rdma/ib_verbs.h | 9 +
2 files changed, 12 insertions(+)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index c660cef66ac6..c9af2deba8c1 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -691,6 +691,9 @@ static int add_client_context(struct ib_device *device,
if (!device->kverbs_provider && !client->no_kverbs_req)
return 0;
+ if (client->is_supported && !client->is_supported(device))
+ return 0;
+
down_write(>client_data_rwsem);
/*
* So long as the client is registered hold both the client and device
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 59138174affa..777fbcbd4858 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -2756,6 +2756,15 @@ struct ib_client {
const union ib_gid *gid,
const struct sockaddr *addr,
void *client_data);
+ /*
+* Returns if the client is supported for a given device or not.
+* @dev: An RDMA device to check if client can support this RDMA or not.
+*
+* A client that is interested in specific device attributes, should
+* implement it to check if client can be supported for this device or
+* not.
+*/
+ bool (*is_supported)(struct ib_device *dev);
refcount_t uses;
struct completion uses_zero;
--
2.30.2
[PATCH rdma-next 3/8] IB/cm: Skip device which doesn't support IB CM
From: Parav Pandit
There are at least 3 types of RDMA devices which do not support IB CM.
They are
(1) A (eswitch) switchdev RDMA device,
(2) iWARP device and
(3) RDMA device without a RoCE capability
Hence, avoid IB CM initialization for such devices.
This saves 8Kbytes of memory for eswitch device consist of 512 ports and
also avoids unnecessary initialization for all above 3 types of devices.
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/cm.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 8a7791ebae69..5025f2c1347b 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -87,6 +87,7 @@ struct cm_id_private;
struct cm_work;
static int cm_add_one(struct ib_device *device);
static void cm_remove_one(struct ib_device *device, void *client_data);
+static bool cm_supported(struct ib_device *device);
static void cm_process_work(struct cm_id_private *cm_id_priv,
struct cm_work *work);
static int cm_send_sidr_rep_locked(struct cm_id_private *cm_id_priv,
@@ -103,7 +104,8 @@ static int cm_send_rej_locked(struct cm_id_private
*cm_id_priv,
static struct ib_client cm_client = {
.name = "cm",
.add= cm_add_one,
- .remove = cm_remove_one
+ .remove = cm_remove_one,
+ .is_supported = cm_supported,
};
static struct ib_cm {
@@ -4371,6 +4373,17 @@ static void cm_remove_port_fs(struct cm_port *port)
}
+static bool cm_supported(struct ib_device *device)
+{
+ u32 i;
+
+ rdma_for_each_port(device, i) {
+ if (rdma_cap_ib_cm(device, i))
+ return true;
+ }
+ return false;
+}
+
static int cm_add_one(struct ib_device *ib_device)
{
struct cm_device *cm_dev;
--
2.30.2
[PATCH rdma-next 2/8] RDMA/cma: Skip device which doesn't support CM
From: Parav Pandit
A switchdev RDMA device do not support IB CM. When such device is added
to the RDMA CM's device list, when application invokes rdma_listen(),
cma attempts to listen to such device, however it has IB CM attribute
disabled.
Due to this, rdma_listen() call fails to listen for other non
switchdev devices as well.
A below error message can be seen.
infiniband mlx5_0: RDMA CMA: cma_listen_on_dev, error -38
A failing call flow is below.
rdma_listen()
cma_listen_on_all()
cma_listen_on_dev()
_cma_attach_to_dev()
rdma_listen() <- fails on a specific switchdev device
Hence, when a IB device doesn't support IB CM or IW CM, avoid adding
such device to the cma list.
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/cma.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 42a1c8955c50..80156faf90de 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -157,11 +157,13 @@ EXPORT_SYMBOL(rdma_res_to_id);
static int cma_add_one(struct ib_device *device);
static void cma_remove_one(struct ib_device *device, void *client_data);
+static bool cma_supported(struct ib_device *device);
static struct ib_client cma_client = {
.name = "cma",
.add= cma_add_one,
- .remove = cma_remove_one
+ .remove = cma_remove_one,
+ .is_supported = cma_supported,
};
static struct ib_sa_client sa_client;
@@ -4870,6 +4872,17 @@ static void cma_process_remove(struct cma_device
*cma_dev)
wait_for_completion(_dev->comp);
}
+static bool cma_supported(struct ib_device *device)
+{
+ u32 i;
+
+ rdma_for_each_port(device, i) {
+ if (rdma_cap_ib_cm(device, i) || rdma_cap_iw_cm(device, i))
+ return true;
+ }
+ return false;
+}
+
static int cma_add_one(struct ib_device *device)
{
struct rdma_id_private *to_destroy;
--
2.30.2
[PATCH rdma-next 0/8] Generalize if ULP supported check
From: Leon Romanovsky Hi, This series adds new callback to check if ib client is supported/not_supported. Such general callback allows us to save memory footprint by not starting on devices that not going to work on them anyway. Thanks Parav Pandit (8): RDMA/core: Check if client supports IB device or not RDMA/cma: Skip device which doesn't support CM IB/cm: Skip device which doesn't support IB CM IB/core: Skip device which doesn't have necessary capabilities IB/IPoIB: Skip device which doesn't have InfiniBand port IB/opa_vnic: Move to client_supported callback net/smc: Move to client_supported callback net/rds: Move to client_supported callback drivers/infiniband/core/cm.c | 15 +- drivers/infiniband/core/cma.c | 15 +- drivers/infiniband/core/device.c | 3 +++ drivers/infiniband/core/multicast.c | 15 +- drivers/infiniband/core/sa_query.c| 15 +- drivers/infiniband/ulp/ipoib/ipoib_main.c | 13 .../infiniband/ulp/opa_vnic/opa_vnic_vema.c | 4 +--- include/rdma/ib_verbs.h | 9 + net/rds/ib.c | 20 --- net/smc/smc_ib.c | 9 ++--- 10 files changed, 101 insertions(+), 17 deletions(-) -- 2.30.2
High kmalloc-32 slab cache consumption with 10k containers
Hi,
When running 1 (more-or-less-empty-)containers on a bare-metal Power9
server(160 CPUs, 2 NUMA nodes, 256G memory), it is seen that memory
consumption increases quite a lot (around 172G) when the containers are
running. Most of it comes from slab (149G) and within slab, the majority of
it comes from kmalloc-32 cache (102G)
The major allocator of kmalloc-32 slab cache happens to be the list_head
allocations of list_lru_one list. These lists are created whenever a
FS mount happens. Specially two such lists are registered by alloc_super(),
one for dentry and another for inode shrinker list. And these lists
are created for all possible NUMA nodes and for all given memcgs
(memcg_nr_cache_ids to be particular)
If,
A = Nr allocation request per mount: 2 (one for dentry and inode list)
B = Nr NUMA possible nodes
C = memcg_nr_cache_ids
D = size of each kmalloc-32 object: 32 bytes,
then for every mount, the amount of memory consumed by kmalloc-32 slab
cache for list_lru creation is A*B*C*D bytes.
Following factors contribute to the excessive allocations:
- Lists are created for possible NUMA nodes.
- memcg_nr_cache_ids grows in bulk (see memcg_alloc_cache_id() and additional
list_lrus are created when it grows. Thus we end up creating list_lru_one
list_heads even for those memcgs which are yet to be created.
For example, when 1 memcgs are created, memcg_nr_cache_ids reach
a value of 12286.
- When a memcg goes offline, the list elements are drained to the parent
memcg, but the list_head entry remains.
- The lists are destroyed only when the FS is unmounted. So list_heads
for non-existing memcgs remain and continue to contribute to the
kmalloc-32 allocation. This is presumably done for performance
reason as they get reused when new memcgs are created, but they end up
consuming slab memory until then.
- In case of containers, a few file systems get mounted and are specific
to the container namespace and hence to a particular memcg, but we
end up creating lists for all the memcgs.
As an example, if 7 FS mounts are done for every container and when
10k containers are created, we end up creating 2*7*12286 list_lru_one
lists for each NUMA node. It appears that no elements will get added
to other than 2*7=14 of them in the case of containers.
One straight forward way to prevent this excessive list_lru_one
allocations is to limit the list_lru_one creation only to the
relevant memcg. However I don't see an easy way to figure out
that relevant memcg from FS mount path (alloc_super())
As an alternative approach, I have this below hack that does lazy
list_lru creation. The memcg-specific list is created and initialized
only when there is a request to add an element to that particular
list. Though I am not sure about the full impact of this change
on the owners of the lists and also the performance impact of this,
the overall savings look good.
Used memory
Before During After
W/o patch 23G 172G40G
W/ patch 23G 69G 29G
Slab consumption
Before During After
W/o patch 1.5G149G22G
W/ patch 1.5G45G 10G
Number of kmalloc-32 allocations
Before During After
W/o patch 178176 3442409472 388933632
W/ patch 190464 468992 468992
Any thoughts on other approaches to address this scenario and
any specific comments about the approach that I have taken is
appreciated. Meanwhile the patch looks like below:
>From 9444a0c6734c2853057b1f486f85da2c409fdc84 Mon Sep 17 00:00:00 2001
From: Bharata B Rao
Date: Wed, 31 Mar 2021 18:21:45 +0530
Subject: [PATCH 1/1] mm: list_lru: Allocate list_lru_one only when required.
Don't pre-allocate list_lru_one list heads for all memcg_cache_ids.
Instead allocate and initialize it only when required.
Signed-off-by: Bharata B Rao
---
mm/list_lru.c | 79 +--
1 file changed, 38 insertions(+), 41 deletions(-)
diff --git a/mm/list_lru.c b/mm/list_lru.c
index 6f067b6b935f..b453fa5008cc 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -112,16 +112,32 @@ list_lru_from_kmem(struct list_lru_node *nlru, void *ptr,
}
#endif /* CONFIG_MEMCG_KMEM */
+static void init_one_lru(struct list_lru_one *l)
+{
+ INIT_LIST_HEAD(>list);
+ l->nr_items = 0;
+}
+
bool list_lru_add(struct list_lru *lru, struct list_head *item)
{
int nid = page_to_nid(virt_to_page(item));
struct list_lru_node *nlru = >node[nid];
struct mem_cgroup *memcg;
struct list_lru_one *l;
+ struct list_lru_memcg *memcg_lrus;
spin_lock(>lock);
if (list_empty(item)) {
l = list_lru_from_kmem(nlru, item, );
+ if (!l) {
+ l = kmalloc(sizeof(struct list_lru_one), GFP_ATOMIC);
+
Re: [PATCH v2] net: mac802154: Fix general protection fault
Hi! On Sun, 2021-04-04 at 20:43 -0400, Alexander Aring wrote: > Hi, > > On Thu, 4 Mar 2021 at 10:25, Pavel Skripkin > wrote: > > > > syzbot found general protection fault in crypto_destroy_tfm()[1]. > > It was caused by wrong clean up loop in llsec_key_alloc(). > > If one of the tfm array members is in IS_ERR() range it will > > cause general protection fault in clean up function [1]. > > > > Call Trace: > > crypto_free_aead include/crypto/aead.h:191 [inline] [1] > > llsec_key_alloc net/mac802154/llsec.c:156 [inline] > > mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 > > ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 > > rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] > > nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 > > genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 > > genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] > > genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 > > netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 > > genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 > > netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] > > netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 > > netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 > > sock_sendmsg_nosec net/socket.c:654 [inline] > > sock_sendmsg+0xcf/0x120 net/socket.c:674 > > sys_sendmsg+0x6e8/0x810 net/socket.c:2350 > > ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 > > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 > > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > > > Signed-off-by: Pavel Skripkin > > Reported-by: syzbot+9ec037722d2603a9f...@syzkaller.appspotmail.com > > Change-Id: I29f7ac641a039096d63d1e6070bb32cb5a3beb07 > > I am sorry, I don't know the tag "Change-Id", I was doing a whole > grep > on Documentation/ without any luck. > I forgot to check the patch with ./scripts/checkpatch.pl :( > Dumb question: What is the meaning of it? This is for gerrit code review. This is required to push changes to gerrit public mirror. I'm using it to check patches with syzbot. Change ids are useless outside gerrit, so it shouldn't be here. Btw, should I sent v2 or this is already fixed? > > - Alex With regards, Pavel Skripkin
Re: [PATCH] RDMA/addr: potential uninitialized variable in ib_nl_process_good_ip_rsep()
Could you send that and give me a reported-by? I'm going AFK for a week. regards, dan carpenter
[syzbot] WARNING: suspicious RCU usage in do_user_addr_fault
Hello,
syzbot found the following issue on:
HEAD commit:d19cc4bf Merge tag 'trace-v5.12-rc5' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17a22d16d0
kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
dashboard link: https://syzkaller.appspot.com/bug?extid=3d5082ab6eec95ad4231
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3d5082ab6eec95ad4...@syzkaller.appspotmail.com
WARNING: suspicious RCU usage
5.12.0-rc5-syzkaller #0 Not tainted
-
kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical
section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
1 lock held by syz-executor.5/8582:
#0: 888029093218 (>mmap_lock#2){}-{3:3}, at: mmap_read_trylock
include/linux/mmap_lock.h:136 [inline]
#0: 888029093218 (>mmap_lock#2){}-{3:3}, at:
do_user_addr_fault+0x285/0x1210 arch/x86/mm/fault.c:1331
stack backtrace:
CPU: 0 PID: 8582 Comm: syz-executor.5 Not tainted 5.12.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294
do_user_addr_fault+0x2c2/0x1210 arch/x86/mm/fault.c:1348
handle_page_fault arch/x86/mm/fault.c:1475 [inline]
exc_page_fault+0x9e/0x180 arch/x86/mm/fault.c:1531
asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:577
RIP: 0033:0x406f13
Code: 00 00 e8 a0 a1 ff ff 85 c0 74 4e 8b 54 24 0c 49 8b 37 31 c0 48 8d 3d 79
7f 0b 00 e8 27 c3 ff ff 8b 44 24 6c 49 8d 4f 60 89 de <4d> 89 a7 b8 00 00 00 ba
40 00 00 00 44 89 ef 41 89 87 b4 00 00 00
RSP: 002b:7fff2a8e7140 EFLAGS: 00010202
RAX: 0005 RBX: RCX: 00544420
RDX: 0002 RSI: RDI: 004bee7d
RBP: 7fff2a8e7160 R08: 7fff2a8e715c R09: 7fff2a8e71f0
R10: 7fff2a8e71c0 R11: 0202 R12: 7fff2a8e71c0
R13: 0003 R14: 7fff2a8e715c R15: 005443c0
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH rdma-next 10/10] xprtrdma: Enable Relaxed Ordering
From: Avihai Horon Enable Relaxed Ordering for xprtrdma. Relaxed Ordering is an optional access flag and as such, it is ignored by vendors that don't support it. Signed-off-by: Avihai Horon Reviewed-by: Michael Guralnik Signed-off-by: Leon Romanovsky --- net/sunrpc/xprtrdma/frwr_ops.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/net/sunrpc/xprtrdma/frwr_ops.c b/net/sunrpc/xprtrdma/frwr_ops.c index cfbdd197cdfe..f9334c0a1a13 100644 --- a/net/sunrpc/xprtrdma/frwr_ops.c +++ b/net/sunrpc/xprtrdma/frwr_ops.c @@ -135,7 +135,8 @@ int frwr_mr_init(struct rpcrdma_xprt *r_xprt, struct rpcrdma_mr *mr) struct ib_mr *frmr; int rc; - frmr = ib_alloc_mr(ep->re_pd, ep->re_mrtype, depth, 0); + frmr = ib_alloc_mr(ep->re_pd, ep->re_mrtype, depth, + IB_ACCESS_RELAXED_ORDERING); if (IS_ERR(frmr)) goto out_mr_err; @@ -339,9 +340,10 @@ struct rpcrdma_mr_seg *frwr_map(struct rpcrdma_xprt *r_xprt, reg_wr = >frwr.fr_regwr; reg_wr->mr = ibmr; reg_wr->key = ibmr->rkey; - reg_wr->access = writing ? -IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE : -IB_ACCESS_REMOTE_READ; + reg_wr->access = + (writing ? IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE : + IB_ACCESS_REMOTE_READ) | + IB_ACCESS_RELAXED_ORDERING; mr->mr_handle = ibmr->rkey; mr->mr_length = ibmr->length; -- 2.30.2
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04, 2021 at 09:30:38PM -0700, Paul E. McKenney wrote:
> On Sun, Apr 04, 2021 at 09:01:25PM -0700, Paul E. McKenney wrote:
> > On Mon, Apr 05, 2021 at 04:08:55AM +0100, Matthew Wilcox wrote:
> > > On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote:
> > > > On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote:
> > > > > On Sun, Apr 04 2021 at 12:05, syzbot wrote:
> > > > >
> > > > > Cc + ...
> > > >
> > > > And a couple more...
> > > >
> > > > > > Hello,
> > > > > >
> > > > > > syzbot found the following issue on:
> > > > > >
> > > > > > HEAD commit:5e46d1b7 reiserfs: update
> > > > > > reiserfs_xattrs_initialized() co..
> > > > > > git tree: upstream
> > > > > > console output:
> > > > > > https://syzkaller.appspot.com/x/log.txt?x=1125f831d0
> > > > > > kernel config:
> > > > > > https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> > > > > > dashboard link:
> > > > > > https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d
> > > > > >
> > > > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > > > >
> > > > > > IMPORTANT: if you fix the issue, please add the following tag to
> > > > > > the commit:
> > > > > > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com
> > > > > >
> > > > > > =
> > > > > > WARNING: suspicious RCU usage
> > > > > > 5.12.0-rc5-syzkaller #0 Not tainted
> > > > > > -
> > > > > > kernel/sched/core.c:8294 Illegal context switch in RCU-sched
> > > > > > read-side critical section!
> > > > > >
> > > > > > other info that might help us debug this:
> > > > > >
> > > > > >
> > > > > > rcu_scheduler_active = 2, debug_locks = 0
> > > > > > 3 locks held by syz-executor.4/8418:
> > > > > > #0:
> > > > > > 8880751d2b28
> > > > > > (
> > > > > > >pi_lock
> > > > > > ){-.-.}-{2:2}
> > > > > > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345
> > > > > > #1:
> > > > > > 8880b9d35258
> > > > > > (
> > > > > > >lock
> > > > > > ){-.-.}-{2:2}
> > > > > > , at: rq_lock kernel/sched/sched.h:1321 [inline]
> > > > > > , at: ttwu_queue kernel/sched/core.c:3184 [inline]
> > > > > > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464
> > > > > > #2: 8880b9d1f948 (_cpu_ptr(group->pcpu,
> > > > > > cpu)->seq){-.-.}-{0:0}, at: psi_task_change+0x142/0x220
> > > > > > kernel/sched/psi.c:807
> > > >
> > > > This looks similar to
> > > > syzbot+dde0cc33951735441...@syzkaller.appspotmail.com
> > > > in that rcu_sleep_check() sees an RCU lock held, but the later call to
> > > > lockdep_print_held_locks() does not. Did something change recently that
> > > > could let the ->lockdep_depth counter get out of sync with the actual
> > > > number of locks held?
> > >
> > > Dmitri had a different theory here:
> > >
> > > https://groups.google.com/g/syzkaller-bugs/c/FmYvfZCZzqA/m/nc2CXUgsAgAJ
> >
> > There is always room for more than one bug. ;-)
> >
> > He says "one-off false positives". I was afraid of that...
>
> And both the examples I have been copied on today are consistent with
> debug_locks getting zeroed (e.g., via a call to __debug_locks_off())
> in the midst of a call to rcu_sleep_check(). But I would expect to see
> a panic or another splat if that were to happen.
>
> Dmitry's example did have an additional splat, but I would expect the
> RCU-related one to come second. Again, there is always room for more
> than one bug.
>
> On the other hand, there are a lot more callers to debug_locks_off()
> than there were last I looked into this. And both of these splats
> are consistent with an interrupt in the middle of rcu_sleep_check(),
> and that interrupt's handler invoking debug_locks_off(), but without
> printing anything to the console. Does that sequence of events ring a
> bell for anyone?
>
> If this is the new normal, I could make RCU_LOCKDEP_WARN() recheck
> debug_lockdep_rcu_enabled() after evaluating the condition, but with
> a memory barrier immediately before the recheck. But I am not at all
> excited by doing this on speculation. Especially given that doing
> so might be covering up some other bug.
>
Just check the original console log and find:
[ 356.696686][ T8418] =
[ 356.696692][ T8418] WARNING: suspicious RCU usage
[ 356.700193][T14782]
[ 356.704548][ T8418] 5.12.0-rc5-syzkaller #0 Not tainted
[ 356.729981][ T8418] -
[ 356.732473][T14782] WARNING: iou-sqp-14780/14782 still has locks held!
, so there are two warnnings here, one is from lockdep_rcu_suspisous()
and the other is from print_held_locks_bug(). I think this is what
happened:
in RCU_LOCKDEP_WARN():
if (debug_lockdep_rcu_enabled() // this is true and at this time
debug_locks = 1
// lockdep detects a lock bug, set debug_locks = 0
&& !__warned // true
&& (c)) //
[PATCH rdma-next 09/10] net/smc: Enable Relaxed Ordering
From: Avihai Horon
Enable Relaxed Ordering for smc.
Relaxed Ordering is an optional access flag and as such, it is ignored
by vendors that don't support it.
Signed-off-by: Avihai Horon
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
net/smc/smc_ib.c | 3 ++-
net/smc/smc_wr.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c
index 4e91ed3dc265..6b65c5d1f957 100644
--- a/net/smc/smc_ib.c
+++ b/net/smc/smc_ib.c
@@ -579,7 +579,8 @@ int smc_ib_get_memory_region(struct ib_pd *pd, int
access_flags,
return 0; /* already done */
buf_slot->mr_rx[link_idx] =
- ib_alloc_mr(pd, IB_MR_TYPE_MEM_REG, 1 << buf_slot->order, 0);
+ ib_alloc_mr(pd, IB_MR_TYPE_MEM_REG, 1 << buf_slot->order,
+ IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(buf_slot->mr_rx[link_idx])) {
int rc;
diff --git a/net/smc/smc_wr.c b/net/smc/smc_wr.c
index cbc73a7e4d59..78e9650621f1 100644
--- a/net/smc/smc_wr.c
+++ b/net/smc/smc_wr.c
@@ -555,7 +555,8 @@ static void smc_wr_init_sge(struct smc_link *lnk)
lnk->wr_reg.wr.num_sge = 0;
lnk->wr_reg.wr.send_flags = IB_SEND_SIGNALED;
lnk->wr_reg.wr.opcode = IB_WR_REG_MR;
- lnk->wr_reg.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE;
+ lnk->wr_reg.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE |
+IB_ACCESS_RELAXED_ORDERING;
}
void smc_wr_free_link(struct smc_link *lnk)
--
2.30.2
Re: [PATCH v5 00/19] Support ROHM BD71815 PMIC
On Fri, 2021-04-02 at 20:19 +0100, Mark Brown wrote: > On Tue, Mar 30, 2021 at 11:06:53AM +, Vaittinen, Matti wrote: > > > Do you think Lee could merge other but the regulator parts to MFD > > if > > Mark is busy? I'd like to be able to squeeze the amount of patches > > and > > recipients for future iterations. It might be easier to work > > directly > > on regulator tree if regulator part gets delayed to next cycle. (I > > do > > also plan further working with the GPIO part during 5.13-rc cycle > > to > > utilize the regmap_gpio. That could be done in the GPIO tree then). > > I > > think the other portions are in a pretty stable shape now. > > This wouldn't be a bad idea in general for these serieses, especially > the bigger ones or the ones that get a lot of review comments on some > patches. > > In any case, here's a pull request for the helpers that are added Thanks Mark. > Matti Vaittinen (2): > regulator: helpers: Export helper voltage listing > regulator: Add regmap helper for ramp-delay setting > If I understand this correctly, the idea is that Lee could pull these changes to his tree? So, I will drop these two patches from the series when I resend it. Helpers are needed for the regulator part of the series to apply. Lee, Mark, please let me know if I misunderstood. Best Regards Matti Vaittinen
[PATCH rdma-next 08/10] net/rds: Enable Relaxed Ordering
From: Avihai Horon
Enable Relaxed Ordering for rds.
Relaxed Ordering is an optional access flag and as such, it is ignored
by vendors that don't support it.
Signed-off-by: Avihai Horon
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
net/rds/ib_frmr.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/rds/ib_frmr.c b/net/rds/ib_frmr.c
index 694eb916319e..1a60c2c90c78 100644
--- a/net/rds/ib_frmr.c
+++ b/net/rds/ib_frmr.c
@@ -76,7 +76,7 @@ static struct rds_ib_mr *rds_ib_alloc_frmr(struct
rds_ib_device *rds_ibdev,
frmr = >u.frmr;
frmr->mr = ib_alloc_mr(rds_ibdev->pd, IB_MR_TYPE_MEM_REG,
- pool->max_pages, 0);
+ pool->max_pages, IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(frmr->mr)) {
pr_warn("RDS/IB: %s failed to allocate MR", __func__);
err = PTR_ERR(frmr->mr);
@@ -156,9 +156,8 @@ static int rds_ib_post_reg_frmr(struct rds_ib_mr *ibmr)
reg_wr.wr.num_sge = 0;
reg_wr.mr = frmr->mr;
reg_wr.key = frmr->mr->rkey;
- reg_wr.access = IB_ACCESS_LOCAL_WRITE |
- IB_ACCESS_REMOTE_READ |
- IB_ACCESS_REMOTE_WRITE;
+ reg_wr.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
+ IB_ACCESS_REMOTE_WRITE | IB_ACCESS_RELAXED_ORDERING;
reg_wr.wr.send_flags = IB_SEND_SIGNALED;
ret = ib_post_send(ibmr->ic->i_cm_id->qp, _wr.wr, NULL);
--
2.30.2
[PATCH rdma-next 06/10] nvme-rdma: Enable Relaxed Ordering
From: Avihai Horon
Enable Relaxed Ordering for nvme.
Relaxed Ordering is an optional access flag and as such, it is ignored
by vendors that don't support it.
Signed-off-by: Avihai Horon
Reviewed-by: Max Gurtovoy
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
drivers/nvme/host/rdma.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 4dbc17311e0b..8f106b20b39c 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -532,9 +532,8 @@ static int nvme_rdma_create_queue_ib(struct nvme_rdma_queue
*queue)
*/
pages_per_mr = nvme_rdma_get_max_fr_pages(ibdev, queue->pi_support) + 1;
ret = ib_mr_pool_init(queue->qp, >qp->rdma_mrs,
- queue->queue_size,
- IB_MR_TYPE_MEM_REG,
- pages_per_mr, 0, 0);
+ queue->queue_size, IB_MR_TYPE_MEM_REG,
+ pages_per_mr, 0, IB_ACCESS_RELAXED_ORDERING);
if (ret) {
dev_err(queue->ctrl->ctrl.device,
"failed to initialize MR pool sized %d for QID %d\n",
@@ -545,7 +544,8 @@ static int nvme_rdma_create_queue_ib(struct nvme_rdma_queue
*queue)
if (queue->pi_support) {
ret = ib_mr_pool_init(queue->qp, >qp->sig_mrs,
queue->queue_size, IB_MR_TYPE_INTEGRITY,
- pages_per_mr, pages_per_mr, 0);
+ pages_per_mr, pages_per_mr,
+ IB_ACCESS_RELAXED_ORDERING);
if (ret) {
dev_err(queue->ctrl->ctrl.device,
"failed to initialize PI MR pool sized %d for
QID %d\n",
@@ -1382,9 +1382,9 @@ static int nvme_rdma_map_sg_fr(struct nvme_rdma_queue
*queue,
req->reg_wr.wr.num_sge = 0;
req->reg_wr.mr = req->mr;
req->reg_wr.key = req->mr->rkey;
- req->reg_wr.access = IB_ACCESS_LOCAL_WRITE |
-IB_ACCESS_REMOTE_READ |
-IB_ACCESS_REMOTE_WRITE;
+ req->reg_wr.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
+IB_ACCESS_REMOTE_WRITE |
+IB_ACCESS_RELAXED_ORDERING;
sg->addr = cpu_to_le64(req->mr->iova);
put_unaligned_le24(req->mr->length, sg->length);
@@ -1488,9 +1488,8 @@ static int nvme_rdma_map_sg_pi(struct nvme_rdma_queue
*queue,
wr->wr.send_flags = 0;
wr->mr = req->mr;
wr->key = req->mr->rkey;
- wr->access = IB_ACCESS_LOCAL_WRITE |
-IB_ACCESS_REMOTE_READ |
-IB_ACCESS_REMOTE_WRITE;
+ wr->access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
+IB_ACCESS_REMOTE_WRITE | IB_ACCESS_RELAXED_ORDERING;
sg->addr = cpu_to_le64(req->mr->iova);
put_unaligned_le24(req->mr->length, sg->length);
--
2.30.2
[PATCH rdma-next 07/10] cifs: smbd: Enable Relaxed Ordering
From: Avihai Horon
Enable Relaxed Ordering for smbd.
Relaxed Ordering is an optional access flag and as such, it is ignored
by vendors that don't support it.
Signed-off-by: Avihai Horon
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
fs/cifs/smbdirect.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
index 647098a5cf3b..1e86dc8bbe85 100644
--- a/fs/cifs/smbdirect.c
+++ b/fs/cifs/smbdirect.c
@@ -2178,8 +2178,10 @@ static void smbd_mr_recovery_work(struct work_struct
*work)
continue;
}
- smbdirect_mr->mr = ib_alloc_mr(info->pd, info->mr_type,
- info->max_frmr_depth, 0);
+ smbdirect_mr->mr =
+ ib_alloc_mr(info->pd, info->mr_type,
+ info->max_frmr_depth,
+ IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(smbdirect_mr->mr)) {
log_rdma_mr(ERR, "ib_alloc_mr failed mr_type=%x
max_frmr_depth=%x\n",
info->mr_type,
@@ -2244,7 +2246,8 @@ static int allocate_mr_list(struct smbd_connection *info)
if (!smbdirect_mr)
goto out;
smbdirect_mr->mr = ib_alloc_mr(info->pd, info->mr_type,
- info->max_frmr_depth, 0);
+ info->max_frmr_depth,
+ IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(smbdirect_mr->mr)) {
log_rdma_mr(ERR, "ib_alloc_mr failed mr_type=%x
max_frmr_depth=%x\n",
info->mr_type, info->max_frmr_depth);
@@ -2406,9 +2409,10 @@ struct smbd_mr *smbd_register_mr(
reg_wr->wr.send_flags = IB_SEND_SIGNALED;
reg_wr->mr = smbdirect_mr->mr;
reg_wr->key = smbdirect_mr->mr->rkey;
- reg_wr->access = writing ?
- IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE :
- IB_ACCESS_REMOTE_READ;
+ reg_wr->access =
+ (writing ? IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE :
+ IB_ACCESS_REMOTE_READ) |
+ IB_ACCESS_RELAXED_ORDERING;
/*
* There is no need for waiting for complemtion on ib_post_send
--
2.30.2
[PATCH rdma-next 02/10] RDMA/core: Enable Relaxed Ordering in __ib_alloc_pd()
From: Avihai Horon
Enable Relaxed Ordering in __ib_alloc_pd() allocation of the
local_dma_lkey.
This will take effect only for devices that don't pre-allocate the lkey
but allocate it per PD allocation.
Signed-off-by: Avihai Horon
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/verbs.c | 3 ++-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index a1782f8a6ca0..9b719f7d6fd5 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -287,7 +287,8 @@ struct ib_pd *__ib_alloc_pd(struct ib_device *device,
unsigned int flags,
if (device->attrs.device_cap_flags & IB_DEVICE_LOCAL_DMA_LKEY)
pd->local_dma_lkey = device->local_dma_lkey;
else
- mr_access_flags |= IB_ACCESS_LOCAL_WRITE;
+ mr_access_flags |=
+ IB_ACCESS_LOCAL_WRITE | IB_ACCESS_RELAXED_ORDERING;
if (flags & IB_PD_UNSAFE_GLOBAL_RKEY) {
pr_warn("%s: enabling unsafe global rkey\n", caller);
diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
index b3fa783698a0..d74827694f92 100644
--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
+++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
@@ -66,6 +66,7 @@ struct ib_mr *pvrdma_get_dma_mr(struct ib_pd *pd, int acc)
int ret;
/* Support only LOCAL_WRITE flag for DMA MRs */
+ acc &= ~IB_ACCESS_RELAXED_ORDERING;
if (acc & ~IB_ACCESS_LOCAL_WRITE) {
dev_warn(>pdev->dev,
"unsupported dma mr access flags %#x\n", acc);
--
2.30.2
[PATCH rdma-next 05/10] RDMA/srp: Enable Relaxed Ordering
From: Avihai Horon
Enable Relaxed Ordering for srp.
Relaxed Ordering is an optional access flag and as such, it is ignored
by vendors that don't support it.
Signed-off-by: Avihai Horon
Reviewed-by: Max Gurtovoy
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/ulp/srp/ib_srp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 8481ad769ba4..0026660c3ead 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -436,7 +436,8 @@ static struct srp_fr_pool *srp_create_fr_pool(struct
ib_device *device,
mr_type = IB_MR_TYPE_MEM_REG;
for (i = 0, d = >desc[0]; i < pool->size; i++, d++) {
- mr = ib_alloc_mr(pd, mr_type, max_page_list_len, 0);
+ mr = ib_alloc_mr(pd, mr_type, max_page_list_len,
+IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(mr)) {
ret = PTR_ERR(mr);
if (ret == -ENOMEM)
@@ -1487,9 +1488,8 @@ static int srp_map_finish_fr(struct srp_map_state *state,
wr.wr.send_flags = 0;
wr.mr = desc->mr;
wr.key = desc->mr->rkey;
- wr.access = (IB_ACCESS_LOCAL_WRITE |
-IB_ACCESS_REMOTE_READ |
-IB_ACCESS_REMOTE_WRITE);
+ wr.access = (IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
+IB_ACCESS_REMOTE_WRITE | IB_ACCESS_RELAXED_ORDERING);
*state->fr.next++ = desc;
state->nmdesc++;
--
2.30.2
[PATCH rdma-next 04/10] RDMA/rtrs: Enable Relaxed Ordering
From: Avihai Horon
Enable Relaxed Ordering fro rtrs client and server.
Relaxed Ordering is an optional access flag and as such, it is ignored
by vendors that don't support it.
Signed-off-by: Avihai Horon
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/ulp/rtrs/rtrs-clt.c | 6 --
drivers/infiniband/ulp/rtrs/rtrs-srv.c | 15 ---
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-clt.c
b/drivers/infiniband/ulp/rtrs/rtrs-clt.c
index 0d3960ed5b2b..a3fbb47a3574 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-clt.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-clt.c
@@ -1099,7 +1099,8 @@ static int rtrs_clt_read_req(struct rtrs_clt_io_req *req)
.mr = req->mr,
.key = req->mr->rkey,
.access = (IB_ACCESS_LOCAL_WRITE |
- IB_ACCESS_REMOTE_WRITE),
+ IB_ACCESS_REMOTE_WRITE |
+ IB_ACCESS_RELAXED_ORDERING),
};
wr =
@@ -1260,7 +1261,8 @@ static int alloc_sess_reqs(struct rtrs_clt_sess *sess)
goto out;
req->mr = ib_alloc_mr(sess->s.dev->ib_pd, IB_MR_TYPE_MEM_REG,
- sess->max_pages_per_mr, 0);
+ sess->max_pages_per_mr,
+ IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(req->mr)) {
err = PTR_ERR(req->mr);
req->mr = NULL;
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
index 575f31ff20fd..c28ed5e2245d 100644
--- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c
+++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c
@@ -312,8 +312,8 @@ static int rdma_write_sg(struct rtrs_srv_op *id)
rwr.mr = srv_mr->mr;
rwr.wr.send_flags = 0;
rwr.key = srv_mr->mr->rkey;
- rwr.access = (IB_ACCESS_LOCAL_WRITE |
- IB_ACCESS_REMOTE_WRITE);
+ rwr.access = (IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE |
+ IB_ACCESS_RELAXED_ORDERING);
msg = srv_mr->iu->buf;
msg->buf_id = cpu_to_le16(id->msg_id);
msg->type = cpu_to_le16(RTRS_MSG_RKEY_RSP);
@@ -432,8 +432,8 @@ static int send_io_resp_imm(struct rtrs_srv_con *con,
struct rtrs_srv_op *id,
rwr.wr.send_flags = 0;
rwr.mr = srv_mr->mr;
rwr.key = srv_mr->mr->rkey;
- rwr.access = (IB_ACCESS_LOCAL_WRITE |
- IB_ACCESS_REMOTE_WRITE);
+ rwr.access = (IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE |
+ IB_ACCESS_RELAXED_ORDERING);
msg = srv_mr->iu->buf;
msg->buf_id = cpu_to_le16(id->msg_id);
msg->type = cpu_to_le16(RTRS_MSG_RKEY_RSP);
@@ -638,7 +638,7 @@ static int map_cont_bufs(struct rtrs_srv_sess *sess)
goto free_sg;
}
mr = ib_alloc_mr(sess->s.dev->ib_pd, IB_MR_TYPE_MEM_REG,
-sgt->nents, 0);
+sgt->nents, IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(mr)) {
err = PTR_ERR(mr);
goto unmap_sg;
@@ -823,8 +823,9 @@ static int process_info_req(struct rtrs_srv_con *con,
rwr[mri].wr.send_flags = 0;
rwr[mri].mr = mr;
rwr[mri].key = mr->rkey;
- rwr[mri].access = (IB_ACCESS_LOCAL_WRITE |
- IB_ACCESS_REMOTE_WRITE);
+ rwr[mri].access =
+ (IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE |
+IB_ACCESS_RELAXED_ORDERING);
reg_wr = [mri].wr;
}
--
2.30.2
[PATCH rdma-next 01/10] RDMA: Add access flags to ib_alloc_mr() and ib_mr_pool_init()
From: Avihai Horon
Add access flags parameter to ib_alloc_mr() and to ib_mr_pool_init(),
and refactor relevant code. This parameter is used to pass MR access
flags during MR allocation.
In the following patches, the new access flags parameter will be used
to enable Relaxed Ordering for ib_alloc_mr() and ib_mr_pool_init() users.
Signed-off-by: Avihai Horon
Reviewed-by: Max Gurtovoy
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/mr_pool.c | 7 +-
drivers/infiniband/core/rw.c | 12 ++--
drivers/infiniband/core/verbs.c | 23 +--
drivers/infiniband/hw/bnxt_re/ib_verbs.c | 2 +-
drivers/infiniband/hw/bnxt_re/ib_verbs.h | 2 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h| 2 +-
drivers/infiniband/hw/cxgb4/mem.c | 2 +-
drivers/infiniband/hw/hns/hns_roce_device.h | 2 +-
drivers/infiniband/hw/hns/hns_roce_mr.c | 2 +-
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 3 +-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 2 +-
drivers/infiniband/hw/mlx4/mr.c | 2 +-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 12 ++--
drivers/infiniband/hw/mlx5/mr.c | 61
drivers/infiniband/hw/mlx5/wr.c | 69 ++-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +-
drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 2 +-
drivers/infiniband/hw/qedr/verbs.c| 2 +-
drivers/infiniband/hw/qedr/verbs.h| 2 +-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 3 +-
.../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +-
drivers/infiniband/sw/rdmavt/mr.c | 3 +-
drivers/infiniband/sw/rdmavt/mr.h | 2 +-
drivers/infiniband/sw/rxe/rxe_verbs.c | 2 +-
drivers/infiniband/sw/siw/siw_verbs.c | 2 +-
drivers/infiniband/sw/siw/siw_verbs.h | 2 +-
drivers/infiniband/ulp/iser/iser_verbs.c | 4 +-
drivers/infiniband/ulp/rtrs/rtrs-clt.c| 2 +-
drivers/infiniband/ulp/rtrs/rtrs-srv.c| 2 +-
drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
drivers/nvme/host/rdma.c | 4 +-
fs/cifs/smbdirect.c | 7 +-
include/rdma/ib_verbs.h | 11 ++-
include/rdma/mr_pool.h| 3 +-
net/rds/ib_frmr.c | 2 +-
net/smc/smc_ib.c | 2 +-
net/sunrpc/xprtrdma/frwr_ops.c| 2 +-
37 files changed, 163 insertions(+), 105 deletions(-)
diff --git a/drivers/infiniband/core/mr_pool.c
b/drivers/infiniband/core/mr_pool.c
index c0e2df128b34..b869c3487475 100644
--- a/drivers/infiniband/core/mr_pool.c
+++ b/drivers/infiniband/core/mr_pool.c
@@ -34,7 +34,8 @@ void ib_mr_pool_put(struct ib_qp *qp, struct list_head *list,
struct ib_mr *mr)
EXPORT_SYMBOL(ib_mr_pool_put);
int ib_mr_pool_init(struct ib_qp *qp, struct list_head *list, int nr,
- enum ib_mr_type type, u32 max_num_sg, u32 max_num_meta_sg)
+ enum ib_mr_type type, u32 max_num_sg, u32 max_num_meta_sg,
+ u32 access)
{
struct ib_mr *mr;
unsigned long flags;
@@ -43,9 +44,9 @@ int ib_mr_pool_init(struct ib_qp *qp, struct list_head *list,
int nr,
for (i = 0; i < nr; i++) {
if (type == IB_MR_TYPE_INTEGRITY)
mr = ib_alloc_mr_integrity(qp->pd, max_num_sg,
- max_num_meta_sg);
+ max_num_meta_sg, access);
else
- mr = ib_alloc_mr(qp->pd, type, max_num_sg);
+ mr = ib_alloc_mr(qp->pd, type, max_num_sg, access);
if (IS_ERR(mr)) {
ret = PTR_ERR(mr);
goto out;
diff --git a/drivers/infiniband/core/rw.c b/drivers/infiniband/core/rw.c
index a588c2038479..d5a0038e82a4 100644
--- a/drivers/infiniband/core/rw.c
+++ b/drivers/infiniband/core/rw.c
@@ -110,7 +110,7 @@ static int rdma_rw_init_one_mr(struct ib_qp *qp, u32
port_num,
reg->reg_wr.wr.opcode = IB_WR_REG_MR;
reg->reg_wr.mr = reg->mr;
- reg->reg_wr.access = IB_ACCESS_LOCAL_WRITE;
+ reg->reg_wr.access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_RELAXED_ORDERING;
if (rdma_protocol_iwarp(qp->device, port_num))
reg->reg_wr.access |= IB_ACCESS_REMOTE_WRITE;
count++;
@@ -437,7 +437,8 @@ int rdma_rw_ctx_signature_init(struct rdma_rw_ctx *ctx,
struct ib_qp *qp,
ctx->reg->reg_wr.wr.wr_cqe = NULL;
ctx->reg->reg_wr.wr.num_sge = 0;
ctx->reg->reg_wr.wr.send_flags = 0;
- ctx->reg->reg_wr.access = IB_ACCESS_LOCAL_WRITE;
+ ctx->reg->reg_wr.access =
+ IB_ACCESS_LOCAL_WRITE | IB_ACCESS_RELAXED_ORDERING;
if (rdma_protocol_iwarp(qp->device, port_num))
[PATCH rdma-next 03/10] RDMA/iser: Enable Relaxed Ordering
From: Avihai Horon
Enable Relaxed Ordering for iser.
Relaxed Ordering is an optional access flag and as such, it is ignored
by vendors that don't support it.
Signed-off-by: Avihai Horon
Reviewed-by: Max Gurtovoy
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/ulp/iser/iser_memory.c | 10 --
drivers/infiniband/ulp/iser/iser_verbs.c | 6 --
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iser_memory.c
b/drivers/infiniband/ulp/iser/iser_memory.c
index afec40da9b58..29849c9e82e8 100644
--- a/drivers/infiniband/ulp/iser/iser_memory.c
+++ b/drivers/infiniband/ulp/iser/iser_memory.c
@@ -271,9 +271,8 @@ iser_reg_sig_mr(struct iscsi_iser_task *iser_task,
wr->wr.send_flags = 0;
wr->mr = mr;
wr->key = mr->rkey;
- wr->access = IB_ACCESS_LOCAL_WRITE |
-IB_ACCESS_REMOTE_READ |
-IB_ACCESS_REMOTE_WRITE;
+ wr->access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
+IB_ACCESS_REMOTE_WRITE | IB_ACCESS_RELAXED_ORDERING;
rsc->mr_valid = 1;
sig_reg->sge.lkey = mr->lkey;
@@ -318,9 +317,8 @@ static int iser_fast_reg_mr(struct iscsi_iser_task
*iser_task,
wr->wr.num_sge = 0;
wr->mr = mr;
wr->key = mr->rkey;
- wr->access = IB_ACCESS_LOCAL_WRITE |
-IB_ACCESS_REMOTE_WRITE |
-IB_ACCESS_REMOTE_READ;
+ wr->access = IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_WRITE |
+IB_ACCESS_REMOTE_READ | IB_ACCESS_RELAXED_ORDERING;
rsc->mr_valid = 1;
diff --git a/drivers/infiniband/ulp/iser/iser_verbs.c
b/drivers/infiniband/ulp/iser/iser_verbs.c
index 3c370ee25f2f..1e236b1cf29b 100644
--- a/drivers/infiniband/ulp/iser/iser_verbs.c
+++ b/drivers/infiniband/ulp/iser/iser_verbs.c
@@ -121,7 +121,8 @@ iser_create_fastreg_desc(struct iser_device *device,
else
mr_type = IB_MR_TYPE_MEM_REG;
- desc->rsc.mr = ib_alloc_mr(pd, mr_type, size, 0);
+ desc->rsc.mr = ib_alloc_mr(pd, mr_type, size,
+ IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(desc->rsc.mr)) {
ret = PTR_ERR(desc->rsc.mr);
iser_err("Failed to allocate ib_fast_reg_mr err=%d\n", ret);
@@ -129,7 +130,8 @@ iser_create_fastreg_desc(struct iser_device *device,
}
if (pi_enable) {
- desc->rsc.sig_mr = ib_alloc_mr_integrity(pd, size, size, 0);
+ desc->rsc.sig_mr = ib_alloc_mr_integrity(pd, size, size,
+ IB_ACCESS_RELAXED_ORDERING);
if (IS_ERR(desc->rsc.sig_mr)) {
ret = PTR_ERR(desc->rsc.sig_mr);
iser_err("Failed to allocate sig_mr err=%d\n", ret);
--
2.30.2
[PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
From: Leon Romanovsky >From Avihai, Relaxed Ordering is a PCIe mechanism that relaxes the strict ordering imposed on PCI transactions, and thus, can improve performance. Until now, relaxed ordering could be set only by user space applications for user MRs. The following patch series enables relaxed ordering for the kernel ULPs as well. Relaxed ordering is an optional capability, and as such, it is ignored by vendors that don't support it. The following test results show the performance improvement achieved with relaxed ordering. The test was performed on a NVIDIA A100 in order to check performance of storage infrastructure over xprtrdma: Without Relaxed Ordering: READ: bw=16.5GiB/s (17.7GB/s), 16.5GiB/s-16.5GiB/s (17.7GB/s-17.7GB/s), io=1987GiB (2133GB), run=120422-120422msec With relaxed ordering: READ: bw=72.9GiB/s (78.2GB/s), 72.9GiB/s-72.9GiB/s (78.2GB/s-78.2GB/s), io=2367GiB (2542GB), run=32492-32492msec Thanks Avihai Horon (10): RDMA: Add access flags to ib_alloc_mr() and ib_mr_pool_init() RDMA/core: Enable Relaxed Ordering in __ib_alloc_pd() RDMA/iser: Enable Relaxed Ordering RDMA/rtrs: Enable Relaxed Ordering RDMA/srp: Enable Relaxed Ordering nvme-rdma: Enable Relaxed Ordering cifs: smbd: Enable Relaxed Ordering net/rds: Enable Relaxed Ordering net/smc: Enable Relaxed Ordering xprtrdma: Enable Relaxed Ordering drivers/infiniband/core/mr_pool.c | 7 +- drivers/infiniband/core/rw.c | 12 ++-- drivers/infiniband/core/verbs.c | 26 +-- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 2 +- drivers/infiniband/hw/bnxt_re/ib_verbs.h | 2 +- drivers/infiniband/hw/cxgb4/iw_cxgb4.h| 2 +- drivers/infiniband/hw/cxgb4/mem.c | 2 +- drivers/infiniband/hw/hns/hns_roce_device.h | 2 +- drivers/infiniband/hw/hns/hns_roce_mr.c | 2 +- drivers/infiniband/hw/i40iw/i40iw_verbs.c | 3 +- drivers/infiniband/hw/mlx4/mlx4_ib.h | 2 +- drivers/infiniband/hw/mlx4/mr.c | 2 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 12 ++-- drivers/infiniband/hw/mlx5/mr.c | 61 drivers/infiniband/hw/mlx5/wr.c | 69 ++- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_verbs.h | 2 +- drivers/infiniband/hw/qedr/verbs.c| 2 +- drivers/infiniband/hw/qedr/verbs.h| 2 +- drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 4 +- .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +- drivers/infiniband/sw/rdmavt/mr.c | 3 +- drivers/infiniband/sw/rdmavt/mr.h | 2 +- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 +- drivers/infiniband/sw/siw/siw_verbs.c | 2 +- drivers/infiniband/sw/siw/siw_verbs.h | 2 +- drivers/infiniband/ulp/iser/iser_memory.c | 10 ++- drivers/infiniband/ulp/iser/iser_verbs.c | 6 +- drivers/infiniband/ulp/rtrs/rtrs-clt.c| 6 +- drivers/infiniband/ulp/rtrs/rtrs-srv.c| 15 ++-- drivers/infiniband/ulp/srp/ib_srp.c | 8 +-- drivers/nvme/host/rdma.c | 19 +++-- fs/cifs/smbdirect.c | 17 +++-- include/rdma/ib_verbs.h | 11 ++- include/rdma/mr_pool.h| 3 +- net/rds/ib_frmr.c | 7 +- net/smc/smc_ib.c | 3 +- net/smc/smc_wr.c | 3 +- net/sunrpc/xprtrdma/frwr_ops.c| 10 +-- 39 files changed, 209 insertions(+), 140 deletions(-) -- 2.30.2
Re: [PATCH v5 15/19] regulator: Support ROHM BD71815 regulators
On Sun, 2021-04-04 at 19:21 +0300, Matti Vaittinen wrote: > On Fri, 2021-04-02 at 18:42 +0100, Mark Brown wrote: > > On Mon, Mar 29, 2021 at 03:59:51PM +0300, Matti Vaittinen wrote: > > > > Acked-by: Mark Brown > > > > but... > > Do you want me to respin the series or do you think this can be > applied > as-is and fixed by a follow-up? Actually, this was a bit stupid question. I will resend the series as I have also some small fixes to the GPIO. Best Regards Matti Vaittinen
[PATCH] mtd: rawnand: qcom: Use dma_mapping_error() for error check
dma_mapping_error() should be used for checking the error value of dma_map_resource() API. Signed-off-by: Manivannan Sadhasivam --- drivers/mtd/nand/raw/qcom_nandc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index fe74cf3aece5..07b3c156a802 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2990,7 +2990,7 @@ static int qcom_nandc_probe(struct platform_device *pdev) nandc->base_dma = dma_map_resource(dev, res->start, resource_size(res), DMA_BIDIRECTIONAL, 0); - if (!nandc->base_dma) + if (dma_mapping_error(dev, nandc->base_dma)) return -ENXIO; ret = qcom_nandc_alloc(nandc); -- 2.25.1
Re: [PATCH RESEND v1 3/4] powerpc/vdso: Separate vvar vma from vdso
On Wed, Mar 31, 2021 at 04:48:46PM +, Christophe Leroy wrote:
> From: Dmitry Safonov
>
> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
> VVAR page is in front of the VDSO area. In result it breaks CRIU
> (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]"
> from /proc/../maps points at ELF/vdso image, rather than at VVAR data page.
> Laurent made a patch to keep CRIU working (by reading aux vector).
> But I think it still makes sence to separate two mappings into different
> VMAs. It will also make ppc64 less "special" for userspace and as
> a side-bonus will make VVAR page un-writable by debugger (which previously
> would COW page and can be unexpected).
>
> I opportunistically Cc stable on it: I understand that usually such
> stuff isn't a stable material, but that will allow us in CRIU have
> one workaround less that is needed just for one release (v5.11) on
> one platform (ppc64), which we otherwise have to maintain.
> I wouldn't go as far as to say that the commit 511157ab641e is ABI
> regression as no other userspace got broken, but I'd really appreciate
> if it gets backported to v5.11 after v5.12 is released, so as not
> to complicate already non-simple CRIU-vdso code. Thanks!
>
> Cc: Andrei Vagin
Acked-by: Andrei Vagin
> Cc: Andy Lutomirski
> Cc: Benjamin Herrenschmidt
> Cc: Christophe Leroy
> Cc: Laurent Dufour
> Cc: Michael Ellerman
> Cc: Paul Mackerras
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: sta...@vger.kernel.org # v5.11
> [1]: https://github.com/checkpoint-restore/criu/issues/1417
> Signed-off-by: Dmitry Safonov
> Tested-by: Christophe Leroy
> Signed-off-by: Christophe Leroy
Re: [PATCH RESEND v1 2/4] lib/vdso: Add vdso_data pointer as input to __arch_get_timens_vdso_data()
On Wed, Mar 31, 2021 at 04:48:45PM +, Christophe Leroy wrote:
> For the same reason as commit e876f0b69dc9 ("lib/vdso: Allow
> architectures to provide the vdso data pointer"), powerpc wants to
> avoid calculation of relative position to code.
>
> As the timens_vdso_data is next page to vdso_data, provide
> vdso_data pointer to __arch_get_timens_vdso_data() in order
> to ease the calculation on powerpc in following patches.
>
Acked-by: Andrei Vagin
> Signed-off-by: Christophe Leroy
Re: [PATCH] net/mlx5: fix kfree mismatch in indir_table.c
On Mon, Apr 05, 2021 at 10:53:39AM +0800, Xiaoming Ni wrote:
> Memory allocated by kvzalloc() should be freed by kvfree().
>
> Fixes: 34ca65352ddf2 ("net/mlx5: E-Switch, Indirect table infrastructur")
> Signed-off-by: Xiaoming Ni
> ---
> .../net/ethernet/mellanox/mlx5/core/esw/indir_table.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky
Re: [PATCH RESEND v1 4/4] powerpc/vdso: Add support for time namespaces
On Wed, Mar 31, 2021 at 04:48:47PM +, Christophe Leroy wrote: > This patch adds the necessary glue to provide time namespaces. > > Things are mainly copied from ARM64. > > __arch_get_timens_vdso_data() calculates timens vdso data position > based on the vdso data position, knowing it is the next page in vvar. > This avoids having to redo the mflr/bcl/mflr/mtlr dance to locate > the page relative to running code position. > Acked-by: Andrei Vagin > Signed-off-by: Christophe Leroy
YOUR COMPENSATION MONEY
Dear Friend, I'm sorry but happy to inform you about my success in getting those funds transferred under the cooperation of a new partner from Vietnam though i tried my best to involve you in the business but God decided the whole situations. Presently i'm in Vietnam for investment projects with my own share of the total sum. Meanwhile, i didn't forget your past efforts and attempts to assist me in transferring those funds despite that it failed us some how. Now contact my secretary her name is Ms.Aisha Atan on her e-mail address here: ( aishaatansecreta...@gmail.com ) Ask her to send you the total of ( Hundred thousand united states dollars, $100.000.00 ) which i kept for your compensation for all the past efforts and attempts to assist me in this matter. I appreciated your efforts at that time very much. so feel free and get in touched with my secretary Ms.Aisha Atan and instruct her where to send the amount to you. Please do let me know immediately you receive it so that we can share the joy after all the sufferer at that time. In the moment, I’m very busy here because of the investment projects which I and the new partner are having at hand, finally, remembers that I had forwarded instruction to the secretary on your behalf to receive that money, so feel free to get in touch with Ms.Aisha Atan.She will send the amount to you without any delay. Regards
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04, 2021 at 09:01:25PM -0700, Paul E. McKenney wrote:
> On Mon, Apr 05, 2021 at 04:08:55AM +0100, Matthew Wilcox wrote:
> > On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote:
> > > On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote:
> > > > On Sun, Apr 04 2021 at 12:05, syzbot wrote:
> > > >
> > > > Cc + ...
> > >
> > > And a couple more...
> > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following issue on:
> > > > >
> > > > > HEAD commit:5e46d1b7 reiserfs: update
> > > > > reiserfs_xattrs_initialized() co..
> > > > > git tree: upstream
> > > > > console output:
> > > > > https://syzkaller.appspot.com/x/log.txt?x=1125f831d0
> > > > > kernel config:
> > > > > https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> > > > > dashboard link:
> > > > > https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d
> > > > >
> > > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > > >
> > > > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > > > commit:
> > > > > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com
> > > > >
> > > > > =
> > > > > WARNING: suspicious RCU usage
> > > > > 5.12.0-rc5-syzkaller #0 Not tainted
> > > > > -
> > > > > kernel/sched/core.c:8294 Illegal context switch in RCU-sched
> > > > > read-side critical section!
> > > > >
> > > > > other info that might help us debug this:
> > > > >
> > > > >
> > > > > rcu_scheduler_active = 2, debug_locks = 0
> > > > > 3 locks held by syz-executor.4/8418:
> > > > > #0:
> > > > > 8880751d2b28
> > > > > (
> > > > > >pi_lock
> > > > > ){-.-.}-{2:2}
> > > > > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345
> > > > > #1:
> > > > > 8880b9d35258
> > > > > (
> > > > > >lock
> > > > > ){-.-.}-{2:2}
> > > > > , at: rq_lock kernel/sched/sched.h:1321 [inline]
> > > > > , at: ttwu_queue kernel/sched/core.c:3184 [inline]
> > > > > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464
> > > > > #2: 8880b9d1f948 (_cpu_ptr(group->pcpu,
> > > > > cpu)->seq){-.-.}-{0:0}, at: psi_task_change+0x142/0x220
> > > > > kernel/sched/psi.c:807
> > >
> > > This looks similar to
> > > syzbot+dde0cc33951735441...@syzkaller.appspotmail.com
> > > in that rcu_sleep_check() sees an RCU lock held, but the later call to
> > > lockdep_print_held_locks() does not. Did something change recently that
> > > could let the ->lockdep_depth counter get out of sync with the actual
> > > number of locks held?
> >
> > Dmitri had a different theory here:
> >
> > https://groups.google.com/g/syzkaller-bugs/c/FmYvfZCZzqA/m/nc2CXUgsAgAJ
>
> There is always room for more than one bug. ;-)
>
> He says "one-off false positives". I was afraid of that...
And both the examples I have been copied on today are consistent with
debug_locks getting zeroed (e.g., via a call to __debug_locks_off())
in the midst of a call to rcu_sleep_check(). But I would expect to see
a panic or another splat if that were to happen.
Dmitry's example did have an additional splat, but I would expect the
RCU-related one to come second. Again, there is always room for more
than one bug.
On the other hand, there are a lot more callers to debug_locks_off()
than there were last I looked into this. And both of these splats
are consistent with an interrupt in the middle of rcu_sleep_check(),
and that interrupt's handler invoking debug_locks_off(), but without
printing anything to the console. Does that sequence of events ring a
bell for anyone?
If this is the new normal, I could make RCU_LOCKDEP_WARN() recheck
debug_lockdep_rcu_enabled() after evaluating the condition, but with
a memory barrier immediately before the recheck. But I am not at all
excited by doing this on speculation. Especially given that doing
so might be covering up some other bug.
Thanx, Paul
Re: [PATCH] Kbuild: Update config_data.gz only if KCONFIG_CONFIG materially changed
On 4/2/2021 10:11 PM, Masahiro Yamada wrote: On Fri, Apr 2, 2021 at 7:45 AM Elliot Berman wrote: If you update the timestamp of KCONFIG_CONFIG without actually changing anything, config_data.gz is re-generated and causes vmlinux to re-link. When Link Time Optimization is enabled, unnecessary re-linking of vmlinux is highly desirable since it adds several minutes to build time. Avoid touching config_data.gz by using filechk to compare the existing config_data.gz and update only if it changed. The .config can be touched, for instance, by a build script which installs the default defconfig and then applies a defconfig fragment on top. For a simple example on my x86 machine, I modified x86 default defconfig to set CONFIG_IKCONFIG=y and run: make -j50 defconfig tiny.config vmlinux make -j50 defconfig tiny.config vmlinux With this patch, vmlinux is not re-built as a result of config_data.gz change. Signed-off-by: Elliot Berman --- kernel/Makefile | 2 +- scripts/Makefile.lib | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/Makefile b/kernel/Makefile index 320f1f3..bd4e558 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -140,7 +140,7 @@ $(obj)/configs.o: $(obj)/config_data.gz targets += config_data.gz $(obj)/config_data.gz: $(KCONFIG_CONFIG) FORCE - $(call if_changed,gzip) + $(call filechk,gzip) I do not think this is the right approach because gzip is executed every time, even if the time stamp is not changed. Since .config is relatively small, gzip was quickly producing the same binary in multiple runs on my host. I thought about following gen_ikheaders.sh approach of comparing the md5sum, but I felt it was more complex than using filechk and re-compressing every time. I'll send a v2 tomorrow which follows gen_ikheaders.sh approach. $(obj)/kheaders.o: $(obj)/kheaders_data.tar.xz diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index a4fbaf8..81d3ec1 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -282,6 +282,8 @@ cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@ quiet_cmd_gzip = GZIP$@ cmd_gzip = cat $(real-prereqs) | $(KGZIP) -n -f -9 > $@ +filechk_gzip = cat $(real-prereqs) | $(KGZIP) -n -f -9 + # DTC # --- DTC ?= $(objtree)/scripts/dtc/dtc -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Mon, Apr 05, 2021 at 04:08:55AM +0100, Matthew Wilcox wrote:
> On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote:
> > On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote:
> > > On Sun, Apr 04 2021 at 12:05, syzbot wrote:
> > >
> > > Cc + ...
> >
> > And a couple more...
> >
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized()
> > > > co..
> > > > git tree: upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1125f831d0
> > > > kernel config:
> > > > https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> > > > dashboard link:
> > > > https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d
> > > >
> > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > > commit:
> > > > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com
> > > >
> > > > =
> > > > WARNING: suspicious RCU usage
> > > > 5.12.0-rc5-syzkaller #0 Not tainted
> > > > -
> > > > kernel/sched/core.c:8294 Illegal context switch in RCU-sched read-side
> > > > critical section!
> > > >
> > > > other info that might help us debug this:
> > > >
> > > >
> > > > rcu_scheduler_active = 2, debug_locks = 0
> > > > 3 locks held by syz-executor.4/8418:
> > > > #0:
> > > > 8880751d2b28
> > > > (
> > > > >pi_lock
> > > > ){-.-.}-{2:2}
> > > > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345
> > > > #1:
> > > > 8880b9d35258
> > > > (
> > > > >lock
> > > > ){-.-.}-{2:2}
> > > > , at: rq_lock kernel/sched/sched.h:1321 [inline]
> > > > , at: ttwu_queue kernel/sched/core.c:3184 [inline]
> > > > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464
> > > > #2: 8880b9d1f948 (_cpu_ptr(group->pcpu,
> > > > cpu)->seq){-.-.}-{0:0}, at: psi_task_change+0x142/0x220
> > > > kernel/sched/psi.c:807
> >
> > This looks similar to syzbot+dde0cc33951735441...@syzkaller.appspotmail.com
> > in that rcu_sleep_check() sees an RCU lock held, but the later call to
> > lockdep_print_held_locks() does not. Did something change recently that
> > could let the ->lockdep_depth counter get out of sync with the actual
> > number of locks held?
>
> Dmitri had a different theory here:
>
> https://groups.google.com/g/syzkaller-bugs/c/FmYvfZCZzqA/m/nc2CXUgsAgAJ
There is always room for more than one bug. ;-)
He says "one-off false positives". I was afraid of that...
Thanx, Paul
Re: [PATCH 1/1] of: properly check for error returned by fdt_get_name()
Hi Guenter,
Can you please test this patch to see if it prevents the crash on
openrisc that you reported in
https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/
Just after start of unittest you should see a warning about
testcases.
Thanks,
Frank
On 4/4/21 10:28 PM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> fdt_get_name() returns error values via a parameter pointer
> instead of in function return. Fix check for this error value
> in populate_node() and callers of populate_node().
>
> Chasing up the caller tree showed callers of various functions
> failing to initialize the value of pointer parameters that
> can return error values. Initialize those values to NULL.
>
> The bug was introduced by
> commit e6a6928c3ea1 ("of/fdt: Convert FDT functions to use libfdt")
> but this patch can not be backported directly to that commit
> because the relevant code has further been restructured by
> commit dfbd4c6eff35 ("drivers/of: Split unflatten_dt_node()")
>
> The bug became visible by triggering a crash on openrisc with:
> commit 79edff12060f ("scripts/dtc: Update to upstream version
> v1.6.0-51-g183df9e9c2b9")
> as reported in:
> https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/
>
> Fixes: commit 79edff12060f ("scripts/dtc: Update to upstream version
> v1.6.0-51-g183df9e9c2b9")
> Reported-by: Guenter Roeck
> Signed-off-by: Frank Rowand
>
> ---
>
> This patch papers over the unaligned pointer passed to
> of_fdt_unflatten_tree() bug that Guenter reported in
> https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/
>
> I will create a separate patch to fix that problem.
>
> drivers/of/fdt.c | 36 +++-
> drivers/of/overlay.c | 2 +-
> drivers/of/unittest.c | 15 ++-
> 3 files changed, 34 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index dcc1dd96911a..adb26aff481d 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -205,7 +205,7 @@ static void populate_properties(const void *blob,
> *pprev = NULL;
> }
>
> -static bool populate_node(const void *blob,
> +static int populate_node(const void *blob,
> int offset,
> void **mem,
> struct device_node *dad,
> @@ -214,24 +214,24 @@ static bool populate_node(const void *blob,
> {
> struct device_node *np;
> const char *pathp;
> - unsigned int l, allocl;
> + int len;
>
> - pathp = fdt_get_name(blob, offset, );
> + pathp = fdt_get_name(blob, offset, );
> if (!pathp) {
> *pnp = NULL;
> - return false;
> + return len;
> }
>
> - allocl = ++l;
> + len++;
>
> - np = unflatten_dt_alloc(mem, sizeof(struct device_node) + allocl,
> + np = unflatten_dt_alloc(mem, sizeof(struct device_node) + len,
> __alignof__(struct device_node));
> if (!dryrun) {
> char *fn;
> of_node_init(np);
> np->full_name = fn = ((char *)np) + sizeof(*np);
>
> - memcpy(fn, pathp, l);
> + memcpy(fn, pathp, len);
>
> if (dad != NULL) {
> np->parent = dad;
> @@ -295,6 +295,7 @@ static int unflatten_dt_nodes(const void *blob,
> struct device_node *nps[FDT_MAX_DEPTH];
> void *base = mem;
> bool dryrun = !base;
> + int ret;
>
> if (nodepp)
> *nodepp = NULL;
> @@ -322,9 +323,10 @@ static int unflatten_dt_nodes(const void *blob,
> !of_fdt_device_is_available(blob, offset))
> continue;
>
> - if (!populate_node(blob, offset, , nps[depth],
> -[depth+1], dryrun))
> - return mem - base;
> + ret = populate_node(blob, offset, , nps[depth],
> +[depth+1], dryrun);
> + if (ret < 0)
> + return ret;
>
> if (!dryrun && nodepp && !*nodepp)
> *nodepp = nps[depth+1];
> @@ -372,6 +374,10 @@ void *__unflatten_device_tree(const void *blob,
> {
> int size;
> void *mem;
> + int ret;
> +
> + if (mynodes)
> + *mynodes = NULL;
>
> pr_debug(" -> unflatten_device_tree()\n");
>
> @@ -392,7 +398,7 @@ void *__unflatten_device_tree(const void *blob,
>
> /* First pass, scan for size */
> size = unflatten_dt_nodes(blob, NULL, dad, NULL);
> - if (size < 0)
> + if (size <= 0)
> return NULL;
>
> size = ALIGN(size, 4);
> @@ -410,12 +416,16 @@ void *__unflatten_device_tree(const void *blob,
> pr_debug(" unflattening %p...\n", mem);
>
> /* Second pass, do actual unflattening */
> - unflatten_dt_nodes(blob, mem, dad, mynodes);
> + ret = unflatten_dt_nodes(blob, mem, dad,
[PATCH 10/10] tty: tty_ldisc: Remove the repeated word 'the'
Remove the repeated word 'the' following advice of checkpatch.pl Signed-off-by: Xiaofei Tan --- drivers/tty/tty_ldisc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index 56e67f7..fdc4fa3 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -147,7 +147,7 @@ static int tty_ldisc_autoload = IS_BUILTIN(CONFIG_LDISC_AUTOLOAD); * Returns: -EINVAL if the discipline index is not [N_TTY..NR_LDISCS] or * if the discipline is not registered * -EAGAIN if request_module() failed to load or register the - * the discipline + * discipline * -ENOMEM if allocation failure * * Otherwise, returns a pointer to the discipline and bumps the -- 2.8.1
[PATCH 06/10] tty: tty_ldisc: Fix an issue of code indent should use tabs
Fix an issue of code indent should use tabs, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan
---
drivers/tty/tty_ldisc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 1ba74d6..2992319 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -459,7 +459,7 @@ static int tty_ldisc_open(struct tty_struct *tty, struct
tty_ldisc *ld)
WARN_ON(test_and_set_bit(TTY_LDISC_OPEN, >flags));
if (ld->ops->open) {
int ret;
-/* BTM here locks versus a hangup event */
+ /* BTM here locks versus a hangup event */
ret = ld->ops->open(tty);
if (ret)
clear_bit(TTY_LDISC_OPEN, >flags);
--
2.8.1
[PATCH 08/10] tty: tty_ldisc: Fix coding style issues of block comments
Fix coding style issues of block comments, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan
---
drivers/tty/tty_ldisc.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index df0b589..874d238 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -529,9 +529,11 @@ static void tty_ldisc_restore(struct tty_struct *tty,
struct tty_ldisc *old)
const char *name = tty_name(tty);
pr_warn("Falling back ldisc for %s.\n", name);
- /* The traditional behaviour is to fall back to N_TTY, we
- want to avoid falling back to N_NULL unless we have no
- choice to avoid the risk of breaking anything */
+ /*
+* The traditional behaviour is to fall back to N_TTY, we
+* want to avoid falling back to N_NULL unless we have no
+* choice to avoid the risk of breaking anything
+*/
if (tty_ldisc_failto(tty, N_TTY) < 0 &&
tty_ldisc_failto(tty, N_NULL) < 0)
panic("Couldn't open N_NULL ldisc for %s.", name);
@@ -600,17 +602,21 @@ int tty_set_ldisc(struct tty_struct *tty, int disc)
up_read(>termios_rwsem);
}
- /* At this point we hold a reference to the new ldisc and a
- reference to the old ldisc, or we hold two references to
- the old ldisc (if it was restored as part of error cleanup
- above). In either case, releasing a single reference from
- the old ldisc is correct. */
+ /*
+* At this point we hold a reference to the new ldisc and a
+* reference to the old ldisc, or we hold two references to
+* the old ldisc (if it was restored as part of error cleanup
+* above). In either case, releasing a single reference from
+* the old ldisc is correct.
+*/
new_ldisc = old_ldisc;
out:
tty_ldisc_unlock(tty);
- /* Restart the work queue in case no characters kick it off. Safe if
- already running */
+ /*
+* Restart the work queue in case no characters kick it off. Safe if
+* already running
+*/
tty_buffer_restart_work(tty->port);
err:
tty_ldisc_put(new_ldisc); /* drop the extra reference */
@@ -812,8 +818,10 @@ void tty_ldisc_release(struct tty_struct *tty)
tty_ldisc_kill(o_tty);
tty_ldisc_unlock_pair(tty, o_tty);
- /* And the memory resources remaining (buffers, termios) will be
- disposed of when the kref hits zero */
+ /*
+* And the memory resources remaining (buffers, termios) will be
+* disposed of when the kref hits zero
+*/
tty_ldisc_debug(tty, "released\n");
}
--
2.8.1
[PATCH 09/10] tty: tty_ldisc: Do not use assignment in if condition
Do not use assignment in if condition following the advice of checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_ldisc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c index 874d238..56e67f7 100644 --- a/drivers/tty/tty_ldisc.c +++ b/drivers/tty/tty_ldisc.c @@ -508,7 +508,8 @@ static int tty_ldisc_failto(struct tty_struct *tty, int ld) return PTR_ERR(disc); tty->ldisc = disc; tty_set_termios_ldisc(tty, ld); - if ((r = tty_ldisc_open(tty, disc)) < 0) + r = tty_ldisc_open(tty, disc); + if (r < 0) tty_ldisc_put(disc); return r; } -- 2.8.1
[PATCH 01/10] tty/sysrq: Add a blank line after declarations
Add a blank line after declarations, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan
---
drivers/tty/sysrq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 959f9e1..0372ed7 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -118,6 +118,7 @@ static const struct sysrq_key_op sysrq_loglevel_op = {
static void sysrq_handle_SAK(int key)
{
struct work_struct *SAK_work = _cons[fg_console].SAK_work;
+
schedule_work(SAK_work);
}
static const struct sysrq_key_op sysrq_SAK_op = {
--
2.8.1
[PATCH 05/10] tty: tty_jobctrl: Remove spaces before tabs
Remove spaces before tabs following the advice of checkpatch.pl. Signed-off-by: Xiaofei Tan --- drivers/tty/tty_jobctrl.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/tty/tty_jobctrl.c b/drivers/tty/tty_jobctrl.c index 4d78422..2f7d4ba 100644 --- a/drivers/tty/tty_jobctrl.c +++ b/drivers/tty/tty_jobctrl.c @@ -244,10 +244,10 @@ int tty_signal_session_leader(struct tty_struct *tty, int exit_session) * it wants to disassociate itself from its controlling tty. * * It performs the following functions: - * (1) Sends a SIGHUP and SIGCONT to the foreground process group - * (2) Clears the tty from being controlling the session - * (3) Clears the controlling tty for all processes in the - * session group. + * (1) Sends a SIGHUP and SIGCONT to the foreground process group + * (2) Clears the tty from being controlling the session + * (3) Clears the controlling tty for all processes in the + * session group. * * The argument on_exit is set to 1 if called when a process is * exiting; it is 0 if called by the ioctl TIOCNOTTY. -- 2.8.1
[PATCH 04/10] tty: tty_jobctrl: Fix coding style issues of block comments
Fix coding style issues of block comments, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan
---
drivers/tty/tty_jobctrl.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/tty_jobctrl.c b/drivers/tty/tty_jobctrl.c
index 86070f7..4d78422 100644
--- a/drivers/tty/tty_jobctrl.c
+++ b/drivers/tty/tty_jobctrl.c
@@ -204,8 +204,10 @@ int tty_signal_session_leader(struct tty_struct *tty, int
exit_session)
spin_lock_irq(>sighand->siglock);
if (p->signal->tty == tty) {
p->signal->tty = NULL;
- /* We defer the dereferences outside fo
- the tasklist lock */
+ /*
+* We defer the dereferences outside fo
+* the tasklist lock
+*/
refs++;
}
if (!p->signal->leader) {
@@ -328,9 +330,11 @@ void disassociate_ctty(int on_exit)
*/
void no_tty(void)
{
- /* FIXME: Review locking here. The tty_lock never covered any race
- between a new association and proc_clear_tty but possible we need
- to protect against this anyway */
+ /*
+* FIXME: Review locking here. The tty_lock never covered any race
+* between a new association and proc_clear_tty but possible we need
+* to protect against this anyway
+*/
struct task_struct *tsk = current;
disassociate_ctty(0);
@@ -536,7 +540,7 @@ static int tiocgsid(struct tty_struct *tty, struct
tty_struct *real_tty, pid_t _
/*
* (tty == real_tty) is a cheap way of
* testing if the tty is NOT a master pty.
- */
+*/
if (tty == real_tty && current->signal->tty != real_tty)
return -ENOTTY;
--
2.8.1
[PATCH 07/10] tty: tty_ldisc: Add a blank line after declarations
Add a blank line after declarations, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan
---
drivers/tty/tty_ldisc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 2992319..df0b589 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -771,6 +771,7 @@ void tty_ldisc_hangup(struct tty_struct *tty, bool reinit)
int tty_ldisc_setup(struct tty_struct *tty, struct tty_struct *o_tty)
{
int retval = tty_ldisc_open(tty, tty->ldisc);
+
if (retval)
return retval;
@@ -829,6 +830,7 @@ EXPORT_SYMBOL_GPL(tty_ldisc_release);
int tty_ldisc_init(struct tty_struct *tty)
{
struct tty_ldisc *ld = tty_ldisc_get(tty, N_TTY);
+
if (IS_ERR(ld))
return PTR_ERR(ld);
tty->ldisc = ld;
--
2.8.1
[PATCH 02/10] tty/sysrq: Fix issues of code indent should use tabs
Fix issues of code indent should use tabs, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan
---
drivers/tty/sysrq.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 0372ed7..1ece100 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -548,22 +548,22 @@ static int sysrq_key_table_key2index(int key)
*/
static const struct sysrq_key_op *__sysrq_get_key_op(int key)
{
-const struct sysrq_key_op *op_p = NULL;
-int i;
+ const struct sysrq_key_op *op_p = NULL;
+ int i;
i = sysrq_key_table_key2index(key);
if (i != -1)
- op_p = sysrq_key_table[i];
+ op_p = sysrq_key_table[i];
-return op_p;
+ return op_p;
}
static void __sysrq_put_key_op(int key, const struct sysrq_key_op *op_p)
{
-int i = sysrq_key_table_key2index(key);
+ int i = sysrq_key_table_key2index(key);
-if (i != -1)
-sysrq_key_table[i] = op_p;
+ if (i != -1)
+ sysrq_key_table[i] = op_p;
}
void __handle_sysrq(int key, bool check_mask)
@@ -587,8 +587,8 @@ void __handle_sysrq(int key, bool check_mask)
orig_log_level = console_loglevel;
console_loglevel = CONSOLE_LOGLEVEL_DEFAULT;
-op_p = __sysrq_get_key_op(key);
-if (op_p) {
+ op_p = __sysrq_get_key_op(key);
+ if (op_p) {
/*
* Should we check for enabled operations (/proc/sysrq-trigger
* should not) and is the invoked operation enabled?
@@ -637,13 +637,13 @@ static int sysrq_reset_downtime_ms;
/* Simple translation table for the SysRq keys */
static const unsigned char sysrq_xlate[KEY_CNT] =
-"\000\0331234567890-=\177\t"/* 0x00 - 0x0f */
-"qwertyuiop[]\r\000as" /* 0x10 - 0x1f */
-"dfghjkl;'`\000\\zxcv" /* 0x20 - 0x2f */
-"bnm,./\000*\000 \000\201\202\203\204\205" /* 0x30 - 0x3f */
-"\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */
-"230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /*
0x50 - 0x5f */
-"\r\000/"; /* 0x60 - 0x6f */
+ "\000\0331234567890-=\177\t"/* 0x00 - 0x0f */
+ "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */
+ "dfghjkl;'`\000\\zxcv" /* 0x20 - 0x2f */
+ "bnm,./\000*\000 \000\201\202\203\204\205" /* 0x30 - 0x3f */
+ "\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */
+ "230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /*
0x50 - 0x5f */
+ "\r\000/"; /* 0x60 - 0x6f */
struct sysrq_state {
struct input_handle handle;
@@ -1108,7 +1108,7 @@ int sysrq_toggle_support(int enable_mask)
EXPORT_SYMBOL_GPL(sysrq_toggle_support);
static int __sysrq_swap_key_ops(int key, const struct sysrq_key_op
*insert_op_p,
-const struct sysrq_key_op *remove_op_p)
+ const struct sysrq_key_op *remove_op_p)
{
int retval;
--
2.8.1
[PATCH 00/10] tty: Fix some coding style issues
Fix some issues reported by checkpatch.pl. All of them are coding style issues, no function changes. Xiaofei Tan (10): tty/sysrq: Add a blank line after declarations tty/sysrq: Fix issues of code indent should use tabs tty: tty_jobctrl: Add a blank line after declarations tty: tty_jobctrl: Fix coding style issues of block comments tty: tty_jobctrl: Remove spaces before tabs tty: tty_ldisc: Fix an issue of code indent should use tabs tty: tty_ldisc: Add a blank line after declarations tty: tty_ldisc: Fix coding style issues of block comments tty: tty_ldisc: Do not use assignment in if condition tty: tty_ldisc: Remove the repeated word 'the' drivers/tty/sysrq.c | 35 ++- drivers/tty/tty_jobctrl.c | 29 +++-- drivers/tty/tty_ldisc.c | 41 ++--- 3 files changed, 63 insertions(+), 42 deletions(-) -- 2.8.1
[PATCH 03/10] tty: tty_jobctrl: Add a blank line after declarations
Add a blank line after declarations, reported by checkpatch.pl.
Signed-off-by: Xiaofei Tan
---
drivers/tty/tty_jobctrl.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/tty/tty_jobctrl.c b/drivers/tty/tty_jobctrl.c
index 4b751b9..86070f7 100644
--- a/drivers/tty/tty_jobctrl.c
+++ b/drivers/tty/tty_jobctrl.c
@@ -75,6 +75,7 @@ void proc_clear_tty(struct task_struct *p)
{
unsigned long flags;
struct tty_struct *tty;
+
spin_lock_irqsave(>sighand->siglock, flags);
tty = p->signal->tty;
p->signal->tty = NULL;
@@ -173,6 +174,7 @@ EXPORT_SYMBOL_GPL(get_current_tty);
void session_clear_tty(struct pid *session)
{
struct task_struct *p;
+
do_each_pid_task(session, PIDTYPE_SID, p) {
proc_clear_tty(p);
} while_each_pid_task(session, PIDTYPE_SID, p);
@@ -269,6 +271,7 @@ void disassociate_ctty(int on_exit)
tty_vhangup_session(tty);
} else {
struct pid *tty_pgrp = tty_get_pgrp(tty);
+
if (tty_pgrp) {
kill_pgrp(tty_pgrp, SIGHUP, on_exit);
if (!on_exit)
@@ -280,6 +283,7 @@ void disassociate_ctty(int on_exit)
} else if (on_exit) {
struct pid *old_pgrp;
+
spin_lock_irq(>sighand->siglock);
old_pgrp = current->signal->tty_old_pgrp;
current->signal->tty_old_pgrp = NULL;
@@ -328,6 +332,7 @@ void no_tty(void)
between a new association and proc_clear_tty but possible we need
to protect against this anyway */
struct task_struct *tsk = current;
+
disassociate_ctty(0);
proc_clear_tty(tsk);
}
--
2.8.1
[PATCH 1/1] of: properly check for error returned by fdt_get_name()
From: Frank Rowand
fdt_get_name() returns error values via a parameter pointer
instead of in function return. Fix check for this error value
in populate_node() and callers of populate_node().
Chasing up the caller tree showed callers of various functions
failing to initialize the value of pointer parameters that
can return error values. Initialize those values to NULL.
The bug was introduced by
commit e6a6928c3ea1 ("of/fdt: Convert FDT functions to use libfdt")
but this patch can not be backported directly to that commit
because the relevant code has further been restructured by
commit dfbd4c6eff35 ("drivers/of: Split unflatten_dt_node()")
The bug became visible by triggering a crash on openrisc with:
commit 79edff12060f ("scripts/dtc: Update to upstream version
v1.6.0-51-g183df9e9c2b9")
as reported in:
https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/
Fixes: commit 79edff12060f ("scripts/dtc: Update to upstream version
v1.6.0-51-g183df9e9c2b9")
Reported-by: Guenter Roeck
Signed-off-by: Frank Rowand
---
This patch papers over the unaligned pointer passed to
of_fdt_unflatten_tree() bug that Guenter reported in
https://lore.kernel.org/lkml/20210327224116.69309-1-li...@roeck-us.net/
I will create a separate patch to fix that problem.
drivers/of/fdt.c | 36 +++-
drivers/of/overlay.c | 2 +-
drivers/of/unittest.c | 15 ++-
3 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index dcc1dd96911a..adb26aff481d 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -205,7 +205,7 @@ static void populate_properties(const void *blob,
*pprev = NULL;
}
-static bool populate_node(const void *blob,
+static int populate_node(const void *blob,
int offset,
void **mem,
struct device_node *dad,
@@ -214,24 +214,24 @@ static bool populate_node(const void *blob,
{
struct device_node *np;
const char *pathp;
- unsigned int l, allocl;
+ int len;
- pathp = fdt_get_name(blob, offset, );
+ pathp = fdt_get_name(blob, offset, );
if (!pathp) {
*pnp = NULL;
- return false;
+ return len;
}
- allocl = ++l;
+ len++;
- np = unflatten_dt_alloc(mem, sizeof(struct device_node) + allocl,
+ np = unflatten_dt_alloc(mem, sizeof(struct device_node) + len,
__alignof__(struct device_node));
if (!dryrun) {
char *fn;
of_node_init(np);
np->full_name = fn = ((char *)np) + sizeof(*np);
- memcpy(fn, pathp, l);
+ memcpy(fn, pathp, len);
if (dad != NULL) {
np->parent = dad;
@@ -295,6 +295,7 @@ static int unflatten_dt_nodes(const void *blob,
struct device_node *nps[FDT_MAX_DEPTH];
void *base = mem;
bool dryrun = !base;
+ int ret;
if (nodepp)
*nodepp = NULL;
@@ -322,9 +323,10 @@ static int unflatten_dt_nodes(const void *blob,
!of_fdt_device_is_available(blob, offset))
continue;
- if (!populate_node(blob, offset, , nps[depth],
- [depth+1], dryrun))
- return mem - base;
+ ret = populate_node(blob, offset, , nps[depth],
+ [depth+1], dryrun);
+ if (ret < 0)
+ return ret;
if (!dryrun && nodepp && !*nodepp)
*nodepp = nps[depth+1];
@@ -372,6 +374,10 @@ void *__unflatten_device_tree(const void *blob,
{
int size;
void *mem;
+ int ret;
+
+ if (mynodes)
+ *mynodes = NULL;
pr_debug(" -> unflatten_device_tree()\n");
@@ -392,7 +398,7 @@ void *__unflatten_device_tree(const void *blob,
/* First pass, scan for size */
size = unflatten_dt_nodes(blob, NULL, dad, NULL);
- if (size < 0)
+ if (size <= 0)
return NULL;
size = ALIGN(size, 4);
@@ -410,12 +416,16 @@ void *__unflatten_device_tree(const void *blob,
pr_debug(" unflattening %p...\n", mem);
/* Second pass, do actual unflattening */
- unflatten_dt_nodes(blob, mem, dad, mynodes);
+ ret = unflatten_dt_nodes(blob, mem, dad, mynodes);
+
if (be32_to_cpup(mem + size) != 0xdeadbeef)
pr_warn("End of tree marker overwritten: %08x\n",
be32_to_cpup(mem + size));
- if (detached && mynodes) {
+ if (ret <= 0)
+ return NULL;
+
+ if (detached && mynodes && *mynodes) {
of_node_set_flag(*mynodes, OF_DETACHED);
pr_debug("unflattened tree is detached\n");
}
diff --git
[PATCH] of: property: do not create device links from *nr-gpios
[,]nr-gpios property is used by some GPIO drivers[0] to indicate
the number of GPIOs present on a system, not define a GPIO. nr-gpios is
not configured by #gpio-cells and can't be parsed along with other
"*-gpios" properties.
scripts/dtc/checks.c also has a special case for nr-gpio{s}. However,
nr-gpio is not really special, so we only need to fix nr-gpios suffix
here.
[0]: nr-gpios is referenced in Documentation/devicetree/bindings/gpio:
- gpio-adnp.txt
- gpio-xgene-sb.txt
- gpio-xlp.txt
- snps,dw-apb-gpio.yaml
Fixes errors such as:
OF: /palmbus@30/gpio@600: could not find phandle
Call Trace:
of_phandle_iterator_next+0x8c/0x16c
__of_parse_phandle_with_args+0x38/0xb8
of_parse_phandle_with_args+0x28/0x3c
parse_suffix_prop_cells+0x80/0xac
parse_gpios+0x20/0x2c
of_link_to_suppliers+0x18c/0x288
of_link_to_suppliers+0x1fc/0x288
device_add+0x4e0/0x734
of_platform_device_create_pdata+0xb8/0xfc
of_platform_bus_create+0x170/0x214
of_platform_populate+0x88/0xf4
__dt_register_buses+0xbc/0xf0
plat_of_setup+0x1c/0x34
Fixes: 7f00be96f125 ("of: property: Add device link support for
interrupt-parent, dmas and -gpio(s)")
Signed-off-by: Ilya Lipnitskiy
Cc: Saravana Kannan
Cc: # 5.5.x
---
drivers/of/property.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 2bb3158c9e43..24672c295603 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1271,7 +1271,16 @@ DEFINE_SIMPLE_PROP(pinctrl8, "pinctrl-8", NULL)
DEFINE_SIMPLE_PROP(remote_endpoint, "remote-endpoint", NULL)
DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells")
-DEFINE_SUFFIX_PROP(gpios, "-gpios", "#gpio-cells")
+
+static struct device_node *parse_gpios(struct device_node *np,
+ const char *prop_name, int index)
+{
+ if (!strcmp_suffix(prop_name, "nr-gpios"))
+ return NULL;
+
+ return parse_suffix_prop_cells(np, prop_name, index, "-gpios",
+ "#gpio-cells");
+}
static struct device_node *parse_iommu_maps(struct device_node *np,
const char *prop_name, int index)
--
2.31.1
Re: [ovs-dev] [PATCH net] openvswitch: fix send of uninitialized stack memory in ct limit reply
On Mon, Apr 5, 2021 at 2:01 AM Ilya Maximets wrote:
>
> CC: ovs-dev
>
> On 4/4/21 7:50 PM, Ilya Maximets wrote:
> > 'struct ovs_zone_limit' has more members than initialized in
> > ovs_ct_limit_get_default_limit(). The rest of the memory is a random
> > kernel stack content that ends up being sent to userspace.
> >
> > Fix that by using designated initializer that will clear all
> > non-specified fields.
> >
> > Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
> > Signed-off-by: Ilya Maximets
> > ---
> > net/openvswitch/conntrack.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> > index c29b0ef1fc27..cadb6a29b285 100644
> > --- a/net/openvswitch/conntrack.c
> > +++ b/net/openvswitch/conntrack.c
> > @@ -2032,10 +2032,10 @@ static int ovs_ct_limit_del_zone_limit(struct
> > nlattr *nla_zone_limit,
> > static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
> > struct sk_buff *reply)
> > {
> > - struct ovs_zone_limit zone_limit;
> > -
> > - zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE;
> > - zone_limit.limit = info->default_limit;
> > + struct ovs_zone_limit zone_limit = {
> > + .zone_id = OVS_ZONE_LIMIT_DEFAULT_ZONE,
> > + .limit = info->default_limit,
> > + };
I review the code, userspace don't use the count of ovs_zone_lime
struct, but this patch looks to to me.
Thanks Ilya.
Acked-by: Tonghao Zhang
> > return nla_put_nohdr(reply, sizeof(zone_limit), _limit);
> > }
> >
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
--
Best regards, Tonghao
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04, 2021 at 02:40:30PM -0700, Paul E. McKenney wrote:
> On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote:
> > On Sun, Apr 04 2021 at 12:05, syzbot wrote:
> >
> > Cc + ...
>
> And a couple more...
>
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized()
> > > co..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1125f831d0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > commit:
> > > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com
> > >
> > > =
> > > WARNING: suspicious RCU usage
> > > 5.12.0-rc5-syzkaller #0 Not tainted
> > > -
> > > kernel/sched/core.c:8294 Illegal context switch in RCU-sched read-side
> > > critical section!
> > >
> > > other info that might help us debug this:
> > >
> > >
> > > rcu_scheduler_active = 2, debug_locks = 0
> > > 3 locks held by syz-executor.4/8418:
> > > #0:
> > > 8880751d2b28
> > > (
> > > >pi_lock
> > > ){-.-.}-{2:2}
> > > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345
> > > #1:
> > > 8880b9d35258
> > > (
> > > >lock
> > > ){-.-.}-{2:2}
> > > , at: rq_lock kernel/sched/sched.h:1321 [inline]
> > > , at: ttwu_queue kernel/sched/core.c:3184 [inline]
> > > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464
> > > #2: 8880b9d1f948 (_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0},
> > > at: psi_task_change+0x142/0x220 kernel/sched/psi.c:807
>
> This looks similar to syzbot+dde0cc33951735441...@syzkaller.appspotmail.com
> in that rcu_sleep_check() sees an RCU lock held, but the later call to
> lockdep_print_held_locks() does not. Did something change recently that
> could let the ->lockdep_depth counter get out of sync with the actual
> number of locks held?
Dmitri had a different theory here:
https://groups.google.com/g/syzkaller-bugs/c/FmYvfZCZzqA/m/nc2CXUgsAgAJ
Re: [syzbot] WARNING: suspicious RCU usage in dput
#syz dup: WARNING: suspicious RCU usage in getname_flags On Fri, Apr 02, 2021 at 07:52:17PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:1e43c377 Merge tag 'xtensa-20210329' of git://github.com/j.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=16d76301d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 > dashboard link: https://syzkaller.appspot.com/bug?extid=bdef67a6b28a89e6fe71 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+bdef67a6b28a89e6f...@syzkaller.appspotmail.com > > = > WARNING: suspicious RCU usage > 5.12.0-rc5-syzkaller #0 Not tainted > - > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical > section! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 0 > no locks held by systemd-udevd/4825. > > stack backtrace: > CPU: 1 PID: 4825 Comm: systemd-udevd Not tainted 5.12.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294 > dput+0x4d/0xbc0 fs/dcache.c:870 > step_into+0x2cf/0x1c80 fs/namei.c:1778 > walk_component+0x171/0x6a0 fs/namei.c:1945 > link_path_walk.part.0+0x712/0xc90 fs/namei.c:2266 > link_path_walk fs/namei.c:2190 [inline] > path_lookupat+0xb7/0x830 fs/namei.c:2419 > filename_lookup+0x19f/0x560 fs/namei.c:2453 > do_readlinkat+0xcd/0x2f0 fs/stat.c:417 > __do_sys_readlinkat fs/stat.c:444 [inline] > __se_sys_readlinkat fs/stat.c:441 [inline] > __x64_sys_readlinkat+0x93/0xf0 fs/stat.c:441 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7fb5a7e200ba > Code: 48 8b 0d e1 bd 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 > 00 00 00 0f 1f 44 00 00 49 89 ca b8 0b 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 > 01 c3 48 8b 0d ae bd 2b 00 f7 d8 64 89 01 48 > RSP: 002b:7ffc9c440e38 EFLAGS: 0202 ORIG_RAX: 010b > RAX: ffda RBX: 5604089e4380 RCX: 7fb5a7e200ba > RDX: 5604089e4380 RSI: 7ffc9c440ec0 RDI: ff9c > RBP: 0064 R08: 7fb5a80dcbc8 R09: 0070 > R10: 0063 R11: 0202 R12: 7ffc9c440ec0 > R13: ff9c R14: 7ffc9c440e90 R15: 0063 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [syzbot] WARNING: suspicious RCU usage in remove_vma (2)
#syz dup: WARNING: suspicious RCU usage in getname_flags On Sat, Apr 03, 2021 at 04:23:20AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:1e43c377 Merge tag 'xtensa-20210329' of git://github.com/j.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1052e1d6d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=d1a3d65a48dbd1bc > dashboard link: https://syzkaller.appspot.com/bug?extid=26ad5e106ca477175819 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+26ad5e106ca477175...@syzkaller.appspotmail.com > > = > WARNING: suspicious RCU usage > 5.12.0-rc5-syzkaller #0 Not tainted > - > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical > section! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 0 > no locks held by syz-executor.0/29105. > > stack backtrace: > CPU: 0 PID: 29105 Comm: syz-executor.0 Not tainted 5.12.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x141/0x1d7 lib/dump_stack.c:120 > ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294 > remove_vma+0x44/0x170 mm/mmap.c:178 > exit_mmap+0x33f/0x590 mm/mmap.c:3229 > __mmput+0x122/0x470 kernel/fork.c:1090 > mmput+0x58/0x60 kernel/fork.c: > exit_mm kernel/exit.c:501 [inline] > do_exit+0xb0a/0x2a60 kernel/exit.c:812 > do_group_exit+0x125/0x310 kernel/exit.c:922 > get_signal+0x47f/0x2150 kernel/signal.c:2781 > arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:789 > 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+0x148/0x250 kernel/entry/common.c:208 > __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] > syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:301 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x466459 > Code: Unable to access opcode bytes at RIP 0x46642f. > RSP: 002b:7fdfaa117218 EFLAGS: 0246 > ORIG_RAX: 00ca > RAX: RBX: 0056bf68 RCX: 00466459 > RDX: RSI: 0080 RDI: 0056bf68 > RBP: 0056bf60 R08: R09: > R10: R11: 0246 R12: 0056bf6c > R13: 7fff64c569cf R14: 7fdfaa117300 R15: 00022000 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. >
Re: [syzbot] WARNING: suspicious RCU usage in clear_huge_page
#syz dup: WARNING: suspicious RCU usage in getname_flags
On Sat, Apr 03, 2021 at 07:35:16PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:d19cc4bf Merge tag 'trace-v5.12-rc5' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1611e681d0
> kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> dashboard link: https://syzkaller.appspot.com/bug?extid=7a0c25f9520c969c15f5
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+7a0c25f9520c969c1...@syzkaller.appspotmail.com
>
> =
> WARNING: suspicious RCU usage
> 5.12.0-rc5-syzkaller #0 Not tainted
> -
> kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical
> section!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 0
> 1 lock held by syz-executor.2/10002:
> #0: 8880129669d8 (>mmap_lock#2){}-{3:3}, at: mmap_read_trylock
> include/linux/mmap_lock.h:136 [inline]
> #0: 8880129669d8 (>mmap_lock#2){}-{3:3}, at:
> do_user_addr_fault+0x285/0x1210 arch/x86/mm/fault.c:1331
>
> stack backtrace:
> CPU: 0 PID: 10002 Comm: syz-executor.2 Not tainted 5.12.0-rc5-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294
> process_huge_page mm/memory.c:5051 [inline]
> clear_huge_page+0x9c/0x560 mm/memory.c:5112
> __do_huge_pmd_anonymous_page mm/huge_memory.c:607 [inline]
> do_huge_pmd_anonymous_page+0x60e/0x2570 mm/huge_memory.c:772
> create_huge_pmd mm/memory.c:4189 [inline]
> __handle_mm_fault+0x2e59/0x4f70 mm/memory.c:4424
> handle_mm_fault+0x1bc/0x7e0 mm/memory.c:4551
> do_user_addr_fault+0x483/0x1210 arch/x86/mm/fault.c:1390
> handle_page_fault arch/x86/mm/fault.c:1475 [inline]
> exc_page_fault+0x9e/0x180 arch/x86/mm/fault.c:1531
> asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:577
> RIP: 0033:0x461b6d
> Code: 48 01 d0 eb 0b 0f 1f 84 00 00 00 00 00 48 89 f8 48 83 fa 20 72 49 48 83
> fa 40 0f 87 9f 00 00 00 c5 fe 6f 06 c5 fe 6f 4c 16 e0 fe 7f 07 c5 fe 7f
> 4c 17 e0 c5 f8 77 c3 48 3b 15 7e 8e 04 01 0f
> RSP: 002b:7fffc28c60c8 EFLAGS: 00010287
> RAX: 2080 RBX: 0003 RCX: 0057
> RDX: 002b RSI: 00570020 RDI: 2080
> RBP: 7fffc28c6188 R08: 0097 R09: 7fffc2907090
> R10: a8e8 R11: R12: 0001
> R13: R14: 0056bf60 R15: 00035790
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
Re: [syzbot] WARNING: suspicious RCU usage in list_lru_destroy
#syz dup: WARNING: suspicious RCU usage in getname_flags On Sun, Apr 04, 2021 at 08:15:13AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() co.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15556cced0 > kernel config: https://syzkaller.appspot.com/x/.config?x=71a75beb62b62a34 > dashboard link: https://syzkaller.appspot.com/bug?extid=d7dd989878658902c6d6 > compiler: Debian clang version 11.0.1-2 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+d7dd989878658902c...@syzkaller.appspotmail.com > > EXT4-fs (loop0): mount failed > = > WARNING: suspicious RCU usage > 5.12.0-rc5-syzkaller #0 Not tainted > - > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical > section! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 0 > no locks held by syz-executor.0/10672. > > stack backtrace: > CPU: 0 PID: 10672 Comm: syz-executor.0 Not tainted 5.12.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x176/0x24e lib/dump_stack.c:120 > ___might_sleep+0x6e/0x530 kernel/sched/core.c:8294 > down_read+0x17/0x50 kernel/locking/rwsem.c:1352 > list_lru_destroy+0x49/0x390 mm/list_lru.c:628 > deactivate_locked_super+0xbf/0xf0 fs/super.c:343 > mount_bdev+0x288/0x3a0 fs/super.c:1369 > legacy_get_tree+0xea/0x180 fs/fs_context.c:592 > vfs_get_tree+0x86/0x270 fs/super.c:1497 > do_new_mount fs/namespace.c:2903 [inline] > path_mount+0x188a/0x29a0 fs/namespace.c:3233 > do_mount fs/namespace.c:3246 [inline] > __do_sys_mount fs/namespace.c:3454 [inline] > __se_sys_mount+0x28c/0x320 fs/namespace.c:3431 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x46797a > Code: 48 c7 c2 bc ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 b8 04 00 00 > 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 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:7f77bde01fa8 EFLAGS: 0206 ORIG_RAX: 00a5 > RAX: ffda RBX: 2200 RCX: 0046797a > RDX: 2300 RSI: 2100 RDI: 7f77bde02000 > RBP: 7f77bde02040 R08: 7f77bde02040 R09: 2300 > R10: R11: 0206 R12: 2300 > R13: 2100 R14: 7f77bde02000 R15: 20c0 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. >
[PATCH] net/mlx5: fix kfree mismatch in indir_table.c
Memory allocated by kvzalloc() should be freed by kvfree().
Fixes: 34ca65352ddf2 ("net/mlx5: E-Switch, Indirect table infrastructur")
Signed-off-by: Xiaoming Ni
---
.../net/ethernet/mellanox/mlx5/core/esw/indir_table.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.c
b/drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.c
index 6f6772bf61a2..3da7becc1069 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.c
@@ -248,7 +248,7 @@ static int mlx5_esw_indir_table_rule_get(struct
mlx5_eswitch *esw,
err_ethertype:
kfree(rule);
out:
- kfree(rule_spec);
+ kvfree(rule_spec);
return err;
}
@@ -328,7 +328,7 @@ static int mlx5_create_indir_recirc_group(struct
mlx5_eswitch *esw,
e->recirc_cnt = 0;
out:
- kfree(in);
+ kvfree(in);
return err;
}
@@ -347,7 +347,7 @@ static int mlx5_create_indir_fwd_group(struct mlx5_eswitch
*esw,
spec = kvzalloc(sizeof(*spec), GFP_KERNEL);
if (!spec) {
- kfree(in);
+ kvfree(in);
return -ENOMEM;
}
@@ -371,8 +371,8 @@ static int mlx5_create_indir_fwd_group(struct mlx5_eswitch
*esw,
}
err_out:
- kfree(spec);
- kfree(in);
+ kvfree(spec);
+ kvfree(in);
return err;
}
--
2.27.0
arch/mips/kvm/vz.c:392:10: warning: variable 'freeze_time' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e49d033bddf5b565044e2abe4241353959bc9120
commit: cf99c505cf7a5b6d3deee91e3571871f20320d31 MIPS: VZ: Only include
loongson_regs.h for CPU_LOONGSON64
date: 8 months ago
config: mips-randconfig-r033-20210405 (attached as .config)
compiler: mips-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=cf99c505cf7a5b6d3deee91e3571871f20320d31
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout cf99c505cf7a5b6d3deee91e3571871f20320d31
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
arch/mips/kvm/vz.c: In function '_kvm_vz_restore_htimer':
>> arch/mips/kvm/vz.c:392:10: warning: variable 'freeze_time' set but not used
>> [-Wunused-but-set-variable]
392 | ktime_t freeze_time;
| ^~~
vim +/freeze_time +392 arch/mips/kvm/vz.c
c992a4f6a9b0a3 James Hogan 2017-03-14 378
c992a4f6a9b0a3 James Hogan 2017-03-14 379 /**
f4474d50c7d483 James Hogan 2017-03-14 380 * _kvm_vz_restore_htimer() -
Restore hard timer state.
f4474d50c7d483 James Hogan 2017-03-14 381 * @vcpu: Virtual CPU.
f4474d50c7d483 James Hogan 2017-03-14 382 * @compare:CP0_Compare
register value, restored by caller.
f4474d50c7d483 James Hogan 2017-03-14 383 * @cause: CP0_Cause register to
restore.
f4474d50c7d483 James Hogan 2017-03-14 384 *
f4474d50c7d483 James Hogan 2017-03-14 385 * Restore hard timer Guest.Count &
Guest.Cause taking care to preserve the
f4474d50c7d483 James Hogan 2017-03-14 386 * value of Guest.CP0_Cause.TI
while restoring Guest.CP0_Cause.
f4474d50c7d483 James Hogan 2017-03-14 387 */
f4474d50c7d483 James Hogan 2017-03-14 388 static void
_kvm_vz_restore_htimer(struct kvm_vcpu *vcpu,
f4474d50c7d483 James Hogan 2017-03-14 389 u32
compare, u32 cause)
f4474d50c7d483 James Hogan 2017-03-14 390 {
f4474d50c7d483 James Hogan 2017-03-14 391 u32 start_count, after_count;
f4474d50c7d483 James Hogan 2017-03-14 @392 ktime_t freeze_time;
f4474d50c7d483 James Hogan 2017-03-14 393 unsigned long flags;
f4474d50c7d483 James Hogan 2017-03-14 394
f4474d50c7d483 James Hogan 2017-03-14 395 /*
f4474d50c7d483 James Hogan 2017-03-14 396 * Freeze the soft-timer and
sync the guest CP0_Count with it. We do
f4474d50c7d483 James Hogan 2017-03-14 397 * this with interrupts
disabled to avoid latency.
f4474d50c7d483 James Hogan 2017-03-14 398 */
f4474d50c7d483 James Hogan 2017-03-14 399 local_irq_save(flags);
f4474d50c7d483 James Hogan 2017-03-14 400 freeze_time =
kvm_mips_freeze_hrtimer(vcpu, _count);
f4474d50c7d483 James Hogan 2017-03-14 401 write_c0_gtoffset(start_count -
read_c0_count());
f4474d50c7d483 James Hogan 2017-03-14 402 local_irq_restore(flags);
f4474d50c7d483 James Hogan 2017-03-14 403
f4474d50c7d483 James Hogan 2017-03-14 404 /* restore guest CP0_Cause, as
TI may already be set */
f4474d50c7d483 James Hogan 2017-03-14 405 back_to_back_c0_hazard();
f4474d50c7d483 James Hogan 2017-03-14 406 write_gc0_cause(cause);
f4474d50c7d483 James Hogan 2017-03-14 407
f4474d50c7d483 James Hogan 2017-03-14 408 /*
f4474d50c7d483 James Hogan 2017-03-14 409 * The above sequence isn't
atomic and would result in lost timer
f4474d50c7d483 James Hogan 2017-03-14 410 * interrupts if we're not
careful. Detect if a timer interrupt is due
f4474d50c7d483 James Hogan 2017-03-14 411 * and assert it.
f4474d50c7d483 James Hogan 2017-03-14 412 */
f4474d50c7d483 James Hogan 2017-03-14 413 back_to_back_c0_hazard();
f4474d50c7d483 James Hogan 2017-03-14 414 after_count = read_gc0_count();
f4474d50c7d483 James Hogan 2017-03-14 415 if (after_count - start_count >
compare - start_count - 1)
f4474d50c7d483 James Hogan 2017-03-14 416 kvm_vz_queue_irq(vcpu,
MIPS_EXC_INT_TIMER);
f4474d50c7d483 James Hogan 2017-03-14 417 }
f4474d50c7d483 James Hogan 2017-03-14 418
:: The code at line 392 was first introduced by commit
:: f4474d50c7d483dd4432d5b0891b0bb9ad0eefc9 KVM: MIPS/VZ: Support hardware
guest timer
:: TO: James Hogan
:: CC: James Hogan
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
drivers/remoteproc/ti_k3_r5_remoteproc.c:377:28: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e49d033bddf5b565044e2abe4241353959bc9120
commit: 34f2653686fecc9bd5a4ee16724768c72953fb57 remoteproc: k3-r5: Initialize
TCM memories for ECC
date: 6 months ago
config: arm64-randconfig-s032-20210405 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-279-g6d5d9b42-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f2653686fecc9bd5a4ee16724768c72953fb57
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 34f2653686fecc9bd5a4ee16724768c72953fb57
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/remoteproc/ti_k3_r5_remoteproc.c:377:28: sparse: sparse: incorrect
>> type in argument 1 (different address spaces) @@ expected void *p @@
>> got void [noderef] __iomem *cpu_addr @@
drivers/remoteproc/ti_k3_r5_remoteproc.c:377:28: sparse: expected void *p
drivers/remoteproc/ti_k3_r5_remoteproc.c:377:28: sparse: got void
[noderef] __iomem *cpu_addr
drivers/remoteproc/ti_k3_r5_remoteproc.c:380:28: sparse: sparse: incorrect
type in argument 1 (different address spaces) @@ expected void *p @@
got void [noderef] __iomem *cpu_addr @@
drivers/remoteproc/ti_k3_r5_remoteproc.c:380:28: sparse: expected void *p
drivers/remoteproc/ti_k3_r5_remoteproc.c:380:28: sparse: got void
[noderef] __iomem *cpu_addr
vim +377 drivers/remoteproc/ti_k3_r5_remoteproc.c
346
347 /*
348 * The R5F cores have controls for both a reset and a halt/run. The code
349 * execution from DDR requires the initial boot-strapping code to be run
350 * from the internal TCMs. This function is used to release the resets
on
351 * applicable cores to allow loading into the TCMs. The .prepare() ops
is
352 * invoked by remoteproc core before any firmware loading, and is
followed
353 * by the .start() ops after loading to actually let the R5 cores run.
354 */
355 static int k3_r5_rproc_prepare(struct rproc *rproc)
356 {
357 struct k3_r5_rproc *kproc = rproc->priv;
358 struct k3_r5_cluster *cluster = kproc->cluster;
359 struct k3_r5_core *core = kproc->core;
360 struct device *dev = kproc->dev;
361 int ret;
362
363 ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP) ?
364 k3_r5_lockstep_release(cluster) :
k3_r5_split_release(core);
365 if (ret) {
366 dev_err(dev, "unable to enable cores for TCM loading,
ret = %d\n",
367 ret);
368 return ret;
369 }
370
371 /*
372 * Zero out both TCMs unconditionally (access from v8 Arm core
is not
373 * affected by ATCM & BTCM enable configuration values) so that
ECC
374 * can be effective on all TCM addresses.
375 */
376 dev_dbg(dev, "zeroing out ATCM memory\n");
> 377 memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size);
378
379 dev_dbg(dev, "zeroing out BTCM memory\n");
380 memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size);
381
382 return 0;
383 }
384
---
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 next 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support
> > Any specific reason you are not using the misc_device api? That would clean > up this driver a lot, there's no need to create a whole class just for a > single > driver. > Hi Greg No specific reason. I just didn't know the existence of misc_register API. Do you recommend using this API to create the device? If yes, can you tell me how to obtain a appropriate MINOR number from miscdevice.h? Thanks Min
Re: [PATCH v3] sched/debug: Use sched_debug_lock to serialize use of cgroup_path[] only
On 4/4/21 9:27 PM, Waiman Long wrote: On 4/4/21 12:02 PM, Steven Rostedt wrote: On Fri, 2 Apr 2021 23:09:09 -0400 Waiman Long wrote: The main problem with sched_debug_lock is that under certain circumstances, a lock waiter may wait a long time to acquire the lock (in seconds). We can't insert touch_nmi_watchdog() while the cpu is waiting for the spinlock. The problem I have with the patch is that it seems to be a hack (as it doesn't fix the issue in all cases). Since sched_debug_lock is "special", perhaps we can add wrappers to take it, and instead of doing the spin_lock_irqsave(), do a trylock loop. Add lockdep annotation to tell lockdep that this is not a try lock (so that it can still detect deadlocks). Then have the strategically placed touch_nmi_watchdog() also increment a counter. Then in that trylock loop, if it sees the counter get incremented, it knows that forward progress is being made by the lock holder, and it too can call touch_nmi_watchdog(). Thanks for the suggestion, but it also sound complicated. I think we can fix this lockup problem if we are willing to lose some information in case of contention. As you have suggested, a trylock will be used to acquire sched_debug_lock. If succeeded, all is good. Otherwise, a shorter stack buffer will be used for cgroup path. The path may be truncated in this case. If we detect that the full length of the buffer is used, we assume truncation and add, e.g. "...", to indicate there is more to the actual path. Do you think this is an acceptable comprise? Actually, I don't really need to disable interrupt under this situation as deadlock can't happen. Cheers, Longman
[PATCH 1/1] SUNRPC: Handle major timeout in xprt_adjust_timeout()
Currently if a major timeout value is reached, but the minor value has
not been reached, an ETIMEOUT will not be sent back to the caller.
This can occur if the v4 server is not responding to requests and
retrans is configured larger than the default of two.
For example, A TCP mount with a configured timeout value of 50 and a
retransmission count of 3 to a v4 server which is not responding:
1. Initial value and increment set to 5s, maxval set to 20s, retries at 3
2. Major timeout is set to 20s, minor timeout set to 5s initially
3. xport_adjust_timeout() is called after 5s, retry with 10s timeout,
minor timeout is bumped to 10s
4. And again after another 10s, 15s total time with minor timeout set
to 15s
5. After 20s total time xport_adjust_timeout is called as major timeout is
reached, but skipped because the minor timeout is not reached
- After this time the cpu spins continually calling
xport_adjust_timeout() and returning 0 for 10 seconds.
As seen on perf sched:
39243.913182 [0005] mount.nfs[3794] 4607.938 0.017 9746.863
6. This continues until the 15s minor timeout condition is reached (in
this case for 10 seconds). After which the ETIMEOUT is processed
back to the caller, the cpu spinning stops, and normal operations
continue
Fixes: 7de62bc09fe6 ("SUNRPC dont update timeout value on connection reset")
Signed-off-by: Chris Dion
---
Hello,
We recently have noticed an issue where we see a cpu spinning for a few
seconds at a time bouncing between xprt_adjust_timeout() and call_connect().
This is ocurring with an v4 client mounting a non-responsive server with a
low timeout and retransmissions set. In this case if the major timeout is
not serviced there appears to be a spin/bouncing between these functions
until such timeout is returned. It made sense to service the major timeout
in this scenario. I am not clear on the implications on the original
implementation here but I will submit for your review.
Regards,
Chris
net/sunrpc/xprt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index 691ccf8049a4..7fe975c1000a 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -698,9 +698,9 @@ int xprt_adjust_timeout(struct rpc_rqst *req)
const struct rpc_timeout *to = req->rq_task->tk_client->cl_timeout;
int status = 0;
- if (time_before(jiffies, req->rq_minortimeo))
- return status;
if (time_before(jiffies, req->rq_majortimeo)) {
+ if (time_before(jiffies, req->rq_minortimeo))
+ return status;
if (to->to_exponential)
req->rq_timeout <<= 1;
else
--
2.18.2
Re: [PATCH v3] sched/debug: Use sched_debug_lock to serialize use of cgroup_path[] only
On 4/4/21 12:02 PM, Steven Rostedt wrote: On Fri, 2 Apr 2021 23:09:09 -0400 Waiman Long wrote: The main problem with sched_debug_lock is that under certain circumstances, a lock waiter may wait a long time to acquire the lock (in seconds). We can't insert touch_nmi_watchdog() while the cpu is waiting for the spinlock. The problem I have with the patch is that it seems to be a hack (as it doesn't fix the issue in all cases). Since sched_debug_lock is "special", perhaps we can add wrappers to take it, and instead of doing the spin_lock_irqsave(), do a trylock loop. Add lockdep annotation to tell lockdep that this is not a try lock (so that it can still detect deadlocks). Then have the strategically placed touch_nmi_watchdog() also increment a counter. Then in that trylock loop, if it sees the counter get incremented, it knows that forward progress is being made by the lock holder, and it too can call touch_nmi_watchdog(). Thanks for the suggestion, but it also sound complicated. I think we can fix this lockup problem if we are willing to lose some information in case of contention. As you have suggested, a trylock will be used to acquire sched_debug_lock. If succeeded, all is good. Otherwise, a shorter stack buffer will be used for cgroup path. The path may be truncated in this case. If we detect that the full length of the buffer is used, we assume truncation and add, e.g. "...", to indicate there is more to the actual path. Do you think this is an acceptable comprise? Cheers, Longman
Re: [Outreachy kernel] [PATCH] staging: qlge: remove else after break
On Mon, Apr 05, 2021 at 06:11:43AM +0530, Mitali Borkar wrote:
> - } else {
> - netif_err(qdev, drv, qdev->ndev,
> + } netif_err(qdev, drv, qdev->ndev,
That's not the normal indentation style ... does checkpatch really not
complain about that?
> "IDC: Invalid State 0x%.04x.\n",
> mbcp->mbox_out[0]);
> status = -EIO;
> break;
> - }
> }
>
> return status;
> --
> 2.30.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/YGpcx9MZuZJFy0Z/%40kali.
Re: [PATCH v3 11/12] drm/bridge: ti-sn65dsi86: Print an error if we fallback to panel modes
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:45PM -0700, Douglas Anderson wrote: > Now that we can properly read the EDID for modes there should be no > reason to fallback to the fixed modes that our downstream panel driver > provides us. Let's make that clear by: > - Putting an error message in the logs if we fall back. > - Putting a comment in saying what's going on. > > Signed-off-by: Douglas Anderson Reviewed-by: Laurent Pinchart > --- > > (no changes since v1) > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index fb50f9f95b0f..3b61898cf9cb 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -303,6 +303,13 @@ static int ti_sn_bridge_connector_get_modes(struct > drm_connector *connector) > return num; > } > > + /* > + * Ideally this should never happen and we could remove the fallback > + * but let's preserve old behavior. > + */ > + DRM_DEV_ERROR(pdata->dev, > + "Failed to read EDID; falling back to panel modes"); > + > exit: > return drm_panel_get_modes(pdata->panel, connector); > } -- Regards, Laurent Pinchart
Re: [PATCH v3 10/12] drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:44PM -0700, Douglas Anderson wrote:
> Though I don't have access to any hardware that uses ti-sn65dsi86 and
> _doesn't_ provide a "refclk", I believe that we'll have trouble
> reading the EDID at bootup in that case. Specifically I believe that
> if there's no "refclk" we need the MIPI source clock to be active
> before we can successfully read the EDID. My evidence here is that, in
> testing, I couldn't read the EDID until I turned on the DPPLL in the
> bridge chip and that the DPPLL needs the input clock to be active.
>
> Since this is hard to support, let's punt trying to read the EDID if
> there's no "refclk".
>
> I don't believe there are any users of the ti-sn65dsi86 bridge chip
> that _don't_ use "refclk". The bridge chip is _very_ inflexible in
> that mode. The only time I've seen that mode used was for some really
> early prototype hardware that was thrown in the e-waste bin years ago
> when we realized how inflexible it was.
>
> Even if someone is using the bridge chip without the "refclk" they're
> in no worse shape than they were before the (fairly recent) commit
> 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC").
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Laurent Pinchart
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index a76cac93cb46..fb50f9f95b0f 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -275,6 +275,18 @@ static int ti_sn_bridge_connector_get_modes(struct
> drm_connector *connector)
> bool was_enabled;
> int num;
>
> + /*
> + * Don't try to read the EDID if no refclk. In theory it is possible
> + * to make this work but it's tricky. I believe that we need to get
> + * our upstream MIPI source to provide a pixel clock before we can
> + * do AUX transations but we need to be able to read the EDID before
> + * we've picked a display mode. The bridge is already super limited
> + * if you try to use it without a refclk so presumably limiting to
> + * the fixed modes our downstream panel reports is fine.
> + */
> + if (!pdata->refclk)
> + goto exit;
> +
> if (!edid) {
> was_enabled = pdata->pre_enabled;
>
> @@ -291,6 +303,7 @@ static int ti_sn_bridge_connector_get_modes(struct
> drm_connector *connector)
> return num;
> }
>
> +exit:
> return drm_panel_get_modes(pdata->panel, connector);
> }
>
--
Regards,
Laurent Pinchart
Re: [PATCH v3 07/12] drm/bridge: ti-sn65dsi86: Remove extra call: drm_connector_update_edid_property()
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:41PM -0700, Douglas Anderson wrote:
> As of commit 5186421cbfe2 ("drm: Introduce epoch counter to
> drm_connector") the drm_get_edid() function calls
> drm_connector_update_edid_property() for us. There's no reason for us
> to call it again.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
This looks like a widespread issue, would you be able to send a patch to
address all the other drivers ?
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 51db30d573c1..6390bc58f29a 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -270,7 +270,7 @@ static int ti_sn_bridge_connector_get_modes(struct
> drm_connector *connector)
> {
> struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> struct edid *edid = pdata->edid;
> - int num, ret;
> + int num;
>
> if (!edid) {
> pm_runtime_get_sync(pdata->dev);
> @@ -279,12 +279,9 @@ static int ti_sn_bridge_connector_get_modes(struct
> drm_connector *connector)
> }
>
> if (edid && drm_edid_is_valid(edid)) {
> - ret = drm_connector_update_edid_property(connector, edid);
> - if (!ret) {
> - num = drm_add_edid_modes(connector, edid);
> - if (num)
> - return num;
> - }
> + num = drm_add_edid_modes(connector, edid);
> + if (num)
> + return num;
> }
>
> return drm_panel_get_modes(pdata->panel, connector);
--
Regards,
Laurent Pinchart
Re: [PATCH v3 06/12] drm/bridge: ti-sn65dsi86: Get rid of the useless detect() function
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:40PM -0700, Douglas Anderson wrote:
> If we just leave the detect() function as NULL then the upper layers
> assume we're always connected. There's no reason for a stub.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index e30460002c48..51db30d573c1 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -306,20 +306,8 @@ static struct drm_connector_helper_funcs
> ti_sn_bridge_connector_helper_funcs = {
> .mode_valid = ti_sn_bridge_connector_mode_valid,
> };
>
> -static enum drm_connector_status
> -ti_sn_bridge_connector_detect(struct drm_connector *connector, bool force)
> -{
> - /**
> - * TODO: Currently if drm_panel is present, then always
> - * return the status as connected. Need to add support to detect
> - * device state for hot pluggable scenarios.
> - */
> - return connector_status_connected;
> -}
> -
> static const struct drm_connector_funcs ti_sn_bridge_connector_funcs = {
> .fill_modes = drm_helper_probe_single_connector_modes,
> - .detect = ti_sn_bridge_connector_detect,
> .destroy = drm_connector_cleanup,
> .reset = drm_atomic_helper_connector_reset,
> .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
--
Regards,
Laurent Pinchart
Re: [PATCH v3 05/12] drm/bridge: ti-sn65dsi86: Move drm_panel_unprepare() to post_disable()
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:39PM -0700, Douglas Anderson wrote:
> We prepared the panel in pre_enable() so we should unprepare it in
> post_disable() to match.
>
> This becomes important once we start using pre_enable() and
> post_disable() to make sure things are powered on (and then off again)
> when reading the EDID.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index c006678c9921..e30460002c48 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -452,8 +452,6 @@ static void ti_sn_bridge_disable(struct drm_bridge
> *bridge)
> regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0);
> /* disable DP PLL */
> regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0);
> -
> - drm_panel_unprepare(pdata->panel);
> }
>
> static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn_bridge *pdata)
> @@ -869,6 +867,8 @@ static void ti_sn_bridge_post_disable(struct drm_bridge
> *bridge)
> {
> struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>
> + drm_panel_unprepare(pdata->panel);
> +
> clk_disable_unprepare(pdata->refclk);
>
> pm_runtime_put_sync(pdata->dev);
--
Regards,
Laurent Pinchart
Re: [PATCH v3 04/12] drm/bridge: ti-sn65dsi86: Reorder remove()
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:38PM -0700, Douglas Anderson wrote:
> Let's make the remove() function strictly the reverse of the probe()
> function so it's easier to reason about.
>
> This patch was created by code inspection and should move us closer to
> a proper remove.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
> ---
>
> Changes in v3:
> - Removed "NOTES" from commit message.
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 76f43af6735d..c006678c9921 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -1315,20 +1315,21 @@ static int ti_sn_bridge_remove(struct i2c_client
> *client)
> if (!pdata)
> return -EINVAL;
>
> - kfree(pdata->edid);
> - ti_sn_debugfs_remove(pdata);
> -
> - of_node_put(pdata->host_node);
> -
> - pm_runtime_disable(pdata->dev);
> -
> if (pdata->dsi) {
> mipi_dsi_detach(pdata->dsi);
> mipi_dsi_device_unregister(pdata->dsi);
> }
>
> + kfree(pdata->edid);
> +
> + ti_sn_debugfs_remove(pdata);
> +
> drm_bridge_remove(>bridge);
>
> + pm_runtime_disable(pdata->dev);
> +
> + of_node_put(pdata->host_node);
> +
> return 0;
> }
>
--
Regards,
Laurent Pinchart
Re: [PATCH v3 03/12] drm/bridge: ti-sn65dsi86: Remove incorrectly tagged kerneldoc comment
Hi Doug, Thank you for the patch. On Fri, Apr 02, 2021 at 03:28:37PM -0700, Douglas Anderson wrote: > A random comment inside a function had "/**" in front of it. That > doesn't make sense. Remove. > > Signed-off-by: Douglas Anderson > Reviewed-by: Andrzej Hajda Reviewed-by: Laurent Pinchart > --- > > (no changes since v1) > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index 96fe8f2c0ea9..76f43af6735d 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -788,7 +788,7 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge) > /* set dsi clk frequency value */ > ti_sn_bridge_set_dsi_rate(pdata); > > - /** > + /* >* The SN65DSI86 only supports ASSR Display Authentication method and >* this method is enabled by default. An eDP panel must support this >* authentication method. We need to enable this method in the eDP panel -- Regards, Laurent Pinchart
Re: [PATCH v3 01/12] drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable()
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:35PM -0700, Douglas Anderson wrote:
> The drm_bridge_chain_pre_enable() is not the proper opposite of
> drm_bridge_chain_post_disable(). It continues along the chain to
> _before_ the starting bridge. Let's fix that.
>
> Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked list")
> Signed-off-by: Douglas Anderson
> Reviewed-by: Andrzej Hajda
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_bridge.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 64f0effb52ac..044acd07c153 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -522,6 +522,9 @@ void drm_bridge_chain_pre_enable(struct drm_bridge
> *bridge)
> list_for_each_entry_reverse(iter, >bridge_chain, chain_node) {
> if (iter->funcs->pre_enable)
> iter->funcs->pre_enable(iter);
> +
> + if (iter == bridge)
> + break;
This looks good as it matches drm_atomic_bridge_chain_disable().
Reviewed-by: Laurent Pinchart
I'm curious though, given that the bridge passed to the function should
be the one closest to the encoder, does this make a difference ?
> }
> }
> EXPORT_SYMBOL(drm_bridge_chain_pre_enable);
--
Regards,
Laurent Pinchart
Re: [PATCH v2] net: mac802154: Fix general protection fault
Hi, On Thu, 4 Mar 2021 at 10:25, Pavel Skripkin wrote: > > syzbot found general protection fault in crypto_destroy_tfm()[1]. > It was caused by wrong clean up loop in llsec_key_alloc(). > If one of the tfm array members is in IS_ERR() range it will > cause general protection fault in clean up function [1]. > > Call Trace: > crypto_free_aead include/crypto/aead.h:191 [inline] [1] > llsec_key_alloc net/mac802154/llsec.c:156 [inline] > mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 > ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 > rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] > nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 > genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 > genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] > genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 > netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 > genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 > netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] > netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 > netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 > sock_sendmsg_nosec net/socket.c:654 [inline] > sock_sendmsg+0xcf/0x120 net/socket.c:674 > sys_sendmsg+0x6e8/0x810 net/socket.c:2350 > ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > > Signed-off-by: Pavel Skripkin > Reported-by: syzbot+9ec037722d2603a9f...@syzkaller.appspotmail.com > Change-Id: I29f7ac641a039096d63d1e6070bb32cb5a3beb07 I am sorry, I don't know the tag "Change-Id", I was doing a whole grep on Documentation/ without any luck. Dumb question: What is the meaning of it? - Alex
[PATCH] staging: qlge: remove else after break
linux-staging@lists,linux-kernel@vger.kernel.org
Bcc:
Subject: [PATCH] staging: qlge:remove else after break
Reply-To:
Fixed Warning:- else is not needed after break
break terminates the loop if encountered. else is unnecessary and
increases indenatation
Signed-off-by: Mitali Borkar
---
drivers/staging/qlge/qlge_mpi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c
index 2630ebf50341..3a49f187203b 100644
--- a/drivers/staging/qlge/qlge_mpi.c
+++ b/drivers/staging/qlge/qlge_mpi.c
@@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev)
netif_err(qdev, drv, qdev->ndev, "IDC Success.\n");
status = 0;
break;
- } else {
- netif_err(qdev, drv, qdev->ndev,
+ } netif_err(qdev, drv, qdev->ndev,
"IDC: Invalid State 0x%.04x.\n",
mbcp->mbox_out[0]);
status = -EIO;
break;
- }
}
return status;
--
2.30.2
Re: [PATCH] net: fix NULL ptr dereference in nl802154_del_llsec_key
Hi, On Sat, 3 Apr 2021 at 11:18, Pavel Skripkin wrote: > > syzbot reported NULL ptr dereference in nl802154_del_llsec_key()[1] > The problem was in case of info->attrs[NL802154_ATTR_SEC_KEY] == NULL. > nla_parse_nested_deprecated()[2] doesn't check this condition before calling > nla_len()[3] > this is already fixed in the same way just not in net yet. - Alex
Re: [PATCH v4 0/3] cgroup: New misc cgroup controller
On Sun, Apr 4, 2021 at 10:35 AM Tejun Heo wrote: > > Applied to cgroup/for-5.13. If there are further issues, let's address them > incrementally. > > Thanks. > > -- > tejun Thanks Tejun for accepting and guiding through each version of this patch series.
Re: [PATCH] doc: Fix mistaken diagram references in RCU
On Sun, Apr 04, 2021 at 11:58:43PM +0200, Frederic Weisbecker wrote: > The 3 diagrams describing rcu_gp_init() all spuriously refer to the same > figure, probably due to some copy/paste issue. Fix the references. > > Signed-off-by: Frederic Weisbecker Good catch, queued, thank you! Thanx, Paul > --- > .../RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst > b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst > index 3f6ce41ee0c5..11cdab037bff 100644 > --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst > +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst > @@ -339,14 +339,14 @@ The diagram below shows the path of ordering if the > leftmost > leftmost ``rcu_node`` structure offlines its last CPU and if the next > ``rcu_node`` structure has no online CPUs). > > -.. kernel-figure:: TreeRCU-gp-init-1.svg > +.. kernel-figure:: TreeRCU-gp-init-2.svg > > The final ``rcu_gp_init()`` pass through the ``rcu_node`` tree traverses > breadth-first, setting each ``rcu_node`` structure's ``->gp_seq`` field > to the newly advanced value from the ``rcu_state`` structure, as shown > in the following diagram. > > -.. kernel-figure:: TreeRCU-gp-init-1.svg > +.. kernel-figure:: TreeRCU-gp-init-3.svg > > This change will also cause each CPU's next call to > ``__note_gp_changes()`` to notice that a new grace period has started, > -- > 2.25.1 >
Re: [PATCH] libbpf: Fix KERNEL_VERSION macro
On Sun, Apr 4, 2021 at 2:53 AM Hengqi Chen wrote: > > Add missing ')' for KERNEL_VERSION macro. > > Signed-off-by: Hengqi Chen > --- The fix looks good, thank you. But your patch didn't make it into bpf/netdev patchworks instance ([0]) most probably due to too long CC list. Can you please re-send with just maintainers and bpf@ and netdev@ mailing lists in to/cc. Also for bpf and bpf-next tree, we ask to specify the tree with [PATCH bpf-next] prefix, so when re-submitting please adjust as well. Thanks. [0] https://patchwork.kernel.org/project/netdevbpf/list/ > tools/lib/bpf/bpf_helpers.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h > index cc2e51c64a54..b904128626c2 100644 > --- a/tools/lib/bpf/bpf_helpers.h > +++ b/tools/lib/bpf/bpf_helpers.h > @@ -51,7 +51,7 @@ > #endif > > #ifndef KERNEL_VERSION > -#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 : > (c)) > +#define KERNEL_VERSION(a, b, c) (((a) << 16) + ((b) << 8) + ((c) > 255 ? 255 > : (c))) > #endif > > /* > -- > 2.25.1 >
Re: [syzbot] WARNING: suspicious RCU usage in __ext4_handle_dirty_metadata
#syz dup: WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04, 2021 at 01:55:17PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() co..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10808831d0
> kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> dashboard link: https://syzkaller.appspot.com/bug?extid=cb293a00f01b422bac7d
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+cb293a00f01b422ba...@syzkaller.appspotmail.com
>
> =
> WARNING: suspicious RCU usage
> 5.12.0-rc5-syzkaller #0 Not tainted
> -
> kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical
> section!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 0
> 7 locks held by syz-executor.2/17885:
> #0:
> 888014000930
> (
> >f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:961
> #1: 88802455a460 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x12d/0x250
> fs/read_write.c:658
> #2: 888080e91888 (>s_type->i_mutex_key#9){+.+.}-{3:3}, at:
> inode_lock include/linux/fs.h:775 [inline]
> #2: 888080e91888 (>s_type->i_mutex_key#9){+.+.}-{3:3}, at:
> ext4_dio_write_iter fs/ext4/file.c:493 [inline]
> #2: 888080e91888 (>s_type->i_mutex_key#9){+.+.}-{3:3}, at:
> ext4_file_write_iter+0xaeb/0x14e0 fs/ext4/file.c:661
> #3: 888080e91678 (>i_data_sem){}-{3:3}, at:
> ext4_map_blocks+0x5e1/0x17d0 fs/ext4/inode.c:631
> #4: 8bf718a0 (rcu_read_lock){}-{1:2}, at:
> ieee80211_rx_napi+0x0/0x3d0 arch/x86/include/asm/bitops.h:207
> #5: 88807b381580 (>rx_path_lock){+.-.}-{2:2}, at: spin_lock_bh
> include/linux/spinlock.h:359 [inline]
> #5: 88807b381580 (>rx_path_lock){+.-.}-{2:2}, at:
> ieee80211_rx_handlers+0xd7/0xae60 net/mac80211/rx.c:3758
> #6: 8880b9d26358 (hrtimer_bases.lock){-.-.}-{2:2}, at: __run_hrtimer
> kernel/time/hrtimer.c:1541 [inline]
> #6: 8880b9d26358 (hrtimer_bases.lock){-.-.}-{2:2}, at:
> __hrtimer_run_queues+0x243/0xe40 kernel/time/hrtimer.c:1601
>
> stack backtrace:
> CPU: 1 PID: 17885 Comm: syz-executor.2 Not tainted 5.12.0-rc5-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294
> __ext4_handle_dirty_metadata+0x37/0x730 fs/ext4/ext4_jbd2.c:326
> ext4_mb_mark_diskspace_used+0x991/0x1160 fs/ext4/mballoc.c:3279
> ext4_mb_new_blocks+0xd46/0x51a0 fs/ext4/mballoc.c:5000
> ext4_new_meta_blocks+0x2fe/0x360 fs/ext4/balloc.c:693
> ext4_alloc_branch fs/ext4/indirect.c:335 [inline]
> ext4_ind_map_blocks+0xb0d/0x2450 fs/ext4/indirect.c:626
> ext4_map_blocks+0x9c9/0x17d0 fs/ext4/inode.c:640
> ext4_iomap_alloc fs/ext4/inode.c:3428 [inline]
> ext4_iomap_begin+0x463/0x7a0 fs/ext4/inode.c:3478
> iomap_apply+0x177/0xb50 fs/iomap/apply.c:46
> __iomap_dio_rw+0x71b/0x1280 fs/iomap/direct-io.c:553
> iomap_dio_rw+0x30/0x90 fs/iomap/direct-io.c:641
> ext4_dio_write_iter fs/ext4/file.c:551 [inline]
> ext4_file_write_iter+0xe18/0x14e0 fs/ext4/file.c:661
> call_write_iter include/linux/fs.h:1977 [inline]
> new_sync_write+0x426/0x650 fs/read_write.c:518
> vfs_write+0x796/0xa30 fs/read_write.c:605
> ksys_write+0x12d/0x250 fs/read_write.c:658
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x466459
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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:7fadff8ad188 EFLAGS: 0246 ORIG_RAX: 0001
> RAX: ffda RBX: 0056bf60 RCX: 00466459
> RDX: 00248800 RSI: 2000 RDI: 0005
> RBP: 004bf9fb R08: R09:
> R10: R11: 0246 R12: 0056bf60
> R13: 7ffc9e5e3caf R14: 7fadff8ad300 R15: 00022000
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[no subject]
outreachy-ker...@googlegroups.com, mitaliborkar...@gmail.com
Bcc:
Subject: [PATCH] staging: qlge:remove else after break
Reply-To:
Fixed Warning:- else is not needed after break
break terminates the loop if encountered. else is unnecessary and
increases indenatation
Signed-off-by: Mitali Borkar
---
drivers/staging/qlge/qlge_mpi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/qlge/qlge_mpi.c b/drivers/staging/qlge/qlge_mpi.c
index 2630ebf50341..3a49f187203b 100644
--- a/drivers/staging/qlge/qlge_mpi.c
+++ b/drivers/staging/qlge/qlge_mpi.c
@@ -935,13 +935,11 @@ static int qlge_idc_wait(struct qlge_adapter *qdev)
netif_err(qdev, drv, qdev->ndev, "IDC Success.\n");
status = 0;
break;
- } else {
- netif_err(qdev, drv, qdev->ndev,
+ } netif_err(qdev, drv, qdev->ndev,
"IDC: Invalid State 0x%.04x.\n",
mbcp->mbox_out[0]);
status = -EIO;
break;
- }
}
return status;
--
2.30.2
Re: [PATCH 0/9] sched: Core scheduling interfaces
cc'ing Michal and Christian who've been spending some time on cgroup interface issues recently and Li Zefan for cpuset. On Thu, Apr 01, 2021 at 03:10:12PM +0200, Peter Zijlstra wrote: > The cgroup interface now uses a 'core_sched' file, which still takes 0,1. It > is > however changed such that you can have nested tags. The for any given task, > the > first parent with a cookie is the effective one. The rationale is that this > way > you can delegate subtrees and still allow them some control over grouping. I find it difficult to like the proposed interface from the name (the term "core" is really confusing given how the word tends to be used internally) to the semantics (it isn't like anything else) and even the functionality (we're gonna have fixed processors at some point, right?). Here are some preliminary thoughts: * Are both prctl and cgroup based interfaces really necessary? I could be being naive but given that we're (hopefully) working around hardware deficiencies which will go away in time, I think there's a strong case for minimizing at least the interface to the bare minimum. Given how cgroups are set up (membership operations happening only for seeding, especially with the new clone interface), it isn't too difficult to synchronize process tree and cgroup hierarchy where it matters - ie. given the right per-process level interface, restricting configuration for a cgroup sub-hierarchy may not need any cgroup involvement at all. This also nicely gets rid of the interaction between prctl and cgroup bits. * If we *have* to have cgroup interface, I wonder whether this would fit a lot better as a part of cpuset. If you squint just right, this can be viewed as some dynamic form of cpuset. Implementation-wise, it probably won't integrate with the rest but I think the feature will be less jarring as a part of cpuset, which already is a bit of kitchensink anyway. > The cgroup thing also '(ab)uses' cgroup_mutex for serialization because it > needs to ensure continuity between ss->can_attach() and ss->attach() for the > memory allocation. If the prctl() were allowed to interleave it might steal > the > memory. > > Using cgroup_mutex feels icky, but is not without precedent, > kernel/bpf/cgroup.c does the same thing afaict. > > TJ, can you please have a look at this? Yeah, using cgroup_mutex for stabilizing cgroup hierarchy for consecutive operations is fine. It might be worthwhile to break that out into a proper interface but that's the least of concerns here. Can someone point me to a realistic and concrete usage scenario for this feature? Thanks. -- tejun
[PATCH] task_work: add helper for more targeted task_work canceling
The only exported helper we have right now is task_work_cancel(), which
cancels any task_work from a given task where func matches the queued
work item. This is a bit too coarse for some use cases. Add a
task_work_cancel_match() that allows to more specifically target
individual work items outside of purely the callback function used.
task_work_cancel() can be trivially implemented on top of that, hence do
so.
Signed-off-by: Jens Axboe
---
I've got a patch on top of this that uses task_work_cancel_match(), but
sending this one out separately. There should be no functional changes
in this patch, it just allows someone to build func == func && data ==
data matches on top.
diff --git a/include/linux/task_work.h b/include/linux/task_work.h
index 0d848a1e9e62..5b8a93f288bb 100644
--- a/include/linux/task_work.h
+++ b/include/linux/task_work.h
@@ -22,6 +22,8 @@ enum task_work_notify_mode {
int task_work_add(struct task_struct *task, struct callback_head *twork,
enum task_work_notify_mode mode);
+struct callback_head *task_work_cancel_match(struct task_struct *task,
+ bool (*match)(struct callback_head *, void *data), void *data);
struct callback_head *task_work_cancel(struct task_struct *, task_work_func_t);
void task_work_run(void);
diff --git a/kernel/task_work.c b/kernel/task_work.c
index 9cde961875c0..e9316198c64b 100644
--- a/kernel/task_work.c
+++ b/kernel/task_work.c
@@ -59,18 +59,17 @@ int task_work_add(struct task_struct *task, struct
callback_head *work,
}
/**
- * task_work_cancel - cancel a pending work added by task_work_add()
+ * task_work_cancel_match - cancel a pending work added by task_work_add()
* @task: the task which should execute the work
- * @func: identifies the work to remove
- *
- * Find the last queued pending work with ->func == @func and remove
- * it from queue.
+ * @match: match function to call
*
* RETURNS:
* The found work or NULL if not found.
*/
struct callback_head *
-task_work_cancel(struct task_struct *task, task_work_func_t func)
+task_work_cancel_match(struct task_struct *task,
+ bool (*match)(struct callback_head *, void *data),
+ void *data)
{
struct callback_head **pprev = >task_works;
struct callback_head *work;
@@ -86,7 +85,7 @@ task_work_cancel(struct task_struct *task, task_work_func_t
func)
*/
raw_spin_lock_irqsave(>pi_lock, flags);
while ((work = READ_ONCE(*pprev))) {
- if (work->func != func)
+ if (!match(work, data))
pprev = >next;
else if (cmpxchg(pprev, work, work->next) == work)
break;
@@ -96,6 +95,28 @@ task_work_cancel(struct task_struct *task, task_work_func_t
func)
return work;
}
+static bool task_work_func_match(struct callback_head *cb, void *data)
+{
+ return cb->func == data;
+}
+
+/**
+ * task_work_cancel - cancel a pending work added by task_work_add()
+ * @task: the task which should execute the work
+ * @func: identifies the work to remove
+ *
+ * Find the last queued pending work with ->func == @func and remove
+ * it from queue.
+ *
+ * RETURNS:
+ * The found work or NULL if not found.
+ */
+struct callback_head *
+task_work_cancel(struct task_struct *task, task_work_func_t func)
+{
+ return task_work_cancel_match(task, task_work_func_match, func);
+}
+
/**
* task_work_run - execute the works added by task_work_add()
*
--
Jens Axboe
[PATCH] kpc2000: kpc2000: Removed extra blank line
Fix checkpatch warning: CHECK: Please don't use multiple blank lines Signed-off-by: David Villasana Jiménez --- drivers/staging/kpc2000/kpc2000/pcie.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/kpc2000/kpc2000/pcie.h b/drivers/staging/kpc2000/kpc2000/pcie.h index cb815c30faa4..f1fc91b4c704 100644 --- a/drivers/staging/kpc2000/kpc2000/pcie.h +++ b/drivers/staging/kpc2000/kpc2000/pcie.h @@ -6,7 +6,6 @@ #include "../kpc.h" #include "dma_common_defs.h" - /* System Register Map (BAR 1, Start Addr 0) * * BAR Size: -- 2.30.2
Re: [PATCH] net: phy: fix PHY possibly unwork after MDIO bus resume back
On 04.04.2021 16:09, Heiner Kallweit wrote:
> On 04.04.2021 12:07, Joakim Zhang wrote:
>> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut
>> off PHY power") invokes phy_init_hw() when MDIO bus resume, it will
>> soft reset PHY if PHY driver implements soft_reset callback.
>> commit 764d31cacfe4 ("net: phy: micrel: set soft_reset callback to
>> genphy_soft_reset for KSZ8081") adds soft_reset for KSZ8081. After these
>> two patches, I found i.MX6UL 14x14 EVK which connected to KSZ8081RNB doesn't
>> work any more when system resume back, MAC driver is fec_main.c.
>>
>> It's obvious that initializing PHY hardware when MDIO bus resume back
>> would introduce some regression when PHY implements soft_reset. When I
>
> Why is this obvious? Please elaborate on why a soft reset should break
> something.
>
>> am debugging, I found PHY works fine if MAC doesn't support suspend/resume
>> or phy_stop()/phy_start() doesn't been called during suspend/resume. This
>> let me realize, PHY state machine phy_state_machine() could do something
>> breaks the PHY.
>>
>> As we known, MAC resume first and then MDIO bus resume when system
>> resume back from suspend. When MAC resume, usually it will invoke
>> phy_start() where to change PHY state to PHY_UP, then trigger the stat>
>> machine to run now. In phy_state_machine(), it will start/config
>> auto-nego, then change PHY state to PHY_NOLINK, what to next is
>> periodically check PHY link status. When MDIO bus resume, it will
>> initialize PHY hardware, including soft_reset, what would soft_reset
>> affect seems various from different PHYs. For KSZ8081RNB, when it in
>> PHY_NOLINK state and then perform a soft reset, it will never complete
>> auto-nego.
>
> Why? That would need to be checked in detail. Maybe chip errata
> documentation provides a hint.
>
The KSZ8081 spec says the following about bit BMCR_PDOWN:
If software reset (Register 0.15) is
used to exit power-down mode
(Register 0.11 = 1), two software
reset writes (Register 0.15 = 1) are
required. The first write clears
power-down mode; the second
write resets the chip and re-latches
the pin strapping pin values.
Maybe this causes the issue you see and genphy_soft_reset() isn't
appropriate for this PHY. Please re-test with the KSZ8081 soft reset
following the spec comment.
>>
>> This patch changes PHY state to PHY_UP when MDIO bus resume back, it
>> should be reasonable after PHY hardware re-initialized. Also give state
>> machine a chance to start/config auto-nego again.
>>
>
> If the MAC driver calls phy_stop() on suspend, then phydev->suspended
> is true and mdio_bus_phy_may_suspend() returns false. As a consequence
> phydev->suspended_by_mdio_bus is false and mdio_bus_phy_resume()
> skips the PHY hw initialization.
> Please also note that mdio_bus_phy_suspend() calls phy_stop_machine()
> that sets the state to PHY_UP.
>
Forgot that MDIO bus suspend is done before MAC driver suspend.
Therefore disregard this part for now.
> Having said that the current argumentation isn't convincing. I'm not
> aware of such issues on other systems, therefore it's likely that
> something is system-dependent.
>
> Please check the exact call sequence on your system, maybe it
> provides a hint.
>
>> Signed-off-by: Joakim Zhang
>> ---
>> drivers/net/phy/phy_device.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index cc38e326405a..312a6f662481 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -306,6 +306,13 @@ static __maybe_unused int mdio_bus_phy_resume(struct
>> device *dev)
>> ret = phy_resume(phydev);
>> if (ret < 0)
>> return ret;
>> +
>> +/* PHY state could be changed to PHY_NOLINK from MAC controller resume
>> + * rounte with phy_start(), here change to PHY_UP after re-initializing
>> + * PHY hardware, let PHY state machine to start/config auto-nego again.
>> + */
>> +phydev->state = PHY_UP;
>> +
>> no_resume:
>> if (phydev->attached_dev && phydev->adjust_link)
>> phy_start_machine(phydev);
>>
>
Re: [PATCH] staging: rtl8188eu: replace goto with direct return
On Sun, Apr 04, 2021 at 11:54:40AM +0200, Greg KH wrote: > On Sat, Apr 03, 2021 at 10:40:08PM -0700, Deborah Brouwer wrote: > > To conform with Linux kernel coding style, replace goto statement that > > does no cleanup with a direct return. To preserve meaning, copy comments > > from the original goto statement to the return statement. Identified by > > the checkpatch warning: WARNING: void function return statements are not > > generally useful. > > > > Signed-off-by: Deborah Brouwer > > --- > > drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c > > b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c > > index 391c59490718..d21f21857c20 100644 > > --- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c > > +++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c > > @@ -139,7 +139,9 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter) > > hw_init_completed = Adapter->hw_init_completed; > > > > if (!hw_init_completed) > > - goto skip_dm; > > + /* Check GPIO to determine current RF on/off and Pbc status. */ > > + /* Check Hardware Radio ON/OFF or not */ > > + return; > > It does not make sense to have the comments in two places here. The > original code is just fine, there's nothing wrong with the goto > statement here. > > thanks, > > greg k-h Ok, thanks for this feedback.
[PATCH] staging: iio: cdc: remove repeated word
Fix checkpatch warning: WARNING: Possible repeated word: 'from' Signed-off-by: David Villasana Jiménez --- drivers/staging/iio/cdc/ad7150.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c index 48132ab157ef..1be214512ff8 100644 --- a/drivers/staging/iio/cdc/ad7150.c +++ b/drivers/staging/iio/cdc/ad7150.c @@ -57,7 +57,7 @@ * @threshold: thresholds for simple capacitance value events * @thresh_sensitivity: threshold for simple capacitance offset * from 'average' value. - * @mag_sensitity: threshold for magnitude of capacitance offset from + * @mag_sensitity: threshold for magnitude of capacitance offset * from 'average' value. * @thresh_timeout: a timeout, in samples from the moment an * adaptive threshold event occurs to when the average -- 2.30.2
[PATCH] staging: rtl8192e: move const after static
Move the const after static to conform with kernel preference for
static const declaration style instead of static const.
Identified by checkpatch: WARNING: Move const after static - use 'static
const char'.
Signed-off-by: Deborah Brouwer
---
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index e340be3ebb97..c53aa2d305ca 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -260,7 +260,7 @@ void rtl92e_dm_watchdog(struct net_device *dev)
static void _rtl92e_dm_check_ac_dc_power(struct net_device *dev)
{
struct r8192_priv *priv = rtllib_priv(dev);
- static char const ac_dc_script[] =
"/etc/acpi/wireless-rtl-ac-dc-power.sh";
+ static const char ac_dc_script[] =
"/etc/acpi/wireless-rtl-ac-dc-power.sh";
char *argv[] = {(char *)ac_dc_script, DRV_NAME, NULL};
static char *envp[] = {"HOME=/",
"TERM=linux",
@@ -1801,7 +1801,7 @@ static void _rtl92e_dm_check_rf_ctrl_gpio(void *data)
enum rt_rf_power_state eRfPowerStateToSet;
bool bActuallySet = false;
char *argv[3];
- static char const RadioPowerPath[] = "/etc/acpi/events/RadioPower.sh";
+ static const char RadioPowerPath[] = "/etc/acpi/events/RadioPower.sh";
static char *envp[] = {"HOME=/", "TERM=linux", "PATH=/usr/bin:/bin",
NULL};
--
2.17.1
[PATCH] doc: Fix mistaken diagram references in RCU
The 3 diagrams describing rcu_gp_init() all spuriously refer to the same figure, probably due to some copy/paste issue. Fix the references. Signed-off-by: Frederic Weisbecker --- .../RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index 3f6ce41ee0c5..11cdab037bff 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -339,14 +339,14 @@ The diagram below shows the path of ordering if the leftmost leftmost ``rcu_node`` structure offlines its last CPU and if the next ``rcu_node`` structure has no online CPUs). -.. kernel-figure:: TreeRCU-gp-init-1.svg +.. kernel-figure:: TreeRCU-gp-init-2.svg The final ``rcu_gp_init()`` pass through the ``rcu_node`` tree traverses breadth-first, setting each ``rcu_node`` structure's ``->gp_seq`` field to the newly advanced value from the ``rcu_state`` structure, as shown in the following diagram. -.. kernel-figure:: TreeRCU-gp-init-1.svg +.. kernel-figure:: TreeRCU-gp-init-3.svg This change will also cause each CPU's next call to ``__note_gp_changes()`` to notice that a new grace period has started, -- 2.25.1
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04, 2021 at 10:38:41PM +0200, Thomas Gleixner wrote:
> On Sun, Apr 04 2021 at 12:05, syzbot wrote:
>
> Cc + ...
And a couple more...
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() co..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1125f831d0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> > dashboard link: https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com
> >
> > =
> > WARNING: suspicious RCU usage
> > 5.12.0-rc5-syzkaller #0 Not tainted
> > -
> > kernel/sched/core.c:8294 Illegal context switch in RCU-sched read-side
> > critical section!
> >
> > other info that might help us debug this:
> >
> >
> > rcu_scheduler_active = 2, debug_locks = 0
> > 3 locks held by syz-executor.4/8418:
> > #0:
> > 8880751d2b28
> > (
> > >pi_lock
> > ){-.-.}-{2:2}
> > , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345
> > #1:
> > 8880b9d35258
> > (
> > >lock
> > ){-.-.}-{2:2}
> > , at: rq_lock kernel/sched/sched.h:1321 [inline]
> > , at: ttwu_queue kernel/sched/core.c:3184 [inline]
> > , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464
> > #2: 8880b9d1f948 (_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0},
> > at: psi_task_change+0x142/0x220 kernel/sched/psi.c:807
This looks similar to syzbot+dde0cc33951735441...@syzkaller.appspotmail.com
in that rcu_sleep_check() sees an RCU lock held, but the later call to
lockdep_print_held_locks() does not. Did something change recently that
could let the ->lockdep_depth counter get out of sync with the actual
number of locks held?
Thanx, Paul
> > stack backtrace:
> > CPU: 0 PID: 8418 Comm: syz-executor.4 Not tainted 5.12.0-rc5-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:79 [inline]
> > dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> > ___might_sleep+0x266/0x2c0 kernel/sched/core.c:8294
> > __might_fault+0x6e/0x180 mm/memory.c:5018
> > _copy_from_user+0x27/0x180 lib/usercopy.c:13
> > copy_from_user include/linux/uaccess.h:192 [inline]
> > get_timespec64+0x75/0x220 kernel/time/time.c:787
> > __do_sys_clock_nanosleep kernel/time/posix-timers.c:1257 [inline]
> > __se_sys_clock_nanosleep kernel/time/posix-timers.c:1245 [inline]
> > __x64_sys_clock_nanosleep+0x1bb/0x430 kernel/time/posix-timers.c:1245
> > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> > entry_SYSCALL_64_after_hwframe+0x44/0xae
> > RIP: 0033:0x48a621
> > Code: 24 0c 89 3c 24 48 89 4c 24 18 e8 aa e7 ff ff 4c 8b 54 24 18 48 8b 54
> > 24 10 41 89 c0 8b 74 24 0c 8b 3c 24 b8 e6 00 00 00 0f 05 <44> 89 c7 48 89
> > 04 24 e8 e3 e7 ff ff 48 8b 04 24 eb 97 66 2e 0f 1f
> > RSP: 002b:7fffe59fbd50 EFLAGS: 0293 ORIG_RAX: 00e6
> > RAX: ffda RBX: 0294 RCX: 0048a621
> > RDX: 7fffe59fbd90 RSI: RDI:
> > RBP: 7fffe59fbe2c R08: R09: 7fffe5b8a090
> > R10: R11: 0293 R12: 0032
> > R13: 0005717a R14: 0003 R15: 7fffe59fbe90
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: Something is leaking RCU holds from interrupt context
On Sun, Apr 04, 2021 at 07:24:53PM +0100, Matthew Wilcox wrote:
> On Sun, Apr 04, 2021 at 09:48:08AM -0700, Paul E. McKenney wrote:
> > On Sun, Apr 04, 2021 at 11:24:57AM +0100, Matthew Wilcox wrote:
> > > On Sat, Apr 03, 2021 at 09:15:17PM -0700, syzbot wrote:
> > > > HEAD commit:2bb25b3a Merge tag 'mips-fixes_5.12_3' of
> > > > git://git.kernel..
> > > > git tree: upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1284cc31d0
> > > > kernel config:
> > > > https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> > > > dashboard link:
> > > > https://syzkaller.appspot.com/bug?extid=dde0cc33951735441301
> > > >
> > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > > commit:
> > > > Reported-by: syzbot+dde0cc33951735441...@syzkaller.appspotmail.com
> > > >
> > > > WARNING: suspicious RCU usage
> > > > 5.12.0-rc5-syzkaller #0 Not tainted
> > > > -
> > > > kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side
> > > > critical section!
> > > >
> > > > other info that might help us debug this:
> > > >
> > > >
> > > > rcu_scheduler_active = 2, debug_locks = 0
> > > > no locks held by systemd-udevd/4825.
> > >
> > > I think we have something that's taking the RCU read lock in
> > > (soft?) interrupt context and not releasing it properly in all
> > > situations. This thread doesn't have any locks recorded, but
> > > lock_is_held(_bh_lock_map) is true.
> > >
> > > Is there some debugging code that could find this? eg should
> > > lockdep_softirq_end() check that rcu_bh_lock_map is not held?
> > > (if it's taken in process context, then BHs can't run, so if it's
> > > held at softirq exit, then there's definitely a problem).
> >
> > Something like the (untested) patch below?
>
> Maybe? Will this tell us who took the lock? I was really trying to
> throw out a suggestion in the hope that somebody who knows this area
> better than I do would tell me I was wrong.
No idea. If it is reproducible, hopefully someone will try it. If it
is not reproducible, so it goes!
And hey, it is not my fault that you sounded like you knew what you were
talking about! ;-)
But yes, now that you mention it, it is odd that rcu_sleep_check()
thought that rcu_bh_lock_map was held, but lockdep_rcu_suspicious()
does not. One clue might be that rcu_sleep_check() is looking at
rcu_bh_lock_map() itself, while lockdep_rcu_suspicious() and its callee,
lockdep_print_held_locks(), rely on current->lockdep_depth.
Maybe these have gotten out of sync.
> > Please note that it does not make sense to also check for
> > either rcu_lock_map or rcu_sched_lock_map because either of
> > these might be held by the interrupted code.
>
> Yes! Although if we do it somewhere like tasklet_action_common(),
> we could do something like:
>
> +++ b/kernel/softirq.c
> @@ -774,6 +774,7 @@ static void tasklet_action_common(struct softirq_action
> *a,
>
> while (list) {
> struct tasklet_struct *t = list;
> + unsigned long rcu_lockdep = rcu_get_lockdep_state();
>
> list = list->next;
>
> @@ -790,6 +791,10 @@ static void tasklet_action_common(struct softirq_action
> *a,
> }
> tasklet_unlock(t);
> }
> + if (rcu_lockdep != rcu_get_lockdep_state()) {
> + printk(something useful about t);
> + RCU_LOCKDEP_WARN(... something else useful ...);
> + }
>
> local_irq_disable();
>
> where rcu_get_lockdep_state() returns a bitmap of whether the four rcu
> lockdep maps are held.
>
> We might also need something similar in __do_softirq(), in case it's
> not a tasklet that's the problem.
The rcu_get_lockdep_state() function would just set bits based on RCU's
various lockdep maps, but the comparison would need to take at least
debug_lockdep_rcu_enabled() into account. Just in case there is a
lockdep report between the sampling and comparison.
But first let's see what the lockdep experts have to say.
Thanx, Paul
Linux 5.12-rc6
Well, if rc5 was bigger than usual, and I worried about what that
meant for this release, rc6 is positively tiny.
So I think it was just due to the usual random timing fluctuations,
probably mainly networking updates (which were in rc5, but not in
rc6). Which means that unless things change in the next two weeks, the
schedule for this release is going to be the usual one.
Most of the changes here are drivers (gpu and usb stand out, that's
not because of any huge changes, it's mainly because everything else
is even smaller) and some arch updates (mainly x86 kvm, but some
arm64, powerpc, s390, xtensa and RISC-V too).
The rest is random other stuff (with io_uring showing up again, but
much smaller this time).
The shortlog is appended - small and easy to scan if you care about the details.
So hey, in between all those extra helpings of memma - it is Easter,
after all - go ahead and do some more testing as we approach the final
weeks of the release,
Linus
---
Adrian Hunter (2):
PM: runtime: Fix ordering in pm_runtime_get_suppliers()
PM: runtime: Fix race getting/putting suppliers at probe
Ahmad Fatoum (1):
driver core: clear deferred probe reason on probe retry
Alex Deucher (1):
drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend
Andrew Price (1):
gfs2: Flag a withdraw if init_threads() fails
Andy Shevchenko (2):
pinctrl: intel: Show the GPIO base calculation explicitly
usb: dwc3: pci: Enable dis_uX_susphy_quirk for Intel Merrifield
Aneesh Kumar K.V (1):
powerpc/mm/book3s64: Use the correct storage key value when
calling H_PROTECT
Arnd Bergmann (2):
drm/imx: imx-ldb: fix out of bounds array access warning
pinctrl: qcom: fix unintentional string concatenation
Artur Petrosyan (2):
usb: dwc2: Fix HPRT0.PrtSusp bit setting for HiKey 960 board.
usb: dwc2: Prevent core suspend when port connection flag is 0
Atul Gopinathan (2):
staging: rtl8192e: Fix incorrect source in memcpy()
staging: rtl8192e: Change state information from u16 to u8
Ben Dooks (1):
riscv: evaluate put_user() arg before enabling user access
Benjamin Li (1):
interconnect: qcom: msm8939: remove rpm-ids from non-RPM nodes
Bob Peterson (1):
gfs2: report "already frozen/thawed" errors
Christoph Hellwig (2):
block: update a few comments in uapi/linux/blkpg.h
block: remove the unused RQF_ALLOCED flag
Chunfeng Yun (1):
usb: xhci-mtk: fix broken streams issue on 0.96 xHCI
Damien Le Moal (1):
null_blk: fix command timeout completion handling
Daniel Jordan (1):
vfio/type1: Empty batch for pfnmap pages
Dinghao Liu (1):
extcon: Fix error handling in extcon_dev_register
Dmitry Osipenko (1):
drm/tegra: dc: Don't set PLL clock to 0Hz
Dongli Zhang (1):
KVM: x86: remove unused declaration of kvm_write_tsc()
Du Cheng (1):
drivers: video: fbcon: fix NULL dereference in fbcon_cursor()
Evan Quan (1):
drm/amd/pm: no need to force MCLK to highest when no display connected
Geert Uytterhoeven (1):
cpufreq: Fix scaling_{available,boost}_frequencies_show() comments
Georgi Djakov (1):
interconnect: Fix kerneldoc warning
Gulam Mohamed (1):
scsi: iscsi: Fix race condition between login and sync thread
Haiwei Li (1):
KVM: clean up the unused argument
Hans de Goede (1):
ACPI: scan: Fix _STA getting called on devices with unmet dependencies
Heiko Carstens (3):
s390/vdso: copy tod_steering_delta value to vdso_data page
s390/vdso: fix tod_steering_delta type
s390/vdso: fix initializing and updating of vdso_data
Huacai Chen (1):
drm/amdgpu: Set a suitable dev_info.gart_page_size
Hui Wang (2):
ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO
ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook
Ikjoon Jang (1):
ALSA: usb-audio: Apply sample rate quirk to Logitech Connect
Ilya Lipnitskiy (1):
mm: fix race by making init_zero_pfn() early_initcall
Jan Beulich (1):
xen-blkback: don't leak persistent grants from xen_blkbk_map()
Jason Gunthorpe (1):
vfio/nvlink: Add missing SPAPR_TCE_IOMMU depends
Jens Axboe (5):
tomoyo: don't special case PF_IO_WORKER for PF_KTHREAD
io_uring: drop sqd lock before handling signals for SQPOLL
io_uring: don't mark S_ISBLK async work as unbounded
io_uring: move reissue into regular IO path
io_uring: fix !CONFIG_BLOCK compilation failure
Jeremy Szu (1):
ALSA: hda/realtek: fix mute/micmute LEDs for HP 640 G8
Jia-Ju Bai (1):
interconnect: core: fix error return code of icc_link_destroy()
Johan Hovold (8):
USB: cdc-acm: fix double free on probe failure
USB: cdc-acm: fix use-after-free after probe failure
USB: cdc-acm: drop redundant driver-data assignment
USB: cdc-acm: drop redundant driver-data reset
USB: cdc-acm: clean up probe
[syzbot] WARNING: suspicious RCU usage in __ext4_handle_dirty_metadata
Hello,
syzbot found the following issue on:
HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() co..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10808831d0
kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
dashboard link: https://syzkaller.appspot.com/bug?extid=cb293a00f01b422bac7d
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+cb293a00f01b422ba...@syzkaller.appspotmail.com
=
WARNING: suspicious RCU usage
5.12.0-rc5-syzkaller #0 Not tainted
-
kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical
section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
7 locks held by syz-executor.2/17885:
#0:
888014000930
(
>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:961
#1: 88802455a460 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x12d/0x250
fs/read_write.c:658
#2: 888080e91888 (>s_type->i_mutex_key#9){+.+.}-{3:3}, at: inode_lock
include/linux/fs.h:775 [inline]
#2: 888080e91888 (>s_type->i_mutex_key#9){+.+.}-{3:3}, at:
ext4_dio_write_iter fs/ext4/file.c:493 [inline]
#2: 888080e91888 (>s_type->i_mutex_key#9){+.+.}-{3:3}, at:
ext4_file_write_iter+0xaeb/0x14e0 fs/ext4/file.c:661
#3: 888080e91678 (>i_data_sem){}-{3:3}, at:
ext4_map_blocks+0x5e1/0x17d0 fs/ext4/inode.c:631
#4: 8bf718a0 (rcu_read_lock){}-{1:2}, at:
ieee80211_rx_napi+0x0/0x3d0 arch/x86/include/asm/bitops.h:207
#5: 88807b381580 (>rx_path_lock){+.-.}-{2:2}, at: spin_lock_bh
include/linux/spinlock.h:359 [inline]
#5: 88807b381580 (>rx_path_lock){+.-.}-{2:2}, at:
ieee80211_rx_handlers+0xd7/0xae60 net/mac80211/rx.c:3758
#6: 8880b9d26358 (hrtimer_bases.lock){-.-.}-{2:2}, at: __run_hrtimer
kernel/time/hrtimer.c:1541 [inline]
#6: 8880b9d26358 (hrtimer_bases.lock){-.-.}-{2:2}, at:
__hrtimer_run_queues+0x243/0xe40 kernel/time/hrtimer.c:1601
stack backtrace:
CPU: 1 PID: 17885 Comm: syz-executor.2 Not tainted 5.12.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294
__ext4_handle_dirty_metadata+0x37/0x730 fs/ext4/ext4_jbd2.c:326
ext4_mb_mark_diskspace_used+0x991/0x1160 fs/ext4/mballoc.c:3279
ext4_mb_new_blocks+0xd46/0x51a0 fs/ext4/mballoc.c:5000
ext4_new_meta_blocks+0x2fe/0x360 fs/ext4/balloc.c:693
ext4_alloc_branch fs/ext4/indirect.c:335 [inline]
ext4_ind_map_blocks+0xb0d/0x2450 fs/ext4/indirect.c:626
ext4_map_blocks+0x9c9/0x17d0 fs/ext4/inode.c:640
ext4_iomap_alloc fs/ext4/inode.c:3428 [inline]
ext4_iomap_begin+0x463/0x7a0 fs/ext4/inode.c:3478
iomap_apply+0x177/0xb50 fs/iomap/apply.c:46
__iomap_dio_rw+0x71b/0x1280 fs/iomap/direct-io.c:553
iomap_dio_rw+0x30/0x90 fs/iomap/direct-io.c:641
ext4_dio_write_iter fs/ext4/file.c:551 [inline]
ext4_file_write_iter+0xe18/0x14e0 fs/ext4/file.c:661
call_write_iter include/linux/fs.h:1977 [inline]
new_sync_write+0x426/0x650 fs/read_write.c:518
vfs_write+0x796/0xa30 fs/read_write.c:605
ksys_write+0x12d/0x250 fs/read_write.c:658
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x466459
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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:7fadff8ad188 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 0056bf60 RCX: 00466459
RDX: 00248800 RSI: 2000 RDI: 0005
RBP: 004bf9fb R08: R09:
R10: R11: 0246 R12: 0056bf60
R13: 7ffc9e5e3caf R14: 7fadff8ad300 R15: 00022000
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH] ia64: module: fix symbolizer crash on fdescr
Hi Sergei! On 4/3/21 9:48 AM, Sergei Trofimovich wrote: > Noticed failure as a crash on ia64 when tried to symbolize all > backtraces collected by page_owner=on: > > $ cat /sys/kernel/debug/page_owner > > > CPU: 1 PID: 2074 Comm: cat Not tainted 5.12.0-rc4 #226 > Hardware name: hp server rx3600, BIOS 04.03 04/08/2008 > ip is at dereference_module_function_descriptor+0x41/0x100 > > Crash happens at dereference_module_function_descriptor() due to > use-after-free when dereferencing ".opd" section header. > > All section headers are already freed after module is laoded > successfully. > > To keep symbolizer working the change stores ".opd" address > and size after module is relocated to a new place and before > section headers are discarded. > > To make similar errors less obscure module_finalize() now > zeroes out all variables relevant to module loading only. Typo: s/zeroes/zero/. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH 1/2] staging: rtl8712: add blank lines after declarations
Add blank lines after function/struct/union/enum declarations to adhere to
Linux kernel coding style.
Reported by checkpatch.
Signed-off-by: Zhansaya Bagdauletkyzy
---
drivers/staging/rtl8712/rtl8712_recv.h | 1 +
drivers/staging/rtl8712/rtl871x_cmd.h | 10 ++
drivers/staging/rtl8712/rtl871x_event.h| 1 +
drivers/staging/rtl8712/rtl871x_mp.c | 1 +
drivers/staging/rtl8712/rtl871x_mp.h | 1 +
drivers/staging/rtl8712/rtl871x_mp_ioctl.c | 3 +++
drivers/staging/rtl8712/rtl871x_recv.c | 1 +
7 files changed, 18 insertions(+)
diff --git a/drivers/staging/rtl8712/rtl8712_recv.h
b/drivers/staging/rtl8712/rtl8712_recv.h
index 3e385b2242d8..c70b37ff554e 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.h
+++ b/drivers/staging/rtl8712/rtl8712_recv.h
@@ -66,6 +66,7 @@ struct phy_stat {
__le32 phydw6;
__le32 phydw7;
};
+
#define PHY_STAT_GAIN_TRSW_SHT 0
#define PHY_STAT_PWDB_ALL_SHT 4
#define PHY_STAT_CFOSHO_SHT 5
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.h
b/drivers/staging/rtl8712/rtl871x_cmd.h
index 254182a6ce8e..bf6f0c6a86e5 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.h
+++ b/drivers/staging/rtl8712/rtl871x_cmd.h
@@ -333,6 +333,7 @@ struct getdatarate_parm {
u32 rsvd;
};
+
struct getdatarate_rsp {
u8 datarates[NumRates];
};
@@ -377,6 +378,7 @@ struct getphy_rsp {
struct readBB_parm {
u8 offset;
};
+
struct readBB_rsp {
u8 value;
};
@@ -384,6 +386,7 @@ struct readBB_rsp {
struct readTSSI_parm {
u8 offset;
};
+
struct readTSSI_rsp {
u8 value;
};
@@ -400,6 +403,7 @@ struct writePTM_parm {
struct readRF_parm {
u8 offset;
};
+
struct readRF_rsp {
u32 value;
};
@@ -498,6 +502,7 @@ struct settxagctbl_parm {
struct gettxagctbl_parm {
u32 rsvd;
};
+
struct gettxagctbl_rsp {
u32 txagc[MAX_RATES_LENGTH];
};
@@ -513,6 +518,7 @@ struct setssup_parm {
struct getssup_parm{
u32 rsvd;
};
+
struct getssup_rsp {
u8 ss_ForceUp[MAX_RATES_LENGTH];
};
@@ -524,6 +530,7 @@ struct setssdlevel_parm {
struct getssdlevel_parm{
u32 rsvd;
};
+
struct getssdlevel_rsp {
u8 ss_DLevel[MAX_RATES_LENGTH];
};
@@ -535,6 +542,7 @@ struct setssulevel_parm {
struct getssulevel_parm{
u32 rsvd;
};
+
struct getssulevel_rsp {
u8 ss_ULevel[MAX_RATES_LENGTH];
};
@@ -585,6 +593,7 @@ struct setratable_parm {
struct getratable_parm {
uint rsvd;
};
+
struct getratable_rsp {
u8 ss_ForceUp[NumRates];
u8 ss_ULevel[NumRates];
@@ -621,6 +630,7 @@ struct getbcnokcnt_rsp {
struct getbcnerrcnt_parm {
unsigned int rsvd;
};
+
struct getbcnerrcnt_rsp {
unsigned long bcnerrcnt;
};
diff --git a/drivers/staging/rtl8712/rtl871x_event.h
b/drivers/staging/rtl8712/rtl871x_event.h
index d9a5476d2426..759a2d27d8f2 100644
--- a/drivers/staging/rtl8712/rtl871x_event.h
+++ b/drivers/staging/rtl8712/rtl871x_event.h
@@ -102,6 +102,7 @@ struct ADDBA_Req_Report_parm {
unsigned short StartSeqNum;
unsigned char tid;
};
+
#include "rtl8712_event.h"
#endif /* _WLANEVENT_H_ */
diff --git a/drivers/staging/rtl8712/rtl871x_mp.c
b/drivers/staging/rtl8712/rtl871x_mp.c
index 24020257bc58..099c512c8519 100644
--- a/drivers/staging/rtl8712/rtl871x_mp.c
+++ b/drivers/staging/rtl8712/rtl871x_mp.c
@@ -387,6 +387,7 @@ void r8712_SwitchBandwidth(struct _adapter *pAdapter)
break;
}
}
+
/*--Define structure*/
struct R_ANTENNA_SELECT_OFDM {
u32 r_tx_antenna:4;
diff --git a/drivers/staging/rtl8712/rtl871x_mp.h
b/drivers/staging/rtl8712/rtl871x_mp.h
index e79a67676469..0a60b1e6ccaf 100644
--- a/drivers/staging/rtl8712/rtl871x_mp.h
+++ b/drivers/staging/rtl8712/rtl871x_mp.h
@@ -121,6 +121,7 @@ struct bb_reg_param {
u32 offset;
u32 value;
};
+
/* === */
#define LOWER true
diff --git a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
index f906d3fbe179..31414a960c9e 100644
--- a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
+++ b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
@@ -681,6 +681,7 @@ uint oid_rt_pro_read_efuse_hdl(struct oid_par_priv
*poid_par_priv)
*poid_par_priv->bytes_rw = poid_par_priv->information_buf_len;
return status;
}
+
/**/
uint oid_rt_pro_write_efuse_hdl(struct oid_par_priv *poid_par_priv)
{
@@ -708,6 +709,7 @@ uint oid_rt_pro_write_efuse_hdl(struct oid_par_priv
*poid_par_priv)
status = RNDIS_STATUS_FAILURE;
return status;
}
+
/*--*/
uint oid_rt_get_efuse_current_size_hdl(struct oid_par_priv
[PATCH 2/2] staging: rtl8712: remove extra blank lines
Remove extra blank lines to adhere to Linux kernel coding style.
Reported by checkpatch.
Signed-off-by: Zhansaya Bagdauletkyzy
---
drivers/staging/rtl8712/rtl8712_recv.h| 1 -
drivers/staging/rtl8712/rtl871x_mlme.c| 3 ---
drivers/staging/rtl8712/rtl871x_pwrctrl.h | 3 ---
drivers/staging/rtl8712/rtl871x_recv.h| 1 -
4 files changed, 8 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl8712_recv.h
b/drivers/staging/rtl8712/rtl8712_recv.h
index c70b37ff554e..f4d20b0efd4e 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.h
+++ b/drivers/staging/rtl8712/rtl8712_recv.h
@@ -85,7 +85,6 @@ union recvstat {
unsigned int value[RXDESC_SIZE>>2];
};
-
struct recv_buf {
struct list_head list;
spinlock_t recvbuf_lock;
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
b/drivers/staging/rtl8712/rtl871x_mlme.c
index f5886b39b3b5..8a97307fbbd6 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -124,7 +124,6 @@ static void free_network_nolock(struct mlme_priv *pmlmepriv,
pmlmepriv->num_of_scanned--;
}
-
/* return the wlan_network with the matching addr
* Shall be called under atomic context...
* to avoid possible racing condition...
@@ -358,7 +357,6 @@ static void update_scanned_network(struct _adapter *adapter,
plist = plist->next;
}
-
/* If we didn't find a match, then get a new network slot to initialize
* with this beacon's information
*/
@@ -621,7 +619,6 @@ void r8712_indicate_connect(struct _adapter *padapter)
jiffies + msecs_to_jiffies(6));
}
-
/*
* r8712_ind_disconnect: the caller has to lock pmlmepriv->lock
*/
diff --git a/drivers/staging/rtl8712/rtl871x_pwrctrl.h
b/drivers/staging/rtl8712/rtl871x_pwrctrl.h
index dd5a79f90b1a..bf6623cfaf27 100644
--- a/drivers/staging/rtl8712/rtl871x_pwrctrl.h
+++ b/drivers/staging/rtl8712/rtl871x_pwrctrl.h
@@ -17,7 +17,6 @@
#include "osdep_service.h"
#include "drv_types.h"
-
#define CMD_ALIVE BIT(2)
enum Power_Mgnt {
@@ -63,12 +62,10 @@ enum Power_Mgnt {
#definePS_STATE_S3 (PS_ALL_ON)
#definePS_STATE_S4 ((PS_ST_ACTIVE) | (PS_ALL_ON))
-
#definePS_IS_RF_ON(x) ((x) & (PS_ALL_ON))
#definePS_IS_ACTIVE(x) ((x) & (PS_ST_ACTIVE))
#defineCLR_PS_STATE(x) ((x) = ((x) & (0xF0)))
-
struct reportpwrstate_parm {
unsigned char mode;
unsigned char state; /* the CPWM value */
diff --git a/drivers/staging/rtl8712/rtl871x_recv.h
b/drivers/staging/rtl8712/rtl871x_recv.h
index e83c256e1474..7c9995060a6f 100644
--- a/drivers/staging/rtl8712/rtl871x_recv.h
+++ b/drivers/staging/rtl8712/rtl871x_recv.h
@@ -29,7 +29,6 @@ structstainfo_rxcache {
#definePHY_RSSI_SLID_WIN_MAX 100
#definePHY_LINKQUALITY_SLID_WIN_MAX20
-
struct smooth_rssi_data {
u32 elements[100]; /* array to store values */
u32 index; /* index to current array to store */
--
2.25.1
[PATCH 0/2] staging: rtl8712: add blank lines after declarations and remove extra blank lines
This patchset adds blank lines after function/struct/union/enum declarations and removes extra blank lines. Reported by checkpatch. Zhansaya Bagdauletkyzy (2): staging: rtl8712: add blank lines after declarations staging: rtl8712: remove extra blank lines drivers/staging/rtl8712/rtl8712_recv.h | 2 +- drivers/staging/rtl8712/rtl871x_cmd.h | 10 ++ drivers/staging/rtl8712/rtl871x_event.h| 1 + drivers/staging/rtl8712/rtl871x_mlme.c | 3 --- drivers/staging/rtl8712/rtl871x_mp.c | 1 + drivers/staging/rtl8712/rtl871x_mp.h | 1 + drivers/staging/rtl8712/rtl871x_mp_ioctl.c | 3 +++ drivers/staging/rtl8712/rtl871x_pwrctrl.h | 3 --- drivers/staging/rtl8712/rtl871x_recv.c | 1 + drivers/staging/rtl8712/rtl871x_recv.h | 1 - 10 files changed, 18 insertions(+), 8 deletions(-) -- 2.25.1
[GIT PULL] clk: imx: Updates for v5.13
The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux.git clk/imx for you to fetch changes up to 054ef44ea3ef2883e0f63c9a54c91c07f321a0b4: clk: imx: Reference preceded by free (2021-04-04 22:39:05 +0300) Adam Ford (1): clk: imx: Fix reparenting of UARTs not associated with stdout Jian Dong (1): clk: imx: Reference preceded by free Richard Zhu (2): clk: imx8mp: Remove the none exist pcie clocks clk: imx8mq: Correct the pcie1 sels drivers/clk/imx/clk-imx25.c | 12 +- drivers/clk/imx/clk-imx27.c | 13 +- drivers/clk/imx/clk-imx35.c | 10 +--- drivers/clk/imx/clk-imx5.c | 30 +++ drivers/clk/imx/clk-imx6q.c | 16 + drivers/clk/imx/clk-imx6sl.c | 16 + drivers/clk/imx/clk-imx6sll.c| 24 +-- drivers/clk/imx/clk-imx6sx.c | 16 + drivers/clk/imx/clk-imx7d.c | 22 + drivers/clk/imx/clk-imx7ulp.c| 31 ++-- drivers/clk/imx/clk-imx8mm.c | 18 ++ drivers/clk/imx/clk-imx8mn.c | 18 ++ drivers/clk/imx/clk-imx8mp.c | 32 + drivers/clk/imx/clk-imx8mq.c | 22 - drivers/clk/imx/clk-lpcg-scu.c | 1 + drivers/clk/imx/clk-scu.c| 1 + drivers/clk/imx/clk.c| 41 +--- drivers/clk/imx/clk.h| 4 ++-- include/dt-bindings/clock/imx8mp-clock.h | 3 --- 19 files changed, 58 insertions(+), 272 deletions(-)
Re: [syzbot] WARNING: suspicious RCU usage in get_timespec64
On Sun, Apr 04 2021 at 12:05, syzbot wrote:
Cc + ...
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:5e46d1b7 reiserfs: update reiserfs_xattrs_initialized() co..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1125f831d0
> kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
> dashboard link: https://syzkaller.appspot.com/bug?extid=88e4f02896967fe1ab0d
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+88e4f02896967fe1a...@syzkaller.appspotmail.com
>
> =
> WARNING: suspicious RCU usage
> 5.12.0-rc5-syzkaller #0 Not tainted
> -
> kernel/sched/core.c:8294 Illegal context switch in RCU-sched read-side
> critical section!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 0
> 3 locks held by syz-executor.4/8418:
> #0:
> 8880751d2b28
> (
> >pi_lock
> ){-.-.}-{2:2}
> , at: try_to_wake_up+0x98/0x14a0 kernel/sched/core.c:3345
> #1:
> 8880b9d35258
> (
> >lock
> ){-.-.}-{2:2}
> , at: rq_lock kernel/sched/sched.h:1321 [inline]
> , at: ttwu_queue kernel/sched/core.c:3184 [inline]
> , at: try_to_wake_up+0x5e6/0x14a0 kernel/sched/core.c:3464
> #2: 8880b9d1f948 (_cpu_ptr(group->pcpu, cpu)->seq){-.-.}-{0:0}, at:
> psi_task_change+0x142/0x220 kernel/sched/psi.c:807
>
> stack backtrace:
> CPU: 0 PID: 8418 Comm: syz-executor.4 Not tainted 5.12.0-rc5-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> ___might_sleep+0x266/0x2c0 kernel/sched/core.c:8294
> __might_fault+0x6e/0x180 mm/memory.c:5018
> _copy_from_user+0x27/0x180 lib/usercopy.c:13
> copy_from_user include/linux/uaccess.h:192 [inline]
> get_timespec64+0x75/0x220 kernel/time/time.c:787
> __do_sys_clock_nanosleep kernel/time/posix-timers.c:1257 [inline]
> __se_sys_clock_nanosleep kernel/time/posix-timers.c:1245 [inline]
> __x64_sys_clock_nanosleep+0x1bb/0x430 kernel/time/posix-timers.c:1245
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x48a621
> Code: 24 0c 89 3c 24 48 89 4c 24 18 e8 aa e7 ff ff 4c 8b 54 24 18 48 8b 54 24
> 10 41 89 c0 8b 74 24 0c 8b 3c 24 b8 e6 00 00 00 0f 05 <44> 89 c7 48 89 04 24
> e8 e3 e7 ff ff 48 8b 04 24 eb 97 66 2e 0f 1f
> RSP: 002b:7fffe59fbd50 EFLAGS: 0293 ORIG_RAX: 00e6
> RAX: ffda RBX: 0294 RCX: 0048a621
> RDX: 7fffe59fbd90 RSI: RDI:
> RBP: 7fffe59fbe2c R08: R09: 7fffe5b8a090
> R10: R11: 0293 R12: 0032
> R13: 0005717a R14: 0003 R15: 7fffe59fbe90
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
