[RFC PATCH] bit_spinlock: introduce smp_cond_load_relaxed
It is better to use smp_cond_load_relaxed instead
of busy waiting for bit_spinlock.
Signed-off-by: Gao Xiang
---
include/linux/bit_spinlock.h | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/include/linux/bit_spinlock.h b/include/linux/bit_spinlock.h
index bbc4730..713efc4 100644
--- a/include/linux/bit_spinlock.h
+++ b/include/linux/bit_spinlock.h
@@ -15,22 +15,17 @@
*/
static inline void bit_spin_lock(int bitnum, unsigned long *addr)
{
- /*
-* Assuming the lock is uncontended, this never enters
-* the body of the outer loop. If it is contended, then
-* within the inner loop a non-atomic test is used to
-* busywait with less bus contention for a good time to
-* attempt to acquire the lock bit.
-*/
- preempt_disable();
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
- while (unlikely(test_and_set_bit_lock(bitnum, addr))) {
- preempt_enable();
- do {
- cpu_relax();
- } while (test_bit(bitnum, addr));
+ while (1) {
+ smp_cond_load_relaxed(&addr[BIT_WORD(bitnum)],
+ !(VAL >> (bitnum & (BITS_PER_LONG-1;
preempt_disable();
+ if (!test_and_set_bit_lock(bitnum, addr))
+ break;
+ preempt_enable();
}
+#else
+ preempt_disable();
#endif
__acquire(bitlock);
}
--
2.7.4
Re: [PATCH 3.18 000/120] 3.18.124-stable review
On Fri, Oct 12, 2018 at 10:07:09AM -0700, Nathan Chancellor wrote: > On Thu, Oct 11, 2018 at 05:33:01PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.124 release. > > There are 120 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 Sat Oct 13 15:25:29 UTC 2018. > > 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/v3.x/stable-review/patch-3.18.124-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-3.18.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Merged, compiled with -Werror, and installed onto my Pixel XL. > > No initial issues noticed in dmesg or general usage. Thanks for testing 3 of these and letting me know. greg k-h
Re: [PATCH 3.18 000/120] 3.18.124-stable review
On Fri, Oct 12, 2018 at 01:24:52PM -0700, Guenter Roeck wrote: > On Thu, Oct 11, 2018 at 05:33:01PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.124 release. > > There are 120 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 Sat Oct 13 15:25:29 UTC 2018. > > Anything received after that time might be too late. > > > > For v3.18.123-122-gfaa00f6cbce8: > > Build results: > total: 138 pass: 138 fail: 0 > Qemu test results: > total: 221 pass: 221 fail: 0 > > Details are available at https://kerneltests.org/builders/. Great, thanks for testing all of these and letting me know the issues. greg k-h
Re: [PATCH] kernel/signal: Signal-based pre-coredump notification
On Fri, Oct 12, 2018 at 05:33:35PM -0700, Enke Chen wrote: > For simplicity and consistency, this patch provides an implementation > for signal-based fault notification prior to the coredump of a child > process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can > be used by an application to express its interest and to specify the > signal (SIGCHLD or SIGUSR1 or SIGUSR2) for such a notification. A new > signal code (si_code), CLD_PREDUMP, is also defined for SIGCHLD. > > Background: > > As the coredump of a process may take time, in certain time-sensitive > applications it is necessary for a parent process (e.g., a process > manager) to be notified of a child's imminent death before the coredump > so that the parent process can act sooner, such as re-spawning an > application process, or initiating a control-plane fail-over. > > Currently there are two ways for a parent process to be notified of a > child process's state change. One is to use the POSIX signal, and > another is to use the kernel connector module. The specific events and > actions are summarized as follows: > > Process EventPOSIX SignalConnector-based > -- > ptrace_attach() do_notify_parent_cldstop() proc_ptrace_connector() > SIGCHLD / CLD_STOPPED > > ptrace_detach() do_notify_parent_cldstop() proc_ptrace_connector() > SIGCHLD / CLD_CONTINUED > > pre_coredump/N/A proc_coredump_connector() > get_signal() > > post_coredump/ do_notify_parent() proc_exit_connector() > do_exit()SIGCHLD / exit_signal > -- > > As shown in the table, the signal-based pre-coredump notification is not > currently available. In some cases using a connector-based notification > can be quite complicated (e.g., when a process manager is written in shell > scripts and thus is subject to certain inherent limitations), and a > signal-based notification would be simpler and better suited. > > Signed-off-by: Enke Chen > --- > arch/x86/kernel/signal_compat.c| 2 +- > include/linux/sched.h | 4 ++ > include/linux/signal.h | 5 +++ > include/uapi/asm-generic/siginfo.h | 3 +- > include/uapi/linux/prctl.h | 4 ++ > kernel/fork.c | 1 + > kernel/signal.c| 51 + > kernel/sys.c | 77 > ++ > 8 files changed, 145 insertions(+), 2 deletions(-) Shouldn't there also be a manpage update, and a kselftest added for this new user/kernel api that is being created? thanks, greg k-h
Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]
On Fri, Oct 12, 2018 at 03:49:50PM +0100, Alan Jenkins wrote:
> > +SYSCALL_DEFINE3(fspick, int, dfd, const char __user *, path, unsigned int,
> > flags)
> > +{
> > + struct fs_context *fc;
> > + struct path target;
> > + unsigned int lookup_flags;
> > + int ret;
> > +
> > + if (!ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN))
> > + return -EPERM;
>
>
> This seems to accept basically any mount. Specifically: are you sure it's
> OK to return a handle to a SB_NO_USER superblock?
Umm... As long as we don't try to do pathname resolution from its ->s_root,
shouldn't be a problem and I don't see anything that would do that. I might've
missed something, but...
Re: [PATCH V8 16/21] csky: SMP support
Hi Marc,
Thx for the review.
On Fri, Oct 12, 2018 at 12:09:52PM +0100, Marc Zyngier wrote:
> On 12/10/18 05:42, Guo Ren wrote:
> > This patch adds boot, ipi, hotplug code for SMP.
> > +static struct {
> > + unsigned long bits cacheline_aligned;
> > +} ipi_data[NR_CPUS] __cacheline_aligned;
>
> Why isn't this a per-cpu variable?
Ok, use per-cpu.
> > +void *__cpu_up_stack_pointer[NR_CPUS];
> > +void *__cpu_up_task_pointer[NR_CPUS];
>
> Why aren't these per-cpu variables? More importantly, what are they used
> for? None of the patches in this series are using them.
No use at all, remove them :-P
> > +void __init enable_smp_ipi(void)
> > +{
> > + enable_percpu_irq(ipi_irq, 0);
> > +}
>
> Why isn't this function static?
Ok, static. and remove the declaration in asm/smp.h
> > +volatile unsigned int secondary_hint;
> > +volatile unsigned int secondary_ccr;
> > +volatile unsigned int secondary_stack;
>
> This looks pretty dodgy.
It's not dodgy. They are used to pass hint,ccr,sp regs value for
seconardy CPU in smp.c:csky_start_secondary().
> Shouldn't you be using READ_ONCE/WRITE_ONCE instead?
The most problem is all other CPUs is in reset state not running and
CIU just fake signal for MESI. So we must flush all data into the
DRAM/L2cache. When secondary CPUs bootup from reset, they could see
right value in RAM.
So barrier is no use at all, we must flush dcache here and I'll add a
comment for explain.
Here is my modification with your feedback:
diff --git a/arch/csky/kernel/smp.c b/arch/csky/kernel/smp.c
index 5ea9516..36ebaf9 100644
--- a/arch/csky/kernel/smp.c
+++ b/arch/csky/kernel/smp.c
@@ -22,9 +22,10 @@
#include
#include
-static struct {
+struct ipi_data_struct {
unsigned long bits cacheline_aligned;
-} ipi_data[NR_CPUS] __cacheline_aligned;
+};
+static DEFINE_PER_CPU(struct ipi_data_struct, ipi_data);
enum ipi_message_type {
IPI_EMPTY,
@@ -35,12 +36,10 @@ enum ipi_message_type {
static irqreturn_t handle_ipi(int irq, void *dev)
{
- unsigned long *pending_ipis = &ipi_data[smp_processor_id()].bits;
-
while (true) {
unsigned long ops;
- ops = xchg(pending_ipis, 0);
+ ops = xchg(&this_cpu_ptr(&ipi_data)->bits, 0);
if (ops == 0)
return IRQ_HANDLED;
@@ -74,7 +73,7 @@ send_ipi_message(const struct cpumask *to_whom, enum
ipi_message_type operation)
int i;
for_each_cpu(i, to_whom)
- set_bit(operation, &ipi_data[i].bits);
+ set_bit(operation, &per_cpu_ptr(&ipi_data, i)->bits);
smp_mb();
send_arch_ipi(to_whom);
@@ -105,9 +104,6 @@ void smp_send_reschedule(int cpu)
send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
}
-void *__cpu_up_stack_pointer[NR_CPUS];
-void *__cpu_up_task_pointer[NR_CPUS];
-
void __init smp_prepare_boot_cpu(void)
{
}
@@ -116,7 +112,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
{
}
-void __init enable_smp_ipi(void)
+static void __init enable_smp_ipi(void)
{
enable_percpu_irq(ipi_irq, 0);
}
@@ -173,7 +169,11 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
secondary_ccr = mfcr("cr18");
- /* Flush dcache */
+ /*
+* Because other CPUs are in reset status, we must flush data
+* from cache to out and secondary CPUs use them in
+* csky_start_secondary(void)
+*/
mtcr("cr17", 0x22);
/* Enable cpu in SMP reset ctrl reg */
Best Regards
Guo Ren
Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]
On Thu, Oct 11, 2018 at 09:17:54PM +0100, David Howells wrote:
> +/*
> + * Object if there are any nsfs mounts in the specified subtree. These can
> act
> + * as pins for mount namespaces that aren't checked by the mount-cycle
> checking
> + * code, thereby allowing cycles to be made.
> + */
> +static bool check_for_nsfs_mounts(struct mount *subtree)
> +{
> + struct mount *p;
> + bool ret = false;
> +
> + lock_mount_hash();
> + for (p = subtree; p; p = next_mnt(p, subtree))
> + if (mnt_ns_loop(p->mnt.mnt_root))
> + goto out;
> +
> + ret = true;
> +out:
> + unlock_mount_hash();
> + return ret;
> +}
Umm... The comment doesn't match the behaviour - you are
accepting references to later namespaces. Behaviour is
not a problem, the comment is.
Re: [PATCH v2 2/2] mtd: rawnand: ams-delta: Use ->exec_op()
Hi Janusz,
On Fri, 12 Oct 2018 22:41:01 +0200
Janusz Krzysztofik wrote:
> Replace legacy callbacks with ->select_chip() and ->exec_op().
>
> In order to remove any references to legacy structure members, use of
> .IO_ADDR_R/W has been replaced wit runtime calculations based on
^ with
> priv->io_base.
Can we do that in 2 steps?
1/ Stop using .IO_ADDR_R/W
2/ Convert the driver to ->exec_op()
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Janusz Krzysztofik
> ---
[...]
> -static int ams_delta_nand_ready(struct nand_chip *this)
> +static int ams_delta_exec_op(struct nand_chip *this,
> + const struct nand_operation *op, bool check_only)
> {
> struct ams_delta_nand *priv = nand_get_controller_data(this);
> + const struct nand_op_instr *instr;
> + int ret = 0;
> +
You should have:
if (check_only)
return 0;
Other than that, the conversion looks good, so you can add
Reviewed-by: Boris Brezillon once you've
addressed my comments.
Regards,
Boris
> + for (instr = op->instrs; instr < op->instrs + op->ninstrs; instr++) {
> +
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + gpiod_set_value(priv->gpiod_cle, 1);
> + ams_delta_write_buf(priv, &instr->ctx.cmd.opcode, 1);
> + gpiod_set_value(priv->gpiod_cle, 0);
> + break;
> +
> + case NAND_OP_ADDR_INSTR:
> + gpiod_set_value(priv->gpiod_ale, 1);
> + ams_delta_write_buf(priv, instr->ctx.addr.addrs,
> + instr->ctx.addr.naddrs);
> + gpiod_set_value(priv->gpiod_ale, 0);
> + break;
> +
> + case NAND_OP_DATA_IN_INSTR:
> + ams_delta_read_buf(priv, instr->ctx.data.buf.in,
> +instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_DATA_OUT_INSTR:
> + ams_delta_write_buf(priv, instr->ctx.data.buf.out,
> + instr->ctx.data.len);
> + break;
> +
> + case NAND_OP_WAITRDY_INSTR:
> + ret = priv->gpiod_rdy ?
> + nand_gpio_waitrdy(this, priv->gpiod_rdy,
> + instr->ctx.waitrdy.timeout_ms) :
> + nand_soft_waitrdy(this,
> + instr->ctx.waitrdy.timeout_ms);
> + break;
> + }
> +
> + if (ret)
> + break;
> + }
>
> - return gpiod_get_value(priv->gpiod_rdy);
> + return ret;
> }
Re: [PATCH v2 1/2] mtd: rawnand: Provide helper for polling GPIO R/B pin
Hi Janusz,
On Fri, 12 Oct 2018 22:41:00 +0200
Janusz Krzysztofik wrote:
> Each controller driver with access to NAND R/B pin over GPIO would have
> to reimplement the polling loop otherwise.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> Changelog:
> v2:
> New patch - v1 consisted of only one patch (the followning one)
>
>
> drivers/mtd/nand/raw/nand_base.c | 38 ++
> include/linux/mtd/rawnand.h | 10 ++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index 05bd0779fe9b..ff1ac4a3c647 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -45,6 +45,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_GPIOLIB
> +#include
> +#endif
The ifdef is not needed here, linux/gpio/consumer.h already has dummy
wrappers when CONFIG_GPIOLIB is not enabled.
>
> #include "internals.h"
>
> @@ -531,6 +534,41 @@ int nand_soft_waitrdy(struct nand_chip *chip, unsigned
> long timeout_ms)
> };
> EXPORT_SYMBOL_GPL(nand_soft_waitrdy);
>
> +#ifdef CONFIG_GPIOLIB
> +/**
> + * nand_gpio_waitrdy - Poll R/B GPIO pin until ready
> + * @chip: NAND chip structure
> + * @gpiod: GPIO descriptor of R/B pin
> + * @timeout_ms: Timeout in ms
> + *
> + * Poll the R/B GPIO pin until it becomes ready. If that does not happen
> + * whitin the specified timeout, -ETIMEDOUT is returned.
> + *
> + * This helper is intended to be used when the controller has access to the
> + * NAND R/B pin over GPIO.
> + *
> + * Be aware that calling this helper from an ->exec_op() implementation means
> + * ->exec_op() must be re-entrant.
This is not true for this function: it does not call nand_exec_op().
> + *
> + * Return 0 if the R/B pin indicates chip is ready, a negative error
> otherwise.
> + */
> +int nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod,
> + unsigned long timeout_ms)
> +{
> + /* Wait until command is processed or timeout occurs */
> + timeout_ms = jiffies + msecs_to_jiffies(timeout_ms);
> + do {
> + if (gpiod_get_value_cansleep(gpiod))
> + return 0;
> +
> + cond_resched();
> + } while (time_before(jiffies, timeout_ms));
> +
> + return gpiod_get_value_cansleep(gpiod) ? 0 : -ETIMEDOUT;
> +};
> +EXPORT_SYMBOL_GPL(nand_gpio_waitrdy);
> +#endif
Hm, I don't see any other helpers defined in #ifdef blocks though most
of them are optionals and are most of the time not used by drivers.
Let's keep things consistent (at the expense of embedding unused code
in nand.o) and remove the #ifdef here. If someone starts complaining
about the size of the rawnand core, we'll consider doing that.
> +
> /**
> * panic_nand_get_device - [GENERIC] Get chip for selected access
> * @chip: the nand chip descriptor
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index e10b126e148f..09f0ed1345b1 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -1346,4 +1346,14 @@ void nand_release(struct nand_chip *chip);
> */
> int nand_soft_waitrdy(struct nand_chip *chip, unsigned long timeout_ms);
>
> +#ifdef CONFIG_GPIOLIB
> +struct gpio_desc;
> +/*
> + * External helper for controller drivers that have to implement the WAITRDY
> + * instruction and do have GPIO pin to check it.
> + */
You can drop this comment, this is already explained in the kerneldoc
header above the function def.
> +int nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod,
> + unsigned long timeout_ms);
> +#endif
> +
> #endif /* __LINUX_MTD_RAWNAND_H */
Regards,
Boris
Re: [PATCH 09/50] amiserial: switch to ->[sg]et_serial()
On Thu, Oct 11, 2018 at 07:58:28PM +0200, Geert Uytterhoeven wrote: > drivers/tty/amiserial.c:1076:3: error: 'retval' undeclared (first use > in this function) > > http://kisskb.ellerman.id.au/kisskb/buildresult/13544535/ > http://kisskb.ellerman.id.au/kisskb/buildresult/13544413/ Fixed and folded.
[PATCH v2] MAINTAINERS: Clarify UIO vs UIOVEC maintainer
The UIO file mask in MAINTAINERS was incorrectly directing UIOVEC (include/linux/uio.h) patches to Greg. Tag Al as the UIOVEC maintainer as Ingo and others have explicitly required his ack before taking architecture patches that touch lib/iov_iter.c. Cc: Al Viro Reported-by: Greg Kroah-Hartman Signed-off-by: Dan Williams --- Changes in v2: * Rename UACCESS to UIOVEC MAINTAINERS |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d870cb57c887..c1841d58d7ae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15344,13 +15344,19 @@ F:arch/x86/um/ F: fs/hostfs/ F: fs/hppfs/ +USERSPACE COPYIN/COPYOUT (UIOVEC) +M: Alexander Viro +S: Maintained +F: lib/iov_iter.c +F: include/linux/uio.h + USERSPACE I/O (UIO) M: Greg Kroah-Hartman S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git F: Documentation/driver-api/uio-howto.rst F: drivers/uio/ -F: include/linux/uio*.h +F: include/linux/uio_driver.h UTIL-LINUX PACKAGE M: Karel Zak
[PATCH v4] printk: Add line-buffered printk() API.
Sometimes we want to print a whole line without being disturbed by
concurrent printk() from interrupts and/or other threads, for printk()
which does not end with '\n' can be disturbed.
Mixed printk() output makes it hard to interpret. Assuming that we will go
to a direction that we allow prefixing context identifier to each line of
printk() output (so that we can group multiple lines into one block when
parsing), this patch introduces API for line-buffered printk() output
(so that we can make sure that printk() ends with '\n').
Since functions introduced by this patch are merely wrapping
printk()/vprintk() calls in order to minimize possibility of using
"struct cont", it is safe to replace printk()/vprintk() with this API.
Details:
A structure named "struct printk_buffer" is introduced for buffering
up to LOG_LINE_MAX bytes of printk() output which did not end with '\n'.
get_printk_buffer() tries to assign a "struct printk_buffer" from
statically preallocated array. get_printk_buffer() returns NULL if
all "struct printk_buffer" are in use, but the caller does not need to
check for NULL.
put_printk_buffer() flushes and releases the "struct printk_buffer".
put_printk_buffer() must match corresponding get_printk_buffer() as with
rcu_read_unlock() must match corresponding rcu_read_lock().
Three functions buffered_vprintk(), buffered_printk() and
flush_printk_buffer() are provided for using "struct printk_buffer".
These are like vfprintf(), fprintf(), fflush() except that these receive
"struct printk_buffer *" for the first argument.
buffered_vprintk() and buffered_printk() behave like vprintk() and
printk() respectively if "struct printk_buffer *" argument is NULL.
flush_printk_buffer() and put_printk_buffer() become no-op if
"struct printk_buffer *" argument is NULL. Therefore, the caller of
get_printk_buffer() does not need to check for NULL.
How to configure this API:
For those who want to save memory footprint, this API is enabled only
if CONFIG_PRINTK_LINE_BUFFERED option is selected.
For those who want to tune the number of statically preallocated
buffers, CONFIG_PRINTK_NUM_LINE_BUFFERS option is available. The default
value is 16. Since "struct printk_buffer" makes difference only when
there are multiple threads concurrently calling printk() which does not
end with '\n', and this API will fallback to normal printk() when all
CONFIG_PRINTK_NUM_LINE_BUFFERS buffers are in use, you won't need to
specify a large number.
But somebody might forget to call put_printk_buffer(). For those who
want to know why all CONFIG_PRINTK_NUM_LINE_BUFFERS buffers are in use,
CONFIG_PRINTK_REPORT_OUT_OF_LINE_BUFFERS option is available.
This option reports when/where get_printk_buffer() was called and
put_printk_buffer() is not yet called, up to once per a minute.
How to use this API:
(1) Call get_printk_buffer() and acquire "struct printk_buffer *".
(2) Rewrite printk() calls in the following way. The "ptr" is
"struct printk_buffer *" obtained in step (1).
printk(fmt, ...) => buffered_printk(ptr, fmt, ...)
vprintk(fmt, args) => buffered_vprintk(ptr, fmt, args)
pr_emerg(fmt, ...) => bpr_emerg(ptr, fmt, ...)
pr_alert(fmt, ...) => bpr_alert(ptr, fmt, ...)
pr_crit(fmt, ...)=> bpr_crit(ptr, fmt, ...)
pr_err(fmt, ...) => bpr_err(ptr, fmt, ...)
pr_warning(fmt, ...) => bpr_warning(ptr, fmt, ...)
pr_warn(fmt, ...)=> bpr_warn(ptr, fmt, ...)
pr_notice(fmt, ...) => bpr_notice(ptr, fmt, ...)
pr_info(fmt, ...)=> bpr_info(ptr, fmt, ...)
pr_cont(fmt, ...)=> bpr_cont(ptr, fmt, ...)
(3) Release "struct printk_buffer" by calling put_printk_buffer().
Note that since "struct printk_buffer" buffers only up to one line, there
is no need to rewrite if it is known that the "struct printk_buffer" is
empty and printk() ends with '\n'.
Good example:
printk("Hello ");=> buf = get_printk_buffer();
pr_cont("world.\n"); buffered_printk(buf, "Hello ");
buffered_printk(buf, "world.\n");
put_printk_buffer(buf);
Pointless example:
printk("Hello\n"); => buf = get_printk_buffer();
printk("World.\n"); buffered_printk(buf, "Hello\n");
buffered_printk(buf, "World.\n");
put_printk_buffer(buf);
Note that bpr_devel() and bpr_debug() are not defined. This is
because pr_devel()/pr_debug() should not be followed by pr_cont()
because pr_devel()/pr_debug() are conditionally enabled; output from
pr_devel()/pr_debug() should always end with '\n'.
Signed-off-by: Tetsuo Handa
---
include/linux/printk.h | 41 +
init/Kconfig | 31 +++
kernel/printk/printk.c | 239 +
3 files changed, 311 insertions(+)
diff --git a/include/linux/printk.h b/include/linux/printk.h
Re: [resend PATCH] MAINTAINERS: Clarify UIO vs UACCESS maintainer
On Mon, Oct 08, 2018 at 11:50:09AM -0700, Dan Williams wrote: > The UIO file mask in MAINTAINERS was incorrectly directing UACCESS > (include/linux/uio.h) patches to Greg. > > Tag Al as the UACCESS maintainer as Ingo and others have explicitly > required his ack before taking architecture patches that touch > lib/iov_iter.c. > > Cc: Al Viro > Reported-by: Greg Kroah-Hartman > Acked-by: Greg Kroah-Hartman > Signed-off-by: Dan Williams > --- > I got a bounce last time I tried to send this, hopefully the situation > has improved now. > > Al, let me know if you want this entry. Alternatively we can just do the > UIO file mask fixup by itself. Sure, no problem, except that UACCESS refers to different things. I'd probably call it UIOVEC, if we want a name that does refer to the same somewhere (*BSD). If anything, it's generalization of copyin/copyout for non-userland destinations/sources; uaccess answer to (subset of) the same problem would be set_fs()/get_fs() and the fewer we have left of that, the better...
Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count
On Thu, Oct 11, 2018 at 11:00:12PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Add two struct page fields that, combined, are unioned with
> struct page->lru. There is no change in the size of
> struct page. These new fields are for type safety and clarity.
>
> Also add page flag accessors to test, set and clear the new
> page->dma_pinned_flags field.
>
> The page->dma_pinned_count field will be used in upcoming
> patches
>
> Signed-off-by: John Hubbard
> ---
> include/linux/mm_types.h | 22 +-
> include/linux/page-flags.h | 47 ++
> 2 files changed, 63 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 5ed8f6292a53..017ab82e36ca 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -78,12 +78,22 @@ struct page {
>*/
> union {
> struct {/* Page cache and anonymous pages */
> - /**
> - * @lru: Pageout list, eg. active_list protected by
> - * zone_lru_lock. Sometimes used as a generic list
> - * by the page owner.
> - */
> - struct list_head lru;
> + union {
> + /**
> + * @lru: Pageout list, eg. active_list protected
> + * by zone_lru_lock. Sometimes used as a
> + * generic list by the page owner.
> + */
> + struct list_head lru;
> + /* Used by get_user_pages*(). Pages may not be
> + * on an LRU while these dma_pinned_* fields
> + * are in use.
> + */
> + struct {
> + unsigned long dma_pinned_flags;
> + atomic_t dma_pinned_count;
> + };
> + };
Isn't this broken for mapped file-backed pages? i.e. they may be
passed as the user buffer to read/write direct IO and so the pages
passed to gup will be on the active/inactive LRUs. hence I can't see
how you can have dual use of the LRU list head like this
What am I missing here?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
[PATCH -next] gpio: fix SNPS_CREG kconfig dependency warning
From: Randy Dunlap Fix kconfig warning for GPIO_SNPS_CREG: WARNING: unmet direct dependencies detected for OF_GPIO Depends on [n]: GPIOLIB [=y] && OF [=n] && HAS_IOMEM [=y] Selected by [y]: - GPIO_SNPS_CREG [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && (ARC || COMPILE_TEST [=y]) Drivers in drivers/gpio/Kconfig depend on OF_GPIO, not select it. This prevents attempting to build when OF is not enabled. Signed-off-by: Randy Dunlap Cc: Linus Walleij Cc: linux-g...@vger.kernel.org Cc: Eugeniy Paltsev --- Found in mmotm but comes from/applies to linux-next. drivers/gpio/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20181012.orig/drivers/gpio/Kconfig +++ linux-next-20181012/drivers/gpio/Kconfig @@ -439,7 +439,7 @@ config GPIO_SIOX config GPIO_SNPS_CREG bool "Synopsys GPIO via CREG (Control REGisters) driver" depends on ARC || COMPILE_TEST - select OF_GPIO + depends on OF_GPIO help This driver supports GPIOs via CREG on various Synopsys SoCs. This is a single-register MMIO GPIO driver for complex cases
Re: [PATCH v4 1/2] arm64: dts: allwinner: new board - Emlid Neutis N5
On Sat, Oct 13, 2018 at 4:23 AM Maxime Ripard wrote:
>
> On Fri, Oct 12, 2018 at 04:39:14PM +0300, Aleksandr Aleksandrov wrote:
> > Hi Andreas,
> >
> > Thanks for your feedback!
> >
> > > > + *
> > > > + * Copyright (C) 2018 Aleksandr Aleksandrov
> > > >
> > > > + */
> > > > +
> > > > +/dts-v1/;
> > > > +
> > > > +#include "sun50i-h5-emlid-neutis-n5.dtsi"
> > > > +
> > > > +/ {
> > > > + model = "Emlid Neutis N5 Developer board";
> > > > + compatible = "emlid,neutis-n5-devboard",
> > > > + "emlid,neutis-n5",
> > >
> > > You are lacking bindings definitions for these new identifiers. The
> > > vendor prefix should be patch 1/3, the SoM/board compatibles 2/3 and
> > > this .dts[i] patch 3/3, so that only vendor prefixes and compatibles
> > > that are defined and don't result in checkpatch.pl warnings get used.
> >
> > Patch 2/3:
> >
> > commit 46dcb8632b36644cb20e6b35ede12ff0088a60eb
> > Author: Aleksandr Aleksandrov
> > Date: Fri Oct 12 16:22:28 2018 +0300
> >
> > dt-bindings: arm: sunxi: emlid,neutis-n5(-devboard)
> >
> > sunxi: add new compatibles for Emlid Neutis Dev board and SoM module
> >
> > Signed-off-by: Aleksandr Aleksandrov
> >
> > diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
> > b/Documentation/devicetree/bindings/arm/sunxi.txt
> > index e4beec3..a907e52 100644
> > --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> > +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> > @@ -19,3 +19,5 @@ using one of the following compatible strings:
> >allwinner,sun9i-a80
> >allwinner,sun50i-a64
> >nextthing,gr8
> > + emlid,neutis-n5
> > + emlid,neutis-n5-devboard
> >
> > Is this right place for the neutis compatibles?
>
> No, those are for SoCs compatible. I'm not sure we ever created a
> board compatible files.
We never did. We don't even have all vendor prefixes in, only the ones
that seem more popular, and actually have an identifiable website.
ChenYu
RE: [PATCH v1] KVM/x86/vPMU: Guest PMI Optimization
On Saturday, October 13, 2018 12:31 AM, Andi Kleen wrote: > > 4. Results > > - Without this optimization, the guest pmi handling time is > > ~450 ns, and the max sampling rate is reduced to 250. > > - With this optimization, the guest pmi handling time is ~9000 ns > > (i.e. 1 / 500 of the non-optimization case), and the max sampling > > rate remains at the original 10. > > Impressive performance improvement! > > It's not clear to me why you're special casing PMIs here. The optimization > should work generically, right? Yes, seems doable. I plan to try some lazy approach for the perf event allocation. > Is that guaranteed to be always called on the right CPU that will run the > vcpu? > > AFAIK there's an ioctl to set MSRs in the guest from qemu, I'm pretty sure it > won't handle that. Thanks, will consider that case. Best, Wei
[PATCH] selftests/ftrace: Add color to the PASS / FAIL results
From: Steven Rostedt (VMware)
Now that ftracetest has over 80 tests, it is difficult to simply scroll
up the console window to find the failed tests when it reports just two
tests have failed. In order to make this stand out better, have the
color of the word "PASS" be green, "FAIL" and "XFAIL" be red, and all
other results be blue. This helps tremendously in quickly spotting the
failed tests by just scrolling up the console window.
Signed-off-by: Steven Rostedt (VMware)
---
diff --git a/tools/testing/selftests/ftrace/ftracetest
b/tools/testing/selftests/ftrace/ftracetest
index 5c71d58..4946b2e 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -153,7 +153,7 @@ else
fi
prlog() { # messages
- [ -z "$LOG_FILE" ] && echo "$@" || echo "$@" | tee -a $LOG_FILE
+ [ -z "$LOG_FILE" ] && echo -e "$@" || echo -e "$@" | tee -a $LOG_FILE
}
catlog() { #file
[ -z "$LOG_FILE" ] && cat $1 || cat $1 | tee -a $LOG_FILE
@@ -195,37 +195,37 @@ test_on_instance() { # testfile
eval_result() { # sigval
case $1 in
$PASS)
- prlog " [PASS]"
+ prlog " [\e[32mPASS\e[30m]"
PASSED_CASES="$PASSED_CASES $CASENO"
return 0
;;
$FAIL)
- prlog " [FAIL]"
+ prlog " [\e[31mFAIL\e[30m]"
FAILED_CASES="$FAILED_CASES $CASENO"
return 1 # this is a bug.
;;
$UNRESOLVED)
- prlog " [UNRESOLVED]"
+ prlog " [\e[34mUNRESOLVED\e[30m]"
UNRESOLVED_CASES="$UNRESOLVED_CASES $CASENO"
return 1 # this is a kind of bug.. something happened.
;;
$UNTESTED)
- prlog " [UNTESTED]"
+ prlog " [\e[34mUNTESTED\e[30m]"
UNTESTED_CASES="$UNTESTED_CASES $CASENO"
return 0
;;
$UNSUPPORTED)
- prlog " [UNSUPPORTED]"
+ prlog " [\e[34mUNSUPPORTED\e[30m]"
UNSUPPORTED_CASES="$UNSUPPORTED_CASES $CASENO"
return $UNSUPPORTED_RESULT # depends on use case
;;
$XFAIL)
- prlog " [XFAIL]"
+ prlog " [\e[31mXFAIL\e[30m]"
XFAILED_CASES="$XFAILED_CASES $CASENO"
return 0
;;
*)
- prlog " [UNDEFINED]"
+ prlog " [\e[34mUNDEFINED\e[30m]"
UNDEFINED_CASES="$UNDEFINED_CASES $CASENO"
return 1 # this must be a test bug
;;
mmotm 2018-10-12-19-18 uploaded
The mm-of-the-moment snapshot 2018-10-12-19-18 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (4.x or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 4.19-rc7: (patches marked "*" will be included in linux-next) origin.patch * ocfs2-fix-a-gcc-compiled-warning.patch * mm-dont-clobber-partially-overlapping-vma-with-map_fixed_noreplace.patch * mm-thp-fix-call-to-mmu_notifier-in-set_pmd_migration_entry-v2.patch * fs-fat-add-cond_resched-to-fat_count_free_clusters.patch * mm-thp-always-specify-disabled-vmas-as-nh-in-smaps.patch * mm-thp-relax-__gfp_thisnode-for-madv_hugepage-mappings.patch * arm-arch-arm-include-asm-pageh-needs-personalityh.patch * linkageh-align-weak-symbols.patch * arm64-lib-use-c-string-functions-with-kasan-enabled.patch * lib-test_kasan-add-tests-for-several-string-memory-api-functions.patch * scripts-tags-add-declare_hashtable.patch * ocfs2-dlm-remove-unnecessary-parentheses.patch * ocfs2-remove-unused-pointer-eb.patch * ocfs2-fix-unneeded-null-check.patch * fs-ocfs2-dlm-fix-a-sleep-in-atomic-context-bug-in-dlm_print_one_mle.patch * ocfs2-remove-set-but-not-used-variable-rb.patch * ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch * ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery.patch * ocfs2-dont-use-iocb-when-eiocbqueued-returns.patch * ocfs2-fix-a-misuse-a-of-brelse-after-failing-ocfs2_check_dir_entry.patch * ocfs2-dont-put-and-assigning-null-to-bh-allocated-outside.patch * ocfs2-dlmglue-clean-up-timestamp-handling.patch * fix-dead-lock-caused-by-ocfs2_defrag_extent.patch * ocfs2-fix-dead-lock-caused-by-ocfs2_defrag_extent.patch * fix-clusters-leak-in-ocfs2_defrag_extent.patch * fix-clusters-leak-in-ocfs2_defrag_extent-fix.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch * vfs-allow-dedupe-of-user-owned-read-only-files.patch * vfs-dedupe-should-return-eperm-if-permission-is-not-granted.patch * fs-iomap-change-return-type-to-vm_fault_t.patch * xtensa-use-generic-vgah.patch mm.patch * mm-slubc-switch-to-bitmap_zalloc.patch * mm-dont-warn-about-large-allocations-for-slab.patch * slub-extend-slub-debug-to-handle-multiple-slabs.patch * mm-rework-memcg-kernel-stack-accounting.patch * mm-drain-memcg-stocks-on-css-offlining.patch * mm-dont-miss-the-last-page-because-of-round-off-error.patch * mm-dont-miss-the-last-page-because-of-round-off-error-fix.patch * mmpage_alloc-pf_wq_worker-threads-must-sleep-at-should_reclaim_retry.patch * mmpage_alloc-pf_wq_worker-threads-must-sleep-at-should_reclaim_retry-fix.patch * mm-mmu_notifier-be-explicit-about-range-invalition-non-blocking-mode.patch * revert-mm-mmu_notifier-annotate-mmu-notifiers-with-blockable-invalidate-callbacks.patch * kmemleak-add-module-param-to-print-warnings-to-
Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration
Hi Mathieu, I love your patch! Yet something to improve: [auto build test ERROR on tip/perf/core] [also build test ERROR on v4.19-rc7 next-20181012] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mathieu-Desnoyers/tracepoint-Fix-out-of-bound-tracepoint-array-iteration/20181013-073410 config: arm-allyesconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm All errors (new ones prefixed by >>): In file included from drivers/media/media-devnode.c:33:0: >> include/linux/module.h:433:2: error: unknown type name 'tracepoint_ptr_t' tracepoint_ptr_t *tracepoints_ptrs; ^~~~ vim +/tracepoint_ptr_t +433 include/linux/module.h 430 431 #ifdef CONFIG_TRACEPOINTS 432 unsigned int num_tracepoints; > 433 tracepoint_ptr_t *tracepoints_ptrs; 434 #endif 435 #ifdef HAVE_JUMP_LABEL 436 struct jump_entry *jump_entries; 437 unsigned int num_jump_entries; 438 #endif 439 #ifdef CONFIG_TRACING 440 unsigned int num_trace_bprintk_fmt; 441 const char **trace_bprintk_fmt_start; 442 #endif 443 #ifdef CONFIG_EVENT_TRACING 444 struct trace_event_call **trace_events; 445 unsigned int num_trace_events; 446 struct trace_eval_map **trace_evals; 447 unsigned int num_trace_evals; 448 #endif 449 #ifdef CONFIG_FTRACE_MCOUNT_RECORD 450 unsigned int num_ftrace_callsites; 451 unsigned long *ftrace_callsites; 452 #endif 453 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] MAINTAINERS: Replace Vince Bridgers as Altera TSE maintainer
On Fri, Oct 12, 2018 at 8:12 PM Bridgers, Vince wrote: > > > > -Original Message- > From: Thor Thayer > Sent: Friday, October 12, 2018 3:49 PM > To: Greg KH > Cc: geert+rene...@glider.be; jho...@kernel.org; at...@kernel.org; > bhelg...@google.com; james.hart...@sondrel.com; linux-kernel@vger.kernel.org; > Bridgers, Vince > Subject: Re: [PATCH] MAINTAINERS: Replace Vince Bridgers as Altera TSE > maintainer > > On 10/12/2018 11:57 AM, Greg KH wrote: > > On Fri, Oct 12, 2018 at 11:50:52AM -0500, thor.tha...@linux.intel.com wrote: > >> From: Thor Thayer > >> > >> Vince has moved to a different role. Replace him as Altera TSE > >> maintainer. > >> > >> Signed-off-by: Thor Thayer > > > > Would be nice if Vince can ack this... > > > + Vince (at a new email address) > > Thanks Thor, > > Acked-by: Vince Bridgers Acked-by:Alan Tull Alan
Re: [PATCH] docs: Fix typos in histogram.rst
On Sat, 13 Oct 2018 10:30:57 +0900 Masanari Iida wrote: > This patch fixes some spelling typos. > > Signed-off-by: Masanari Iida > --- > Documentation/trace/histogram.rst | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Documentation/trace/histogram.rst > b/Documentation/trace/histogram.rst > index 5ac724baea7d..7dda76503127 100644 > --- a/Documentation/trace/histogram.rst > +++ b/Documentation/trace/histogram.rst > @@ -1765,7 +1765,7 @@ For example, here's how a latency can be calculated:: ># echo 'hist:keys=pid,prio:ts0=common_timestamp ...' >> event1/trigger ># echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ...' >> > event2/trigger > > -In the first line above, the event's timetamp is saved into the > +In the first line above, the event's timestamp is saved into the > variable ts0. In the next line, ts0 is subtracted from the second > event's timestamp to produce the latency, which is then assigned into > yet another variable, 'wakeup_lat'. The hist trigger below in turn > @@ -1811,7 +1811,7 @@ the command that defined it with a '!':: > /sys/kernel/debug/tracing/synthetic_events > > At this point, there isn't yet an actual 'wakeup_latency' event > -instantiated in the event subsytem - for this to happen, a 'hist > +instantiated in the event subsystem - for this to happen, a 'hist The first two appear to show that Tom has a faulty 's' key ;-) Acked-by: Steven Rostedt (VMware) -- Steve > trigger action' needs to be instantiated and bound to actual fields > and variables defined on other events (see Section 2.2.3 below on > how that is done using hist trigger 'onmatch' action). Once that is > @@ -1837,7 +1837,7 @@ output can be displayed by reading the event's 'hist' > file. > A hist trigger 'action' is a function that's executed whenever a > histogram entry is added or updated. > > -The default 'action' if no special function is explicity specified is > +The default 'action' if no special function is explicitly specified is > as it always has been, to simply update the set of values associated > with an entry. Some applications, however, may want to perform > additional actions at that point, such as generate another event, or
ubifs: WARNINGs
Hi,
Linux 4.19-rc7, x86_64 laptop.
I don't have an ubifs filesystem. When I just modprobe ubifs and then
rmmod ubifs, I get 2 WARNINGs from these 2 lines:
static void __exit ubifs_exit(void)
{
WARN_ON(list_empty(&ubifs_infos));
WARN_ON(atomic_long_read(&ubifs_clean_zn_cnt) == 0);
Is this normal/expected?
[ 977.091170] calling init_mtd+0x0/0x100 [mtd] @ 3187
[ 977.092365] initcall init_mtd+0x0/0x100 [mtd] returned 0 after 251 usecs
[ 977.146490] calling ubi_init+0x0/0x249 [ubi] @ 3187
[ 977.148351] initcall ubi_init+0x0/0x249 [ubi] returned 0 after 896 usecs
[ 977.260504] calling ubifs_init+0x0/0xae [ubifs] @ 3187
[ 977.261976] initcall ubifs_init+0x0/0xae [ubifs] returned 0 after 516 usecs
[ 987.695589] WARNING: CPU: 2 PID: 3217 at ../fs/ubifs/super.c:2340
ubifs_exit+0xf/0x488 [ubifs]
[ 987.697142] Modules linked in: ubifs(-) ubi mtd fuse xt_tcpudp ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set
nfnetlink af_packet ebtable_nat ebtable_broute bridge stp llc ip6table_nat
nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat
nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle
iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
iptable_filter ip_tables x_tables bpfilter snd_hda_codec_hdmi
snd_hda_codec_realtek btrfs snd_hda_codec_generic xor coretemp zstd_compress
hwmon i915 raid6_pq uvcvideo intel_rapl x86_pkg_temp_thermal intel_powerclamp
libcrc32c zstd_decompress xxhash videobuf2_vmalloc kvm_intel videobuf2_memops
crct10dif_pclmul videobuf2_v4l2 videobuf2_common hid_generic
[ 987.709985] videodev arc4 usbmouse crc32_pclmul usbhid iwldvm media
crc32c_intel hid ghash_clmulni_intel pcbc mac80211 msr aesni_intel aes_x86_64
crypto_simd cryptd glue_helper iwlwifi kvmgt vfio_mdev mdev vfio_iommu_type1
vfio intel_cstate snd_hda_intel snd_hda_codec gpio_ich sdhci_pci iTCO_wdt kvm
iTCO_vendor_support snd_hda_core cqhci cfg80211 intel_uncore intel_rapl_perf
snd_hwdep sdhci snd_pcm irqbypass joydev mei_me mmc_core mei toshiba_acpi evdev
sparse_keymap e1000e mousedev snd_timer input_leds mac_hid sr_mod snd
uio_pdrv_genirq lpc_ich uio rfkill wmi serio_raw led_class industrialio cdrom
thermal video soundcore button pcc_cpufreq ac pcspkr toshiba_haps battery sg
dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua autofs4
[ 987.721976] CPU: 2 PID: 3217 Comm: rmmod Not tainted 4.19.0-rc7mod #2
[ 987.723150] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version
4.10 01/08/2013
[ 987.724583] RIP: 0010:ubifs_exit+0xf/0x488 [ubifs]
[ 987.725377] Code: c3 8b 97 24 0a 00 00 6a 00 45 31 c9 41 b8 10 00 00 00 31
c9 e8 3a 32 ff ff 5a c3 48 8b 05 b1 e6 01 00 48 3d 30 62 fb c0 75 02 <0f> 0b 48
8b 05 f0 3b 02 00 48 85 c0 75 02 0f 0b e8 44 b9 ff ff e8
[ 987.728689] RSP: 0018:a3a18286fed0 EFLAGS: 00010246
[ 987.729608] RAX: c0fb6230 RBX: c0fbb400 RCX: 0001
[ 987.730907] RDX: RSI: 0001 RDI: 0246
[ 987.732211] RBP: R08: 0001 R09: 0001
[ 987.733512] R10: R11: R12: 0800
[ 987.734807] R13: R14: R15:
[ 987.736103] FS: 7fd2ded67b80() GS:88664ae0()
knlGS:
[ 987.737527] CS: 0010 DS: ES: CR0: 80050033
[ 987.738571] CR2: 55b4d9cd4ed8 CR3: 0001352b4004 CR4: 000606e0
[ 987.739869] Call Trace:
[ 987.740292] __x64_sys_delete_module+0x157/0x240
[ 987.741086] ? task_work_run+0x6e/0xb0
[ 987.741757] do_syscall_64+0x60/0x180
[ 987.742426] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 987.743346] RIP: 0033:0x7fd2de453f87
[ 987.744013] Code: 73 01 c3 48 8b 0d 11 af 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 b8 b0 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d e1 ae 2b 00 f7 d8 64 89 01 48
[ 987.747326] RSP: 002b:7ffe66c1a6d8 EFLAGS: 0206 ORIG_RAX:
00b0
[ 987.748624] RAX: ffda RBX: 7ffe66c1a738 RCX: 7fd2de453f87
[ 987.749919] RDX: 000a RSI: 0800 RDI: 55b4d9cca7e8
[ 987.751215] RBP: 55b4d9cca780 R08: 7ffe66c19651 R09:
[ 987.752512] R10: 7fd2de4c31e0 R11: 0206 R12: 7ffe66c1a900
[ 987.753808] R13: 7ffe66c1c256 R14: 55b4d9cca260 R15: 55b4d9cca780
[ 987.755111] ---[ end trace 512f0dc2470230e0 ]---
[ 987.755997] WARNING: CPU: 2 PID: 3217 at ../fs/ubifs/super.c:2341
ubifs_exit+0x1d/0x488 [ubifs]
[ 987.756383] systemd-journald[142]: Compressed data object 804 -> 577 using
LZ4
[ 987.757553] Modules linked in: ubifs(-) ubi mtd fuse xt_tcpudp ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set
nfnetlink af_packet ebtable_nat ebtable_broute bridge stp llc ip6table_nat
nf_nat_
Re: [PATCH] docs: Fix typos in histogram.rst
On 10/12/18 6:30 PM, Masanari Iida wrote: > This patch fixes some spelling typos. > > Signed-off-by: Masanari Iida > --- > Documentation/trace/histogram.rst | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Acked-by: Randy Dunlap thanks. -- ~Randy
[PATCH] docs: Fix typos in histogram.rst
This patch fixes some spelling typos. Signed-off-by: Masanari Iida --- Documentation/trace/histogram.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst index 5ac724baea7d..7dda76503127 100644 --- a/Documentation/trace/histogram.rst +++ b/Documentation/trace/histogram.rst @@ -1765,7 +1765,7 @@ For example, here's how a latency can be calculated:: # echo 'hist:keys=pid,prio:ts0=common_timestamp ...' >> event1/trigger # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp-$ts0 ...' >> event2/trigger -In the first line above, the event's timetamp is saved into the +In the first line above, the event's timestamp is saved into the variable ts0. In the next line, ts0 is subtracted from the second event's timestamp to produce the latency, which is then assigned into yet another variable, 'wakeup_lat'. The hist trigger below in turn @@ -1811,7 +1811,7 @@ the command that defined it with a '!':: /sys/kernel/debug/tracing/synthetic_events At this point, there isn't yet an actual 'wakeup_latency' event -instantiated in the event subsytem - for this to happen, a 'hist +instantiated in the event subsystem - for this to happen, a 'hist trigger action' needs to be instantiated and bound to actual fields and variables defined on other events (see Section 2.2.3 below on how that is done using hist trigger 'onmatch' action). Once that is @@ -1837,7 +1837,7 @@ output can be displayed by reading the event's 'hist' file. A hist trigger 'action' is a function that's executed whenever a histogram entry is added or updated. -The default 'action' if no special function is explicity specified is +The default 'action' if no special function is explicitly specified is as it always has been, to simply update the set of values associated with an entry. Some applications, however, may want to perform additional actions at that point, such as generate another event, or -- 2.19.1.328.g5a0cc8aca797
[PATCH] x86/boot: Add -Wno-pointer-sign to KBUILD_CFLAGS
When compiling the kernel with Clang, this warning appears even though it is disabled for the whole kernel because this folder has its own set of KBUILD_CFLAGS. It was disabled before the beginning of git history. In file included from arch/x86/boot/compressed/kaslr.c:29: In file included from arch/x86/boot/compressed/misc.h:21: In file included from ./include/linux/elf.h:5: In file included from ./arch/x86/include/asm/elf.h:77: In file included from ./arch/x86/include/asm/vdso.h:11: In file included from ./include/linux/mm_types.h:9: In file included from ./include/linux/spinlock.h:88: In file included from ./arch/x86/include/asm/spinlock.h:43: In file included from ./arch/x86/include/asm/qrwlock.h:6: ./include/asm-generic/qrwlock.h:101:53: warning: passing 'u32 *' (aka 'unsigned int *') to parameter of type 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] if (likely(atomic_try_cmpxchg_acquire(&lock->cnts, &cnts, _QW_LOCKED))) ^ ./include/linux/compiler.h:76:40: note: expanded from macro 'likely' # define likely(x) __builtin_expect(!!(x), 1) ^ ./include/asm-generic/atomic-instrumented.h:69:66: note: passing argument to parameter 'old' here static __always_inline bool atomic_try_cmpxchg(atomic_t *v, int *old, int new) ^ Signed-off-by: Nathan Chancellor --- There has been some discussion around whether KBUILD_CFLAGS should be overwritten in the folder (few examples linked below). In the meantime, there is precedent for taking top level disabled warnings and adding them here, thus this patch. * https://lore.kernel.org/lkml/CAKwvOdmXcztP542kADhyJYN2=Fk3qyXif_MCs=kqpge8qtt...@mail.gmail.com/ * https://lore.kernel.org/lkml/56442061-7f55-878d-5b26-7cdd14e90...@zytor.com/ arch/x86/boot/compressed/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile index 28764dacf018..466f66c8a7f8 100644 --- a/arch/x86/boot/compressed/Makefile +++ b/arch/x86/boot/compressed/Makefile @@ -37,6 +37,7 @@ KBUILD_CFLAGS += $(call cc-option,-ffreestanding) KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector) KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member) KBUILD_CFLAGS += $(call cc-disable-warning, gnu) +KBUILD_CFLAGS += -Wno-pointer-sign KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ GCOV_PROFILE := n -- 2.19.1
[PATCH 1/6] zorro_esp: Limit DMA transfers to 65535 bytes
The core driver, esp_scsi, does not use the ESP_CONFIG2_FENAB bit, so
the chip's Transfer Counter register is only 16 bits wide (not 24).
A larger transfer cannot work and will theoretically result in a failed
command and a "DMA length is zero" error.
Fixes: 3109e5ae0311
Signed-off-by: Finn Thain
Cc: Michael Schmitz
---
drivers/scsi/zorro_esp.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/scsi/zorro_esp.c b/drivers/scsi/zorro_esp.c
index bb70882e6b56..be79127db594 100644
--- a/drivers/scsi/zorro_esp.c
+++ b/drivers/scsi/zorro_esp.c
@@ -245,7 +245,7 @@ static int fastlane_esp_irq_pending(struct esp *esp)
static u32 zorro_esp_dma_length_limit(struct esp *esp, u32 dma_addr,
u32 dma_len)
{
- return dma_len > 0xFF ? 0xFF : dma_len;
+ return dma_len > 0x ? 0x : dma_len;
}
static void zorro_esp_reset_dma(struct esp *esp)
@@ -484,7 +484,6 @@ static void zorro_esp_send_blz1230_dma_cmd(struct esp *esp,
u32 addr,
scsi_esp_cmd(esp, ESP_CMD_DMA);
zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
- zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);
scsi_esp_cmd(esp, cmd);
}
@@ -529,7 +528,6 @@ static void zorro_esp_send_blz1230II_dma_cmd(struct esp
*esp, u32 addr,
scsi_esp_cmd(esp, ESP_CMD_DMA);
zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
- zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);
scsi_esp_cmd(esp, cmd);
}
@@ -574,7 +572,6 @@ static void zorro_esp_send_blz2060_dma_cmd(struct esp *esp,
u32 addr,
scsi_esp_cmd(esp, ESP_CMD_DMA);
zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
- zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);
scsi_esp_cmd(esp, cmd);
}
@@ -599,7 +596,6 @@ static void zorro_esp_send_cyber_dma_cmd(struct esp *esp,
u32 addr,
zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
- zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);
if (write) {
/* DMA receive */
@@ -649,7 +645,6 @@ static void zorro_esp_send_cyberII_dma_cmd(struct esp *esp,
u32 addr,
zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
- zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);
if (write) {
/* DMA receive */
@@ -691,7 +686,6 @@ static void zorro_esp_send_fastlane_dma_cmd(struct esp
*esp, u32 addr,
zorro_esp_write8(esp, (esp_count >> 0) & 0xff, ESP_TCLOW);
zorro_esp_write8(esp, (esp_count >> 8) & 0xff, ESP_TCMED);
- zorro_esp_write8(esp, (esp_count >> 16) & 0xff, ESP_TCHI);
if (write) {
/* DMA receive */
--
2.16.4
[PATCH 2/6] esp_scsi: Track residual for PIO transfers
If a target disconnects during a PIO data transfer the command may
fail when the target reconnects:
scsi host1: DMA length is zero!
scsi host1: cur adr[0438] len[]
The scsi bus is then reset. This happens because the residual reached
zero before the transfer was completed.
The usual residual calculation relies on the Transfer Count registers
which works for DMA transfers but not for PIO transfers. Fix the problem
by storing the PIO transfer residual and using that to correctly
calculate bytes_sent.
Fixes: 6fe07aaffbf0
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/scsi/esp_scsi.c | 1 +
drivers/scsi/esp_scsi.h | 2 ++
drivers/scsi/mac_esp.c | 2 ++
3 files changed, 5 insertions(+)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index c3fc34b9964d..9e5d3f7d29ae 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -1338,6 +1338,7 @@ static int esp_data_bytes_sent(struct esp *esp, struct
esp_cmd_entry *ent,
bytes_sent = esp->data_dma_len;
bytes_sent -= ecount;
+ bytes_sent -= esp->send_cmd_residual;
/*
* The am53c974 has a DMA 'pecularity'. The doc states:
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index 8163dca2071b..db4b6ea94caa 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -540,6 +540,8 @@ struct esp {
void*dma;
int dmarev;
+
+ int send_cmd_residual;
};
/* A front-end driver for the ESP chip should do the following in
diff --git a/drivers/scsi/mac_esp.c b/drivers/scsi/mac_esp.c
index eb551f3cc471..71879f2207e0 100644
--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -427,6 +427,8 @@ static void mac_esp_send_pio_cmd(struct esp *esp, u32 addr,
u32 esp_count,
scsi_esp_cmd(esp, ESP_CMD_TI);
}
}
+
+ esp->send_cmd_residual = esp_count;
}
static int mac_esp_irq_pending(struct esp *esp)
--
2.16.4
RE: [PATCH] MAINTAINERS: Replace Vince Bridgers as Altera TSE maintainer
-Original Message- From: Thor Thayer Sent: Friday, October 12, 2018 3:49 PM To: Greg KH Cc: geert+rene...@glider.be; jho...@kernel.org; at...@kernel.org; bhelg...@google.com; james.hart...@sondrel.com; linux-kernel@vger.kernel.org; Bridgers, Vince Subject: Re: [PATCH] MAINTAINERS: Replace Vince Bridgers as Altera TSE maintainer On 10/12/2018 11:57 AM, Greg KH wrote: > On Fri, Oct 12, 2018 at 11:50:52AM -0500, thor.tha...@linux.intel.com wrote: >> From: Thor Thayer >> >> Vince has moved to a different role. Replace him as Altera TSE >> maintainer. >> >> Signed-off-by: Thor Thayer > > Would be nice if Vince can ack this... > + Vince (at a new email address) Thanks Thor, Acked-by: Vince Bridgers
[PATCH 5/6] esp_scsi: De-duplicate PIO routines
As a temporary measure, the code to implement PIO transfers was
duplicated in zorro_esp and mac_esp. Now that this code has stabilized,
move it into the core driver to eliminate the duplication.
This replaces the inline assembler with more portable writesb() calls.
Optimizing the m68k writesb() implementation is a separate patch.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/scsi/esp_scsi.c | 126 +
drivers/scsi/esp_scsi.h | 5 +
drivers/scsi/mac_esp.c | 173 ++-
drivers/scsi/zorro_esp.c | 232 +++
4 files changed, 171 insertions(+), 365 deletions(-)
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 6ccaf818357e..646701fc22a4 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2776,3 +2776,129 @@ MODULE_PARM_DESC(esp_debug,
module_init(esp_init);
module_exit(esp_exit);
+
+#if IS_ENABLED(CONFIG_SCSI_MAC_ESP) || IS_ENABLED(CONFIG_SCSI_ZORRO_ESP)
+static inline unsigned int esp_wait_for_fifo(struct esp *esp)
+{
+ int i = 50;
+
+ do {
+ unsigned int fbytes = esp_read8(ESP_FFLAGS) & ESP_FF_FBYTES;
+
+ if (fbytes)
+ return fbytes;
+
+ udelay(2);
+ } while (--i);
+
+ pr_err("FIFO is empty (sreg %02x)\n", esp_read8(ESP_STATUS));
+ return 0;
+}
+
+static inline int esp_wait_for_intr(struct esp *esp)
+{
+ int i = 50;
+
+ do {
+ esp->sreg = esp_read8(ESP_STATUS);
+ if (esp->sreg & ESP_STAT_INTR)
+ return 0;
+
+ udelay(2);
+ } while (--i);
+
+ pr_err("IRQ timeout (sreg %02x)\n", esp->sreg);
+ return 1;
+}
+
+#define ESP_FIFO_SIZE 16
+
+void esp_send_pio_cmd(struct esp *esp, u32 addr, u32 esp_count,
+ u32 dma_count, int write, u8 cmd)
+{
+ u8 phase = esp->sreg & ESP_STAT_PMASK;
+
+ cmd &= ~ESP_CMD_DMA;
+ esp->send_cmd_error = 0;
+
+ if (write) {
+ u8 *dst = (u8 *)addr;
+ u8 mask = ~(phase == ESP_MIP ? ESP_INTR_FDONE : ESP_INTR_BSERV);
+
+ scsi_esp_cmd(esp, cmd);
+
+ while (1) {
+ if (!esp_wait_for_fifo(esp))
+ break;
+
+ *dst++ = esp_read8(ESP_FDATA);
+ --esp_count;
+
+ if (!esp_count)
+ break;
+
+ if (esp_wait_for_intr(esp)) {
+ esp->send_cmd_error = 1;
+ break;
+ }
+
+ if ((esp->sreg & ESP_STAT_PMASK) != phase)
+ break;
+
+ esp->ireg = esp_read8(ESP_INTRPT);
+ if (esp->ireg & mask) {
+ esp->send_cmd_error = 1;
+ break;
+ }
+
+ if (phase == ESP_MIP)
+ scsi_esp_cmd(esp, ESP_CMD_MOK);
+
+ scsi_esp_cmd(esp, ESP_CMD_TI);
+ }
+ } else {
+ unsigned int n = ESP_FIFO_SIZE;
+ u8 *src = (u8 *)addr;
+
+ scsi_esp_cmd(esp, ESP_CMD_FLUSH);
+
+ if (n > esp_count)
+ n = esp_count;
+ writesb(esp->fifo_reg, src, n);
+ src += n;
+ esp_count -= n;
+
+ scsi_esp_cmd(esp, cmd);
+
+ while (esp_count) {
+ if (esp_wait_for_intr(esp)) {
+ esp->send_cmd_error = 1;
+ break;
+ }
+
+ if ((esp->sreg & ESP_STAT_PMASK) != phase)
+ break;
+
+ esp->ireg = esp_read8(ESP_INTRPT);
+ if (esp->ireg & ~ESP_INTR_BSERV) {
+ esp->send_cmd_error = 1;
+ break;
+ }
+
+ n = ESP_FIFO_SIZE -
+ (esp_read8(ESP_FFLAGS) & ESP_FF_FBYTES);
+
+ if (n > esp_count)
+ n = esp_count;
+ writesb(esp->fifo_reg, src, n);
+ src += n;
+ esp_count -= n;
+
+ scsi_esp_cmd(esp, ESP_CMD_TI);
+ }
+ }
+
+ esp->send_cmd_residual = esp_count;
+}
+EXPORT_SYMBOL(esp_send_pio_cmd);
+#endif
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index d0c032803749..2590e5eda595 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -431,6 +431,7 @@ struct esp_driver_ops {
struct esp {
void __iomem*regs;
void __iomem*dma_regs;
+
[PATCH] m68k: Unroll raw_outsb() loop
Unroll the raw_outsb() loop using the optimized assembler code from
raw_outsw(). That code is copied and pasted, with movew changed to moveb.
This improves the performance of sequential write transfers using mac_esp
in PIO mode by 5% or 10%. (The DMA controller on the 840av/660av models is
still unsupported so PIO transfers are used.)
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
In a separate patch series, mac_esp adopts writesb() in place of inline
assembler, making that code smaller and more reusable.
---
arch/m68k/include/asm/raw_io.h | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/arch/m68k/include/asm/raw_io.h b/arch/m68k/include/asm/raw_io.h
index 85761255dde5..8a6dc6e5a279 100644
--- a/arch/m68k/include/asm/raw_io.h
+++ b/arch/m68k/include/asm/raw_io.h
@@ -107,12 +107,43 @@ static inline void raw_insb(volatile u8 __iomem *port, u8
*buf, unsigned int len
}
static inline void raw_outsb(volatile u8 __iomem *port, const u8 *buf,
-unsigned int len)
+unsigned int nr)
{
- unsigned int i;
+ unsigned int tmp;
-for (i = 0; i < len; i++)
- out_8(port, *buf++);
+ if (nr & 15) {
+ tmp = (nr & 15) - 1;
+ asm volatile (
+ "1: moveb %0@+,%2@; dbra %1,1b"
+ : "=a" (buf), "=d" (tmp)
+ : "a" (port), "0" (buf),
+ "1" (tmp));
+ }
+ if (nr >> 4) {
+ tmp = (nr >> 4) - 1;
+ asm volatile (
+ "1: "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "moveb %0@+,%2@; "
+ "dbra %1,1b"
+ : "=a" (buf), "=d" (tmp)
+ : "a" (port), "0" (buf),
+ "1" (tmp));
+ }
}
static inline void raw_insw(volatile u16 __iomem *port, u16 *buf, unsigned int
nr)
--
2.16.4
[PATCH] x86/time: Correct the attribute on jiffies' definition
Clang warns that the declaration of jiffies in include/linux/jiffies.h
doesn't match the definition in arch/x86/time/kernel.c:
arch/x86/kernel/time.c:29:42: warning: section does not match previous
declaration [-Wsection]
__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
^
./include/linux/cache.h:49:4: note: expanded from macro '__cacheline_aligned'
__section__(".data..cacheline_aligned")))
^
./include/linux/jiffies.h:81:31: note: previous attribute is here
extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data
jiffies;
^
./arch/x86/include/asm/cache.h:20:2: note: expanded from macro
'__cacheline_aligned_in_smp'
__page_aligned_data
^
./include/linux/linkage.h:39:29: note: expanded from macro '__page_aligned_data'
#define __page_aligned_data __section(.data..page_aligned)
__aligned(PAGE_SIZE)
^
./include/linux/compiler_attributes.h:233:56: note: expanded from macro
'__section'
#define __section(S)__attribute__((__section__(#S)))
^
1 warning generated.
The declaration was changed in commit 7c30f352c852 ("jiffies.h: declare
jiffies and jiffies_64 with cacheline_aligned_in_smp") but wasn't
updated here. Make them match so Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/98
Signed-off-by: Nathan Chancellor
---
arch/x86/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
index b23f5420b26a..0e14f6c0d35e 100644
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -26,7 +26,7 @@
#include
#ifdef CONFIG_X86_64
-__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
+__visible volatile unsigned long jiffies __cacheline_aligned_in_smp =
INITIAL_JIFFIES;
#endif
unsigned long profile_pc(struct pt_regs *regs)
--
2.19.1
[PATCH] PCI: make pci_size() return real size
From: Du Changbin Currently, the pci_size() function actually return 'size-1'. Make it return real size to avoid confusing. Signed-off-by: Du Changbin --- drivers/pci/probe.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 201f9e5ff55c..8ff2b1413865 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -121,13 +121,13 @@ static u64 pci_size(u64 base, u64 maxbase, u64 mask) * Get the lowest of them to find the decode size, and from that * the extent. */ - size = (size & ~(size-1)) - 1; + size = size & ~(size-1); /* * base == maxbase can be valid only if the BAR has already been * programmed with all 1s. */ - if (base == maxbase && ((base | size) & mask) != mask) + if (base == maxbase && ((base | (size - 1)) & mask) != mask) return 0; return size; @@ -278,7 +278,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, /* Above 32-bit boundary; try to reallocate */ res->flags |= IORESOURCE_UNSET; res->start = 0; - res->end = sz64; + res->end = sz64 - 1; pci_info(dev, "reg 0x%x: can't handle BAR above 4GB (bus address %#010llx)\n", pos, (unsigned long long)l64); goto out; @@ -286,7 +286,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, } region.start = l64; - region.end = l64 + sz64; + region.end = l64 + sz64 - 1; pcibios_bus_to_resource(dev->bus, res, ®ion); pcibios_resource_to_bus(dev->bus, &inverted_region, res); -- 2.17.1
[PATCH] kernel/signal: Signal-based pre-coredump notification
For simplicity and consistency, this patch provides an implementation
for signal-based fault notification prior to the coredump of a child
process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
be used by an application to express its interest and to specify the
signal (SIGCHLD or SIGUSR1 or SIGUSR2) for such a notification. A new
signal code (si_code), CLD_PREDUMP, is also defined for SIGCHLD.
Background:
As the coredump of a process may take time, in certain time-sensitive
applications it is necessary for a parent process (e.g., a process
manager) to be notified of a child's imminent death before the coredump
so that the parent process can act sooner, such as re-spawning an
application process, or initiating a control-plane fail-over.
Currently there are two ways for a parent process to be notified of a
child process's state change. One is to use the POSIX signal, and
another is to use the kernel connector module. The specific events and
actions are summarized as follows:
Process EventPOSIX SignalConnector-based
--
ptrace_attach() do_notify_parent_cldstop() proc_ptrace_connector()
SIGCHLD / CLD_STOPPED
ptrace_detach() do_notify_parent_cldstop() proc_ptrace_connector()
SIGCHLD / CLD_CONTINUED
pre_coredump/N/A proc_coredump_connector()
get_signal()
post_coredump/ do_notify_parent() proc_exit_connector()
do_exit()SIGCHLD / exit_signal
--
As shown in the table, the signal-based pre-coredump notification is not
currently available. In some cases using a connector-based notification
can be quite complicated (e.g., when a process manager is written in shell
scripts and thus is subject to certain inherent limitations), and a
signal-based notification would be simpler and better suited.
Signed-off-by: Enke Chen
---
arch/x86/kernel/signal_compat.c| 2 +-
include/linux/sched.h | 4 ++
include/linux/signal.h | 5 +++
include/uapi/asm-generic/siginfo.h | 3 +-
include/uapi/linux/prctl.h | 4 ++
kernel/fork.c | 1 +
kernel/signal.c| 51 +
kernel/sys.c | 77 ++
8 files changed, 145 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/signal_compat.c b/arch/x86/kernel/signal_compat.c
index 9ccbf05..a3deba8 100644
--- a/arch/x86/kernel/signal_compat.c
+++ b/arch/x86/kernel/signal_compat.c
@@ -30,7 +30,7 @@ static inline void signal_compat_build_tests(void)
BUILD_BUG_ON(NSIGSEGV != 7);
BUILD_BUG_ON(NSIGBUS != 5);
BUILD_BUG_ON(NSIGTRAP != 5);
- BUILD_BUG_ON(NSIGCHLD != 6);
+ BUILD_BUG_ON(NSIGCHLD != 7);
BUILD_BUG_ON(NSIGSYS != 1);
/* This is part of the ABI and can never change in size: */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 09026ea..cfb9645 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -696,6 +696,10 @@ struct task_struct {
int exit_signal;
/* The signal sent when the parent dies: */
int pdeath_signal;
+
+ /* The signal sent prior to a child's coredump: */
+ int predump_signal;
+
/* JOBCTL_*, siglock protected: */
unsigned long jobctl;
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 706a499..7cb976d 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -256,6 +256,11 @@ static inline int valid_signal(unsigned long sig)
return sig <= _NSIG ? 1 : 0;
}
+static inline int valid_predump_signal(int sig)
+{
+ return (sig == SIGCHLD) || (sig == SIGUSR1) || (sig == SIGUSR2);
+}
+
struct timespec;
struct pt_regs;
enum pid_type;
diff --git a/include/uapi/asm-generic/siginfo.h
b/include/uapi/asm-generic/siginfo.h
index cb3d6c2..1a47cef 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -267,7 +267,8 @@ struct {\
#define CLD_TRAPPED4 /* traced child has trapped */
#define CLD_STOPPED5 /* child has stopped */
#define CLD_CONTINUED 6 /* stopped child has continued */
-#define NSIGCHLD 6
+#define CLD_PREDUMP7 /* child is about to dump core */
+#define NSIGCHLD 7
/*
* SIGPOLL (or any other signal without signal specific si_codes) si_codes
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index c0d7ea0..79f0a8a 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -219,4 +219,8 @@ struct prctl_mm_map {
# define PR_SPEC_DISABLE (1UL << 2)
# define PR_SPEC_FORCE_DISABLE (1UL << 3)
+/* Whether to receive signal p
Re: [PATCH 6/6] mm: track gup pages with page->dma_pinned_* fields
On 10/12/18 4:07 AM, Balbir Singh wrote:
> On Thu, Oct 11, 2018 at 11:00:14PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
[...]
>> +static int pin_page_for_dma(struct page *page)
>> +{
>> +int ret = 0;
>> +struct zone *zone;
>> +
>> +page = compound_head(page);
>> +zone = page_zone(page);
>> +
>> +spin_lock(zone_gup_lock(zone));
>> +
>> +if (PageDmaPinned(page)) {
>> +/* Page was not on an LRU list, because it was DMA-pinned. */
>> +VM_BUG_ON_PAGE(PageLRU(page), page);
>> +
>> +atomic_inc(&page->dma_pinned_count);
>> +goto unlock_out;
>> +}
>> +
>> +/*
>> + * Note that page->dma_pinned_flags is unioned with page->lru.
>> + * Therefore, the rules are: checking if any of the
>> + * PAGE_DMA_PINNED_FLAGS bits are set may be done while page->lru
>> + * is in use. However, setting those flags requires that
>> + * the page is both locked, and also, removed from the LRU.
>> + */
>> +ret = isolate_lru_page(page);
>> +
>
> isolate_lru_page() can be expensive and in terms of the overall locking order
> sounds like zone_gup_lock is higher in the hierarchy than the locks taken
> inside isolate_lru_page()
As for the expensive part, that is a concern. But I do think we need some lock
here. The hierarchy shouldn't be a problem, given that this is a new lock. But
I'm not sure how to make this better. In any case, I think it should work--note
that
the zone_lru_lock, within isolate_lru_page(), is of similar use, and is held
for a similar duration, so...maybe not really a problem?
>> +if (ret == 0) {
>> +/* Avoid problems later, when freeing the page: */
>> +ClearPageActive(page);
>> +ClearPageUnevictable(page);
>> +
>> +/* counteract isolate_lru_page's effects: */
>> +put_page(page);
>
> Can the page get reaped here? What's the expected page count?
Nope. The page_count is at least one, because get_user_pages() incremented it.
>> +
>> +atomic_set(&page->dma_pinned_count, 1);
>> +SetPageDmaPinned(page);
>> +}
>> +
>> +unlock_out:
>> +spin_unlock(zone_gup_lock(zone));
>> +
>> +return ret;
>> +}
>> +
>> static struct page *no_page_table(struct vm_area_struct *vma,
>> unsigned int flags)
>> {
>> @@ -659,7 +704,7 @@ static long __get_user_pages(struct task_struct *tsk,
>> struct mm_struct *mm,
>> unsigned int gup_flags, struct page **pages,
>> struct vm_area_struct **vmas, int *nonblocking)
>> {
>> -long i = 0;
>> +long i = 0, j;
>> int err = 0;
>> unsigned int page_mask;
>> struct vm_area_struct *vma = NULL;
>> @@ -764,6 +809,10 @@ static long __get_user_pages(struct task_struct *tsk,
>> struct mm_struct *mm,
>> } while (nr_pages);
>>
>> out:
>> +if (pages)
>> +for (j = 0; j < i; j++)
>> +pin_page_for_dma(pages[j]);
>> +
>
> Why does get_user_pages() unconditionally pin_page_for_dma?
That's the grand plan here: get_user_pages() now means "unconditionally pin the
page for dma".
If you didn't want that, then either release it quickly (many callers do), or
use a different
way of pinning or acquiring the page.
>
>> return i ? i : err;
>> }
>>
>> @@ -1841,7 +1890,7 @@ int get_user_pages_fast(unsigned long start, int
>> nr_pages, int write,
>> struct page **pages)
>> {
>> unsigned long addr, len, end;
>> -int nr = 0, ret = 0;
>> +int nr = 0, ret = 0, i;
>>
>> start &= PAGE_MASK;
>> addr = start;
>> @@ -1862,6 +1911,9 @@ int get_user_pages_fast(unsigned long start, int
>> nr_pages, int write,
>> ret = nr;
>> }
>>
>> +for (i = 0; i < nr; i++)
>> +pin_page_for_dma(pages[i]);
>
> Why does get_user_pages_fast() unconditionally pin_page_for_dma?
All of the get_user_pages*() variants need to follow the same rules, so the
same
explanation as above, applies here also.
>> +
>> if (nr < nr_pages) {
>> /* Try to get the remaining pages with get_user_pages */
>> start += nr << PAGE_SHIFT;
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index e79cb59552d9..af9719756081 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -2335,6 +2335,11 @@ static void lock_page_lru(struct page *page, int
>> *isolated)
>> if (PageLRU(page)) {
>> struct lruvec *lruvec;
>>
>> +/* LRU and PageDmaPinned are mutually exclusive: they use the
>> + * same fields in struct page, but for different purposes.
>> + */
>
> Comment style needs fixing
oops, thanks for spotting those, will fix.
--
thanks,
John Hubbard
NVIDIA
Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count
On 10/12/18 3:56 AM, Balbir Singh wrote:
> On Thu, Oct 11, 2018 at 11:00:12PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
[...]
>> + * Because page->dma_pinned_flags is unioned with page->lru, any page that
>> + * uses these flags must NOT be on an LRU. That's partly enforced by
>> + * ClearPageDmaPinned, which gives the page back to LRU.
>> + *
>> + * PageDmaPinned also corresponds to PageTail (the 0th bit in the first
>> union
>> + * of struct page), and this flag is checked without knowing whether it is a
>> + * tail page or a PageDmaPinned page. Therefore, start the flags at bit 1
>> (0x2),
>> + * rather than bit 0.
>> + */
>> +#define PAGE_DMA_PINNED 0x2
>> +#define PAGE_DMA_PINNED_FLAGS (PAGE_DMA_PINNED)
>> +
>
> This is really subtle, additional changes to compound_head will need to
> coordinate
> with these flags? Also doesn't this bit need to be unique across all structs
> in
> the union? I guess that is guaranteed by the fact that page ==
> compound_head(page)
> as per your assertion, but I've forgotten why that is true. Could you please
> add some commentary on that
>
Yes, agreed. I've rewritten and augmented that comment block, plus removed the
PAGE_DMA_PINNED_FLAGS (there are no more bits available, so it's just
misleading
to even have it). So now it looks like this:
/*
* Because page->dma_pinned_flags is unioned with page->lru, any page that
* uses these flags must NOT be on an LRU. That's partly enforced by
* ClearPageDmaPinned, which gives the page back to LRU.
*
* PageDmaPinned is checked without knowing whether it is a tail page or a
* PageDmaPinned page. For that reason, PageDmaPinned avoids PageTail (the 0th
* bit in the first union of struct page), and instead uses bit 1 (0x2),
* rather than bit 0.
*
* PageDmaPinned can only be used if no other systems are using the same bit
* across the first struct page union. In this regard, it is similar to
* PageTail, and in fact, because of PageTail's constraint that bit 0 be left
* alone, bit 1 is also left alone so far: other union elements (ignoring tail
* pages) put pointers there, and pointer alignment leaves the lower two bits
* available.
*
* So, constraints include:
*
* -- Only use PageDmaPinned on non-tail pages.
* -- Remove the page from any LRU list first.
*/
#define PAGE_DMA_PINNED 0x2
/*
* Because these flags are read outside of a lock, ensure visibility between
* different threads, by using READ|WRITE_ONCE.
*/
static __always_inline int PageDmaPinned(struct page *page)
{
VM_BUG_ON(page != compound_head(page));
return (READ_ONCE(page->dma_pinned_flags) & PAGE_DMA_PINNED) != 0;
}
[...]
>> +static __always_inline void SetPageDmaPinned(struct page *page)
>> +{
>> +VM_BUG_ON(page != compound_head(page));
>
> VM_BUG_ON(!list_empty(&page->lru))
There is only one place where we set this flag, and that is when (in patch 6/6)
transitioning from a page that might (or might not) have been
on an LRU. In that case, the calling code has already corrupted page->lru, by
writing to page->dma_pinned_count, which is unions with page->lru:
atomic_set(&page->dma_pinned_count, 1);
SetPageDmaPinned(page);
...so it would be inappropriate to call a list function, such as
list_empty(), on that field. Let's just leave it as-is.
>
>> +WRITE_ONCE(page->dma_pinned_flags, PAGE_DMA_PINNED);
>> +}
>> +
>> +static __always_inline void ClearPageDmaPinned(struct page *page)
>> +{
>> +VM_BUG_ON(page != compound_head(page));
>> +VM_BUG_ON_PAGE(!PageDmaPinnedFlags(page), page);
>> +
>> +/* This does a WRITE_ONCE to the lru.next, which is also the
>> + * page->dma_pinned_flags field. So in addition to restoring page->lru,
>> + * this provides visibility to other threads.
>> + */
>> +INIT_LIST_HEAD(&page->lru);
>
> This assumes certain things about list_head, why not use the correct
> initialization bits.
>
Yes, OK, changed to:
static __always_inline void ClearPageDmaPinned(struct page *page)
{
VM_BUG_ON(page != compound_head(page));
VM_BUG_ON_PAGE(!PageDmaPinned(page), page);
/* Provide visibility to other threads: */
WRITE_ONCE(page->dma_pinned_flags, 0);
/*
* Safety precaution: restore the list head, before possibly returning
* the page to other subsystems.
*/
INIT_LIST_HEAD(&page->lru);
}
--
thanks,
John Hubbard
NVIDIA
Re: [PATCH v2 1/7] modules: Create rlimit for module space
On Sat, Oct 13, 2018 at 2:04 AM Edgecombe, Rick P wrote: > On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote: > > On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P > > wrote: > > > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote: > > > > Why all the rbtree stuff instead of stashing a pointer in struct > > > > vmap_area, or something like that? > > > > > > Since the tracking was not for all vmalloc usage, the intention was to not > > > bloat > > > the structure for other usages likes stacks. I thought usually there > > > wouldn't be > > > nearly as much module space allocations as there would be kernel stacks, > > > but > > > I > > > didn't do any actual measurements on the tradeoffs. > > > > I imagine that one extra pointer in there - pointing to your struct > > mod_alloc_user - would probably not be terrible. 8 bytes more per > > kernel stack shouldn't be so bad? > > I looked into this and it starts to look a little messy. The nommu.c version > of > vmalloc doesn't use or expose access to vmap_area or vm_struct. So it starts > to > look like a bunch of IFDEFs to remove the rlimit in the nommu case or making a > stand in that maintains pretend vm struct's in nommu.c. I had actually > previously tried to at least pull the allocations size from vmalloc structs, > but it broke on nommu. > > Thought I would check back and see. How important do you think this is? I don't think it's important - I just thought that it would be nice to avoid the extra complexity if it is easily avoidable.
Re: [LKP] 601d5abfea [ 13.686356] BUG: unable to handle kernel paging request at 34ca027e
kernel test robot writes:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> siginfo-next
>
This is an odd one. This is the first time I recall the lkp test robot
emailing me and telling me that I have fixed an issue. I don't mind I
am just a little surprised.
Recently it was discovered that on my branch passing a large negative signal
number to rt_sigqueueinfo could cause an oops. The underlying issues
were fixed by:
b2a2ab527d6d ("signal: Guard against negative signal numbers in
copy_siginfo_from_user")
a36700589b85 ("signal: Guard against negative signal numbers in
copy_siginfo_from_user32")
It appears that this issue was found in linux-next before these fixes
were applied. And then the top of my siginfo-next branch where these
fixes exist was tested.
I have not problem with that sequence of events it is just a little
surprising.
If I have not read this test report correctly please let me know.
Eric
> commit 601d5abfeaf244b86bb68c1e05c6e0d57be2f6b0
> Author: Eric W. Biederman
> AuthorDate: Fri Oct 5 09:02:48 2018 +0200
> Commit: Eric W. Biederman
> CommitDate: Mon Oct 8 09:35:26 2018 +0200
>
> signal: In sigqueueinfo prefer sig not si_signo
>
> Andrei Vagin reported:
>
> > Accoding to the man page, the user should not set si_signo, it has to
> be set
> > by kernel.
> >
> > $ man 2 rt_sigqueueinfo
> >
> > The uinfo argument specifies the data to accompany the signal.
> This
> >argument is a pointer to a structure of type siginfo_t,
> described in
> >sigaction(2) (and defined by including ). The
> caller
> >should set the following fields in this structure:
> >
> >si_code
> > This must be one of the SI_* codes in the Linux kernel
> source
> > file include/asm-generic/siginfo.h, with the
> restriction that
> > the code must be negative (i.e., cannot be SI_USER,
> which is
> > used by the kernel to indicate a signal sent by
> kill(2)) and
> > cannot (since Linux 2.6.39) be SI_TKILL (which is used
> by the
> > kernel to indicate a signal sent using tgkill(2)).
> >
> >si_pid This should be set to a process ID, typically the process
> ID of
> > the sender.
> >
> >si_uid This should be set to a user ID, typically the real
> user ID of
> > the sender.
> >
> >si_value
> > This field contains the user data to accompany the
> signal. For
> > more information, see the description of the last (union
> sigval)
> > argument of sigqueue(3).
> >
> >Internally, the kernel sets the si_signo field to the value
> specified
> >in sig, so that the receiver of the signal can also obtain the
> signal
> >number via that field.
> >
> > On Tue, Sep 25, 2018 at 07:19:02PM +0200, Eric W. Biederman wrote:
> >>
> >> If there is some application that calls sigqueueinfo directly that has
> >> a problem with this added sanity check we can revisit this when we see
> >> what kind of crazy that application is doing.
> >
> >
> > I already know two "applications" ;)
> >
> >
> https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ptrace/peeksiginfo.c
> >
> https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/sigpending.c
> >
> > Disclaimer: I'm the author of both of them.
>
> Looking at the kernel code the historical behavior has alwasy been to
> prefer
> the signal number passed in by the kernel.
>
> So sigh. Implmenet __copy_siginfo_from_user and
> __copy_siginfo_from_user32 to
> take that signal number and prefer it. The user of ptrace will still
> use copy_siginfo_from_user and copy_siginfo_from_user32 as they do not and
> never have had a signal number there.
>
> Luckily this change has never made it farther than linux-next.
>
> Fixes: e75dc036c445 ("signal: Fail sigqueueinfo if si_signo != sig")
> Reported-by: Andrei Vagin
> Tested-by: Andrei Vagin
> Signed-off-by: "Eric W. Biederman"
>
> 4ce5f9c9e7 signal: Use a smaller struct siginfo in the kernel
> 601d5abfea signal: In sigqueueinfo prefer sig not si_signo
> a36700589b signal: Guard against negative signal numbers in
> copy_siginfo_from_user32
> 771b65e89c Add linux-next specific files for 20181011
> +--++++---+
> | | 4ce5f9c9e7 | 601d5abfea |
> a36700589b | next-20181011 |
> +---
Re: [PATCH v2 1/7] modules: Create rlimit for module space
On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote: > On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P > wrote: > > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote: > > > Why all the rbtree stuff instead of stashing a pointer in struct > > > vmap_area, or something like that? > > > > Since the tracking was not for all vmalloc usage, the intention was to not > > bloat > > the structure for other usages likes stacks. I thought usually there > > wouldn't be > > nearly as much module space allocations as there would be kernel stacks, but > > I > > didn't do any actual measurements on the tradeoffs. > > I imagine that one extra pointer in there - pointing to your struct > mod_alloc_user - would probably not be terrible. 8 bytes more per > kernel stack shouldn't be so bad? I looked into this and it starts to look a little messy. The nommu.c version of vmalloc doesn't use or expose access to vmap_area or vm_struct. So it starts to look like a bunch of IFDEFs to remove the rlimit in the nommu case or making a stand in that maintains pretend vm struct's in nommu.c. I had actually previously tried to at least pull the allocations size from vmalloc structs, but it broke on nommu. Thought I would check back and see. How important do you think this is?
Re: [PATCH] mm/kasan: make quarantine_lock a raw_spinlock_t
On Wed, 10 Oct 2018 23:49:45 +0200 Sebastian Andrzej Siewior wrote: > On 2018-10-10 11:57:41 [+0200], Dmitry Vyukov wrote: > > Yes. Clark's patch looks good to me. Probably would be useful to add a > > comment as to why raw spinlock is used (otherwise somebody may > > refactor it back later). > > If you really insist, I could add something but this didn't happen so > far. git's changelog should provide enough information why to why it was > changed. Requiring code readers to look up changelogs in git is rather user-hostile. There are several reasons for using raw_*, so an explanatory comment at each site is called for. However it would be smarter to stop "using raw_* for several reasons". Instead, create a differently named variant for each such reason. ie, do /* * Nice comment goes here. It explains all the possible reasons why -rt * might use a raw_spin_lock when a spin_lock could otherwise be used. */ #define raw_spin_lock_for_rtraw_spinlock Then use raw_spin_lock_for_rt() at all such sites.
Re: [patch] mm, slab: avoid high-order slab pages when it does not reduce waste
On Fri, 12 Oct 2018, Andrew Morton wrote: > > The slab allocator has a heuristic that checks whether the internal > > fragmentation is satisfactory and, if not, increases cachep->gfporder to > > try to improve this. > > > > If the amount of waste is the same at higher cachep->gfporder values, > > there is no significant benefit to allocating higher order memory. There > > will be fewer calls to the page allocator, but each call will require > > zone->lock and finding the page of best fit from the per-zone free areas. > > > > Instead, it is better to allocate order-0 memory if possible so that pages > > can be returned from the per-cpu pagesets (pcp). > > > > There are two reasons to prefer this over allocating high order memory: > > > > - allocating from the pcp lists does not require a per-zone lock, and > > > > - this reduces stranding of MIGRATE_UNMOVABLE pageblocks on pcp lists > >that increases slab fragmentation across a zone. > > Confused. Higher-order slab pages never go through the pcp lists, do > they? Nope. > I'd have thought that by tending to increase the amount of > order-0 pages which are used by slab, such stranding would be > *increased*? > These cpus have MIGRATE_UNMOVABLE pages on their pcp list. But because they are order-1 instead of order-0, we take zone->lock and find the smallest possible page in the zone's free area that is of sufficient size. On low on memory situations, there are no pages of MIGRATE_UNMOVABLE migratetype at any order in the free area. This calls __rmqueue_fallback() that steals pageblocks, MIGRATE_RECLAIMABLE and then MIGRATE_MOVABLE, and as MIGRATE_UNMOVABLE. We rely on the pcp batch count to backfill MIGRATE_UNMOVABLE pages onto the pcp list so we don't need to take zone->lock, and as a result of these allocations being order-0 rather than order-1 we can then allocate from these pages when such slab caches are expanded rather than stranding them. We noticed this when the amount of memory wasted for TCPv6 was the same for both order-0 and order-1 allocations (order-1 waste was two times the order-0 waste). We had hundreds of cpus with pages on their MIGRATE_UNMOVABLE pcp list, but while allocating order-1 memory it would prefer to happily steal other pageblocks before calling reclaim and draining pcp lists. > > We are particularly interested in the second point to eliminate cases > > where all other pages on a pageblock are movable (or free) and fallback to > > pageblocks of other migratetypes from the per-zone free areas causes > > high-order slab memory to be allocated from them rather than from free > > MIGRATE_UNMOVABLE pages on the pcp. > > > > mm/slab.c | 15 +++ > > Do slub and slob also suffer from this effect? > SLOB should not, SLUB will typically increase the order to improve performance of the cpu cache; there's a drawback to changing out the cpu cache that SLAB does not have. In the case that this patch is addressing, there is no greater memory utilization from the allocted slab pages.
Re: turbostat-17.06.23 floating point exception
> Why would the cpu topology report 0 cpus? I added a debug entry to > cpu_usage_stat and /proc/stat showed it as an extra column. Then > fscanf parsing in for_all_cpus() failed, causing the SIGFPE. > > This is not an issue. Thanks. Yes, it is true that turbostat doesn't check for systems with 0 cpus. I'm curious how you provoked the kernel to claim that. If it is something others might do, we can have check for it and gracefully exit. thanks, -Len -- Len Brown, Intel Open Source Technology Center
Re: [PATCH v2 4/7] arm64/modules: Add rlimit checking for arm64 modules
On Fri, 2018-10-12 at 22:01 +, Edgecombe, Rick P wrote:
> On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> > +++ Dave Hansen [11/10/18 16:47 -0700]:
> > > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > > + if (check_inc_mod_rlimit(size))
> > > > + return NULL;
> > > > +
> > > > p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> > > > module_alloc_base + MODULES_VSIZE,
> > > > gfp_mask, PAGE_KERNEL_EXEC, 0,
> > > > @@ -65,6 +68,8 @@ void *module_alloc(unsigned long size)
> > > > return NULL;
> > > > }
> > > >
> > > > + update_mod_rlimit(p, size);
> > >
> > > Is there a reason we couldn't just rename all of the existing per-arch
> > > module_alloc() calls to be called, say, "arch_module_alloc()", then put
> > > this new rlimit code in a generic helper that does:
> > >
> > >
> > > if (check_inc_mod_rlimit(size))
> > > return NULL;
> > >
> > > p = arch_module_alloc(...);
> > >
> > > ...
> > >
> > > update_mod_rlimit(p, size);
> > >
> >
> > I second this suggestion. Just make module_{alloc,memfree} generic,
> > non-weak functions that call the rlimit helpers in addition to the
> > arch-specific arch_module_{alloc,memfree} functions.
> >
> > Jessica
>
> Ok, thanks. I am going to try another version of this with just a system wide
> BPF JIT limit based on the problems Jann brought up. I think it would be nice
> to
> have a module space limit, but as far as I know the only way today un-
> privlidged
> users could fill the space is from BPF JIT. Unless you see another purpose
> long
> term?
Err, nevermind. Going to try to include both limits. I'll incorporate this
refactor into the next version.
[PATCH] x86/intel_rdt: Prevent pseudo-locking from using stale pointers
From: Jithu Joseph
When the last CPU in an rdt_domain goes offline, its rdt_domain struct
gets freed. Current pseudo-locking code is unaware of this scenario
and tries to dereference the freed structure in a few places.
Add checks to prevent pseudo-locking code from doing this.
While further work is needed to seamlessly restore resource groups
(not just pseudo-locking) to their configuration when the domain is
brought back online, the immediate issue of invalid pointers is
addressed here.
Fixes: f4e80d67a5274 ("x86/intel_rdt: Resctrl files reflect pseudo-locked
information")
Fixes: 443810fe61605 ("x86/intel_rdt: Create debugfs files for pseudo-locking
testing")
Fixes: 746e08590b864 ("x86/intel_rdt: Create character device exposing
pseudo-locked region")
Fixes: 33dc3e410a0d9 ("x86/intel_rdt: Make CPU information accessible for
pseudo-locked regions")
Signed-off-by: Jithu Joseph
Signed-off-by: Reinette Chatre
---
arch/x86/kernel/cpu/intel_rdt.c | 7
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 12 +--
arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 10 ++
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c| 38 +++--
4 files changed, 55 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu/intel_rdt.c
index 1214f3f7ec6d..44272b7107ad 100644
--- a/arch/x86/kernel/cpu/intel_rdt.c
+++ b/arch/x86/kernel/cpu/intel_rdt.c
@@ -608,6 +608,13 @@ static void domain_remove_cpu(int cpu, struct rdt_resource
*r)
cancel_delayed_work(&d->cqm_limbo);
}
+ /*
+* rdt_domain "d" is going to be freed below, so clear
+* its pointer from pseudo_lock_region struct.
+*/
+ if (d->plr)
+ d->plr->d = NULL;
+
kfree(d->ctrl_val);
kfree(d->mbps_val);
bitmap_free(d->rmid_busy_llc);
diff --git a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
index 0f53049719cd..27937458c231 100644
--- a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
+++ b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
@@ -404,8 +404,16 @@ int rdtgroup_schemata_show(struct kernfs_open_file *of,
for_each_alloc_enabled_rdt_resource(r)
seq_printf(s, "%s:uninitialized\n", r->name);
} else if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED) {
- seq_printf(s, "%s:%d=%x\n", rdtgrp->plr->r->name,
- rdtgrp->plr->d->id, rdtgrp->plr->cbm);
+ if (!rdtgrp->plr->d) {
+ rdt_last_cmd_clear();
+ rdt_last_cmd_puts("Cache domain offline\n");
+ ret = -ENODEV;
+ } else {
+ seq_printf(s, "%s:%d=%x\n",
+ rdtgrp->plr->r->name,
+ rdtgrp->plr->d->id,
+ rdtgrp->plr->cbm);
+ }
} else {
closid = rdtgrp->closid;
for_each_alloc_enabled_rdt_resource(r) {
diff --git a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
index 9d54b191964b..9c8b602bd583 100644
--- a/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
+++ b/arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c
@@ -1174,6 +1174,11 @@ static int pseudo_lock_measure_cycles(struct rdtgroup
*rdtgrp, int sel)
goto out;
}
+ if (!plr->d) {
+ ret = -ENODEV;
+ goto out;
+ }
+
plr->thread_done = 0;
cpu = cpumask_first(&plr->d->cpu_mask);
if (!cpu_online(cpu)) {
@@ -1494,6 +1499,11 @@ static int pseudo_lock_dev_mmap(struct file *filp,
struct vm_area_struct *vma)
plr = rdtgrp->plr;
+ if (!plr->d) {
+ mutex_unlock(&rdtgroup_mutex);
+ return -ENODEV;
+ }
+
/*
* Task is required to run with affinity to the cpus associated
* with the pseudo-locked region. If this is not the case the task
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 5f55f8848da6..3a3ed7cf3773 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -268,17 +268,27 @@ static int rdtgroup_cpus_show(struct kernfs_open_file *of,
struct seq_file *s, void *v)
{
struct rdtgroup *rdtgrp;
+ struct cpumask *mask;
int ret = 0;
rdtgrp = rdtgroup_kn_lock_live(of->kn);
if (rdtgrp) {
- if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED)
- seq_printf(s, is_cpu_list(of) ? "%*pbl\n" : "%*pb\n",
-
Re: [PATCH 1/6] mm: get_user_pages: consolidate error handling
On 10/11/18 11:30 PM, Balbir Singh wrote: On Thu, Oct 11, 2018 at 11:00:09PM -0700, john.hubb...@gmail.com wrote: From: John Hubbard An upcoming patch requires a way to operate on each page that any of the get_user_pages_*() variants returns. In preparation for that, consolidate the error handling for __get_user_pages(). This provides a single location (the "out:" label) for operating on the collected set of pages that are about to be returned. As long every use of the "ret" variable is being edited, rename "ret" --> "err", so that its name matches its true role. This also gets rid of two shadowed variable declarations, as a tiny beneficial a side effect. Reviewed-by: Jan Kara Reviewed-by: Andrew Morton Signed-off-by: John Hubbard --- Looks good, might not be needed but Reviewed-by: Balbir Singh Thanks for the review, very good to have another set of eyes on this one. -- thanks, John Hubbard NVIDIA
[PATCH] staging: rtl8188eu: fix spelling mistake "EINPROGESS" -> "EINPROGRESS"
From: Colin Ian King
Trivial fix to spelling mistake in RT_TRACE message text.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index 43f031d644fd..d6a499692e96 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -606,7 +606,7 @@ static void usb_write_port_complete(struct urb *purb,
struct pt_regs *regs)
if ((purb->status == -EPIPE) || (purb->status == -EPROTO)) {
sreset_set_wifi_error_status(padapter,
USB_WRITE_PORT_FAIL);
} else if (purb->status == -EINPROGRESS) {
- RT_TRACE(_module_hci_ops_os_c_, _drv_err_,
("usb_write_port_complete: EINPROGESS\n"));
+ RT_TRACE(_module_hci_ops_os_c_, _drv_err_,
("usb_write_port_complete: EINPROGRESS\n"));
goto check_completion;
} else if (purb->status == -ENOENT) {
DBG_88E("%s: -ENOENT\n", __func__);
--
2.17.1
Re: [PATCH 2/6] mm: introduce put_user_page*(), placeholder versions
On 10/12/18 12:35 AM, Balbir Singh wrote:
On Thu, Oct 11, 2018 at 11:00:10PM -0700, john.hubb...@gmail.com wrote:
From: John Hubbard
[...]>> +/*
+ * put_user_pages_dirty() - for each page in the @pages array, make
+ * that page (or its head page, if a compound page) dirty, if it was
+ * previously listed as clean. Then, release the page using
+ * put_user_page().
+ *
+ * Please see the put_user_page() documentation for details.
+ *
+ * set_page_dirty(), which does not lock the page, is used here.
+ * Therefore, it is the caller's responsibility to ensure that this is
+ * safe. If not, then put_user_pages_dirty_lock() should be called instead.
+ *
+ * @pages: array of pages to be marked dirty and released.
+ * @npages: number of pages in the @pages array.
+ *
+ */
+void put_user_pages_dirty(struct page **pages, unsigned long npages)
+{
+ unsigned long index;
+
+ for (index = 0; index < npages; index++) {
Do we need any checks on npages, npages <= (PUD_SHIFT - PAGE_SHIFT)?
Hi Balbir,
Thanks for combing through this series.
I'd go with "probably not", because the only check that can be done is
what you showed above: "did someone crazy pass in more pages than are
possible for this system?". I don't think checking for that helps here,
as that will show up loud and clear, in other ways.
The release_pages() implementation made the same judgment call to not
check npages, which also influenced me.
A VM_BUG_ON could be added but I'd prefer not to, as it seems to have
not enough benefit to be worth it.
+ struct page *page = compound_head(pages[index]);
+
+ if (!PageDirty(page))
+ set_page_dirty(page);
+
+ put_user_page(page);
+ }
+}
+EXPORT_SYMBOL(put_user_pages_dirty);
+
+/*
+ * put_user_pages_dirty_lock() - for each page in the @pages array, make
+ * that page (or its head page, if a compound page) dirty, if it was
+ * previously listed as clean. Then, release the page using
+ * put_user_page().
+ *
+ * Please see the put_user_page() documentation for details.
+ *
+ * This is just like put_user_pages_dirty(), except that it invokes
+ * set_page_dirty_lock(), instead of set_page_dirty().
+ *
+ * @pages: array of pages to be marked dirty and released.
+ * @npages: number of pages in the @pages array.
+ *
+ */
+void put_user_pages_dirty_lock(struct page **pages, unsigned long npages)
+{
+ unsigned long index;
+
+ for (index = 0; index < npages; index++) {
+ struct page *page = compound_head(pages[index]);
+
+ if (!PageDirty(page))
+ set_page_dirty_lock(page);
+
+ put_user_page(page);
+ }
+}
+EXPORT_SYMBOL(put_user_pages_dirty_lock);
+
This can be collapsed w.r.t put_user_pages_dirty, a function pointer indirection
for the locked vs unlocked case, not sure how that affects function
optimization.
OK, good point. I initially wanted to avoid the overhead of a function
pointer, but considering that there are lots of other operations
happening, I think you're right: best to just get rid of the code
duplication. If later on we find that changing it back actually helps
any benchmarks, that can always be done.
See below for how I'm planning on fixing it, and it is a nice little
cleanup, so thanks for pointing that out.
+/*
+ * put_user_pages() - for each page in the @pages array, release the page
+ * using put_user_page().
+ *
+ * Please see the put_user_page() documentation for details.
+ *
+ * This is just like put_user_pages_dirty(), except that it invokes
+ * set_page_dirty_lock(), instead of set_page_dirty().
The comment is incorrect.
Yes, it sure is! Jan spotted it before, and I fixed it once, then
rebased off of the version right *before* the fix, so now I have to
delete that sentence again. It's hard to kill! :)
+ *
+ * @pages: array of pages to be marked dirty and released.
+ * @npages: number of pages in the @pages array.
+ *
+ */
+void put_user_pages(struct page **pages, unsigned long npages)
+{
+ unsigned long index;
+
+ for (index = 0; index < npages; index++)
+ put_user_page(pages[index]);
+}
Ditto in terms of code duplication
Here, I think you'll find that the end result, is sufficiently
de-duplicated, after applying the function pointer above. Here's what it
looks like without the comment blocks, below. I don't want to go any
further than this, because the only thing left is the "for" loops, and
macro-izing such a trivial thing is not really a win:
typedef int (*set_dirty_func)(struct page *page);
static void __put_user_pages_dirty(struct page **pages,
unsigned long npages,
set_dirty_func sdf)
{
unsigned long index;
for (index = 0; index < npages; index++) {
struct page *page = compound_head(pages[index]);
if (!PageDirty(page))
Re: turbostat-17.06.23 floating point exception
On Fri, Oct 12, 2018 at 11:26:30AM -0700, Solio Sarabia wrote: > Hi -- > > turbostat 17.06.23 is throwing an exception on a custom linux-4.16.12 > kernel, on Xeon E5-2699 v4 Broadwell EP, 2S, 22C/S, 44C total, HT off, > VTx off. > > Initially the system had 4.4.0-137. Then I built and installed > linux-4.16.12-default. turbostat works fine for these two versions. > After building linux-4.16.12 for a second time, the older kernel is > renamed and now `ls -l /boot/` (I'm using version without .old suffix): > > vmlinuz-4.16.12-default+ > vmlinuz-4.16.12-default+.old > > grep -i 'turbostat' /var/log/kern.log > > kernel: [ 159.140836] capability: warning: `turbostat' uses 32-bit > capabilities (legacy support in use) > kernel: [ 164.149264] traps: turbostat[1801] trap divide error > ip:407625 sp:7ffe4b0df000 error:0 in turbostat[40+17000] > > (gdb) > cpu22: MSR_PKGC3_IRTL: 0x (NOTvalid, 0 ns) > cpu22: MSR_PKGC6_IRTL: 0x (NOTvalid, 0 ns) > cpu22: MSR_PKGC7_IRTL: 0x (NOTvalid, 0 ns) > > Program received signal SIGFPE, Arithmetic exception. > 0x00407625 in compute_average (t=0x61a3b0, c=0x61a3d0, p=0x61a480) at > turbostat.c:1378 > 1378average.threads.tsc /= topo.num_cpus; > Why would the cpu topology report 0 cpus? I added a debug entry to cpu_usage_stat and /proc/stat showed it as an extra column. Then fscanf parsing in for_all_cpus() failed, causing the SIGFPE. This is not an issue. Thanks. > Let me know if you need more details. > > Thanks, > -SS
RE: [PATCH net-next, v2] hv_netvsc: fix vf serial matching with pci slot info
> -Original Message-
> From: Stephen Hemminger
> Sent: Friday, October 12, 2018 6:21 PM
> To: Haiyang Zhang
> Cc: Haiyang Zhang ; da...@davemloft.net;
> net...@vger.kernel.org; o...@aepfle.de; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; vkuznets
> Subject: Re: [PATCH net-next, v2] hv_netvsc: fix vf serial matching with pci
> slot
> info
>
> On Fri, 12 Oct 2018 20:55:15 +
> Haiyang Zhang wrote:
>
> Thanks for fixing this.
>
>
> > + if (kstrtou32(kobject_name(&pdev->slot->kobj), 10, &serial)) {
> > + netdev_notice(vf_netdev, "Invalid vf serial:%s\n",
> > + pdev->slot->kobj.name);
> > + return NULL;
> > + }
>
> Shouldn't this use kobject_name() in the message as well.
>
> Looking at the pci.h code there is already an API to get name from slot (it
> uses
> kobject_name()). So please use that one.
Sure, I will look for that api. Thanks.
Re: [patch] mm, slab: avoid high-order slab pages when it does not reduce waste
On Fri, 12 Oct 2018 14:24:57 -0700 (PDT) David Rientjes wrote: > The slab allocator has a heuristic that checks whether the internal > fragmentation is satisfactory and, if not, increases cachep->gfporder to > try to improve this. > > If the amount of waste is the same at higher cachep->gfporder values, > there is no significant benefit to allocating higher order memory. There > will be fewer calls to the page allocator, but each call will require > zone->lock and finding the page of best fit from the per-zone free areas. > > Instead, it is better to allocate order-0 memory if possible so that pages > can be returned from the per-cpu pagesets (pcp). > > There are two reasons to prefer this over allocating high order memory: > > - allocating from the pcp lists does not require a per-zone lock, and > > - this reduces stranding of MIGRATE_UNMOVABLE pageblocks on pcp lists >that increases slab fragmentation across a zone. Confused. Higher-order slab pages never go through the pcp lists, do they? I'd have thought that by tending to increase the amount of order-0 pages which are used by slab, such stranding would be *increased*? > We are particularly interested in the second point to eliminate cases > where all other pages on a pageblock are movable (or free) and fallback to > pageblocks of other migratetypes from the per-zone free areas causes > high-order slab memory to be allocated from them rather than from free > MIGRATE_UNMOVABLE pages on the pcp. > > mm/slab.c | 15 +++ Do slub and slob also suffer from this effect?
Re: [PATCH v2 1/5] mfd: lochnagar: Add initial binding documentation
On Mon, Oct 08, 2018 at 02:25:38PM +0100, Charles Keepax wrote: > Lochnagar is an evaluation and development board for Cirrus > Logic Smart CODEC and Amp devices. It allows the connection of > most Cirrus Logic devices on mini-cards, as well as allowing > connection of various application processor systems to provide a > full evaluation platform. This driver supports the board > controller chip on the Lochnagar board. > > Signed-off-by: Charles Keepax > --- > > Changes since v1: > - Move the binding includes into this patch. > - Move patch to the start of the patch chain. > - Update commit message a little > > Thanks, > Charles > > .../devicetree/bindings/mfd/cirrus,lochnagar.txt | 230 > + > include/dt-bindings/clk/lochnagar.h| 33 +++ > include/dt-bindings/pinctrl/lochnagar.h| 132 > 3 files changed, 395 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt > create mode 100644 include/dt-bindings/clk/lochnagar.h > create mode 100644 include/dt-bindings/pinctrl/lochnagar.h A few nits, otherwise: Acked-by: Rob Herring > > diff --git a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt > b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt > new file mode 100644 > index 0..3382a14c19fe4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt > @@ -0,0 +1,230 @@ > +Cirrus Logic Lochnagar Audio Development Board > + > +Lochnagar is an evaluation and development board for Cirrus Logic > +Smart CODEC and Amp devices. It allows the connection of most Cirrus > +Logic devices on mini-cards, as well as allowing connection of > +various application processor systems to provide a full evaluation > +platform. Audio system topology, clocking and power can all be > +controlled through the Lochnagar, allowing the device under test > +to be used in a variety of possible use cases. > + > +Also see these documents for generic binding information: > + [1] GPIO : ../gpio/gpio.txt > + [2] Pinctrl: ../pinctrl/pinctrl-bindings.txt > + [3] Clock : ../clock/clock-bindings.txt > + [4] Regulator: ../regulator/regulator.txt > + > +And these for relevant defines: > + [5] include/dt-bindings/pinctrl/lochnagar.h > + [6] include/dt-bindings/clock/lochnagar.h > + > +Required properties: > + > + - compatible : One of the following strings: > + "cirrus,lochnagar1" > + "cirrus,lochnagar2" > + > + - reg : I2C slave address > + > + - gpio-controller : Indicates this device is a GPIO controller. > + - #gpio-cells : Must be 2. The first cell is the pin number, see > +[5] for available pins and the second cell is used to specify > +optional parameters, see [1]. > + - gpio-ranges : Range of pins managed by the GPIO controller, see > +[1]. Both the GPIO and Pinctrl base should be set to zero and the > +count to the appropriate of the LOCHNAGARx_PIN_NUM_GPIOS define, > +see [5]. > + > + - reset-gpios : Reset line to the Lochnagar, see [1]. > + > + - #clock-cells : Must be 1. The first cell indicates the clock > +number, see [6] for available clocks and [3]. > + > + - pinctrl-names : A pinctrl state named "default" must be defined. > + - pinctrl-0 : A phandle to the default pinctrl state. > + > + - SYSVDD-supply: Primary power supply for the Lochnagar. > + > +Optional properties: > + > + - present-gpios : Host present line, indicating the presence of a > +host system, see [1]. This can be omitted if the present line is > +tied in hardware. > + > + - clocks : Must contain an entry for each clock in clock-names. > + - clock-names : May contain entries for each of the following > +clocks: > + - ln-cdc-clkout : Output clock from CODEC card. > + - ln-dsp-clkout : Output clock from DSP card. > + - ln-gf-mclk1,ln-gf-mclk2,ln-gf-mclk3,ln-gf-mclk4 : Optional > + input audio clocks from host system. > + - ln-psia1-mclk, ln-psia2-mclk : Optional input audio clocks from > + external connector. > + - ln-spdif-clkout : Optional input audio clock from SPDIF. > + - ln-adat-clkout : Optional input audio clock from ADAT. > + > + - assigned-clocks : A list of Lochnagar clocks to be reparented, see > +[6] for available clocks. > + - assigned-clock-parents : Parents to be assigned to the clocks > +listed in "assigned-clocks". > + > + - MICBIAS1-supply, MICBIAS2-supply: Regulator supplies for the > +MICxVDD outputs, supplying the digital microphones, normally > +supplied from the attached CODEC. > + > +Required sub-nodes: > + > +The pin configurations are defined as a child of the pinctrl states > +node, see [2]. Each sub-node can have the following properties: > + - groups : A list of groups to select (either this or "pins" must be > +specified), available groups: > + codec-aif1, codec-aif2, codec-aif3, dsp-aif1, dsp-aif2, psia1, > + psia2,
Re: [PATCH v13 3/8] clk: Use devm_ in the register fixed factor clock
Quoting Ricardo Salveti (2018-09-14 11:53:02) > On Thu, Jun 14, 2018 at 6:55 PM wrote: > > > > From: Ilia Lin > > > > Use devm_clk_hw_register instead of clk_hw_register > > to simplify the usage of this API. This way drivers that call > > the clk_hw_register_fixed_factor won't need to maintain > > a data structure for further cleanup. > > > > Signed-off-by: Ilia Lin > > Tested-by: Amit Kucheria > > --- > > drivers/clk/clk-fixed-factor.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c > > index a5d402de5584..8e39bda8e596 100644 > > --- a/drivers/clk/clk-fixed-factor.c > > +++ b/drivers/clk/clk-fixed-factor.c > > @@ -94,7 +94,7 @@ struct clk_hw *clk_hw_register_fixed_factor(struct device > > *dev, > > init.num_parents = 1; > > > > hw = &fix->hw; > > - ret = clk_hw_register(dev, hw); > > + ret = devm_clk_hw_register(dev, hw); > > Not sure what is the current state of this patch-set, but this change > breaks drivers calling clk_hw_register_fixed_factor with a NULL dev > (e.g. imx_clk_fixed_factor), as devm_clk_hw_register needs a valid dev > for devres_add to work. > Yep. Probably better to just have a driver register the clk_hw structure itself with the clk framework vs. trying to get it right here in the generic type registration function.
Re: [PATCH v2 4/7] arm64/modules: Add rlimit checking for arm64 modules
On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> +++ Dave Hansen [11/10/18 16:47 -0700]:
> > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > + if (check_inc_mod_rlimit(size))
> > > + return NULL;
> > > +
> > > p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> > > module_alloc_base + MODULES_VSIZE,
> > > gfp_mask, PAGE_KERNEL_EXEC, 0,
> > > @@ -65,6 +68,8 @@ void *module_alloc(unsigned long size)
> > > return NULL;
> > > }
> > >
> > > + update_mod_rlimit(p, size);
> >
> > Is there a reason we couldn't just rename all of the existing per-arch
> > module_alloc() calls to be called, say, "arch_module_alloc()", then put
> > this new rlimit code in a generic helper that does:
> >
> >
> > if (check_inc_mod_rlimit(size))
> > return NULL;
> >
> > p = arch_module_alloc(...);
> >
> > ...
> >
> > update_mod_rlimit(p, size);
> >
>
> I second this suggestion. Just make module_{alloc,memfree} generic,
> non-weak functions that call the rlimit helpers in addition to the
> arch-specific arch_module_{alloc,memfree} functions.
>
> Jessica
Ok, thanks. I am going to try another version of this with just a system wide
BPF JIT limit based on the problems Jann brought up. I think it would be nice to
have a module space limit, but as far as I know the only way today
un-privlidged
users could fill the space is from BPF JIT. Unless you see another purpose long
term?
Rick
[PATCH-tip] locking/lockdep: Remove duplicated lock_class_ops percpu array
Remove the duplicated lock_class_ops percpu array that is not used
anywhere.
Fixes: 8ca2b56cd7da ("locking/lockdep: Make class->ops a percpu counter
and move it under CONFIG_DEBUG_LOCKDEP=y")
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 5faeb2e..be76f47 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -435,7 +435,6 @@ static int save_trace(struct stack_trace *trace)
* Various lockdep statistics:
*/
DEFINE_PER_CPU(struct lockdep_stats, lockdep_stats);
-DEFINE_PER_CPU(unsigned long [MAX_LOCKDEP_KEYS], lock_class_ops);
#endif
/*
--
1.8.3.1
[PATCH] dt-bindings: ufs: Fix the compatible string definition
If you look at the bindings for the UFS Host Controller it says:
- compatible: must contain "jedec,ufs-1.1" or "jedec,ufs-2.0", may
also list one or more of the following:
"qcom,msm8994-ufshc"
"qcom,msm8996-ufshc"
"qcom,ufshc"
My reading of that is that it's fine to just have either of these:
1. "qcom,msm8996-ufshc", "jedec,ufs-2.0"
2. "qcom,ufshc", "jedec,ufs-2.0"
As far as I can tell neither of the above is actually a good idea.
For #1 it turns out that the driver currently only keys off the
compatible string "qcom,ufshc" so it won't actually probe.
For #2 the driver won't probe but it's not a good idea to keep the SoC
name out of the compatible string.
Let's update the compatible string to make it really explicit. We'll
include a nod to the existing driver and the old binding and say that
we should always include the "qcom,ufshc" string in addition to the
SoC compatible string.
While we're at it we'll also include another example SoC known to have
UFS: sdm845.
Fixes: 47555a5c8a11 ("scsi: ufs: make the UFS variant a platform device")
Signed-off-by: Douglas Anderson
---
.../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index 2df00524bd21..69a06a1b732e 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -4,11 +4,14 @@ UFSHC nodes are defined to describe on-chip UFS host
controllers.
Each UFS controller instance should have its own node.
Required properties:
-- compatible : must contain "jedec,ufs-1.1" or "jedec,ufs-2.0", may
- also list one or more of the following:
- "qcom,msm8994-ufshc"
- "qcom,msm8996-ufshc"
- "qcom,ufshc"
+- compatible : must contain "jedec,ufs-1.1" or "jedec,ufs-2.0"
+
+ For Qualcomm SoCs must contain, as below, an
+ SoC-specific compatible along with "qcom,ufshc" and
+ the appropriate jedec string:
+ "qcom,msm8994-ufshc", "qcom,ufshc", "jedec,ufs-2.0"
+ "qcom,msm8996-ufshc", "qcom,ufshc", "jedec,ufs-2.0"
+ "qcom,sdm845-ufshc", "qcom,ufshc", "jedec,ufs-2.0"
- interrupts:
- reg :
--
2.19.0.605.g01d371f741-goog
[PATCH] dt-bindings: phy-qcom-qmp: Fix several mistakes from prior commits
Digging through the "phy-qcom-qmp" showed me many inconsistencies
between the bindings and the reality of the driver. Let's fix them
all.
* In commit 2d66eab18375 ("dt-bindings: phy: qmp: Add support for QMP
phy in IPQ8074") we probably should have explicitly listed that
there are no clocks for this PHY and also added the reset names in
alphabetical order. You can see that there are no clocks in the
driver where "clk_list" is NULL.
* In commit 8587b220f05e ("dt-bindings: phy-qcom-qmp: Update bindings
for QMP V3 USB PHY") we probably should have listed the resets for
this new PHY and also removed the "(Optional)" marking for the "cfg"
reset since PHYs that need "cfg" really do need it. It's just that
not all PHYs need it.
* In commit 7f0802074120 ("dt-bindings: phy-qcom-qmp: Update bindings
for sdm845") we forgot to update one instance of the string
"qcom,qmp-v3-usb3-phy" to be "qcom,sdm845-qmp-usb3-phy". Let's fix
that. We should also have added "qcom,sdm845-qmp-usb3-uni-phy" to
the clock-names and reset-names lists.
* In commit 99c7c7364b71 ("dt-bindings: phy-qcom-qmp: Add UFS phy
compatible string for sdm845") we should have added the set of
clocks and resets for "qcom,sdm845-qmp-ufs-phy". These were taken
from the driver.
* Cleanup the wording for what properties child nodes have to make it
more obvious which types of PHYs need clocks and resets. This was
sorta implicit in the "-names" description but I found myself
confused.
* As per the code not all "pcie qmp phys" have resets. Specifically
note that the "has_lane_rst" property in the driver is false for
"ipq8074-qmp-pcie-phy". Thus make it clear exactly which PHYs need
child nodes with resets.
Signed-off-by: Douglas Anderson
---
.../devicetree/bindings/phy/qcom-qmp-phy.txt | 31 ++-
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index adf20b2bdf71..fbc198d5dd39 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -40,24 +40,36 @@ Required properties:
"ref" for 19.2 MHz ref clk,
"com_aux" for phy common block aux clock,
"ref_aux" for phy reference aux clock,
+
+ For "qcom,ipq8074-qmp-pcie-phy": no clocks are listed.
For "qcom,msm8996-qmp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref".
For "qcom,msm8996-qmp-usb3-phy" must contain:
"aux", "cfg_ahb", "ref".
- For "qcom,qmp-v3-usb3-phy" must contain:
+ For "qcom,sdm845-qmp-usb3-phy" must contain:
+ "aux", "cfg_ahb", "ref", "com_aux".
+ For "qcom,sdm845-qmp-usb3-uni-phy" must contain:
"aux", "cfg_ahb", "ref", "com_aux".
+ For "qcom,sdm845-qmp-ufs-phy" must contain:
+ "ref", "ref_aux".
- resets: a list of phandles and reset controller specifier pairs,
one for each entry in reset-names.
- reset-names: "phy" for reset of phy block,
"common" for phy common block reset,
- "cfg" for phy's ahb cfg block reset (Optional).
+ "cfg" for phy's ahb cfg block reset.
+
+ For "qcom,ipq8074-qmp-pcie-phy" must contain:
+ "phy", "common".
For "qcom,msm8996-qmp-pcie-phy" must contain:
-"phy", "common", "cfg".
+ "phy", "common", "cfg".
For "qcom,msm8996-qmp-usb3-phy" must contain
-"phy", "common".
- For "qcom,ipq8074-qmp-pcie-phy" must contain:
-"phy", "common".
+ "phy", "common".
+ For "qcom,sdm845-qmp-usb3-phy" must contain:
+ "phy", "common".
+ For "qcom,sdm845-qmp-usb3-uni-phy" must contain:
+ "phy", "common".
+ For "qcom,sdm845-qmp-ufs-phy": no resets are listed.
- vdda-phy-supply: Phandle to a regulator supply to PHY core block.
- vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
@@ -79,9 +91,10 @@ Required properties for child node:
- #phy-cells: must be 0
+Required properties child node of pcie and usb3 qmp phys:
- clocks: a list of phandles and clock-specifier pairs,
one for each entry in clock-names.
- - clock-names: Must contain following for pcie and usb qmp phys:
+ - clock-names: Must contain following:
"pipe" for pipe clock specific to each lane.
- clock-output-names: Name of the PHY clock that will be the parent for
the above pipe clock.
@@ -91,9 +104,11 @@ Required properties for child node:
(or)
"pcie20_phy1_pipe_clk"
+
[BUG] perf stat: hangs with -p and process completes
Hi, I am running into a perf stat issue with the -p option which allows you to attach to a running process. If that process happens to terminate while under monitoring perf hangs in there and never terminates. The proper behavior would be to stop. I can see the issue in that the attached process is not a child, so wait() would not work. To reproduce: $ sleep 10 & $ perf stat -p $! doing the same with perf record works, so there is a solution to this problem.
[patch] mm, slab: avoid high-order slab pages when it does not reduce waste
The slab allocator has a heuristic that checks whether the internal
fragmentation is satisfactory and, if not, increases cachep->gfporder to
try to improve this.
If the amount of waste is the same at higher cachep->gfporder values,
there is no significant benefit to allocating higher order memory. There
will be fewer calls to the page allocator, but each call will require
zone->lock and finding the page of best fit from the per-zone free areas.
Instead, it is better to allocate order-0 memory if possible so that pages
can be returned from the per-cpu pagesets (pcp).
There are two reasons to prefer this over allocating high order memory:
- allocating from the pcp lists does not require a per-zone lock, and
- this reduces stranding of MIGRATE_UNMOVABLE pageblocks on pcp lists
that increases slab fragmentation across a zone.
We are particularly interested in the second point to eliminate cases
where all other pages on a pageblock are movable (or free) and fallback to
pageblocks of other migratetypes from the per-zone free areas causes
high-order slab memory to be allocated from them rather than from free
MIGRATE_UNMOVABLE pages on the pcp.
Signed-off-by: David Rientjes
---
mm/slab.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/mm/slab.c b/mm/slab.c
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1748,6 +1748,7 @@ static size_t calculate_slab_order(struct kmem_cache
*cachep,
for (gfporder = 0; gfporder <= KMALLOC_MAX_ORDER; gfporder++) {
unsigned int num;
size_t remainder;
+ int order;
num = cache_estimate(gfporder, size, flags, &remainder);
if (!num)
@@ -1803,6 +1804,20 @@ static size_t calculate_slab_order(struct kmem_cache
*cachep,
*/
if (left_over * 8 <= (PAGE_SIZE << gfporder))
break;
+
+ /*
+* If a higher gfporder would not reduce internal fragmentation,
+* no need to continue. The preference is to keep gfporder as
+* small as possible so slab allocations can be served from
+* MIGRATE_UNMOVABLE pcp lists to avoid stranding.
+*/
+ for (order = gfporder + 1; order <= slab_max_order; order++) {
+ cache_estimate(order, size, flags, &remainder);
+ if (remainder < left_over)
+ break;
+ }
+ if (order > slab_max_order)
+ break;
}
return left_over;
}
Re: [PATCH 0/7] HMM updates, improvements and fixes
On Fri, 12 Oct 2018 14:15:45 -0400 Jerome Glisse wrote: > On Fri, Aug 24, 2018 at 03:25:42PM -0400, jgli...@redhat.com wrote: > > From: Jérôme Glisse > > > > Few fixes that only affect HMM users. Improve the synchronization call > > back so that we match was other mmu_notifier listener do and add proper > > support to the new blockable flags in the process. > > > > For curious folks here are branches to leverage HMM in various existing > > device drivers: > > > > https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-nouveau-v01 > > https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-radeon-v00 > > https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-intel-v00 > > > > More to come (amd gpu, Mellanox, ...) > > > > I expect more of the preparatory work for nouveau will be merge in 4.20 > > (like we have been doing since 4.16) and i will wait until this patchset > > is upstream before pushing the patches that actualy make use of HMM (to > > avoid complex tree inter-dependency). > > > > Andrew do you want me to repost this on top of lastest mmotm ? > All conflict should be pretty trivial to fix. Please. I ducked v1 because a v2 was in the works. It's very late in the cycle so you might want to prepare an urgent-for-4.19 series and a for-4.20 series. Or, better, a single series with the appropriate Cc:stable tags. Please ensure that all review questions which have thus far been received are appropriately answered in code comments and in changelogs. Because if one reader was wondering about something, others will wonder the same thing in the future.
Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration
Hi Mathieu,
On 12 October 2018 at 22:05, Mathieu Desnoyers
wrote:
> commit 46e0c9be206f ("kernel: tracepoints: add support for relative
> references") changes the layout of the __tracepoint_ptrs section on
> architectures supporting relative references. However, it does so
> without turning struct tracepoint * const into const int * elsewhere in
> the tracepoint code, which has the following side-effect:
>
> tracepoint_module_{coming,going} invoke
> tp_module_going_check_quiescent() with mod->tracepoints_ptrs
> as first argument, and computes the end address of the array
> for the second argument with:
>
> mod->tracepoints_ptrs + mod->num_tracepoints
>
> However, because the type of mod->tracepoint_ptrs in module.h
> has not been changed from pointer to int, it passes an end
> pointer which is twice larger than the array, causing out-of-bound
> array accesses.
>
> Fix this by introducing a new typedef: tracepoint_ptr_t, which
> is either "const int" on architectures that have PREL32 relocations,
> or "struct tracepoint * const" on architectures that does not have
> this feature.
>
> Also provide a new tracepoint_ptr_defer() static inline to
> encapsulate deferencing this type rather than duplicate code and
> ugly idefs within the for_each_tracepoint_range() implementation.
>
Apologies for the breakage. FWIW, this looks like the correct approach
to me (and mirrors what I did for initcalls in the same series)
> This issue appears in 4.19-rc kernels, and should ideally be fixed
> before the end of the rc cycle.
>
+1
> Signed-off-by: Mathieu Desnoyers
> Link:
> http://lkml.kernel.org/r/20180704083651.24360-7-ard.biesheu...@linaro.org
> Cc: Michael Ellerman
> Cc: Ingo Molnar
> Cc: Steven Rostedt (VMware)
> Cc: Ard Biesheuvel
> Cc: Arnd Bergmann
> Cc: Benjamin Herrenschmidt
> Cc: Bjorn Helgaas
> Cc: Catalin Marinas
> Cc: James Morris
> Cc: James Morris
> Cc: Jessica Yu
> Cc: Josh Poimboeuf
> Cc: Kees Cook
> Cc: Nicolas Pitre
> Cc: Paul Mackerras
> Cc: Petr Mladek
> Cc: Russell King
> Cc: "Serge E. Hallyn"
> Cc: Sergey Senozhatsky
> Cc: Thomas Garnier
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Andrew Morton
> Cc: Linus Torvalds
> Cc: Greg Kroah-Hartman
Acked-by: Ard Biesheuvel
> ---
> include/linux/module.h | 2 +-
> include/linux/tracepoint-defs.h | 6 ++
> include/linux/tracepoint.h | 36 +
> kernel/tracepoint.c | 24 --
> 4 files changed, 38 insertions(+), 30 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index f807f15bebbe..cdab2451d6be 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -430,7 +430,7 @@ struct module {
>
> #ifdef CONFIG_TRACEPOINTS
> unsigned int num_tracepoints;
> - struct tracepoint * const *tracepoints_ptrs;
> + tracepoint_ptr_t *tracepoints_ptrs;
> #endif
> #ifdef HAVE_JUMP_LABEL
> struct jump_entry *jump_entries;
> diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
> index 22c5a46e9693..49ba9cde7e4b 100644
> --- a/include/linux/tracepoint-defs.h
> +++ b/include/linux/tracepoint-defs.h
> @@ -35,6 +35,12 @@ struct tracepoint {
> struct tracepoint_func __rcu *funcs;
> };
>
> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> +typedef const int tracepoint_ptr_t;
> +#else
> +typedef struct tracepoint * const tracepoint_ptr_t;
> +#endif
> +
> struct bpf_raw_event_map {
> struct tracepoint *tp;
> void*bpf_func;
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 041f7e56a289..538ba1a58f5b 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -99,6 +99,29 @@ extern void syscall_unregfunc(void);
> #define TRACE_DEFINE_ENUM(x)
> #define TRACE_DEFINE_SIZEOF(x)
>
> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> +static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> +{
> + return offset_to_ptr(p);
> +}
> +
> +#define __TRACEPOINT_ENTRY(name) \
> + asm(" .section \"__tracepoints_ptrs\", \"a\" \n" \
> + " .balign 4 \n" \
> + " .long __tracepoint_" #name " - . \n" \
> + " .previous \n")
> +#else
> +static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> +{
> + return *p;
> +}
> +
> +#define __TRACEPOINT_ENTRY(name)\
> + static tracepoint_ptr_t __tracepoint_ptr_##name __used \
> + __attribute__((section("__tracepoints_ptrs"))) = \
> + &__tracepoint_##name
> +#endif
> +
> #endif /* _LINUX_TRACEPOINT_H */
>
> /*
> @@ -253,19 +276,6 @@ extern void syscall_unregfunc(void);
> return static_key_false(&__tracepoint_##nam
Re: [PATCH 7/8] mips: convert to generic builtin command line
Hi Maksym, On Mon, Oct 08, 2018 at 08:56:25PM +0300, Maksym Kokhan wrote: > On Thu, Sep 27, 2018 at 9:56 PM Paul Burton wrote: > > It also doesn't allow for the various Kconfig options which allow us to > > ignore some of the sources of command line arguments, nor does it honor > > the ordering that those existing options allow. In practice perhaps we > > can cut down on some of this configurability anyway, but if we do that > > it needs to be thought through & the commit message should describe the > > changes in behaviour. > > Yes, this generic command line implementation lacks some of the > features, existing in the current mips command line code, and we > are going to expand functionality of generic command line code to > correspond it, but it would be easier to initially merge this simple > implementation and then develop it step by step. The problem occurs if merging the simple implementation breaks currently working systems. That is a no-go, and that is what I believe will happen with the current patchset. "Knowingly break it now & say we'll fix it later" is not an acceptable approach. Thanks, Paul
Re: [PATCH V2 1/2] dt-bindings: mmc: sdhci-msm: Add new compatible string for sdcdc10 DLL
On Mon, Oct 08, 2018 at 06:55:37PM +0530, Veerabhadrarao Badiganti wrote: > On the SDHC-MSM controllers which makes use of sdcdc10 variant DLLs, > the DLL configuration needs to be restored whenever controller clocks > are gated. This new compatible string denotes the sdhc-msm controller > variant which uses sdcdc10 DLL. What is sdcdc10 DLL? Seems like a work-around to not having SoC specific compatible strings. > > Signed-off-by: Veerabhadrarao Badiganti > --- > Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > index 3720385..49b0a43 100644 > --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > @@ -6,7 +6,11 @@ and the properties used by the sdhci-msm driver. > Required properties: > - compatible: Should contain: > "qcom,sdhci-msm-v4" for sdcc versions less than 5.0 > + "qcom,sdhci-msm-v4-sdcdc10" for sdcc versions < 5.0 and > + which makes use of sdcdc10 variant DLLs. > "qcom,sdhci-msm-v5" for sdcc versions >= 5.0 > + "qcom,sdhci-msm-v5-sdcdc10" for sdcc versions >= 5.0 and > + which makes use of sdcdc10 variant DLLs. > For SDCC version 5.0.0, MCI registers are removed from SDCC > interface and some registers are moved to HC. New compatible > string is added to support this change - "qcom,sdhci-msm-v5". > -- > Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux > Foundation Collaborative Project. >
Re: [PATCH] MAINTAINERS: Replace Vince Bridgers as Altera TSE maintainer
On 10/12/2018 11:57 AM, Greg KH wrote: On Fri, Oct 12, 2018 at 11:50:52AM -0500, thor.tha...@linux.intel.com wrote: From: Thor Thayer Vince has moved to a different role. Replace him as Altera TSE maintainer. Signed-off-by: Thor Thayer Would be nice if Vince can ack this... + Vince (at a new email address)
Re: [PATCH v2] Documentation: dt: Add binding for /secure-chosen/stdout-path
On Mon, Oct 08, 2018 at 06:16:42PM +0800, Jerome Forissier wrote:
> Some platforms may use a single device tree to describe two address
> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
> for Secure-only devices"). For these platforms it makes sense to define
> a secure counterpart of /chosen, namely: /secure-chosen. This new node
> is meant to be used by the secure firmware to pass data to the secure
> OS. Only the stdout-path property is supported for now.
>
> Signed-off-by: Jerome Forissier
> ---
>
> Notes:
> Sending this again, slightly modified. Previous submission was in March
> 2017 [1]. Since then, OP-TEE has implemented this binding for platforms
> that use DT [2] (fallback to /chosen/stdout-path to be implemented in
> [3]). A patch for QEMU has been proposed [4], to which the maintainer
> responded "Are the DT bindings upstream yet?" ;-)
>
> [1] https://patchwork.kernel.org/patch/9602401/
> [2] https://github.com/OP-TEE/optee_os/commit/4dc31c52544a
> [3] https://github.com/OP-TEE/optee_os/pull/2569
> [4] https://patchwork.ozlabs.org/patch/979345/
>
> Changes since v1:
> - Use "should" instead of "may" ("...the Secure OS should use the value
> of /chosen/stdout-path...").
>
> Documentation/devicetree/bindings/arm/secure.txt | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
Applied.
Rob
[PATCH v2 1/2] mtd: rawnand: Provide helper for polling GPIO R/B pin
Each controller driver with access to NAND R/B pin over GPIO would have
to reimplement the polling loop otherwise.
Signed-off-by: Janusz Krzysztofik
---
Changelog:
v2:
New patch - v1 consisted of only one patch (the followning one)
drivers/mtd/nand/raw/nand_base.c | 38 ++
include/linux/mtd/rawnand.h | 10 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 05bd0779fe9b..ff1ac4a3c647 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -45,6 +45,9 @@
#include
#include
#include
+#ifdef CONFIG_GPIOLIB
+#include
+#endif
#include "internals.h"
@@ -531,6 +534,41 @@ int nand_soft_waitrdy(struct nand_chip *chip, unsigned
long timeout_ms)
};
EXPORT_SYMBOL_GPL(nand_soft_waitrdy);
+#ifdef CONFIG_GPIOLIB
+/**
+ * nand_gpio_waitrdy - Poll R/B GPIO pin until ready
+ * @chip: NAND chip structure
+ * @gpiod: GPIO descriptor of R/B pin
+ * @timeout_ms: Timeout in ms
+ *
+ * Poll the R/B GPIO pin until it becomes ready. If that does not happen
+ * whitin the specified timeout, -ETIMEDOUT is returned.
+ *
+ * This helper is intended to be used when the controller has access to the
+ * NAND R/B pin over GPIO.
+ *
+ * Be aware that calling this helper from an ->exec_op() implementation means
+ * ->exec_op() must be re-entrant.
+ *
+ * Return 0 if the R/B pin indicates chip is ready, a negative error otherwise.
+ */
+int nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod,
+ unsigned long timeout_ms)
+{
+ /* Wait until command is processed or timeout occurs */
+ timeout_ms = jiffies + msecs_to_jiffies(timeout_ms);
+ do {
+ if (gpiod_get_value_cansleep(gpiod))
+ return 0;
+
+ cond_resched();
+ } while (time_before(jiffies, timeout_ms));
+
+ return gpiod_get_value_cansleep(gpiod) ? 0 : -ETIMEDOUT;
+};
+EXPORT_SYMBOL_GPL(nand_gpio_waitrdy);
+#endif
+
/**
* panic_nand_get_device - [GENERIC] Get chip for selected access
* @chip: the nand chip descriptor
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index e10b126e148f..09f0ed1345b1 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -1346,4 +1346,14 @@ void nand_release(struct nand_chip *chip);
*/
int nand_soft_waitrdy(struct nand_chip *chip, unsigned long timeout_ms);
+#ifdef CONFIG_GPIOLIB
+struct gpio_desc;
+/*
+ * External helper for controller drivers that have to implement the WAITRDY
+ * instruction and do have GPIO pin to check it.
+ */
+int nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod,
+ unsigned long timeout_ms);
+#endif
+
#endif /* __LINUX_MTD_RAWNAND_H */
--
2.16.4
[PATCH v2 2/2] mtd: rawnand: ams-delta: Use ->exec_op()
Replace legacy callbacks with ->select_chip() and ->exec_op().
In order to remove any references to legacy structure members, use of
.IO_ADDR_R/W has been replaced wit runtime calculations based on
priv->io_base.
Suggested-by: Boris Brezillon
Signed-off-by: Janusz Krzysztofik
---
Changelog:
v2:
- replace references to legacy structure .IO_ADDR_R/W members with
runtime calculated values - requested by Boris Brezillon, thanks!
- modify ams_delta_read/write_buf() functions, no longer exposed as
callbacks, to accept driver private structure instead of struct
nand_chip,
- use newly introduced nand_gpio_waitrdy() helper instead of legacy
nand_wait_ready() - suggested by Boris Brezillon, thanks!
- remove no longer needed ams_delta_dev_ready() legacy callback and
legacy structure member .chip_delay.
drivers/mtd/nand/raw/ams-delta.c | 103 +--
1 file changed, 55 insertions(+), 48 deletions(-)
diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c
index 5ba180a291eb..f0745aeecb1c 100644
--- a/drivers/mtd/nand/raw/ams-delta.c
+++ b/drivers/mtd/nand/raw/ams-delta.c
@@ -75,7 +75,7 @@ static const struct mtd_partition partition_info[] = {
static void ams_delta_io_write(struct ams_delta_nand *priv, u_char byte)
{
- writew(byte, priv->nand_chip.legacy.IO_ADDR_W);
+ writew(byte, priv->io_base + OMAP_MPUIO_OUTPUT);
gpiod_set_value(priv->gpiod_nwe, 0);
ndelay(40);
gpiod_set_value(priv->gpiod_nwe, 1);
@@ -87,7 +87,7 @@ static u_char ams_delta_io_read(struct ams_delta_nand *priv)
gpiod_set_value(priv->gpiod_nre, 0);
ndelay(40);
- res = readw(priv->nand_chip.legacy.IO_ADDR_R);
+ res = readw(priv->io_base + OMAP_MPUIO_INPUT_LATCH);
gpiod_set_value(priv->gpiod_nre, 1);
return res;
@@ -99,10 +99,9 @@ static void ams_delta_dir_input(struct ams_delta_nand *priv,
bool in)
priv->data_in = in;
}
-static void ams_delta_write_buf(struct nand_chip *this, const u_char *buf,
+static void ams_delta_write_buf(struct ams_delta_nand *priv, const u_char *buf,
int len)
{
- struct ams_delta_nand *priv = nand_get_controller_data(this);
int i;
if (priv->data_in)
@@ -112,9 +111,9 @@ static void ams_delta_write_buf(struct nand_chip *this,
const u_char *buf,
ams_delta_io_write(priv, buf[i]);
}
-static void ams_delta_read_buf(struct nand_chip *this, u_char *buf, int len)
+static void ams_delta_read_buf(struct ams_delta_nand *priv, u_char *buf,
+ int len)
{
- struct ams_delta_nand *priv = nand_get_controller_data(this);
int i;
if (!priv->data_in)
@@ -124,46 +123,63 @@ static void ams_delta_read_buf(struct nand_chip *this,
u_char *buf, int len)
buf[i] = ams_delta_io_read(priv);
}
-static u_char ams_delta_read_byte(struct nand_chip *this)
-{
- u_char res;
-
- ams_delta_read_buf(this, &res, 1);
-
- return res;
-}
-
-/*
- * Command control function
- *
- * ctrl:
- * NAND_NCE: bit 0 -> bit 2
- * NAND_CLE: bit 1 -> bit 7
- * NAND_ALE: bit 2 -> bit 6
- */
-static void ams_delta_hwcontrol(struct nand_chip *this, int cmd,
- unsigned int ctrl)
+static void ams_delta_select_chip(struct nand_chip *this, int n)
{
struct ams_delta_nand *priv = nand_get_controller_data(this);
- if (ctrl & NAND_CTRL_CHANGE) {
- gpiod_set_value(priv->gpiod_nce, !(ctrl & NAND_NCE));
- gpiod_set_value(priv->gpiod_cle, !!(ctrl & NAND_CLE));
- gpiod_set_value(priv->gpiod_ale, !!(ctrl & NAND_ALE));
- }
-
- if (cmd != NAND_CMD_NONE) {
- u_char byte = cmd;
+ if (n > 0)
+ return;
- ams_delta_write_buf(this, &byte, 1);
- }
+ gpiod_set_value(priv->gpiod_nce, n < 0);
}
-static int ams_delta_nand_ready(struct nand_chip *this)
+static int ams_delta_exec_op(struct nand_chip *this,
+const struct nand_operation *op, bool check_only)
{
struct ams_delta_nand *priv = nand_get_controller_data(this);
+ const struct nand_op_instr *instr;
+ int ret = 0;
+
+ for (instr = op->instrs; instr < op->instrs + op->ninstrs; instr++) {
+
+ switch (instr->type) {
+ case NAND_OP_CMD_INSTR:
+ gpiod_set_value(priv->gpiod_cle, 1);
+ ams_delta_write_buf(priv, &instr->ctx.cmd.opcode, 1);
+ gpiod_set_value(priv->gpiod_cle, 0);
+ break;
+
+ case NAND_OP_ADDR_INSTR:
+ gpiod_set_value(priv->gpiod_ale, 1);
+ ams_delta_write_buf(priv, instr->ctx.addr.addrs,
+ instr->ctx.addr.naddrs);
+ gpiod_set_value(priv->gpiod_ale, 0);
+
Re: [PATCH v2 1/3] dt-bindings: mtd: stm32_fmc2: add STM32 FMC2 NAND controller documentation
On Fri, Oct 05, 2018 at 11:41:58AM +0200, christophe.kere...@st.com wrote:
> From: Christophe Kerello
>
> This patch adds the documentation of the device tree bindings for the STM32
> FMC2 NAND controller.
>
> Signed-off-by: Christophe Kerello
> ---
> .../devicetree/bindings/mtd/stm32-fmc2-nand.txt| 59
> ++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt
> b/Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt
> new file mode 100644
> index 000..b620176
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt
> @@ -0,0 +1,59 @@
> +STMicroelectronics Flexible Memory Controller 2 (FMC2)
> +NAND Interface
> +
> +Required properties:
> +- compatible: Should be one of:
> + * st,stm32mp15-fmc2
> +- reg: NAND flash controller memory areas.
> + First region contains the register location.
> + Regions 2 to 4 respectively contain the data, command,
> + and address space for CS0.
> + Regions 5 to 7 contain the same areas for CS1.
> +- interrupts: The interrupt number
> +- pinctrl-0: Standard Pinctrl phandle (see: pinctrl/pinctrl-bindings.txt)
> +- clocks: Use common clock framework
How many? 'common clock framework' is a Linux thing, not part of
bindings.
> +
> +Optional properties:
> +- resets: Reference to a reset controller asserting the FMC controller
> +- dmas: DMA specifiers (see: dma/stm32-mdma.txt)
> +- dma-names: Must be "tx", "rx" and "ecc"
> +
> +Optional children nodes:
> +Children nodes represent the available NAND chips.
> +
> +Optional properties:
> +- nand-on-flash-bbt: see nand.txt
> +- nand-ecc-strength: see nand.txt
> +- nand-ecc-step-size: see nand.txt
> +
> +The following ECC strength and step size are currently supported:
> + - nand-ecc-strength = <1>, nand-ecc-step-size = <512> (Hamming)
> + - nand-ecc-strength = <4>, nand-ecc-step-size = <512> (BCH4)
> + - nand-ecc-strength = <8>, nand-ecc-step-size = <512> (BCH8) (default)
> +
> +Example:
> +
> + fmc: nand-controller@58002000 {
> + compatible = "st,stm32mp15-fmc2";
> + reg = <0x58002000 0x1000>,
> + <0x8000 0x1000>,
> + <0x8801 0x1000>,
> + <0x8802 0x1000>,
> + <0x8100 0x1000>,
> + <0x8901 0x1000>,
> + <0x8902 0x1000>;
> + interrupts = ;
> + clocks = <&rcc FMC_K>;
> + resets = <&rcc FMC_R>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&fmc_pins_a>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + nand@0 {
> + reg = <0>;
> + nand-on-flash-bbt;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> + };
> --
> 1.9.1
>
Re: [PATCH 07/11] x86/pkeys: Drop the preempt-disable section
On 2018-10-12 11:07:28 [-0700], Andy Lutomirski wrote: > All these "if" statements in the FPU code are messy and make > understanding and reviewing this code hard. > > Can you prepare a patch for the beginning of your series that removes > fpu->initialized and just ensures that the fpu is always initialized? > This will regress performance, but you should get all that performance > back with TIF_LOAD_FPU. okay, will do. Sebastian
Re: [PATCH 11/11] x86/fpu: defer FPU state load until return to userspace
On 2018-10-04 09:14:33 [-0700], Andy Lutomirski wrote:
> > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > index 3b2490b819181..3dad5c3b335eb 100644
> > --- a/arch/x86/entry/common.c
> > +++ b/arch/x86/entry/common.c
> > @@ -196,6 +197,14 @@ __visible inline void prepare_exit_to_usermode(struct
> > pt_regs *regs)
> > if (unlikely(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS))
> > exit_to_usermode_loop(regs, cached_flags);
> >
> > + /* Reload ti->flags; we may have rescheduled above. */
> > + cached_flags = READ_ONCE(ti->flags);
> > +
> > + if (unlikely(cached_flags & _TIF_LOAD_FPU))
> > + switch_fpu_return();
> > + else
> > + fpregs_is_state_consistent();
>
> Shouldn't this be:
>
> fpregs_assert_state_consistent(); /* see below */
>
> if (unlikely(cached_flags & _TIF_LOAD_FPU))
> switch_fpu_return();
hmm. This should work.
> > diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h
> > index a9caac9d4a729..e3077860f7333 100644
> > --- a/arch/x86/include/asm/fpu/api.h
> > +++ b/arch/x86/include/asm/fpu/api.h
> > @@ -27,6 +27,17 @@ extern void kernel_fpu_begin(void);
> > extern void kernel_fpu_end(void);
> > extern bool irq_fpu_usable(void);
> >
> > +#ifdef CONFIG_X86_DEBUG_FPU
> > +extern void fpregs_is_state_consistent(void);
> > +#else
> > +static inline void fpregs_is_state_consistent(void) { }
> > +#endif
>
> Can you name this something like fpregs_assert_state_consistent()?
sure.
Sebastian
Re: [PATCH 3.18 000/120] 3.18.124-stable review
On Thu, Oct 11, 2018 at 05:33:01PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.124 release. > There are 120 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 Sat Oct 13 15:25:29 UTC 2018. > Anything received after that time might be too late. > For v3.18.123-122-gfaa00f6cbce8: Build results: total: 138 pass: 138 fail: 0 Qemu test results: total: 221 pass: 221 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH v4 1/2] arm64: dts: allwinner: new board - Emlid Neutis N5
On Fri, Oct 12, 2018 at 04:39:14PM +0300, Aleksandr Aleksandrov wrote:
> Hi Andreas,
>
> Thanks for your feedback!
>
> > > + *
> > > + * Copyright (C) 2018 Aleksandr Aleksandrov
> > >
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "sun50i-h5-emlid-neutis-n5.dtsi"
> > > +
> > > +/ {
> > > + model = "Emlid Neutis N5 Developer board";
> > > + compatible = "emlid,neutis-n5-devboard",
> > > + "emlid,neutis-n5",
> >
> > You are lacking bindings definitions for these new identifiers. The
> > vendor prefix should be patch 1/3, the SoM/board compatibles 2/3 and
> > this .dts[i] patch 3/3, so that only vendor prefixes and compatibles
> > that are defined and don't result in checkpatch.pl warnings get used.
>
> Patch 2/3:
>
> commit 46dcb8632b36644cb20e6b35ede12ff0088a60eb
> Author: Aleksandr Aleksandrov
> Date: Fri Oct 12 16:22:28 2018 +0300
>
> dt-bindings: arm: sunxi: emlid,neutis-n5(-devboard)
>
> sunxi: add new compatibles for Emlid Neutis Dev board and SoM module
>
> Signed-off-by: Aleksandr Aleksandrov
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
> b/Documentation/devicetree/bindings/arm/sunxi.txt
> index e4beec3..a907e52 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -19,3 +19,5 @@ using one of the following compatible strings:
>allwinner,sun9i-a80
>allwinner,sun50i-a64
>nextthing,gr8
> + emlid,neutis-n5
> + emlid,neutis-n5-devboard
>
> Is this right place for the neutis compatibles?
No, those are for SoCs compatible. I'm not sure we ever created a
board compatible files.
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration
- On Oct 12, 2018, at 4:05 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> commit 46e0c9be206f ("kernel: tracepoints: add support for relative
> references") changes the layout of the __tracepoint_ptrs section on
> architectures supporting relative references. However, it does so
> without turning struct tracepoint * const into const int * elsewhere in
> the tracepoint code, which has the following side-effect:
Actually, the above sentence should read:
"However, it does so without turning struct tracepoint * const into const int
elsewhere in the tracepoint code [...]" (I had mistakenly worded it "const int
*").
Thanks,
Mathieu
>
> tracepoint_module_{coming,going} invoke
> tp_module_going_check_quiescent() with mod->tracepoints_ptrs
> as first argument, and computes the end address of the array
> for the second argument with:
>
> mod->tracepoints_ptrs + mod->num_tracepoints
>
> However, because the type of mod->tracepoint_ptrs in module.h
> has not been changed from pointer to int, it passes an end
> pointer which is twice larger than the array, causing out-of-bound
> array accesses.
>
> Fix this by introducing a new typedef: tracepoint_ptr_t, which
> is either "const int" on architectures that have PREL32 relocations,
> or "struct tracepoint * const" on architectures that does not have
> this feature.
>
> Also provide a new tracepoint_ptr_defer() static inline to
> encapsulate deferencing this type rather than duplicate code and
> ugly idefs within the for_each_tracepoint_range() implementation.
>
> This issue appears in 4.19-rc kernels, and should ideally be fixed
> before the end of the rc cycle.
>
> Signed-off-by: Mathieu Desnoyers
> Link:
> http://lkml.kernel.org/r/20180704083651.24360-7-ard.biesheu...@linaro.org
> Cc: Michael Ellerman
> Cc: Ingo Molnar
> Cc: Steven Rostedt (VMware)
> Cc: Ard Biesheuvel
> Cc: Arnd Bergmann
> Cc: Benjamin Herrenschmidt
> Cc: Bjorn Helgaas
> Cc: Catalin Marinas
> Cc: James Morris
> Cc: James Morris
> Cc: Jessica Yu
> Cc: Josh Poimboeuf
> Cc: Kees Cook
> Cc: Nicolas Pitre
> Cc: Paul Mackerras
> Cc: Petr Mladek
> Cc: Russell King
> Cc: "Serge E. Hallyn"
> Cc: Sergey Senozhatsky
> Cc: Thomas Garnier
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Andrew Morton
> Cc: Linus Torvalds
> Cc: Greg Kroah-Hartman
> ---
> include/linux/module.h | 2 +-
> include/linux/tracepoint-defs.h | 6 ++
> include/linux/tracepoint.h | 36 +
> kernel/tracepoint.c | 24 --
> 4 files changed, 38 insertions(+), 30 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index f807f15bebbe..cdab2451d6be 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -430,7 +430,7 @@ struct module {
>
> #ifdef CONFIG_TRACEPOINTS
> unsigned int num_tracepoints;
> - struct tracepoint * const *tracepoints_ptrs;
> + tracepoint_ptr_t *tracepoints_ptrs;
> #endif
> #ifdef HAVE_JUMP_LABEL
> struct jump_entry *jump_entries;
> diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
> index 22c5a46e9693..49ba9cde7e4b 100644
> --- a/include/linux/tracepoint-defs.h
> +++ b/include/linux/tracepoint-defs.h
> @@ -35,6 +35,12 @@ struct tracepoint {
> struct tracepoint_func __rcu *funcs;
> };
>
> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> +typedef const int tracepoint_ptr_t;
> +#else
> +typedef struct tracepoint * const tracepoint_ptr_t;
> +#endif
> +
> struct bpf_raw_event_map {
> struct tracepoint *tp;
> void*bpf_func;
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 041f7e56a289..538ba1a58f5b 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -99,6 +99,29 @@ extern void syscall_unregfunc(void);
> #define TRACE_DEFINE_ENUM(x)
> #define TRACE_DEFINE_SIZEOF(x)
>
> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> +static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> +{
> + return offset_to_ptr(p);
> +}
> +
> +#define __TRACEPOINT_ENTRY(name) \
> + asm(" .section \"__tracepoints_ptrs\", \"a\" \n" \
> + " .balign 4 \n" \
> + " .long __tracepoint_" #name " - . \n" \
> + " .previous \n")
> +#else
> +static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> +{
> + return *p;
> +}
> +
> +#define __TRACEPOINT_ENTRY(name) \
> + static tracepoint_ptr_t __tracepoint_ptr_##name __used \
> + __attribute__((section("__tracepoints_ptrs"))) = \
> + &__tracepoint_##name
> +#endif
> +
> #endif /* _LINUX_TRACEPOINT_H */
>
> /*
> @@ -253,19 +276,6 @@ extern void syscall_unregfunc(void);
> re
Re: [RFC v2 6/7] dt-binding: mips: Document Realtek SoC DT bindings
On Mon, 1 Oct 2018 13:29:51 +0300, Yasha Cherikovsky wrote: > This patch adds device tree binding doc for Realtek MIPS SoCs. > > It includes a compatible string for the Realtek RTL8186 SoC. > > Signed-off-by: Yasha Cherikovsky > Cc: Rob Herring > Cc: Mark Rutland > Cc: Ralf Baechle > Cc: Paul Burton > Cc: James Hogan > Cc: devicet...@vger.kernel.org > Cc: linux-m...@linux-mips.org > Cc: linux-kernel@vger.kernel.org > --- > Documentation/devicetree/bindings/mips/realtek.txt | 9 + > 1 file changed, 9 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mips/realtek.txt > Reviewed-by: Rob Herring
Re: [RFC v2 4/7] dt-binding: timer: Document RTL8186 SoC DT bindings
On Mon, 1 Oct 2018 13:29:49 +0300, Yasha Cherikovsky wrote: > This patch adds device tree binding doc for the > Realtek RTL8186 SoC timer controller. > > Signed-off-by: Yasha Cherikovsky > Cc: Rob Herring > Cc: Mark Rutland > Cc: Daniel Lezcano > Cc: Thomas Gleixner > Cc: Ralf Baechle > Cc: Paul Burton > Cc: James Hogan > Cc: devicet...@vger.kernel.org > Cc: linux-m...@linux-mips.org > Cc: linux-kernel@vger.kernel.org > --- > .../bindings/timer/realtek,rtl8186-timer.txt| 17 + > 1 file changed, 17 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt > Reviewed-by: Rob Herring
Re: [PATCH v3 02/11] arch/x86: Rename the RDT functions and definitions
On 10/12/2018 02:40 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/11/2018 1:33 PM, Moger, Babu wrote:
>> @@ -883,20 +883,20 @@ static int __init intel_rdt_late_init(void)
>> rdt_online = state;
>>
>> for_each_alloc_capable_rdt_resource(r)
>> -pr_info("Intel RDT %s allocation detected\n", r->name);
>> +pr_info("RESCTRL %s allocation detected\n", r->name);
>>
>> for_each_mon_capable_rdt_resource(r)
>> -pr_info("Intel RDT %s monitoring detected\n", r->name);
>> +pr_info("RESCTRL %s monitoring detected\n", r->name);
>>
>
> I'm sorry - I know it was me who suggested the change to RESCTRL but I
> clearly did not consider the final result which is (for example):
>
> resctrl: RESCTRL %s allocation detected
>
> Perhaps we could just drop that RESCTRL text?
Yes. We can drop it.
>
> Reinette
>
Re: [RFC v2 2/7] dt-binding: interrupt-controller: Document RTL8186 SoC DT bindings
On Mon, Oct 01, 2018 at 01:29:47PM +0300, Yasha Cherikovsky wrote: > This patch adds device tree binding doc for the > Realtek RTL8186 SoC interrupt controller. > > Signed-off-by: Yasha Cherikovsky > Cc: Rob Herring > Cc: Mark Rutland > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Ralf Baechle > Cc: Paul Burton > Cc: James Hogan > Cc: devicet...@vger.kernel.org > Cc: linux-m...@linux-mips.org > Cc: linux-kernel@vger.kernel.org > --- > .../interrupt-controller/realtek,rtl8186-intc | 18 ++ .txt With that, Reviewed-by: Rob Herring
Re: [PATCH v3 01/11] arch/x86: Start renaming the rdt files to more generic names
Hi Reinette,
On 10/12/2018 02:07 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/11/2018 1:33 PM, Moger, Babu wrote:
>> New generation of AMD processors start supporting RDT(or QOS) features.
>> With more than one vendors supporting these features, it seems more
>> appropriate to rename these files.
>>
>> Changed intel_rdt to resctrl where applicable.
>>
>> Signed-off-by: Babu Moger
>> ---
>> arch/x86/include/asm/{intel_rdt_sched.h => resctrl_sched.h} | 0
>> arch/x86/kernel/cpu/Makefile| 6 +++---
>> arch/x86/kernel/cpu/{intel_rdt.c => resctrl.c} | 4 ++--
>> arch/x86/kernel/cpu/{intel_rdt.h => resctrl.h} | 6 +++---
>> .../cpu/{intel_rdt_ctrlmondata.c => resctrl_ctrlmondata.c} | 2 +-
>> .../kernel/cpu/{intel_rdt_monitor.c => resctrl_monitor.c} | 2 +-
>> .../cpu/{intel_rdt_pseudo_lock.c => resctrl_pseudo_lock.c} | 6 +++---
>> ..._rdt_pseudo_lock_event.h => resctrl_pseudo_lock_event.h} | 2 +-
>> .../kernel/cpu/{intel_rdt_rdtgroup.c => resctrl_rdtgroup.c} | 4 ++--
>> arch/x86/kernel/process_32.c| 2 +-
>> arch/x86/kernel/process_64.c| 2 +-
>> 11 files changed, 18 insertions(+), 18 deletions(-)
>> rename arch/x86/include/asm/{intel_rdt_sched.h => resctrl_sched.h} (100%)
>> rename arch/x86/kernel/cpu/{intel_rdt.c => resctrl.c} (99%)
>> rename arch/x86/kernel/cpu/{intel_rdt.h => resctrl.h} (99%)
>> rename arch/x86/kernel/cpu/{intel_rdt_ctrlmondata.c =>
>> resctrl_ctrlmondata.c} (99%)
>> rename arch/x86/kernel/cpu/{intel_rdt_monitor.c => resctrl_monitor.c} (99%)
>> rename arch/x86/kernel/cpu/{intel_rdt_pseudo_lock.c =>
>> resctrl_pseudo_lock.c} (99%)
>> rename arch/x86/kernel/cpu/{intel_rdt_pseudo_lock_event.h =>
>> resctrl_pseudo_lock_event.h} (95%)
>> rename arch/x86/kernel/cpu/{intel_rdt_rdtgroup.c => resctrl_rdtgroup.c}
>> (99%)
>>
>
> I missed this earlier ... this change creates a need to change the
> MAINTAINERS file. There were some other things that a run of
Yes. I see that now. We need to update MAINTAINERS file.
The file name Documentation/x86/intel_rdt_ui.txt needs rename. Also
contents of the file needs some minor changes. Will take care of it in
next revision.
> "checkpatch.pl --strict" picked up in the other patches that you could
> consider.
Yes. With --strict I see some more warnings. Will try to fix most of it.
Sorry, I did not run --strict before. There are couple of "line over 80
characters" warnings which are difficult to handle. I will skip those.
>
> Reinette
>
[PATCH for 4.19] tracepoint: Fix: out-of-bound tracepoint array iteration
commit 46e0c9be206f ("kernel: tracepoints: add support for relative
references") changes the layout of the __tracepoint_ptrs section on
architectures supporting relative references. However, it does so
without turning struct tracepoint * const into const int * elsewhere in
the tracepoint code, which has the following side-effect:
tracepoint_module_{coming,going} invoke
tp_module_going_check_quiescent() with mod->tracepoints_ptrs
as first argument, and computes the end address of the array
for the second argument with:
mod->tracepoints_ptrs + mod->num_tracepoints
However, because the type of mod->tracepoint_ptrs in module.h
has not been changed from pointer to int, it passes an end
pointer which is twice larger than the array, causing out-of-bound
array accesses.
Fix this by introducing a new typedef: tracepoint_ptr_t, which
is either "const int" on architectures that have PREL32 relocations,
or "struct tracepoint * const" on architectures that does not have
this feature.
Also provide a new tracepoint_ptr_defer() static inline to
encapsulate deferencing this type rather than duplicate code and
ugly idefs within the for_each_tracepoint_range() implementation.
This issue appears in 4.19-rc kernels, and should ideally be fixed
before the end of the rc cycle.
Signed-off-by: Mathieu Desnoyers
Link: http://lkml.kernel.org/r/20180704083651.24360-7-ard.biesheu...@linaro.org
Cc: Michael Ellerman
Cc: Ingo Molnar
Cc: Steven Rostedt (VMware)
Cc: Ard Biesheuvel
Cc: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: Bjorn Helgaas
Cc: Catalin Marinas
Cc: James Morris
Cc: James Morris
Cc: Jessica Yu
Cc: Josh Poimboeuf
Cc: Kees Cook
Cc: Nicolas Pitre
Cc: Paul Mackerras
Cc: Petr Mladek
Cc: Russell King
Cc: "Serge E. Hallyn"
Cc: Sergey Senozhatsky
Cc: Thomas Garnier
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Greg Kroah-Hartman
---
include/linux/module.h | 2 +-
include/linux/tracepoint-defs.h | 6 ++
include/linux/tracepoint.h | 36 +
kernel/tracepoint.c | 24 --
4 files changed, 38 insertions(+), 30 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index f807f15bebbe..cdab2451d6be 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -430,7 +430,7 @@ struct module {
#ifdef CONFIG_TRACEPOINTS
unsigned int num_tracepoints;
- struct tracepoint * const *tracepoints_ptrs;
+ tracepoint_ptr_t *tracepoints_ptrs;
#endif
#ifdef HAVE_JUMP_LABEL
struct jump_entry *jump_entries;
diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
index 22c5a46e9693..49ba9cde7e4b 100644
--- a/include/linux/tracepoint-defs.h
+++ b/include/linux/tracepoint-defs.h
@@ -35,6 +35,12 @@ struct tracepoint {
struct tracepoint_func __rcu *funcs;
};
+#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
+typedef const int tracepoint_ptr_t;
+#else
+typedef struct tracepoint * const tracepoint_ptr_t;
+#endif
+
struct bpf_raw_event_map {
struct tracepoint *tp;
void*bpf_func;
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 041f7e56a289..538ba1a58f5b 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -99,6 +99,29 @@ extern void syscall_unregfunc(void);
#define TRACE_DEFINE_ENUM(x)
#define TRACE_DEFINE_SIZEOF(x)
+#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
+static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
+{
+ return offset_to_ptr(p);
+}
+
+#define __TRACEPOINT_ENTRY(name) \
+ asm(" .section \"__tracepoints_ptrs\", \"a\" \n" \
+ " .balign 4 \n" \
+ " .long __tracepoint_" #name " - . \n" \
+ " .previous \n")
+#else
+static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
+{
+ return *p;
+}
+
+#define __TRACEPOINT_ENTRY(name)\
+ static tracepoint_ptr_t __tracepoint_ptr_##name __used \
+ __attribute__((section("__tracepoints_ptrs"))) = \
+ &__tracepoint_##name
+#endif
+
#endif /* _LINUX_TRACEPOINT_H */
/*
@@ -253,19 +276,6 @@ extern void syscall_unregfunc(void);
return static_key_false(&__tracepoint_##name.key); \
}
-#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
-#define __TRACEPOINT_ENTRY(name) \
- asm(" .section \"__tracepoints_ptrs\", \"a\" \n" \
- " .balign 4 \n" \
- " .long __tracepoint_" #name " - . \n" \
- " .previous \n")
-#else
-#define __TRACEPOINT_ENTRY(name)
Re: [git pull] Input updates for v4.19-rc7
On Fri, Oct 12, 2018 at 12:51:52PM +0200, Greg KH wrote: > On Thu, Oct 11, 2018 at 04:57:36PM -0700, Dmitry Torokhov wrote: > > Hi Greg, > > > > Please pull from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus > > > > to receive updates for the input subsystem: > > > > - we added a few scheduling points into various input interfaces to > > ensure that large writes will not cause RCU stalls > > > > - fixed configuring PS/2 keyboards as wakeup devices on newer platforms > > That feels like a really "late" contribution, I hope it goes well :) Yeah, that is true, but I'd be marking it for 4.19 stable anyway as we do want newer devices to wake up on keyboard activity, so there was no reason not to send it now. If we have to revert we'd be reverting everywhere anyways. FWIW Daniel posted the patch a while ago, we just have been working out kinks in handling builds with different config options. Thanks. -- Dmitry
Re: [RFC][PATCH] x86: ptrace: Add function argument access API
On Fri, 12 Oct 2018 11:21:28 -0700
Andy Lutomirski wrote:
> On Fri, Oct 12, 2018 at 9:26 AM Steven Rostedt wrote:
> >
> >
> > Anyone have any issues with this patch?
> >
>
> I'm conceptually okay with it. That being said,
> regs_within_kernel_stack(), which you're indirectly using, is
> off-by-a-few. And updating it to use probe_kernel_read() might be
> nice for robustness.
>
Something like this?
-- Steve
From: "Steven Rostedt (VMware)"
Date: Fri, 12 Oct 2018 15:44:20 -0400
Subject: [PATCH] x86: ptrace.h: Add regs_get_kernel_stack_nth_safe() function
Andy had some concerns about using regs_get_kernel_stack_nth() in a new
function regs_get_kernel_argument() as if there's any error in the stack
code, it could cause a bad memory access. Instead, add a new function called
regs_get_kernel_stack_nth_safe() that does a probe_kernel_read() on the
stack address to be extra careful in accessing the memory. To share the
code, regs_get_kernel_stack_nth_addr() was added to just return the stack
address (or NULL if not on the stack), that both regs_get_kernel_stack_nth()
and the _safe() version can use.
Link:
http://lkml.kernel.org/r/calcetrxn9zktb9i1lp3qofcpqzhf34bdkuz5d3n0ucmrr+v...@mail.gmail.com
Requested-by: Andy Lutomirski
Signed-off-by: Steven Rostedt (VMware)
---
arch/x86/include/asm/ptrace.h | 57 ---
1 file changed, 54 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index c2304b25e2fd..8df7ab6a17c5 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -237,6 +237,27 @@ static inline int regs_within_kernel_stack(struct pt_regs
*regs,
}
/**
+ * regs_get_kernel_stack_nth_addr() - get the address of the Nth entry on stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @n: stack entry number.
+ *
+ * regs_get_kernel_stack_nth() returns the address of the @n th entry of the
+ * kernel stack which is specified by @regs. If the @n th entry is NOT in
+ * the kernel stack, this returns NULL.
+ */
+static inline unsigned long *regs_get_kernel_stack_nth_addr(struct pt_regs
*regs,
+ unsigned int n)
+{
+ unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+
+ addr += n;
+ if (regs_within_kernel_stack(regs, (unsigned long)addr))
+ return addr;
+ else
+ return NULL;
+}
+
+/**
* regs_get_kernel_stack_nth() - get Nth entry of the stack
* @regs: pt_regs which contains kernel stack pointer.
* @n: stack entry number.
@@ -248,14 +269,44 @@ static inline int regs_within_kernel_stack(struct pt_regs
*regs,
static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
unsigned int n)
{
- unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
- addr += n;
- if (regs_within_kernel_stack(regs, (unsigned long)addr))
+ unsigned long *addr;
+
+ addr = regs_get_kernel_stack_nth_addr(regs, n);
+ if (addr)
return *addr;
else
return 0;
}
+/* To avoid include hell, we can't include uaccess.h */
+extern long probe_kernel_read(void *dst, const void *src, size_t size);
+
+/**
+ * regs_get_kernel_stack_nth_safe() - safely get Nth entry of the stack
+ * @regs: pt_regs which contains kernel stack pointer.
+ * @n: stack entry number.
+ *
+ * Same as regs_get_kernel_stack_nth(), but references the stack value
+ * with a probe_kernel_read() in case there's a bad stack pointer, it
+ * will not cause a bad memory access. If the @n is not on the stack,
+ * or a bad memory access happened, it returns zero.
+ */
+static inline unsigned long regs_get_kernel_stack_nth_safe(struct pt_regs
*regs,
+ unsigned int n)
+{
+ unsigned long *addr;
+ unsigned long val;
+ long ret;
+
+ addr = regs_get_kernel_stack_nth_addr(regs, n);
+ if (addr) {
+ ret = probe_kernel_read(&val, addr, sizeof(val));
+ if (!ret)
+ return val;
+ }
+ return 0;
+}
+
/**
* regs_get_kernel_argument() - get Nth function argument in kernel
* @regs: pt_regs of that context
--
2.13.6
Re: [PATCH v4 5/5] clk: RK808: add RK809 and RK817 support.
Quoting Tony Xie (2018-09-03 03:04:00) > RK809 and RK817 are power management IC chips for multimedia products. > most of their functions and registers are same, including the clkout > funciton. > > Signed-off-by: Tony Xie > --- Acked-by: Stephen Boyd
Re: [PATCH 00/16] clk: at91: Rework DT bindings
Quoting Alexandre Belloni (2018-10-12 11:40:17) > On 12/10/2018 11:28:06-0700, Stephen Boyd wrote: > > Quoting Stephen Boyd (2018-08-31 10:45:30) > > > Quoting Alexandre Belloni (2018-08-16 04:47:55) > > > > On 27/07/2018 10:03:22-0700, Stephen Boyd wrote: > > > > > Quoting Alexandre Belloni (2018-07-17 15:27:41) > > > > > > This is the promised rework of the at91 PMC clocks driver. It is > > > > > > mainly > > > > > > necessary to remove the DTC warnings but it also complies with the > > > > > > CCF > > > > > > rule that there should be one node per controller instead of one > > > > > > node > > > > > > per clock. > > > > > > > > > > > > This only handles the PMC, I'm planning to also rework the SCKC > > > > > > bindings > > > > > > later (without breaking the DT ABI). > > > > > > > > > > > > The series is based on top of clk-next plus at91-dt so I don't > > > > > > think it > > > > > > is convenient to have it this cycle. However, I would really like to > > > > > > ensure we agree on the new bindings this cycle before converting > > > > > > all the > > > > > > other platforms as this is a bit tedious. > > > > > > > > > > > > The first two patches are actually fixes and may be considered for > > > > > > this > > > > > > cycle. > > > > > > > > > > > > One nice note: > > > > > > at91-sama5d2_xplained.dtb goes from 29351 bytes to 22082 bytes > > > > > > > > > > Patches look mostly good. Rob is happy with the bindings and so am I. > > > > > > > > > > One general question is why the drivers can't be moved to real > > > > > platform > > > > > drivers instead of using OF_CLK_DECLARE? > > > > > > > > > > > > > I tried, this makes the clocksource drivers fail with -EPROBE_DEFER and > > > > so the kernel just stops there. > > > > > > > > > > Ok. We have CLK_OF_DECLARE_DRIVER for that. Can you use that? > > > > > > > I assume this will be resent. I haven't seen anything yet though. > > > > It will, would you be willing to take it for this cycle if I manage to > send it on Monday? (it seems that we will have an -rc8). > Well there are fixes to be made, so go at your own pace and don't stress yourself to deliver it on Monday. I plan to stop picking most things early next week.
RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Quoting Anson Huang (2018-10-08 01:34:59) > > Quoting Anson Huang (2018-09-03 00:20:53) > > > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote: > > > > > > Quoting Peng Fan (2018-08-12 18:15:41) > > > > > >> Hi Anson, > > > > > >> > > > > > > -Original Message- > > > > > > From: Anson Huang > > > > > > Sent: 2018年8月8日 12:39 > > > > > > To: shawn...@kernel.org; s.ha...@pengutronix.de; > > > > > > ker...@pengutronix.de; Fabio Estevam > > > > > > ; mturque...@baylibre.com; > > > > > > sb...@kernel.org; linux-arm-ker...@lists.infradead.org; > > > > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > > Cc: dl-linux-imx > > > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on > > > > > > array > > > > > > > > > > > > Clock framework will enable those clocks registered with > > > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array > > > > > > during clock > > > > > initialization now. > > > > > > > > > > Will it be more flexible to parse dts saying "critical-clocks = > > > > > " > > > > > or "init-on-arrary=" > > > > > and enable those clocks? > > > > > >>> > > > > > >>> Parsing the clocks arrays from dtb is another way of enabling > > > > > >>> critical clocks, but for current i.MX6/7 platforms, we > > > > > >>> implement it in same way as most of other SoCs, currently I > > > > > >>> did NOT see any necessity of putting them in dtb, just adding > > > > > >>> flag during clock registering is more simple, if there is any > > > > > >>> special requirement for different clocks set to be enabled, > > > > > >>> then we can add support to enable > > > > the method of parsing critical-clocks from dtb. Just my two cents. > > > > > >> > > > > > >> Thinking about OP-TEE want to use one device, but it's clocks > > > > > >> are registered by Linux, because there is no module in Linux > > > > > >> side use it, it will shutdown the clock, which cause OP-TEE > > > > > >> could not access the > > > > device. > > > > > >> > > > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag > > > > > >> to make sure the clocks are not shutdown by Linux. > > > > > >> > > > > > >> However adding a new property in clk node and let driver code > > > > > >> parse the dts, there is no need to modify clk driver code when > > > > > >> OP-TEE needs > > > > another device clock. > > > > > >> > > > > > > > > > > > > If OP-TEE needs linux to keep things on then why can't the > > > > > > OP-TEE driver in Linux probe, acquire clocks, and keep the clks > > > > > > enabled > > forever? > > > > > > > > > > Sounds reasonable, but how could this be done without introducing > > > > > platform-specific stuff in the OP-TEE driver? > > > > > > > > > > > > > Why is that a goal? > > > > > > I do NOT think we should consider such case in this patch series, > > > whatever OP-TEE needs for its own feature, it should do necessary > > > operations > > either in its driver or somewhere else by adding new patch. > > > > > > > Why can't we add clks to the op-tee node in DT's /firmware container? > > Then any clks in there can be turned on forever and left enabled by the > > linux > > driver? > > I did NOT run op-tee with Linux-next kernel before, can you advise more? Neither have I, so I can't advise more. > And I think if op-tee has such requirement, > can we have another patch to cover it? Yes. > I believe all other i.MX platforms also have same > requirements if considering op-tee support, so I think it should be another > topic, what do you think? > I'm going to drop these patches from my review queue. Please resend them and please include the op-tee patches too.
Re: [PATCH 04/11] x86/fpu: eager switch PKRU state
On 10/12/2018 11:09 AM, Andy Lutomirski wrote: > But maybe WRPKRU is more expensive than RDPKRU and a branch? Yeah, it is more expensive. It has a higher cycle cost and it's also practically a (light) speculation barrier.
Re: [PATCH 10/11] x86/fpu: prepare copy_fpstate_to_sigframe for TIF_LOAD_FPU
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> From: Rik van Riel
>
> If TIF_LOAD_FPU is set, then the registers are saved (not loaded). In that
> case
> we skip the saving part.
This sentence hurts my brain.
"If TIF_LOAD_FPU is set the registers are ... not loaded"
I think that means that something could use some better naming.
Should TIF_LOAD_FPU be TIF_NEED_FPU_LOAD, perhaps?
> Signed-off-by: Rik van Riel
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> arch/x86/kernel/fpu/signal.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> index c8f5ff58578ed..979dcd1ed82e0 100644
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -155,13 +155,17 @@ int copy_fpstate_to_sigframe(void __user *buf, void
> __user *buf_fx, int size)
> sizeof(struct user_i387_ia32_struct), NULL,
> (struct _fpstate_32 __user *) buf) ? -1 : 1;
>
> - /* Update the thread's fxstate to save the fsave header. */
> - if (ia32_fxstate) {
> - copy_fxregs_to_kernel(fpu);
> - } else {
> - copy_fpregs_to_fpstate(fpu);
> - fpregs_deactivate(fpu);
> + __fpregs_changes_begin();
> + if (!test_thread_flag(TIF_LOAD_FPU)) {
This needs commenting, please.
If we do not need to load the FPU at return to userspace, it means the
state is in the the registers, not the buffer. So, update the buffer to
match the registers.
> + /* Update the thread's fxstate to save the fsave header. */
> + if (ia32_fxstate) {
> + copy_fxregs_to_kernel(fpu);
> + } else {
> + copy_fpregs_to_fpstate(fpu);
> + fpregs_deactivate(fpu);
> + }
> }
> + __fpregs_changes_end();
Do we really need the __fpregs_changes_*() abstraction for this single
call site?
Re: [PATCH v3 02/11] arch/x86: Rename the RDT functions and definitions
Hi Babu,
On 10/11/2018 1:33 PM, Moger, Babu wrote:
> @@ -883,20 +883,20 @@ static int __init intel_rdt_late_init(void)
> rdt_online = state;
>
> for_each_alloc_capable_rdt_resource(r)
> - pr_info("Intel RDT %s allocation detected\n", r->name);
> + pr_info("RESCTRL %s allocation detected\n", r->name);
>
> for_each_mon_capable_rdt_resource(r)
> - pr_info("Intel RDT %s monitoring detected\n", r->name);
> + pr_info("RESCTRL %s monitoring detected\n", r->name);
>
I'm sorry - I know it was me who suggested the change to RESCTRL but I
clearly did not consider the final result which is (for example):
resctrl: RESCTRL %s allocation detected
Perhaps we could just drop that RESCTRL text?
Reinette
Re: [PATCH V2 1/5] dt-bindings: usb: xhci-tegra: Add power-domain details
On Fri, 28 Sep 2018 15:11:46 +0100, Jon Hunter wrote: > Add details for power-domains to the Tegra xHCI bindings so that > generic power-domains can be used for inconjunction with the xHCI > driver. > > Signed-off-by: Jon Hunter > --- > Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 8 > 1 file changed, 8 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v2 2/3] dt-bindings: arm: omap: Add binding for Moxa UC-2101 open platform
On Fri, 28 Sep 2018 18:47:38 +0800, =?UTF-8?q?SZ=20Lin=20=28=E6=9E=97=E4=B8=8A=E6=99=BA=29?= wrote: > Add devicetree binding for Moxa UC-2101 open platform > > Signed-off-by: SZ Lin (林上智) > --- > Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v3 6/7] mfd: axp20x: Add AC power supply cell for AXP813
Hi Oskari, On Mon, Oct 08, 2018 at 09:19:07PM +0300, Oskari Lemmela wrote: > As axp20x-ac-power-supply now supports AXP813, add a cell for it. > Reviewed-by: Quentin Schulz Thanks, Quentin signature.asc Description: PGP signature
Re: [PATCH v3 4/7] arm64: dts: allwinner: a64: sopine: enable power supplies
Hi Oskari, On Mon, Oct 08, 2018 at 09:19:05PM +0300, Oskari Lemmela wrote: > Sopine baseboard have ACIN and battery connectors. > Reviewed-by: Quentin Schulz Thanks, Quentin signature.asc Description: PGP signature
Re: [PATCH v2 1/2] dt-bindings: i2c-omap: Add new compatible for AM654 SoCs
On Fri, 28 Sep 2018 10:55:56 +0530, Vignesh R wrote: > AM654 SoCs have same I2C IP as OMAP SoCs. Add new compatible to > handle AM654 SoCs. While at that reformat the existing compatible list > for older SoCs to list one valid compatible per line. > > Signed-off-by: Vignesh R > --- > > v2: Reformat compatible existing compatible list. > > Documentation/devicetree/bindings/i2c/i2c-omap.txt | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v3 3/7] arm64: dts: allwinner: axp803: add AC and battery power supplies
Hi Oskari, On Mon, Oct 08, 2018 at 09:19:04PM +0300, Oskari Lemmela wrote: > AXP803 is compatible with AXP813. Add DT nodes ADC, GPIO, > AC and battery power supplies. > Reviewed-by: Quentin Schulz Thanks, Quentin signature.asc Description: PGP signature
Re: [PATCH v3 1/7] dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
Hi Oskari, On Mon, Oct 08, 2018 at 09:19:02PM +0300, Oskari Lemmela wrote: > The AXP803/AXP813 AC power supply can limit input current and voltage. > Reviewed-by: Quentin Schulz Thanks, Quentin signature.asc Description: PGP signature
Re: [PATCH v3 2/7] ARM: dts: axp81x: add AC power supply subnode
Hi Oskari, On Mon, Oct 08, 2018 at 09:19:03PM +0300, Oskari Lemmela wrote: > Add AC power supply subnode for AXP81X PMIC. > Reviewed-by: Quentin Schulz Thanks, Quentin signature.asc Description: PGP signature
Re: [PATCH v2] dt-bindings: input: pwm-vibrator: correct pwms in example
On Wed, 26 Sep 2018 20:48:58 -0400, Brian Masney wrote: > In the example for the pwm-vibrator bindings, pwm8 is the direction pin, > and pwm9 is the enable pin. The pwms on the vibrator node has these two > values swapped so this patch corrects it. > > Signed-off-by: Brian Masney > --- > Changes since v1: > - Swapped the pwms values instead of the pwm-names values since enable > is required and direction is optional. Based on feedback from > Rob Herring. > > Documentation/devicetree/bindings/input/pwm-vibrator.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring
[PATCH 2/2] arm64: acpi: Prepare for longer MADTs
The BAD_MADT_GICC_ENTRY check is a little too strict because it rejects MADT entries that don't match the currently known lengths. We should remove this restriction to avoid problems if the table length changes. Future code which might depend on additional fields should be written to validate those fields before using them, rather than trying to globally check known MADT version lengths. Signed-off-by: Jeremy Linton --- arch/arm64/include/asm/acpi.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index 709208dfdc8b..4d0946bd485a 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -22,12 +22,12 @@ #include /* Macros for consistency checks of the GICC subtable of MADT */ -#define ACPI_MADT_GICC_LENGTH \ - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) +#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ + struct acpi_madt_generic_interrupt, efficiency_class) #define BAD_MADT_GICC_ENTRY(entry, end) \ - (!(entry) || (entry)->header.length != ACPI_MADT_GICC_LENGTH || \ - (unsigned long)(entry) + ACPI_MADT_GICC_LENGTH > (end)) + (!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \ + (unsigned long)(entry) + (entry)->header.length > (end)) /* Basic configuration for ACPI */ #ifdef CONFIG_ACPI -- 2.14.3
Re: [PATCH v2] of: base: Change logic in of_alias_get_alias_list()
On Fri, Oct 12, 2018 at 12:43 AM Michal Simek wrote:
>
> Check compatible string first before setting up bit in bitmap to also
> cover cases that allocated bitfield is not big enough.
> Show warning about it but let driver to continue to work with allocated
> bitfield to keep at least some devices (included console which
> is commonly close to serial0) to work.
>
> Fixes: b1078c355d76 ("of: base: Introduce of_alias_get_alias_list() to check
> alias IDs")
> Fixes: ae1cca3fa347 ("serial: uartps: Change uart ID port allocation")
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Use EOVERFLOW instead of EINVAL - Rob
Reviewed-by: Rob Herring
[PATCH 1/2] perf: arm_spe: Enable automatic DT loading
When built as a module, the spe driver isn't automatically
loaded on DT systems. Add the MODULE_DEVICE_TABLE entry.
Signed-off-by: Jeremy Linton
---
drivers/perf/arm_spe_pmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index 54ec278d2fc4..18d61077b157 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -1169,6 +1169,7 @@ static const struct of_device_id arm_spe_pmu_of_match[] =
{
{ .compatible = "arm,statistical-profiling-extension-v1", .data = (void
*)1 },
{ /* Sentinel */ },
};
+MODULE_DEVICE_TABLE(of, arm_spe_pmu_of_match);
static int arm_spe_pmu_device_dt_probe(struct platform_device *pdev)
{
--
2.14.3
[RFT PATCH] mmc: pwrseq_simple: Fix incorrect handling of GPIO bitmap
Commit b9762bebc633 ("gpiolib: Pass bitmaps, not integer arrays, to
get/set array") changed the way GPIO values are passed to
gpiod_get/set_array_value() and friends. The new code introduced into
mmc_pwrseq_simple_set_gpios_value() incorrectly interpretes the 'value'
argument as a bitmap of GPIO values and assigns it directly to the
'values' bitmap variable passed to gpiod_set_array_value_cansleep()
instead of filling that bitmap with bits equal to the 'value' argument.
As a result, only member 0 of the array is handled correctly.
Moreover, wrong assumption is taken about the 'values' bitmap size not
exceding the number of bits of the 'value' argument type.
Fix it.
Signed-off-by: Janusz Krzysztofik
---
Hi,
I think that patch has been missed while we were resolving issues
related to GPIO fast bitmap processing. Since all issues other than the
one addreessed by this patch have been been hopefully identified and
fixed, GPIO tree seems now to be in good shape in regard to that.
However, I believe pwrseq_simple is still broken. Hence, I'm
resubmitting this patch to Ulf for inclusion in MMC tree, Cc: many other
people who are kindly requested to test it if possible.
I've identified the following DT files representing devices which may be
affected (have more than one GPIO assigned to pwrseq_simple):
- arch/arm/boot/dts/imx6qdl-sr-som-brcm.dtsi
- arch/arm/boot/dts/exynos5250-snow-common.dtsi
- arch/arm/boot/dts/imx6sl-warp.dts
- arch/arm/boot/dts/omap3-igep0030.dts
- arch/arm/boot/dts/omap3-igep0020.dts
- arch/arm/boot/dts/rk3036-kylin.dts
- arch/arm64/boot/dts/rockchip/rk3368-r88.dts
- arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
Please start with checking if pwrseq_simple from linux-next works for
you and if not, please test if this patch fixes the issue.
Thanks,
Janusz
drivers/mmc/core/pwrseq_simple.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 7f882a2bb872..ece34c734693 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -40,13 +40,22 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
mmc_pwrseq_simple *pwrseq,
struct gpio_descs *reset_gpios = pwrseq->reset_gpios;
if (!IS_ERR(reset_gpios)) {
- DECLARE_BITMAP(values, BITS_PER_TYPE(value));
+ unsigned long *values;
int nvalues = reset_gpios->ndescs;
- values[0] = value;
+ values = bitmap_alloc(nvalues, GFP_KERNEL);
+ if (!values)
+ return;
+
+ if (value)
+ bitmap_fill(values, nvalues);
+ else
+ bitmap_zero(values, nvalues);
gpiod_set_array_value_cansleep(nvalues, reset_gpios->desc,
reset_gpios->info, values);
+
+ kfree(values);
}
}
--
2.16.4
Re: [PATCH v3 01/11] arch/x86: Start renaming the rdt files to more generic names
Hi Babu,
On 10/11/2018 1:33 PM, Moger, Babu wrote:
> New generation of AMD processors start supporting RDT(or QOS) features.
> With more than one vendors supporting these features, it seems more
> appropriate to rename these files.
>
> Changed intel_rdt to resctrl where applicable.
>
> Signed-off-by: Babu Moger
> ---
> arch/x86/include/asm/{intel_rdt_sched.h => resctrl_sched.h} | 0
> arch/x86/kernel/cpu/Makefile| 6 +++---
> arch/x86/kernel/cpu/{intel_rdt.c => resctrl.c} | 4 ++--
> arch/x86/kernel/cpu/{intel_rdt.h => resctrl.h} | 6 +++---
> .../cpu/{intel_rdt_ctrlmondata.c => resctrl_ctrlmondata.c} | 2 +-
> .../kernel/cpu/{intel_rdt_monitor.c => resctrl_monitor.c} | 2 +-
> .../cpu/{intel_rdt_pseudo_lock.c => resctrl_pseudo_lock.c} | 6 +++---
> ..._rdt_pseudo_lock_event.h => resctrl_pseudo_lock_event.h} | 2 +-
> .../kernel/cpu/{intel_rdt_rdtgroup.c => resctrl_rdtgroup.c} | 4 ++--
> arch/x86/kernel/process_32.c| 2 +-
> arch/x86/kernel/process_64.c| 2 +-
> 11 files changed, 18 insertions(+), 18 deletions(-)
> rename arch/x86/include/asm/{intel_rdt_sched.h => resctrl_sched.h} (100%)
> rename arch/x86/kernel/cpu/{intel_rdt.c => resctrl.c} (99%)
> rename arch/x86/kernel/cpu/{intel_rdt.h => resctrl.h} (99%)
> rename arch/x86/kernel/cpu/{intel_rdt_ctrlmondata.c =>
> resctrl_ctrlmondata.c} (99%)
> rename arch/x86/kernel/cpu/{intel_rdt_monitor.c => resctrl_monitor.c} (99%)
> rename arch/x86/kernel/cpu/{intel_rdt_pseudo_lock.c =>
> resctrl_pseudo_lock.c} (99%)
> rename arch/x86/kernel/cpu/{intel_rdt_pseudo_lock_event.h =>
> resctrl_pseudo_lock_event.h} (95%)
> rename arch/x86/kernel/cpu/{intel_rdt_rdtgroup.c => resctrl_rdtgroup.c} (99%)
>
I missed this earlier ... this change creates a need to change the
MAINTAINERS file. There were some other things that a run of
"checkpatch.pl --strict" picked up in the other patches that you could
consider.
Reinette
