* [PATCH 4.14 1/8] Revert "scsi: libsas: direct call probe and destruct"
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
@ 2020-08-05 15:53 ` Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 2/8] random32: update the net random state on interrupt and activity Greg Kroah-Hartman
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-05 15:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jason Yan, John Garry,
Johannes Thumshirn, Ewan Milne, Christoph Hellwig, Tomas Henzl,
Dan Williams, Hannes Reinecke, Martin K. Petersen, Sasha Levin
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 3a156abd24346a3188eb7e88cf86386a409e0d02 which is
commit 0558f33c06bb910e2879e355192227a8e8f0219d upstream.
John writes:
This patch was one of a series from Jason to fix this WARN issue, below:
https://lore.kernel.org/linux-scsi/8f6e3763-2b04-23e8-f1ec-8ed3c58f55d3@huawei.com/
I'm doubtful that it should be taken in isolation. Maybe 1 or 2 other
patches are required.
The WARN was really annoying, so we could spend a bit of time to test a
backport of what is strictly required. Let us know.
Cc: Jason Yan <yanaijie@huawei.com>
CC: John Garry <john.garry@huawei.com>
CC: Johannes Thumshirn <jthumshirn@suse.de>
CC: Ewan Milne <emilne@redhat.com>
CC: Christoph Hellwig <hch@lst.de>
CC: Tomas Henzl <thenzl@redhat.com>
CC: Dan Williams <dan.j.williams@intel.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/libsas/sas_ata.c | 1 +
drivers/scsi/libsas/sas_discover.c | 32 ++++++++++++++------------------
drivers/scsi/libsas/sas_expander.c | 8 +++++---
drivers/scsi/libsas/sas_internal.h | 1 -
drivers/scsi/libsas/sas_port.c | 3 ---
include/scsi/libsas.h | 3 ++-
include/scsi/scsi_transport_sas.h | 1 -
7 files changed, 22 insertions(+), 27 deletions(-)
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -730,6 +730,7 @@ int sas_discover_sata(struct domain_devi
if (res)
return res;
+ sas_discover_event(dev->port, DISCE_PROBE);
return 0;
}
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -221,9 +221,13 @@ void sas_notify_lldd_dev_gone(struct dom
}
}
-static void sas_probe_devices(struct asd_sas_port *port)
+static void sas_probe_devices(struct work_struct *work)
{
struct domain_device *dev, *n;
+ struct sas_discovery_event *ev = to_sas_discovery_event(work);
+ struct asd_sas_port *port = ev->port;
+
+ clear_bit(DISCE_PROBE, &port->disc.pending);
/* devices must be domain members before link recovery and probe */
list_for_each_entry(dev, &port->disco_list, disco_list_node) {
@@ -299,6 +303,7 @@ int sas_discover_end_dev(struct domain_d
res = sas_notify_lldd_dev_found(dev);
if (res)
return res;
+ sas_discover_event(dev->port, DISCE_PROBE);
return 0;
}
@@ -357,9 +362,13 @@ static void sas_unregister_common_dev(st
sas_put_device(dev);
}
-void sas_destruct_devices(struct asd_sas_port *port)
+static void sas_destruct_devices(struct work_struct *work)
{
struct domain_device *dev, *n;
+ struct sas_discovery_event *ev = to_sas_discovery_event(work);
+ struct asd_sas_port *port = ev->port;
+
+ clear_bit(DISCE_DESTRUCT, &port->disc.pending);
list_for_each_entry_safe(dev, n, &port->destroy_list, disco_list_node) {
list_del_init(&dev->disco_list_node);
@@ -370,16 +379,6 @@ void sas_destruct_devices(struct asd_sas
}
}
-static void sas_destruct_ports(struct asd_sas_port *port)
-{
- struct sas_port *sas_port, *p;
-
- list_for_each_entry_safe(sas_port, p, &port->sas_port_del_list, del_list) {
- list_del_init(&sas_port->del_list);
- sas_port_delete(sas_port);
- }
-}
-
void sas_unregister_dev(struct asd_sas_port *port, struct domain_device *dev)
{
if (!test_bit(SAS_DEV_DESTROY, &dev->state) &&
@@ -394,6 +393,7 @@ void sas_unregister_dev(struct asd_sas_p
if (!test_and_set_bit(SAS_DEV_DESTROY, &dev->state)) {
sas_rphy_unlink(dev->rphy);
list_move_tail(&dev->disco_list_node, &port->destroy_list);
+ sas_discover_event(dev->port, DISCE_DESTRUCT);
}
}
@@ -499,8 +499,6 @@ static void sas_discover_domain(struct w
port->port_dev = NULL;
}
- sas_probe_devices(port);
-
SAS_DPRINTK("DONE DISCOVERY on port %d, pid:%d, result:%d\n", port->id,
task_pid_nr(current), error);
}
@@ -534,10 +532,6 @@ static void sas_revalidate_domain(struct
port->id, task_pid_nr(current), res);
out:
mutex_unlock(&ha->disco_mutex);
-
- sas_destruct_devices(port);
- sas_destruct_ports(port);
- sas_probe_devices(port);
}
/* ---------- Events ---------- */
@@ -593,8 +587,10 @@ void sas_init_disc(struct sas_discovery
static const work_func_t sas_event_fns[DISC_NUM_EVENTS] = {
[DISCE_DISCOVER_DOMAIN] = sas_discover_domain,
[DISCE_REVALIDATE_DOMAIN] = sas_revalidate_domain,
+ [DISCE_PROBE] = sas_probe_devices,
[DISCE_SUSPEND] = sas_suspend_devices,
[DISCE_RESUME] = sas_resume_devices,
+ [DISCE_DESTRUCT] = sas_destruct_devices,
};
disc->pending = 0;
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1946,8 +1946,7 @@ static void sas_unregister_devs_sas_addr
sas_port_delete_phy(phy->port, phy->phy);
sas_device_set_phy(found, phy->port);
if (phy->port->num_phys == 0)
- list_add_tail(&phy->port->del_list,
- &parent->port->sas_port_del_list);
+ sas_port_delete(phy->port);
phy->port = NULL;
}
}
@@ -2157,7 +2156,7 @@ int sas_ex_revalidate_domain(struct doma
struct domain_device *dev = NULL;
res = sas_find_bcast_dev(port_dev, &dev);
- if (res == 0 && dev) {
+ while (res == 0 && dev) {
struct expander_device *ex = &dev->ex_dev;
int i = 0, phy_id;
@@ -2169,6 +2168,9 @@ int sas_ex_revalidate_domain(struct doma
res = sas_rediscover(dev, phy_id);
i = phy_id + 1;
} while (i < ex->num_phys);
+
+ dev = NULL;
+ res = sas_find_bcast_dev(port_dev, &dev);
}
return res;
}
--- a/drivers/scsi/libsas/sas_internal.h
+++ b/drivers/scsi/libsas/sas_internal.h
@@ -98,7 +98,6 @@ int sas_try_ata_reset(struct asd_sas_phy
void sas_hae_reset(struct work_struct *work);
void sas_free_device(struct kref *kref);
-void sas_destruct_devices(struct asd_sas_port *port);
#ifdef CONFIG_SCSI_SAS_HOST_SMP
extern void sas_smp_host_handler(struct bsg_job *job, struct Scsi_Host *shost);
--- a/drivers/scsi/libsas/sas_port.c
+++ b/drivers/scsi/libsas/sas_port.c
@@ -66,7 +66,6 @@ static void sas_resume_port(struct asd_s
rc = sas_notify_lldd_dev_found(dev);
if (rc) {
sas_unregister_dev(port, dev);
- sas_destruct_devices(port);
continue;
}
@@ -220,7 +219,6 @@ void sas_deform_port(struct asd_sas_phy
if (port->num_phys == 1) {
sas_unregister_domain_devices(port, gone);
- sas_destruct_devices(port);
sas_port_delete(port->port);
port->port = NULL;
} else {
@@ -325,7 +323,6 @@ static void sas_init_port(struct asd_sas
INIT_LIST_HEAD(&port->dev_list);
INIT_LIST_HEAD(&port->disco_list);
INIT_LIST_HEAD(&port->destroy_list);
- INIT_LIST_HEAD(&port->sas_port_del_list);
spin_lock_init(&port->phy_list_lock);
INIT_LIST_HEAD(&port->phy_list);
port->ha = sas_ha;
--- a/include/scsi/libsas.h
+++ b/include/scsi/libsas.h
@@ -87,8 +87,10 @@ enum discover_event {
DISCE_DISCOVER_DOMAIN = 0U,
DISCE_REVALIDATE_DOMAIN = 1,
DISCE_PORT_GONE = 2,
+ DISCE_PROBE = 3,
DISCE_SUSPEND = 4,
DISCE_RESUME = 5,
+ DISCE_DESTRUCT = 6,
DISC_NUM_EVENTS = 7,
};
@@ -267,7 +269,6 @@ struct asd_sas_port {
struct list_head dev_list;
struct list_head disco_list;
struct list_head destroy_list;
- struct list_head sas_port_del_list;
enum sas_linkrate linkrate;
struct sas_work work;
--- a/include/scsi/scsi_transport_sas.h
+++ b/include/scsi/scsi_transport_sas.h
@@ -156,7 +156,6 @@ struct sas_port {
struct mutex phy_list_mutex;
struct list_head phy_list;
- struct list_head del_list; /* libsas only */
};
#define dev_to_sas_port(d) \
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 4.14 2/8] random32: update the net random state on interrupt and activity
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 1/8] Revert "scsi: libsas: direct call probe and destruct" Greg Kroah-Hartman
@ 2020-08-05 15:53 ` Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 3/8] ARM: percpu.h: fix build error Greg Kroah-Hartman
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-05 15:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Amit Klein, Linus Torvalds,
Eric Dumazet, Jason A. Donenfeld, Andy Lutomirski, Kees Cook,
Thomas Gleixner, Peter Zijlstra, Willy Tarreau
From: Willy Tarreau <w@1wt.eu>
commit f227e3ec3b5cad859ad15666874405e8c1bbc1d4 upstream.
This modifies the first 32 bits out of the 128 bits of a random CPU's
net_rand_state on interrupt or CPU activity to complicate remote
observations that could lead to guessing the network RNG's internal
state.
Note that depending on some network devices' interrupt rate moderation
or binding, this re-seeding might happen on every packet or even almost
never.
In addition, with NOHZ some CPUs might not even get timer interrupts,
leaving their local state rarely updated, while they are running
networked processes making use of the random state. For this reason, we
also perform this update in update_process_times() in order to at least
update the state when there is user or system activity, since it's the
only case we care about.
Reported-by: Amit Klein <aksecurity@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/random.c | 1 +
include/linux/random.h | 3 +++
kernel/time/timer.c | 8 ++++++++
lib/random32.c | 2 +-
4 files changed, 13 insertions(+), 1 deletion(-)
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1246,6 +1246,7 @@ void add_interrupt_randomness(int irq, i
fast_mix(fast_pool);
add_interrupt_bench(cycles);
+ this_cpu_add(net_rand_state.s1, fast_pool->pool[cycles & 3]);
if (unlikely(crng_init == 0)) {
if ((fast_pool->count >= 64) &&
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -9,6 +9,7 @@
#include <linux/list.h>
#include <linux/once.h>
+#include <linux/percpu.h>
#include <uapi/linux/random.h>
@@ -116,6 +117,8 @@ struct rnd_state {
__u32 s1, s2, s3, s4;
};
+DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
+
u32 prandom_u32_state(struct rnd_state *state);
void prandom_bytes_state(struct rnd_state *state, void *buf, size_t nbytes);
void prandom_seed_full_state(struct rnd_state __percpu *pcpu_state);
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -44,6 +44,7 @@
#include <linux/sched/debug.h>
#include <linux/slab.h>
#include <linux/compat.h>
+#include <linux/random.h>
#include <linux/uaccess.h>
#include <asm/unistd.h>
@@ -1595,6 +1596,13 @@ void update_process_times(int user_tick)
scheduler_tick();
if (IS_ENABLED(CONFIG_POSIX_TIMERS))
run_posix_cpu_timers(p);
+
+ /* The current CPU might make use of net randoms without receiving IRQs
+ * to renew them often enough. Let's update the net_rand_state from a
+ * non-constant value that's not affine to the number of calls to make
+ * sure it's updated when there's some activity (we don't care in idle).
+ */
+ this_cpu_add(net_rand_state.s1, rol32(jiffies, 24) + user_tick);
}
/**
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -48,7 +48,7 @@ static inline void prandom_state_selftes
}
#endif
-static DEFINE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
+DEFINE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
/**
* prandom_u32_state - seeded pseudo-random number generator.
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 4.14 3/8] ARM: percpu.h: fix build error
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 1/8] Revert "scsi: libsas: direct call probe and destruct" Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 2/8] random32: update the net random state on interrupt and activity Greg Kroah-Hartman
@ 2020-08-05 15:53 ` Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 4/8] random: fix circular include dependency on arm64 after addition of percpu.h Greg Kroah-Hartman
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-05 15:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Grygorii Strashko, Linus Torvalds
From: Grygorii Strashko <grygorii.strashko@ti.com>
commit aa54ea903abb02303bf55855fb51e3fcee135d70 upstream.
Fix build error for the case:
defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
config: keystone_defconfig
CC arch/arm/kernel/signal.o
In file included from ../include/linux/random.h:14,
from ../arch/arm/kernel/signal.c:8:
../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’:
../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’?
: "Q" (*(const unsigned long *)current_stack_pointer));
^~~~~~~~~~~~~~~~~~~~~
user_stack_pointer
Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/percpu.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/include/asm/percpu.h
+++ b/arch/arm/include/asm/percpu.h
@@ -16,6 +16,8 @@
#ifndef _ASM_ARM_PERCPU_H_
#define _ASM_ARM_PERCPU_H_
+#include <asm/thread_info.h>
+
/*
* Same as asm-generic/percpu.h, except that we store the per cpu offset
* in the TPIDRPRW. TPIDRPRW only exists on V6K and V7
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 4.14 4/8] random: fix circular include dependency on arm64 after addition of percpu.h
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2020-08-05 15:53 ` [PATCH 4.14 3/8] ARM: percpu.h: fix build error Greg Kroah-Hartman
@ 2020-08-05 15:53 ` Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 5/8] random32: remove net_rand_state from the latent entropy gcc plugin Greg Kroah-Hartman
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-05 15:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Díaz, Kees Cook,
Marc Zyngier, Stephen Rothwell, Willy Tarreau, Linus Torvalds
From: Willy Tarreau <w@1wt.eu>
commit 1c9df907da83812e4f33b59d3d142c864d9da57f upstream.
Daniel Díaz and Kees Cook independently reported that commit
f227e3ec3b5c ("random32: update the net random state on interrupt and
activity") broke arm64 due to a circular dependency on include files
since the addition of percpu.h in random.h.
The correct fix would definitely be to move all the prandom32 stuff out
of random.h but for backporting, a smaller solution is preferred.
This one replaces linux/percpu.h with asm/percpu.h, and this fixes the
problem on x86_64, arm64, arm, and mips. Note that moving percpu.h
around didn't change anything and that removing it entirely broke
differently. When backporting, such options might still be considered
if this patch fails to help.
[ It turns out that an alternate fix seems to be to just remove the
troublesome <asm/pointer_auth.h> remove from the arm64 <asm/smp.h>
that causes the circular dependency.
But we might as well do the whole belt-and-suspenders thing, and
minimize inclusion in <linux/random.h> too. Either will fix the
problem, and both are good changes. - Linus ]
Reported-by: Daniel Díaz <daniel.diaz@linaro.org>
Reported-by: Kees Cook <keescook@chromium.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Fixes: f227e3ec3b5c
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/random.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -9,7 +9,7 @@
#include <linux/list.h>
#include <linux/once.h>
-#include <linux/percpu.h>
+#include <asm/percpu.h>
#include <uapi/linux/random.h>
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 4.14 5/8] random32: remove net_rand_state from the latent entropy gcc plugin
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2020-08-05 15:53 ` [PATCH 4.14 4/8] random: fix circular include dependency on arm64 after addition of percpu.h Greg Kroah-Hartman
@ 2020-08-05 15:53 ` Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 6/8] random32: move the pseudo-random 32-bit definitions to prandom.h Greg Kroah-Hartman
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-05 15:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stephen Rothwell, Emese Revfy,
Kees Cook, Willy Tarreau, Linus Torvalds
From: Linus Torvalds <torvalds@linux-foundation.org>
commit 83bdc7275e6206f560d247be856bceba3e1ed8f2 upstream.
It turns out that the plugin right now ends up being really unhappy
about the change from 'static' to 'extern' storage that happened in
commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity").
This is probably a trivial fix for the latent_entropy plugin, but for
now, just remove net_rand_state from the list of things the plugin
worries about.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Emese Revfy <re.emese@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/random.h | 2 +-
lib/random32.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -117,7 +117,7 @@ struct rnd_state {
__u32 s1, s2, s3, s4;
};
-DECLARE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
+DECLARE_PER_CPU(struct rnd_state, net_rand_state);
u32 prandom_u32_state(struct rnd_state *state);
void prandom_bytes_state(struct rnd_state *state, void *buf, size_t nbytes);
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -48,7 +48,7 @@ static inline void prandom_state_selftes
}
#endif
-DEFINE_PER_CPU(struct rnd_state, net_rand_state) __latent_entropy;
+DEFINE_PER_CPU(struct rnd_state, net_rand_state);
/**
* prandom_u32_state - seeded pseudo-random number generator.
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 4.14 6/8] random32: move the pseudo-random 32-bit definitions to prandom.h
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2020-08-05 15:53 ` [PATCH 4.14 5/8] random32: remove net_rand_state from the latent entropy gcc plugin Greg Kroah-Hartman
@ 2020-08-05 15:53 ` Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 7/8] ext4: fix direct I/O read error Greg Kroah-Hartman
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-05 15:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Guenter Roeck, Willy Tarreau, Linus Torvalds
From: Linus Torvalds <torvalds@linux-foundation.org>
commit c0842fbc1b18c7a044e6ff3e8fa78bfa822c7d1a upstream.
The addition of percpu.h to the list of includes in random.h revealed
some circular dependencies on arm64 and possibly other platforms. This
include was added solely for the pseudo-random definitions, which have
nothing to do with the rest of the definitions in this file but are
still there for legacy reasons.
This patch moves the pseudo-random parts to linux/prandom.h and the
percpu.h include with it, which is now guarded by _LINUX_PRANDOM_H and
protected against recursive inclusion.
A further cleanup step would be to remove this from <linux/random.h>
entirely, and make people who use the prandom infrastructure include
just the new header file. That's a bit of a churn patch, but grepping
for "prandom_" and "next_pseudo_random32" "struct rnd_state" should
catch most users.
But it turns out that that nice cleanup step is fairly painful, because
a _lot_ of code currently seems to depend on the implicit include of
<linux/random.h>, which can currently come in a lot of ways, including
such fairly core headfers as <linux/net.h>.
So the "nice cleanup" part may or may never happen.
Fixes: 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
Tested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/prandom.h | 78 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/random.h | 66 ++--------------------------------------
2 files changed, 82 insertions(+), 62 deletions(-)
--- /dev/null
+++ b/include/linux/prandom.h
@@ -0,0 +1,78 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * include/linux/prandom.h
+ *
+ * Include file for the fast pseudo-random 32-bit
+ * generation.
+ */
+#ifndef _LINUX_PRANDOM_H
+#define _LINUX_PRANDOM_H
+
+#include <linux/types.h>
+#include <linux/percpu.h>
+
+u32 prandom_u32(void);
+void prandom_bytes(void *buf, size_t nbytes);
+void prandom_seed(u32 seed);
+void prandom_reseed_late(void);
+
+struct rnd_state {
+ __u32 s1, s2, s3, s4;
+};
+
+DECLARE_PER_CPU(struct rnd_state, net_rand_state);
+
+u32 prandom_u32_state(struct rnd_state *state);
+void prandom_bytes_state(struct rnd_state *state, void *buf, size_t nbytes);
+void prandom_seed_full_state(struct rnd_state __percpu *pcpu_state);
+
+#define prandom_init_once(pcpu_state) \
+ DO_ONCE(prandom_seed_full_state, (pcpu_state))
+
+/**
+ * prandom_u32_max - returns a pseudo-random number in interval [0, ep_ro)
+ * @ep_ro: right open interval endpoint
+ *
+ * Returns a pseudo-random number that is in interval [0, ep_ro). Note
+ * that the result depends on PRNG being well distributed in [0, ~0U]
+ * u32 space. Here we use maximally equidistributed combined Tausworthe
+ * generator, that is, prandom_u32(). This is useful when requesting a
+ * random index of an array containing ep_ro elements, for example.
+ *
+ * Returns: pseudo-random number in interval [0, ep_ro)
+ */
+static inline u32 prandom_u32_max(u32 ep_ro)
+{
+ return (u32)(((u64) prandom_u32() * ep_ro) >> 32);
+}
+
+/*
+ * Handle minimum values for seeds
+ */
+static inline u32 __seed(u32 x, u32 m)
+{
+ return (x < m) ? x + m : x;
+}
+
+/**
+ * prandom_seed_state - set seed for prandom_u32_state().
+ * @state: pointer to state structure to receive the seed.
+ * @seed: arbitrary 64-bit value to use as a seed.
+ */
+static inline void prandom_seed_state(struct rnd_state *state, u64 seed)
+{
+ u32 i = (seed >> 32) ^ (seed << 10) ^ seed;
+
+ state->s1 = __seed(i, 2U);
+ state->s2 = __seed(i, 8U);
+ state->s3 = __seed(i, 16U);
+ state->s4 = __seed(i, 128U);
+}
+
+/* Pseudo random number generator from numerical recipes. */
+static inline u32 next_pseudo_random32(u32 seed)
+{
+ return seed * 1664525 + 1013904223;
+}
+
+#endif
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -9,7 +9,6 @@
#include <linux/list.h>
#include <linux/once.h>
-#include <asm/percpu.h>
#include <uapi/linux/random.h>
@@ -108,63 +107,12 @@ declare_get_random_var_wait(long)
unsigned long randomize_page(unsigned long start, unsigned long range);
-u32 prandom_u32(void);
-void prandom_bytes(void *buf, size_t nbytes);
-void prandom_seed(u32 seed);
-void prandom_reseed_late(void);
-
-struct rnd_state {
- __u32 s1, s2, s3, s4;
-};
-
-DECLARE_PER_CPU(struct rnd_state, net_rand_state);
-
-u32 prandom_u32_state(struct rnd_state *state);
-void prandom_bytes_state(struct rnd_state *state, void *buf, size_t nbytes);
-void prandom_seed_full_state(struct rnd_state __percpu *pcpu_state);
-
-#define prandom_init_once(pcpu_state) \
- DO_ONCE(prandom_seed_full_state, (pcpu_state))
-
-/**
- * prandom_u32_max - returns a pseudo-random number in interval [0, ep_ro)
- * @ep_ro: right open interval endpoint
- *
- * Returns a pseudo-random number that is in interval [0, ep_ro). Note
- * that the result depends on PRNG being well distributed in [0, ~0U]
- * u32 space. Here we use maximally equidistributed combined Tausworthe
- * generator, that is, prandom_u32(). This is useful when requesting a
- * random index of an array containing ep_ro elements, for example.
- *
- * Returns: pseudo-random number in interval [0, ep_ro)
- */
-static inline u32 prandom_u32_max(u32 ep_ro)
-{
- return (u32)(((u64) prandom_u32() * ep_ro) >> 32);
-}
-
/*
- * Handle minimum values for seeds
- */
-static inline u32 __seed(u32 x, u32 m)
-{
- return (x < m) ? x + m : x;
-}
-
-/**
- * prandom_seed_state - set seed for prandom_u32_state().
- * @state: pointer to state structure to receive the seed.
- * @seed: arbitrary 64-bit value to use as a seed.
+ * This is designed to be standalone for just prandom
+ * users, but for now we include it from <linux/random.h>
+ * for legacy reasons.
*/
-static inline void prandom_seed_state(struct rnd_state *state, u64 seed)
-{
- u32 i = (seed >> 32) ^ (seed << 10) ^ seed;
-
- state->s1 = __seed(i, 2U);
- state->s2 = __seed(i, 8U);
- state->s3 = __seed(i, 16U);
- state->s4 = __seed(i, 128U);
-}
+#include <linux/prandom.h>
#ifdef CONFIG_ARCH_RANDOM
# include <asm/archrandom.h>
@@ -195,10 +143,4 @@ static inline bool arch_has_random_seed(
}
#endif
-/* Pseudo random number generator from numerical recipes. */
-static inline u32 next_pseudo_random32(u32 seed)
-{
- return seed * 1664525 + 1013904223;
-}
-
#endif /* _LINUX_RANDOM_H */
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 4.14 7/8] ext4: fix direct I/O read error
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2020-08-05 15:53 ` [PATCH 4.14 6/8] random32: move the pseudo-random 32-bit definitions to prandom.h Greg Kroah-Hartman
@ 2020-08-05 15:53 ` Greg Kroah-Hartman
2020-08-05 15:53 ` [PATCH 4.14 8/8] ARM: 8702/1: head-common.S: Clear lr before jumping to start_kernel() Greg Kroah-Hartman
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-05 15:53 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jan Kara, Wang Long, Jiang Ying
From: Jiang Ying <jiangying8582@126.com>
This patch is used to fix ext4 direct I/O read error when
the read size is not aligned with block size.
Then, I will use a test to explain the error.
(1) Make a file that is not aligned with block size:
$dd if=/dev/zero of=./test.jar bs=1000 count=3
(2) I wrote a source file named "direct_io_read_file.c" as following:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/file.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <string.h>
#define BUF_SIZE 1024
int main()
{
int fd;
int ret;
unsigned char *buf;
ret = posix_memalign((void **)&buf, 512, BUF_SIZE);
if (ret) {
perror("posix_memalign failed");
exit(1);
}
fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755);
if (fd < 0){
perror("open ./test.jar failed");
exit(1);
}
do {
ret = read(fd, buf, BUF_SIZE);
printf("ret=%d\n",ret);
if (ret < 0) {
perror("write test.jar failed");
}
} while (ret > 0);
free(buf);
close(fd);
}
(3) Compile the source file:
$gcc direct_io_read_file.c -D_GNU_SOURCE
(4) Run the test program:
$./a.out
The result is as following:
ret=1024
ret=1024
ret=952
ret=-1
write test.jar failed: Invalid argument.
I have tested this program on XFS filesystem, XFS does not have
this problem, because XFS use iomap_dio_rw() to do direct I/O
read. And the comparing between read offset and file size is done
in iomap_dio_rw(), the code is as following:
if (pos < size) {
retval = filemap_write_and_wait_range(mapping, pos,
pos + iov_length(iov, nr_segs) - 1);
if (!retval) {
retval = mapping->a_ops->direct_IO(READ, iocb,
iov, pos, nr_segs);
}
...
}
...only when "pos < size", direct I/O can be done, or 0 will be return.
I have tested the fix patch on Ext4, it is up to the mustard of
EINVAL in man2(read) as following:
#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);
EINVAL
fd is attached to an object which is unsuitable for reading;
or the file was opened with the O_DIRECT flag, and either the
address specified in buf, the value specified in count, or the
current file offset is not suitably aligned.
So I think this patch can be applied to fix ext4 direct I/O error.
However Ext4 introduces direct I/O read using iomap infrastructure
on kernel 5.5, the patch is commit <b1b4705d54ab>
("ext4: introduce direct I/O read using iomap infrastructure"),
then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct
I/O read. So this problem does not exist on kernel 5.5 for Ext4.
>From above description, we can see this problem exists on all the kernel
versions between kernel 3.14 and kernel 5.4. It will cause the Applications
to fail to read. For example, when the search service downloads a new full
index file, the search engine is loading the previous index file and is
processing the search request, it can not use buffer io that may squeeze
the previous index file in use from pagecache, so the serch service must
use direct I/O read.
Please apply this patch on these kernel versions, or please use the method
on kernel 5.5 to fix this problem.
Fixes: 9fe55eea7e4b ("Fix race when checking i_size on direct i/o read")
Reviewed-by: Jan Kara <jack@suse.cz>
Co-developed-by: Wang Long <wanglong19@meituan.com>
Signed-off-by: Wang Long <wanglong19@meituan.com>
Signed-off-by: Jiang Ying <jiangying8582@126.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/inode.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3794,6 +3794,11 @@ static ssize_t ext4_direct_IO_read(struc
struct inode *inode = mapping->host;
size_t count = iov_iter_count(iter);
ssize_t ret;
+ loff_t offset = iocb->ki_pos;
+ loff_t size = i_size_read(inode);
+
+ if (offset >= size)
+ return 0;
/*
* Shared inode_lock is enough for us - it protects against concurrent
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 4.14 8/8] ARM: 8702/1: head-common.S: Clear lr before jumping to start_kernel()
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2020-08-05 15:53 ` [PATCH 4.14 7/8] ext4: fix direct I/O read error Greg Kroah-Hartman
@ 2020-08-05 15:53 ` Greg Kroah-Hartman
2020-08-06 10:35 ` [PATCH 4.14 0/8] 4.14.193-rc1 review Naresh Kamboju
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-05 15:53 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ard Biesheuvel, Geert Uytterhoeven,
Nicolas Pitre, Russell King, Nick Desaulniers
From: Geert Uytterhoeven <geert@linux-m68k.org>
commit 59b6359dd92d18f5dc04b14a4c926fa08ab66f7c upstream.
If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few
hundred identical messages:
unwind: Unknown symbol address c0800300
unwind: Index not found c0800300
c0800300 is the return address from the last subroutine call (to
__memzero()) in __mmap_switched(). Apparently having this address in
the link register confuses the unwinder.
To fix this, reset the link register to zero before jumping to
start_kernel().
Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
arch/arm/kernel/head-common.S | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -101,6 +101,7 @@ __mmap_switched:
str r2, [r6] @ Save atags pointer
cmp r7, #0
strne r0, [r7] @ Save control register values
+ mov lr, #0
b start_kernel
ENDPROC(__mmap_switched)
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 4.14 0/8] 4.14.193-rc1 review
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2020-08-05 15:53 ` [PATCH 4.14 8/8] ARM: 8702/1: head-common.S: Clear lr before jumping to start_kernel() Greg Kroah-Hartman
@ 2020-08-06 10:35 ` Naresh Kamboju
2020-08-06 18:57 ` Guenter Roeck
2020-08-06 19:34 ` Shuah Khan
10 siblings, 0 replies; 12+ messages in thread
From: Naresh Kamboju @ 2020-08-06 10:35 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Shuah Khan, patches, lkft-triage, Ben Hutchings,
linux- stable, Andrew Morton, Linus Torvalds, Guenter Roeck
On Wed, 5 Aug 2020 at 21:23, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.14.193 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 07 Aug 2020 15:34:53 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.193-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.14.193-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: e8ffd3efac224a0f72ae9ddffc0522f6b2e169ba
git describe: v4.14.192-9-ge8ffd3efac22
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.192-9-ge8ffd3efac22
No regressions (compared to build v4.14.191-57-ge8ffd3efac22)
No fixes (compared to build v4.14.191-57-ge8ffd3efac22)
Ran 25279 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan
Test Suites
-----------
* build
* igt-gpu-tools
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* libhugetlbfs
* linux-log-parser
* ltp-commands-tests
* ltp-containers-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* v4l2-compliance
* kvm-unit-tests
* ltp-cap_bounds-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-ipc-tests
* ltp-mm-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* ssuite
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 4.14 0/8] 4.14.193-rc1 review
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2020-08-06 10:35 ` [PATCH 4.14 0/8] 4.14.193-rc1 review Naresh Kamboju
@ 2020-08-06 18:57 ` Guenter Roeck
2020-08-06 19:34 ` Shuah Khan
10 siblings, 0 replies; 12+ messages in thread
From: Guenter Roeck @ 2020-08-06 18:57 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Wed, Aug 05, 2020 at 05:53:26PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.193 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 07 Aug 2020 15:34:53 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 171 pass: 171 fail: 0
Qemu test results:
total: 407 pass: 407 fail: 0
Guenter
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 4.14 0/8] 4.14.193-rc1 review
2020-08-05 15:53 [PATCH 4.14 0/8] 4.14.193-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2020-08-06 18:57 ` Guenter Roeck
@ 2020-08-06 19:34 ` Shuah Khan
10 siblings, 0 replies; 12+ messages in thread
From: Shuah Khan @ 2020-08-06 19:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, skhan
On 8/5/20 9:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.193 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 07 Aug 2020 15:34:53 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.193-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 12+ messages in thread