Re: [PATCH v2 1/3] usb: gadget: f_fs: virtual address mapping
On 07/25/2014 04:18 PM, Michal Nazarewicz wrote: > On Fri, Jul 25 2014, Robert Baldyga wrote: >> This patch adds virtual endpoint address mapping to functionfs. >> >> So far endpoint addresses given by user through endpoint descriptors >> were ignored, and replaced by physical endpoint addresses. Endpoint >> address in wIndex field of setup requesti, addressed to endpoint, was >> the physical endpoint address, and names of files in functionfs >> directory was numered in order, and were the same as indexes of >> ffs_epfile in epfile array. In result user has no way to indicate >> which file in functionfs is associated with which particular >> requested endpoint. He also didn't know which endpoint is recipient >> of setup request. > > Couldn't that be solved by simply providing the mapping to user space? There would be only small differences in code (add mapping instead of changing file names) so why would we not want do it in more intuitive way? > >> There was also one more problem - if endpoint addresses in descriptors >> were non-consecutive, there were created redundant files, which could >> cause problems in kernel, when user tryed to read/write to them. >> It was result of fact that maximum endpoint address was taken as >> total number of endpoints in funciton. > > This is kinda unrelated though. I mean it's a separate bug. Yes, but it can be fixed by the way, as a side effect, so there is no sense (and probably no simple way) to move it into separate patch. > >> This patch solves this problems by introducing virtual endpoint address >> mapping. Now each function has separate endpoint address space. Numbers >> of endpoint files in functionfs and addresses in setup requests are >> mapped to addresses choosen by user in endpoint descriptors. >> >> It also introduces additional testing if desctiptors given by user are >> consistent - if number of endpoints and their addresses in each speed >> are the same. >> >> Signed-off-by: Robert Baldyga >> --- >> drivers/usb/gadget/f_fs.c | 78 >> +++ >> drivers/usb/gadget/u_fs.h | 2 ++ >> 2 files changed, 68 insertions(+), 12 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug 24912 - I think this one fell through the cracks a bit
On Sun, Jul 27, 2014 at 8:11 PM, Steven Stewart-Gallus wrote: > Hello, > > I think that bug 2491 at > https://bugzilla.kernel.org/show_bug.cgi?id=24912 sort of fell through > the cracks and I'm not sure as many people are aware of it as there > could be. This bug is that one can't mount bind mounts readonly but > can only remount them readonly which is insufficient for recursive > bind mounts and certain kinds of sandboxing. Also the bind mount fails > silenty without giving an error which is never a good idea. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Steven, It's late now but I will look into this tomorrow and see if I can trace the issue and may be write a solution. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH ] ARM: pxa: fix section mismatch warning for pxa_timer_nodt_init
On 07/26/2014 08:50 PM, Arnd Bergmann wrote:
commit a38b1f60b5245a3 ("ARM: pxa: Add non device-tree timer link to
clocksource") introduced a harmless section mismatch warning for
all pxa platforms, by introducing a new pxa_timer_init() function
that is not marked __init but that calls pxa_timer_nodt_init(),
which is. The function is only called at init time, so it is safe
to also annotate it this way.
Signed-off-by: Arnd Bergmann
---
Daniel, please apply on top of Robert's patch series.
Applied thanks!
-- Daniel
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 630fa916bbc6..04b013fbc98f 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -61,7 +61,7 @@ EXPORT_SYMBOL(get_clock_tick_rate);
/*
* For non device-tree builds, keep legacy timer init
*/
-void pxa_timer_init(void)
+void __init pxa_timer_init(void)
{
pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x40a0),
get_clock_tick_rate());
--
Facebook |
Twitter |
Re: [PATCH v2 3/5] ARM: add IPI tracepoints
On 07/25/2014 10:05 PM, Nicolas Pitre wrote:
The strings used to list IPIs in /proc/interrupts are reused for tracing
purposes.
While at it, prevent a negative ipinr from escaping the range check
in handle_IPI().
Signed-off-by: Nicolas Pitre
Acked-by: Steven Rostedt
Acked-by: Daniel Lezcano
---
arch/arm/kernel/smp.c | 70 ++-
1 file changed, 42 insertions(+), 28 deletions(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7c4fada440..9388a3d479 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -47,6 +47,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include
+
/*
* as from 2.5, kernels no longer have an init_tasks structure
* so we need some other way of telling a new secondary core
@@ -430,38 +433,15 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
}
}
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
+static void (*__smp_cross_call)(const struct cpumask *, unsigned int);
void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned
int))
{
- if (!smp_cross_call)
- smp_cross_call = fn;
-}
-
-void arch_send_call_function_ipi_mask(const struct cpumask *mask)
-{
- smp_cross_call(mask, IPI_CALL_FUNC);
-}
-
-void arch_send_wakeup_ipi_mask(const struct cpumask *mask)
-{
- smp_cross_call(mask, IPI_WAKEUP);
-}
-
-void arch_send_call_function_single_ipi(int cpu)
-{
- smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+ if (!__smp_cross_call)
+ __smp_cross_call = fn;
}
-#ifdef CONFIG_IRQ_WORK
-void arch_irq_work_raise(void)
-{
- if (is_smp())
- smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
-}
-#endif
-
-static const char *ipi_types[NR_IPI] = {
+static const char *ipi_types[NR_IPI] __tracepoint_string = {
#define S(x,s)[x] = s
S(IPI_WAKEUP, "CPU wakeup interrupts"),
S(IPI_TIMER, "Timer broadcast interrupts"),
@@ -473,6 +453,12 @@ static const char *ipi_types[NR_IPI] = {
S(IPI_COMPLETION, "completion interrupts"),
};
+static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
+{
+ trace_ipi_raise(target, ipi_types[ipinr]);
+ __smp_cross_call(target, ipinr);
+}
+
void show_ipi_list(struct seq_file *p, int prec)
{
unsigned int cpu, i;
@@ -499,6 +485,29 @@ u64 smp_irq_stat_cpu(unsigned int cpu)
return sum;
}
+void arch_send_call_function_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_CALL_FUNC);
+}
+
+void arch_send_wakeup_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_WAKEUP);
+}
+
+void arch_send_call_function_single_ipi(int cpu)
+{
+ smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+}
+
+#ifdef CONFIG_IRQ_WORK
+void arch_irq_work_raise(void)
+{
+ if (is_smp())
+ smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
+}
+#endif
+
#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
void tick_broadcast(const struct cpumask *mask)
{
@@ -556,8 +565,10 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
unsigned int cpu = smp_processor_id();
struct pt_regs *old_regs = set_irq_regs(regs);
- if (ipinr < NR_IPI)
+ if ((unsigned)ipinr < NR_IPI) {
+ trace_ipi_entry(ipi_types[ipinr]);
__inc_irq_stat(cpu, ipi_irqs[ipinr]);
+ }
switch (ipinr) {
case IPI_WAKEUP:
@@ -612,6 +623,9 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
cpu, ipinr);
break;
}
+
+ if ((unsigned)ipinr < NR_IPI)
+ trace_ipi_exit(ipi_types[ipinr]);
set_irq_regs(old_regs);
}
--
Facebook |
Twitter |
[PATCH v2 2/4] Staging: lustre: linux-module: remove unnecessary spaces
Remove extraneous space after open paren and before close paren.
Signed-off-by: Jessica Yu
---
drivers/staging/lustre/lustre/libcfs/linux/linux-module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
index b0c00a9..abd7e6f 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
@@ -140,9 +140,9 @@ static long libcfs_ioctl(struct file *file,
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
- if ( _IOC_TYPE(cmd) != IOC_LIBCFS_TYPE ||
+ if (_IOC_TYPE(cmd) != IOC_LIBCFS_TYPE ||
_IOC_NR(cmd) < IOC_LIBCFS_MIN_NR ||
-_IOC_NR(cmd) > IOC_LIBCFS_MAX_NR ) {
+_IOC_NR(cmd) > IOC_LIBCFS_MAX_NR) {
CDEBUG(D_IOCTL, "invalid ioctl ( type %d, nr %d, size %d )\n",
_IOC_TYPE(cmd), _IOC_NR(cmd), _IOC_SIZE(cmd));
return (-EINVAL);
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] Staging: lustre: linux-module: remove extraneous parens
Remove unnecessary parens from return statements, return is not a function
Signed-off-by: Jessica Yu
---
drivers/staging/lustre/lustre/libcfs/linux/linux-module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
index abd7e6f..745fe4c 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
@@ -154,7 +154,7 @@ static long libcfs_ioctl(struct file *file,
if (!capable(CFS_CAP_SYS_BOOT))
return (-EPERM);
panic("debugctl-invoked panic");
- return (0);
+ return 0;
case IOC_LIBCFS_MEMHOG:
if (!capable(CFS_CAP_SYS_ADMIN))
return -EPERM;
@@ -167,7 +167,7 @@ static long libcfs_ioctl(struct file *file,
rc = libcfs_psdev_ops.p_ioctl(, cmd, (void *)arg);
else
rc = -EPERM;
- return (rc);
+ return rc;
}
static struct file_operations libcfs_fops = {
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] Staging: lustre: linux-module: add const modifier to file_operations
Add the const modifier to the file_operations struct, since it is
normally const.
Signed-off-by: Jessica Yu
---
drivers/staging/lustre/lustre/libcfs/linux/linux-module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
index 745fe4c..de3c199 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
@@ -170,7 +170,7 @@ static long libcfs_ioctl(struct file *file,
return rc;
}
-static struct file_operations libcfs_fops = {
+static const struct file_operations libcfs_fops = {
.unlocked_ioctl = libcfs_ioctl,
.open = libcfs_psdev_open,
.release= libcfs_psdev_release,
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] Staging: lustre: linux-module: fix pointer style issue
Fix pointer code style (foo * bar -> foo *bar)
Signed-off-by: Jessica Yu
---
drivers/staging/lustre/lustre/libcfs/linux/linux-module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
index ccadf65..b0c00a9 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
@@ -99,7 +99,7 @@ int libcfs_ioctl_popdata(void *arg, void *data, int size)
extern struct cfs_psdev_ops libcfs_psdev_ops;
static int
-libcfs_psdev_open(struct inode * inode, struct file * file)
+libcfs_psdev_open(struct inode *inode, struct file *file)
{
struct libcfs_device_userstate **pdu = NULL;
intrc = 0;
@@ -116,7 +116,7 @@ libcfs_psdev_open(struct inode * inode, struct file * file)
/* called when closing /dev/device */
static int
-libcfs_psdev_release(struct inode * inode, struct file * file)
+libcfs_psdev_release(struct inode *inode, struct file *file)
{
struct libcfs_device_userstate *pdu;
intrc = 0;
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] Staging: lustre: linux-module: fix style issues
I revisited my original patch and realized that it should be split into separate parts. Jessica Yu (4): Staging: lustre: linux-module: fix pointer style issue Staging: lustre: linux-module: remove unnecessary spaces Staging: lustre: linux-module: remove extraneous parens Staging: lustre: linux-module: add const modifier to file_operations drivers/staging/lustre/lustre/libcfs/linux/linux-module.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH ftrace/core v4 4/4] kprobes: Set IPMODIFY flag only if the probe can change regs->ip
Set FTRACE_OPS_FL_IPMODIFY flag only for the probes which can change
regs->ip, which has kprobe->break_handler.
Currently we can not put jprobe and another ftrace handler which
changes regs->ip on the same function because all kprobes have
FTRACE_OPS_FL_IPMODIFY flag. This removes FTRACE_OPS_FL_IPMODIFY
flag from kprobes and only when the user uses jprobe (or the
kprobe.break_handler != NULL) we add additinal ftrace_ops with
FTRACE_OPS_FL_IPMODIFY on target function.
Note about the implementation: This uses a dummy ftrace_ops to
reserve IPMODIFY flag on the given ftrace address, for the case
that we have a enabled kprobe on a function entry and a jprobe
is added on the same point. In that case, we already have a
ftrace_ops without IPMODIFY flag on the entry, and we have to
add another ftrace_ops with IPMODIFY on the same address.
If we put a same handler on both ftrace_ops, the handler can
be called twice on that entry until the first one is removed.
This means that the kprobe and the jprobe are called twice too,
and that will not what kprobes expected.
Thus I added a dummy ftrace_ops just for reserving IPMODIFY flag.
Changes in v4:
- Increment refcounter after succeeded to register ftrace_ops.
Changes in v3:
- Update __ftrace_add/remove_filter_ip() according to
Namhyng's comments (thanks!)
- Split out regs->ip recovering code from this patch.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Steven Rostedt
Cc: Josh Poimboeuf
Cc: Namhyung Kim
---
Documentation/kprobes.txt | 12 ++--
kernel/kprobes.c | 125 +++--
2 files changed, 114 insertions(+), 23 deletions(-)
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index 4bbeca8..177f051 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt
@@ -264,15 +264,13 @@ stop-machine method that ksplice uses for supporting a
CONFIG_PREEMPT=y
kernel.
NOTE for geeks:
-The jump optimization changes the kprobe's pre_handler behavior.
-Without optimization, the pre_handler can change the kernel's execution
+The jump optimization (and ftrace-based kprobes) changes the kprobe's
+pre_handler behavior.
+Without optimizations, the pre_handler can change the kernel's execution
path by changing regs->ip and returning 1. However, when the probe
is optimized, that modification is ignored. Thus, if you want to
-tweak the kernel's execution path, you need to suppress optimization,
-using one of the following techniques:
-- Specify an empty function for the kprobe's post_handler or break_handler.
- or
-- Execute 'sysctl -w debug.kprobes_optimization=n'
+tweak the kernel's execution path, you need to suppress optimization or
+notify your handler will modify regs->ip by setting p->break_handler.
1.5 Blacklist
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index e52d86f..509875e 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -915,10 +915,93 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
#ifdef CONFIG_KPROBES_ON_FTRACE
static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
.func = kprobe_ftrace_handler,
- .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
+ .flags = FTRACE_OPS_FL_SAVE_REGS,
};
static int kprobe_ftrace_enabled;
+static void kprobe_ftrace_stub(unsigned long a0, unsigned long a1,
+ struct ftrace_ops *op, struct pt_regs *regs)
+{
+ /* Do nothing. This is just a dummy handler */
+}
+
+/* This is only for checking conflict with other ftrace users */
+static struct ftrace_ops kprobe_ipmod_ftrace_ops __read_mostly = {
+ .func = kprobe_ftrace_stub,
+ .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
+};
+static int kprobe_ipmod_ftrace_enabled;
+
+static int __ftrace_add_filter_ip(struct ftrace_ops *ops, unsigned long ip,
+ int *ref)
+{
+ int ret;
+
+ /* Try to set given ip to filter */
+ ret = ftrace_set_filter_ip(ops, ip, 0, 0);
+ if (ret < 0)
+ return ret;
+
+ if (*ref == 0) {
+ ret = register_ftrace_function(ops);
+ if (ret < 0) {
+ /* Rollback the filter */
+ ftrace_set_filter_ip(ops, ip, 1, 0);
+ goto out;
+ }
+ }
+ (*ref)++;
+
+out:
+ return ret;
+}
+
+static int __ftrace_remove_filter_ip(struct ftrace_ops *ops, unsigned long ip,
+int *ref)
+{
+ int ret;
+
+ if (*ref == 1) {
+ ret = unregister_ftrace_function(ops);
+ if (ret < 0)
+ return ret;
+ /*Ignore failure, because it is already unregistered */
+ ftrace_set_filter_ip(ops, ip, 1, 0);
+ } else {
+ /* Try to remove given ip to filter */
+ ret = ftrace_set_filter_ip(ops, ip, 1, 0);
+ if (ret < 0)
+
[PATCH ftrace/core v4 3/4] kprobes: Add IPMODIFY flag to kprobe_ftrace_ops
Add FTRACE_OPS_FL_IPMODIFY flag to kprobe_ftrace_ops
since kprobes can changes regs->ip.
Signed-off-by: Masami Hiramatsu
---
kernel/kprobes.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 3214289..e52d86f 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -915,7 +915,7 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
#ifdef CONFIG_KPROBES_ON_FTRACE
static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
.func = kprobe_ftrace_handler,
- .flags = FTRACE_OPS_FL_SAVE_REGS,
+ .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
};
static int kprobe_ftrace_enabled;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH ftrace/core v4 1/4] kprobes/ftrace: Recover original IP if pre_handler doesn't change it
Recover original IP register if the pre_handler doesn't change it.
Since current kprobes doesn't expect that another ftrace handler
may change regs->ip, it sets kprobe.addr + MCOUNT_INSN_SIZE to
regs->ip and returns to ftrace.
This seems wrong behavior since kprobes can recover regs->ip
and safely pass it to another handler.
This adds a code which recovers original regs->ip passed from
ftrace right before returning to ftrace, so that another ftrace
user can change regs->ip.
Changes in v4:
- Fix description and remove bugfix tag.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/ftrace.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
index 717b02a..5f8f0b3 100644
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -27,7 +27,7 @@
static nokprobe_inline
int __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
- struct kprobe_ctlblk *kcb)
+ struct kprobe_ctlblk *kcb, unsigned long orig_ip)
{
/*
* Emulate singlestep (and also recover regs->ip)
@@ -39,6 +39,8 @@ int __skip_singlestep(struct kprobe *p, struct pt_regs *regs,
p->post_handler(p, regs, 0);
}
__this_cpu_write(current_kprobe, NULL);
+ if (orig_ip)
+ regs->ip = orig_ip;
return 1;
}
@@ -46,7 +48,7 @@ int skip_singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
if (kprobe_ftrace(p))
- return __skip_singlestep(p, regs, kcb);
+ return __skip_singlestep(p, regs, kcb, 0);
else
return 0;
}
@@ -71,13 +73,14 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long
parent_ip,
if (kprobe_running()) {
kprobes_inc_nmissed_count(p);
} else {
+ unsigned long orig_ip = regs->ip;
/* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
regs->ip = ip + sizeof(kprobe_opcode_t);
__this_cpu_write(current_kprobe, p);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
if (!p->pre_handler || !p->pre_handler(p, regs))
- __skip_singlestep(p, regs, kcb);
+ __skip_singlestep(p, regs, kcb, orig_ip);
/*
* If pre_handler returns !0, it sets regs->ip and
* resets current kprobe.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH ftrace/core v4 0/4] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts
Hi,
Here is the 4th version of the series of patches which introduces
IPMODIFY flag for ftrace_ops to detect conflicts of ftrace users
who can modify regs->ip in their handler.
This version is basically an update of previous version, and
I've splitted a patch which adding IPMODIFY to kprobes from ftrace
IPMODIFY introducing patch.
Currently, only kprobes can change the regs->ip in the handler,
but recently kpatch is also want to change it. Moreover, since
the ftrace itself exported to modules, it might be considerable
senario.
Here we talked on github.
https://github.com/dynup/kpatch/issues/47
To protect modified regs-ip from each other, this series
introduces FTRACE_OPS_FL_IPMODIFY flag and ftrace now ensures
the flag can be set on each function entry location. If there
is someone who already reserve regs->ip on target function
entry, ftrace_set_filter_ip or register_ftrace_function will
return -EBUSY. Users must handle that.
The ftrace_ops with IPMODIFY flag requires at least one
entry for filter hash, and its notrace_hash must be empty,
because the IPMODIFY action is very address sensitve and
user must consider the ip address.
The 3rd patch adds a special reservation of IPMODIFY on the
jprobed address, since it is the only user who will change
the regs->ip. Other kprobes do not change it anymore.
Here is the new testcase.
---
#!/bin/bash
echo "IPMODIFY test"
ADDR=0x`grep do_fork /proc/kallsyms | cut -f 1 -d" "`
echo "Case1: kprobe->jprobe->ipmodify(fail)"
modprobe kprobe_example
modprobe jprobe_example
insmod ./ipmodify.ko target=$ADDR && echo "Case1: [FAIL]" || echo "Case1: [OK]"
rmmod kprobe_example jprobe_example
echo "Case2: jprobe->kprobe->ipmodify(fail)"
modprobe jprobe_example
modprobe kprobe_example
insmod ./ipmodify.ko target=$ADDR && echo "Case2: [FAIL]" || echo "Case2: [OK]"
rmmod kprobe_example jprobe_example
echo "Case3: jprobe->ipmodify(fail)"
modprobe jprobe_example
insmod ./ipmodify.ko target=$ADDR && echo "Case3: [FAIL]" || echo "Case3: [OK]"
rmmod jprobe_example
echo "Case4: ipmodify->jprobe(fail)"
insmod ./ipmodify.ko target=$ADDR
modprobe jprobe_example && echo "Case4: [FAIL]" || echo "Case4: [OK]"
rmmod ipmodify
echo "Case5: ipmodify->kprobe->jprobe(fail)"
insmod ./ipmodify.ko target=$ADDR
modprobe kprobe_example
modprobe jprobe_example && echo "Case5: [FAIL]" || echo "Case5: [OK]"
rmmod ipmodify kprobe_example
echo "Case6: ipmodify with targeting all functions(fail)"
insmod ./ipmodify.ko && echo "Case6: [FAIL]" || echo "Case6: [OK]"
rmmod ipmodify
echo "Case7: ipmodify with notrace filter (fail)"
insmod ./ipmodify.ko target=$ADDR noexp="do_fork" && echo "Case7: [FAIL]" ||
echo "Case7: [OK]"
rmmod ipmodify
---
And ipmodify.c
---
#include
#include
#include
static void ftrace_ipmodify_handler(unsigned long a0, unsigned long a1,
struct ftrace_ops *op, struct pt_regs *regs)
{
return;
}
static struct ftrace_ops test_ops __read_mostly = {
.func = ftrace_ipmodify_handler,
.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
};
static unsigned long target;
module_param(target, ulong, 0444);
static char *noexp = "";
module_param(noexp, charp, 0444);
static int __init ipmodify_init(void)
{
int ret;
unsigned long ip = target;
if (strlen(noexp) != 0) {
ret = ftrace_set_notrace(_ops, noexp, 0, 0);
pr_err("ipmodify_test: set notrace \"%s\", ret = %d\n",
noexp, ret);
}
if (ret < 0)
return ret;
ret = ftrace_set_filter_ip(_ops, ip, 0, 0);
pr_err("ipmodify_test: set filter ip 0x%lx, ret = %d\n", ip, ret);
if (ret >= 0) {
ret = register_ftrace_function(_ops);
pr_err("ipmodify_test: register ftrace on 0x%lx, ret = %d\n",
ip, ret);
}
return ret;
}
static void __exit ipmodify_exit(void)
{
int ret;
unsigned long ip = target;
ret = unregister_ftrace_function(_ops);
pr_err("ipmodify_test: unregister ftrace on 0x%lx, ret = %d\n", ip,
ret);
if (ret >= 0) {
ret = ftrace_set_filter_ip(_ops, ip, 1, 0);
pr_err("ipmodify_test: clear filter ip 0x%lx, ret = %d\n",
ip, ret);
}
}
module_init(ipmodify_init)
module_exit(ipmodify_exit)
MODULE_LICENSE("GPL");
---
Thank you,
---
Masami Hiramatsu (4):
kprobes/ftrace: Recover original IP if pre_handler doesn't change it
ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict
kprobes: Add IPMODIFY flag to kprobe_ftrace_ops
kprobes: Set IPMODIFY flag only if the probe can change regs->ip
Documentation/kprobes.txt| 12 +--
Documentation/trace/ftrace.txt |5 +
arch/x86/kernel/kprobes/ftrace.c |9 ++
include/linux/ftrace.h | 16
kernel/kprobes.c | 123
[PATCH ftrace/core v4 2/4] ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict
Introduce FTRACE_OPS_FL_IPMODIFY to avoid conflict among
ftrace users who may modify regs->ip to change the execution
path. If two or more users modify the regs->ip on the same
function entry, one of them will be broken. So they must add
IPMODIFY flag and make sure that ftrace_set_filter_ip() succeeds.
Note that ftrace doesn't allow ftrace_ops which has IPMODIFY
flag to have notrace hash, and the ftrace_ops must have a
filter hash (so that the ftrace_ops can hook only specific
entries), because it strongly depends on the address and
must be allowed for only few selected functions.
Changes in v4:
- Split kprobe's part from this patch.
- Add no-notrace hash check.
- Reject if the filter_hash is empty. Since IPMODIFY action
is very address sensitive, empty hash (means hooking all
functions) must not be allowed.
Changes in v3:
- Update for the latest ftrace/core.
- Add a comment about FTRACE_OPS_FL_* attribute flags.
- Don't check FTRACE_OPS_FL_SAVE_REGS in
__ftrace_hash_update_ipmodify().
- Fix comments.
Changes in v2:
- Add a description how __ftrace_hash_update_ipmodify() will
handle the given hashes (NULL and EMPTY_HASH cases).
- Clear FTRACE_OPS_FL_ENABLED after calling
__unregister_ftrace_function() in error path.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: Steven Rostedt
Cc: Josh Poimboeuf
Cc: Namhyung Kim
---
Documentation/trace/ftrace.txt |5 +
include/linux/ftrace.h | 16
kernel/trace/ftrace.c | 143 +++-
3 files changed, 160 insertions(+), 4 deletions(-)
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index 2479b2a..aa7e5bd 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -234,6 +234,11 @@ of ftrace. Here is a list of some of the key files:
will be displayed on the same line as the function that
is returning registers.
+ If the callback registered to be traced by a function with
+ the "ip modify" attribute (thus the regs->ip can be changed),
+ an 'I' will be displayed on the same line as the function that
+ can be overridden.
+
function_profile_enabled:
When set it will enable all functions with either the function
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 6bb5e3f..905ec9f 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -59,6 +59,11 @@ typedef void (*ftrace_func_t)(unsigned long ip, unsigned
long parent_ip,
/*
* FTRACE_OPS_FL_* bits denote the state of ftrace_ops struct and are
* set in the flags member.
+ * CONTROL, SAVE_REGS, SAVE_REGS_IF_SUPPORTED, RECURSION_SAFE, STUB and
+ * IPMODIFY are a kind of attribute flags which can be set only before
+ * registering the ftrace_ops, and can not be modified while registered.
+ * Changing those attribute flags after regsitering ftrace_ops will
+ * cause unexpected results.
*
* ENABLED - set/unset when ftrace_ops is registered/unregistered
* DYNAMIC - set when ftrace_ops is registered to denote dynamically
@@ -89,6 +94,10 @@ typedef void (*ftrace_func_t)(unsigned long ip, unsigned
long parent_ip,
* INITIALIZED - The ftrace_ops has already been initialized (first use time
*register_ftrace_function() is called, it will initialized the
ops)
* DELETED - The ops are being deleted, do not let them be registered again.
+ * IPMODIFY - The ops can modify the IP register. This can only be set with
+ *SAVE_REGS. If another ops is already registered for any of the
+ *functions that this ops will be registered for, then this ops
+ *will fail to register or set_filter_ip.
*/
enum {
FTRACE_OPS_FL_ENABLED = 1 << 0,
@@ -100,6 +109,7 @@ enum {
FTRACE_OPS_FL_STUB = 1 << 6,
FTRACE_OPS_FL_INITIALIZED = 1 << 7,
FTRACE_OPS_FL_DELETED = 1 << 8,
+ FTRACE_OPS_FL_IPMODIFY = 1 << 9,
};
/*
@@ -281,6 +291,7 @@ extern int ftrace_nr_registered_ops(void);
* ENABLED - the function is being traced
* REGS- the record wants the function to save regs
* REGS_EN - the function is set up to save regs.
+ * IPMODIFY - the record allows for the IP address to be changed.
*
* When a new ftrace_ops is registered and wants a function to save
* pt_regs, the rec->flag REGS is set. When the function has been
@@ -294,10 +305,11 @@ enum {
FTRACE_FL_REGS_EN = (1UL << 29),
FTRACE_FL_TRAMP = (1UL << 28),
FTRACE_FL_TRAMP_EN = (1UL << 27),
+ FTRACE_FL_IPMODIFY = (1UL << 26),
};
-#define FTRACE_REF_MAX_SHIFT 27
-#define FTRACE_FL_BITS 5
+#define FTRACE_REF_MAX_SHIFT 26
+#define FTRACE_FL_BITS 6
#define FTRACE_FL_MASKED_BITS ((1UL << FTRACE_FL_BITS) - 1)
#define FTRACE_FL_MASK (FTRACE_FL_MASKED_BITS << FTRACE_REF_MAX_SHIFT)
[PATCH -tip/master 4/7] locking/mutex: Refactor optimistic spinning code
When we fail to acquire the mutex in the fastpath, we end up calling
__mutex_lock_common(). A lot goes on in this function. Move out the
optimistic spinning code into mutex_optimistic_spin() and simplify
the former a bit. Furthermore, this is similar to what we have in
rwsems. No logical changes.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/mutex.c | 387 +++--
1 file changed, 212 insertions(+), 175 deletions(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 7a9be39..a925597 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -106,6 +106,92 @@ void __sched mutex_lock(struct mutex *lock)
EXPORT_SYMBOL(mutex_lock);
#endif
+static __always_inline void ww_mutex_lock_acquired(struct ww_mutex *ww,
+ struct ww_acquire_ctx
*ww_ctx)
+{
+#ifdef CONFIG_DEBUG_MUTEXES
+ /*
+* If this WARN_ON triggers, you used ww_mutex_lock to acquire,
+* but released with a normal mutex_unlock in this call.
+*
+* This should never happen, always use ww_mutex_unlock.
+*/
+ DEBUG_LOCKS_WARN_ON(ww->ctx);
+
+ /*
+* Not quite done after calling ww_acquire_done() ?
+*/
+ DEBUG_LOCKS_WARN_ON(ww_ctx->done_acquire);
+
+ if (ww_ctx->contending_lock) {
+ /*
+* After -EDEADLK you tried to
+* acquire a different ww_mutex? Bad!
+*/
+ DEBUG_LOCKS_WARN_ON(ww_ctx->contending_lock != ww);
+
+ /*
+* You called ww_mutex_lock after receiving -EDEADLK,
+* but 'forgot' to unlock everything else first?
+*/
+ DEBUG_LOCKS_WARN_ON(ww_ctx->acquired > 0);
+ ww_ctx->contending_lock = NULL;
+ }
+
+ /*
+* Naughty, using a different class will lead to undefined behavior!
+*/
+ DEBUG_LOCKS_WARN_ON(ww_ctx->ww_class != ww->ww_class);
+#endif
+ ww_ctx->acquired++;
+}
+
+/*
+ * after acquiring lock with fastpath or when we lost out in contested
+ * slowpath, set ctx and wake up any waiters so they can recheck.
+ *
+ * This function is never called when CONFIG_DEBUG_LOCK_ALLOC is set,
+ * as the fastpath and opportunistic spinning are disabled in that case.
+ */
+static __always_inline void
+ww_mutex_set_context_fastpath(struct ww_mutex *lock,
+ struct ww_acquire_ctx *ctx)
+{
+ unsigned long flags;
+ struct mutex_waiter *cur;
+
+ ww_mutex_lock_acquired(lock, ctx);
+
+ lock->ctx = ctx;
+
+ /*
+* The lock->ctx update should be visible on all cores before
+* the atomic read is done, otherwise contended waiters might be
+* missed. The contended waiters will either see ww_ctx == NULL
+* and keep spinning, or it will acquire wait_lock, add itself
+* to waiter list and sleep.
+*/
+ smp_mb(); /* ^^^ */
+
+ /*
+* Check if lock is contended, if not there is nobody to wake up
+*/
+ if (likely(atomic_read(>base.count) == 0))
+ return;
+
+ /*
+* Uh oh, we raced in fastpath, wake up everyone in this case,
+* so they can see the new lock->ctx.
+*/
+ spin_lock_mutex(>base.wait_lock, flags);
+ list_for_each_entry(cur, >base.wait_list, list) {
+ debug_mutex_wake_waiter(>base, cur);
+ wake_up_process(cur->task);
+ }
+ spin_unlock_mutex(>base.wait_lock, flags);
+}
+
+
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
/*
* In order to avoid a stampede of mutex spinners from acquiring the mutex
@@ -180,6 +266,126 @@ static inline int mutex_can_spin_on_owner(struct mutex
*lock)
*/
return retval;
}
+
+/*
+ * Atomically try to take the lock when it is available */
+static inline bool mutex_try_to_acquire(struct mutex *lock)
+{
+ return !mutex_is_locked(lock) &&
+ (atomic_cmpxchg(>count, 1, 0) == 1);
+}
+
+/*
+ * Optimistic spinning.
+ *
+ * We try to spin for acquisition when we find that the lock owner
+ * is currently running on a (different) CPU and while we don't
+ * need to reschedule. The rationale is that if the lock owner is
+ * running, it is likely to release the lock soon.
+ *
+ * Since this needs the lock owner, and this mutex implementation
+ * doesn't track the owner atomically in the lock field, we need to
+ * track it non-atomically.
+ *
+ * We can't do this for DEBUG_MUTEXES because that relies on wait_lock
+ * to serialize everything.
+ *
+ * The mutex spinners are queued up using MCS lock so that only one
+ * spinner can compete for the mutex. However, if mutex spinning isn't
+ * going to happen, there is no point in going through the lock/unlock
+ * overhead.
+ *
+ * Returns true when the lock was taken, otherwise false, indicating
+ * that we need to jump to the slowpath and sleep.
+ */
[PATCH -tip/master 5/7] locking/mutex: Use MUTEX_SPIN_ON_OWNER when appropriate
4badad35 (locking/mutex: Disable optimistic spinning on some
architectures) added a ARCH_SUPPORTS_ATOMIC_RMW flag to
disable the mutex optimistic feature on specific archs.
Because CONFIG_MUTEX_SPIN_ON_OWNER only depended on DEBUG and
SMP, it was ok to have the ->owner field conditional a bit
flexible. However by adding a new variable to the matter,
we can waste space with the unused field, ie: CONFIG_SMP &&
(!CONFIG_MUTEX_SPIN_ON_OWNER && !CONFIG_DEBUG_MUTEX).
Signed-off-by: Davidlohr Bueso
---
include/linux/mutex.h | 2 +-
kernel/locking/mutex.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 8d5535c..e4c2941 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -52,7 +52,7 @@ struct mutex {
atomic_tcount;
spinlock_t wait_lock;
struct list_headwait_list;
-#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_SMP)
+#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_MUTEX_SPIN_ON_OWNER)
struct task_struct *owner;
#endif
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
diff --git a/kernel/locking/mutex.h b/kernel/locking/mutex.h
index 4115fbf..5cda397 100644
--- a/kernel/locking/mutex.h
+++ b/kernel/locking/mutex.h
@@ -16,7 +16,7 @@
#define mutex_remove_waiter(lock, waiter, ti) \
__list_del((waiter)->list.prev, (waiter)->list.next)
-#ifdef CONFIG_SMP
+#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
static inline void mutex_set_owner(struct mutex *lock)
{
lock->owner = current;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip/master 1/7] locking/mutex: Unify arguments in lock/unlock slowpaths
Just how the locking-end behaves, when unlocking, go ahead and
obtain the proper data structure immediately after the previous
(asm-end) call exits and there are (probably) pending waiters.
This simplifies a bit some of the layering.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/mutex.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index ae712b2..ad0e333 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -679,9 +679,8 @@ EXPORT_SYMBOL_GPL(__ww_mutex_lock_interruptible);
* Release the lock, slowpath:
*/
static inline void
-__mutex_unlock_common_slowpath(atomic_t *lock_count, int nested)
+__mutex_unlock_common_slowpath(struct mutex *lock, int nested)
{
- struct mutex *lock = container_of(lock_count, struct mutex, count);
unsigned long flags;
/*
@@ -716,7 +715,9 @@ __mutex_unlock_common_slowpath(atomic_t *lock_count, int
nested)
__visible void
__mutex_unlock_slowpath(atomic_t *lock_count)
{
- __mutex_unlock_common_slowpath(lock_count, 1);
+ struct mutex *lock = container_of(lock_count, struct mutex, count);
+
+ __mutex_unlock_common_slowpath(lock, 1);
}
#ifndef CONFIG_DEBUG_LOCK_ALLOC
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip/master 2/7] locking/mutex: Document quick lock release when unlocking
When unlocking, we always want to reach the slowpath with the lock's counter indicating it is unlocked. -- as returned by the asm fastpath call or by explicitly setting it. While doing so, at least in theory, we can optimize and allow faster lock stealing. This is not immediately obvious and deserves to be documented. Signed-off-by: Davidlohr Bueso --- kernel/locking/mutex.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c index ad0e333..7a9be39 100644 --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -676,7 +676,8 @@ EXPORT_SYMBOL_GPL(__ww_mutex_lock_interruptible); #endif /* - * Release the lock, slowpath: + * Release the lock, slowpath. + * At this point, the lock counter is 0 or negative. */ static inline void __mutex_unlock_common_slowpath(struct mutex *lock, int nested) @@ -684,9 +685,16 @@ __mutex_unlock_common_slowpath(struct mutex *lock, int nested) unsigned long flags; /* -* some architectures leave the lock unlocked in the fastpath failure +* As a performance measurement, release the lock before doing other +* wakeup related duties to follow. This allows other tasks to acquire +* the lock sooner, while still handling cleanups in past unlock calls. +* This can be done as we do not enforce strict equivalence between the +* mutex counter and wait_list. +* +* +* Some architectures leave the lock unlocked in the fastpath failure * case, others need to leave it locked. In the later case we have to -* unlock it here +* unlock it here. */ if (__mutex_slowpath_needs_to_unlock()) atomic_set(>count, 1); -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip/master 7/7] Documentation: Update locking/mutex-design.txt disadvantages
Fortunately Jason was able to reduce some of the overhead we had introduced in the original rwsem optimistic spinning - an it is now the same size as mutexes. Update the documentation accordingly. Signed-off-by: Davidlohr Bueso --- Documentation/locking/mutex-design.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/locking/mutex-design.txt b/Documentation/locking/mutex-design.txt index ee231ed..60c482d 100644 --- a/Documentation/locking/mutex-design.txt +++ b/Documentation/locking/mutex-design.txt @@ -145,9 +145,9 @@ Disadvantages Unlike its original design and purpose, 'struct mutex' is larger than most locks in the kernel. E.g: on x86-64 it is 40 bytes, almost twice -as large as 'struct semaphore' (24 bytes) and 8 bytes shy of the -'struct rw_semaphore' variant. Larger structure sizes mean more CPU -cache and memory footprint. +as large as 'struct semaphore' (24 bytes) and tied, along with rwsems, +for the largest lock in the kernel. Larger structure sizes mean more +CPU cache and memory footprint. When to use mutexes --- -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip/master 3/7] locking/mcs: Remove obsolete comment
... as we clearly inline mcs_spin_lock() now.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/mcs_spinlock.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/locking/mcs_spinlock.h b/kernel/locking/mcs_spinlock.h
index 23e89c5..4d60986 100644
--- a/kernel/locking/mcs_spinlock.h
+++ b/kernel/locking/mcs_spinlock.h
@@ -56,9 +56,6 @@ do {
\
* If the lock has already been acquired, then this will proceed to spin
* on this node->locked until the previous lock holder sets the node->locked
* in mcs_spin_unlock().
- *
- * We don't inline mcs_spin_lock() so that perf can correctly account for the
- * time spent in this lock function.
*/
static inline
void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] staging: android: Fixed missing blank line
Hello Greg, I didn't received automated email. Regards Sanjeev Sharma -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Wednesday, July 23, 2014 8:55 PM To: Sharma, Sanjeev Cc: de...@driverdev.osuosl.org; swetl...@google.com; way...@gmail.com; linux-kernel@vger.kernel.org; dan...@ffwll.ch Subject: Re: [PATCH] staging: android: Fixed missing blank line On Wed, Jul 23, 2014 at 10:08:44AM +, Sharma, Sanjeev wrote: > Thanks, so this is also available in next kernel release version. I don't understand the question. You should have gotten an automated email when the patch was applied that explained where the patch was now located, and when it would be merged into Linus's tree. Did you not get that? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the mmc-uh tree
Hi Ulf,
After merging the mmc-uh tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/mmc/host/dw_mmc.c: In function 'dw_mci_reset':
drivers/mmc/host/dw_mmc.c:2262:3: error: implicit declaration of function
'dw_mci_idmac_reset' [-Werror=implicit-function-declaration]
dw_mci_idmac_reset(host);
^
Caused by commit 25f7dadbd982 ("mmc: dw_mmc: change to use recommended
reset procedure").
I have used the mmc-uh tree from next-20140725 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
REVERT request for patch "ARC: [arcfpga] stdout-path now suffices for earlycon/console" added to tty tree
Hi Greg,
On Friday 11 July 2014 04:11 AM, gre...@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> ARC: [arcfpga] stdout-path now suffices for earlycon/console
>
> to my tty git tree which can be found at
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
> in the tty-next branch.
>
> The patch will show up in the next release of the linux-next tree
> (usually sometime within the next 24 hours during the week.)
>
> The patch will also be merged in the next major kernel release
> during the merge window.
>
> If you have any questions about this process, please let me know.
>
>
>>From 9da433c0a0b5f71ac92dc9dca778295649675f08 Mon Sep 17 00:00:00 2001
> From: Vineet Gupta
> Date: Tue, 24 Jun 2014 13:55:15 +0530
> Subject: ARC: [arcfpga] stdout-path now suffices for earlycon/console
>
> With recent improvements to serial/of core from Grant and Rob,
> stdout-path alone suffices for setting up earlycon/console.
>
> arc_uart driver is already equipped to handle that, switch the DT now.
>
> Signed-off-by: Vineet Gupta
> Reviewed-by: Rob Herring
> Signed-off-by: Greg Kroah-Hartman
> ---
> arch/arc/boot/dts/angel4.dts | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arc/boot/dts/angel4.dts b/arch/arc/boot/dts/angel4.dts
> index 6b57475967a6..298a46daa633 100644
> --- a/arch/arc/boot/dts/angel4.dts
> +++ b/arch/arc/boot/dts/angel4.dts
> @@ -17,7 +17,8 @@
> interrupt-parent = <>;
>
> chosen {
> - bootargs = "earlycon=arc_uart,mmio32,0xc0fc1000,115200n8
> console=ttyARC0,115200n8";
> + bootargs = "earlycon";
> + stdout-path =
> };
>
> aliases {
>
Could you please revert this single patch from tty-next for 3.17 as the needed
core changes are not yet finalized.
Thx and sorry for the trouble.
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [drm] WARNING: CPU: 2 PID: 430 at drivers/gpu/drm/drm_crtc.c:1391 drm_universal_plane_init+0x241/0x260 [drm]()
On Mon, Jul 28, 2014 at 12:11 AM, Aaron Lu wrote:
> On 07/28/2014 11:16 AM, Nick Krause wrote:
>> On Sun, Jul 27, 2014 at 10:02 PM, Aaron Lu wrote:
>>> FYI, we noticed the below changes on
>>>
>>> git://people.freedesktop.org/~robclark/linux cold-fusion-v3.16-rc5
>>> commit 08172e9d2385ca9bd545a8229ac749f589146a31 ("drm: convert plane to
>>> properties/state")
>>>
>>> +-+++
>>> | | 88471ddbb1 | 08172e9d23 |
>>> +-+++
>>> | boot_successes | 10 | 10 |
>>> | early-boot-hang | 1 | 1 |
>>> +-+++
>>>
>>>
>>> [ 21.274681] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [ 21.275090] [drm] Driver supports precise vblank timestamp query.
>>> [ 21.275984] [ cut here ]
>>> [ 21.276300] WARNING: CPU: 2 PID: 430 at drivers/gpu/drm/drm_crtc.c:1391
>>> drm_universal_plane_init+0x241/0x260 [drm]()
>>> [ 21.277126] Modules linked in: firewire_ohci(+) firewire_core crc_itu_t
>>> snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic shpchp
>>> pcspkr i2c_i801 ahci snd_hda_intel i915(+) libahci snd_hda_controller
>>> libata snd_hda_codec snd_hwdep snd_pcm snd_timer drm_kms_helper snd
>>> soundcore drm winbond_cir rc_core floppy(+) parport_pc parport video
>>> [ 21.279682] CPU: 2 PID: 430 Comm: modprobe Not tainted
>>> 3.16.0-rc6-wl-ath-04110-gc6264ea #1
>>> [ 21.280208] Hardware name: Intel Corporation 2012 Client
>>> Platform/LosLunas CRB, BIOS ACRVMBY1.86C.0054.B00.1107311147 07/31/2011
>>> [ 21.281029] 0009 88041b34b860 8182d64b
>>>
>>> [ 21.281655] 88041b34b898 8106d16d 88007fb32000
>>>
>>> [ 21.282191] 88041a9ebe00 000a 88041a9ebe00
>>> 88041b34b8a8
>>> [ 21.282791] Call Trace:
>>> [ 21.282958] [] dump_stack+0x4d/0x66
>>> [ 21.283290] [] warn_slowpath_common+0x7d/0xa0
>>> [ 21.283756] [] warn_slowpath_null+0x1a/0x20
>>> [ 21.284134] [] drm_universal_plane_init+0x241/0x260
>>> [drm]
>>> [ 21.284697] [] intel_modeset_init+0x471/0xe70 [i915]
>>> [ 21.285127] [] ? ibx_irq_postinstall+0x5a/0xe0 [i915]
>>> [ 21.285652] [] ? ironlake_irq_postinstall+0xc6/0x1a0
>>> [i915]
>>> [ 21.286137] [] i915_driver_load+0xb4a/0x1000 [i915]
>>> [ 21.286640] [] ? kobject_uevent_env+0x178/0x690
>>> [ 21.287028] [] ? get_device+0x17/0x30
>>> [ 21.287361] [] ? klist_class_dev_get+0x15/0x20
>>> [ 21.287813] [] ? klist_add_tail+0x3a/0x40
>>> [ 21.288166] [] ? device_add+0x1f9/0x610
>>> [ 21.288608] [] ? drm_sysfs_device_add+0xd6/0x120 [drm]
>>> [ 21.289033] [] drm_dev_register+0xad/0x100 [drm]
>>> [ 21.289420] [] drm_get_pci_dev+0x8f/0x1f0 [drm]
>>> [ 21.289887] [] i915_pci_probe+0x3b/0x60 [i915]
>>> [ 21.290258] [] local_pci_probe+0x45/0xa0
>>> [ 21.290690] [] ? pci_match_device+0xe5/0x110
>>> [ 21.291078] [] pci_device_probe+0xd1/0x130
>>> [ 21.291435] [] driver_probe_device+0x90/0x3c0
>>> [ 21.291891] [] __driver_attach+0x93/0xa0
>>> [ 21.292227] [] ? __device_attach+0x40/0x40
>>> [ 21.292640] [] bus_for_each_dev+0x63/0xa0
>>> [ 21.292969] [] driver_attach+0x1e/0x20
>>> [ 21.293293] [] bus_add_driver+0x180/0x250
>>> [ 21.293705] [] driver_register+0x64/0xf0
>>> [ 21.294041] [] __pci_register_driver+0x4c/0x50
>>> [ 21.294399] [] drm_pci_init+0x10a/0x140 [drm]
>>> [ 21.294863] [] ? 0xa026cfff
>>> [ 21.295209] [] i915_init+0x89/0x90 [i915]
>>> [ 21.295654] [] do_one_initcall+0xbc/0x1f0
>>> [ 21.296010] [] ? __vunmap+0xb2/0x100
>>> [ 21.296330] [] load_module+0x15fc/0x1a30
>>> [ 21.296760] [] ? store_uevent+0x40/0x40
>>> [ 21.297132] [] SyS_init_module+0xc1/0x110
>>> [ 21.297470] [] system_call_fastpath+0x16/0x1b
>>> [ 21.297910] ---[ end trace ecc622d672d3c733 ]---
>>> [ 21.298652] [ cut here ]
>>>
>>>
>>>
>>> Disclaimer:
>>> Results have been estimated based on internal Intel analysis and are
>>> provided
>>> for informational purposes only. Any difference in system hardware or
>>> software
>>> design or configuration may affect actual performance.
>>>
>>> Thanks,
>>> Aaron
>>
>> Aaron,
>> I want to known what cpu's Intel is running this on it order to get
>> kernel warning in the x86 boot code.
>
> I suppose you want GPU information?
> Here it is:
>
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen
> Core processor Graphics Controller (rev 04) (prog-if 00 [VGA controller])
> Subsystem: Intel Corporation Device 2211
> Flags: bus master, fast devsel, latency 0, IRQ 45
> Memory at afc0 (64-bit, non-prefetchable) [size=4M]
> Memory at c000 (64-bit, prefetchable) [size=256M]
> I/O ports at 2000 [size=64]
> Expansion ROM at [disabled]
> Capabilities: [90] MSI:
Re: ARC fails to boot on linux-next of 20140711
On Saturday 26 July 2014 10:21 PM, Grant Likely wrote:
> On Sat, 26 Jul 2014 06:52:36 +, Vineet Gupta
> wrote:
>> Hi Rob,
>>
>> On Friday 25 July 2014 07:45 PM, Rob Herring wrote:
>>> On Fri, Jul 25, 2014 at 6:02 AM, Vineet Gupta
>>> wrote:
> Hi Grant,
>
> linux-next has a series for arc_uart (via tty tree) which converts it to
> generic
> earlycon and specifies console via /chosen/stdout-path vs. an explicit
> param in
> /chose/bootargs
>
> 2014-06-24 9da433c0a0b5 ARC: [arcfpga] stdout-path now suffices for
> earlycon/console
>
> This relied on prev commit of yours (from linux next of 20140711), which
> seem to
> have disappeared now.
>
> 2014-03-27 a9296cf2d0b6 of: Create of_console_check() for selecting a
> console
> specified in /chosen
> 2014-03-27 cfa9cacc5dd3 of: Enable console on serial ports specified by
> /chosen/stdout-path
>
> Is there a specific reason for dropping these patches (or perhaps a merge
> to be
> merged). I cherry-picked both but still doesn't work.
>
> Can you please advise next step forward, before I go off debugging with
> those
> patches in.
>>> There's an issue that if you have stdout-path and "earlycon" on the
>>> command line, the kernel will switch to tty0 and disable the earlycon.
>>>
>>> This is the "fix", but I don't like adding the DT dependency into generic
>>> code:
>>>
>>> @@ -2382,7 +2386,7 @@ void register_console(struct console *newcon)
>>> if (newcon->setup == NULL ||
>>> newcon->setup(newcon, NULL) == 0) {
>>> newcon->flags |= CON_ENABLED;
>>> - if (newcon->device) {
>>> + if (newcon->device && !of_stdout) {
>>> newcon->flags |= CON_CONSDEV;
>>> preferred_console = 0;
>>> }
>> The DT settings relevant for ARC, which enable generic-earlycon and
>> console-with-stdout-path are as follows
>>
>> chosen {
>> bootargs = "earlycon";
>> stdout-path =
>> };
>>
>>
>> arcuart0: serial@c0fc1000 {
>> compatible = "snps,arc-uart";
>>
>> And it works w/o above hunk, provided the 2 patches from Grant exist in
>> linux-next
>> which they don't at the moment. I'm pretty confused how the hunk above comes
>> into
>> picture.
>>
>> And if not then I will have to get the ARC std-out patch reverted in
>> tty-next as
>> it is broken.
> You need to revert it anyway, the dependency chain is broken. Just
> because something is in linux-next doesn't mean it will be merged.
> Dependencies must always be in the branch to which you commit.
>
> If that doesn't happen (like here) then bisecting is broken and the
> dependencies may not actually get merged.
>
> When this happens, what you're supposed to do is tell the maintainers
> what commits the patch depends on so that it can be applied to the
> correct tree. In this case I could take it through my devicetree branch
> that contains the console patches.
I understand all of that. Actually 9 out of 10 of my changes were for switching
to
earlycon for which corresponding core changes from Rob were already in mainline.
When reviewing my code, Rob pointed me to your on going work on use of
stdout-path
so my mistake was to pile that up in the same series vs. asking you to add that
patch in ur tree for precisely the multi dependency reason.
> If a patch depends on commits in several branches then it is a bit more
> complex. What we usually do is create a new branch that merges in each
> branch that is depended on, and then apply the commit on top of that.
>
> As for the console patches, I'm only going to be putting them back if I
> can devise a good fix for the earlycon duplication issue.
If you have an internal branch for this work, can you please add the patch below
to it so that we don't forget abt it.
https://lkml.org/lkml/2014/6/24/127
I'll ask Greg to revert it from tty tree !
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] x86,cpu-hotplug: assign same CPU number to readded CPU
Ping.
(2014/07/23 12:22), Yasuaki Ishimatsu wrote:
llc_shared_map is not cleared even if CPU is offline or hot removed.
So when hot-plugging CPU and assigning new CPU number to hot-added CPU,
the mask has wrong value. The mask is used by CSF schduler to create
sched_domain. So it breaks CFS scheduler.
Here is a example on my system.
My system has 4 sockets and each socket has 15 cores and HT is enabled.
In this case, each core of sockes is numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-44, 90-104
Socket#3 | 45-59, 105-119
Then llc_shared_mask of CPU#30 has 0x3fff8001fffc000.
It means that last level cache of Socket#2 is shared with
CPU#30-44 and 90-104.
When hot-removing socket#2 and #3, each core of sockets is numbered
as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30 remains
having 0x3fff8001fffc000.
After that, when hot-adding socket#2 and #3, each core of sockets is
numbered as follows:
| CPU#
Socket#0 | 0-14 , 60-74
Socket#1 | 15-29, 75-89
Socket#2 | 30-59
Socket#3 | 90-119
Then llc_shared_mask of CPU#30 becomes 0x3fff8000fffc000.
It means that last level cache of Socket#2 is shared with CPU#30-59
and 90-104. So the mask has wrong value.
At first, I cleared hot-removed CPU number's bit from llc_shared_map
when hot removing CPU. But Borislav suggested that the problem will
disappear if readded CPU is assigned same CPU number. And llc_shared_map
must not be changed.
So the patch assigns same CPU number to readded CPU by linking CPU
number to APIC ID. And by the patch, the problem disappers.
Signed-off-by: Yasuaki Ishimatsu
Suggested-by: Borislav Petkov
Reviewed-by: Toshi Kani
---
v2: change cpuid to cpunum
v3: fix Borislav's email address of Suggested-by
fix typo (ACPI ID to APIC ID)
v4: change cpu_used_xxx to cpu_number_xxx
---
arch/x86/kernel/apic/apic.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ad28db7..5cecc3b 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -220,6 +220,23 @@ static void apic_pm_activate(void);
static unsigned long apic_phys;
/*
+ * Bind APIC ID to Logical CPU number
+ * Logical CPU number to APIC ID does not change by this array
+ * even if CPU is hotplugged. So don't clear the array even if
+ * CPU is hot-removed
+ */
+static int apicid_to_cpunum[MAX_LOCAL_APIC] = {
+[0 ... MAX_LOCAL_APIC-1] = -1,
+};
+
+/*
+ * Represent Logical CPU number bound to APIC ID
+ * Don't clear a bit even if CPU is hot-removed
+ */
+static DECLARE_BITMAP(cpu_number_bits, CONFIG_NR_CPUS);
+static struct cpumask *const cpu_number_mask = to_cpumask(cpu_number_bits);
+
+/*
* Get the LAPIC version
*/
static inline int lapic_get_version(void)
@@ -2122,6 +2139,17 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
+static int get_cpunum(int apicid)
+{
+int cpu;
+
+cpu = apicid_to_cpunum[apicid];
+if (cpu < 0)
+cpu = cpumask_next_zero(-1, cpu_number_mask);
+
+return cpu;
+}
+
int generic_processor_info(int apicid, int version)
{
int cpu, max = nr_cpu_ids;
@@ -2199,7 +2227,9 @@ int generic_processor_info(int apicid, int version)
*/
cpu = 0;
} else
-cpu = cpumask_next_zero(-1, cpu_present_mask);
+cpu = get_cpunum(apicid);
+
+apicid_to_cpunum[apicid] = cpu;
/*
* Validate version
@@ -2228,6 +2258,7 @@ int generic_processor_info(int apicid, int version)
early_per_cpu(x86_cpu_to_logical_apicid, cpu) =
apic->x86_32_early_logical_apicid(cpu);
#endif
+cpumask_set_cpu(cpu, cpu_number_mask);
set_cpu_possible(cpu, true);
set_cpu_present(cpu, true);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] sched: deferred set priority (dprio)
On Sun, Jul 27, 2014 at 6:19 PM, Andi Kleen wrote: >> [This is a repost of the message from few day ago, with patch file >> inline instead of being pointed by the URL.] > > Have you checked out the preemption control that was posted some time > ago? It did essentially the same thing, but somewhat simpler than your > patch. > > http://lkml.iu.edu/hypermail/linux/kernel/1403.0/00780.html Yes, I have seen this discussion. The patch suggested by Khalid implements a solution very much resembling Solaris/AIX schedctl. Schedctl is less generic and powerful than dprio. I compared dprio vs. schedctl in the write-up https://raw.githubusercontent.com/oboguev/dprio/master/dprio.txt To quote from there, [--- Quote ---] The Solaris schedctl [...] does not provide a way to associate a priority with the resource whose lock is being held (or, more generally, with thread application-specific logical state; see the footnote below). An application is likely to have a range of locks with different criticality levels and different needs for holder protection [*]. For some locks, holder preemption may be tolerated somewhat, while other locks are highly critical, furthermore for some lock holders preemption by a high-priority thread is acceptable but not a preemption by a low-priority thread. The Solaris/AIX schedctl does not provide a capability for priority ranging relative to the context of the whole application and other processes in the system. [*] We refer just to locks here for simplicity, but the need of a thread for preemption control does not reduce to locks held alone, and may result from other intra-application state conditions, such as executing a time-urgent fragment of code in response to a high-priority event (that may potentially be blocking for other threads) or other code paths that can lead to wait chains unless completed promptly. Second, in some cases application may need to perform time-urgent processing without knowing in advance how long it will take. In the majority of cases the processing may be very short (a fraction of a scheduling timeslice), but occasionally may take much longer (such as a fraction of a second). Since schedctl would not be effective in the latter case, an application would have to resort to system calls for thread priority control in all cases [*], even in the majority of "short processing" cases, with all the overhead of this approach. [*] Or introduce extra complexity, most likely very cumbersome, by trying to gauge and monitor the accumulated duration of the processing, with the intention to transition from schedctl to thread priority elevation once a threshold has been reached. [--- End of quote ---] Even so, I felt somewhat puzzled by the response to Khalid's delay-preempt patch. While some arguments put forth against it were certainly valid in their own right, but somehow their focus seemed to be that the solution won't interoperate well with all the conceivable setups and application mixes, won't solve all the concurrency issues, and the worst of all won't slice bread either. Whereas my perception (perhaps incorrectly) was that this patch was not meant to solve a whole range of problems and to be a feature enabled by default in a generic system, but rather a specialized feature configurable in special-purpose systems (e.g. database servers, Khalid was doing it for Oracle, and his JVM use case I believe is also in this context) dedicated to running a primary-importance application that utilizes this mechanism and meant to solve a very particular problem of this specific category of system deployment cases. It appeared to me that the participants to delay-preempt patch discussion might have had different idea of the implied use scope of the suggested feature, and it might have influenced the direction of the discussion. - Sergey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices
Hi Arnd, On Wednesday, June 18, 2014 Arnd wrote: > To: Tomasz Figa > Cc: linux-arm-ker...@lists.infradead.org; mark.br...@linaro.org; Tomasz Figa; > linux-samsung-...@vger.kernel.org; Kukjin Kim; Russell King - ARM Linux; Samuel > Ortiz; Pankaj Dubey; linux-kernel@vger.kernel.org; jo...@samsung.com; > vikas.saj...@samsung.com; chow@samsung.com; Lee Jones > Subject: Re: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon > devices > > On Tuesday 17 June 2014 23:26:22 Tomasz Figa wrote: > > On 17.06.2014 17:42, Arnd Bergmann wrote: > > > This seems like a reasonable way of solving the problem, but I think > > > there is an even better one that we have about in the past: if we > > > promote syscon from a platform driver into a a drivers/base/ helper > > > that is independent of the platform device matching, we can use call > > > syscon_regmap_lookup_* for any device node, whether it's already > > > bound to a driver or not, which do what you need. It would also make > > > it easier to call the syscon code before the platform_device > > > infrastructure gets initialized, which is something a number of > > > people have asked for, e.g. for using regmap to do SMP bringup or > > > for clock registration. > > > > Basically, unless I'm missing your point, this is what my patch does, > > except that I don't move it to drivers/base/ and the registration > > function I added require a pointer to struct device. Indeed, > > decoupling it further from the driver model, by adding > > of_syscon_register() should be useful for early users. > > I believe the part you are missing is that with the approach I suggested, there would > be no registration function at all. You can easily do the lookup from the client drivers > using the DT data structures, with no need for the device at all. Will you please elaborate more on this? The only exception > today is the clps711x platform using syscon_regmap_lookup_by_pdevname(), but > that should be solved in 3.17 when clps711x becomes DT-only. > Does it mean that this may become a blocking issue for this patch to go before 3.17? If yes, isn't it will be good to accept this patch as it is if it's not causing issue or breaking anything with existing users of syscon. At least for our use of converting Exynos PMU and PM related consolidation this change is working fine and we have verified it. > > Should I move this to drivers/base/, even though from current location > > it can be used outside the platform driver anyway? > > Thinking about it some more, drivers/of might be better than drivers/base. > It depends a bit where we are heading with this, in particular if we expect to see non- > DT users in the future. > > Arnd Thanks, Pankaj Dubey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [drm] WARNING: CPU: 2 PID: 430 at drivers/gpu/drm/drm_crtc.c:1391 drm_universal_plane_init+0x241/0x260 [drm]()
On 07/28/2014 11:16 AM, Nick Krause wrote:
> On Sun, Jul 27, 2014 at 10:02 PM, Aaron Lu wrote:
>> FYI, we noticed the below changes on
>>
>> git://people.freedesktop.org/~robclark/linux cold-fusion-v3.16-rc5
>> commit 08172e9d2385ca9bd545a8229ac749f589146a31 ("drm: convert plane to
>> properties/state")
>>
>> +-+++
>> | | 88471ddbb1 | 08172e9d23 |
>> +-+++
>> | boot_successes | 10 | 10 |
>> | early-boot-hang | 1 | 1 |
>> +-+++
>>
>>
>> [ 21.274681] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 21.275090] [drm] Driver supports precise vblank timestamp query.
>> [ 21.275984] [ cut here ]
>> [ 21.276300] WARNING: CPU: 2 PID: 430 at drivers/gpu/drm/drm_crtc.c:1391
>> drm_universal_plane_init+0x241/0x260 [drm]()
>> [ 21.277126] Modules linked in: firewire_ohci(+) firewire_core crc_itu_t
>> snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic shpchp pcspkr
>> i2c_i801 ahci snd_hda_intel i915(+) libahci snd_hda_controller libata
>> snd_hda_codec snd_hwdep snd_pcm snd_timer drm_kms_helper snd soundcore drm
>> winbond_cir rc_core floppy(+) parport_pc parport video
>> [ 21.279682] CPU: 2 PID: 430 Comm: modprobe Not tainted
>> 3.16.0-rc6-wl-ath-04110-gc6264ea #1
>> [ 21.280208] Hardware name: Intel Corporation 2012 Client
>> Platform/LosLunas CRB, BIOS ACRVMBY1.86C.0054.B00.1107311147 07/31/2011
>> [ 21.281029] 0009 88041b34b860 8182d64b
>>
>> [ 21.281655] 88041b34b898 8106d16d 88007fb32000
>>
>> [ 21.282191] 88041a9ebe00 000a 88041a9ebe00
>> 88041b34b8a8
>> [ 21.282791] Call Trace:
>> [ 21.282958] [] dump_stack+0x4d/0x66
>> [ 21.283290] [] warn_slowpath_common+0x7d/0xa0
>> [ 21.283756] [] warn_slowpath_null+0x1a/0x20
>> [ 21.284134] [] drm_universal_plane_init+0x241/0x260
>> [drm]
>> [ 21.284697] [] intel_modeset_init+0x471/0xe70 [i915]
>> [ 21.285127] [] ? ibx_irq_postinstall+0x5a/0xe0 [i915]
>> [ 21.285652] [] ? ironlake_irq_postinstall+0xc6/0x1a0
>> [i915]
>> [ 21.286137] [] i915_driver_load+0xb4a/0x1000 [i915]
>> [ 21.286640] [] ? kobject_uevent_env+0x178/0x690
>> [ 21.287028] [] ? get_device+0x17/0x30
>> [ 21.287361] [] ? klist_class_dev_get+0x15/0x20
>> [ 21.287813] [] ? klist_add_tail+0x3a/0x40
>> [ 21.288166] [] ? device_add+0x1f9/0x610
>> [ 21.288608] [] ? drm_sysfs_device_add+0xd6/0x120 [drm]
>> [ 21.289033] [] drm_dev_register+0xad/0x100 [drm]
>> [ 21.289420] [] drm_get_pci_dev+0x8f/0x1f0 [drm]
>> [ 21.289887] [] i915_pci_probe+0x3b/0x60 [i915]
>> [ 21.290258] [] local_pci_probe+0x45/0xa0
>> [ 21.290690] [] ? pci_match_device+0xe5/0x110
>> [ 21.291078] [] pci_device_probe+0xd1/0x130
>> [ 21.291435] [] driver_probe_device+0x90/0x3c0
>> [ 21.291891] [] __driver_attach+0x93/0xa0
>> [ 21.292227] [] ? __device_attach+0x40/0x40
>> [ 21.292640] [] bus_for_each_dev+0x63/0xa0
>> [ 21.292969] [] driver_attach+0x1e/0x20
>> [ 21.293293] [] bus_add_driver+0x180/0x250
>> [ 21.293705] [] driver_register+0x64/0xf0
>> [ 21.294041] [] __pci_register_driver+0x4c/0x50
>> [ 21.294399] [] drm_pci_init+0x10a/0x140 [drm]
>> [ 21.294863] [] ? 0xa026cfff
>> [ 21.295209] [] i915_init+0x89/0x90 [i915]
>> [ 21.295654] [] do_one_initcall+0xbc/0x1f0
>> [ 21.296010] [] ? __vunmap+0xb2/0x100
>> [ 21.296330] [] load_module+0x15fc/0x1a30
>> [ 21.296760] [] ? store_uevent+0x40/0x40
>> [ 21.297132] [] SyS_init_module+0xc1/0x110
>> [ 21.297470] [] system_call_fastpath+0x16/0x1b
>> [ 21.297910] ---[ end trace ecc622d672d3c733 ]---
>> [ 21.298652] [ cut here ]
>>
>>
>>
>> Disclaimer:
>> Results have been estimated based on internal Intel analysis and are provided
>> for informational purposes only. Any difference in system hardware or
>> software
>> design or configuration may affect actual performance.
>>
>> Thanks,
>> Aaron
>
> Aaron,
> I want to known what cpu's Intel is running this on it order to get
> kernel warning in the x86 boot code.
I suppose you want GPU information?
Here it is:
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen
Core processor Graphics Controller (rev 04) (prog-if 00 [VGA controller])
Subsystem: Intel Corporation Device 2211
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at afc0 (64-bit, non-prefetchable) [size=4M]
Memory at c000 (64-bit, prefetchable) [size=256M]
I/O ports at 2000 [size=64]
Expansion ROM at [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Re: [PATCH v2 2/2] pwm: add this patch to support the new pwm of Rockchip SoCs
Caesar,
On Sun, Jul 27, 2014 at 7:00 AM, caesar wrote:
> /*I think will be show the faill log:->
>
> * rockchip-pwm ff9301a0.pwm: can't request region for resource [mem
> 0xff9301a0-0xff93019f]
> */
>
> pc->base = devm_ioremap_resource(dev, regs);
Did you actually code this up and try it and get this error? I hadn't
tried it but I researched other dts files and it looked as if there
was one example that was doing this. ...but perhaps it wasn't
actually doing the ioremap_resource on both ranges.
I'd imagine that this is _probably_ equivalent to what Thierry was
suggesting, so if it didn't work then maybe Thierry's won't work
either?
I don't have any other great suggestions other than doing two memory
ranges for lcdc:
lcdc@ff93 {
compatible = "rockchip,rk3288-lcdc";
reg = <0xff93 0x1a0>, <0xff9301b0 0xfe50>;
...
};
pwm@ff9301a0 {
compatible = "rockchip,vop-pwm";
reg = <0xff9301a0 0x10>;
...
};
...but I am certainly nowhere near an expert on this stuff...
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Help with Brtfs Bugs
Hey Josef, Seems there are a lot of brtfs bugs open on the kernel Bugzilla. I am new to the brtfs side of development so please let me known if you want help cleaning up some of the bugs here that are actually valid and still open. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpuidle: ladder governor - use macro instead of hardcoded value
use CPUIDLE_DRIVER_STATE_START, instead of hardcoded value 0. As,
CPUIDLE_DRIVER_STATE_START can be 1/0 based on
CONFIG_ARCH_HAS_CPU_RELAX is defined or not.
Signed-off-by: Mohammad Merajul Islam Molla
---
drivers/cpuidle/governors/ladder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpuidle/governors/ladder.c
b/drivers/cpuidle/governors/ladder.c
index 9f08e8c..044ee0d 100644
--- a/drivers/cpuidle/governors/ladder.c
+++ b/drivers/cpuidle/governors/ladder.c
@@ -144,7 +144,7 @@ static int ladder_enable_device(struct cpuidle_driver *drv,
ldev->last_state_idx = CPUIDLE_DRIVER_STATE_START;
- for (i = 0; i < drv->state_count; i++) {
+ for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
state = >states[i];
lstate = >states[i];
@@ -156,7 +156,7 @@ static int ladder_enable_device(struct cpuidle_driver *drv,
if (i < drv->state_count - 1)
lstate->threshold.promotion_time = state->exit_latency;
- if (i > 0)
+ if (i > CPUIDLE_DRIVER_STATE_START)
lstate->threshold.demotion_time = state->exit_latency;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the modules tree
Hi Rusty,
After merging the modules tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/thread_info.h:11:0,
from arch/powerpc/include/asm/ptrace.h:151,
from arch/powerpc/include/asm/processor.h:44,
from arch/powerpc/include/asm/mmu-hash64.h:25,
from arch/powerpc/include/asm/mmu.h:189,
from arch/powerpc/include/asm/lppaca.h:36,
from arch/powerpc/include/asm/paca.h:20,
from arch/powerpc/include/asm/current.h:16,
from include/linux/mutex.h:13,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/of.h:21,
from arch/powerpc/platforms/powernv/opal-elog.c:13:
include/linux/bug.h:33:45: error: negative width in bit-field ''
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/kernel.h:853:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO((perms) & 2) +\
^
include/linux/sysfs.h:75:12: note: in expansion of macro
'VERIFY_OCTAL_PERMISSIONS'
.mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
^
arch/powerpc/platforms/powernv/opal-elog.c:85:2: note: in expansion of macro
'__ATTR'
__ATTR(id, 0666, elog_id_show, NULL);
^
include/linux/bug.h:33:45: error: negative width in bit-field ''
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/kernel.h:853:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO((perms) & 2) +\
^
include/linux/sysfs.h:75:12: note: in expansion of macro
'VERIFY_OCTAL_PERMISSIONS'
.mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
^
arch/powerpc/platforms/powernv/opal-elog.c:87:2: note: in expansion of macro
'__ATTR'
__ATTR(type, 0666, elog_type_show, NULL);
^
In file included from include/linux/thread_info.h:11:0,
from arch/powerpc/include/asm/ptrace.h:151,
from arch/powerpc/include/asm/processor.h:44,
from arch/powerpc/include/asm/mmu-hash64.h:25,
from arch/powerpc/include/asm/mmu.h:189,
from arch/powerpc/include/asm/lppaca.h:36,
from arch/powerpc/include/asm/paca.h:20,
from arch/powerpc/include/asm/current.h:16,
from include/linux/mutex.h:13,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from arch/powerpc/platforms/powernv/opal-dump.c:12:
include/linux/bug.h:33:45: error: negative width in bit-field ''
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/kernel.h:853:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO((perms) & 2) +\
^
include/linux/sysfs.h:75:12: note: in expansion of macro
'VERIFY_OCTAL_PERMISSIONS'
.mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
^
arch/powerpc/platforms/powernv/opal-dump.c:105:2: note: in expansion of macro
'__ATTR'
__ATTR(id, 0666, dump_id_show, NULL);
^
include/linux/bug.h:33:45: error: negative width in bit-field ''
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/kernel.h:853:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO((perms) & 2) +\
^
include/linux/sysfs.h:75:12: note: in expansion of macro
'VERIFY_OCTAL_PERMISSIONS'
.mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
^
arch/powerpc/platforms/powernv/opal-dump.c:107:2: note: in expansion of macro
'__ATTR'
__ATTR(type, 0666, dump_type_show, NULL);
^
Caused by commit 37549e94c77a ("sysfs: disallow world-writable files")
interacting with commit c7e64b9ce04a ("powerpc/powernv Platform dump
interface") from v3.15-rc1. I guess this patch needs updating ...
I have used the modules tree form next-20140725 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
signature.asc
Description: PGP signature
[PATCH v2] PCI: tegra: add missing cleanup in error path and teardown_irq
We should call tegra_msi_free() to free the msi bit if
irq_create_mapping() fails. And we need to dispose the irq mapping
during irq teardown.
Signed-off-by: Jisheng Zhang
---
drivers/pci/host/pci-tegra.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 083cf37..4ccc418 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1203,8 +1203,10 @@ static int tegra_msi_setup_irq(struct msi_chip *chip,
struct pci_dev *pdev,
return hwirq;
irq = irq_create_mapping(msi->domain, hwirq);
- if (!irq)
+ if (!irq) {
+ tegra_msi_free(msi, hwirq);
return -EINVAL;
+ }
irq_set_msi_desc(irq, desc);
@@ -1222,8 +1224,10 @@ static void tegra_msi_teardown_irq(struct msi_chip
*chip, unsigned int irq)
{
struct tegra_msi *msi = to_tegra_msi(chip);
struct irq_data *d = irq_get_irq_data(irq);
+ unsigned long hwirq = d->hwirq;
- tegra_msi_free(msi, d->hwirq);
+ irq_dispose_mapping(irq);
+ tegra_msi_free(msi, hwirq);
}
static struct irq_chip tegra_msi_irq_chip = {
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are 3 more small powerpc fixes that should still go into .16. One is a recent regression (MMCR2 business), the other is a trivial endian fix without which FW updates won't work on LE in IBM machines, and the 3rd one turns a BUG_ON into a WARN_ON which is definitely a LOT more friendly especially when the whole thing is about retrieving error logs ... Cheers, Ben. The following changes since commit 6f5405bc2ee0102bb3856e2cdea64ff415db2e0c: powerpc: use _GLOBAL_TOC for memmove (2014-07-22 15:56:04 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 396a34340cdf7373c00e3977db27d1a20ea65ebc: powerpc: Fix endianness of flash_block_list in rtas_flash (2014-07-28 11:30:54 +1000) Michael Ellerman (1): powerpc/perf: Fix MMCR2 handling for EBB Thomas Falcon (1): powerpc: Fix endianness of flash_block_list in rtas_flash Vasant Hegde (1): powerpc/powernv: Change BUG_ON to WARN_ON in elog code arch/powerpc/kernel/rtas_flash.c | 6 -- arch/powerpc/perf/core-book3s.c| 6 +++--- arch/powerpc/platforms/powernv/opal-elog.c | 4 ++-- 3 files changed, 9 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] block: loop: support to submit I/O via kernel aio based
Hi David, Thanks for your interest in the patch. On Sun, Jul 27, 2014 at 10:20 PM, David Horner wrote: > You mention > 100 % improvement. > > Can you help me to run some (micro) benchmarks that I could contribute to > V1? Sure, no problem, generally I just run tests over the loop block device directly, since I want to expose performance improvement. But I did run test bench(mkfs, copy big file and compare, ...) over filesystem mounted on the loop device too, and looks it is stable enough. So your benchmarks are either on loop block or filesystem, both are fine. > If you can direct me to relevant threads and docs that would be greatly > appreciated. Follows my test which was observed with 100% improvement( throughout is doubled, actually it is more than doubled): - losetup -f /dev/nullb0 #so /dev/loop0 will be backed with /dev/nullb0 #if it is the 1st loop device - run below fio script[1] in single job to test direct randread on /dev/loop0 - it is just for single job improvement, with more than 1 jobs, the throughout should be increased more with blk-mq conversion I will send out V1 this week, and more test cases may be posted too. [1], fio test script [global] direct=1 size=32G bsrange=4k-4k timeout=20 numjobs=1 ioengine=libaio iodepth=64 filename=/dev/loop0 group_reporting=1 [f] rw=randread Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched/fair: Fix 'make xmldocs' warning caused by missing description
This patch fix following warning caused by missing description "overload" in kernel/sched/fair.c Warning(.//kernel/sched/fair.c:5906): No description found for parameter 'overload' Signed-off-by: Masanari Iida --- kernel/sched/fair.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 45943b2..bfa3c86 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5898,6 +5898,7 @@ static inline int sg_capacity_factor(struct lb_env *env, struct sched_group *gro * @load_idx: Load index of sched_domain of this_cpu for load calc. * @local_group: Does group contain this_cpu. * @sgs: variable to hold the statistics for this group. + * @overload: Indicate more than one runnable task for any CPU. */ static inline void update_sg_lb_stats(struct lb_env *env, struct sched_group *group, int load_idx, -- 2.1.0.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2 v4] sched: Rewrite per entity runnable load average tracking
Thanks a lot, Mike. Ben asked for this test, but actually I don't know how to get pipe-test, still not even after google it. On Sun, Jul 20, 2014 at 07:46:23AM +0200, Mike Galbraith wrote: > On Fri, 2014-07-18 at 07:26 +0800, Yuyang Du wrote: > > Thanks to Morten, Ben, and Fengguang. > > > > v4 changes: > > > > - Insert memory barrier before writing cfs_rq->load_last_update_copy. > > - Fix typos. > > My little desktop box says lovely minus signs have had their usual > effect on the general case (cgroups enabled but not in use). > > pipe-test scheduling cross core - full fastpath > 3.0.101-default3.753363 usecs/loop -- avg 3.770737 530.4 KHz 1.000 > 3.1.10-default 3.723843 usecs/loop -- avg 3.716058 538.2 KHz 1.014 > 3.2.51-default 3.728060 usecs/loop -- avg 3.710372 539.0 KHz 1.016 > 3.3.8-default 3.906174 usecs/loop -- avg 3.900399 512.8 KHz.966 > 3.4.97-default 3.864158 usecs/loop -- avg 3.865281 517.4 KHz.975 > 3.5.7-default 3.967481 usecs/loop -- avg 3.962757 504.7 KHz.951 > 3.6.11-default 3.851186 usecs/loop -- avg 3.845321 520.1 KHz.980 > 3.7.10-default 3.777869 usecs/loop -- avg 3.776913 529.5 KHz.998 > 3.8.13-default 4.049927 usecs/loop -- avg 4.041905 494.8 KHz.932 > 3.9.11-default 3.973046 usecs/loop -- avg 3.974208 503.2 KHz.948 > 3.10.27-default4.189598 usecs/loop -- avg 4.189298 477.4 KHz.900 > 3.11.10-default4.293870 usecs/loop -- avg 4.297979 465.3 KHz.877 > 3.12.24-default4.321570 usecs/loop -- avg 4.321961 462.8 KHz.872 > 3.13.11-default4.137845 usecs/loop -- avg 4.134863 483.7 KHz.911 > 3.14.10-default4.145348 usecs/loop -- avg 4.139987 483.1 KHz.910 > > 3.15.4-default 4.355594 usecs/loop -- avg 4.351961 459.6 KHz.866 > > 3.16.0-default 4.537279 usecs/loop -- avg 4.543532 440.2 KHz.829 >1.000 > 3.16.0-default+v4 4.343542 usecs/loop -- avg 4.318803 463.1 KHz.873 >1.052 > > Extending max depth to 5, cost of depth++ seemingly did not change > despite repeatable dip at depth = 3 (gremlins at play). > > mount -t cgroup o cpu none /cgroups > mkdir -p /cgroups/a/b/c/d/e > > cgexec -g cpu:a pipe-test 1 > 3.16.0-default 5.016373 usecs/loop -- avg 5.021115 398.3 KHz 1.000 > 3.16.0-default+v4 4.978625 usecs/loop -- avg 4.977381 401.8 KHz 1.008 > > cgexec -g cpu:a/b pipe-test 1 > 3.16.0-default 5.543566 usecs/loop -- avg 5.565475 359.4 KHz 1.000 > 3.16.0-default+v4 5.597399 usecs/loop -- avg 5.570444 359.0 KHz.998 > > cgexec -g cpu:a/b/c pipe-test 1 > 3.16.0-default 6.092256 usecs/loop -- avg 6.094186 328.2 KHz 1.000 > 3.16.0-default+v4 6.294858 usecs/loop -- avg 6.338453 315.5 KHz.961 > > cgexec -g cpu:a/b/c/d pipe-test 1 > 3.16.0-default 6.719044 usecs/loop -- avg 6.717118 297.7 KHz 1.000 > 3.16.0-default+v4 6.788559 usecs/loop -- avg 6.710102 298.1 KHz 1.001 > > cgexec -g cpu:a/b/c/d/e pipe-test 1 > 3.16.0-default 7.186431 usecs/loop -- avg 7.194884 278.0 KHz 1.000 > 3.16.0-default+v4 7.368443 usecs/loop -- avg 7.250371 275.8 KHz.992 > So the result is flat compared to before or a pass? Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/9] perf, x86: handle multiple records in PEBS buffer
> I don't think this method works for interrupt threshold > 1 case. When > collision > happens, the hardware only create one PEBS record. The status in next record > has > nothing to do with the collision record. > Not even for the threshold == 1 case, because the same could happen with a different PEBS event. Of course in any case it's very unlikely ... > > > So typically we'd have one event set and no problem, but in case there's > > more we can reconstruct with such a backwards pass from a known good > > state. > > > > But when in doubt, we should drop the record, its the safest choice. > > The problem is that, in some cases, each PEBS record has more than one events > set, so we will drop all records. Just dropping is fine imho, this should be rare. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/9] perf, x86: handle multiple records in PEBS buffer
> how about following patch
Looks good to me.
This will also solve the existing problem that perf record -e cycles:u
... gives kernel samples too.
-Andi
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
> b/arch/x86/kernel/cpu/perf_event_intel_ds.c
> index 33b4c0e..ea76507 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
> @@ -1016,6 +1016,16 @@ static void setup_pebs_sample_data(struct perf_event
> *event,
> data->br_stack = >lbr_stack;
> }
>
> +static inline bool intel_pmu_pebs_filter(struct perf_event *event,
> + struct pebs_record_nhm *record)
> +{
> + if (event->attr.exclude_user && !kernel_ip(record->ip))
> + return true;
> + if (event->attr.exclude_kernel && kernel_ip(record->ip))
> + return true;
> + return false;
> +}
> +
> static void __intel_pmu_pebs_event(struct perf_event *event,
> struct pt_regs *iregs,
> void *at, void *top, int count)
> @@ -1052,6 +1062,8 @@ static void __intel_pmu_pebs_event(struct perf_event
> *event,
> struct pebs_record_nhm *p = at;
> if (!(p->status & (1 << event->hw.idx)))
> continue;
> + if (intel_pmu_pebs_filter(event, p))
> + continue;
>
> setup_pebs_sample_data(event, iregs, at, , );
> perf_output_sample(, , , event);
> @@ -1139,6 +1151,8 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs
> *iregs)
> WARN_ON_ONCE(!event);
> if (!event->attr.precise_ip)
> continue;
> + if (intel_pmu_pebs_filter(event, p))
> + continue;
> counts[bit]++;
> }
> }
> @@ -1149,7 +1163,8 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs
> *iregs)
> event = cpuc->events[bit];
> for (at = base; at < top; at += x86_pmu.pebs_record_size) {
> struct pebs_record_nhm *p = at;
> - if (p->status & (1 << bit))
> + if ((p->status & (1 << bit)) &&
> + !intel_pmu_pebs_filter(event, p))
> break;
> }
>
> ---
>
--
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Multi Core Support for compression in compression.c
On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn wrote: > On 07/27/2014 04:47 PM, Nick Krause wrote: >> This may be a bad idea , but compression in brtfs seems to be only >> using one core to compress. >> Depending on the CPU used and the amount of cores in the CPU we can >> make this much faster >> with multiple cores. This seems bad by my reading at least I would >> recommend for writing compression >> we write a function to use a certain amount of cores based on the load >> of the system's CPU not using >> more then 75% of the system's CPU resources as my system when idle has >> never needed more >> then one core of my i5 2500k to run when with interrupts for opening >> eclipse are running. For reading >> compression on good core seems fine to me as testing other compression >> software for reads , it's >> way less CPU intensive. >> Cheers Nick > We would probably get a bigger benefit from taking an approach like > SquashFS has recently added, that is, allowing multi-threaded > decompression fro reads, and decompressing directly into the pagecache. > Such an approach would likely make zlib compression much more scalable > on large systems. > > Austin, That seems better then my idea as you seem to be more up to date on brtfs devolopment. If you and the other developers of brtfs are interested in adding this as a feature please let me known as I would like to help improve brtfs as the file system as an idea is great just seems like it needs a lot of work :). Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/9] perf, x86: handle multiple records in PEBS buffer
On 07/26/2014 12:40 AM, Andi Kleen wrote:
>> Suppose two pebs events, one has exclude_kernel set. It overflows,
>> before entering the kernel, the other event generates PEBS records from
>> inside the kernel with both events marked in the overflow field.
>>
>> And only once we leave the kernel can the exclude_kernel event tick
>> again and trigger the assist, finalyl clearing the bit.
>>
>> If you were to report the records to both events, one would get a lot of
>> kernel info he was not entitled to.
>
> Ok that case can be filtered in software. Shouldn't be too difficult.
> Perhaps just using ip
>
> if (event->attr.exclude_kernel && pebs->ip >= __PAGE_OFFSET)
> skip;
> if (event->attr.exclude_user && pebs->ip < __PAGE_OFFSET)
> skip;
>
> This would also help with the existing skid.
>
> Any other concerns?
>
> -Andi
>
how about following patch
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 33b4c0e..ea76507 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -1016,6 +1016,16 @@ static void setup_pebs_sample_data(struct perf_event
*event,
data->br_stack = >lbr_stack;
}
+static inline bool intel_pmu_pebs_filter(struct perf_event *event,
+struct pebs_record_nhm *record)
+{
+ if (event->attr.exclude_user && !kernel_ip(record->ip))
+ return true;
+ if (event->attr.exclude_kernel && kernel_ip(record->ip))
+ return true;
+ return false;
+}
+
static void __intel_pmu_pebs_event(struct perf_event *event,
struct pt_regs *iregs,
void *at, void *top, int count)
@@ -1052,6 +1062,8 @@ static void __intel_pmu_pebs_event(struct perf_event
*event,
struct pebs_record_nhm *p = at;
if (!(p->status & (1 << event->hw.idx)))
continue;
+ if (intel_pmu_pebs_filter(event, p))
+ continue;
setup_pebs_sample_data(event, iregs, at, , );
perf_output_sample(, , , event);
@@ -1139,6 +1151,8 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs
*iregs)
WARN_ON_ONCE(!event);
if (!event->attr.precise_ip)
continue;
+ if (intel_pmu_pebs_filter(event, p))
+ continue;
counts[bit]++;
}
}
@@ -1149,7 +1163,8 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs
*iregs)
event = cpuc->events[bit];
for (at = base; at < top; at += x86_pmu.pebs_record_size) {
struct pebs_record_nhm *p = at;
- if (p->status & (1 << bit))
+ if ((p->status & (1 << bit)) &&
+ !intel_pmu_pebs_filter(event, p))
break;
}
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [drm] WARNING: CPU: 2 PID: 430 at drivers/gpu/drm/drm_crtc.c:1391 drm_universal_plane_init+0x241/0x260 [drm]()
On Sun, Jul 27, 2014 at 10:02 PM, Aaron Lu wrote:
> FYI, we noticed the below changes on
>
> git://people.freedesktop.org/~robclark/linux cold-fusion-v3.16-rc5
> commit 08172e9d2385ca9bd545a8229ac749f589146a31 ("drm: convert plane to
> properties/state")
>
> +-+++
> | | 88471ddbb1 | 08172e9d23 |
> +-+++
> | boot_successes | 10 | 10 |
> | early-boot-hang | 1 | 1 |
> +-+++
>
>
> [ 21.274681] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [ 21.275090] [drm] Driver supports precise vblank timestamp query.
> [ 21.275984] [ cut here ]
> [ 21.276300] WARNING: CPU: 2 PID: 430 at drivers/gpu/drm/drm_crtc.c:1391
> drm_universal_plane_init+0x241/0x260 [drm]()
> [ 21.277126] Modules linked in: firewire_ohci(+) firewire_core crc_itu_t
> snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic shpchp pcspkr
> i2c_i801 ahci snd_hda_intel i915(+) libahci snd_hda_controller libata
> snd_hda_codec snd_hwdep snd_pcm snd_timer drm_kms_helper snd soundcore drm
> winbond_cir rc_core floppy(+) parport_pc parport video
> [ 21.279682] CPU: 2 PID: 430 Comm: modprobe Not tainted
> 3.16.0-rc6-wl-ath-04110-gc6264ea #1
> [ 21.280208] Hardware name: Intel Corporation 2012 Client Platform/LosLunas
> CRB, BIOS ACRVMBY1.86C.0054.B00.1107311147 07/31/2011
> [ 21.281029] 0009 88041b34b860 8182d64b
>
> [ 21.281655] 88041b34b898 8106d16d 88007fb32000
>
> [ 21.282191] 88041a9ebe00 000a 88041a9ebe00
> 88041b34b8a8
> [ 21.282791] Call Trace:
> [ 21.282958] [] dump_stack+0x4d/0x66
> [ 21.283290] [] warn_slowpath_common+0x7d/0xa0
> [ 21.283756] [] warn_slowpath_null+0x1a/0x20
> [ 21.284134] [] drm_universal_plane_init+0x241/0x260
> [drm]
> [ 21.284697] [] intel_modeset_init+0x471/0xe70 [i915]
> [ 21.285127] [] ? ibx_irq_postinstall+0x5a/0xe0 [i915]
> [ 21.285652] [] ? ironlake_irq_postinstall+0xc6/0x1a0
> [i915]
> [ 21.286137] [] i915_driver_load+0xb4a/0x1000 [i915]
> [ 21.286640] [] ? kobject_uevent_env+0x178/0x690
> [ 21.287028] [] ? get_device+0x17/0x30
> [ 21.287361] [] ? klist_class_dev_get+0x15/0x20
> [ 21.287813] [] ? klist_add_tail+0x3a/0x40
> [ 21.288166] [] ? device_add+0x1f9/0x610
> [ 21.288608] [] ? drm_sysfs_device_add+0xd6/0x120 [drm]
> [ 21.289033] [] drm_dev_register+0xad/0x100 [drm]
> [ 21.289420] [] drm_get_pci_dev+0x8f/0x1f0 [drm]
> [ 21.289887] [] i915_pci_probe+0x3b/0x60 [i915]
> [ 21.290258] [] local_pci_probe+0x45/0xa0
> [ 21.290690] [] ? pci_match_device+0xe5/0x110
> [ 21.291078] [] pci_device_probe+0xd1/0x130
> [ 21.291435] [] driver_probe_device+0x90/0x3c0
> [ 21.291891] [] __driver_attach+0x93/0xa0
> [ 21.292227] [] ? __device_attach+0x40/0x40
> [ 21.292640] [] bus_for_each_dev+0x63/0xa0
> [ 21.292969] [] driver_attach+0x1e/0x20
> [ 21.293293] [] bus_add_driver+0x180/0x250
> [ 21.293705] [] driver_register+0x64/0xf0
> [ 21.294041] [] __pci_register_driver+0x4c/0x50
> [ 21.294399] [] drm_pci_init+0x10a/0x140 [drm]
> [ 21.294863] [] ? 0xa026cfff
> [ 21.295209] [] i915_init+0x89/0x90 [i915]
> [ 21.295654] [] do_one_initcall+0xbc/0x1f0
> [ 21.296010] [] ? __vunmap+0xb2/0x100
> [ 21.296330] [] load_module+0x15fc/0x1a30
> [ 21.296760] [] ? store_uevent+0x40/0x40
> [ 21.297132] [] SyS_init_module+0xc1/0x110
> [ 21.297470] [] system_call_fastpath+0x16/0x1b
> [ 21.297910] ---[ end trace ecc622d672d3c733 ]---
> [ 21.298652] [ cut here ]
>
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
> Thanks,
> Aaron
Aaron,
I want to known what cpu's Intel is running this on it order to get
kernel warning in the x86 boot code.
Regards Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] drivers: staging: cxt1e1: linux.c - missing __user annotation
On Mon, Jul 28, 2014 at 08:38:29AM +0530, Anil Belur wrote:
> From: Anil Belur
>
> - Some of the functions internally call copy_{to,from}_user() but does
> not use '__user'. this patch fixes missing __user annotations.
> - this patch fixes the following sparse errors:
> drivers/staging/cxt1e1/linux.c:488:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:488:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:488:33:got void *data
> drivers/staging/cxt1e1/linux.c:499:26: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:499:26:expected void [noderef] *to
> drivers/staging/cxt1e1/linux.c:499:26:got void *data
> drivers/staging/cxt1e1/linux.c:512:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:512:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:512:33:got void *data
> drivers/staging/cxt1e1/linux.c:534:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:534:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:534:33:got void *data
> drivers/staging/cxt1e1/linux.c:550:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:550:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:550:33:got void *data
> drivers/staging/cxt1e1/linux.c:558:26: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:558:26:expected void [noderef] *to
> drivers/staging/cxt1e1/linux.c:558:26:got void *data
> drivers/staging/cxt1e1/linux.c:571:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:571:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:571:33:got void *data
> drivers/staging/cxt1e1/linux.c:580:26: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:580:26:expected void [noderef] *to
> drivers/staging/cxt1e1/linux.c:580:26:got void *data
> drivers/staging/cxt1e1/linux.c:593:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:593:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:593:33:got void *data
> drivers/staging/cxt1e1/linux.c:601:26: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:601:26:expected void [noderef] *to
> drivers/staging/cxt1e1/linux.c:601:26:got void *data
> drivers/staging/cxt1e1/linux.c:612:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:612:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:612:33:got void *data
> drivers/staging/cxt1e1/linux.c:620:26: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:620:26:expected void [noderef] *to
> drivers/staging/cxt1e1/linux.c:620:26:got void *data
> drivers/staging/cxt1e1/linux.c:631:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:631:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:631:33:got void *data
> drivers/staging/cxt1e1/linux.c:647:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:647:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:647:33:got void *data
> drivers/staging/cxt1e1/linux.c:673:34: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:673:34:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:673:34:got void *data
> drivers/staging/cxt1e1/linux.c:681:26: warning: incorrect type in argument 1
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:681:26:expected void [noderef] *to
> drivers/staging/cxt1e1/linux.c:681:26:got void *data
> drivers/staging/cxt1e1/linux.c:691:47: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:691:47:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:691:47:got void *data
> drivers/staging/cxt1e1/linux.c:738:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:738:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:738:33:got void *data
> drivers/staging/cxt1e1/linux.c:785:33: warning: incorrect type in argument 2
> (different address spaces)
> drivers/staging/cxt1e1/linux.c:785:33:expected void const [noderef]
> *from
> drivers/staging/cxt1e1/linux.c:785:33:got void *data
>
RE: [PATCH v7 3/4] ARM: EXYNOS: Add platform driver support for Exynos PMU
Hi Tomasz, On Friday, July 25, 2014 Tomasz Figa wrote: > To: Pankaj Dubey; 'Kukjin Kim'; linux-arm-ker...@lists.infradead.org; linux- > samsung-...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: li...@arm.linux.org.uk; t.f...@samsung.com; vikas.saj...@samsung.com; > jo...@samsung.com; naus...@samsung.com; thomas...@samsung.com; > chow@samsung.com > Subject: Re: [PATCH v7 3/4] ARM: EXYNOS: Add platform driver support for > Exynos PMU > > Hi Pankaj, Kukjin, > > On 25.07.2014 07:32, Pankaj Dubey wrote: > > Hi Kukjin, > > > > On Friday, July 25, 2014 Kukjin Kim wrote: > > [snip] > > >>> > >> Looks good to me, will apply this and 4/4. > >> > > > > We need to hold these two patches until dependent patch [1] from > > Tomasz Figa gets merged. > > > > [1]: mfd: syscon: Decouple syscon interface from syscon devices > > https://lkml.org/lkml/2014/6/24/188 > > That RFC patch had few comments from Arnd needed to be addressed, so it needs a > new revision. > > Pankaj, If I remember correctly, we had talked about this and the conclusion was that > you would take care of addressing the comments and sending new version of the > patch. Any update on this or have I missed something? > Well, I don't think we concluded as such anything. Since this patch needs to get in so that Exynos PMU and PM related changes can go in, I discussed with you saying that I am not able to understand about Arnd's comments and if possible and time permits I will look into it. Meanwhile I got busy with some other official work, so could not get time to look into it. > Best regards, > Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] drivers: staging: cxt1e1: linux.c - missing __user annotation
From: Anil Belur
- Some of the functions internally call copy_{to,from}_user() but does
not use '__user'. this patch fixes missing __user annotations.
- this patch fixes the following sparse errors:
drivers/staging/cxt1e1/linux.c:488:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:488:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:488:33:got void *data
drivers/staging/cxt1e1/linux.c:499:26: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/cxt1e1/linux.c:499:26:expected void [noderef] *to
drivers/staging/cxt1e1/linux.c:499:26:got void *data
drivers/staging/cxt1e1/linux.c:512:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:512:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:512:33:got void *data
drivers/staging/cxt1e1/linux.c:534:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:534:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:534:33:got void *data
drivers/staging/cxt1e1/linux.c:550:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:550:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:550:33:got void *data
drivers/staging/cxt1e1/linux.c:558:26: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/cxt1e1/linux.c:558:26:expected void [noderef] *to
drivers/staging/cxt1e1/linux.c:558:26:got void *data
drivers/staging/cxt1e1/linux.c:571:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:571:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:571:33:got void *data
drivers/staging/cxt1e1/linux.c:580:26: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/cxt1e1/linux.c:580:26:expected void [noderef] *to
drivers/staging/cxt1e1/linux.c:580:26:got void *data
drivers/staging/cxt1e1/linux.c:593:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:593:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:593:33:got void *data
drivers/staging/cxt1e1/linux.c:601:26: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/cxt1e1/linux.c:601:26:expected void [noderef] *to
drivers/staging/cxt1e1/linux.c:601:26:got void *data
drivers/staging/cxt1e1/linux.c:612:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:612:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:612:33:got void *data
drivers/staging/cxt1e1/linux.c:620:26: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/cxt1e1/linux.c:620:26:expected void [noderef] *to
drivers/staging/cxt1e1/linux.c:620:26:got void *data
drivers/staging/cxt1e1/linux.c:631:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:631:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:631:33:got void *data
drivers/staging/cxt1e1/linux.c:647:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:647:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:647:33:got void *data
drivers/staging/cxt1e1/linux.c:673:34: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:673:34:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:673:34:got void *data
drivers/staging/cxt1e1/linux.c:681:26: warning: incorrect type in argument 1
(different address spaces)
drivers/staging/cxt1e1/linux.c:681:26:expected void [noderef] *to
drivers/staging/cxt1e1/linux.c:681:26:got void *data
drivers/staging/cxt1e1/linux.c:691:47: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:691:47:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:691:47:got void *data
drivers/staging/cxt1e1/linux.c:738:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:738:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:738:33:got void *data
drivers/staging/cxt1e1/linux.c:785:33: warning: incorrect type in argument 2
(different address spaces)
drivers/staging/cxt1e1/linux.c:785:33:expected void const [noderef]
*from
drivers/staging/cxt1e1/linux.c:785:33:got void *data
drivers/staging/cxt1e1/linux.c:839:14: warning: incorrect type in assignment
(different address spaces)
drivers/staging/cxt1e1/linux.c:839:14:expected void *data
drivers/staging/cxt1e1/linux.c:839:14:got void [noderef] *
drivers/staging/cxt1e1/linux.c:840:34:
hi
Hello My name is favour kamala i saw your profile today in this site i will also like to know you the more,and i want you to send an email to my email address so i can give you my pictures for you to know whom i am.Here is my email address (kamala_fav...@yahoo.com) I believe we can move from here!I am waiting for your mail to my email address above catherine (Remember the distance or color does not matter but love matters a lot in life) please contact me here (kamala_fav...@yahoo.com) (kamala_fav...@yahoo.com) kamala_fav...@yahoo.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2 v4] sched: Rewrite per entity runnable load average tracking
Hi Morten, On Fri, Jul 18, 2014 at 04:39:31PM +0100, Morten Rasmussen wrote: > 1. runnable_avg_period is removed > > load_avg_contrib used to be runnable_avg_sum/runnable_avg_period scaled > by the task load weight (priority). The runnable_avg_period is replaced > by a constant in this patch set. The effect of that change is that task > load tracking no longer is more sensitive early life of the task until > it has built up some history. Task are now initialized to start out as > if they have been runnable forever (>345ms). If this assumption about > the task behavior is wrong it will take longer to converge to the true > average than it did before. The upside is that is more stable. I think "Give new task start runnable values to heavy its load in infant time" in general is good, with an emphasis on infant. Or from the opposite, making it zero to let it gain runnable weight looks worse than full weight. > 2. runnable_load_avg and blocked_load_avg are combined > > runnable_load_avg currently represents the sum of load_avg_contrib of > all tasks on the rq, while blocked_load_avg is the sum of those tasks > not on a runqueue. It makes perfect sense to consider the sum of both > when calculating the load of a cpu, but we currently don't include > blocked_load_avg. The reason for that is the priority scaling of the > task load_avg_contrib may lead to under-utilization of cpus that > occasionally have tiny high priority task running. You can easily have a > task that takes 5% of cpu time but has a load_avg_contrib several times > larger than a default priority task runnable 100% of the time. So this is the effect of historical averaging and weight scaling, both of which are just generally good, but may have bad cases. > Another thing that might be an issue is that the blocked of a terminated > task lives on for quite a while until has decayed away. Good point. To do so, if I read correctly, we need to hook do_exit(), but probably we are gonna encounter rq->lock issue. What is the opinion/guidance from the maintainers/others? > I'm all for taking the blocked load into consideration, but this issue > has to be resolved first. Which leads me on to the next thing. > > Most of the work going on around energy awareness is based on the load > tracking to estimate task and cpu utilization. It seems that most of the > involved parties think that we need an unweighted variant of the tracked > load as well as tracking the running time of a task. The latter was part > of the original proposal by pjt and Ben, but wasn't used. It seems that > unweighted runnable tracking should be fairly easy to add to your > proposal, but I don't have an overview of whether it is possible to add > running tracking. Do you think that is possible? > Running tracking is absolutely possbile, just the matter of minimizing overhead (how to do it along with runnable for task and maybe for CPU, but not for cfs_rq) from execution and code cleanness ponit of view. We can do it as soon as it is needed. Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi Core Support for compression in compression.c
On 07/27/2014 04:47 PM, Nick Krause wrote: > This may be a bad idea , but compression in brtfs seems to be only > using one core to compress. > Depending on the CPU used and the amount of cores in the CPU we can > make this much faster > with multiple cores. This seems bad by my reading at least I would > recommend for writing compression > we write a function to use a certain amount of cores based on the load > of the system's CPU not using > more then 75% of the system's CPU resources as my system when idle has > never needed more > then one core of my i5 2500k to run when with interrupts for opening > eclipse are running. For reading > compression on good core seems fine to me as testing other compression > software for reads , it's > way less CPU intensive. > Cheers Nick We would probably get a bigger benefit from taking an approach like SquashFS has recently added, that is, allowing multi-threaded decompression fro reads, and decompressing directly into the pagecache. Such an approach would likely make zlib compression much more scalable on large systems. smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v5 3/6] thermal: Added Bang-bang thermal governor
On Sat, 2014-07-26 at 16:14 +0200, Peter Feuerer wrote: > Hi Rui, > > Peter Feuerer writes: > > > The bang-bang thermal governor uses a hysteresis to switch abruptly on > > or off a cooling device. It is intended to control fans, which can > > not be throttled but just switched on or off. > > Bang-bang cannot be set as default governor as it is intended for > > special devices only. For those special devices the driver needs to > > explicitely request it. > > > > Cc: Andrew Morton > > Cc: Zhang Rui > > Anything that prevents you from giving your acked-by? > NO. I'll queue them for 3.18. thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/9] perf, x86: handle multiple records in PEBS buffer
On 07/25/2014 10:06 PM, Peter Zijlstra wrote: > On Fri, Jul 25, 2014 at 04:34:44PM +0800, Yan, Zheng wrote: >> On 07/25/2014 04:10 PM, Peter Zijlstra wrote: >>> On Tue, Jul 22, 2014 at 04:09:59PM +0800, Yan, Zheng wrote: One corner case needs to mention is that the PEBS hardware doesn't deal well with collisions, when PEBS events happen near to each other. The records for the events can be collapsed into a single one. However in practice collisions are extremely rare, as long as different events are used. The periods are typically very large, so any collision is unlikely. When collision happens, we can either drop the PEBS record or use the record to serve multiple events. This patch chooses the later approach. >>> >>> You can't.. the events might have different security context. >>> >>> Remember, the overflow bit is set from the overflow until the PEBS >>> event is generated, this is quite a long time. So if another PEBS event >>> gets generated while the other is still pending it will have both bits >>> set. Even though the second bit is for another (unrelated) counter. >>> >>> The unrelated counter might not have privilege to observe the data of >>> the generated event. >>> >>> I think you can unwind and fully correct this trainwreck. >> >> could you give more information how to do this. > > We went over that already: > > lkml.kernel.org/r/20140528170531.gt30...@twins.programming.kicks-ass.net > > Now ignore the patch there, its nonsense. > > But the idea is that the bit gets cleared upon writing the PEBS record. > So look to the next record and see which bit got cleared. > > Furthermore, we know that all bits set at PMI time are in-progress and > can therefore be cleared from the last record. > > This should allow us to iterate the entire thing backwards and provide > a unique event for each record. > > So take this series of 2 records and a PMI: > > C0 C1 C3 C4 > --- > O > | O > | | > | A < R1 > | O > A | < R2 > -+- < PMI > > O - overflow > A - assist > > So at PMI time we have C3 set in the overflow mask, our last even R2 > will have both C0 and C3 set, we clear C3 because we know it cannot have > been that. Then for R1 we have C0 and C1 set, but because R2 was C0 we > can clear C0 from R1, finding it was indeed C1. I don't think this method works for interrupt threshold > 1 case. When collision happens, the hardware only create one PEBS record. The status in next record has nothing to do with the collision record. > > So typically we'd have one event set and no problem, but in case there's > more we can reconstruct with such a backwards pass from a known good > state. > > But when in doubt, we should drop the record, its the safest choice. The problem is that, in some cases, each PEBS record has more than one events set, so we will drop all records. Regards Yan, Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the slave-dma tree
Hi Vinod,
After merging the slave-dma tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/dma/sun6i-dma.c: In function 'sun6i_dma_dump_chan_regs':
drivers/dma/sun6i-dma.c:203:2: error: implicit declaration of function
'__virt_to_phys' [-Werror=implicit-function-declaration]
phys_addr_t reg = __virt_to_phys((unsigned long)pchan->base);
^
Caused by commit 555859308723 ("dmaengine: sun6i: Add driver for the
Allwinner A31 DMA controller"). Presumably missing an include file.
I have used the slave-dma tree from next-20140725 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH 1/5] ARM: imx: Remove references to platform_bus in mxc code
On Fri, Jul 25, 2014 at 03:23:49PM +0100, Pawel Moll wrote: > The bus devices created to be parents for other peripherals > were using platform_bus as a parent, not being platform > devices themselves. Remove the references, making them > virtual devices instead. > > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Russell King > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Pawel Moll Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v4] sched: Rewrite per entity runnable load average tracking
Hi Vincent,
On Fri, Jul 18, 2014 at 11:43:00AM +0200, Vincent Guittot wrote:
> > @@ -2291,23 +2299,24 @@ static __always_inline int
> > __update_entity_runnable_avg(u64 now,
> > delta >>= 10;
> > if (!delta)
> > return 0;
> > - sa->last_runnable_update = now;
> > + sa->last_update_time = now;
> >
> > /* delta_w is the amount already accumulated against our next
> > period */
> > - delta_w = sa->runnable_avg_period % 1024;
> > + delta_w = sa->period_contrib;
> > if (delta + delta_w >= 1024) {
> > - /* period roll-over */
> > decayed = 1;
> >
> > + /* how much left for next period will start over, we don't
> > know yet */
> > + sa->period_contrib = 0;
> > +
> > /*
> > * Now that we know we're crossing a period boundary, figure
> > * out how much from delta we need to complete the current
> > * period and accrue it.
> > */
> > delta_w = 1024 - delta_w;
> > - if (runnable)
> > - sa->runnable_avg_sum += delta_w;
> > - sa->runnable_avg_period += delta_w;
> > + if (w)
> > + sa->load_sum += w * delta_w;
>
> Do you really need to have *w for computing the load_sum ? can't you
> only use it when computing the load_avg ?
>
> sa->load_avg = div_u64(sa->load_sum * w , LOAD_AVG_MAX)
>
For task, assuming its load.weight does not change much, yes, we can. But in
theory, task's
load.weight can change, and *w in load_sum can take into that change. For group
entity
and cfs_rq, its load.weight changes all the time, I don't know how to do it
without *w
for load_sum.
Sorry for my irresponsiveness for last week. I was on vacation and
unfortunately failed to
connect VPN from where I was.
Thanks,
Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: vt6655: coding style: Fixed commenting style
fix coding style: use C89 comments, not C99
Signed-off-by: Rahul Garg
---
drivers/staging/vt6655/tcrc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/tcrc.c b/drivers/staging/vt6655/tcrc.c
index ed6868a..ddc5efd 100644
--- a/drivers/staging/vt6655/tcrc.c
+++ b/drivers/staging/vt6655/tcrc.c
@@ -41,7 +41,7 @@
/*- Static Variables --*/
-// 32-bit CRC table
+/* 32-bit CRC table */
static const unsigned long s_adwCrc32Table[256] = {
0xL, 0x77073096L, 0xEE0E612CL, 0x990951BAL,
0x076DC419L, 0x706AF48FL, 0xE963A535L, 0x9E6495A3L,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 28/52] perf script: Allow callchains if any event samples them
Hi Arnaldo, On Fri, 25 Jul 2014 10:27:05 -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Jul 22, 2014 at 04:17:37PM +0300, Adrian Hunter escreveu: >> perf script was not displaying callchains if any selected >> event did not have PERF_SAMPLE_CALLCHAIN. Change this to >> disable callchains only if all selected events do not have >> PERF_SAMPLE_CALLCHAIN. > > I wonder if some other tool gets this wrong as well, report maybe? > > Perhaps we need to have this check in some perf_evlist method? > > Wonder how report/top, i.e. the hists browser will react with some > events having callchains while some don't, specially with this new > children stuff, Namhyung, can you please check that? The children/cumulate stuff is enabled if a combined sample type contains PERF_SAMPLE_CALLCHAIN and works only a sample actually contains callchain. So I guess if some have it and some don't, events don't have callchain just prints real entries/samples with same children overhead value. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] sched: deferred set priority (dprio)
Sergey Oboguev writes: > [This is a repost of the message from few day ago, with patch file > inline instead of being pointed by the URL.] Have you checked out the preemption control that was posted some time ago? It did essentially the same thing, but somewhat simpler than your patch. http://lkml.iu.edu/hypermail/linux/kernel/1403.0/00780.html Yes I agree with you that lock preemption is a serious issue that needs solving. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf tools: Ensure --symfs ends with '/'
Hi Arnaldo, On Fri, 25 Jul 2014 10:15:21 -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jul 25, 2014 at 10:31:47AM +0900, Namhyung Kim escreveu: >> Minchan reported that perf failed to load vmlinux if --symfs argument >> doesn't end with '/' character. So make sure that the symfs always >> ends with the '/'. > > I don't think this is the right way of doing this, users of > symbol_conf.symfs should instead make sure that they do what they expect > to, i.e. if they want it to be a base directory, make sure that a path > separator is added between it and the relative path following it, if > not, do as they please. Hmm.. what's the usecase of non-directory symfs? I guess realpath(3) already nullifies such case and defaults to no symfs.. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] perf report: Honor column width setting
On Fri, 25 Jul 2014 13:13:02 +0200, Jiri Olsa wrote:
> On Fri, Jul 25, 2014 at 10:18:55AM +0900, Namhyung Kim wrote:
>> Set column width and do not change it if user gives -w/--column-widths
>> option. It'll truncate longer symbols than the width if exists.
>>
>> Signed-off-by: Namhyung Kim
>> ---
>
> SNIP
>
>>
>> __HPP_COLOR_PERCENT_FN(overhead, period)
>> @@ -797,8 +798,11 @@ static int hist_browser__show_entry(struct hist_browser
>> *browser,
>> if (fmt->color) {
>> width -= fmt->color(fmt, , entry);
>> } else {
>> -width -= fmt->entry(fmt, , entry);
>> +int ret = fmt->entry(fmt, , entry);
>> +s[ret] = '\0';
>> slsmg_printf("%s", s);
>
> from quick check it seems like all entry callback functions
> use some sort of snprint which should already handle the string
> length properly.. if not, we should fix that instead, no?
It was 'symbol' sort entry (_hist_entry__sym_snprintf) which has several
snprint calls in it. So I changed here rather than adding complexity
the print function. I can change it if you want. ;)
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] ARM: EXYNOS: Fix Exynos5410 boot
Andreas Färber wrote: > > Am 27.07.2014 14:22, schrieb Andreas Färber: > > Hello, > > > > This mini-series unbreaks booting on 5410 based ODROID-XU. > > > > Since I do not have access to a TRM, the address is a guess based on > > 5250 and 5410. Such a node was not present in the 3.14 downstream tree. > > s/5410/5420/ > OK. > > > > Regards, > > Andreas > > > > Andreas Färber (3): > > Documentation: devicetree: Document exynos5410 PMU > > ARM: dts: exynos: Add PMU to Exynos5410 > > ARM: EXYNOS: Add support for Exynos5410 PMU > > > > Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + > > arch/arm/boot/dts/exynos5410.dtsi | 5 + > > arch/arm/mach-exynos/exynos.c | 1 + > > 3 files changed, 7 insertions(+) > Andreas, thanks. I'll apply this whole series. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] perf tools: Add name field into perf_hpp_fmt
Hi Jiri,
On Fri, 25 Jul 2014 13:12:30 +0200, Jiri Olsa wrote:
> On Fri, Jul 25, 2014 at 10:18:57AM +0900, Namhyung Kim wrote:
>
> SNIP
>
>> }
>>
>> -#define __HPP_WIDTH_FN(_type, _str) \
>> +#define __HPP_WIDTH_FN(_type)
>> \
>> static int hpp__width_##_type(struct perf_hpp_fmt *fmt,
>> \
>>struct perf_hpp *hpp __maybe_unused, \
>>struct perf_evsel *evsel) \
>> @@ -219,19 +219,19 @@ static int hpp__width_##_type(struct perf_hpp_fmt
>> *fmt,\
>> if (symbol_conf.event_group)\
>> len = max(len, evsel->nr_members * fmt->len); \
>> \
>> -if (len < (int)strlen(_str))\
>> -len = strlen(_str); \
>> +if (len < (int)strlen(fmt->name)) \
>> +len = strlen(fmt->name);\
>
> hum, so with the '_str' string argument missing we dont need this
> function to be generated by macro, right? could be one single function
> called hpp__width_entry or something like that
You're right. Will change both!
Thanks,
Namhyung
>
>> \
>> return len; \
>> }
>>
>> -#define __HPP_HEADER_FN(_type, _str)
>> \
>> +#define __HPP_HEADER_FN(_type)
>> \
>> static int hpp__header_##_type(struct perf_hpp_fmt *fmt,\
>> struct perf_hpp *hpp,\
>> struct perf_evsel *evsel)\
>> { \
>> int len = hpp__width_##_type(fmt, hpp, evsel); \
>> -return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
>> +return scnprintf(hpp->buf, hpp->size, "%*s", len, fmt->name); \
>> }
>>
>
> same here ^^^ for hpp__header_##_type
>
>
> jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Bug 24912 - I think this one fell through the cracks a bit
Hello, I think that bug 2491 at https://bugzilla.kernel.org/show_bug.cgi?id=24912 sort of fell through the cracks and I'm not sure as many people are aware of it as there could be. This bug is that one can't mount bind mounts readonly but can only remount them readonly which is insufficient for recursive bind mounts and certain kinds of sandboxing. Also the bind mount fails silenty without giving an error which is never a good idea. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf tools: Default to python version 2
Hi Thomas, On Fri, 25 Jul 2014 13:43:24 +0200, Thomas Ilsche wrote: > Hi Namhyung, > > apologies for mixing up your first name earlier. It's okay, nevermind. :) > On 2014-07-25 12:24, Namhyung Kim wrote: >> On Fri, 25 Jul 2014 11:28:55 +0200, Thomas Ilsche wrote: >>> ifndef NO_LIBPYTHON >>> - override PYTHON := \ >>> -$(call get-executable-or-default,PYTHON,python) >>> + PYTHON2 := $(call get-executable-or-default,PYTHON,python2) >> >> But wouldn't it set PYTHON2 to python2 even if the system doesn't have >> python2 actually? >> >> >>> + override PYTHON := $(if $(PYTHON2),$(PYTHON2),$(call >>> get-executable,python)) >> >> And then it'll set PYTHON to python2, no? >> > > No, get-executable-or-default only returns anything if it is an actual > executable > (asserted by a 'command -v' and 'test -f $ -a -x $'). At least this is how I > understand > the Makefile code. I also tested it with a Python 2.6.9 (no python2 in path) > and it worked > (after fixing some totally unrelated issues in python headers). It will > however complain > that "The path 'python2' is not executable." before using python. Yeah, that's annoying. > >> >>>override PYTHON_CONFIG := \ >>> $(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON)-config) >> >> >> I'm thinking about something like below.. but sadly it doesn't work for >> me.. hmm. > > Actually this appears to work for me (with 2.6.9 & 2.7.6) and I find this > solution more > elegant. Thanks for testing. It was my fault on setting symlink to a non-existing file for testing. It now works well for me too. Can I add your Tested-by then? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] rcu: Use rcu_gp_kthread_wake() to wake up grace period kthreads
- Original Message -
> From: "Pranith Kumar"
> To: "Mathieu Desnoyers"
> Cc: "Paul E. McKenney" , "Josh Triplett"
> , "Steven Rostedt"
> , "Lai Jiangshan" , "open
> list:READ-COPY UPDATE..."
>
> Sent: Sunday, July 27, 2014 7:58:40 PM
> Subject: Re: [PATCH 1/1] rcu: Use rcu_gp_kthread_wake() to wake up grace
> period kthreads
>
> On Sun, Jul 27, 2014 at 7:49 PM, Mathieu Desnoyers
> wrote:
> > - Original Message -
> >> From: "Pranith Kumar"
> >> To: "Paul E. McKenney" , "Josh Triplett"
> >> , "Steven Rostedt"
> >> , "Mathieu Desnoyers"
> >> , "Lai Jiangshan" ,
> >> "open list:READ-COPY UPDATE..."
> >> Sent: Sunday, July 27, 2014 7:37:29 PM
> >> Subject: [PATCH 1/1] rcu: Use rcu_gp_kthread_wake() to wake up grace
> >> period kthreads
> >>
> >> The rcu_gp_kthread_wake() function checks for three conditions before
> >> waking
> >> up
> >> grace period kthreads:
> >>
> >> * Is the thread we are trying to wake up the current thread?
> >> * Are the gp_flags zero? (all threads wait on non-zero gp_flags
> >> condition)
> >> * Is there no thread created for this flavour, hence nothing to wake up?
> >>
> >> If any one of these condition is true, we do not call wake_up().
> >>
> >> It was found that there are quite a few avoidable wake ups both during
> >> idle
> >> time and under stress induced by rcutorture.
> >>
> >> Idle:
> >>
> >> Total:66000, unnecessary:66000, case1:61827, case2:66000, case3:0
> >> Total:68000, unnecessary:68000, case1:63696, case2:68000, case3:0
> >>
> >> rcutorture:
> >>
> >> Total:254000, unnecessary:254000, case1:199913, case2:254000, case3:0
> >> Total:256000, unnecessary:256000, case1:201784, case2:256000, case3:0
> >>
> >> Here case{1-3} are the cases listed above. We can avoid these wake ups by
> >> using
> >> rcu_gp_kthread_wake() to conditionally wake up the grace period kthreads.
> >>
> >> Hence this commit tries to avoid calling wake_up() whenever we can by
> >> using
> >> rcu_gp_kthread_wake() function.
> >>
> >> Signed-off-by: Pranith Kumar
> >> ---
> >> kernel/rcu/tree.c | 10 --
> >> 1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> >> index b63517c..36911ee 100644
> >> --- a/kernel/rcu/tree.c
> >> +++ b/kernel/rcu/tree.c
> >> @@ -1938,7 +1938,10 @@ static void rcu_report_qs_rsp(struct rcu_state
> >> *rsp,
> >> unsigned long flags)
> >> {
> >> WARN_ON_ONCE(!rcu_gp_in_progress(rsp));
> >> raw_spin_unlock_irqrestore(_get_root(rsp)->lock, flags);
> >> - wake_up(>gp_wq); /* Memory barrier implied by wake_up() path.
> >> */
> >> + /* ->gp_flags is properly protected by locks, so a memory barrier
> >> + * is not necessary here
> >
> > Two point:
> >
> > 1- The format of this comment is odd, and should be:
> >
> > /*
> > * Text...
> > */
>
> OK, I will update it according to this format.
>
> >
> > 2- Since when can a memory barrier be replaced by a lock ? More explanation
> >appears to be needed on what this barrier matches exactly.
>
> On re-reading I realize that this comment is very vague and introduces
> more doubts than it clears.
>
> The context here is that in rcu_gp_kthread_wake() we are accessing
> ->gp_flags to determine whether we need to wake up the gp kthreads. We
> don't need a barrier here since we are accessing it using
> ACCESS_ONCE() and all other accesses are properly protected by using
> ACCESS_ONCE() and taking the root rcu_node lock.
>
> So how about this:
>
> /*
> * ->gp_flags is being accessed using ACCESS_ONCE() because of
> * which a memory barrier is not required here.
> */
>
A memory barrier is typically not there to interact with a single
variable and a single memory access. I'm concerned that this memory
barrier might be ordering other things besides gp_flags.
Thanks,
Mathieu
> >
> >> + */
> >> + rcu_gp_kthread_wake(rsp);
> >> }
> >>
> >> /*
> >> @@ -2516,7 +2519,10 @@ static void force_quiescent_state(struct rcu_state
> >> *rsp)
> >> ACCESS_ONCE(rsp->gp_flags) =
> >> ACCESS_ONCE(rsp->gp_flags) | RCU_GP_FLAG_FQS;
> >> raw_spin_unlock_irqrestore(_old->lock, flags);
> >> - wake_up(>gp_wq); /* Memory barrier implied by wake_up() path.
> >> */
> >> + /* ->gp_flags is properly protected by locks, so a memory barrier
> >> + * is not necessary here
> >> + */
> >> + rcu_gp_kthread_wake(rsp);
> >> }
> >>
> >> /*
> >> --
> >> 1.9.1
> >>
> >>
> >
> > --
> > Mathieu Desnoyers
> > EfficiOS Inc.
> > http://www.efficios.com
>
>
>
> --
> Pranith
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] rcu: Use rcu_gp_kthread_wake() to wake up grace period kthreads
On Sun, Jul 27, 2014 at 7:49 PM, Mathieu Desnoyers
wrote:
> - Original Message -
>> From: "Pranith Kumar"
>> To: "Paul E. McKenney" , "Josh Triplett"
>> , "Steven Rostedt"
>> , "Mathieu Desnoyers" ,
>> "Lai Jiangshan" ,
>> "open list:READ-COPY UPDATE..."
>> Sent: Sunday, July 27, 2014 7:37:29 PM
>> Subject: [PATCH 1/1] rcu: Use rcu_gp_kthread_wake() to wake up grace period
>> kthreads
>>
>> The rcu_gp_kthread_wake() function checks for three conditions before waking
>> up
>> grace period kthreads:
>>
>> * Is the thread we are trying to wake up the current thread?
>> * Are the gp_flags zero? (all threads wait on non-zero gp_flags condition)
>> * Is there no thread created for this flavour, hence nothing to wake up?
>>
>> If any one of these condition is true, we do not call wake_up().
>>
>> It was found that there are quite a few avoidable wake ups both during idle
>> time and under stress induced by rcutorture.
>>
>> Idle:
>>
>> Total:66000, unnecessary:66000, case1:61827, case2:66000, case3:0
>> Total:68000, unnecessary:68000, case1:63696, case2:68000, case3:0
>>
>> rcutorture:
>>
>> Total:254000, unnecessary:254000, case1:199913, case2:254000, case3:0
>> Total:256000, unnecessary:256000, case1:201784, case2:256000, case3:0
>>
>> Here case{1-3} are the cases listed above. We can avoid these wake ups by
>> using
>> rcu_gp_kthread_wake() to conditionally wake up the grace period kthreads.
>>
>> Hence this commit tries to avoid calling wake_up() whenever we can by using
>> rcu_gp_kthread_wake() function.
>>
>> Signed-off-by: Pranith Kumar
>> ---
>> kernel/rcu/tree.c | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
>> index b63517c..36911ee 100644
>> --- a/kernel/rcu/tree.c
>> +++ b/kernel/rcu/tree.c
>> @@ -1938,7 +1938,10 @@ static void rcu_report_qs_rsp(struct rcu_state *rsp,
>> unsigned long flags)
>> {
>> WARN_ON_ONCE(!rcu_gp_in_progress(rsp));
>> raw_spin_unlock_irqrestore(_get_root(rsp)->lock, flags);
>> - wake_up(>gp_wq); /* Memory barrier implied by wake_up() path. */
>> + /* ->gp_flags is properly protected by locks, so a memory barrier
>> + * is not necessary here
>
> Two point:
>
> 1- The format of this comment is odd, and should be:
>
> /*
> * Text...
> */
OK, I will update it according to this format.
>
> 2- Since when can a memory barrier be replaced by a lock ? More explanation
>appears to be needed on what this barrier matches exactly.
On re-reading I realize that this comment is very vague and introduces
more doubts than it clears.
The context here is that in rcu_gp_kthread_wake() we are accessing
->gp_flags to determine whether we need to wake up the gp kthreads. We
don't need a barrier here since we are accessing it using
ACCESS_ONCE() and all other accesses are properly protected by using
ACCESS_ONCE() and taking the root rcu_node lock.
So how about this:
/*
* ->gp_flags is being accessed using ACCESS_ONCE() because of
* which a memory barrier is not required here.
*/
>
>> + */
>> + rcu_gp_kthread_wake(rsp);
>> }
>>
>> /*
>> @@ -2516,7 +2519,10 @@ static void force_quiescent_state(struct rcu_state
>> *rsp)
>> ACCESS_ONCE(rsp->gp_flags) =
>> ACCESS_ONCE(rsp->gp_flags) | RCU_GP_FLAG_FQS;
>> raw_spin_unlock_irqrestore(_old->lock, flags);
>> - wake_up(>gp_wq); /* Memory barrier implied by wake_up() path. */
>> + /* ->gp_flags is properly protected by locks, so a memory barrier
>> + * is not necessary here
>> + */
>> + rcu_gp_kthread_wake(rsp);
>> }
>>
>> /*
>> --
>> 1.9.1
>>
>>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: make update_sd_pick_busiest return true on a busier sd
On Fri, 2014-07-25 at 17:27 +0200, Peter Zijlstra wrote: > On Tue, Jul 22, 2014 at 02:45:59PM -0400, Rik van Riel wrote: > > Currently update_sd_pick_busiest only returns true when an sd > > is overloaded, or for SD_ASYM_PACKING when a domain is busier > > than average and a higher numbered domain than the target. > > > > This breaks load balancing between domains that are not overloaded, > > in the !SD_ASYM_PACKING case. This patch makes update_sd_pick_busiest > > return true when the busiest sd yet is encountered. > > > > On a 4 node system, this seems to result in the load balancer finally > > putting 1 thread of a 4 thread test run of "perf bench numa mem" on > > each node, where before the load was generally not spread across all > > nodes. > > So for !ASYM the code is effectively: > > return sgs->avg_load > sds->busiest_stat.avg_load; > > I'd like to at least add a clause that makes overloaded groups > prioritized over !overloaded groups. > > Also, like we found earlier, calculate_imbalance() relies on the > sum_nr_running > group_capacity_factor thing, which you've just > 'wrecked', so we'd need an update to that part too. > > > Behaviour for SD_ASYM_PACKING does not seem to match the comment, > > in that groups with below average load average are ignored, but I > > have no hardware to test that so I have left the behaviour of that > > code unchanged. > > Mikey, does that stuff work as expected? Sorry for the slow response. v1 and v2 both pass testing on POWER7. So FWIW... Acked-By: Michael Neuling Mikey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: General flags to turn things off (getrandom, pid lookup, etc)
Andy Lutomirski writes: > On Jul 27, 2014 5:06 PM, "Theodore Ts'o" wrote: >> >> On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote: >> > >> > There is recent interest in having a way to turn generally-available >> > kernel features off. Maybe we should add a good one so we can stop >> > bikeshedding and avoid proliferating dumb interfaces. >> >> I believe the seccomp infrastructure (which is already upstream) >> should be able to do most of what you want, at least with respect to >> features which are exposed via system calls (which was most of your >> list). > > Seccomp can't really restrict lookups of non-self pids. In fact, this > feature idea started out as a response to a patch adding a kind of > nasty seccomp feature to make it sort of possible. > > I agree that that seccomp can turn off GRND_RANDOM, but how is it > supposed to do it in such a way that the filtered software will fall > back to something sensible? -ENOSYS? -EPERM? Something else? > > I think that -ENOSYS is clearly wrong, but standardizing this would be > nice. Admittedly, adding something fancy like this for GRND_RANDOM > may not be appropriate. Andy you seem to be arguing here for two system calls. get_urandom() and get_random(). Where get_urandom only blocks if there is not enough starting entropy, and get_random(GRND_RANDOM) blocks if there is currently not enough entropy. That would allow -ENOSYS to be the right return value and it would simply things for everyone. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: of: Make OF_DYNAMIC user selectable
Stephen Rothwell writes: > Hi Grant, > > I noticed the subject commit in the devicetree tree in linux-next today. > The commit message gives us no idea why we would want to make this > change. We already have lots of user selectable CONFIG_ options ... do > we really need this one as well? You say that like user-selectable options are somehow evil. The kernel is not Gnome. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] rcu: Use rcu_gp_kthread_wake() to wake up grace period kthreads
- Original Message -
> From: "Pranith Kumar"
> To: "Paul E. McKenney" , "Josh Triplett"
> , "Steven Rostedt"
> , "Mathieu Desnoyers" ,
> "Lai Jiangshan" ,
> "open list:READ-COPY UPDATE..."
> Sent: Sunday, July 27, 2014 7:37:29 PM
> Subject: [PATCH 1/1] rcu: Use rcu_gp_kthread_wake() to wake up grace period
> kthreads
>
> The rcu_gp_kthread_wake() function checks for three conditions before waking
> up
> grace period kthreads:
>
> * Is the thread we are trying to wake up the current thread?
> * Are the gp_flags zero? (all threads wait on non-zero gp_flags condition)
> * Is there no thread created for this flavour, hence nothing to wake up?
>
> If any one of these condition is true, we do not call wake_up().
>
> It was found that there are quite a few avoidable wake ups both during idle
> time and under stress induced by rcutorture.
>
> Idle:
>
> Total:66000, unnecessary:66000, case1:61827, case2:66000, case3:0
> Total:68000, unnecessary:68000, case1:63696, case2:68000, case3:0
>
> rcutorture:
>
> Total:254000, unnecessary:254000, case1:199913, case2:254000, case3:0
> Total:256000, unnecessary:256000, case1:201784, case2:256000, case3:0
>
> Here case{1-3} are the cases listed above. We can avoid these wake ups by
> using
> rcu_gp_kthread_wake() to conditionally wake up the grace period kthreads.
>
> Hence this commit tries to avoid calling wake_up() whenever we can by using
> rcu_gp_kthread_wake() function.
>
> Signed-off-by: Pranith Kumar
> ---
> kernel/rcu/tree.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index b63517c..36911ee 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1938,7 +1938,10 @@ static void rcu_report_qs_rsp(struct rcu_state *rsp,
> unsigned long flags)
> {
> WARN_ON_ONCE(!rcu_gp_in_progress(rsp));
> raw_spin_unlock_irqrestore(_get_root(rsp)->lock, flags);
> - wake_up(>gp_wq); /* Memory barrier implied by wake_up() path. */
> + /* ->gp_flags is properly protected by locks, so a memory barrier
> + * is not necessary here
Two point:
1- The format of this comment is odd, and should be:
/*
* Text...
*/
2- Since when can a memory barrier be replaced by a lock ? More explanation
appears to be needed on what this barrier matches exactly.
Thanks,
Mathieu
> + */
> + rcu_gp_kthread_wake(rsp);
> }
>
> /*
> @@ -2516,7 +2519,10 @@ static void force_quiescent_state(struct rcu_state
> *rsp)
> ACCESS_ONCE(rsp->gp_flags) =
> ACCESS_ONCE(rsp->gp_flags) | RCU_GP_FLAG_FQS;
> raw_spin_unlock_irqrestore(_old->lock, flags);
> - wake_up(>gp_wq); /* Memory barrier implied by wake_up() path. */
> + /* ->gp_flags is properly protected by locks, so a memory barrier
> + * is not necessary here
> + */
> + rcu_gp_kthread_wake(rsp);
> }
>
> /*
> --
> 1.9.1
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] rcu: Use rcu_gp_kthread_wake() to wake up grace period kthreads
The rcu_gp_kthread_wake() function checks for three conditions before waking up
grace period kthreads:
* Is the thread we are trying to wake up the current thread?
* Are the gp_flags zero? (all threads wait on non-zero gp_flags condition)
* Is there no thread created for this flavour, hence nothing to wake up?
If any one of these condition is true, we do not call wake_up().
It was found that there are quite a few avoidable wake ups both during idle
time and under stress induced by rcutorture.
Idle:
Total:66000, unnecessary:66000, case1:61827, case2:66000, case3:0
Total:68000, unnecessary:68000, case1:63696, case2:68000, case3:0
rcutorture:
Total:254000, unnecessary:254000, case1:199913, case2:254000, case3:0
Total:256000, unnecessary:256000, case1:201784, case2:256000, case3:0
Here case{1-3} are the cases listed above. We can avoid these wake ups by using
rcu_gp_kthread_wake() to conditionally wake up the grace period kthreads.
Hence this commit tries to avoid calling wake_up() whenever we can by using
rcu_gp_kthread_wake() function.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index b63517c..36911ee 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1938,7 +1938,10 @@ static void rcu_report_qs_rsp(struct rcu_state *rsp,
unsigned long flags)
{
WARN_ON_ONCE(!rcu_gp_in_progress(rsp));
raw_spin_unlock_irqrestore(_get_root(rsp)->lock, flags);
- wake_up(>gp_wq); /* Memory barrier implied by wake_up() path. */
+ /* ->gp_flags is properly protected by locks, so a memory barrier
+* is not necessary here
+*/
+ rcu_gp_kthread_wake(rsp);
}
/*
@@ -2516,7 +2519,10 @@ static void force_quiescent_state(struct rcu_state *rsp)
ACCESS_ONCE(rsp->gp_flags) =
ACCESS_ONCE(rsp->gp_flags) | RCU_GP_FLAG_FQS;
raw_spin_unlock_irqrestore(_old->lock, flags);
- wake_up(>gp_wq); /* Memory barrier implied by wake_up() path. */
+ /* ->gp_flags is properly protected by locks, so a memory barrier
+* is not necessary here
+*/
+ rcu_gp_kthread_wake(rsp);
}
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: of: Make OF_DYNAMIC user selectable
Hi Grant, I noticed the subject commit in the devicetree tree in linux-next today. The commit message gives us no idea why we would want to make this change. We already have lots of user selectable CONFIG_ options ... do we really need this one as well? -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH 2/2] V3 ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Le 27 juil. 2014 à 22:32, Thomas Petazzoni
a écrit :
> Dear Benoit Masson,
>
Dear Thomas,
> On Sat, 26 Jul 2014 16:48:10 -0700, Benoit Masson wrote:
>
>> +gpio-keys {
>> +compatible = "gpio-keys";
>> +pinctrl-0 = <_button_pin _button_pin
>> +_button_pin _button_pin>;
>> +pinctrl-names = "default";
>> +
>> +power-button {
>> +label = "Power Button";
>> +linux,code = ;
>> +gpios = < 12 GPIO_ACTIVE_HIGH>;
>> +};
>> +
>> +reset-button {
>> +label = "Reset Button";
>> +linux,code = ;
>> +gpios = < 13 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +select-button {
>> +label = "Select Button";
>> +linux,code = ;
>> +gpios = < 9 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +scroll-button {
>> +label = "Scroll Button";
>> +linux,code = ;
>> +gpios = < 10 GPIO_ACTIVE_LOW>;
>
> So you're using the GPIO_ACTIVE_ defines here.
>
>> +};
>> +};
>> +
>> +spi3 {
>> +compatible = "spi-gpio";
>> +status = "okay";
>> +gpio-sck = < 25 0>;
>> +gpio-mosi = < 15 0>; /*gpio 47*/
>> +cs-gpios = < 27 0 >;
>
> But not here. Any reason?
Indeed I think Jason made this comment already and I seem to have missed ->
Corrected in V4
>
> Also, nitpick: unneeded space in < 27 0 > (i.e the space right
> before the closing >).
>
-> Corrected in V4
>> +num-chipselects = <1>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +gpio2: gpio2@0 {
>> +compatible = "fairchild,74hc595";
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +reg = <0>;
>> +registers-number = <2>;
>> +spi-max-frequency = <10>;
>> +};
>
> I'm not sure "gpio2" is a good name, as we might think of it as being
> the third GPIO controller internal to the SoC.
>
Renamed to gpio_spi, tested ok -> Corrected in V4
> Thanks,
>
You're welcome, patch issued as V4 just now.
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] V4 ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb,
USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU.
http://shop.lenovo.com/us/en/servers/network-storage/lenovoemc/ix4-300d/
Signed-off-by: Benoit Masson
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 285
2 files changed, 287 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index adb5ed9..4429495 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -437,8 +437,9 @@ dtb-$(CONFIG_MACH_ARMADA_XP) += \
armada-xp-axpwifiap.dtb \
armada-xp-db.dtb \
armada-xp-gp.dtb \
- armada-xp-netgear-rn2120.dtb \
+ armada-xp-lenovo-ix4-300d.dtb \
armada-xp-matrix.dtb \
+ armada-xp-netgear-rn2120.dtb \
armada-xp-openblocks-ax3-4.dtb
dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
dove-cubox.dtb \
diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
new file mode 100644
index 000..6d5782b
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -0,0 +1,285 @@
+/*
+ * Device Tree file for Lenovo Iomega ix4-300d
+ *
+ * Copyright (C) 2014, Benoit Masson
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "armada-xp-mv78230.dtsi"
+
+/ {
+ model = "Lenovo Iomega ix4-300d";
+ compatible = "lenovo,ix4-300d", "marvell,armadaxp-mv78230",
+"marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ stdout-path = "/soc/internal-regs/serial@12000";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x 0 0x2000>; /* 512MB */
+ };
+
+ soc {
+ ranges = ;
+
+ pcie-controller {
+ status = "okay";
+
+ /* Quad port sata: Marvell 88SX7042 */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ /* USB 3.0 xHCI controller: NEC D720200F1 */
+ pcie@5,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+ };
+
+ internal-regs {
+ pinctrl {
+ poweroff_pin: poweroff-pin {
+ marvell,pins = "mpp24";
+ marvell,function = "gpio";
+ };
+
+ power_button_pin: power-button-pin {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+
+ reset_button_pin: reset-button-pin {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+ select_button_pin: select-button-pin {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+
+ scroll_button_pin: scroll-button-pin {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+
+ hdd_led_pin: hdd-led-pin {
+ marvell,pins = "mpp26";
+ marvell,function = "gpio";
+ };
+ };
+
+ serial@12000 {
+ status = "okay";
+ };
+
+ mdio {
+ phy0: ethernet-phy@0 { /* Marvell 88E1318 */
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy@1 { /* Marvell 88E1318 */
+ reg = <1>;
+ };
+ };
+
+ ethernet@7 {
+ status = "okay";
+ phy = <>;
+ phy-mode =
Re: [PATCH v5 00/11] Add DRM for stih4xx platforms
On 16 July 2014 04:33, Rob Clark wrote: > On Tue, Jul 15, 2014 at 5:41 AM, Benjamin Gaignard > wrote: >> Hi all, >> >> Does version 6 fit to all your expectations ? >> If yes will you consider to merge it into drm-next ? >> If no, please tell me what need to be fixed. > > > I had another pass over the driver, and didn't find anything to > complain about, so for the series: > > Reviewed-by: Rob Clark Can I see a git tree of this with Rob's R-B on it? based off drm-next if possible, I'd like to do a quick pre-merge review of it, but I usually don't find anything too major. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Git v2.1.0-rc0
An early preview release Git v2.1.0-rc0 is now available for testing at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.1.0-rc0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.1 Release Notes (draft) == Backward compatibility notes * The default value we give to the environment variable LESS has been changed from "FRSX" to "FRX", losing "S" (chop long lines instead of wrapping). Existing users who prefer not to see line-wrapped output may want to set $ git config core.pager "less -S" to restore the traditional behaviour. It is expected that people find output from the most subcommands easier to read with the new default, except for "blame" which tends to produce really long lines. To override the new default only for "git blame", you can do this: $ git config pager.blame "less -S" * A few disused directories in contrib/ have been retired. Updates since v2.0 -- UI, Workflows & Features * Since the very beginning of Git, we gave the LESS environment a default value "FRSX" when we spawn "less" as the pager. "S" (chop long lines instead of wrapping) has been removed from this default set of options, because it is more or less a personal taste thing, as opposed to others that have good justifications (i.e. "R" is very much justified because many kinds of output we produce are colored and "FX" is justified because output we produce is often shorter than a page). * The logic and data used to compute the display width needed for UTF-8 strings have been updated to match Unicode 7.0 better. * HTTP-based transports learned to propagate the error messages from the webserver better to the client coming over the HTTP transport. * The completion script for bash (in contrib/) has been updated to handle aliases that define complex sequence of commands better. * The "core.preloadindex" configuration variable is by default enabled, allowing modern platforms to take advantage of the multiple cores they have. * "git clone" applies the "if cloning from a local disk, physically copy repository using hardlinks, unless otherwise told not to with --no-local" optimization when url.*.insteadOf mechanism rewrites a "git clone $URL" that refers to a repository over the network to a clone from a local disk. * "git commit --date=" option learned to read from more timestamp formats, including "--date=now". * The `core.commentChar` configuration variable is used to specify a custom comment character other than the default "#" to be used in the commit log editor. This can be set to `auto` to attempt to choose a different character that does not conflict with what already starts a line in the message being edited for cases like "git commit --amend". * "git format-patch" learned --signature-file= to take the mail signature from. * "git grep" learned grep.fullname configuration variable to force "--full-name" to be default. This may cause regressions on scripted users that do not expect this new behaviour. * "git imap-send" learned to ask the credential helper for auth material. * "git log" and friends now understand the value "auto" set to the "log.decorate" configuration variable to enable the "--decorate" option automatically when the output is sent to tty. * "git merge" without argument, even when there is an upstream defined for the current branch, refused to run until merge.defaultToUpstream is set to true. Flip the default of that configuration variable to true. * "git mergetool" learned to drive the vimdiff3 backend. * mergetool.prompt used to default to 'true', always asking "do you really want to run the tool on this path?". Among the two purposes this prompt serves, ignore the use case to confirm that the user wants to view particular path with the named tool, and redefine the meaning of the prompt only to confirm the choice of the tool made by the autodetection (for those who configured the tool explicitly, the prompt shown for the latter purpose is simply annoying). Strictly speaking, this is a backward incompatible change and the users need to explicitly set the variable to 'true' if they want to resurrect the now-ignored use case. * "git replace" learned the "--edit" subcommand to create a replacement by editing an existing object. * "git replace" learned a "--graft" option to rewrite parents of a commit. * "git
Re: [PATCH] Documentation: laptops: freefall.c: Cleaning up missing null-terminate in conjunction with strncpy
On 07/27/14 07:40, Rickard Strandqvist wrote: > Added a guaranteed null-terminate after call to strncpy. > > Signed-off-by: Rickard Strandqvist > --- > Documentation/laptops/freefall.c |6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/laptops/freefall.c > b/Documentation/laptops/freefall.c > index aab2ff0..113d004 100644 > --- a/Documentation/laptops/freefall.c > +++ b/Documentation/laptops/freefall.c > @@ -33,8 +33,10 @@ static int set_unload_heads_path(char *device) > > if (strlen(device) <= 5 || strncmp(device, "/dev/", 5) != 0) > return -EINVAL; > - strncpy(devname, device + 5, sizeof(devname) - 1); > - strncpy(device_path, device, sizeof(device_path) - 1); Maybe I am overlooking something here, but what was wrong with the - 1 (2 times) above? and then just add the 2 lines below that set the last byte to '\0'? > + strncpy(devname, device + 5, sizeof(devname)); > + devname[sizeof(devname) - 1] = '\0'; > + strncpy(device_path, device, sizeof(device_path)); > + device_path[sizeof(device_path) - 1] = '\0'; > > snprintf(unload_heads_path, sizeof(unload_heads_path) - 1, > "/sys/block/%s/device/unload_heads", devname); > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2] PM / sleep: Fix racing timers
On Friday, July 25, 2014 02:06:48 PM Soren Brinkmann wrote:
> On platforms that do not power off during suspend, successfully entering
> suspend races with timers.
>
> The race happening in a couple of location is:
>
> 1. disable IRQs (e.g. arch_suspend_disable_irqs())
> ...
> 2. syscore_suspend()
> -> timekeeping_suspend()
>-> clockevents_notify(SUSPEND)
> -> tick_suspend() (timers are turned off here)
> ...
> 3. wfi (wait for wake-IRQ here)
>
> Between steps 1 and 2 the timers can still generate interrupts that are
> not handled and stay pending until step 3. That pending IRQ causes an
> immediate - spurious - wake.
>
> The solution is to move the clockevents suspend/resume notification
> out of the syscore_suspend step and explictly call them at the appropriate
> time in the suspend/hibernation paths. I.e. timers are suspend _before_
> IRQs get disabled. And accordingly in the resume path.
>
> Signed-off-by: Soren Brinkmann
> ---
> Hi,
>
> This is my second shot at this. I followed John's suggestion to keep the
> timekeeping suspend where it is and just move the shutdown of the clockevent
> devices around.
John, what do you think?
> kernel/power/hibernate.c | 9 +
> kernel/power/suspend.c| 5 +
> kernel/time/timekeeping.c | 1 -
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index fcc2611d3f14..ab9f807e2ccb 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -285,6 +285,8 @@ static int create_image(int platform_mode)
> if (error || hibernation_test(TEST_CPUS))
> goto Enable_cpus;
>
> + clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
> +
> local_irq_disable();
>
> error = syscore_suspend();
> @@ -316,6 +318,7 @@ static int create_image(int platform_mode)
> syscore_resume();
>
> Enable_irqs:
> + clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
> local_irq_enable();
>
> Enable_cpus:
> @@ -440,6 +443,8 @@ static int resume_target_kernel(bool platform_mode)
> if (error)
> goto Enable_cpus;
>
> + clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
> +
> local_irq_disable();
>
> error = syscore_suspend();
> @@ -474,6 +479,7 @@ static int resume_target_kernel(bool platform_mode)
> syscore_resume();
>
> Enable_irqs:
> + clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
> local_irq_enable();
>
> Enable_cpus:
> @@ -555,6 +561,8 @@ int hibernation_platform_enter(void)
> if (error)
> goto Platform_finish;
>
> + clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
> +
> local_irq_disable();
> syscore_suspend();
> if (pm_wakeup_pending()) {
> @@ -568,6 +576,7 @@ int hibernation_platform_enter(void)
>
> Power_up:
> syscore_resume();
> + clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
> local_irq_enable();
> enable_nonboot_cpus();
>
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index ed35a4790afe..ca6c56a87ea3 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -253,6 +254,8 @@ static int suspend_enter(suspend_state_t state, bool
> *wakeup)
> if (error || suspend_test(TEST_CPUS))
> goto Enable_cpus;
>
> + clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
> +
> arch_suspend_disable_irqs();
> BUG_ON(!irqs_disabled());
>
> @@ -270,6 +273,8 @@ static int suspend_enter(suspend_state_t state, bool
> *wakeup)
> syscore_resume();
> }
>
> + clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL);
> +
> arch_suspend_enable_irqs();
> BUG_ON(irqs_disabled());
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 32d8d6aaedb8..d2f21cbe2bfd 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1032,7 +1032,6 @@ static int timekeeping_suspend(void)
> write_seqcount_end(_seq);
> raw_spin_unlock_irqrestore(_lock, flags);
>
> - clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL);
> clocksource_suspend();
> clockevents_suspend();
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] PM / sleep: Rename symbols, functions and variables related to sleep
From: Rafael J. Wysocki
The names of several symbols, data types, functions and variables
related to system sleep states are confusing and don't reflect the
real behavior of those states correctly.
First of all, there generally are two sleep states that require
platform support and one sleep state that is platform-independent.
The first two of them are currently known as MEM and STANDBY,
although these names really only match what the states do on full
hardware ACPI compliant systems. MEM in particular is supposed
to mean "suspend-to-RAM", but in fact it means "the deepest sleep
state available with platform support". The definition of STANDBY
is even more arbitrary.
Moreover, the remaining sleep state that doesn't need platform support
is currently called FREEZE, which leads to double confusion with the
process freezer (used during transitions to all sleep states) and
with the freeze stage of processing devices during hibernation.
For these reasons, rename the PM_SUSPEND_MEM, PM_SUSPEND_STANDBY
and PM_SUSPEND_FREEZE symbols to PM_SUSPEND_PLATFORM_DEEP,
PM_SUSPEND_PLATFORM_SHALLOW and PM_SUSPEND_IDLE_SLEEP, respectively,
everywhere and rename data types, functions and variables related to
those states to match the new names of the symbols.
This is a semi-mechanical replacement of names and it should not lead
to any functional differences.
Signed-off-by: Rafael J. Wysocki
---
arch/arm/mach-at91/pm.c | 10 +--
arch/arm/mach-davinci/pm.c|6 +-
arch/arm/mach-exynos/pm.c |2
arch/arm/mach-highbank/pm.c |2
arch/arm/mach-imx/mach-mx31ads.c |8 +--
arch/arm/mach-imx/pm-imx27.c |4 -
arch/arm/mach-imx/pm-imx5.c | 12 ++--
arch/arm/mach-imx/pm-imx6.c |4 -
arch/arm/mach-kirkwood/pm.c |4 -
arch/arm/mach-lpc32xx/pm.c|2
arch/arm/mach-mmp/pm-mmp2.c |3 -
arch/arm/mach-mmp/pm-pxa910.c |3 -
arch/arm/mach-mvebu/kirkwood-pm.c |4 -
arch/arm/mach-mxs/pm.c|4 -
arch/arm/mach-omap1/pm.c |6 +-
arch/arm/mach-omap2/pm.c |6 +-
arch/arm/mach-prima2/pm.c |4 -
arch/arm/mach-pxa/pm.c|4 -
arch/arm/mach-pxa/pxa25x.c|4 -
arch/arm/mach-pxa/pxa27x.c| 10 ++-
arch/arm/mach-pxa/pxa3xx.c|7 +-
arch/arm/mach-pxa/sharpsl_pm.c|2
arch/arm/mach-pxa/z2.c|2
arch/arm/mach-s3c64xx/mach-smdk6410.c |2
arch/arm/mach-sa1100/pm.c |2
arch/arm/mach-shmobile/suspend.c |2
arch/arm/mach-tegra/pm.c |2
arch/arm/mach-ux500/pm.c |3 -
arch/arm/plat-samsung/pm.c|2
arch/avr32/mach-at32ap/pm-at32ap700x.S|2
arch/avr32/mach-at32ap/pm.c |8 +--
arch/blackfin/mach-bf609/pm.c |2
arch/blackfin/mach-common/pm.c| 12 ++--
arch/mips/alchemy/devboards/pm.c |2
arch/mips/jz4740/pm.c |2
arch/mips/loongson/common/pm.c|4 -
arch/powerpc/platforms/52xx/lite5200_pm.c | 12 ++--
arch/powerpc/platforms/52xx/mpc52xx_pm.c |2
arch/powerpc/platforms/83xx/suspend.c | 11 ++--
arch/powerpc/platforms/pseries/suspend.c |6 +-
arch/powerpc/sysdev/fsl_pmc.c |2
arch/powerpc/sysdev/ppc4xx_cpm.c |8 +--
arch/sh/boards/mach-hp6xx/pm.c|2
arch/sh/kernel/cpu/shmobile/pm.c |2
arch/unicore32/kernel/pm.c|4 -
arch/unicore32/kernel/puv3-core.c |4 -
arch/x86/platform/olpc/olpc-xo1-pm.c |4 -
drivers/acpi/sleep.c | 24 -
drivers/base/power/wakeup.c |4 -
drivers/char/apm-emulation.c |6 +-
drivers/macintosh/via-pmu.c |4 -
drivers/regulator/core.c |4 -
include/linux/pm.h|4 -
include/linux/suspend.h | 26 -
kernel/power/hibernate.c |2
kernel/power/suspend.c| 79 +++---
kernel/power/suspend_test.c |6 +-
kernel/power/user.c |2
58 files changed, 193 insertions(+), 183 deletions(-)
Index: linux-pm/arch/arm/mach-at91/pm.c
===
--- linux-pm.orig/arch/arm/mach-at91/pm.c
+++ linux-pm/arch/arm/mach-at91/pm.c
@@ -111,8 +111,8 @@ static int at91_pm_valid_state(suspend_s
{
switch (state) {
case PM_SUSPEND_ON:
- case PM_SUSPEND_STANDBY:
- case PM_SUSPEND_MEM:
+ case PM_SUSPEND_PLATFORM_SHALLOW:
+ case
Re: [PATCH] PCI / PM: Make PCIe PME interrupts wake up from "freeze" sleep state
On Thursday, July 24, 2014 05:36:28 PM Rafael J. Wysocki wrote: > On Thursday, July 24, 2014 03:42:41 PM Peter Zijlstra wrote: > > [...] > > > > > So with this patch on: > > > > http://marc.info/?l=3Dlinux-kernel=3D140620918218199 > > > > This will not work on my machine, because aerdrv is requesting the same > > irq. > > > > Now I've not a f'cking clue what aerdrv is, and whether it too wants > > NO_SUSPEND on or not. > > > > But if I make it also request NO_SUSPEND it all starts working. > > OK, so can you please test the updated patch below? > > Rafael > > --- > From: Rafael J. Wysocki > Subject: PCI / PM: Make PCIe PME interrupts wake up from "freeze" sleep state > > The "freeze" sleep state, also known as suspend-to-idle, is entered > without taking nonboot CPUs offline, right after devices have been > suspended. It works by waiting for at least one wakeup source object > to become "active" as a result of handling a hardware interrupt. > > Of course, interrupts supposed to be able to wake up the system from > suspend-to-idle cannot be disabled by suspend_device_irqs() and their > interrupt handlers must be able to cope with interrupts coming after > all devices have been suspended. In that case, they only need to > call __pm_wakeup_event() for a single wakeup source object without > trying to access hardware (that will be resumed later as part of > the subsequent system resume). > > Make PCIe PME interrupts work this way. > > Register an additional wakeup source object for each PCIe PME > service device. That object will be used to generate wakeups from > suspend-to-idle. > > Add IRQF_NO_SUSPEND to PME interrupt flags. This will make > suspend_device_irqs() to ignore PME interrupts, but that's OK, > because the PME interrupt handler is suspend-aware anyway and > can cope with interrupts coming during system suspend-resume. > Unfortunately, that requires the AER service driver to pass > IRQF_NO_SUSPEND when requesting its IRQ which may be shared with > the PME interrupt and to make that safe, simple suspend/resume > routines need to be added to the AER driver. > > During system suspend, while suspending the PME service for given > port, walk the bus below that port and see if any devices on that > bus are configured for wakeup. If so, do not disable the PME > interrupt, but only set a "suspend level" for the service to > "wakeup" and make the interrupt handler behave in a special way, > which is to call __pm_wakeup_event() with the service's wakeup > source object as the first argument whenever the interrupt is > triggered. > > The "suspend level" is cleared while resuming the PME service. > > This change allows Wake-on-LAN to be used for wakeup from > suspend-to-idle on my MSI Wind tesbed netbook. Hi Bjorn, There will be a new version of this, please ignore for now. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: General flags to turn things off (getrandom, pid lookup, etc)
On Jul 27, 2014 5:06 PM, "Theodore Ts'o" wrote: > > On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote: > > > > There is recent interest in having a way to turn generally-available > > kernel features off. Maybe we should add a good one so we can stop > > bikeshedding and avoid proliferating dumb interfaces. > > I believe the seccomp infrastructure (which is already upstream) > should be able to do most of what you want, at least with respect to > features which are exposed via system calls (which was most of your > list). Seccomp can't really restrict lookups of non-self pids. In fact, this feature idea started out as a response to a patch adding a kind of nasty seccomp feature to make it sort of possible. I agree that that seccomp can turn off GRND_RANDOM, but how is it supposed to do it in such a way that the filtered software will fall back to something sensible? -ENOSYS? -EPERM? Something else? I think that -ENOSYS is clearly wrong, but standardizing this would be nice. Admittedly, adding something fancy like this for GRND_RANDOM may not be appropriate. --Andy > > It won't cover x86 specific things like restricting RDTSC or CPUID > (and as far as I know you can't intercept the CPUID instruction), but > I'm not sure it matters. I don't really see the point, myself. > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: x86: ia32: ia32_aout.c: Cleaning up missing null-terminate in conjunction with strncpy
Rickard, On Jul 26, 2014, at 2:50 PM, Rickard Strandqvist wrote: > Replacing strncpy with strlcpy to avoid strings that lacks null terminate. > And use the sizeof on the to string rather than the from string. > > Signed-off-by: Rickard Strandqvist > --- > arch/x86/ia32/ia32_aout.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c > index d21ff89..1a5eb43 100644 > --- a/arch/x86/ia32/ia32_aout.c > +++ b/arch/x86/ia32/ia32_aout.c > @@ -156,7 +156,7 @@ static int aout_core_dump(struct coredump_params *cprm) > fs = get_fs(); > set_fs(KERNEL_DS); > has_dumped = 1; > - strncpy(dump.u_comm, current->comm, sizeof(current->comm)); > + strlcpy(dump.u_comm, current->comm, sizeof(dump.u_comm)); > dump.u_ar0 = offsetof(struct user32, regs); > dump.signal = cprm->siginfo->si_signo; > dump_thread32(cprm->regs, ); This patch appears to introduce an information leakage as well. The dump structure is on the stack and not cleared, so changing to strlcpy leaves part of the u_comm field holding unintialized data which is then written into the dump. The sizeof in the 3rd argument of the original is really an incorrect reference, as you corrected. A question to consider in this case: is the string in that structure expected to always be null-terminated or not. It is not the case that all such character arrays are expected to be. I don't happen to know in this case. -- Mark Rustad, mrus...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v2] iio: exynos-adc: add experimental touchscreen support
Am Sonntag, 27. Juli 2014, 23:10:21 schrieb Hartmut Knaack: > Arnd Bergmann schrieb: > > @@ -205,6 +217,9 @@ static void exynos_adc_v1_init_hw(struct exynos_adc > > *info)> > > /* Enable 12-bit ADC resolution */ > > con1 |= ADC_V1_CON_RES; > > writel(con1, ADC_V1_CON(info->regs)); > > > > + > > + /* set default touchscreen delay */ > > Any information about how many µs/ms it is actually set with this value? "ADC conversion is delayed by counting this value. Counting clock is pclk." So, I guess here 1 pclk ticks. Heiko > > > + writel(1, ADC_V1_DLY(info->regs)); > > > > } > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH, v2]
On Sunday, July 27, 2014 05:53:07 PM Rafael J. Wysocki wrote: > On Saturday, July 26, 2014 12:25:29 AM Rafael J. Wysocki wrote: > > On Friday, July 25, 2014 11:00:12 PM Thomas Gleixner wrote: > > > On Fri, 25 Jul 2014, Rafael J. Wysocki wrote: > > > > On Friday, July 25, 2014 03:25:41 PM Peter Zijlstra wrote: > > > > > OK, so Rafael said there's devices that keep on raising their > > > > > interrupt > > > > > until they get attention. Ideally this won't happen because the device > > > > > is suspended etc.. But I'm sure there's some broken piece of hardware > > > > > out there that'll make it go boom. > > > > > > > > So here's an idea. > > > > > > > > What about returning IRQ_NONE rather than IRQ_HANDLED for "suspended" > > > > interrupts (after all, that's what a sane driver would do for a > > > > suspended device I suppose)? > > > > > > > > If the line is really shared and the interrupt is taken care of by > > > > the other guy sharing the line, we'll be all fine. > > > > > > > > If that is not the case, on the other hand, and something's really > > > > broken, we'll end up disabling the interrupt and marking it as > > > > IRQS_SPURIOUS_DISABLED (if I understand things correctly). > > > > > > We should not wait 100k unhandled interrupts in that case. We know > > > already at the first unhandled interrupt that the shit hit the fan. > > > > The first one may be a bus glitch or some such. Also I guess we still need > > to > > allow the legitimate "no suspend" guy to handle his interrupts until it gets > > too worse. > > > > Also does it really hurt to rely on the generic mechanism here? We regard > > it as fine at all other times after all. > > Having considered this for some more time, I think that we need to address > the IRQF_NO_SUSPEND problem with shared interrupts regardless of what's > decided about the device wakeup and suspending interrupts, because (1) it's > already there (and the Peter's patch to add IRQF_NO_SUSPEND to "mismatch" > flags may break working systems that aren't even buggy, sorry for noticing > that so late) and (2) we'll need something like IRQF_NO_SUSPEND idependently > of wakeup anyway, for timers and things like the ACPI SCI. > > Below is my attempt to do that based on the prototype I sent previously. > It contains a mechanism to disable IRQs generating spurious interrupts > during system suspend/resume faster, but otherwise works along the same > lines. I realized that it had a problem where resume_device_irqs() theoretically could re-enable an IRQ that was not disabled by suspend_device_irqs(). Unfortunately, to plug that hole I needed a new IRQS_ flag that would be set for shared suspended interrupts that required special handling. I also fixed up the changelog as it had one thing described upside down. Updated patch below (I tested it on my MSI Wind in which PCI PME IRQs are shared with other devices). Rafael --- From: Rafael J. Wysocki Subject: irq / PM: Fix IRQF_NO_SUSPEND problem with shared interrupts Since __disable_irq() only checks IRQF_NO_SUSPEND for the first irqaction in a given irq_desc, that value of that bit for the first irqaction affects all of the other irqactions sharing the interrupt with it. This is problematic in two cases. First, if IRQF_NO_SUSPEND is set in the first irqaction and unset in at least one of the other irqactions sharing the same interrupt, the interrupt handlers in the other irqactions with IRQF_NO_SUSPEND unset will be invoked after suspend_device_irqs() has returned even though they are not supposed to. That shouldn't be a problem if those interrupt handlers are implemented correctly and the corresponding devices are properly suspended, but it may lead to functional issues otherwise. Second, if IRQF_NO_SUSPEND is unset in the first irqaction and set in at least one of the other irqactions sharing the same interrupt, the interrupt handlers in the other irqactions with IRQF_NO_SUSPEND set will not be invoked after suspend_device_irqs() has returned, but they are supposed to be invoked then. That may be a problem if the corresponding devices are wakeup devices or if their interrupts have to be properly handled during system suspend/resume too for other reasons, which is the case for timer interrupts or the ACPI SCI for example. To address this, modify the handling of IRQF_NO_SUSPEND by suspend_device_irqs() and resume_device_irqs() and make handle_irq_event_percpu() and note_interrupt() handle suspended interrupts. First of all, make suspend_device_irqs() check IRQF_NO_SUSPEND for all irqactions sharing the same irq_desc and avoid disabling the IRQ if at least one of them has IRQF_NO_SUSPEND set. If that flag is also unset for at least one irqaction in the given irq_desc, however, suspend_device_irqs() will mark the IRQ as IRQS_SHARED_SUSPENDED (new flag). Second, make handle_irq_event_percpu() return IRQ_NONE without invoking the interrupt handler for irqactions with IRQF_NO_SUSPEND unset if their irq_desc
Re: [PATCH] staging: ced1401: userspace: use1401.c: Cleaning up missing null-terminate in conjunction with strncpy
2014-07-27 20:44 GMT+02:00 Greg Kroah-Hartman : > On Sun, Jul 27, 2014 at 01:10:25AM +0200, Rickard Strandqvist wrote: >> Replacing strncpy with strlcpy to avoid strings that lacks null terminate. >> And replacing strncat with strlcat because of incorrect use. >> >> Signed-off-by: Rickard Strandqvist >> --- >> drivers/staging/ced1401/userspace/use1401.c | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) > > This file is no longer in my tree :( Hi No, it does not exist in Linux-next anymore... I must keep better track of linux-next :-/ Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] sched: Add on_rq states and remove several double rq locks
On 26.07.2014 23:39, Oleg Nesterov wrote: > Hi Kirill, > > I'll try to read this series later, just one silly question for now. > > On 07/26, Kirill Tkhai wrote: >> >> Patch [2/5] is main in the series. It introduces new state: ONRQ_MIGRATING >> and teaches scheduler to understand it (we need a little changes >> predominantly >> in try_to_wake_up()). This will be used in the following way: >> >> (we are changing task's rq) >> >> raw_spin_lock(_rq->lock); >> dequeue_task(src_rq, p, 0); >> p->on_rq = ONRQ_MIGRATING; >> set_task_cpu(p, dst_cpu); >> raw_spin_unlock(_rq->lock); >> >> raw_spin_lock(_rq->lock); >> p->on_rq = ONRQ_QUEUED; >> enqueue_task(dst_rq, p, 0); >> raw_spin_unlock(_rq->lock); > > Hmm. And what if the code above doesn't hold p->pi_lock (4/5) and, say, > __sched_setscheduler() does fair_sched_class->rt_sched_class transition > in between? > > ONRQ_MIGRATING helps to avoid the wrong dequeue + enqueue, but I am not > sure about check_class_changed(). > > Say, switched_from_fair() will use dst_rq even if p was never queued on > this rq... This only affects the .decay_count logic, perhaps this is fine, > I simply do not know what this code does. You're right. We have to check for "task_migrating" in switched_from_fair(). One more place is switched_from_dl(). > What about switched_to_rt() ? we lose the push_rt_task() logic... Hmm, > which I can't understand too ;) > > And we also lose ENQUEUE_HEAD in this case, but this looks fine. > > In short: could you confirm there are no problems here? This will be the reason of some RT/DL imbalance. We need a method how to avoid this. Maybe, it would be good to call something like check_class_changed() at the end of migration process. We just need to save task's class before migration and compare with the class after migration (for [3/5], __migrate_task()). For [4/5] and [5/5] the class is always fair_sched_class. Thanks for the comments. I'll think how to fix this in a good way, and update the series. Kirill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] iio: exynos-adc: add experimental touchscreen support
Arnd Bergmann schrieb:
> This adds support for the touchscreen on Samsung s3c64xx.
> The driver is completely untested but shows roughly how
> it could be done, following the example of the at91 driver.
>
> Open questions include:
>
> - compared to the old plat-samsung/adc driver, there is
> no support for prioritizing ts over other clients, nor
> for oversampling. From my reading of the code, the
> priorities didn't actually have any effect at all, but
> the oversampling might be needed. Maybe the original
> authors have some insight.
>
> - We probably need to add support for platform_data as well,
> I've skipped this so far.
>
> Signed-off-by: Arnd Bergmann
> ---
> This should address all previous comments, and I've also added
> a write to ADC_V1_DLY() as the old driver does.
Just two minor issues inline.
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> index cad81b666a67..ba30836c73cb 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> @@ -43,6 +43,10 @@ Required properties:
> and compatible ADC block)
> - vdd-supply VDD input supply.
>
> +Optional properties:
> +- has-touchscreen: If present, indicates that a touchscreen is
> + connected an usable.
Typo: and
> +
> Note: child nodes can be added for auto probing from device tree.
>
> Example: adding device info in dtsi file
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 420c5cda09c3..3b684a117b9c 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -66,6 +67,9 @@
>
> #define ADC_S3C2410_CON_SELMUX(x) (((x)&0x7)<<3)
>
> +/* touch screen always uses channel 0 */
> +#define ADC_S3C2410_MUX_TS 0
> +
> /* ADCTSC Register Bits */
> #define ADC_S3C2443_TSC_UD_SEN (1u << 8)
> #define ADC_S3C2410_TSC_YM_SEN (1u << 7)
> @@ -103,24 +107,32 @@
>
> /* Bit definitions common for ADC_V1 and ADC_V2 */
> #define ADC_CON_EN_START (1u << 0)
> +#define ADC_DATX_PRESSED (1u << 15)
> #define ADC_DATX_MASK0xFFF
> +#define ADC_DATY_MASK0xFFF
>
> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
>
> struct exynos_adc {
> struct exynos_adc_data *data;
> struct device *dev;
> + struct input_dev*input;
> void __iomem*regs;
> void __iomem*enable_reg;
> struct clk *clk;
> struct clk *sclk;
> unsigned intirq;
> + unsigned inttsirq;
> struct regulator*vdd;
>
> struct completion completion;
>
> u32 value;
> unsigned intversion;
> +
> + boolread_ts;
> + u32 ts_x;
> + u32 ts_y;
> };
>
> struct exynos_adc_data {
> @@ -205,6 +217,9 @@ static void exynos_adc_v1_init_hw(struct exynos_adc *info)
> /* Enable 12-bit ADC resolution */
> con1 |= ADC_V1_CON_RES;
> writel(con1, ADC_V1_CON(info->regs));
> +
> + /* set default touchscreen delay */
Any information about how many µs/ms it is actually set with this value?
> + writel(1, ADC_V1_DLY(info->regs));
> }
>
> static void exynos_adc_v1_exit_hw(struct exynos_adc *info)
> @@ -390,12 +405,54 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> return ret;
> }
>
> +static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y)
> +{
> + struct exynos_adc *info = iio_priv(indio_dev);
> + unsigned long timeout;
> + int ret;
> +
> + mutex_lock(_dev->mlock);
> + info->read_ts = true;
> +
> + reinit_completion(>completion);
> +
> + writel(ADC_S3C2410_TSC_PULL_UP_DISABLE | ADC_TSC_AUTOPST,
> +ADC_V1_TSC(info->regs));
> +
> + /* Select the ts channel to be used and Trigger conversion */
> + info->data->start_conv(info, ADC_S3C2410_MUX_TS);
> +
> + timeout = wait_for_completion_timeout
> + (>completion, EXYNOS_ADC_TIMEOUT);
> + if (timeout == 0) {
> + dev_warn(_dev->dev, "Conversion timed out! Resetting\n");
> + if (info->data->init_hw)
> + info->data->init_hw(info);
> + ret = -ETIMEDOUT;
> + } else {
> + *x = info->ts_x;
> + *y = info->ts_y;
> + ret = 0;
> + }
> +
> + info->read_ts = false;
> + mutex_unlock(_dev->mlock);
> +
> + return ret;
> +}
> +
> static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
> {
> struct exynos_adc *info = (struct exynos_adc *)dev_id;
>
> /*
Re: General flags to turn things off (getrandom, pid lookup, etc)
On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote: > > There is recent interest in having a way to turn generally-available > kernel features off. Maybe we should add a good one so we can stop > bikeshedding and avoid proliferating dumb interfaces. I believe the seccomp infrastructure (which is already upstream) should be able to do most of what you want, at least with respect to features which are exposed via system calls (which was most of your list). It won't cover x86 specific things like restricting RDTSC or CPUID (and as far as I know you can't intercept the CPUID instruction), but I'm not sure it matters. I don't really see the point, myself. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: visorchipset: fix sparse warnings about static declaration
Some functions were prototyped as static but the actual definition
wasn't. While this is valid (the function is static because the two
declarations don't conflict and the first one is static), this makes
sparse unhappy and cause confusion of normal people too.
Signed-off-by: Vincent Bernat
---
.../unisys/visorchipset/visorchipset_main.c| 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/unisys/visorchipset/visorchipset_main.c
b/drivers/staging/unisys/visorchipset/visorchipset_main.c
index 58a441dd602e..65541dad014c 100644
--- a/drivers/staging/unisys/visorchipset/visorchipset_main.c
+++ b/drivers/staging/unisys/visorchipset/visorchipset_main.c
@@ -367,8 +367,9 @@ static void
controlvm_respond_physdev_changestate(CONTROLVM_MESSAGE_HEADER *
msgHdr, int response,
ULTRA_SEGMENT_STATE state);
-ssize_t toolaction_show(struct device *dev, struct device_attribute *attr,
- char *buf)
+static ssize_t toolaction_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
U8 toolAction;
@@ -378,8 +379,9 @@ ssize_t toolaction_show(struct device *dev, struct
device_attribute *attr,
return scnprintf(buf, PAGE_SIZE, "%u\n", toolAction);
}
-ssize_t toolaction_store(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t toolaction_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
{
U8 toolAction;
@@ -395,8 +397,9 @@ ssize_t toolaction_store(struct device *dev, struct
device_attribute *attr,
return -EIO;
}
-ssize_t boottotool_show(struct device *dev, struct device_attribute *attr,
- char *buf)
+static ssize_t boottotool_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
{
ULTRA_EFI_SPAR_INDICATION efiSparIndication;
@@ -408,8 +411,9 @@ ssize_t boottotool_show(struct device *dev, struct
device_attribute *attr,
efiSparIndication.BootToTool);
}
-ssize_t boottotool_store(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t boottotool_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
{
int val;
ULTRA_EFI_SPAR_INDICATION efiSparIndication;
@@ -2003,7 +2007,7 @@ handle_command(CONTROLVM_MESSAGE inmsg, HOSTADDRESS
channel_addr)
return TRUE;
}
-HOSTADDRESS controlvm_get_channel_address(void)
+static HOSTADDRESS controlvm_get_channel_address(void)
{
U64 addr = 0;
U32 size = 0;
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Multi Core Support for compression in compression.c
This may be a bad idea , but compression in brtfs seems to be only using one core to compress. Depending on the CPU used and the amount of cores in the CPU we can make this much faster with multiple cores. This seems bad by my reading at least I would recommend for writing compression we write a function to use a certain amount of cores based on the load of the system's CPU not using more then 75% of the system's CPU resources as my system when idle has never needed more then one core of my i5 2500k to run when with interrupts for opening eclipse are running. For reading compression on good core seems fine to me as testing other compression software for reads , it's way less CPU intensive. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug on Kernel 3.16 r6: Sound and Buffering in Clementine with Files are Transferring to Music Directory
On Sun, Jul 27, 2014 at 4:18 PM, Nick Krause wrote: > On Sun, Jul 27, 2014 at 4:37 AM, Heinz Diehl wrote: >> On 27.07.2014, Nick Krause wrote: >> >>> When I transfer a lot of music for a brtfs external hard drive I have the >>> music >>> in clementine I am listening to is stopped for a few seconds and then >>> continues. >> >> Most probably, this is not a bug, but caused by high disk I/O. It's >> not clear to me if the music you are listening to is located on the >> same disk which you transfer to/from. This would make things even >> worse. >> >> However, there are a few thing you can do to try to minimize the observed >> stalls: >> >> 1. Compile your kernel with CONFIG_PREEMPT enabled >> 2. Reduce the amount of memory content sync'ed to disk >> 3. If your disk is a SSD: change the elevator to "noop" >> 4. Enable writeback on your disk >> 5. Increase the disks readahead sectors >> 6. Increase the audio buffers in your player >> >> 1. CONFIG_PREEMPT=y >> >> 2. Sysctl: vm.dirty_ratio = 10 >>vm.dirty_background_ratio = 5 >> >> 3. echo "noop" > /sys/block/sda/queue/scheduler >> >> 4. /sbin/hdparm -W1 /dev/sda >> >> 5. /sbin/blockdev --setra 8192 /dev/sda >> >> Regards, >> Heinz. > Heinz, > The audio buffer is not going to work as this was never a issue with > default Ubuntu kernels. > However I will try your other ideas and report back :). I am > transferring into the same directory > for the music I am listening to. In addition , my cpu usage when doing > this is half of my older > Ubuntu distro kernel, 6 vs 3 percent for upstream. > Cheers Nick Seems to be an issue after updating my settings as stated. I am now using kernel 3.16 r7 as I updated my git tree before compiling my kernel again. Regards Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] iio: adc: exynos_adc: Add support for S3C24xx ADC
Chanwoo Choi schrieb:
> This patch add support for s3c2410/s3c2416/s3c2440/s3c2443 ADC. The s3c24xx
> is alomost same as ADCv1. But, There are a little difference as following:
> - ADCMUX register address to select channel
> - ADCDAT mask (10bit or 12bit ADC resolution according to SoC version)
Hi, just some style issues: better separate things like 10bit with a space to
10 bit, there are some instances of this type in your code. Another issue
inline.
>
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Arnd Bergmann
> ---
> .../devicetree/bindings/arm/samsung/exynos-adc.txt | 10 ++-
> drivers/iio/adc/exynos_adc.c | 89
> +-
> 2 files changed, 96 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> index b6e3989..fe34c76 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> @@ -11,11 +11,19 @@ New driver handles the following
>
> Required properties:
> - compatible:Must be "samsung,exynos-adc-v1"
> - for exynos4412/5250 controllers.
> + for exynos4412/5250 and s5pv210 controllers.
> Must be "samsung,exynos-adc-v2" for
> future controllers.
> Must be "samsung,exynos3250-adc" for
> controllers compatible with ADC of Exynos3250.
> + Must be "samsung,s3c2410-adc" for
> + the ADC in s3c2410 and compatibles
> + Must be "samsung,s3c2416-adc" for
> + the ADC in s3c2416 and compatibles
> + Must be "samsung,s3c2440-adc" for
> + the ADC in s3c2440 and compatibles
> + Must be "samsung,s3c2443-adc" for
> + the ADC in s3c2443 and compatibles
> Must be "samsung,s3c6410-adc" for
> the ADC in s3c6410 and compatibles
> - reg: Contains ADC register address range (base
> address and
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 05bdd2f12..7d28032 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -51,6 +51,9 @@
> #define ADC_V1_MUX(x)((x) + 0x1c)
> #define ADC_V1_CLRINTPNDNUP(x) ((x) + 0x20)
>
> +/* S3C2410 ADC registers definitions */
> +#define ADC_S3C2410_MUX(x) ((x) + 0x18)
> +
> /* Future ADC_V2 registers definitions */
> #define ADC_V2_CON1(x) ((x) + 0x00)
> #define ADC_V2_CON2(x) ((x) + 0x04)
> @@ -67,6 +70,8 @@
>
> /* Bit definitions for S3C2410 ADC */
> #define ADC_S3C2410_CON_SELMUX(x) (((x) & 7) <<3)
> +#define ADC_S3C2410_DATX_MASK0x3FF
> +#define ADC_S3C2416_CON_RES_SEL (1 << 3)
Since it is done this way in this driver, better use (1u << 3) here.
>
> /* Bit definitions for ADC_V2 */
> #define ADC_V2_CON1_SOFT_RESET (1u << 2)
> @@ -84,6 +89,7 @@
>
> /* Bit definitions common for ADC_V1 and ADC_V2 */
> #define ADC_CON_EN_START (1u << 0)
> +#define ADC_CON_EN_START_MASK(0x3 << 0)
> #define ADC_DATX_MASK0xFFF
>
> #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
> @@ -101,12 +107,14 @@ struct exynos_adc {
> struct completion completion;
>
> u32 value;
> + u32 value2;
> unsigned intversion;
> };
>
> struct exynos_adc_data {
> int num_channels;
> bool needs_sclk;
> + u32 mask;
>
> void (*init_hw)(struct exynos_adc *info);
> void (*exit_hw)(struct exynos_adc *info);
> @@ -217,6 +225,17 @@ static void exynos_adc_v1_start_conv(struct exynos_adc
> *info,
>
> static const struct exynos_adc_data const exynos_adc_v1_data = {
> .num_channels = MAX_ADC_V1_CHANNELS,
> + .mask = ADC_DATX_MASK, /* 12bit ADC resolution */
> +
> + .init_hw= exynos_adc_v1_init_hw,
> + .exit_hw= exynos_adc_v1_exit_hw,
> + .clear_irq = exynos_adc_v1_clear_irq,
> + .start_conv = exynos_adc_v1_start_conv,
> +};
> +
> +static struct exynos_adc_data const exynos_adc_s3c24xx_data = {
> + .num_channels = MAX_ADC_V1_CHANNELS,
> + .mask = ADC_S3C2410_DATX_MASK, /* 10bit ADC resolution */
>
> .init_hw= exynos_adc_v1_init_hw,
> .exit_hw= exynos_adc_v1_exit_hw,
> @@ -224,6 +243,55 @@ static const struct exynos_adc_data const
> exynos_adc_v1_data = {
> .start_conv = exynos_adc_v1_start_conv,
> };
>
> +static void exynos_adc_s3c2416_start_conv(struct exynos_adc *info,
> + unsigned long addr)
> +{
Re: [PATCH 2/2] V3 ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
Dear Benoit Masson,
On Sat, 26 Jul 2014 16:48:10 -0700, Benoit Masson wrote:
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-0 = <_button_pin _button_pin
> + _button_pin _button_pin>;
> + pinctrl-names = "default";
> +
> + power-button {
> + label = "Power Button";
> + linux,code = ;
> + gpios = < 12 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reset-button {
> + label = "Reset Button";
> + linux,code = ;
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + select-button {
> + label = "Select Button";
> + linux,code = ;
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + };
> +
> + scroll-button {
> + label = "Scroll Button";
> + linux,code = ;
> + gpios = < 10 GPIO_ACTIVE_LOW>;
So you're using the GPIO_ACTIVE_ defines here.
> + };
> + };
> +
> + spi3 {
> + compatible = "spi-gpio";
> + status = "okay";
> + gpio-sck = < 25 0>;
> + gpio-mosi = < 15 0>; /*gpio 47*/
> + cs-gpios = < 27 0 >;
But not here. Any reason?
Also, nitpick: unneeded space in < 27 0 > (i.e the space right
before the closing >).
> + num-chipselects = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio2: gpio2@0 {
> + compatible = "fairchild,74hc595";
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0>;
> + registers-number = <2>;
> + spi-max-frequency = <10>;
> + };
I'm not sure "gpio2" is a good name, as we might think of it as being
the third GPIO controller internal to the SoC.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: lustre: linux-module: fix coding style issues
Fixed some coding style issues:
- Removed spaces after open parenthesis and before close parenthesis
- Removed parentheses in some return statements, since return is not a
function
- Fixed a warning regarding the file_operations struct; it is
normally const
- Fixed pointer style issues (foo * bar -> foo *bar)
Signed-off-by: Jessica Yu
---
drivers/staging/lustre/lustre/libcfs/linux/linux-module.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
index ccadf65..de3c199 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
@@ -99,7 +99,7 @@ int libcfs_ioctl_popdata(void *arg, void *data, int size)
extern struct cfs_psdev_ops libcfs_psdev_ops;
static int
-libcfs_psdev_open(struct inode * inode, struct file * file)
+libcfs_psdev_open(struct inode *inode, struct file *file)
{
struct libcfs_device_userstate **pdu = NULL;
intrc = 0;
@@ -116,7 +116,7 @@ libcfs_psdev_open(struct inode * inode, struct file * file)
/* called when closing /dev/device */
static int
-libcfs_psdev_release(struct inode * inode, struct file * file)
+libcfs_psdev_release(struct inode *inode, struct file *file)
{
struct libcfs_device_userstate *pdu;
intrc = 0;
@@ -140,9 +140,9 @@ static long libcfs_ioctl(struct file *file,
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
- if ( _IOC_TYPE(cmd) != IOC_LIBCFS_TYPE ||
+ if (_IOC_TYPE(cmd) != IOC_LIBCFS_TYPE ||
_IOC_NR(cmd) < IOC_LIBCFS_MIN_NR ||
-_IOC_NR(cmd) > IOC_LIBCFS_MAX_NR ) {
+_IOC_NR(cmd) > IOC_LIBCFS_MAX_NR) {
CDEBUG(D_IOCTL, "invalid ioctl ( type %d, nr %d, size %d )\n",
_IOC_TYPE(cmd), _IOC_NR(cmd), _IOC_SIZE(cmd));
return (-EINVAL);
@@ -154,7 +154,7 @@ static long libcfs_ioctl(struct file *file,
if (!capable(CFS_CAP_SYS_BOOT))
return (-EPERM);
panic("debugctl-invoked panic");
- return (0);
+ return 0;
case IOC_LIBCFS_MEMHOG:
if (!capable(CFS_CAP_SYS_ADMIN))
return -EPERM;
@@ -167,10 +167,10 @@ static long libcfs_ioctl(struct file *file,
rc = libcfs_psdev_ops.p_ioctl(, cmd, (void *)arg);
else
rc = -EPERM;
- return (rc);
+ return rc;
}
-static struct file_operations libcfs_fops = {
+static const struct file_operations libcfs_fops = {
.unlocked_ioctl = libcfs_ioctl,
.open = libcfs_psdev_open,
.release= libcfs_psdev_release,
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: lustre: linux-module: fix coding style issues.
Fixed some coding style issues.
Signed-off-by: Jessica Yu
---
drivers/staging/lustre/lustre/libcfs/linux/linux-module.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
index ccadf65..de3c199 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
@@ -99,7 +99,7 @@ int libcfs_ioctl_popdata(void *arg, void *data, int size)
extern struct cfs_psdev_ops libcfs_psdev_ops;
static int
-libcfs_psdev_open(struct inode * inode, struct file * file)
+libcfs_psdev_open(struct inode *inode, struct file *file)
{
struct libcfs_device_userstate **pdu = NULL;
intrc = 0;
@@ -116,7 +116,7 @@ libcfs_psdev_open(struct inode * inode, struct file * file)
/* called when closing /dev/device */
static int
-libcfs_psdev_release(struct inode * inode, struct file * file)
+libcfs_psdev_release(struct inode *inode, struct file *file)
{
struct libcfs_device_userstate *pdu;
intrc = 0;
@@ -140,9 +140,9 @@ static long libcfs_ioctl(struct file *file,
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
- if ( _IOC_TYPE(cmd) != IOC_LIBCFS_TYPE ||
+ if (_IOC_TYPE(cmd) != IOC_LIBCFS_TYPE ||
_IOC_NR(cmd) < IOC_LIBCFS_MIN_NR ||
-_IOC_NR(cmd) > IOC_LIBCFS_MAX_NR ) {
+_IOC_NR(cmd) > IOC_LIBCFS_MAX_NR) {
CDEBUG(D_IOCTL, "invalid ioctl ( type %d, nr %d, size %d )\n",
_IOC_TYPE(cmd), _IOC_NR(cmd), _IOC_SIZE(cmd));
return (-EINVAL);
@@ -154,7 +154,7 @@ static long libcfs_ioctl(struct file *file,
if (!capable(CFS_CAP_SYS_BOOT))
return (-EPERM);
panic("debugctl-invoked panic");
- return (0);
+ return 0;
case IOC_LIBCFS_MEMHOG:
if (!capable(CFS_CAP_SYS_ADMIN))
return -EPERM;
@@ -167,10 +167,10 @@ static long libcfs_ioctl(struct file *file,
rc = libcfs_psdev_ops.p_ioctl(, cmd, (void *)arg);
else
rc = -EPERM;
- return (rc);
+ return rc;
}
-static struct file_operations libcfs_fops = {
+static const struct file_operations libcfs_fops = {
.unlocked_ioctl = libcfs_ioctl,
.open = libcfs_psdev_open,
.release= libcfs_psdev_release,
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug on Kernel 3.16 r6: Sound and Buffering in Clementine with Files are Transferring to Music Directory
On Sun, Jul 27, 2014 at 4:37 AM, Heinz Diehl wrote: > On 27.07.2014, Nick Krause wrote: > >> When I transfer a lot of music for a brtfs external hard drive I have the >> music >> in clementine I am listening to is stopped for a few seconds and then >> continues. > > Most probably, this is not a bug, but caused by high disk I/O. It's > not clear to me if the music you are listening to is located on the > same disk which you transfer to/from. This would make things even > worse. > > However, there are a few thing you can do to try to minimize the observed > stalls: > > 1. Compile your kernel with CONFIG_PREEMPT enabled > 2. Reduce the amount of memory content sync'ed to disk > 3. If your disk is a SSD: change the elevator to "noop" > 4. Enable writeback on your disk > 5. Increase the disks readahead sectors > 6. Increase the audio buffers in your player > > 1. CONFIG_PREEMPT=y > > 2. Sysctl: vm.dirty_ratio = 10 >vm.dirty_background_ratio = 5 > > 3. echo "noop" > /sys/block/sda/queue/scheduler > > 4. /sbin/hdparm -W1 /dev/sda > > 5. /sbin/blockdev --setra 8192 /dev/sda > > Regards, > Heinz. Heinz, The audio buffer is not going to work as this was never a issue with default Ubuntu kernels. However I will try your other ideas and report back :). I am transferring into the same directory for the music I am listening to. In addition , my cpu usage when doing this is half of my older Ubuntu distro kernel, 6 vs 3 percent for upstream. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.16-rc7
I'm happy to say that things have calmed down a bit, and things look to be on track. Which didn't actually seem to be the case at all earlier this week - we had what appeared to be really nasty core bugs, and together with rc6 being bigger than previous rc's, I was really not feeling all that good about this release there for a while. But the worst "nasty bugs" ended up clearing up and not being kernel bugs at all. One turned out to be a compiler issue (which is always very scary and hard to debug and very annoying), and it even had a fairly simple workaround so that we didn't end up having to blacklist compilers. Another turned out to be lockdep just being too aggressive, and a false positive. We obviously *do* have various real fixes in here, but none of them look all that special or worrisome. And rc7 is finally noticeable smaller than previous rc's, so we clearly are calming down. So unlike my early worries, this might well be the last rc, we'll see how next week looks/feels. In numbers, rc7 is about one third arch (xtensa, powerpc, x86, s390, blackfin), one third drivers (gpu, media, networking), and one third "random" (networking, mm). But it's all fairly small. Shortlog appended. Linus --- Alex Deucher (1): drm/radeon/TN: only enable bapm on MSI systems Alexander Graf (3): PPC: Add _GLOBAL_TOC for 32bit KVM: PPC: Book3S PR: Fix ABIv2 on LE KVM: PPC: RTAS: Do byte swaps explicitly Alexey Asemov (1): libata: EH should handle AMNF error condition as a media error Amir Vadai (1): net/mlx4_en: cq->irq_desc wasn't set in legacy EQ's Andrew Gallagher (1): fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT Andrey Utkin (1): drivers/ata/pata_ep93xx.c: use signed int type for result of platform_get_irq() Andy Lutomirski (1): kprobes/x86: Don't try to resolve kprobe faults from userspace Aneesh Kumar K.V (2): KVM: PPC: BOOK3S: HV: Use base page size when comparing against slb value powerpc: subpage_protect: Increase the array size to take care of 64TB Anton Blanchard (1): KVM: PPC: Assembly functions exported to modules need _GLOBAL_TOC() Antonio Quartulli (1): batman-adv: fix TT VLAN inconsistency on VLAN re-add Antti Palosaari (8): [media] si2168: add one missing parenthesis [media] si2157: add one missing parenthesis [media] si2168: firmware download fix [media] af9035: override tuner id when bad value set into eeprom [media] tda10071: force modulation to QPSK on DVB-S [media] tda10071: add missing DVB-S2/PSK-8 FEC AUTO [media] tda10071: fix spec inversion reporting [media] tda10071: fix returned symbol rate calculation Arnd Bergmann (1): [media] staging: tighten omap4iss dependencies Bandan Das (1): KVM: x86: Check for nested events if there is an injectable interrupt Ben Hutchings (1): dns_resolver: Null-terminate the right string Bjorn Helgaas (1): Input: sirfsoc-onkey - fix GPL v2 license string typo Bjørn Mork (2): net: qmi_wwan: add two Sierra Wireless/Netgear devices net: huawei_cdc_ncm: add "subclass 3" devices Boaz Harrosh (1): direct-io: fix uninitialized warning in do_direct_IO() Borislav Petkov (1): x86, MCE: Robustify mcheck_init_device Catalin Marinas (1): arm64: Create non-empty ZONE_DMA when DRAM starts above 4GB Chris Wilson (2): drm/i915: Reorder the semaphore deadlock check, again drm/i915: Simplify i915_gem_release_all_mmaps() Christian König (5): drm/radeon: let's use GB for vm_size (v2) drm/radeon: fix handling of radeon_vm_bo_rmv v3 drm/radeon: fix VM IB handling drm/radeon: fix error handling in radeon_vm_bo_set_addr drm/radeon: fix irq ring buffer overflow handling Christoph Hellwig (1): block: don't assume last put of shared tags is for the host Christoph Schulz (1): net: ppp: fix creating PPP pass and active filters Cong Wang (1): net_sched: avoid generating same handle for u32 filters Dan Carpenter (2): [media] davinci: vpif: missing unlocks on error wan/x25_asy: integer overflow in x25_asy_change_mtu() David Hildenbrand (1): s390: require mvcos facility, not tod clock steering facility David Rientjes (1): perf/x86/intel: Avoid spamming kernel log for BTS buffer failure David S. Miller (1): sparc: Hook up renameat2 syscall. Dmitry Torokhov (1): Input: fix defuzzing logic Eric Dumazet (2): netfilter: nf_tables: 64bit stats need some extra synchronization ipv4: fix buffer overflow in ip_options_compile() Felipe Balbi (1): Input: ti_am335x_tsc - warn about incorrect spelling Geert Uytterhoeven (1): sh: also try passing -m4-nofpu for SH2A builds Guenter Roeck (1): hwmon: (smsc47m192) Fix temperature limit and vrm write operations HIMANGI SARAOGI (1): parisc: Eliminate memset after alloc_bootmem_pages Hans Verkuil (2):
Re: Eudyptula Challenge (Task 10)
On Sun, Jul 27, 2014 at 08:56:38PM +0100, Liviu I. wrote: > Hello Kernel Developers! > > I've attached a small patch to fix a coding style problem and make checkpatch > happy, as part of challenge 10 of Eudyptula. > > Thank you > --- drivers/staging/lustre/lustre/ldlm/ldlm_extent.c.orig 2014-07-27 > 20:26:53.714161698 +0100 > +++ drivers/staging/lustre/lustre/ldlm/ldlm_extent.c 2014-07-27 > 20:27:50.410159692 +0100 > @@ -151,7 +151,8 @@ static inline int lock_mode_to_index(ldl > > LASSERT(mode != 0); > LASSERT(IS_PO2(mode)); > - for (index = -1; mode; index++, mode >>= 1) ; > + for (index = -1; mode; index++, mode >>= 1) > + ; > LASSERT(index < LCK_MODE_NUM); > return index; > } Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch does not have a Signed-off-by: line. Please read the kernel file, Documentation/SubmittingPatches and resend it after adding that line. Note, the line needs to be in the body of the email, before the patch, not at the bottom of the patch or in the email signature. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: lustre: linux-module: fix coding style issues.
On Sun, Jul 27, 2014 at 08:53:50PM -0700, Jessica Yu wrote: > Fixed some coding style issues. What coding style issues? Be specific, and explicit. Care to try it again? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Eudyptula Challenge (Task 10)
Hello Kernel Developers! I've attached a small patch to fix a coding style problem and make checkpatch happy, as part of challenge 10 of Eudyptula. Thank you --- drivers/staging/lustre/lustre/ldlm/ldlm_extent.c.orig 2014-07-27 20:26:53.714161698 +0100 +++ drivers/staging/lustre/lustre/ldlm/ldlm_extent.c2014-07-27 20:27:50.410159692 +0100 @@ -151,7 +151,8 @@ static inline int lock_mode_to_index(ldl LASSERT(mode != 0); LASSERT(IS_PO2(mode)); - for (index = -1; mode; index++, mode >>= 1) ; + for (index = -1; mode; index++, mode >>= 1) + ; LASSERT(index < LCK_MODE_NUM); return index; }
[PATCH] Staging: lustre: linux-module: fix coding style issues.
Fixed some coding style issues.
Signed-off-by: Jessica Yu
---
drivers/staging/lustre/lustre/libcfs/linux/linux-module.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
index ccadf65..de3c199 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-module.c
@@ -99,7 +99,7 @@ int libcfs_ioctl_popdata(void *arg, void *data, int size)
extern struct cfs_psdev_ops libcfs_psdev_ops;
static int
-libcfs_psdev_open(struct inode * inode, struct file * file)
+libcfs_psdev_open(struct inode *inode, struct file *file)
{
struct libcfs_device_userstate **pdu = NULL;
intrc = 0;
@@ -116,7 +116,7 @@ libcfs_psdev_open(struct inode * inode, struct file * file)
/* called when closing /dev/device */
static int
-libcfs_psdev_release(struct inode * inode, struct file * file)
+libcfs_psdev_release(struct inode *inode, struct file *file)
{
struct libcfs_device_userstate *pdu;
intrc = 0;
@@ -140,9 +140,9 @@ static long libcfs_ioctl(struct file *file,
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
- if ( _IOC_TYPE(cmd) != IOC_LIBCFS_TYPE ||
+ if (_IOC_TYPE(cmd) != IOC_LIBCFS_TYPE ||
_IOC_NR(cmd) < IOC_LIBCFS_MIN_NR ||
-_IOC_NR(cmd) > IOC_LIBCFS_MAX_NR ) {
+_IOC_NR(cmd) > IOC_LIBCFS_MAX_NR) {
CDEBUG(D_IOCTL, "invalid ioctl ( type %d, nr %d, size %d )\n",
_IOC_TYPE(cmd), _IOC_NR(cmd), _IOC_SIZE(cmd));
return (-EINVAL);
@@ -154,7 +154,7 @@ static long libcfs_ioctl(struct file *file,
if (!capable(CFS_CAP_SYS_BOOT))
return (-EPERM);
panic("debugctl-invoked panic");
- return (0);
+ return 0;
case IOC_LIBCFS_MEMHOG:
if (!capable(CFS_CAP_SYS_ADMIN))
return -EPERM;
@@ -167,10 +167,10 @@ static long libcfs_ioctl(struct file *file,
rc = libcfs_psdev_ops.p_ioctl(, cmd, (void *)arg);
else
rc = -EPERM;
- return (rc);
+ return rc;
}
-static struct file_operations libcfs_fops = {
+static const struct file_operations libcfs_fops = {
.unlocked_ioctl = libcfs_ioctl,
.open = libcfs_psdev_open,
.release= libcfs_psdev_release,
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
