Re: [PATCH v7 2/2] kvm: KVM_EOIFD, an eventfd for EOIs
On Mon, 2012-08-06 at 13:40 +0300, Avi Kivity wrote: > On 08/06/2012 01:38 PM, Avi Kivity wrote: > > > Regarding the implementation, instead of a linked list, would an array > > of counters parallel to the bitmap make it simpler? > > Or even, replace the bitmap with an array of counters. I'm not sure a counter array is what we're really after. That gives us reference counting for the irq source IDs, but not the key->gsi lookup. It also highlights another issue, that we have a limited set of source IDs. Looks like we have BITS_PER_LONG IDs, with two already used, one for the shared userspace ID and another for the PIT. How happy are we going to be with a limit of 62 level interrupts in use at one time? It's arguably a reasonable number since the most virtualization friendly devices (sr-iov VFs) don't even support this kind of interrupt. It's also very wasteful allocating an entire source ID for a single GSI within that source ID. PCI supports interrupts A, B, C, and D, which, in the most optimal config, each go to different GSIs. So we could theoretically be more efficient in our use and allocation of irq source IDs if we tracked use by the source ID, gsi pair. That probably makes it less practical to replace anything at the top level with a counter array. The key that we pass back is currently the actual source ID, but we don't specify what it is, so we could split it and have it encode a 16bit source ID plus 16 bit GSI. It could also be an idr entry. Michael, would the interface be more acceptable to you if we added separate ioctls to allocate and free some representation of an irq source ID, gsi pair? For instance, an ioctl might return an idr entry for an irq source ID/gsi object which would then be passed as a parameter in struct kvm_irqfd and struct kvm_eoifd so that the object representing the source id/gsi isn't magically freed on it's own. This would also allow us to deassign/close one end and reconfigure it later. Thanks, Alex -- 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] PM / Domains: fix early device initialization failure
On Thursday, August 09, 2012, Marek Szyprowski wrote: > dev_pm_get_subsys_data() returns 1 when a new object has been created, > what should not be considered as an error for pm_genpd_add_device(). > > Signed-off-by: Marek Szyprowski This has been reported twice already and there's a patch in linux-next to fix this issue. And your patch is incomplete. :-) Thanks, Rafael > --- > drivers/base/power/domain.c |9 - > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index ba3487c..6b61819 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -1323,9 +1323,16 @@ int __pm_genpd_add_device(struct generic_pm_domain > *genpd, struct device *dev, > } > > ret = dev_pm_get_subsys_data(dev); > - if (ret) > + > + if (ret < 0) > goto out; > > + /* > + * dev_pm_get_subsys_data() returns 1 when new object has been created > + */ > + if (ret == 1) > + ret = 0; > + > genpd->device_count++; > genpd->max_off_time_changed = 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/
Re: [BUG] perf: sharing of cpuctx between core and ibs PMU causes problems
On Thu, Aug 9, 2012 at 8:08 PM, Peter Zijlstra wrote: > On Thu, 2012-08-09 at 16:05 +0200, Stephane Eranian wrote: >> > uncore PMU does not have this issue because uncore_pmu->task_ctx_nr >> > is 'perf_invalid_context'. find_pmu_context() always return NULL in >> > that case. >> > >> Yes, I think IBS should do the same and that should fix the problem >> there too. Will try that. > > I'm afraid not, per-task profiling with uncore doesn't really make that > much sense. For IBS it does. > > We can't share a context with different PMUs, that'll totally mess up > the event scheduling. > > We'll have to grow perf_event_task_context with an extra context and > have IBS use that. Ok, I am fine with that. Don't know about to call it though. -- 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: [09/36] AArch64: Exception handling
Hi Catalin, Thanks for your response. On 08/09/2012 01:23 PM, Catalin Marinas wrote: > Hi Christopher, > > On Thu, Aug 09, 2012 at 06:05:36PM +0100, Christopher Covington wrote: >> On 01/-10/-28163 02:59 PM, Catalin Marinas wrote: >>> +/* >>> + * Exception vectors. >>> + */ >>> + .macro ventry label >>> + .align 7 >>> + b \label >>> + .endm >>> + >>> + .align 11 >>> +ENTRY(vectors) >>> + ventry el1_sync_invalid// Synchronous EL1t >>> + ventry el1_irq_invalid // IRQ EL1t >>> + ventry el1_fiq_invalid // FIQ EL1t >>> + ventry el1_error_invalid // Error EL1t >>> + >>> + ventry el1_sync// Synchronous EL1h >>> + ventry el1_irq // IRQ EL1h >>> + ventry el1_fiq_invalid // FIQ EL1h >>> + ventry el1_error_invalid // Error EL1h >>> + >>> + ventry el0_sync// Synchronous 64-bit EL0 >>> + ventry el0_irq // IRQ 64-bit EL0 >>> + ventry el0_fiq_invalid // FIQ 64-bit EL0 >>> + ventry el0_error_invalid // Error 64-bit EL0 >>> + >>> +#ifdef CONFIG_AARCH32_EMULATION >>> + ventry el0_sync_compat // Synchronous 32-bit EL0 >>> + ventry el0_irq_compat // IRQ 32-bit EL0 >>> + ventry el0_fiq_invalid_compat // FIQ 32-bit EL0 >>> + ventry el0_error_invalid_compat// Error 32-bit EL0 >>> +#else >>> + ventry el0_sync_invalid// Synchronous 32-bit EL0 >>> + ventry el0_irq_invalid // IRQ 32-bit EL0 >>> + ventry el0_fiq_invalid // FIQ 32-bit EL0 >>> + ventry el0_error_invalid // Error 32-bit EL0 >>> +#endif >>> +END(vectors) >>> + >>> +/* >>> + * Invalid mode handlers >>> + */ >>> + .macro inv_entry, el, reason, regsize = 64 >>> + kernel_entry el, \regsize >>> + mov x0, sp >>> + mov x1, #\reason >>> + mrs x2, esr_el1 >>> + b bad_mode >>> + .endm >> >> The code seems to indicate that the invalid mode handlers have >> different alignment requirements than the valid mode handlers, which >> puzzles me. > > I don't see any difference. The whole vector must be 2K aligned while > each individual entry is found every 128 bytes (to allow for more > instructions, though we only use a branch). > > The inv_entry macro (as the kernel_entry one) is used in code being > branched to from the vector and not inside the vector. Sorry to not be clearer. I meant this in relation to the handlers that the vectors branch to, rather than the vectors themselves. For example, an .align 6 directive is used for el0_irq, but not for el0_irq_invalid. >>> +el0_sync_invalid: >>> + inv_entry 0, BAD_SYNC >>> +ENDPROC(el0_sync_invalid) >> >> Plain labels, the ENTRY macro, the END macro and the ENDPROC macro are >> used variously throughout this file, and I wonder if a greater amount >> of consistency might be attainable. The description of the ENDPROC >> macro in include/linux/linkage.h makes me think its use might not be >> completely warranted in blocks of assembly that don't end with a >> return instruction. > > We use ENTRY only when we want to export the symbol as it contains the > .globl directive. The ENDPROC is used to mark a function and it's in > general useful for debugging information it generates. Does code that has no returning path, such as el0_sync_invalid, fully qualify as a function? On the flip side, it appears to me that el1_preempt does qualify and should get an ENDPROC. >>> + .align 6 >>> +el0_irq: >>> + kernel_entry 0 >>> +el0_irq_naked: >>> + disable_step x1 >>> + isb >>> + enable_dbg >>> +#ifdef CONFIG_TRACE_IRQFLAGS >>> + bl trace_hardirqs_off >>> +#endif >>> + get_thread_info tsk >>> +#ifdef CONFIG_PREEMPT >>> + ldr x24, [tsk, #TI_PREEMPT] // get preempt count >>> + add x23, x24, #1// increment it >>> + str x23, [tsk, #TI_PREEMPT] >>> +#endif >>> + irq_handler >>> +#ifdef CONFIG_PREEMPT >>> + ldr x0, [tsk, #TI_PREEMPT] >>> + str x24, [tsk, #TI_PREEMPT] >>> + cmp x0, x23 >>> + b.eq1f >>> + mov x1, #0 >>> + str x1, [x1]// BUG >> >> It looks like the error handling here isn't quite complete. > > We trigger a bug by storing to 0 and the kernel will panic, giving the > full trace. I don't think we can do more in terms of error handling > here. The approach is concise and clever. However, I think it sacrifices clarity to some extent. I worry that the top of the stack trace will be populated with extraneous data fault handling routines. Even if branching to do_mem_abort was ideal, I feel like getting there by way of the address translation hardware and yet another exception vector adds a number of unnecessary variables to that particular state transition. Perhaps branching
Re: [PATCH] [RFC] syscalls,x86: Add execveat() system call (v2)
On 08/01/2012 03:10 PM, Meredydd Luff wrote: > > +#ifndef sys_execveat > +asmlinkage long sys_execveat(int dfd, const char __user *filename, > + const char __user *const __user *argv, > + const char __user *const __user *envp, > + struct pt_regs *regs); > +#endif Should this have a flags argument for future extension? --Andy -- 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/7] perf hists: Separate out hist print functions
Em Mon, Aug 06, 2012 at 05:57:36PM +0900, Namhyung Kim escreveu:
> From: Namhyung Kim
>
> Separate out those functions into ui/hist.c. This is required for
> upcoming changes.
Isn't it better to further separate it by introducing the ui/stdio/
directory since these functions use fprintf?
- Arnaldo
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/Makefile| 4 +-
> tools/perf/ui/hist.c | 648 ++
> tools/perf/util/hist.c | 677
> ++---
> tools/perf/util/hist.h | 2 +
> 4 files changed, 670 insertions(+), 661 deletions(-)
> create mode 100644 tools/perf/ui/hist.c
>
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index 35655c3a7b7a..49cff288ac24 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -388,10 +388,10 @@ LIB_OBJS += $(OUTPUT)util/target.o
> LIB_OBJS += $(OUTPUT)util/rblist.o
> LIB_OBJS += $(OUTPUT)util/intlist.o
>
> -BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
> +LIB_OBJS += $(OUTPUT)ui/hist.o
>
> +BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
> BUILTIN_OBJS += $(OUTPUT)builtin-bench.o
> -
> # Benchmark modules
> BUILTIN_OBJS += $(OUTPUT)bench/sched-messaging.o
> BUILTIN_OBJS += $(OUTPUT)bench/sched-pipe.o
> diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
> new file mode 100644
> index ..b7936dc6271f
> --- /dev/null
> +++ b/tools/perf/ui/hist.c
> @@ -0,0 +1,648 @@
> +#include
> +#include
> +
> +#include "../util/util.h"
> +#include "../util/hist.h"
> +#include "../util/sort.h"
> +
> +
> +static size_t callchain__fprintf_left_margin(FILE *fp, int left_margin)
> +{
> + int i;
> + int ret = fprintf(fp, "");
> +
> + for (i = 0; i < left_margin; i++)
> + ret += fprintf(fp, " ");
> +
> + return ret;
> +}
> +
> +static size_t ipchain__fprintf_graph_line(FILE *fp, int depth, int
> depth_mask,
> + int left_margin)
> +{
> + int i;
> + size_t ret = callchain__fprintf_left_margin(fp, left_margin);
> +
> + for (i = 0; i < depth; i++)
> + if (depth_mask & (1 << i))
> + ret += fprintf(fp, "| ");
> + else
> + ret += fprintf(fp, " ");
> +
> + ret += fprintf(fp, "\n");
> +
> + return ret;
> +}
> +
> +static size_t ipchain__fprintf_graph(FILE *fp, struct callchain_list *chain,
> + int depth, int depth_mask, int period,
> + u64 total_samples, u64 hits,
> + int left_margin)
> +{
> + int i;
> + size_t ret = 0;
> +
> + ret += callchain__fprintf_left_margin(fp, left_margin);
> + for (i = 0; i < depth; i++) {
> + if (depth_mask & (1 << i))
> + ret += fprintf(fp, "|");
> + else
> + ret += fprintf(fp, " ");
> + if (!period && i == depth - 1) {
> + double percent;
> +
> + percent = hits * 100.0 / total_samples;
> + ret += percent_color_fprintf(fp, "--%2.2f%%-- ",
> percent);
> + } else
> + ret += fprintf(fp, "%s", " ");
> + }
> + if (chain->ms.sym)
> + ret += fprintf(fp, "%s\n", chain->ms.sym->name);
> + else
> + ret += fprintf(fp, "0x%0" PRIx64 "\n", chain->ip);
> +
> + return ret;
> +}
> +
> +static struct symbol *rem_sq_bracket;
> +static struct callchain_list rem_hits;
> +
> +static void init_rem_hits(void)
> +{
> + rem_sq_bracket = malloc(sizeof(*rem_sq_bracket) + 6);
> + if (!rem_sq_bracket) {
> + fprintf(stderr, "Not enough memory to display remaining
> hits\n");
> + return;
> + }
> +
> + strcpy(rem_sq_bracket->name, "[...]");
> + rem_hits.ms.sym = rem_sq_bracket;
> +}
> +
> +static size_t __callchain__fprintf_graph(FILE *fp, struct rb_root *root,
> + u64 total_samples, int depth,
> + int depth_mask, int left_margin)
> +{
> + struct rb_node *node, *next;
> + struct callchain_node *child;
> + struct callchain_list *chain;
> + int new_depth_mask = depth_mask;
> + u64 remaining;
> + size_t ret = 0;
> + int i;
> + uint entries_printed = 0;
> +
> + remaining = total_samples;
> +
> + node = rb_first(root);
> + while (node) {
> + u64 new_total;
> + u64 cumul;
> +
> + child = rb_entry(node, struct callchain_node, rb_node);
> + cumul = callchain_cumul_hits(child);
> + remaining -= cumul;
> +
> + /*
> + * The depth mask manages the output of pipes that show
> + * the depth. We don't want to keep the pipes of the current
> + * level for the last child of this depth.
> + * Except
[PATCH RESEND 0/4] device_cgroup: replace internally whitelist with exception list
The original model of device_cgroup is having a whitelist where all the allowed devices are listed. The problem with this approach is that is impossible to have the case of allowing everything but few devices. The reason for that lies in the way the whitelist is handled internally: since there's only a whitelist, the "all devices" entry would have to be removed and replaced by the entire list of possible devices but the ones that are being denied. Since dev_t is 32 bits long, representing the allowed devices as a bitfield is not memory efficient. This patch replaces the "whitelist" by a "exceptions" list and the default policy is kept as "deny_all" variable in dev_cgroup structure. The current interface determines that whenever "a" is written to devices.allow or devices.deny, the entry masking all devices will be added or removed, respectively. This behavior is kept and it's what will determine the default policy: # cat devices.list a *:* rwm # echo a >devices.deny # cat devices.list # echo a >devices.allow # cat devices.list a *:* rwm The interface is also preserved. For example, if one wants to block only access to /dev/null: # ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Jul 24 16:17 /dev/null # echo a >devices.allow # echo "c 1:3 rwm" >devices.deny # cat /dev/null cat: /dev/null: Operation not permitted # echo >/dev/null bash: /dev/null: Operation not permitted mknod /tmp/null c 1 3 mknod: â/tmp/nullâ: Operation not permitted # echo "c 1:3 r" >devices.allow # cat /dev/null # echo >/dev/null bash: /dev/null: Operation not permitted mknod /tmp/null c 1 3 mknod: â/tmp/nullâ: Operation not permitted # echo "c 1:3 rw" >devices.allow # echo >/dev/null # cat /dev/null # mknod /tmp/null c 1 3 mknod: â/tmp/nullâ: Operation not permitted # echo "c 1:3 rwm" >devices.allow # echo >/dev/null # cat /dev/null # mknod /tmp/null c 1 3 # device_cgroup.c | 371 1 file changed, 212 insertions(+), 159 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/
[PATCH RESEND 3/4] device_cgroup: convert device_cgroup internally to policy + exceptions
The original model of device_cgroup is having a whitelist where all the
allowed devices are listed. The problem with this approach is that is
impossible to have the case of allowing everything but few devices.
The reason for that lies in the way the whitelist is handled internally:
since there's only a whitelist, the "all devices" entry would have to be
removed and replaced by the entire list of possible devices but the ones
that are being denied. Since dev_t is 32 bits long, representing the allowed
devices as a bitfield is not memory efficient.
This patch replaces the "whitelist" by a "exceptions" list and the default
policy is kept as "deny_all" variable in dev_cgroup structure.
The current interface determines that whenever "a" is written to devices.allow
or devices.deny, the entry masking all devices will be added or removed,
respectively. This behavior is kept and it's what will determine the default
policy:
# cat devices.list
a *:* rwm
# echo a >devices.deny
# cat devices.list
# echo a >devices.allow
# cat devices.list
a *:* rwm
The interface is also preserved. For example, if one wants to block only access
to /dev/null:
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Jul 24 16:17 /dev/null
# echo a >devices.allow
# echo "c 1:3 rwm" >devices.deny
# cat /dev/null
cat: /dev/null: Operation not permitted
# echo >/dev/null
bash: /dev/null: Operation not permitted
mknod /tmp/null c 1 3
mknod: â/tmp/nullâ: Operation not permitted
# echo "c 1:3 r" >devices.allow
# cat /dev/null
# echo >/dev/null
bash: /dev/null: Operation not permitted
mknod /tmp/null c 1 3
mknod: â/tmp/nullâ: Operation not permitted
# echo "c 1:3 rw" >devices.allow
# echo >/dev/null
# cat /dev/null
# mknod /tmp/null c 1 3
mknod: â/tmp/nullâ: Operation not permitted
# echo "c 1:3 rwm" >devices.allow
# echo >/dev/null
# cat /dev/null
# mknod /tmp/null c 1 3
#
Note that I didn't rename the functions/variables in this patch, but in the
next one to make reviewing easier.
Signed-off-by: Aristeu Rozanski
---
security/device_cgroup.c | 228 +++
1 file changed, 132 insertions(+), 96 deletions(-)
Index: github/security/device_cgroup.c
===
--- github.orig/security/device_cgroup.c2012-07-24 17:58:42.984081909
-0400
+++ github/security/device_cgroup.c 2012-07-24 17:59:11.324823460 -0400
@@ -96,7 +96,6 @@
return -ENOMEM;
}
-/* Stupid prototype - don't bother combining existing entries */
/*
* called under devcgroup_mutex
*/
@@ -136,16 +135,13 @@
struct dev_whitelist_item *walk, *tmp;
list_for_each_entry_safe(walk, tmp, _cgroup->whitelist, list) {
- if (walk->type == DEV_ALL)
- goto remove;
if (walk->type != wh->type)
continue;
- if (walk->major != ~0 && walk->major != wh->major)
+ if (walk->major != wh->major)
continue;
- if (walk->minor != ~0 && walk->minor != wh->minor)
+ if (walk->minor != wh->minor)
continue;
-remove:
walk->access &= ~wh->access;
if (!walk->access) {
list_del_rcu(>list);
@@ -185,19 +181,9 @@
INIT_LIST_HEAD(_cgroup->whitelist);
parent_cgroup = cgroup->parent;
- if (parent_cgroup == NULL) {
- struct dev_whitelist_item *wh;
- wh = kmalloc(sizeof(*wh), GFP_KERNEL);
- if (!wh) {
- kfree(dev_cgroup);
- return ERR_PTR(-ENOMEM);
- }
- wh->minor = wh->major = ~0;
- wh->type = DEV_ALL;
- wh->access = ACC_MASK;
+ if (parent_cgroup == NULL)
dev_cgroup->deny_all = false;
- list_add(>list, _cgroup->whitelist);
- } else {
+ else {
parent_dev_cgroup = cgroup_to_devcgroup(parent_cgroup);
mutex_lock(_mutex);
ret = dev_whitelist_copy(_cgroup->whitelist,
@@ -268,33 +254,48 @@
char maj[MAJMINLEN], min[MAJMINLEN], acc[ACCLEN];
rcu_read_lock();
- list_for_each_entry_rcu(wh, >whitelist, list) {
- set_access(acc, wh->access);
- set_majmin(maj, wh->major);
- set_majmin(min, wh->minor);
- seq_printf(m, "%c %s:%s %s\n", type_to_char(wh->type),
+ /*
+* To preserve the compatibility:
+* - Only show the "all devices" when the default policy is to allow
+* - List the exceptions in case the default policy is to deny
+*
[PATCH RESEND 4/4] device_cgroup: rename whitelist to exception list
This patch replaces the "whitelist" usage in the code and comments and replace
them by exception list related information.
Signed-off-by: Aristeu Rozanski
---
security/device_cgroup.c | 198 +++
1 file changed, 99 insertions(+), 99 deletions(-)
Index: github/security/device_cgroup.c
===
--- github.orig/security/device_cgroup.c2012-07-24 17:50:14.0
-0400
+++ github/security/device_cgroup.c 2012-07-24 17:50:48.343663036 -0400
@@ -26,12 +26,12 @@
static DEFINE_MUTEX(devcgroup_mutex);
/*
- * whitelist locking rules:
+ * exception list locking rules:
* hold devcgroup_mutex for update/read.
* hold rcu_read_lock() for read.
*/
-struct dev_whitelist_item {
+struct dev_exception_item {
u32 major, minor;
short type;
short access;
@@ -41,7 +41,7 @@
struct dev_cgroup {
struct cgroup_subsys_state css;
- struct list_head whitelist;
+ struct list_head exceptions;
bool deny_all;
};
@@ -75,12 +75,12 @@
/*
* called under devcgroup_mutex
*/
-static int dev_whitelist_copy(struct list_head *dest, struct list_head *orig)
+static int dev_exceptions_copy(struct list_head *dest, struct list_head *orig)
{
- struct dev_whitelist_item *wh, *tmp, *new;
+ struct dev_exception_item *ex, *tmp, *new;
- list_for_each_entry(wh, orig, list) {
- new = kmemdup(wh, sizeof(*wh), GFP_KERNEL);
+ list_for_each_entry(ex, orig, list) {
+ new = kmemdup(ex, sizeof(*ex), GFP_KERNEL);
if (!new)
goto free_and_exit;
list_add_tail(>list, dest);
@@ -89,9 +89,9 @@
return 0;
free_and_exit:
- list_for_each_entry_safe(wh, tmp, dest, list) {
- list_del(>list);
- kfree(wh);
+ list_for_each_entry_safe(ex, tmp, dest, list) {
+ list_del(>list);
+ kfree(ex);
}
return -ENOMEM;
}
@@ -99,50 +99,50 @@
/*
* called under devcgroup_mutex
*/
-static int dev_whitelist_add(struct dev_cgroup *dev_cgroup,
- struct dev_whitelist_item *wh)
+static int dev_exception_add(struct dev_cgroup *dev_cgroup,
+struct dev_exception_item *ex)
{
- struct dev_whitelist_item *whcopy, *walk;
+ struct dev_exception_item *excopy, *walk;
- whcopy = kmemdup(wh, sizeof(*wh), GFP_KERNEL);
- if (!whcopy)
+ excopy = kmemdup(ex, sizeof(*ex), GFP_KERNEL);
+ if (!excopy)
return -ENOMEM;
- list_for_each_entry(walk, _cgroup->whitelist, list) {
- if (walk->type != wh->type)
+ list_for_each_entry(walk, _cgroup->exceptions, list) {
+ if (walk->type != ex->type)
continue;
- if (walk->major != wh->major)
+ if (walk->major != ex->major)
continue;
- if (walk->minor != wh->minor)
+ if (walk->minor != ex->minor)
continue;
- walk->access |= wh->access;
- kfree(whcopy);
- whcopy = NULL;
+ walk->access |= ex->access;
+ kfree(excopy);
+ excopy = NULL;
}
- if (whcopy != NULL)
- list_add_tail_rcu(>list, _cgroup->whitelist);
+ if (excopy != NULL)
+ list_add_tail_rcu(>list, _cgroup->exceptions);
return 0;
}
/*
* called under devcgroup_mutex
*/
-static void dev_whitelist_rm(struct dev_cgroup *dev_cgroup,
- struct dev_whitelist_item *wh)
+static void dev_exception_rm(struct dev_cgroup *dev_cgroup,
+struct dev_exception_item *ex)
{
- struct dev_whitelist_item *walk, *tmp;
+ struct dev_exception_item *walk, *tmp;
- list_for_each_entry_safe(walk, tmp, _cgroup->whitelist, list) {
- if (walk->type != wh->type)
+ list_for_each_entry_safe(walk, tmp, _cgroup->exceptions, list) {
+ if (walk->type != ex->type)
continue;
- if (walk->major != wh->major)
+ if (walk->major != ex->major)
continue;
- if (walk->minor != wh->minor)
+ if (walk->minor != ex->minor)
continue;
- walk->access &= ~wh->access;
+ walk->access &= ~ex->access;
if (!walk->access) {
list_del_rcu(>list);
kfree_rcu(walk, rcu);
@@ -151,18 +151,18 @@
}
/**
- * dev_whitelist_clean - frees all entries of the whitelist
- * @dev_cgroup: dev_cgroup with the whitelist to be cleaned
+ * dev_exception_clean - frees all entries of the exception list
+ * @dev_cgroup: dev_cgroup with the exception list to be cleaned
*
* called
[PATCH RESEND 2/4] device_cgroup: introduce dev_whitelist_clean()
This function cleans all the items in a whitelist and will be used by the next
patches.
Signed-off-by: Aristeu Rozanski
---
security/device_cgroup.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
Index: github/security/device_cgroup.c
===
--- github.orig/security/device_cgroup.c2012-07-24 17:16:00.085156162
-0400
+++ github/security/device_cgroup.c 2012-07-24 17:58:42.984081909 -0400
@@ -154,6 +154,22 @@
}
}
+/**
+ * dev_whitelist_clean - frees all entries of the whitelist
+ * @dev_cgroup: dev_cgroup with the whitelist to be cleaned
+ *
+ * called under devcgroup_mutex
+ */
+static void dev_whitelist_clean(struct dev_cgroup *dev_cgroup)
+{
+ struct dev_whitelist_item *wh, *tmp;
+
+ list_for_each_entry_safe(wh, tmp, _cgroup->whitelist, list) {
+ list_del(>list);
+ kfree(wh);
+ }
+}
+
/*
* called from kernel/cgroup.c with cgroup_lock() held.
*/
@@ -200,13 +216,9 @@
static void devcgroup_destroy(struct cgroup *cgroup)
{
struct dev_cgroup *dev_cgroup;
- struct dev_whitelist_item *wh, *tmp;
dev_cgroup = cgroup_to_devcgroup(cgroup);
- list_for_each_entry_safe(wh, tmp, _cgroup->whitelist, list) {
- list_del(>list);
- kfree(wh);
- }
+ dev_whitelist_clean(dev_cgroup);
kfree(dev_cgroup);
}
--
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 RESEND 1/4] device_cgroup: add "deny_all" in dev_cgroup structure
deny_all will determine if the default policy is to deny all device access
unless for the ones in the exception list.
This variable will be used in the next patches to convert device_cgroup
internally into a default policy + rules.
Signed-off-by: Aristeu Rozanski
---
security/device_cgroup.c |5 +
1 file changed, 5 insertions(+)
Index: github/security/device_cgroup.c
===
--- github.orig/security/device_cgroup.c2012-07-24 17:15:58.277108951
-0400
+++ github/security/device_cgroup.c 2012-07-24 17:16:00.085156162 -0400
@@ -42,6 +42,7 @@
struct dev_cgroup {
struct cgroup_subsys_state css;
struct list_head whitelist;
+ bool deny_all;
};
static inline struct dev_cgroup *css_to_devcgroup(struct cgroup_subsys_state
*s)
@@ -178,12 +179,14 @@
wh->minor = wh->major = ~0;
wh->type = DEV_ALL;
wh->access = ACC_MASK;
+ dev_cgroup->deny_all = false;
list_add(>list, _cgroup->whitelist);
} else {
parent_dev_cgroup = cgroup_to_devcgroup(parent_cgroup);
mutex_lock(_mutex);
ret = dev_whitelist_copy(_cgroup->whitelist,
_dev_cgroup->whitelist);
+ dev_cgroup->deny_all = parent_dev_cgroup->deny_all;
mutex_unlock(_mutex);
if (ret) {
kfree(dev_cgroup);
@@ -409,9 +412,11 @@
case DEVCG_ALLOW:
if (!parent_has_perm(devcgroup, ))
return -EPERM;
+ devcgroup->deny_all = false;
return dev_whitelist_add(devcgroup, );
case DEVCG_DENY:
dev_whitelist_rm(devcgroup, );
+ devcgroup->deny_all = true;
break;
default:
return -EINVAL;
--
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/5] [RFC] Add volatile range management code
On 08/09/2012 02:46 AM, Michel Lespinasse wrote:
On Fri, Jul 27, 2012 at 8:57 PM, John Stultz wrote:
v5:
* Drop intervaltree for prio_tree usage per Michel &
Dmitry's suggestions.
Actually, I believe the ranges you need to track are non-overlapping, correct ?
Correct. Any overlapping range is coalesced.
If that is the case, a simple rbtree, sorted by start-of-range
address, would work best.
(I am trying to remove prio_tree users... :)
Sigh. Sure. Although I've blown with the wind on a number of different
approaches for storing the ranges. I'm not particularly passionate about
it, but the continual conflicting suggestions are a slight frustration. :)
+ /* First, find any existing intervals that overlap */
+ prio_tree_iter_init(, root, start, end);
Note that prio tree iterations take intervals as [start; last] not [start; end[
So if you want to stick with prio trees, you would have to use end-1 here.
Thanks! I think I hit this off-by-one issue in my testing, but fixed it
on the backend w/ :
modify_range(>i_data, start, end-1, _nonvolatile_page);
Clearly fixing it at the start instead of papering over it is better.
+ node = prio_tree_next();
+ while (node) {
I'm confused, I don't think you ever expect more than one range to
match, do you ???
So yea. If you already have two ranges (0-5),(10-15) and then add range
(0-20) we need to coalesce the two existing ranges into the new one.
This is far from a complete code review, but I just wanted to point
out a couple details that jumped to me first. I am afraid I am missing
some of the background about how the feature is to be used to really
dig into the rest of the changes at this point :/
Well, I really appreciate any feedback here.
thanks
-john
--
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] net: add new QCA alx ethernet driver
On Thu, Aug 9, 2012 at 8:28 AM, Steven Rostedt wrote: > On Thu, 2012-08-09 at 08:22 -0700, Joe Perches wrote: > >> Yes, I sent signed-off patches to their original RFC submission >> (back last year?). And that is why your SOB was kept. >> To me, this single large patch is like a >> snapshot of a git tree and not all contributors to that git >> tree should be noted as signers of the entire thing. I am not sure we really ever addressed this technical difference and from what I have seen we always run into this question on new driver submissions. Entity x goes on and posts driver joojoo-1, and we some folks in the community may merge such patch onto their tree and edit the driver and send some of their own changes and improvements to the developers / mailing list. Typically if the patches sent had a SOB tag the right thing to due given the legal implications of the Developer's Certificate of Origin is to add those SOBs to the new driver submission if company x goes on and posts joojoo-2.. but... > Ouch, that looks like we are losing all history. Agreed! It'd be best instead to have such changes as part of a linear history somewhere so maybe what would be right prior to inclusion upstream is for such patches to be merged on an external github tree or wherever to be able to keep record of the submissions done during development. Then upon submission to the Linux kernel again as joojoo-2 instead of joojoo-1 company x would simply provide their own SOB, and the record of the previous SOBs would be kept on the forked git tree. Whether or not it is required to have the SOB tog of previous patch submitters is not clear but to me its not necessary if you have a record somewhere that they were submitted and merged in some other tree. The mailing list alone may serve as a good place holder for this information as well so a separate tree may not be required. So -- are we OK to *not* include SOBs of evolutions sent to developers of joojoo-1 when company x submits joojoo-2 so long as those patches were sent publicly or a record is kept somewhere ? > One large patch should not be submitted. If it was developed in steps, > then it is best to show those steps when they are incorporated into the > Linux repository. Sure, but at times some changes are asked after a submission of joojoo-1, and at times this may be ongoing until maybe even joojoo-10, before we are happy to merge it upstream. Luis -- 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: linux-next: Tree for Aug 9 (staging/csr)
On 08/08/2012 08:13 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20120807: > (on i386) ERROR: "register_inetaddr_notifier" [drivers/staging/csr/csr_wifi.ko] undefined! ERROR: "unregister_inetaddr_notifier" [drivers/staging/csr/csr_wifi.ko] undefined! when CONFIG_INET is not enabled. CSR_WIFI probably should depend on INET. -- ~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 v5 03/12] KVM: introduce gfn_to_pfn_memslot_atomic
On Tue, Aug 07, 2012 at 05:49:36PM +0800, Xiao Guangrong wrote: > It can instead of hva_to_pfn_atomic > > Signed-off-by: Xiao Guangrong > --- > arch/x86/kvm/mmu.c |5 + > include/linux/kvm_host.h |3 ++- > virt/kvm/kvm_main.c | 14 -- > 3 files changed, 11 insertions(+), 11 deletions(-) What if someone needs gfn_to_hva_memslot in the future, which is not unlikely? -- 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] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function
On Thu, 9 Aug 2012, Shuah Khan wrote: > Moving these checks into kmem_cache_sanity_check() would mean return > path handling will change. The first block of sanity checks for name, > and size etc. are done before holding the slab_mutex and the second > block that checks the slab lists is done after holding the mutex. > Depending on which one fails, return handling is going to be different > in that if second block fails, mutex needs to be unlocked and when the > first block fails, there is no need to do that. Nothing that is too > complex to solve, just something that needs to be handled. Right. The taking of the mutex etc is not depending on the parameters at all. So its possible. Its rather simple. > Comments, thoughts on > > 1. just remove size from kmem_cache_sanity_check() parameters > or > 2. move first block sanity checks into kmem_cache_sanity_check() > > Personally I prefer the first option to avoid complexity in return path > handling. Would like to hear what others think. We already have to deal with the return path handling for other failure cases. -- 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] Documentation : hypercalls
On Tue, Aug 07, 2012 at 01:09:46PM +0530, Raghavendra K T wrote: > This is the hypercall documentation patch series > First patch covers KVM specific hypercall information. > > second patch is has typo fix for vmcall instruction > comment in kvm_para.h > > Third patch includes a veryful documentation on PowerPC > hypercalls originally written by Alex > > Changes since initial post: > - Added hypercall ABI (Peter) > - made KVM_HC_VAPIC_POLL_IRQ active explicitly (Randy) > - Changed vmrun/vmmrun ==> vmcall/vmmcall (Marcelo) > - use Linux KVM hypercall instead of ABI (Marcelo) > - correct PowerPC typo (Alex) > - Remove value field (Alex) > > Raghavendra K T (2): > Documentation/kvm : Add documentation on hypercalls > Documentation/header : Correct vmrun to vmcall typo > > Alexander Graf (1) : > Documentation/ppc: Add ppc hypercall documentation > > Documentation/virtual/kvm/hypercalls.txt | 66 > ++ > Documentation/virtual/kvm/ppc-pv.txt | 22 ++ > arch/x86/include/asm/kvm_para.h |2 +- > 3 files changed, 89 insertions(+), 1 deletions(-) ACK -- 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 v5 02/12] KVM: hide KVM_MEMSLOT_INVALID from userspace
On Tue, Aug 07, 2012 at 05:48:49PM +0800, Xiao Guangrong wrote:
> Quote Avi's comment:
> | KVM_MEMSLOT_INVALID is actually an internal symbol, not used by
> | userspace. Please move it to kvm_host.h.
>
> Also, move KVM_MEMSLOT_INVALID to the highest bit
>
> Signed-off-by: Xiao Guangrong
> ---
> include/linux/kvm.h |1 -
> include/linux/kvm_host.h |2 ++
> 2 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index 2ce09aa..dc3aa2a 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -103,7 +103,6 @@ struct kvm_userspace_memory_region {
>
> /* for kvm_memory_region::flags */
> #define KVM_MEM_LOG_DIRTY_PAGES 1UL
> -#define KVM_MEMSLOT_INVALID (1UL << 1)
>
> /* for KVM_IRQ_LINE */
> struct kvm_irq_level {
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d2b897e..4c2da5a 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -35,6 +35,8 @@
> #define KVM_MMIO_SIZE 8
> #endif
>
> +#define KVM_MEMSLOT_INVALID (1UL << 31)
> +
> /*
> * If we support unaligned MMIO, at most one fragment will be split into two:
> */
Please document which range is for userspace visible flags, which range
is reserved. Mention that in both headers, point to each other
("userspace definitions are there" / "internal definitions are there").
16/16 bits for each should be fine.
--
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/3] perf tools: Initial bash completion support
Em Thu, Aug 09, 2012 at 07:27:06PM +0100, Alan Cox escreveu: > > > 3rd patch should fix this. > > > > Huh? The problem is not /etc/bash_completion.d/ not existing, it exists, > > its just that I'm not using sudo nor installing as root, this new bash > > completion file is the only one that is being installed on the root > > filesystem, all others are in ~acme/ > > And even with permissions it might not have the right security labels on > a well secured box. > > It's a neat little script (or once its been properly security audited > will be) but IMHO it belongs in the distro bash script packages. Yeah, I think we can keep it in the kernel sources and then send new versions to the bash-completion-de...@lists.alioth.debian.org guys. To test I just did: ln -s ~/etc/bash_completion.d/perf ~/.bash_completion Frédéric, I merged your patches as-is and pushed them to my perf/core branch, thanks! - Arnaldo -- 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] regulator: tps6586x: add support for SYS rail
On Thu, Aug 09, 2012 at 11:10:58AM -0600, Stephen Warren wrote: > Sorry to bug people, but is everyone OK with this patch? I'm holding off > checking in the Tegra-side device tree changes that add regulators until > this patch is checked in (or at least approved) to make sure the Tegra > .dts patches don't need any more changes. I decided to go ahead and apply without Samuel's review since the MFD changes are very small but in general four days is a bit of a fast turnaround for most things... -- 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] Documentation/pinctrl.txt: Fix some misspelled macros
Signed-off-by: Daniel Mack
---
Documentation/pinctrl.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index e40f4b4..1479aca 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -840,9 +840,9 @@ static unsigned long i2c_pin_configs[] = {
static struct pinctrl_map __initdata mapping[] = {
PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
"i2c0", "i2c0"),
- PIN_MAP_MUX_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT,
"pinctrl-foo", "i2c0", i2c_grp_configs),
- PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT,
"pinctrl-foo", "i2c0scl", i2c_pin_configs),
- PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT,
"pinctrl-foo", "i2c0sda", i2c_pin_configs),
+ PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT,
"pinctrl-foo", "i2c0", i2c_grp_configs),
+ PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
"i2c0scl", i2c_pin_configs),
+ PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
"i2c0sda", i2c_pin_configs),
};
Finally, some devices expect the mapping table to contain certain specific
--
1.7.11.2
--
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] regulator: core: request only valid gpio pins for regulator enable
On Thu, Aug 09, 2012 at 04:33:00PM +0200, Marek Szyprowski wrote:
> Commit 65f735082de3 ("regulator: core: Add core support for GPIO controlled
> enable lines") introduced enable gpio entry in regulator configuration
> structure. Some drivers use '-1' as a placeholder for marking that such
> gpio line is not available, because '0' is considered as a valid gpio
> number. This patch fixes initialization of such drivers (like MAX8952
> on UniversalC210 board), when '-1' is provided as enable gpio pin in the
> regulator's platform data.
Applied, 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/
Re: [PATCH] net: add new QCA alx ethernet driver
On Thu, 2012-08-09 at 11:28 -0400, Steven Rostedt wrote: > On Thu, 2012-08-09 at 08:22 -0700, Joe Perches wrote: > > > Yes, I sent signed-off patches to their original RFC submission > > (back last year?). To me, this single large patch is like a > > snapshot of a git tree and not all contributors to that git > > tree should be noted as signers of the entire thing. > > Ouch, that looks like we are losing all history. > > One large patch should not be submitted. If it was developed in steps, > then it is best to show those steps when they are incorporated into the > Linux repository. > > Sure, the patches may be reworked and folded together where appropriate, > but when I read "this single large patch is like a snapshot of a git > tree", that right there is a red flag. I don't think this has ever been a requirement for new drivers. The alterations to the description of atl1c ought to be broken out as a separate patch, though. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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] xconfig: Display dependency values in debug_info
On 12-08-07 12:55 PM, Randy Dunlap wrote: > In Kconfig language, is "" the same as 'n' ? > If so, I'm OK with your proposal above. > So a colleague of mine tested this and came up with a conclusion that expressions in Kconfig can only deal with boolean or tristate operands and no casting is made with strings. Using any string operand as part of a boolean expression is simply a type error and Kconfig probably marks such operand as 'n', regardless of its value. -- 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] exofs: check for allocation failure in uri_store()
On 8/8/12 10:02 AM, Alexey Khoroshilov wrote:
> There is no memory allocation failure check in uri_store().
> That can lead to NULL pointer dereference.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> ---
> fs/exofs/sys.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/fs/exofs/sys.c b/fs/exofs/sys.c
> index 5a7b691..1b4f2f9 100644
> --- a/fs/exofs/sys.c
> +++ b/fs/exofs/sys.c
> @@ -80,8 +80,13 @@ static ssize_t uri_show(struct exofs_dev *edp, char *buf)
>
> static ssize_t uri_store(struct exofs_dev *edp, const char *buf, size_t len)
> {
> + uint8_t *new_uri;
> +
> edp->urilen = strlen(buf) + 1;
> - edp->uri = krealloc(edp->uri, edp->urilen, GFP_KERNEL);
> + new_uri = krealloc(edp->uri, edp->urilen, GFP_KERNEL);
> + if (new_uri == NULL)
> + return -ENOMEM;
> + edp->uri = new_uri;
> strncpy(edp->uri, buf, edp->urilen);
> return edp->urilen;
> }
Ack-by : Sachin Bhamare
--
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/4] promote zcache from staging
On 08/07/2012 03:23 PM, Seth Jennings wrote: > On 07/27/2012 01:18 PM, Seth Jennings wrote: >> Some benchmarking numbers demonstrating the I/O saving that can be had >> with zcache: >> >> https://lkml.org/lkml/2012/3/22/383 > > There was concern that kernel changes external to zcache since v3.3 may > have mitigated the benefit of zcache. So I re-ran my kernel building > benchmark and confirmed that zcache is still providing I/O and runtime > savings. There was a request made to test with even greater memory pressure to demonstrate that, at some unknown point, zcache doesn't have real problems. So I continued out to 32 threads: N=4..20 is the same data as before except for the pswpin values. I found a mistake in the way I computed pswpin that changed those values slightly. However, this didn't change the overall trend. I also inverted the %change fields since it is a percent change vs the normal case. I/O (in pages) normal zcache change N pswpin pswpout majflt I/O sum pswpin pswpout majflt I/O sum %I/O 4 0 2 211621180 0 212521250% 8 0 575 224428190 4 22192223-21% 12 19794038322692431269251938717659-17% 16 21568 47278 942678272 777015598 937232740 -58% 20 50307 127797 15039 193143 20224 40634 17975 78833 -59% 24 186278 364809 45052 596139 47406 90489 30877 168772 -72% 28 274734 777815 53112 1105661 134981 307346 63480 505807 -54% 32 988530 2002087 168662 3159279 324801 723385 140288 1188474 -62% Runtime (in seconds) N normal zcache %change 4 126 127 1% 8 124 124 0% 12 131 133 2% 16 189 156 -17% 20 261 235 -10% 24 513 288 -44% 28 556 434 -22% 32 1463745 -49% %CPU utilization (out of 400% on 4 cpus) N normal zcache %change 4 254 253 0% 8 261 263 1% 12 250 248 -1% 16 173 211 22% 20 124 140 13% 24 64 114 78% 28 59 76 29% 32 23 45 96% The ~60% I/O savings holds even out to 32 threads, at which point the non-zcache case has 12GB of I/O and is taking 12x longer to complete. Additionally, the runtime savings increases significantly beyond 20 threads, even though the absolute runtime is suboptimal due to the extreme memory pressure. Seth -- 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 00/22] mop500 related Audio reorganisation and fixups
On Thu, Aug 09, 2012 at 04:47:26PM +0100, Lee Jones wrote: > Another fine instalment of Audio fixes and Device Tree enablement > surrounding the mop500 sound driver. Hopefully containing all of > the recommendations suggested by Mark Brown. Can we have some review of this from the ARM side please? It's pretty big... -- 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/5][RFC] Fallocate Volatile Ranges v6
On 08/09/2012 02:28 AM, Michel Lespinasse wrote: Hi John, On Fri, Jul 27, 2012 at 8:57 PM, John Stultz wrote: So after not getting too much positive feedback on my last attempt at trying to use a non-shrinker method for managing & purging volatile ranges, I decided I'd go ahead and try to implement something along Minchan's ERECLAIM LRU list idea. Agree that there hasn't been much feedback from MM folks yet - sorry about that :/ I think one issue might be that most people don't have a good background on how the feature is intended to be used, and it is very difficult to comment meaningfully without that. As for myself, I have been wondering: - Why the feature needs to be on a per-range basis, rather than per-file. Is this simply to make it easier to transition the android use case from whatever they are doing right now, or is it that the object boundaries within a file can't be known in advance, and thus one wouldn't know how to split objects accross different files ? Or could it be that some of the objects would be small (less than a page) so space use would be inefficient if they were placed in different files ? Or just that there would be too many files for efficient management ? For me, keeping the feature per-range instead of something like per-file is in order to be able to support Android's existing use case. As to why Android uses per-range instead of per file, Arve or someone from the Android team could probably better answer, but I can theorize. In discussions with the Android guys, they've mentioned ashmem's primary goal was to basically provide atomically unlinked tmpfs fds for sharing memory, and memory unpinning was a follow on feature. So I suspect that ranges fit better into their existing model of using a mmapped fd to share data between two processes. Instead of creating a new tmpfs file and sharing the fd for each object, they're able to create a one shared mapping, which can be effectively resized w/ unpinning, for multiple objects. Another use case where ranges would be beneficial might be for where there's a large single object that might not all be in use at one time. For example, a very large web page, where you have a limited view onto it. Having the rest of the page rendered so you can quickly scroll without re-rendering would be nice, but under memory pressure it could effectively throw out the non-visible portions. Further, one additional reason I have for not having the volatile attribute be per-file, is that I have my eye on allowing volatile ranges to be set on anonymous heap memory via something like madvise() in the future, which would be an easier api to use if you're not sharing data via mmapped tmpfs files, but wouldn't be possible if this was a file attribute rather then a range of pages. - What are the desired semantics for the volatile objects. Can the objects be accessed while they are marked as volatile, or do they have to get unmarked first ? So accessing a volatile page before marking it non-volatile can produce undefined behavior. You could get the data that was there, or you could get empty pages. The expectation is that pages are unmarked before being accessed, so one can know if the data was lost or not. I'm open to other suggestions here, if folks think we should SIGSEGV on accesses to volatile pages. However, I don't know how setting that up and tearing it down on each mark_volatile/unmark_volatile might affect performance. Is it really the case that we always want to reclaim from volatile objects first, before any other kind of caches we might have ? This sounds like a very strong hint, and I think I would be more comfortable with something more subtle if that's possible. So the current Android ashmem implementation uses a shrinker, which isn't necessarily called before any other caches are freed. So, I don't think its a strong hint, but it just seems somewhat intuitive to me that we should free effectively "user-donated" pages before freeing other system caches. But that's not something the interface necessarily defines or requires. Also, if we have several volatile objects to reclaim from, is it desirable to reclaim from the one that's been marked volatile the longest or does it make no difference ? While I don't think its strictly necessary, I do think LRU order purging is important from the least-surprise angle. Since ranges marked volatile should not be touched until they are marked non-volatile, it follows normal expectations that recently touched data is likely to be faster then data that has not been accessed for some time. Reasonable exceptions would be situations like NUMA systems where pressure on one node forces purging volatile pages in a non-global-lru order. So probably not critical, but I think useful to try to preserve. When an object is marked volatile, would it be sufficient to ensure it gets placed on the inactive list (maybe with the referenced bit
[PATCH 5/6] x86/mce: Make cmci_discover() quiet
cmci_discover() works out which machine check banks support CMCI, and
which of those are shared by multiple logical processors. It uses this
information to ensure that exactly one cpu is designated the owner of
each bank so that when interrupts are broadcast to multiple cpus, only one
of them will look in a shared bank to log the error and clear the bank.
At boot time cmci_discover() performs this task silently. But during
certain cpu hotplug operations it prints out a set of summary lines
like this:
CPU 35 MCA banks CMCI:0 CMCI:1 CMCI:3 CMCI:5 CMCI:6 CMCI:7 CMCI:8 CMCI:9
CMCI:10 CMCI:11
CPU 1 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 39 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 38 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 32 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 37 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 36 MCA banks CMCI:0 CMCI:1 CMCI:3
CPU 34 MCA banks CMCI:0 CMCI:1 CMCI:3
The value of these messages seems very low. A user might painstakingly
cross-check against the data sheet for a processor to ensure that all
CMCI supported banks are correctly reported, but this seems improbable.
If users really wanted to do this, we should print the information at
boot time too.
Remove the messages.
Signed-off-by: Tony Luck
---
Gong pointed out to me offline that my previous "patch 5/6" would not
do what I said it did in the case where a processor is taken offline
during a CMCI storm. We'd have a topology change, but would suppress
the bank attribution messages when the storm ended. I took a longer
look at the messages, and decided that we can live without them.
arch/x86/kernel/cpu/mcheck/mce_intel.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index 38e49bc..59648e4 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -65,24 +65,15 @@ static void intel_threshold_interrupt(void)
mce_notify_irq();
}
-static void print_update(char *type, int *hdr, int num)
-{
- if (*hdr == 0)
- printk(KERN_INFO "CPU %d MCA banks", smp_processor_id());
- *hdr = 1;
- printk(KERN_CONT " %s:%d", type, num);
-}
-
/*
* Enable CMCI (Corrected Machine Check Interrupt) for available MCE banks
* on this CPU. Use the algorithm recommended in the SDM to discover shared
* banks.
*/
-static void cmci_discover(int banks, int boot)
+static void cmci_discover(int banks)
{
unsigned long *owned = (void *)&__get_cpu_var(mce_banks_owned);
unsigned long flags;
- int hdr = 0;
int i;
raw_spin_lock_irqsave(_discover_lock, flags);
@@ -96,8 +87,7 @@ static void cmci_discover(int banks, int boot)
/* Already owned by someone else? */
if (val & MCI_CTL2_CMCI_EN) {
- if (test_and_clear_bit(i, owned) && !boot)
- print_update("SHD", , i);
+ clear_bit(i, owned);
__clear_bit(i, __get_cpu_var(mce_poll_banks));
continue;
}
@@ -109,16 +99,13 @@ static void cmci_discover(int banks, int boot)
/* Did the enable bit stick? -- the bank supports CMCI */
if (val & MCI_CTL2_CMCI_EN) {
- if (!test_and_set_bit(i, owned) && !boot)
- print_update("CMCI", , i);
+ set_bit(i, owned);
__clear_bit(i, __get_cpu_var(mce_poll_banks));
} else {
WARN_ON(!test_bit(i, __get_cpu_var(mce_poll_banks)));
}
}
raw_spin_unlock_irqrestore(_discover_lock, flags);
- if (hdr)
- printk(KERN_CONT "\n");
}
/*
@@ -186,7 +173,7 @@ void cmci_rediscover(int dying)
continue;
/* Recheck banks in case CPUs don't all have the same */
if (cmci_supported())
- cmci_discover(banks, 0);
+ cmci_discover(banks);
}
set_cpus_allowed_ptr(current, old);
@@ -200,7 +187,7 @@ void cmci_reenable(void)
{
int banks;
if (cmci_supported())
- cmci_discover(banks, 0);
+ cmci_discover(banks);
}
static void intel_init_cmci(void)
@@ -211,7 +198,7 @@ static void intel_init_cmci(void)
return;
mce_threshold_vector = intel_threshold_interrupt;
- cmci_discover(banks, 1);
+ cmci_discover(banks);
/*
* For CPU #0 this runs with still disabled APIC, but that's
* ok because only the vector is set up. We still do another
--
1.7.10.2.552.gaa3bb87
--
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
Re: PROBLEM: snd_hda_intel bug during boot
If you can collect complete dmesg logs from the working kernel and the broken kernel and post them, the differences might have a clue. You might also collect /proc/iomem and "lspci -vv" for both cases while you're at it. On Wed, Aug 8, 2012 at 10:38 PM, Alexei Kornienko wrote: > Hi, > > Yes it used to work with 2.6 kernel. > Ok I will do a bisect and try to find the source of the problem. > I'll notify you if I'll find something but don't expect it to be fast > cause the problem happens on my home laptop (pretty old and rusty :) ) > and I also have a lot of other stuff to do. > > Regards, > Alexei > > 2012/8/8 Jesper Juhl : >> On Wed, 8 Aug 2012, Jesper Juhl wrote: >> >>> On Wed, 8 Aug 2012, Alexei Kornienko wrote: >>> >>> > Seems like I have a bug in audio driver on my laptop. Cause of this I >>> > don't have any sound card detected. >>> > Please find more details below: >>> > >>> > ** Version: >>> > Linux version 3.2.0-29-generic-pae (buildd@roseapple) (gcc version >>> > 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #46-Ubuntu SMP Fri Jul 27 >>> > 17:25:43 UTC 2012 >>> > >>> Ok, so I openly admit that I have no clue as to what your problem might >>> be. But, one thing I do know is that, a *lot* has changed since the 3.2 >>> kernel you are running and the most recent stable (3.5) kernel. So, >>> perhaps you could test the 3.5 kernel and tell us if you still see the >>> problem with that one or not? >>> If you are feeling adventurous you could also try a snapshot of the latest >>> Linus (to become 3.6) kernel and tell us your experiences with that...? >>> >> Also, if this used to work with an older kernel, then it would probably >> be helpful if you could do a "git bisect" between the older (working) >> kernel version and your current (broken) kernel version in order to zoom >> in on the commit that broke things for you. >> >> -- >> Jesper Juhlhttp://www.chaosbits.net/ >> Don't top-post http://www.catb.org/jargon/html/T/top-post.html >> Plain text mails only, please. >> > -- > 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 v2 06/10] ARM: davinci: don't use broken ntosd2_init_i2c
Hi Arnd, On 8/9/2012 1:30 PM, Arnd Bergmann wrote: > On second thought, there is probably no use in keeping the broken function > around, and we can just kill it off. If someone wants to add an i2c > device to the bus, they can always add the init code back as well. > > 8<- > Subject: ARM: davinci: don't use broken ntosd2_init_i2c > > ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to > be populated with at least one member. gcc correctly warns about > the out-of-bounds access here. > > Since this can not possibly work, it's better to disable i2c > support entirely on this board. > > Without this patch, building davinci_all_defconfig results in: > > arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init': > arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is > above array bounds [-Warray-bounds] > > Signed-off-by: Arnd Bergmann > Cc: Kevin Hilman > Cc: Sekhar Nori > Cc: Andrey Porodko Acked-by: Sekhar Nori Thanks, Sekhar -- 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/3] perf tools: Initial bash completion support
> > 3rd patch should fix this. > > Huh? The problem is not /etc/bash_completion.d/ not existing, it exists, > its just that I'm not using sudo nor installing as root, this new bash > completion file is the only one that is being installed on the root > filesystem, all others are in ~acme/ And even with permissions it might not have the right security labels on a well secured box. It's a neat little script (or once its been properly security audited will be) but IMHO it belongs in the distro bash script packages. Alan -- 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: RFC: mutex: hung tasks on SMP platforms with asm-generic/mutex-xchg.h
On Thu, Aug 09, 2012 at 07:09:02PM +0100, Nicolas Pitre wrote:
> On Thu, 9 Aug 2012, Will Deacon wrote:
> > On Thu, Aug 09, 2012 at 05:57:33PM +0100, Nicolas Pitre wrote:
> > > On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> > > diff --git a/include/asm-generic/mutex-xchg.h
> > > b/include/asm-generic/mutex-xchg.h
> > > index 580a6d35c7..44a66c99c8 100644
> > > --- a/include/asm-generic/mutex-xchg.h
> > > +++ b/include/asm-generic/mutex-xchg.h
> > > @@ -25,8 +25,11 @@
> > > static inline void
> > > __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
> > > {
> > > - if (unlikely(atomic_xchg(count, 0) != 1))
> > > - fail_fn(count);
> > > + if (unlikely(atomic_xchg(count, 0) != 1)) {
> > > + /* Mark lock contention explicitly */
> > > + if (likely(atomic_xchg(count, -1) != 1))
> > > + fail_fn(count);
> > > + }
> > > }
> > >
> > > /**
> >
> > Doesn't this mean that we're no longer just swapping 0 for a 0 if the lock
> > was taken, therefore needlessly sending the current owner down the slowpath
> > on unlock?
>
> If the lock was taken, this means the count was either 0 or -1. If it
> was 1 then we just put a 0 there and we own it. But if the cound was 0
> then we should store -1 instead, which is what the inner xchg does. If
> the count was already -1 then we store -1 back. That more closely mimic
> what the atomic dec does which is what we want.
Ok, I just wasn't sure that marking the lock contended was required when it
was previously locked, given that we'll drop into spinning on the owner
anyway.
I'll add a commit message to the above and re-post if that's ok?
Will
--
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: [RFC PATCH 0/5] Improve hugepage allocation success rates under load V3
On 08/09/2012 07:49 AM, Mel Gorman wrote: Changelog since V2 o Capture !MIGRATE_MOVABLE pages where possible o Document the treatment of MIGRATE_MOVABLE pages while capturing o Expand changelogs Changelog since V1 o Dropped kswapd related patch, basically a no-op and regresses if fixed (minchan) o Expanded changelogs a little Allocation success rates have been far lower since 3.4 due to commit [fe2c2a10: vmscan: reclaim at order 0 when compaction is enabled]. This commit was introduced for good reasons and it was known in advance that the success rates would suffer but it was justified on the grounds that the high allocation success rates were achieved by aggressive reclaim. Success rates are expected to suffer even more in 3.6 due to commit [7db8889a: mm: have order> 0 compaction start off where it left] which testing has shown to severely reduce allocation success rates under load - to 0% in one case. There is a proposed change to that patch in this series and it would be ideal if Jim Schutt could retest the workload that led to commit [7db8889a: mm: have order> 0 compaction start off where it left]. On my first test of this patch series on top of 3.5, I ran into an instance of what I think is the sort of thing that patch 4/5 was fixing. Here's what vmstat had to say during that period: -- 2012-08-09 11:58:04.107-06:00 vmstat -w 4 16 procs ---memory-- ---swap-- -io --system-- -cpu--- r b swpd free buff cache si sobibo in cs us sy id wa st 20 14 0 235884576 389160720012 17047 171 133 3 8 85 4 0 18 17 0 220272576 389559120086 2131838 200142 162956 12 38 31 19 0 17 9 0 244284576 389553280019 2179562 213775 167901 13 43 26 18 0 27 15 0 223036576 389526400024 2202816 217996 158390 14 47 25 15 0 17 16 0 233124576 3895990800 5 2268815 224647 165728 14 50 21 15 0 16 13 0 225840576 389957400052 2253829 216797 160551 14 47 23 16 0 22 13 0 260584576 389829080092 2196737 211694 140924 14 53 19 15 0 16 10 0 235784576 389171280022 2157466 210022 137630 14 54 19 14 0 12 13 0 214300576 389238480031 2187735 213862 142711 14 52 20 14 0 25 12 0 219528576 389195400011 2066523 205256 142080 13 49 23 15 0 26 14 0 229460576 389137040049 2108654 200692 135447 13 51 21 15 0 11 11 0 220376576 388624560045 2136419 207493 146813 13 49 22 16 0 36 12 0 229860576 3886978400 7 2163463 212223 151812 14 47 25 14 0 16 13 0 238356576 388914960067 2251650 221728 154429 14 52 20 14 0 65 15 0 211536576 389221080059 2237925 224237 156587 14 53 19 14 0 24 13 0 585024576 386340240037 2240929 229040 148192 15 61 14 10 0 2012-08-09 11:59:04.714-06:00 vmstat -w 4 16 procs ---memory-- ---swap-- -io --system-- -cpu--- r b swpd free buff cache si sobibo in cs us sy id wa st 43 8 0 794392576 383823160011 20491 576 420 3 10 82 4 0 127 6 0 579328576 384221560021 2006775 205582 119660 12 70 11 7 0 44 5 0 492860576 385123600046 1536525 173377 85320 10 78 7 4 0 218 9 0 585668576 382713200039 1257266 152869 64023 8 83 7 3 0 101 6 0 600168576 381281040010 1438705 160769 68374 9 84 5 3 0 62 5 0 597004576 380989720093 1376841 154012 63912 8 82 7 4 0 61 11 0 850396576 378087720046 1186816 145731 70453 7 78 9 6 0 124 7 0 437388576 381263200015 1208434 149736 57142 7 86 4 3 0 204 11 01105816576 373095320020 1327833 145979 52718 7 87 4 2 0 29 8 0 751020576 3736033200 8 1405474 169916 61982 9 85 4 2 0 38 7 0 626448576 373332440014 1328415 174665 74214 8 84 5 3 0 23 5 0 650040576 371342800028 1351209 179220 71631 8 85 5 2 0 40 10 0 610988576 3705429200 104 1272527 167530 73527 7 85 5 3 0 79 22 02076836576 3548734000 750 1249934 175420 70124 7 88 3 2 0 58 6
Re: [PATCH 2/2] msm: io: Change the default static iomappings to be shared
On Mon, Jul 30, 2012 at 05:54:21PM -0700, Rohit Vaswani wrote: > With 3.4 kernel the static iomappings can be shared with the ioremap > mappings. If ioremap is called with an address for which a static > mapping already exists, then that mapping should be used instead > of creating a new one. > However, the MT_DEVICE_NONSHARED flag prevents this. Hence, get rid > of this flag. Some targets (7X00) that require the static iomappings > to be NONSHARED use the MSM_DEVICE_TYPE and MSM_CHIP_DEVICE_TYPE macros. > > Signed-off-by: Rohit Vaswani > --- > arch/arm/mach-msm/io.c | 25 + > 1 files changed, 17 insertions(+), 8 deletions(-) I don't seem to be able to find a tree that this change applies to. Can you apply this patch to a recent kernel tree (v3.5 is good), and resend. Thanks, David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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] regulator: tps6586x: correct vin pin for sm0/sm1/sm2
On Thu, Aug 09, 2012 at 12:09:31PM -0600, Stephen Warren wrote: > The patch in question just showed up again in next-20120809: > 7f852e0 regulator: tps6586x: correct vin pin for sm0/sm1/sm2 > ... with the exact same content as the previous commit ID. Oh, in that case I must've missed a branch when I was rebuilding -next. I just checked for missing branches. Problem solved. -- 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/7] HID: picoLCD updates
Hi Tejun, As you are working on workqueues and related code, could you have a look at my usage of them in combination with db_defio? The delayed memory corruptions or system reboots after unbinding/unplugging the PicoLCD seem very much related to workqueue used to handle the deferred IO to framebuffer. I think things don't get cleaned-up as they should though I'm not sure where the trouble lies. For ease of reading, I'm inlineing below the framebuffer related code of PicoLCD (for complete driver after this patch series apply the whole series on top of 3.5 https://lkml.org/lkml/2012/7/30/375 ) Thanks, Bruno On Mon, 30 July 2012 Bruno Prémont wrote: > This series updates picoLCD driver: > - split the driver functions into separate files which get included > depending on Kconfig selection > (implementation for CIR using RC_CORE will follow later) > - drop private framebuffer refcounting in favor of refcounting added > to fb_info some time ago > - fix various bugs issues > - disabled firmware version checking in probe() as it does not work > anymore since commit 4ea5454203d991ec85264f64f89ca8855fce69b0 > [HID: Fix race condition between driver core and ll-driver] > > Note: I still get weird behavior on quick unbind/bind sequences > issued via sysfs (CONFIG_SMP=n system) that are triggered by framebuffer > support and apparently more specifically fb_defio part of it. > > Unfortunately I'm out of ideas as to how to track down the problem which > shows either as SLAB corruption (detected with SLUB debugging, e.g. > > [ 6383.521833] > = > [ 6383.530020] BUG kmalloc-64 (Not tainted): Object already free > [ 6383.530020] > - > [ 6383.530020] > [ 6383.530020] INFO: Slab 0xdde0ea20 objects=51 used=40 fp=0xcef516e0 > flags=0x4080 > [ 6383.530020] INFO: Object 0xcef51190 @offset=400 fp=0xcef51f50 > [ 6383.530020] > [ 6383.530020] Bytes b4 cef51180: cc cc cc cc d0 12 f5 ce 5a 5a 5a 5a 5a 5a > 5a 5a > [ 6383.530020] Object cef51190: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b > [ 6383.530020] Object cef511a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b > [ 6383.530020] Object cef511b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b > [ 6383.530020] Object cef511c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > a5 kkk. > [ 6383.530020] Redzone cef511d0: bb bb bb bb > > [ 6383.530020] Padding cef511d8: 5a 5a 5a 5a 5a 5a 5a 5a > > [ 6383.530020] Pid: 1922, comm: bash Not tainted > 3.5.0-jupiter-3-g8d858b1-dirty #2 > [ 6383.530020] Call Trace: > [ 6383.530020] [] print_trailer+0x11c/0x130 > [ 6383.530020] [] object_err+0x35/0x40 > [ 6383.530020] [] free_debug_processing+0x99/0x200 > [ 6383.530020] [] __slab_free+0x2e/0x280 > [ 6383.530020] [] ? hid_submit_out+0xa4/0x120 > [ 6383.530020] [] ? __usbhid_submit_report+0xc0/0x3c0 > [ 6383.530020] [] ? kfree+0xfa/0x110 > [ 6383.530020] [] ? picolcd_debug_out_report+0x8c4/0x8e0 > [hid_picolcd] > [ 6383.530020] [] kfree+0xfa/0x110 > [ 6383.530020] [] ? hid_submit_out+0xa4/0x120 > [ 6383.530020] [] ? hid_submit_out+0xa4/0x120 > [ 6383.530020] [] ? hid_submit_out+0xa4/0x120 > [ 6383.530020] [] hid_submit_out+0xa4/0x120 > [ 6383.530020] [] __usbhid_submit_report+0x158/0x3c0 > [ 6383.530020] [] usbhid_submit_report+0x1b/0x30 > [ 6383.530020] [] picolcd_fb_reset+0xb9/0x180 [hid_picolcd] > [ 6383.530020] [] picolcd_init_framebuffer+0x20d/0x2e0 > [hid_picolcd] > [ 6383.530020] [] picolcd_probe+0x3cc/0x580 [hid_picolcd] > [ 6383.530020] [] hid_device_probe+0x67/0xf0 > [ 6383.530020] [] ? driver_sysfs_add+0x57/0x80 > [ 6383.530020] [] driver_probe_device+0xbd/0x1c0 > [ 6383.530020] [] ? hid_match_device+0x7b/0x90 > [ 6383.530020] [] driver_bind+0x75/0xd0 > [ 6383.530020] [] ? driver_unbind+0x90/0x90 > [ 6383.530020] [] drv_attr_store+0x27/0x30 > [ 6383.530020] [] sysfs_write_file+0xac/0xf0 > [ 6383.530020] [] vfs_write+0x9c/0x130 > [ 6383.530020] [] ? sys_dup3+0x11f/0x160 > [ 6383.530020] [] ? sysfs_poll+0x90/0x90 > [ 6383.530020] [] sys_write+0x3d/0x70 > [ 6383.530020] [] sysenter_do_call+0x12/0x26 > [ 6383.530020] FIX kmalloc-64: Object at 0xcef51190 not freed > > or worse spontaneous reboot of the system without any trace on netconsole or > serial console. > > echo $devid > bind; echo $devid > unbind > or > echo $devid > bind; echo $devid > unbind; sleep 0.2; echo $devid > bind; echo > $devid > unbind > > is sufficient to trigger the above issue while waiting a few seconds between > bind and unbind > shows no sign of trouble. > > Suggestions as to how to debug this and fix it are welcome! = driver/hid/hid-picolcd_fb.c ==
Re: [PATCH] regulator: tps6586x: correct vin pin for sm0/sm1/sm2
On 08/09/2012 12:05 PM, Mark Brown wrote: > On Wed, Aug 08, 2012 at 03:57:04PM -0600, Stephen Warren wrote: > >> I assume that was just an accident? > > Probably. I suspect a conflict with mainline when I rebased onto > v3.6-rc1. Please resend the patch, I don't think I have it any more. The patch in question just showed up again in next-20120809: 7f852e0 regulator: tps6586x: correct vin pin for sm0/sm1/sm2 ... with the exact same content as the previous commit ID. -- 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: RFC: mutex: hung tasks on SMP platforms with asm-generic/mutex-xchg.h
On Thu, 9 Aug 2012, Will Deacon wrote:
> On Thu, Aug 09, 2012 at 05:57:33PM +0100, Nicolas Pitre wrote:
> > On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> > > Yes, that looks fine. I'd remove that if (prev < 0) entirely though.
> > > We'll just swap a 0 for a 0 if the count wasn't < 0, or a 0 for a 1 if
> > > the mutex just got unlocked which is also fine. This is especially
> > > beneficial when a native xchg processor instruction is used.
> >
> > In fact, this suggestion isn't entirely correct either. The inner xchg
> > in this case should be -1 and not 'count'. If 'count' is 0 and the
> > mutex becomes contended in the small window between the two xchg's then
> > the contention mark would be lost again.
> >
> > In other words, I think this should look like this:
> >
> > diff --git a/include/asm-generic/mutex-xchg.h
> > b/include/asm-generic/mutex-xchg.h
> > index 580a6d35c7..44a66c99c8 100644
> > --- a/include/asm-generic/mutex-xchg.h
> > +++ b/include/asm-generic/mutex-xchg.h
> > @@ -25,8 +25,11 @@
> > static inline void
> > __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
> > {
> > - if (unlikely(atomic_xchg(count, 0) != 1))
> > - fail_fn(count);
> > + if (unlikely(atomic_xchg(count, 0) != 1)) {
> > + /* Mark lock contention explicitly */
> > + if (likely(atomic_xchg(count, -1) != 1))
> > + fail_fn(count);
> > + }
> > }
> >
> > /**
>
> Doesn't this mean that we're no longer just swapping 0 for a 0 if the lock
> was taken, therefore needlessly sending the current owner down the slowpath
> on unlock?
If the lock was taken, this means the count was either 0 or -1. If it
was 1 then we just put a 0 there and we own it. But if the cound was 0
then we should store -1 instead, which is what the inner xchg does. If
the count was already -1 then we store -1 back. That more closely mimic
what the atomic dec does which is what we want.
Nicolas
--
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] perf: sharing of cpuctx between core and ibs PMU causes problems
On Thu, 2012-08-09 at 16:05 +0200, Stephane Eranian wrote: > > uncore PMU does not have this issue because uncore_pmu->task_ctx_nr > > is 'perf_invalid_context'. find_pmu_context() always return NULL in > > that case. > > > Yes, I think IBS should do the same and that should fix the problem > there too. Will try that. I'm afraid not, per-task profiling with uncore doesn't really make that much sense. For IBS it does. We can't share a context with different PMUs, that'll totally mess up the event scheduling. We'll have to grow perf_event_task_context with an extra context and have IBS use that. -- 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] regulator: tps6586x: correct vin pin for sm0/sm1/sm2
On Wed, Aug 08, 2012 at 03:57:04PM -0600, Stephen Warren wrote: > I assume that was just an accident? Probably. I suspect a conflict with mainline when I rebased onto v3.6-rc1. Please resend the patch, I don't think I have it any more. -- 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/5] drivers/video/msm/mddi_client_dummy.c: use devm_ functions
On Fri, Aug 03, 2012 at 05:40:14PM +0200, Damien Cassou wrote:
> From: Damien Cassou
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch replaces the use of kzalloc by devm_kzalloc.
>
> Signed-off-by: Damien Cassou
>
> ---
> drivers/video/msm/mddi_client_dummy.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/msm/mddi_client_dummy.c
> b/drivers/video/msm/mddi_client_dummy.c
> index d2a091c..4c31325 100644
> --- a/drivers/video/msm/mddi_client_dummy.c
> +++ b/drivers/video/msm/mddi_client_dummy.c
> @@ -51,7 +51,7 @@ static int mddi_dummy_probe(struct platform_device *pdev)
> {
> struct msm_mddi_client_data *client_data = pdev->dev.platform_data;
> struct panel_info *panel =
> - kzalloc(sizeof(struct panel_info), GFP_KERNEL);
> + devm_kzalloc(>dev, sizeof(struct panel_info), GFP_KERNEL);
> int ret;
> if (!panel)
> return -ENOMEM;
> @@ -67,18 +67,11 @@ static int mddi_dummy_probe(struct platform_device *pdev)
> client_data->fb_resource, 1);
> panel->panel_data.fb_data = client_data->private_client_data;
> panel->pdev.dev.platform_data = >panel_data;
> - ret = platform_device_register(>pdev);
> - if (ret) {
> - kfree(panel);
> - return ret;
> - }
> - return 0;
> + return platform_device_register(>pdev);
Removing this block causes a warning:
kernel/drivers/video/msm/mddi_client_dummy.c: In function 'mddi_dummy_probe':
kernel/drivers/video/msm/mddi_client_dummy.c:55:6: warning: unused variable
'ret' [-Wunused-variable]
Please remove the 'int ret;' line above as well.
Thanks,
David Brown
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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: RFC: mutex: hung tasks on SMP platforms with asm-generic/mutex-xchg.h
On Thu, Aug 09, 2012 at 05:57:33PM +0100, Nicolas Pitre wrote:
> On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> > Yes, that looks fine. I'd remove that if (prev < 0) entirely though.
> > We'll just swap a 0 for a 0 if the count wasn't < 0, or a 0 for a 1 if
> > the mutex just got unlocked which is also fine. This is especially
> > beneficial when a native xchg processor instruction is used.
>
> In fact, this suggestion isn't entirely correct either. The inner xchg
> in this case should be -1 and not 'count'. If 'count' is 0 and the
> mutex becomes contended in the small window between the two xchg's then
> the contention mark would be lost again.
>
> In other words, I think this should look like this:
>
> diff --git a/include/asm-generic/mutex-xchg.h
> b/include/asm-generic/mutex-xchg.h
> index 580a6d35c7..44a66c99c8 100644
> --- a/include/asm-generic/mutex-xchg.h
> +++ b/include/asm-generic/mutex-xchg.h
> @@ -25,8 +25,11 @@
> static inline void
> __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
> {
> - if (unlikely(atomic_xchg(count, 0) != 1))
> - fail_fn(count);
> + if (unlikely(atomic_xchg(count, 0) != 1)) {
> + /* Mark lock contention explicitly */
> + if (likely(atomic_xchg(count, -1) != 1))
> + fail_fn(count);
> + }
> }
>
> /**
Doesn't this mean that we're no longer just swapping 0 for a 0 if the lock
was taken, therefore needlessly sending the current owner down the slowpath
on unlock? If we have the explicit test, that doesn't happen and the
disassembly isn't much different (an additional cmp/conditional branch).
Will
--
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: [SCSI] qla4xxx: support iscsiadm session mgmt
On Aug 8, 2012, at 11:57 AM, Dan Carpenter wrote: > On Wed, Aug 08, 2012 at 10:35:44AM -0500, Mike Christie wrote: >> On 08/08/2012 10:00 AM, Dan Carpenter wrote: >>> I never heard back on this. This buffer overflow is still present >>> in the current code. >>> >> >> Qlogic just sent a patch yesterday. >> http://marc.info/?l=linux-scsi=134434199930938=2 > > Ah, good. > > It seems like qla4xxx_ep_connect() should take a pointer to struct > sockaddr_storage and also dst_addr in qla4xxx_get_ep_fwdb() should > be changed as well. As in: > > static struct iscsi_endpoint * > -qla4xxx_ep_connect(struct Scsi_Host *shost, struct sockaddr *dst_addr, > +qla4xxx_ep_connect(struct Scsi_Host *shost, struct sockaddr_storage > *dst_addr, >int non_blocking) Do you mean that should be done to fix a bug or to just make it nicer? I think it will not be a issue bug wise, because it ends up getting cast to the proper struct in the end and the proper size to copy is detected. What actually gets passed that function above is not a struct sockaddr_storage. It is a sockaddr_in or socaddr_in6. It depends on if it is ipv6 or not. If you are just saying it would be nicer to be consistent in the struct used then it is a larger change that I think should be done in another patch. It will affect other drivers.-- 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 net-next,1/1] hyperv: Add comments for the extended buffer after RNDIS message
Reported-by: Olaf Hering
Signed-off-by: Haiyang Zhang
---
drivers/net/hyperv/rndis_filter.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 1e88a10..06f8601 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -46,8 +46,14 @@ struct rndis_request {
/* Simplify allocation by having a netvsc packet inline */
struct hv_netvsc_packet pkt;
struct hv_page_buffer buf;
- /* FIXME: We assumed a fixed size request here. */
+
struct rndis_message request_msg;
+ /*
+* The buffer for the extended info after the RNDIS message. It's
+* referenced based on the data offset in the RNDIS message. Its size
+* is enough for current needs, and should be sufficient for the near
+* future.
+*/
u8 ext[100];
};
--
1.7.4.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: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock
On Thu, 2012-08-09 at 12:05 -0400, Eric Paris wrote: > On Thu, Aug 9, 2012 at 11:36 AM, Eric Dumazet wrote: > > On Thu, 2012-08-09 at 11:07 -0400, Paul Moore wrote: > > > >> Is is possible to do the call to security_sk_alloc() in the ip_init() > >> function > >> or does the per-cpu nature of the socket make this a pain? > >> > > > > Its a pain, if we want NUMA affinity. > > > > Here, each cpu should get memory from its closest node. > > I really really don't like it. I won't say NAK, but it is the first > and only place in the kernel where I believe we allocate an object and > don't allocate the security blob until some random later point in > time. ... > If it is such a performance issue to have the security blob in > the same numa node, isn't adding a number of branches and putting this > function call on every output at least as bad? Aren't we discouraged > from GFP_ATOMIC? In __init we can use GFP_KERNEL. What a big deal. Its done _once_ time per cpu, and this is so small blob of memory you'll have to show us one single failure out of one million boots. If the security_sk_alloc() fails, we dont care. We are about sending a RESET or ACK packet. They can be lost by the network, or even skb allocation can fail. Nobody ever noticed and complained. Every time we accept() a new socket (and call security_sk_alloc()), its done under soft irq, thus GFP_ATOMIC, and you didn't complain yet, while a socket needs about 2 Kbytes of memory... > > This still doesn't fix these sockets entirely. We now have the > security blob allocated, but it was never set to something useful. > Paul, are you looking into this? This is a bandaide, not a fix > Please do so, on a followup patch, dont pretend I must fix all this stuff. -- 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] ubifs: remove __DATE__ and __TIME__
This tag is useless and it breaks automatic builds. It causes rebuilds
for packages that depend on kernel for no real reason.
Further, quoting Michal, who removed most of the users already:
The kernel already prints its build timestamp during boot, no need to
repeat it in random drivers and produce different object files each
time.
Signed-off-by: Jiri Slaby
Cc: Artem Bityutskiy
Cc: Adrian Hunter
Cc: linux-...@lists.infradead.org
Cc: Michal Marek
---
fs/ubifs/super.c |1 -
1 file changed, 1 deletion(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index e354832..67af316 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1431,7 +1431,6 @@ static int mount_ubifs(struct ubifs_info *c)
ubifs_msg("reserved for root: %llu bytes (%llu KiB)",
c->report_rp_size, c->report_rp_size >> 10);
- dbg_msg("compiled on: " __DATE__ " at " __TIME__);
dbg_msg("min. I/O unit size: %d bytes", c->min_io_size);
dbg_msg("max. write size: %d bytes", c->max_write_size);
dbg_msg("LEB size:%d bytes (%d KiB)",
--
1.7.10.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 v2 0/3] ARM: dt: tegra: cardhu: add entry for regulators
On 08/09/2012 05:00 AM, Laxman Dewangan wrote: > This patch series add the PMIC and fixed regulators for > cardhu board. There is multiple versions of cardhu baord named > as A01, A02, A03..and so on. Cardhu A01 and A03 are not supported. > Cardhu A02 and A04 have different sets of GPIO for regualtors. > The cardhu A04 is compatible for A05, A06 and A07 in GPIOs. > This patch series split the cardhu dts file to cardhu-a02 and > carchu-a04 and then add entry for different fixed regualtors. Thanks, applied the series to Tegra's for-3.7/dt branch. -- 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] Intel xhci: Only switch the switchable ports
With a previous patch to enable the EHCI/XHCI port switching, it switches
all the available ports.
The assumption is not correct because the BIOS may expect some ports
not switchable by the OS.
There are two more registers that contains the information of the switchable
and non-switchable ports.
This patch adds the checking code for the two register so that only the
switchable ports are altered.
Signed-off-by: Keng-Yu Lin
---
drivers/usb/host/pci-quirks.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
Correct the comment as suggested by Sarah Sharp.
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index df0828c..c5065f8 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -75,7 +75,9 @@
#defineNB_PIF0_PWRDOWN_1 0x01100013
#define USB_INTEL_XUSB2PR 0xD0
+#define USB_INTEL_USB2PRM 0xD4
#define USB_INTEL_USB3_PSSEN 0xD8
+#define USB_INTEL_USB3PRM 0xDC
static struct amd_chipset_info {
struct pci_dev *nb_dev;
@@ -772,10 +774,18 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
return;
}
- ports_available = 0x;
+ /* Read USB3PRM, the USB 3.0 Port Routing Mask Register
+* Indicate the ports that can be changed from OS.
+*/
+ pci_read_config_dword(xhci_pdev, USB_INTEL_USB3PRM,
+ _available);
+
+ dev_dbg(_pdev->dev, "Configurable ports to enable SuperSpeed:
0x%x\n",
+ ports_available);
+
/* Write USB3_PSSEN, the USB 3.0 Port SuperSpeed Enable
-* Register, to turn on SuperSpeed terminations for all
-* available ports.
+* Register, to turn on SuperSpeed terminations for the
+* switchable ports.
*/
pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
cpu_to_le32(ports_available));
@@ -785,7 +795,16 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
dev_dbg(_pdev->dev, "USB 3.0 ports that are now enabled "
"under xHCI: 0x%x\n", ports_available);
- ports_available = 0x;
+ /* Read XUSB2PRM, xHCI USB 2.0 Port Routing Mask Register
+* Indicate the USB 2.0 ports to be controlled by the xHCI host.
+*/
+
+ pci_read_config_dword(xhci_pdev, USB_INTEL_USB2PRM,
+ _available);
+
+ dev_dbg(_pdev->dev, "Configurable USB 2.0 ports to hand over to
xCHI: 0x%x\n",
+ ports_available);
+
/* Write XUSB2PR, the xHC USB 2.0 Port Routing Register, to
* switch the USB 2.0 power and data lines over to the xHCI
* host.
--
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 4/5] drivers/video/msm/mddi_client_dummy.c: use devm_ functions
On Fri, Aug 03, 2012 at 05:40:14PM +0200, Damien Cassou wrote: > From: Damien Cassou > > The various devm_ functions allocate memory that is released when a driver > detaches. This patch replaces the use of kzalloc by devm_kzalloc. > > Signed-off-by: Damien Cassou > > --- > drivers/video/msm/mddi_client_dummy.c | 12 ++-- > 1 file changed, 2 insertions(+), 10 deletions(-) Acked-by: David Brown -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 5/5] drivers/video/msm/mddi_client_nt35399.c: use devm_ functions
On Fri, Aug 03, 2012 at 05:40:13PM +0200, Damien Cassou wrote: > From: Damien Cassou > > The various devm_ functions allocate memory that is released when a driver > detaches. This patch replaces the use of kzalloc by devm_kzalloc. > > Additionally, this patch fixes a memory leak: some memory was allocated for > 'panel' but not released when the subsequent call to setup_vsync fails. > > Signed-off-by: Damien Cassou Acked-by: David Brown -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 v5 12/12] block: Only clone bio vecs that are in use
Hello, On Mon, Aug 06, 2012 at 03:08:41PM -0700, Kent Overstreet wrote: > bcache creates large bios internally, and then splits them according to > the device requirements before it sends them down. If a lower level > device tries to clone the bio, and the original bio had more than > BIO_MAX_PAGES, the clone will fail unecessarily. > > We can fix this by only cloning the bio vecs that are actually in use. How was this tested? Thanks. -- tejun -- 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] floppy: error handling fixes on do_floppy_init
On Wed, Aug 08, 2012 at 03:57:30PM -0400, Vivek Goyal wrote:
> On Wed, Aug 08, 2012 at 03:24:53PM -0300, Herton Ronaldo Krzesinski wrote:
> > While looking at commit 3f9a5aa ("floppy: Cleanup disk->queue before
> > caling put_disk() if add_disk() was never called") I noticed some
> > problems with the error handling and cleanup:
> >
> > * missing cleanup (put_disk) if blk_init_queue fails, dr is decremented
> > first in the error handling loop
> > * if something fails in the add_disk loop, there is no cleanup of
> > previous iterations in the error handling.
> > * "if (disks[dr]->queue)" check is bogus, when reaching there for each
> > dr should exist an queue allocated, and it doesn't take into account
> > iterations where add_disk wasn't done, if failure happens in add_disk
> > loop.
> > * floppy_module_exit doesn't reset queue pointer if add_disk wasn't
> > done.
>
> Hey, these seem to be multiple cleanups. Can you break these down into
> individual patches. Review becomes easy.
I'll resend with the fixes broken up.
>
> [..]
> > + blk_cleanup_queue(disks[dr]->queue);
> > + /*
> > +* put_disk() may not be paired with add_disk() and
> > +* will put queue reference one extra time. fix it.
> > +*/
> > + if (dr > registered || !(allowed_drive_mask & (1 << dr)) ||
> > + fdc_state[FDC(dr)].version == FDC_NONE)
> > disks[dr]->queue = NULL;
>
> I think checking for FDC_NONE and allowed_drive_mask() in multiple places
> is becoming unreadable now. Can we just maintain a separate array to keep
> track of disks on which we have called add_disk() and do the cleanup
> accordingly.
>
> static unsigned short disk_registered[N_DRIVE];
>
> /* do add_disk */
> disk_registered[drive] = 1;
>
>
> out_put_disk:
> while(dr--) {
> if (disks[dr]->queue && !disk_registered[dr]) {
> blk_cleanup_queue()
> disks[dr]->queue = NULL;
> }
> }
>
> Same disk_registered[] can be used for your other loop of remove drives.
> Also it can be used in cleaning up code in floppy_module_exit().
>
> I think this will make code much more readable. Right now this error
> handling loop is just getting too complicated.
Complicated as many other code in the kernel :), but yes, we can do
better here, your proposed solution looks good, I'll redo the changes
with it, thanks for the review.
>
> Thanks
> Vivek
>
--
[]'s
Herton
--
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 v5 08/12] block: Introduce new bio_split()
Hello, On Thu, Aug 09, 2012 at 03:33:34AM -0400, Kent Overstreet wrote: > > If you think the active dropping is justified, please let the change > > and justification clearly stated. You're burying the active change in > > two separate patches without even mentioning it or cc'ing people who > > care about bio-integrity (Martin K. Petersen). > > Not intentionally, he isn't in MAINTAINERS so get_maintainers.pl missed > it and it slipped by while I was looking for people to CC. Added him. git-log is your friend. For one-off patches, doing it this way might be okay. Higher layer maintainer would be able to redirect it but if you intend to change block layer APIs significantly as you try to do in this patch series, you need to be *way* more diligent than you currently are. At least I feel risky about acking patches in this series. * Significant change is buried without explicitly mentioning it or discussing its implications. * The patchset makes block layer API changes which impact multiple stacking and low level drivers which are not particularly known for simplicity and robustness, but there's no mention of how the patches are tested and/or why the patches would be safe (e.g. reviewed all the users and tested certain code paths and am fairly sure all the changes should be safe because xxx sort of deal). When asked about testing, not much seems to have been done. * Responses and iterations across patch postings aren't responsive or reliable, making it worrisome what will happen when things go south after this hits mainline. You're asking reviewers and maintainers to take a lot more risks than they usually have to, which isn't a good way to make forward progress. Thanks. -- tejun -- 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/3] perf tools: Initial bash completion support
On Thu, Aug 09, 2012 at 02:14:19PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Aug 09, 2012 at 10:40:19AM -0600, David Ahern escreveu: > > On 8/9/12 10:35 AM, Arnaldo Carvalho de Melo wrote: > > >Em Thu, Aug 09, 2012 at 04:31:51PM +0200, Frederic Weisbecker escreveu: > > >>This implements bash completion for perf subcommands such > > >>as record, report, script, probe, etc... > > > > > >Humm, I get this when doing my usual workflow: > > > > > >[acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > > >install > > >make: Entering directory `/home/git/linux/tools/perf' > > >PERF_VERSION = 3.6.rc1.152.g5758f7 > > > > > >install -d -m 755 > > >'/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > > >install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/bin' > > >install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t > > >'/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > > >install scripts/python/*.py -t > > >'/home/acme/libexec/perf-core/scripts/python' > > >install scripts/python/bin/* -t > > >'/home/acme/libexec/perf-core/scripts/python/bin' > > >install -m 755 bash_completion /etc/bash_completion.d/perf > > >install: cannot create regular file `/etc/bash_completion.d/perf': > > >Permission denied > > >make: *** [install] Error 1 > > >make: Leaving directory `/home/git/linux/tools/perf' > > >[acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > > >install > > > > > > Shouldn't it install on ~/etc/bash_completion.d/perf ? > > > > > > Is there a way to have per user bash completion files like that? > > > > 3rd patch should fix this. > > Huh? The problem is not /etc/bash_completion.d/ not existing, it exists, > its just that I'm not using sudo nor installing as root, this new bash > completion file is the only one that is being installed on the root > filesystem, all others are in ~acme/ No the third patch handles sysconfdir which should take care of that: $ make -C tools/perf O=/home/fweisbec/build install make: entrant dans le répertoire « /home/fweisbec/linux-2.6-tip/tools/perf » make[1]: entrant dans le répertoire « /home/fweisbec/linux-2.6-tip/tools/lib/traceevent » make[1]: quittant le répertoire « /home/fweisbec/linux-2.6-tip/tools/lib/traceevent » LINK /home/fweisbec/build/perf GEN perf-archive install -d -m 755 '/home/fweisbec/bin' install /home/fweisbec/build/perf '/home/fweisbec/bin' install -d -m 755 '/home/fweisbec/libexec/perf-core/scripts/perl/Perf-Trace-Util/lib/Perf/Trace' install -d -m 755 '/home/fweisbec/libexec/perf-core/scripts/perl/bin' install /home/fweisbec/build/perf-archive -t '/home/fweisbec/libexec/perf-core' install scripts/perl/Perf-Trace-Util/lib/Perf/Trace/* -t '/home/fweisbec/libexec/perf-core/scripts/perl/Perf-Trace-Util/lib/Perf/Trace' install scripts/perl/*.pl -t '/home/fweisbec/libexec/perf-core/scripts/perl' install scripts/perl/bin/* -t '/home/fweisbec/libexec/perf-core/scripts/perl/bin' install -d -m 755 '/home/fweisbec/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' install -d -m 755 '/home/fweisbec/libexec/perf-core/scripts/python/bin' install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t '/home/fweisbec/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' install scripts/python/*.py -t '/home/fweisbec/libexec/perf-core/scripts/python' install scripts/python/bin/* -t '/home/fweisbec/libexec/perf-core/scripts/python/bin' install -d -m 755 '/home/fweisbec/etc/bash_completion.d' install bash_completion '/home/fweisbec/etc/bash_completion.d/perf' make: quittant le répertoire « /home/fweisbec/linux-2.6-tip/tools/perf » -- 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:
Hi Fengguang,
Em 09-08-2012 10:54, Fengguang Wu escreveu:
...
> Date: Thu, 9 Aug 2012 21:54:16 +0800
> From: Fengguang Wu
> To: Mauro Carvalho Chehab
> Cc: Dave Peterson , kernel-janit...@vger.kernel.org,
> Doug Thompson , linux-e...@vger.kernel.org,
> linux-kernel@vger.kernel.org
> Message-ID: <20120809135416.GA13100@localhost>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> User-Agent: Mutt/1.5.21 (2010-09-15)
> X-RedHat-Spam-Score: -5.111
> (BAYES_00,MISSING_SUBJECT,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD)
> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
> X-Scanned-By: MIMEDefang 2.68 on 10.5.110.17
>
> Subject: possible double free in edac_mc_alloc()
> Reply-To:
> User-Agent: Heirloom mailx 12.5 6/20/10
There is an extra space between the email headers and the Subject...
due to that I almost deleted this message, considering it as spam.
>
> Hi,
>
> coccinelle warns about:
>
> + drivers/edac/edac_mc.c:429:9-23: ERROR: reference preceded by free on line
> 429
>
> and that line does look strange: the 'i' seems like a temporary value
> used in previous loops, and it won't change at all in the current
> loop. Which means the same mci->csrows[i] get freed once and again.
> It might also do double free for the previous kfree(csr) line.
>
> vim +429 drivers/edac/edac_mc.c
>
> 416 if (mci->dimms) {
> 417 for (i = 0; i < tot_dimms; i++)
> 418 kfree(mci->dimms[i]);
> 419 kfree(mci->dimms);
> 420 }
> 421 if (mci->csrows) {
> 422 for (chn = 0; chn < tot_channels; chn++) {
> 423 csr = mci->csrows[chn];
> 424 if (csr) {
> 425 for (chn = 0; chn < tot_channels;
> chn++)
> 426
> kfree(csr->channels[chn]);
> 427 kfree(csr);
> 428 }
> > 429 kfree(mci->csrows[i]);
It should likely be:
kfree(mci->csrows[csr])
instead. This is likely due to one of the countless rebases I had to do on it,
in order to make everybody happy. I suspect that, in the past, this loop was
also
using 'i' as the index variable.
Care to write us a patch fixing it? My HD crashed yesterday... I'm somewhat
busy today recovering from it, and doing some backup/restore stuff.
Thanks!
Mauro
> 430 }
> 431 kfree(mci->csrows);
> 432 }
>
> ---
> 0-DAY kernel build testing backend Open Source Technology Centre
> Fengguang Wu Intel Corporation
>
--
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/3] perf tools: Initial bash completion support
On 8/9/12 11:14 AM, Arnaldo Carvalho de Melo wrote: Em Thu, Aug 09, 2012 at 10:40:19AM -0600, David Ahern escreveu: On 8/9/12 10:35 AM, Arnaldo Carvalho de Melo wrote: Em Thu, Aug 09, 2012 at 04:31:51PM +0200, Frederic Weisbecker escreveu: This implements bash completion for perf subcommands such as record, report, script, probe, etc... Humm, I get this when doing my usual workflow: [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf install make: Entering directory `/home/git/linux/tools/perf' PERF_VERSION = 3.6.rc1.152.g5758f7 install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/bin' install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' install scripts/python/*.py -t '/home/acme/libexec/perf-core/scripts/python' install scripts/python/bin/* -t '/home/acme/libexec/perf-core/scripts/python/bin' install -m 755 bash_completion /etc/bash_completion.d/perf install: cannot create regular file `/etc/bash_completion.d/perf': Permission denied make: *** [install] Error 1 make: Leaving directory `/home/git/linux/tools/perf' [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf install Shouldn't it install on ~/etc/bash_completion.d/perf ? Is there a way to have per user bash completion files like that? 3rd patch should fix this. Huh? The problem is not /etc/bash_completion.d/ not existing, it exists, its just that I'm not using sudo nor installing as root, this new bash completion file is the only one that is being installed on the root filesystem, all others are in ~acme/ 3rd patch uses sysconfdir_SQ instead of /etc. ifndef DESTDIR prefix = $(HOME) endif ... ifeq ($(prefix),/usr) sysconfdir = /etc ETC_PERFCONFIG = $(sysconfdir)/perfconfig else sysconfdir = $(prefix)/etc ETC_PERFCONFIG = etc/perfconfig endif So, sysconfdir should be set to $(HOME)/etc in your case. -- 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: [09/36] AArch64: Exception handling
Hi Christopher, On Thu, Aug 09, 2012 at 06:05:36PM +0100, Christopher Covington wrote: > On 01/-10/-28163 02:59 PM, Catalin Marinas wrote: > > +/* > > + * Exception vectors. > > + */ > > + .macro ventry label > > + .align 7 > > + b \label > > + .endm > > + > > + .align 11 > > +ENTRY(vectors) > > + ventry el1_sync_invalid// Synchronous EL1t > > + ventry el1_irq_invalid // IRQ EL1t > > + ventry el1_fiq_invalid // FIQ EL1t > > + ventry el1_error_invalid // Error EL1t > > + > > + ventry el1_sync// Synchronous EL1h > > + ventry el1_irq // IRQ EL1h > > + ventry el1_fiq_invalid // FIQ EL1h > > + ventry el1_error_invalid // Error EL1h > > + > > + ventry el0_sync// Synchronous 64-bit EL0 > > + ventry el0_irq // IRQ 64-bit EL0 > > + ventry el0_fiq_invalid // FIQ 64-bit EL0 > > + ventry el0_error_invalid // Error 64-bit EL0 > > + > > +#ifdef CONFIG_AARCH32_EMULATION > > + ventry el0_sync_compat // Synchronous 32-bit EL0 > > + ventry el0_irq_compat // IRQ 32-bit EL0 > > + ventry el0_fiq_invalid_compat // FIQ 32-bit EL0 > > + ventry el0_error_invalid_compat// Error 32-bit EL0 > > +#else > > + ventry el0_sync_invalid// Synchronous 32-bit EL0 > > + ventry el0_irq_invalid // IRQ 32-bit EL0 > > + ventry el0_fiq_invalid // FIQ 32-bit EL0 > > + ventry el0_error_invalid // Error 32-bit EL0 > > +#endif > > +END(vectors) > > + > > +/* > > + * Invalid mode handlers > > + */ > > + .macro inv_entry, el, reason, regsize = 64 > > + kernel_entry el, \regsize > > + mov x0, sp > > + mov x1, #\reason > > + mrs x2, esr_el1 > > + b bad_mode > > + .endm > > The code seems to indicate that the invalid mode handlers have > different alignment requirements than the valid mode handlers, which > puzzles me. I don't see any difference. The whole vector must be 2K aligned while each individual entry is found every 128 bytes (to allow for more instructions, though we only use a branch). The inv_entry macro (as the kernel_entry one) is used in code being branched to from the vector and not inside the vector. > > +el0_sync_invalid: > > + inv_entry 0, BAD_SYNC > > +ENDPROC(el0_sync_invalid) > > Plain labels, the ENTRY macro, the END macro and the ENDPROC macro are > used variously throughout this file, and I wonder if a greater amount > of consistency might be attainable. The description of the ENDPROC > macro in include/linux/linkage.h makes me think its use might not be > completely warranted in blocks of assembly that don't end with a > return instruction. We use ENTRY only when we want to export the symbol as it contains the .globl directive. The ENDPROC is used to mark a function and it's in general useful for debugging information it generates. > > + .align 6 > > +el0_irq: > > + kernel_entry 0 > > +el0_irq_naked: > > + disable_step x1 > > + isb > > + enable_dbg > > +#ifdef CONFIG_TRACE_IRQFLAGS > > + bl trace_hardirqs_off > > +#endif > > + get_thread_info tsk > > +#ifdef CONFIG_PREEMPT > > + ldr x24, [tsk, #TI_PREEMPT] // get preempt count > > + add x23, x24, #1// increment it > > + str x23, [tsk, #TI_PREEMPT] > > +#endif > > + irq_handler > > +#ifdef CONFIG_PREEMPT > > + ldr x0, [tsk, #TI_PREEMPT] > > + str x24, [tsk, #TI_PREEMPT] > > + cmp x0, x23 > > + b.eq1f > > + mov x1, #0 > > + str x1, [x1]// BUG > > It looks like the error handling here isn't quite complete. We trigger a bug by storing to 0 and the kernel will panic, giving the full trace. I don't think we can do more in terms of error handling here. Regards. -- Catalin -- 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: [RFC 5/5] uprobes: add global breakpoints
* Oleg Nesterov | 2012-08-08 15:14:57 [+0200]:
>> What I miss right now is an interface to tell the user/gdb that there is a
>> program that hit a global breakpoint and is waiting for further instructions.
>> A "tail -f trace" does not work and may contain also a lot of other
>> informations. I've been thinking about a poll()able file which returns pids
>> of
>> tasks which are put on hold. Other suggestions?
>
>Honestly, I am not sure this is that useful...
How would you notify gdb that there is a new task that hit a breakpoint?
Or learn yourself?
>OK, I'll try to read this patch later. But, at first glance,
Thank you.
>> @@ -286,8 +286,10 @@ static int ptrace_attach(struct task_struct *task, long
>> request,
>> __ptrace_link(task, current);
>>
>> /* SEIZE doesn't trap tracee on attach */
>> -if (!seize)
>> +if (!seize) {
>> send_sig_info(SIGSTOP, SEND_SIG_FORCED, task);
>> +uprobe_wakeup_task(task, 1);
>> +}
>
>Can't understand why uprobe_wakeup_task() depends on !PTRACE_SEIZE
because in the SEIZE case the task isn't halted, it continues to run. Or
do you want to use PTRACE_SEIZE for tasks which hit the global
breakpoint and you have no interrest in them and want them to continue
like nothing happend?
>> +
>> +set_current_state(TASK_TRACED);
>> +schedule();
>> +}
>
>Suppose that uprobe_wakeup_task() is called in the WINDOW above.
>
>OTOH, uprobe_wakeup_task() can race with itself if it is called
>twice at the same time, say from uprobes_gp_wakeup_write() and
>ptrace_attach().
Okay, I'm going to close the window.
>
>Oleg.
Sebastian
--
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/3] perf tools: Initial bash completion support
Em Thu, Aug 09, 2012 at 10:40:19AM -0600, David Ahern escreveu: > On 8/9/12 10:35 AM, Arnaldo Carvalho de Melo wrote: > >Em Thu, Aug 09, 2012 at 04:31:51PM +0200, Frederic Weisbecker escreveu: > >>This implements bash completion for perf subcommands such > >>as record, report, script, probe, etc... > > > >Humm, I get this when doing my usual workflow: > > > >[acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > >install > >make: Entering directory `/home/git/linux/tools/perf' > >PERF_VERSION = 3.6.rc1.152.g5758f7 > > > >install -d -m 755 > >'/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > >install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/bin' > >install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t > >'/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > >install scripts/python/*.py -t '/home/acme/libexec/perf-core/scripts/python' > >install scripts/python/bin/* -t > >'/home/acme/libexec/perf-core/scripts/python/bin' > >install -m 755 bash_completion /etc/bash_completion.d/perf > >install: cannot create regular file `/etc/bash_completion.d/perf': > >Permission denied > >make: *** [install] Error 1 > >make: Leaving directory `/home/git/linux/tools/perf' > >[acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > >install > > > > Shouldn't it install on ~/etc/bash_completion.d/perf ? > > > > Is there a way to have per user bash completion files like that? > > 3rd patch should fix this. Huh? The problem is not /etc/bash_completion.d/ not existing, it exists, its just that I'm not using sudo nor installing as root, this new bash completion file is the only one that is being installed on the root filesystem, all others are in ~acme/ - Arnaldo -- 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/3] perf tools: Initial bash completion support
On Thu, Aug 09, 2012 at 02:11:22PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Aug 09, 2012 at 07:00:10PM +0200, Frederic Weisbecker escreveu: > > On Thu, Aug 09, 2012 at 01:35:15PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Thu, Aug 09, 2012 at 04:31:51PM +0200, Frederic Weisbecker escreveu: > > > > This implements bash completion for perf subcommands such > > > > as record, report, script, probe, etc... > > > > > > Humm, I get this when doing my usual workflow: > > > > > > [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > > > install > > > make: Entering directory `/home/git/linux/tools/perf' > > > PERF_VERSION = 3.6.rc1.152.g5758f7 > > > > > > install -d -m 755 > > > '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > > > install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/bin' > > > install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t > > > '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > > > install scripts/python/*.py -t > > > '/home/acme/libexec/perf-core/scripts/python' > > > install scripts/python/bin/* -t > > > '/home/acme/libexec/perf-core/scripts/python/bin' > > > install -m 755 bash_completion /etc/bash_completion.d/perf > > > install: cannot create regular file `/etc/bash_completion.d/perf': > > > Permission denied > > > make: *** [install] Error 1 > > > make: Leaving directory `/home/git/linux/tools/perf' > > > [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > > > install > > > > > > Shouldn't it install on ~/etc/bash_completion.d/perf ? > > > > Are you sure you have the third patch? > > So should I fold the third into the first? That's up to you. I kept the third patch seperate to let the credit to Namhyung. > > > > > > > Is there a way to have per user bash completion files like that? > > > > It seems that some manual tweaking is needed :( > > > > http://www.simplicidade.org/notes/archives/2008/02/bash_completion.html > > Will read. > > - Arnaldo -- 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/3] perf tools: Initial bash completion support
Em Thu, Aug 09, 2012 at 04:31:51PM +0200, Frederic Weisbecker escreveu: > This implements bash completion for perf subcommands such > as record, report, script, probe, etc... Humm, I get this when doing my usual workflow: [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf install make: Entering directory `/home/git/linux/tools/perf' PERF_VERSION = 3.6.rc1.152.g5758f7 install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/bin' install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' install scripts/python/*.py -t '/home/acme/libexec/perf-core/scripts/python' install scripts/python/bin/* -t '/home/acme/libexec/perf-core/scripts/python/bin' install -m 755 bash_completion /etc/bash_completion.d/perf install: cannot create regular file `/etc/bash_completion.d/perf': Permission denied make: *** [install] Error 1 make: Leaving directory `/home/git/linux/tools/perf' [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf install Shouldn't it install on ~/etc/bash_completion.d/perf ? Is there a way to have per user bash completion files like that? - Arnaldo -- 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/3] perf tools: Initial bash completion support
Em Thu, Aug 09, 2012 at 07:00:10PM +0200, Frederic Weisbecker escreveu: > On Thu, Aug 09, 2012 at 01:35:15PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Aug 09, 2012 at 04:31:51PM +0200, Frederic Weisbecker escreveu: > > > This implements bash completion for perf subcommands such > > > as record, report, script, probe, etc... > > > > Humm, I get this when doing my usual workflow: > > > > [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > > install > > make: Entering directory `/home/git/linux/tools/perf' > > PERF_VERSION = 3.6.rc1.152.g5758f7 > > > > install -d -m 755 > > '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > > install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/bin' > > install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t > > '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > > install scripts/python/*.py -t '/home/acme/libexec/perf-core/scripts/python' > > install scripts/python/bin/* -t > > '/home/acme/libexec/perf-core/scripts/python/bin' > > install -m 755 bash_completion /etc/bash_completion.d/perf > > install: cannot create regular file `/etc/bash_completion.d/perf': > > Permission denied > > make: *** [install] Error 1 > > make: Leaving directory `/home/git/linux/tools/perf' > > [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > > install > > > > Shouldn't it install on ~/etc/bash_completion.d/perf ? > > Are you sure you have the third patch? So should I fold the third into the first? > > > > Is there a way to have per user bash completion files like that? > > It seems that some manual tweaking is needed :( > > http://www.simplicidade.org/notes/archives/2008/02/bash_completion.html Will read. - Arnaldo -- 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] regulator: tps6586x: add support for SYS rail
On 08/05/2012 01:41 AM, Laxman Dewangan wrote: > Device have SYS rail which is always ON. It is system > power bus. LDO5 and LDO_RTC get powered through this rail > internally. Add support for this rail and make the > LDO5/LDO_RTC input supply to "sys". > Update document accordingly. Sorry to bug people, but is everyone OK with this patch? I'm holding off checking in the Tegra-side device tree changes that add regulators until this patch is checked in (or at least approved) to make sure the Tegra .dts patches don't need any more changes. 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 v2 2/5] x86/uprobes: implement x86 specific arch_uprobe_*_step
The arch specific implementation behaves like user_enable_single_step()
except that it does not disable single stepping if it was already
enabled. This allows the debugger to single step over an uprobe.
The state of block stepping is not restored. It makes only sense
together with TF and if that was enabled then the debugger is notified.
Signed-off-by: Sebastian Andrzej Siewior
---
v1..v2: re-use auprobe->fixups for fixups
arch/x86/include/asm/uprobes.h |2 ++
arch/x86/kernel/uprobes.c | 41 +++-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
index f3971bb..cee5862 100644
--- a/arch/x86/include/asm/uprobes.h
+++ b/arch/x86/include/asm/uprobes.h
@@ -46,6 +46,8 @@ struct arch_uprobe_task {
#ifdef CONFIG_X86_64
unsigned long saved_scratch_register;
#endif
+#define UPROBE_CLEAR_TF(1 << 0)
+ unsigned intrestore_flags;
};
extern int arch_uprobe_analyze_insn(struct arch_uprobe *aup, struct mm_struct
*mm, unsigned long addr);
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 36fd420..5a43606 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -41,6 +41,9 @@
/* Adjust the return address of a call insn */
#define UPROBE_FIX_CALL0x2
+/* Instruction will modify TF, don't change it */
+#define UPROBE_TF_CHANGES 0x4
+
#define UPROBE_FIX_RIP_AX 0x8000
#define UPROBE_FIX_RIP_CX 0x4000
@@ -233,12 +236,16 @@ static int validate_insn_32bits(struct arch_uprobe
*auprobe, struct insn *insn)
*/
static void prepare_fixups(struct arch_uprobe *auprobe, struct insn *insn)
{
- bool fix_ip = true, fix_call = false; /* defaults */
+ bool fix_ip = true, fix_call = false, fix_tf = false; /* defaults */
int reg;
insn_get_opcode(insn); /* should be a nop */
switch (OPCODE1(insn)) {
+ case 0x9d:
+ /* popf */
+ fix_tf = true;
+ break;
case 0xc3: /* ret/lret */
case 0xcb:
case 0xc2:
@@ -277,6 +284,8 @@ static void prepare_fixups(struct arch_uprobe *auprobe,
struct insn *insn)
auprobe->fixups |= UPROBE_FIX_IP;
if (fix_call)
auprobe->fixups |= UPROBE_FIX_CALL;
+ if (fix_tf)
+ auprobe->fixups |= UPROBE_TF_CHANGES;
}
#ifdef CONFIG_X86_64
@@ -673,3 +682,33 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe,
struct pt_regs *regs)
}
return false;
}
+
+void arch_uprobe_enable_step(struct arch_uprobe *auprobe)
+{
+ struct uprobe_task *utask = current->utask;
+ struct arch_uprobe_task *autask = >autask;
+
+ autask->restore_flags = 0;
+ if (!test_tsk_thread_flag(current, TIF_SINGLESTEP) &&
+ !(auprobe->fixups & UPROBE_TF_CHANGES))
+ autask->restore_flags |= UPROBE_CLEAR_TF;
+ /*
+* The state of TIF_BLOCKSTEP is not saved. With the TF flag set we
+* would to examine the opcode and the flags to make it right. Without
+* TF block stepping makes no sense. Instead we wakeup the debugger via
+* SIGTRAP in case TF was set. This has the side effect that the
+* debugger gets woken up even if the opcode normally wouldn't do so.
+*/
+ user_enable_single_step(current);
+}
+
+void arch_uprobe_disable_step(struct arch_uprobe *auprobe)
+{
+ struct uprobe_task *utask = current->utask;
+ struct arch_uprobe_task *autask = >autask;
+
+ if (autask->restore_flags & UPROBE_CLEAR_TF)
+ user_disable_single_step(current);
+ else
+ send_sig(SIGTRAP, current, 0);
+}
--
1.7.10.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: [dm-devel] [PATCH v2 2/2] dm: verity support data device offset (Linux 3.4.7)
On Aug 8, 2012, at 11:35 PM, Milan Broz wrote: > On 08/09/2012 02:40 AM, Wesley Miaw wrote: >> >> >> This isn't as polished because I pretty much just added support to do >> what I needed. I'm not sure if the LKML is the right place to post, >> so let me know if I should send this somewhere else. > > This is libcryptsetup userspace so better list for this is dmcrypt > mailing list (and/or cc me, I will handle these changes anyway). I will continue this thread on the dm-crypt mailing list. Thanks, -- Wesley Miaw signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ext4fs error "ext4_mb_generate_buddy:741:group 16, 8160 clusters in bitmap, 4064 in gd" (with repro)
On Thu, Aug 09, 2012 at 12:00:09PM +0200, Paolo Bonzini wrote: > Here is how to reproduce it. It happens during fstrim. I found other > occurrences of the error in the mailing list, but they were not related > to trim so they may be something different. > > modprobe scsi_debug dev_size_mb=256 lbpws=1 > dd if=/dev/zero of=/dev/sdb bs=1M > fdisk /dev/sdb > >> create a new partition accepting all defaults > fdisk -lu /dev/sdb|tail -1 > >> should show: /dev/sdb1 57 524285 262114+ 83 Linux > > mkfs.ext4 /dev/sdb1 > mkdir test > mount /dev/sdb1 test > fstrim ./test I can confirm that this accurately reproduces file system corruption using a 3.5 kernel. It looks like some block allocation bitmap blocks is getting trimmed when it shouldn't have been. Lukas, can you take a look at this? - 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: [09/36] AArch64: Exception handling
Hi Catalin and Will, On 01/-10/-28163 02:59 PM, Catalin Marinas wrote: > The patch contains the exception entry code (kernel/entry.S), pt_regs > structure and related accessors, undefined instruction trapping and > stack tracing. > > AArch64 Linux kernel (including kernel threads) runs in EL1 mode using > the SP1 stack. The vectors don't have a fixed address, only alignment > (2^11) requirements. [...] > diff --git a/arch/aarch64/kernel/entry.S b/arch/aarch64/kernel/entry.S > new file mode 100644 > index 000..8ad3995 > --- /dev/null > +++ b/arch/aarch64/kernel/entry.S > @@ -0,0 +1,696 @@ > +/* > + * Low-level exception handling code [...] > +/* > + * Exception vectors. > + */ > + .macro ventry label > + .align 7 > + b \label > + .endm > + > + .align 11 > +ENTRY(vectors) > + ventry el1_sync_invalid// Synchronous EL1t > + ventry el1_irq_invalid // IRQ EL1t > + ventry el1_fiq_invalid // FIQ EL1t > + ventry el1_error_invalid // Error EL1t > + > + ventry el1_sync// Synchronous EL1h > + ventry el1_irq // IRQ EL1h > + ventry el1_fiq_invalid // FIQ EL1h > + ventry el1_error_invalid // Error EL1h > + > + ventry el0_sync// Synchronous 64-bit EL0 > + ventry el0_irq // IRQ 64-bit EL0 > + ventry el0_fiq_invalid // FIQ 64-bit EL0 > + ventry el0_error_invalid // Error 64-bit EL0 > + > +#ifdef CONFIG_AARCH32_EMULATION > + ventry el0_sync_compat // Synchronous 32-bit EL0 > + ventry el0_irq_compat // IRQ 32-bit EL0 > + ventry el0_fiq_invalid_compat // FIQ 32-bit EL0 > + ventry el0_error_invalid_compat// Error 32-bit EL0 > +#else > + ventry el0_sync_invalid// Synchronous 32-bit EL0 > + ventry el0_irq_invalid // IRQ 32-bit EL0 > + ventry el0_fiq_invalid // FIQ 32-bit EL0 > + ventry el0_error_invalid // Error 32-bit EL0 > +#endif > +END(vectors) > + > +/* > + * Invalid mode handlers > + */ > + .macro inv_entry, el, reason, regsize = 64 > + kernel_entry el, \regsize > + mov x0, sp > + mov x1, #\reason > + mrs x2, esr_el1 > + b bad_mode > + .endm The code seems to indicate that the invalid mode handlers have different alignment requirements than the valid mode handlers, which puzzles me. > + > +el0_sync_invalid: > + inv_entry 0, BAD_SYNC > +ENDPROC(el0_sync_invalid) Plain labels, the ENTRY macro, the END macro and the ENDPROC macro are used variously throughout this file, and I wonder if a greater amount of consistency might be attainable. The description of the ENDPROC macro in include/linux/linkage.h makes me think its use might not be completely warranted in blocks of assembly that don't end with a return instruction. > +el0_irq_invalid: > + inv_entry 0, BAD_IRQ > +ENDPROC(el0_irq_invalid) > + > +el0_fiq_invalid: > + inv_entry 0, BAD_FIQ > +ENDPROC(el0_fiq_invalid) > + > +el0_error_invalid: > + inv_entry 0, BAD_ERROR > +ENDPROC(el0_error_invalid) > + > +#ifdef CONFIG_AARCH32_EMULATION > +el0_fiq_invalid_compat: > + inv_entry 0, BAD_FIQ, 32 > +ENDPROC(el0_fiq_invalid_compat) > + > +el0_error_invalid_compat: > + inv_entry 0, BAD_ERROR, 32 > +ENDPROC(el0_error_invalid_compat) > +#endif > + > +el1_sync_invalid: > + inv_entry 1, BAD_SYNC > +ENDPROC(el1_sync_invalid) > + > +el1_irq_invalid: > + inv_entry 1, BAD_IRQ > +ENDPROC(el1_irq_invalid) > + > +el1_fiq_invalid: > + inv_entry 1, BAD_FIQ > +ENDPROC(el1_fiq_invalid) > + > +el1_error_invalid: > + inv_entry 1, BAD_ERROR > +ENDPROC(el1_error_invalid) > + > +/* > + * EL1 mode handlers. > + */ > + .align 6 > +el1_sync: > + kernel_entry 1 > + mrs x1, esr_el1 // read the syndrome register > + lsr x24, x1, #26// exception class > + cmp x24, #0x25 // data abort in EL1 > + b.eqel1_da > + cmp x24, #0x18 // configurable trap > + b.eqel1_undef > + cmp x24, #0x26 // stack alignment exception > + b.eqel1_sp_pc > + cmp x24, #0x22 // pc alignment exception > + b.eqel1_sp_pc > + cmp x24, #0x00 // unknown exception in EL1 > + b.eqel1_undef > + cmp x24, #0x30 // debug exception in EL1 > + b.geel1_dbg > + b el1_inv > +el1_da: > + /* > + * Data abort handling > + */ > + mrs x0, far_el1 > + enable_dbg_if_not_stepping x2 > + // re-enable interrupts if they were enabled in the aborted context > + tbnzx23, #7, 1f
Re: [PATCH v2 10/23] xen/arm: compile and run xenbus
> > Right, the original patch didn't break anything with PV domains. The case > > it doesn't handle is an HVM initial domain with an already-running > > Xenstore domain; I think this applies both to ARM and hybrid/PVH on x86. > > In that case, usage would be set to LOCAL instead of HVM. > > > Right, however if I am not mistaken there is no such thing as an HVM > dom0 right now on x86 and hybrid/PVH is probably going to return true on > xen_pv_domain() and false on xen_hvm_domain(). The other way around. HVM = true, PV = false. Mukesh, correct me if I am wrong pls. > > In the ARM case, given that we don't have a start_info page, we would > need another way to figure out whether a xenstore stub domain is already > running, so I think we can just postpone the solution of that problem > for now. -- 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 v7 0/8] Raid: enable talitos xor offload for improving performance
On Thu, Aug 09, 2012 at 04:19:35PM +0800, qiang@freescale.com wrote: > Hi all, > > The following 8 patches enabling fsl-dma and talitos offload raid > operations for improving raid performance and balancing CPU load. > > These patches include talitos, fsl-dma and carma module (caram uses > some features of fsl-dma). > > Write performance will be improved by 25-30% tested by iozone. > Write performance is improved about 2% after using spin_lock_bh replace > spin_lock_irqsave. > CPU load will be reduced by 8%. > > "fwiw, I gave v5 a test-drive, setting up a RAID5 array on ramdisks > [1], and this patchseries, along with FSL_DMA && NET_DMA set seems > to be holding water, so this series gets my:" > > Tested-by: Kim Phillips > The fsldma parts of the series all look great to me. Thanks, Ira > [1] mdadm --create --verbose --force /dev/md0 --level=raid5 --raid-devices=4 \ > /dev/ram[0123] > > Changes in v7: > - add test result which is provided by Kim Phillips; > - correct one coding style issue in patch 5/8; > - add comments by Arnd Bergmann in patch 6/8; > > Changes in v6: > - swap the order of original patch 3/6 and 4/6; > - merge Ira's patch to reduce the size of original patch; > - merge Ira's patch of carma in 8/8; > - update documents and descriptions according to Ira's advice; > > Changes in v5: > - add detail description in patch 3/6 about the process of completed > descriptor, the process is in align with fsl-dma Reference Manual, > illustrate the potential risk and how to reproduce it; > - drop the patch 7/7 in v4 according to Timur's comments; > > Changes in v4: > - fix an error in talitos when dest addr is same with src addr, dest > should be freed only one time if src is same with dest addr; > - correct coding style in fsl-dma according to Ira's comments; > - fix a race condition in fsl-dma fsl_tx_status(), remove the interface > which is used to free descriptors in queue ld_completed, this interface > has been included in fsldma_cleanup_descriptor(), in v3, there is one > place missed spin_lock protect; > - split the original patch 3/4 up to 2 patches 3/7 and 4/7 according to > Li Yang's comments; > - fix a warning of unitialized cookie; > - add memory copy self test in fsl-dma; > - add more detail description about use spin_lock_bh() to instead of > spin_lock_irqsave() according to Timur's comments. > > Changes in v3: > - change release process of fsl-dma descriptor for resolve the > potential race condition; > - add test result when use spin_lock_bh replace spin_lock_irqsave; > - modify the benchmark results according to the latest patch. > > Changes in v2: > - rebase onto cryptodev tree; > - split the patch 3/4 up to 3 independent patches; > - remove the patch 4/4, the fix is not for cryptodev tree; > > Qiang Liu (8): > Talitos: Support for async_tx XOR offload > fsl-dma: remove attribute DMA_INTERRUPT of dmaengine > fsl-dma: add fsl_dma_free_descriptor() to reduce code duplication > fsl-dma: move functions to avoid forward declarations > fsl-dma: change release process of dma descriptor for supporting > async_tx > fsl-dma: use spin_lock_bh to instead of spin_lock_irqsave > fsl-dma: fix a warning of unitialized cookie > carma: remove unnecessary DMA_INTERRUPT capability > > drivers/crypto/Kconfig |9 + > drivers/crypto/talitos.c| 413 ++ > drivers/crypto/talitos.h| 53 > drivers/dma/fsldma.c| 488 > +-- > drivers/dma/fsldma.h| 17 +- > drivers/misc/carma/carma-fpga-program.c |1 - > drivers/misc/carma/carma-fpga.c |2 +- > 7 files changed, 761 insertions(+), 222 deletions(-) > > ___ > Linuxppc-dev mailing list > linuxppc-...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev -- 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] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function
On Thu, 2012-08-09 at 09:13 -0500, Christoph Lameter (Open Source)
wrote:
> On Mon, 6 Aug 2012, Shuah Khan wrote:
>
> > +#ifdef CONFIG_DEBUG_VM
> > +static int kmem_cache_sanity_check(const char *name, size_t size)
>
> Why do we pass "size" in? AFAICT there is no need to.
It is an oversight on my part. Will re-work the patch as needed. Please
see more on your second comment below.
>
> > @@ -53,48 +93,17 @@ struct kmem_cache *kmem_cache_create(const char *name,
> > size_t size, size_t align
> > {
> > struct kmem_cache *s = NULL;
> >
> > -#ifdef CONFIG_DEBUG_VM
> > if (!name || in_interrupt() || size < sizeof(void *) ||
> > size > KMALLOC_MAX_SIZE) {
> > - printk(KERN_ERR "kmem_cache_create(%s) integrity check"
> > - " failed\n", name);
> > + pr_err("kmem_cache_create(%s) integrity check failed\n", name);
> > goto out;
> > }
> > -#endif
> >
>
> If you move the above code into the sanity check function then you will be
> using the size as well. These are also sanity checks after all.
Yes these are also sanity checks, however these checks are common to
debug and non-debug paths, hence the reasoning to leave them in
kmem_cache_create().
You are right, if these checks get moved into the debug section in
kmem_cache_sanity_check, size will be used.
Moving these checks into kmem_cache_sanity_check() would mean return
path handling will change. The first block of sanity checks for name,
and size etc. are done before holding the slab_mutex and the second
block that checks the slab lists is done after holding the mutex.
Depending on which one fails, return handling is going to be different
in that if second block fails, mutex needs to be unlocked and when the
first block fails, there is no need to do that. Nothing that is too
complex to solve, just something that needs to be handled.
Comments, thoughts on
1. just remove size from kmem_cache_sanity_check() parameters
or
2. move first block sanity checks into kmem_cache_sanity_check()
Personally I prefer the first option to avoid complexity in return path
handling. Would like to hear what others think.
-- Shuah
--
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/3] perf tools: Initial bash completion support
On Thu, Aug 09, 2012 at 01:35:15PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Aug 09, 2012 at 04:31:51PM +0200, Frederic Weisbecker escreveu: > > This implements bash completion for perf subcommands such > > as record, report, script, probe, etc... > > Humm, I get this when doing my usual workflow: > > [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > install > make: Entering directory `/home/git/linux/tools/perf' > PERF_VERSION = 3.6.rc1.152.g5758f7 > > install -d -m 755 > '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/bin' > install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t > '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' > install scripts/python/*.py -t '/home/acme/libexec/perf-core/scripts/python' > install scripts/python/bin/* -t > '/home/acme/libexec/perf-core/scripts/python/bin' > install -m 755 bash_completion /etc/bash_completion.d/perf > install: cannot create regular file `/etc/bash_completion.d/perf': Permission > denied > make: *** [install] Error 1 > make: Leaving directory `/home/git/linux/tools/perf' > [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf > install > > Shouldn't it install on ~/etc/bash_completion.d/perf ? Are you sure you have the third patch? > > Is there a way to have per user bash completion files like that? It seems that some manual tweaking is needed :( http://www.simplicidade.org/notes/archives/2008/02/bash_completion.html > > - Arnaldo -- 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: RFC: mutex: hung tasks on SMP platforms with asm-generic/mutex-xchg.h
On Thu, 9 Aug 2012, Nicolas Pitre wrote:
> On Thu, 9 Aug 2012, Will Deacon wrote:
>
> > I think we could actually fix this entirely in mutex-xchg.h by doing
> > something in fastpath_lock similar to what we do for trylock:
> >
> >
> > diff --git a/include/asm-generic/mutex-xchg.h
> > b/include/asm-generic/mutex-xchg.h
> > index 580a6d3..c082e99 100644
> > --- a/include/asm-generic/mutex-xchg.h
> > +++ b/include/asm-generic/mutex-xchg.h
> > @@ -25,8 +25,19 @@
> > static inline void
> > __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
> > {
> > - if (unlikely(atomic_xchg(count, 0) != 1))
> > - fail_fn(count);
> > + int prev = atomic_xchg(count, 0);
> > +
> > + if (unlikely(prev != 1)) {
> > + if (prev < 0)
> > + /*
> > +* The lock was contended, so we need to restore
> > +* its original state to ensure that any waiting
> > +* tasks are woken up by the unlock slow path.
> > +*/
> > + prev = atomic_xchg(count, prev);
> > + if (prev != 1)
> > + fail_fn(count);
> > + }
> > }
> >
> > What do you reckon?
>
> Yes, that looks fine. I'd remove that if (prev < 0) entirely though.
> We'll just swap a 0 for a 0 if the count wasn't < 0, or a 0 for a 1 if
> the mutex just got unlocked which is also fine. This is especially
> beneficial when a native xchg processor instruction is used.
In fact, this suggestion isn't entirely correct either. The inner xchg
in this case should be -1 and not 'count'. If 'count' is 0 and the
mutex becomes contended in the small window between the two xchg's then
the contention mark would be lost again.
In other words, I think this should look like this:
diff --git a/include/asm-generic/mutex-xchg.h b/include/asm-generic/mutex-xchg.h
index 580a6d35c7..44a66c99c8 100644
--- a/include/asm-generic/mutex-xchg.h
+++ b/include/asm-generic/mutex-xchg.h
@@ -25,8 +25,11 @@
static inline void
__mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
{
- if (unlikely(atomic_xchg(count, 0) != 1))
- fail_fn(count);
+ if (unlikely(atomic_xchg(count, 0) != 1)) {
+ /* Mark lock contention explicitly */
+ if (likely(atomic_xchg(count, -1) != 1))
+ fail_fn(count);
+ }
}
/**
Nicolas
--
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] ARM: build ssi-fiq.S in ARM mode to prevent CONFIG_THUMB2_KERNEL build breakage
On Thu, Aug 09, 2012 at 11:05:47AM -0500, Matt Sealey wrote: > On Thu, Aug 9, 2012 at 9:50 AM, Dave Martin wrote: > > On Thu, Aug 09, 2012 at 09:32:59AM -0500, Matt Sealey wrote: > >> Matt Sealey > >> Product Development Analyst, Genesi USA, Inc. > >> > >> > >> On Thu, Aug 9, 2012 at 5:24 AM, Dave Martin wrote: > >> > On Wed, Aug 08, 2012 at 12:32:39PM -0500, Matt Sealey wrote: > >> > > >> > [...] > >> > > >> >> I'm going to do a trapse through and find where Russell nacked Dave's > >> >> thumb-aware > >> >> rewrite.. would you mind if you have any of these boards seeing if it > >> >> really DOES > >> > > >> > There was no NAK because I didn't get as far as posting the patch, > >> > >> http://lists.arm.linux.org.uk/lurker/message/20111202.133911.393b6e28.en.html > >> > >> You did, twice :) > > > > Well, I meant that I had not posted it as a stand-alone patch for > > inclusion; I only posted it when commenting on other threads. > > > >> > mostly because of the doubt about whether this code is ever relevant > >> > on Thumb2-capable hardware. > >> > >> It's not, but it does break the build, and without disabling phyCORE > >> boards for > >> Thumb2 it will always break the build.. > > > > If you want me to push it, let me know. I don't think this should get > > merged without some Tested-bys for hardware where the FIQ stuff actually > > gets used. > > Please, then all the Tested-by's should flood in, right? :) Do you have any suggestions for who I should CC to speed things up? Cheers ---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/
Re: [PATCH v2 02/23] xen/arm: hypercalls
On Thu, Aug 09, 2012 at 04:37:24PM +0100, Stefano Stabellini wrote: > On Wed, 8 Aug 2012, Dave Martin wrote: > > On Mon, Aug 06, 2012 at 03:27:05PM +0100, Stefano Stabellini wrote: > > > Use r12 to pass the hypercall number to the hypervisor. > > > > > > We need a register to pass the hypercall number because we might not > > > know it at compile time and HVC only takes an immediate argument. > > > > > > Among the available registers r12 seems to be the best choice because it > > > is defined as "intra-procedure call scratch register". > > > > > > Use the ISS to pass an hypervisor specific tag. > > > > > > Changes in v2: > > > - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if > > > at the moment is unused; > > > - use ldm instead of pop; > > > - fix up comments. > > > > > > Signed-off-by: Stefano Stabellini > > > --- > > > arch/arm/include/asm/xen/hypercall.h | 50 > > > arch/arm/xen/Makefile|2 +- > > > arch/arm/xen/hypercall.S | 106 > > > ++ > > > 3 files changed, 157 insertions(+), 1 deletions(-) > > > create mode 100644 arch/arm/include/asm/xen/hypercall.h > > > create mode 100644 arch/arm/xen/hypercall.S > > > > [...] > > > > > diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S > > > new file mode 100644 > > > index 000..074f5ed > > > --- /dev/null > > > +++ b/arch/arm/xen/hypercall.S > > > @@ -0,0 +1,106 @@ > > > +/** > > > + * hypercall.S > > > + * > > > + * Xen hypercall wrappers > > > + * > > > + * Stefano Stabellini , Citrix, 2012 > > > + * > > > + * This program is free software; you can redistribute it and/or > > > + * modify it under the terms of the GNU General Public License version 2 > > > + * as published by the Free Software Foundation; or, when distributed > > > + * separately from the Linux kernel or incorporated into other > > > + * software packages, subject to the following license: > > > + * > > > + * Permission is hereby granted, free of charge, to any person obtaining > > > a copy > > > + * of this source file (the "Software"), to deal in the Software without > > > + * restriction, including without limitation the rights to use, copy, > > > modify, > > > + * merge, publish, distribute, sublicense, and/or sell copies of the > > > Software, > > > + * and to permit persons to whom the Software is furnished to do so, > > > subject to > > > + * the following conditions: > > > + * > > > + * The above copyright notice and this permission notice shall be > > > included in > > > + * all copies or substantial portions of the Software. > > > + * > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > > EXPRESS OR > > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > > MERCHANTABILITY, > > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > > > SHALL THE > > > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > > > ARISING > > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > > > DEALINGS > > > + * IN THE SOFTWARE. > > > + */ > > > + > > > +/* > > > + * The Xen hypercall calling convention is very similar to the ARM > > > + * procedure calling convention: the first paramter is passed in r0, the > > > + * second in r1, the third in r2 and the fourth in r3. Considering that > > > + * Xen hypercalls have 5 arguments at most, the fifth paramter is passed > > > + * in r4, differently from the procedure calling convention of using the > > > + * stack for that case. > > > + * > > > + * The hypercall number is passed in r12. > > > + * > > > + * The return value is in r0. > > > + * > > > + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM > > > + * hypercall tag. > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > + > > > + > > > +/* HVC 0xEA1 */ > > > +#ifdef CONFIG_THUMB2_KERNEL > > > +#define xen_hvc .word 0xf7e08ea1 > > > +#else > > > +#define xen_hvc .word 0xe140ea71 > > > +#endif > > > > Consider using my opcode injection helpers patch for this (see > > separate repost: [PATCH v2 REPOST 0/4] ARM: opcodes: Facilitate custom > > opcode injection), assuming that nobody objects to it. This should mean > > that the right opcodes get generated when building a kernel for a big- > > endian target for example. > > > > I believe the __HVC(imm) macro which I put in as an > > example should do what you need in this case. > > Sure I can do that. Maybe I'll add another patch at the end of my series > to replace xen_hvc with __HVC(0xEA1), so that it remains independent > from your series. > I have learned through experience that avoiding cross patch series > dependencies help to reduce the amount of headaches during merge windows > :) I agree. I'll let you know
Re: [PATCH 3/5] hda_intel: Add Device IDs for Intel Lynx Point-LP PCH
At Thu, 9 Aug 2012 09:38:59 -0700,
james.d.rals...@intel.com wrote:
>
> From: James Ralston
>
> This patch adds the Intel HD Audio Device IDs for the Intel Lynx Point-LP PCH
>
> Signed-off-by: James Ralston
Applied now. Thanks.
Takashi
> ---
> sound/pci/hda/hda_intel.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index c8aced1..60882c6 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -151,6 +151,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6},"
>"{Intel, CPT},"
>"{Intel, PPT},"
>"{Intel, LPT},"
> + "{Intel, LPT_LP},"
>"{Intel, HPT},"
>"{Intel, PBG},"
>"{Intel, SCH},"
> @@ -3270,6 +3271,14 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
> { PCI_DEVICE(0x8086, 0x8c20),
> .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
> AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_COMBO },
> + /* Lynx Point-LP */
> + { PCI_DEVICE(0x8086, 0x9c20),
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
> + AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_COMBO },
> + /* Lynx Point-LP */
> + { PCI_DEVICE(0x8086, 0x9c21),
> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
> + AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_COMBO },
> /* Haswell */
> { PCI_DEVICE(0x8086, 0x0c0c),
> .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP |
> --
> 1.7.7.6
>
--
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 07/11] mm: Allocate kernel pages to the right memcg
On 08/09/2012 08:33 PM, Greg Thelen wrote: > On Thu, Aug 09 2012, Glauber Costa wrote: > >> When a process tries to allocate a page with the __GFP_KMEMCG flag, the >> page allocator will call the corresponding memcg functions to validate >> the allocation. Tasks in the root memcg can always proceed. >> >> To avoid adding markers to the page - and a kmem flag that would >> necessarily follow, as much as doing page_cgroup lookups for no reason, >> whoever is marking its allocations with __GFP_KMEMCG flag is responsible >> for telling the page allocator that this is such an allocation at >> free_pages() time. This is done by the invocation of >> __free_accounted_pages() and free_accounted_pages(). >> >> Signed-off-by: Glauber Costa >> CC: Christoph Lameter >> CC: Pekka Enberg >> CC: Michal Hocko >> CC: Kamezawa Hiroyuki >> CC: Johannes Weiner >> CC: Suleiman Souhlal >> --- >> include/linux/gfp.h | 3 +++ >> mm/page_alloc.c | 38 ++ >> 2 files changed, 41 insertions(+) >> >> diff --git a/include/linux/gfp.h b/include/linux/gfp.h >> index d8eae4d..029570f 100644 >> --- a/include/linux/gfp.h >> +++ b/include/linux/gfp.h >> @@ -370,6 +370,9 @@ extern void free_pages(unsigned long addr, unsigned int >> order); >> extern void free_hot_cold_page(struct page *page, int cold); >> extern void free_hot_cold_page_list(struct list_head *list, int cold); >> >> +extern void __free_accounted_pages(struct page *page, unsigned int order); >> +extern void free_accounted_pages(unsigned long addr, unsigned int order); >> + >> #define __free_page(page) __free_pages((page), 0) >> #define free_page(addr) free_pages((addr), 0) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index b956cec..da341dc 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -2532,6 +2532,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int >> order, >> struct page *page = NULL; >> int migratetype = allocflags_to_migratetype(gfp_mask); >> unsigned int cpuset_mems_cookie; >> +void *handle = NULL; >> >> gfp_mask &= gfp_allowed_mask; >> >> @@ -2543,6 +2544,13 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int >> order, >> return NULL; >> >> /* >> + * Will only have any effect when __GFP_KMEMCG is set. >> + * This is verified in the (always inline) callee >> + */ >> +if (!memcg_kmem_new_page(gfp_mask, , order)) >> +return NULL; >> + >> +/* >> * Check the zones suitable for the gfp_mask contain at least one >> * valid zone. It's possible to have an empty zonelist as a result >> * of GFP_THISNODE and a memoryless node > > If memcg_kmem_new_page() succeeds then it may have obtained a memcg > reference with mem_cgroup_get(). I think this reference is leaked when > returning below: > > /* >* Check the zones suitable for the gfp_mask contain at least one >* valid zone. It's possible to have an empty zonelist as a result >* of GFP_THISNODE and a memoryless node >*/ > if (unlikely(!zonelist->_zonerefs->zone)) > return NULL; > > I suspect the easiest fix is to swap the call to memcg_kmem_new_page() > and the (!zonelist->_zonerefs->zone) check. > You are right, indeed. -- 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 4/5] i2c-i801: Add Device IDs for Intel Lynx Point-LP PCH
From: James Ralston
This patch adds the SMBus Device IDs for the Intel Lynx Point-LP PCH. The
Device IDs are defined in drivers/i2c/busses/i2c-i801.c
Signed-off-by: James Ralston
---
Documentation/i2c/busses/i2c-i801 |1 +
drivers/i2c/busses/Kconfig|1 +
drivers/i2c/busses/i2c-i801.c |3 +++
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/i2c/busses/i2c-i801
b/Documentation/i2c/busses/i2c-i801
index 615142d..53207df 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -21,6 +21,7 @@ Supported adapters:
* Intel DH89xxCC (PCH)
* Intel Panther Point (PCH)
* Intel Lynx Point (PCH)
+ * Intel Lynx Point_LP (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2e7530a..3500af7 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -104,6 +104,7 @@ config I2C_I801
DH89xxCC (PCH)
Panther Point (PCH)
Lynx Point (PCH)
+ Lynx Point_LP (PCH)
This driver can also be built as a module. If so, the module
will be called i2c-i801.
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 898dcf9..c467038 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -52,6 +52,7 @@
DH89xxCC (PCH)0x2330 32 hard yes yes yes
Panther Point (PCH) 0x1e22 32 hard yes yes yes
Lynx Point (PCH) 0x8c22 32 hard yes yes yes
+ Lynx Point_LP (PCH) 0x9c22 32 hard yes yes yes
Features supported by this driver:
Software PEC no
@@ -155,6 +156,7 @@
#define PCI_DEVICE_ID_INTEL_DH89XXCC_SMBUS 0x2330
#define PCI_DEVICE_ID_INTEL_5_3400_SERIES_SMBUS0x3b30
#define PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS0x8c22
+#define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS 0x9c22
struct i801_priv {
struct i2c_adapter adapter;
@@ -771,6 +773,7 @@ static DEFINE_PCI_DEVICE_TABLE(i801_ids) = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_DH89XXCC_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_PANTHERPOINT_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS)
},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS) },
{ 0, }
};
--
1.7.7.6
--
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/
[REGRESSION] hard lockup on resume from suspend on ThinkPad T23
Hello! I thought I report it here – although unless it rings a bell I won´t probably be doing much about it like a git-bisect since that machine is slow and it could take ages… With Debian kernel 3.3.0-trunk-686-pae the machine suspends and resume for lots of times for 30-40 days uptime and more if I let it. With Debian kernel 3.4-trunk-686-pae as well as 3.5-trunk-686-pae tried out today often not always the kernel locks up hard after resume. That is, the image is read back but then when switching to graphics or shortly afterwards the mouse pointer is frozen and the machine does not respond to ping anymore. Graphics is ancient: deepdance:~> lspci -nn | grep VGA 01:00.0 VGA compatible controller [0300]: S3 Inc. SuperSavage IX/C SDR [5333:8c2e] (rev 05) CPU is Mobile Intel(R) Pentium(R) III CPU - M 1133MHz, the machine has 768 MiB of RAM. Filesystems are (aged) BTRFS (which contributes to the extreme slowness of the machine it seems – apt-get (dist-)upgrade without eatmydata takes long). Kernel parameters are: linux /vmlinuz-3.3.0-trunk-686-pae root=/dev/mapper/deepdance-debian ro vga=791 threadirqs init=/bin/systemd resume=/dev/mapper/deepdance-swap I didn´t report this with 3.4 cause I hoped that difficult to debug bug would just go away with 3.5, but it seems it didn´t. If it could just dump out something useful before it crashes… I am using threadirqs since quite some time on various machines, but I could try disabling it if it seems to be suspicious. I am back on 3.3 right now. It doesn´t matter that much on this machine. Unless any brilliant ideas I might just keep it at this report. Maybe it rings a bell for someone who has a suggestion to try out. I have 3.4 on ThinkPad T42 with some radeon chip and 3.4 and since some while 3.5 on ThinkPad T520 with Intel Sandybridge graphics – no issues there. So it only seems to affect this machine. T520 uses threadirqs, I think the T42 as well. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/3] perf tools: Initial bash completion support
On 8/9/12 10:35 AM, Arnaldo Carvalho de Melo wrote: Em Thu, Aug 09, 2012 at 04:31:51PM +0200, Frederic Weisbecker escreveu: This implements bash completion for perf subcommands such as record, report, script, probe, etc... Humm, I get this when doing my usual workflow: [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf install make: Entering directory `/home/git/linux/tools/perf' PERF_VERSION = 3.6.rc1.152.g5758f7 install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' install -d -m 755 '/home/acme/libexec/perf-core/scripts/python/bin' install scripts/python/Perf-Trace-Util/lib/Perf/Trace/* -t '/home/acme/libexec/perf-core/scripts/python/Perf-Trace-Util/lib/Perf/Trace' install scripts/python/*.py -t '/home/acme/libexec/perf-core/scripts/python' install scripts/python/bin/* -t '/home/acme/libexec/perf-core/scripts/python/bin' install -m 755 bash_completion /etc/bash_completion.d/perf install: cannot create regular file `/etc/bash_completion.d/perf': Permission denied make: *** [install] Error 1 make: Leaving directory `/home/git/linux/tools/perf' [acme@sandy linux]$ make -j8 -C tools/perf/ O=/home/acme/git/build/perf install Shouldn't it install on ~/etc/bash_completion.d/perf ? Is there a way to have per user bash completion files like that? 3rd patch should fix this. David -- 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 3/5] hda_intel: Add Device IDs for Intel Lynx Point-LP PCH
From: James Ralston
This patch adds the Intel HD Audio Device IDs for the Intel Lynx Point-LP PCH
Signed-off-by: James Ralston
---
sound/pci/hda/hda_intel.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index c8aced1..60882c6 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -151,6 +151,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6},"
"{Intel, CPT},"
"{Intel, PPT},"
"{Intel, LPT},"
+"{Intel, LPT_LP},"
"{Intel, HPT},"
"{Intel, PBG},"
"{Intel, SCH},"
@@ -3270,6 +3271,14 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = {
{ PCI_DEVICE(0x8086, 0x8c20),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_COMBO },
+ /* Lynx Point-LP */
+ { PCI_DEVICE(0x8086, 0x9c20),
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
+ AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_COMBO },
+ /* Lynx Point-LP */
+ { PCI_DEVICE(0x8086, 0x9c21),
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_SCH_SNOOP |
+ AZX_DCAPS_BUFSIZE | AZX_DCAPS_POSFIX_COMBO },
/* Haswell */
{ PCI_DEVICE(0x8086, 0x0c0c),
.driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP |
--
1.7.7.6
--
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] perf lock record: improve message when tracepoints are not enabled
If CONFIG options required for perf-lock are not enabled then the
corresponding tracepoints will not be enabled. Currently, the message to
the user is:
$ perf lock record -a -- sleep 1
invalid or unsupported event: 'lock:lock_acquire'
Run 'perf list' for a list of valid events
Improve the message with a suggestion on which CONFIG options are needed:
$ perf lock record -a -- sleep 1
tracepoint lock:lock_acquire is not enabled. Are CONFIG_LOCKDEP and
CONFIG_LOCK_STAT enabled?
Suggested-by: Arnaldo Carvalho de Melo
Signed-off-by: David Ahern
Cc: Arnaldo Carvalho de Melo
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
---
tools/perf/builtin-lock.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 3f8b955..585aae2 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -903,16 +903,19 @@ static const struct option lock_options[] = {
OPT_END()
};
+static const char * const lock_tracepoints[] = {
+ "lock:lock_acquire",/* CONFIG_LOCKDEP */
+ "lock:lock_acquired", /* CONFIG_LOCKDEP, CONFIG_LOCK_STAT */
+ "lock:lock_contended", /* CONFIG_LOCKDEP, CONFIG_LOCK_STAT */
+ "lock:lock_release",/* CONFIG_LOCKDEP */
+};
+
static const char *record_args[] = {
"record",
"-R",
"-f",
"-m", "1024",
"-c", "1",
- "-e", "lock:lock_acquire",
- "-e", "lock:lock_acquired",
- "-e", "lock:lock_contended",
- "-e", "lock:lock_release",
};
static int __cmd_record(int argc, const char **argv)
@@ -920,15 +923,31 @@ static int __cmd_record(int argc, const char **argv)
unsigned int rec_argc, i, j;
const char **rec_argv;
+ for (i = 0; i < ARRAY_SIZE(lock_tracepoints); i++) {
+ if (!is_valid_tracepoint(lock_tracepoints[i])) {
+ pr_err("tracepoint %s is not enabled. "
+ "Are CONFIG_LOCKDEP and CONFIG_LOCK_STAT
enabled?\n",
+ lock_tracepoints[i]);
+ return 1;
+ }
+ }
+
rec_argc = ARRAY_SIZE(record_args) + argc - 1;
- rec_argv = calloc(rec_argc + 1, sizeof(char *));
+ /* factor of 2 is for -e in front of each tracepoint */
+ rec_argc += 2 * ARRAY_SIZE(lock_tracepoints);
+ rec_argv = calloc(rec_argc + 1, sizeof(char *));
if (rec_argv == NULL)
return -ENOMEM;
for (i = 0; i < ARRAY_SIZE(record_args); i++)
rec_argv[i] = strdup(record_args[i]);
+ for (j = 0; j < ARRAY_SIZE(lock_tracepoints); j++) {
+ rec_argv[i++] = "-e";
+ rec_argv[i++] = strdup(lock_tracepoints[j]);
+ }
+
for (j = 1; j < (unsigned int)argc; j++, i++)
rec_argv[i] = argv[j];
--
1.7.10.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 2/5] ata_piix: Add Device IDs for Intel Lynx Point-LP PCH
From: James Ralston
This patch adds the IDE-mode SATA Device IDs for the Intel Lynx Point-LP PCH
Signed-off-by: James Ralston
---
drivers/ata/ata_piix.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 3c809bf..ef773e1 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -329,6 +329,14 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (Lynx Point-LP) */
+ { 0x8086, 0x9c00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Lynx Point-LP) */
+ { 0x8086, 0x9c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Lynx Point-LP) */
+ { 0x8086, 0x9c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ /* SATA Controller IDE (Lynx Point-LP) */
+ { 0x8086, 0x9c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (DH89xxCC) */
{ 0x8086, 0x2326, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
{ } /* terminate list */
--
1.7.7.6
--
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 07/11] mm: Allocate kernel pages to the right memcg
On Thu, Aug 09 2012, Glauber Costa wrote: > When a process tries to allocate a page with the __GFP_KMEMCG flag, the > page allocator will call the corresponding memcg functions to validate > the allocation. Tasks in the root memcg can always proceed. > > To avoid adding markers to the page - and a kmem flag that would > necessarily follow, as much as doing page_cgroup lookups for no reason, > whoever is marking its allocations with __GFP_KMEMCG flag is responsible > for telling the page allocator that this is such an allocation at > free_pages() time. This is done by the invocation of > __free_accounted_pages() and free_accounted_pages(). > > Signed-off-by: Glauber Costa > CC: Christoph Lameter > CC: Pekka Enberg > CC: Michal Hocko > CC: Kamezawa Hiroyuki > CC: Johannes Weiner > CC: Suleiman Souhlal > --- > include/linux/gfp.h | 3 +++ > mm/page_alloc.c | 38 ++ > 2 files changed, 41 insertions(+) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index d8eae4d..029570f 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -370,6 +370,9 @@ extern void free_pages(unsigned long addr, unsigned int > order); > extern void free_hot_cold_page(struct page *page, int cold); > extern void free_hot_cold_page_list(struct list_head *list, int cold); > > +extern void __free_accounted_pages(struct page *page, unsigned int order); > +extern void free_accounted_pages(unsigned long addr, unsigned int order); > + > #define __free_page(page) __free_pages((page), 0) > #define free_page(addr) free_pages((addr), 0) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index b956cec..da341dc 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2532,6 +2532,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int > order, > struct page *page = NULL; > int migratetype = allocflags_to_migratetype(gfp_mask); > unsigned int cpuset_mems_cookie; > + void *handle = NULL; > > gfp_mask &= gfp_allowed_mask; > > @@ -2543,6 +2544,13 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int > order, > return NULL; > > /* > + * Will only have any effect when __GFP_KMEMCG is set. > + * This is verified in the (always inline) callee > + */ > + if (!memcg_kmem_new_page(gfp_mask, , order)) > + return NULL; > + > + /* >* Check the zones suitable for the gfp_mask contain at least one >* valid zone. It's possible to have an empty zonelist as a result >* of GFP_THISNODE and a memoryless node If memcg_kmem_new_page() succeeds then it may have obtained a memcg reference with mem_cgroup_get(). I think this reference is leaked when returning below: /* * Check the zones suitable for the gfp_mask contain at least one * valid zone. It's possible to have an empty zonelist as a result * of GFP_THISNODE and a memoryless node */ if (unlikely(!zonelist->_zonerefs->zone)) return NULL; I suspect the easiest fix is to swap the call to memcg_kmem_new_page() and the (!zonelist->_zonerefs->zone) check. -- 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: comedi: ssv_snp: fix checkpatch.pl warnings
On Thursday, August 09, 2012 8:20 AM, Güngör Erseymen wrote:
> Fix two checkpatch.pl warnings about printk issues by using
> pr_info(...) instead of printk(KERN_INFO, ...).
>
> Signed-off-by: Güngör Erseymen
> ---
> drivers/staging/comedi/drivers/ssv_dnp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Hello Güngör,
You have a typo in the subject for this patch.
"ssv_snp" should be "ssv_dnp"
>
> diff --git a/drivers/staging/comedi/drivers/ssv_dnp.c
> b/drivers/staging/comedi/drivers/ssv_dnp.c
> index 84b9f2a..4cd0f1b 100644
> --- a/drivers/staging/comedi/drivers/ssv_dnp.c
> +++ b/drivers/staging/comedi/drivers/ssv_dnp.c
> @@ -177,7 +177,7 @@ static int dnp_attach(struct comedi_device *dev, struct
> comedi_devconfig *it)
> struct comedi_subdevice *s;
> int ret;
>
> - printk(KERN_INFO "comedi%d: dnp: ", dev->minor);
> + pr_info("comedi%d: dnp: ", dev->minor);
Where possible, fixes like this should use the dev_printk versions.
For instance, this one would be:
dev_info(dev->class_dev, "dnp:");
But, there is a cleaner fix for this file. See below.
> dev->board_name = board->name;
>
> @@ -195,7 +195,7 @@ static int dnp_attach(struct comedi_device *dev, struct
> comedi_devconfig *it)
> s->insn_bits = dnp_dio_insn_bits;
> s->insn_config = dnp_dio_insn_config;
>
> - printk("attached\n");
> + pr_info("attached\n");
There are only two printk's in this file, both in the "attach" routine.
The first one does not have a "\n" and the function could exit without
ever terminating the message.
A better fix would be to merge the two messages into one "attached" message
at the end of the function. You could also use the dev->board_name instead of
the open coded string. Something like:
dev_info(dev->class_dev, "%s: attached\n", dev->board_name);
Also, the message should be moved so that it's the last thing that happens
before the function returns.
Regards,
Hartley
>
> /* We use the I/O ports 0x22,0x23 and 0xa3-0xa9, which are always
>* allocated for the primary 8259, so we don't need to allocate them
--
1.7.11.4
Re: [PATCH 1/8] of/irq: Create stub for of_irq_find_parent when !CONFIG_OF
On 08/09/2012 10:53 AM, Lee Jones wrote:
> of_irq_find_parent is a handy function to use outside the confines of
> the Open Firmware subsystem. One such use-case is when the IRQ Domain
> wishes to find an IRQ domain for a given device node. Currently it can
> not take any notice of the 'interrupt-parent' property. Instead it
> just uses the first IRQ controller as it climbs the Device Tree. If
> we were to use this as a precursor the resultant controller is more
> likely to be correct.
Where are you using this? I don't have all the patches in the series.
Rob
>
> CC: Rob Herring
> CC: devicetree-disc...@lists.ozlabs.org
> Signed-off-by: Lee Jones
> ---
> include/linux/of_irq.h |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index 1717cd9..b8e2411 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -83,6 +83,11 @@ static inline unsigned int irq_of_parse_and_map(struct
> device_node *dev,
> {
> return 0;
> }
> +
> +static inline void *of_irq_find_parent(struct device_node *child)
> +{
> + return NULL;
> +}
> #endif /* !CONFIG_OF */
>
> #endif /* __OF_IRQ_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/
Re: RFC: mutex: hung tasks on SMP platforms with asm-generic/mutex-xchg.h
On Thu, 9 Aug 2012, Will Deacon wrote:
> I think we could actually fix this entirely in mutex-xchg.h by doing
> something in fastpath_lock similar to what we do for trylock:
>
>
> diff --git a/include/asm-generic/mutex-xchg.h
> b/include/asm-generic/mutex-xchg.h
> index 580a6d3..c082e99 100644
> --- a/include/asm-generic/mutex-xchg.h
> +++ b/include/asm-generic/mutex-xchg.h
> @@ -25,8 +25,19 @@
> static inline void
> __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
> {
> - if (unlikely(atomic_xchg(count, 0) != 1))
> - fail_fn(count);
> + int prev = atomic_xchg(count, 0);
> +
> + if (unlikely(prev != 1)) {
> + if (prev < 0)
> + /*
> +* The lock was contended, so we need to restore
> +* its original state to ensure that any waiting
> +* tasks are woken up by the unlock slow path.
> +*/
> + prev = atomic_xchg(count, prev);
> + if (prev != 1)
> + fail_fn(count);
> + }
> }
>
> What do you reckon?
Yes, that looks fine. I'd remove that if (prev < 0) entirely though.
We'll just swap a 0 for a 0 if the count wasn't < 0, or a 0 for a 1 if
the mutex just got unlocked which is also fine. This is especially
beneficial when a native xchg processor instruction is used.
> > Of course that might tilt the balance towards using mutex-dec.h on ARM
> > v6 and above instead of mutex-xchg.h. But that is an orthogonal issue,
> > and that doesn't remove the need for fixing the xchg based case for
> > correctness.
>
> I'll do some hackbench runs against mutex-dec once we've decided on the final
> xchg code. If it's faster, I'll submit a patch for ARM.
I don't think it would be faster. It is just potentially more fair.
Nicolas
--
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] regulator: core: Use list_voltage() to read single voltage regulators
On 08/09/2012 09:45 AM, Mark Brown wrote:
> If the regulator doesn't supply a way of reading back the voltage but does
> provide a list_voltage() operation then use that with a selector of zero
> to read the voltage.
Ah, this makes sense. The only issue is:
static int add_regulator_attributes(struct regulator_dev *rdev)
...
if ((ops->get_voltage && ops->get_voltage(rdev) >= 0) ||
(ops->get_voltage_sel && ops->get_voltage_sel(rdev) >= 0)) {
status = device_create_file(dev, _attr_microvolts);
so the microvolts file doesn't get created.
--
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] Intel xhci: Only switch the switchable ports
On Thu, Aug 9, 2012 at 10:24 PM, Sarah Sharp
wrote:
> On Thu, Aug 09, 2012 at 05:31:51PM +0800, Keng-Yu Lin wrote:
>> With a previous patch to enable the EHCI/XHCI port switching, it switches
>> all the available ports.
>>
>> The assumption is not correct because the BIOS may expect some ports
>> not switchable by the OS.
>
> Why would the BIOS expect some ports to not be switchable? I know that
> we internally at Intel had discussed some theoretical reasons why it
> might not be good to switch some ports, but when I presented the
> original patch with this same code in it to Linux USB mailing list, both
> Alan and Greg said, "Why not unconditionally switch ports?" I had no
> good examples at the time.
>
> Is this causing issues with some particular BIOS?
>
Yes, this is causing the internal webcam missing on the USB bus as I
observed on some HM70-based laptops.
The internal webcam is attached to one port that is controlled by the
xhci host.
But the other ports with the outer plugs work well after booting. I
cannot test the USB port of the internal webcam easily (without
tearing down the laptop :-/).
I also tried some similar HM77-based models. HM77 has no this issue.
This could be some chipset mystery I am not aware now.
Some bisecting led to your original patch.
>> There are two more registers that contains the information of the switchable
>> and non-switchable ports.
>>
>> This patch adds the checking code for the two register so that only the
>> switchable ports are altered.
>>
>> Signed-off-by: Keng-Yu Lin
>> ---
>> drivers/usb/host/pci-quirks.c | 27 +++
>> 1 file changed, 23 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
>> index 833b3c6..89f62f2 100644
>> --- a/drivers/usb/host/pci-quirks.c
>> +++ b/drivers/usb/host/pci-quirks.c
>> @@ -75,7 +75,9 @@
>> #define NB_PIF0_PWRDOWN_1 0x01100013
>>
>> #define USB_INTEL_XUSB2PR 0xD0
>> +#define USB_INTEL_USB2PRM 0xD4
>> #define USB_INTEL_USB3_PSSEN 0xD8
>> +#define USB_INTEL_USB3PRM 0xDC
>>
>> static struct amd_chipset_info {
>> struct pci_dev *nb_dev;
>> @@ -772,10 +774,18 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
>> return;
>> }
>>
>> - ports_available = 0x;
>> + /* Read USB3PRM, the USB 3.0 Port Routing Mask Register
>> + * Indicate the ports that can be changed from OS.
>> + */
>> + pci_read_config_dword(xhci_pdev, USB_INTEL_USB3PRM,
>> + _available);
>> +
>> + dev_dbg(_pdev->dev, "Configurable ports to enable SuperSpeed:
>> 0x%x\n",
>> + ports_available);
>> +
>> /* Write USB3_PSSEN, the USB 3.0 Port SuperSpeed Enable
>> - * Register, to turn on SuperSpeed terminations for all
>> - * available ports.
>> + * Register, to turn on SuperSpeed terminations for the
>> + * switchable ports.
>>*/
>> pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
>> cpu_to_le32(ports_available));
>> @@ -785,7 +795,16 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
>> dev_dbg(_pdev->dev, "USB 3.0 ports that are now enabled "
>> "under xHCI: 0x%x\n", ports_available);
>>
>> - ports_available = 0x;
>> + /* Read XUSB2PRM, xHCI USB 2.0 Port Routing Mask Register
>> + * Indicate the port to be controlled by the EHCI host.
>
> Your code is correct, but your comment is wrong. XUSB2PRM is the USB
> 2.0 ports that should be controlled by the xHCI host.
>
Thanks for the explanation.
>> + */
>> +
>> + pci_read_config_dword(xhci_pdev, USB_INTEL_USB2PRM,
>> + _available);
>> +
>> + dev_dbg(_pdev->dev, "Configurable ports to hand over the ECHI
>> host:
>> + 0x%x\n", ports_available);
>
> Again, this should be "Configurable USB 2.0 ports to hand over to xHCI:"
> Also, don't split strings, it makes it hard to grep for them later.
>
Thanks. I will re-sent a patch with the correct comment.
>> +
>> /* Write XUSB2PR, the xHC USB 2.0 Port Routing Register, to
>>* switch the USB 2.0 power and data lines over to the xHCI
>>* host.
>
> Sarah Sharp
-kengyu
--
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] ipv4: tcp: security_sk_alloc() needed for unicast_sock
On Thu, Aug 9, 2012 at 12:05 PM, Eric Paris wrote: > Paul, are you looking into this? This is a bandaide, not a fix Yep, I mentioned this a few times in the other thread. The problem is there is not going to be an easy fix for the labeling so I'd rather we see this patch, or something like it, go in now to resolve the kernel panic, and fix the labeling later. -- paul moore www.paul-moore.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/2] ARM: build ssi-fiq.S in ARM mode to prevent CONFIG_THUMB2_KERNEL build breakage
On Thu, Aug 9, 2012 at 9:50 AM, Dave Martin wrote: > On Thu, Aug 09, 2012 at 09:32:59AM -0500, Matt Sealey wrote: >> Matt Sealey >> Product Development Analyst, Genesi USA, Inc. >> >> >> On Thu, Aug 9, 2012 at 5:24 AM, Dave Martin wrote: >> > On Wed, Aug 08, 2012 at 12:32:39PM -0500, Matt Sealey wrote: >> > >> > [...] >> > >> >> I'm going to do a trapse through and find where Russell nacked Dave's >> >> thumb-aware >> >> rewrite.. would you mind if you have any of these boards seeing if it >> >> really DOES >> > >> > There was no NAK because I didn't get as far as posting the patch, >> >> http://lists.arm.linux.org.uk/lurker/message/20111202.133911.393b6e28.en.html >> >> You did, twice :) > > Well, I meant that I had not posted it as a stand-alone patch for > inclusion; I only posted it when commenting on other threads. > >> > mostly because of the doubt about whether this code is ever relevant >> > on Thumb2-capable hardware. >> >> It's not, but it does break the build, and without disabling phyCORE boards >> for >> Thumb2 it will always break the build.. > > If you want me to push it, let me know. I don't think this should get > merged without some Tested-bys for hardware where the FIQ stuff actually > gets used. Please, then all the Tested-by's should flood in, right? :) > The older post would be the one to use, since that at least got a > reasonable level of build testing. -- Matt Sealey Product Development Analyst, Genesi USA, Inc. -- 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] ipv4: tcp: security_sk_alloc() needed for unicast_sock
On Thu, Aug 9, 2012 at 11:36 AM, Eric Dumazet wrote: > On Thu, 2012-08-09 at 11:07 -0400, Paul Moore wrote: > >> Is is possible to do the call to security_sk_alloc() in the ip_init() >> function >> or does the per-cpu nature of the socket make this a pain? >> > > Its a pain, if we want NUMA affinity. > > Here, each cpu should get memory from its closest node. I really really don't like it. I won't say NAK, but it is the first and only place in the kernel where I believe we allocate an object and don't allocate the security blob until some random later point in time. If it is such a performance issue to have the security blob in the same numa node, isn't adding a number of branches and putting this function call on every output at least as bad? Aren't we discouraged from GFP_ATOMIC? In __init we can use GFP_KERNEL. This still doesn't fix these sockets entirely. We now have the security blob allocated, but it was never set to something useful. Paul, are you looking into this? This is a bandaide, not a fix -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/
[PATCH 1/5] ahci: Add Device IDs for Intel Lynx Point-LP PCH
From: James Ralston
This patch adds the AHCI-mode SATA Device IDs for the Intel Lynx Point-LP PCH
Signed-off-by: James Ralston
---
drivers/ata/ahci.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index ebaf67e..c590259 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -267,6 +267,14 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x8c07), board_ahci }, /* Lynx Point RAID */
{ PCI_VDEVICE(INTEL, 0x8c0e), board_ahci }, /* Lynx Point RAID */
{ PCI_VDEVICE(INTEL, 0x8c0f), board_ahci }, /* Lynx Point RAID */
+ { PCI_VDEVICE(INTEL, 0x9c02), board_ahci }, /* Lynx Point-LP AHCI */
+ { PCI_VDEVICE(INTEL, 0x9c03), board_ahci }, /* Lynx Point-LP AHCI */
+ { PCI_VDEVICE(INTEL, 0x9c04), board_ahci }, /* Lynx Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c05), board_ahci }, /* Lynx Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c06), board_ahci }, /* Lynx Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c07), board_ahci }, /* Lynx Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c0e), board_ahci }, /* Lynx Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c0f), board_ahci }, /* Lynx Point-LP RAID */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
--
1.7.7.6
--
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 2/2] Btrfs merge fix
Hi Linus, Please pull my for-linus-3.6 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-3.6 It fixes a merging error in rc1. The calls to mnt_want_write should have been removed. Alexander Block (1): Btrfs: remove mnt_want_write call in btrfs_mksubvol fs/btrfs/ioctl.c | 5 - 1 file changed, 5 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/
[PATCH 01/22] ARM: ux500: Fix merge error, no matching driver name for 'snd_soc_u8500'
The platform attempts to register platform device 'snd_soc_u8500'
which doesn't actually exist. Here we change the reference to the
correct one 'snd_soc_mop500'.
Signed-off-by: Lee Jones
---
arch/arm/mach-ux500/board-mop500-msp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-msp.c
b/arch/arm/mach-ux500/board-mop500-msp.c
index 9960480..df15646 100644
--- a/arch/arm/mach-ux500/board-mop500-msp.c
+++ b/arch/arm/mach-ux500/board-mop500-msp.c
@@ -191,9 +191,9 @@ static struct platform_device *db8500_add_msp_i2s(struct
device *parent,
return pdev;
}
-/* Platform device for ASoC U8500 machine */
-static struct platform_device snd_soc_u8500 = {
- .name = "snd-soc-u8500",
+/* Platform device for ASoC MOP500 machine */
+static struct platform_device snd_soc_mop500 = {
+ .name = "snd-soc-mop500",
.id = 0,
.dev = {
.platform_data = NULL,
@@ -227,8 +227,8 @@ int mop500_msp_init(struct device *parent)
{
struct platform_device *msp1;
- pr_info("%s: Register platform-device 'snd-soc-u8500'.\n", __func__);
- platform_device_register(_soc_u8500);
+ pr_info("%s: Register platform-device 'snd-soc-mop500'.\n", __func__);
+ platform_device_register(_soc_mop500);
pr_info("Initialize MSP I2S-devices.\n");
db8500_add_msp_i2s(parent, 0, U8500_MSP0_BASE, IRQ_DB8500_MSP0,
--
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/
[PATCH 02/22] ARM: ux500: Ensure probing of Audio devices when Device Tree is enabled
Previous attempts to add platform probing of the Audio related devices
only call from non-DT initialisation functions. This patch extends that
functionality to the Device Tree related ones too.
Signed-off-by: Lee Jones
---
arch/arm/mach-ux500/board-mop500.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-ux500/board-mop500.c
b/arch/arm/mach-ux500/board-mop500.c
index f413587..5d9600b 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -799,6 +799,7 @@ static void __init u8500_init_machine(void)
ARRAY_SIZE(mop500_platform_devs));
mop500_sdi_init(parent);
+ mop500_msp_init(parent);
i2c0_devs = ARRAY_SIZE(mop500_i2c0_devices);
i2c_register_board_info(0, mop500_i2c0_devices, i2c0_devs);
i2c_register_board_info(2, mop500_i2c2_devices,
@@ -806,6 +807,8 @@ static void __init u8500_init_machine(void)
mop500_uib_init();
+ } else if (of_machine_is_compatible("calaosystems,snowball-a9500")) {
+ mop500_msp_init(parent);
} else if (of_machine_is_compatible("st-ericsson,hrefv60+")) {
/*
* The HREFv60 board removed a GPIO expander and routed
@@ -817,6 +820,7 @@ static void __init u8500_init_machine(void)
ARRAY_SIZE(mop500_platform_devs));
hrefv60_sdi_init(parent);
+ mop500_msp_init(parent);
i2c0_devs = ARRAY_SIZE(mop500_i2c0_devices);
i2c0_devs -= NUM_PRE_V60_I2C0_DEVICES;
--
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] ipv4: tcp: security_sk_alloc() needed for unicast_sock
On Thu, Aug 9, 2012 at 11:36 AM, Eric Dumazet wrote: > On Thu, 2012-08-09 at 11:07 -0400, Paul Moore wrote: > >> Is is possible to do the call to security_sk_alloc() in the ip_init() >> function >> or does the per-cpu nature of the socket make this a pain? >> > > Its a pain, if we want NUMA affinity. > > Here, each cpu should get memory from its closest node. Okay, makes sense. Acked-by: Paul Moore -- paul moore www.paul-moore.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/
Linux 3.5.1
I'm announcing the release of the 3.5.1 kernel. All users of the 3.5 kernel series must upgrade. The updated 3.5.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.5.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/sound/alsa/HD-Audio-Models.txt|3 Documentation/stable_kernel_rules.txt | 19 +- Makefile|2 arch/arm/boot/dts/tegra-trimslice.dts |2 arch/arm/mach-omap2/opp.c |3 arch/m68k/kernel/sys_m68k.c |8 - arch/mips/kernel/kspd.c |2 arch/powerpc/boot/dts/p1022ds.dtsi | 16 -- arch/powerpc/include/asm/reg.h |3 arch/powerpc/kernel/ftrace.c| 12 - arch/powerpc/platforms/85xx/p1022_ds.c | 106 -- arch/powerpc/platforms/pseries/eeh_event.c |6 arch/s390/include/asm/mmu_context.h | 14 + arch/s390/include/asm/processor.h |2 arch/s390/kernel/processor.c|2 arch/s390/kernel/smp.c |3 arch/s390/mm/fault.c| 13 - arch/s390/mm/mmap.c | 12 + arch/s390/mm/pgtable.c |5 arch/x86/kernel/cpu/mcheck/mce.c|6 arch/x86/kernel/microcode_core.c| 26 ++- drivers/acpi/ac.c |4 drivers/acpi/apei/apei-base.c |5 drivers/base/power/main.c | 10 + drivers/char/tpm/tpm.c | 12 + drivers/gpu/drm/nouveau/nouveau_drv.h |2 drivers/gpu/drm/nouveau/nouveau_irq.c |4 drivers/gpu/drm/nouveau/nouveau_software.h |1 drivers/gpu/drm/nouveau/nva3_copy.fuc |4 drivers/gpu/drm/nouveau/nva3_copy.fuc.h | 94 drivers/gpu/drm/nouveau/nvc0_copy.fuc.h | 87 +++- drivers/gpu/drm/radeon/atombios_dp.c| 10 - drivers/gpu/drm/radeon/atombios_encoders.c | 12 + drivers/gpu/drm/radeon/radeon_connectors.c | 35 +++- drivers/gpu/drm/radeon/radeon_cs.c |2 drivers/gpu/drm/radeon/radeon_cursor.c |8 - drivers/gpu/drm/radeon/radeon_object.c |3 drivers/hid/hid-multitouch.c| 13 + drivers/iommu/amd_iommu.c | 17 +- drivers/iommu/amd_iommu_v2.c|2 drivers/md/dm-thin.c|7 drivers/mmc/host/sdhci-pci.c|1 drivers/mmc/host/sdhci.c|8 - drivers/net/caif/caif_serial.c |3 drivers/net/ethernet/atheros/atl1c/atl1c_hw.h |5 drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 16 ++ drivers/net/ethernet/broadcom/tg3.c | 10 - drivers/net/ethernet/emulex/benet/be_ethtool.c |5 drivers/net/ethernet/emulex/benet/be_main.c |2 drivers/net/ethernet/realtek/r8169.c| 27 --- drivers/net/tun.c |9 - drivers/net/usb/kaweth.c|2 drivers/net/wireless/b43/b43.h |7 drivers/net/wireless/b43/main.c | 32 +--- drivers/net/wireless/iwlwifi/iwl-agn-lib.c |5 drivers/net/wireless/iwlwifi/iwl-agn-sta.c |1 drivers/net/wireless/mwifiex/cfg80211.c |4 drivers/net/wireless/rt2x00/rt2800usb.c |3 drivers/net/wireless/rtlwifi/rtl8192de/phy.c|6 drivers/net/wireless/rtlwifi/usb.c | 14 + drivers/net/wireless/rtlwifi/wifi.h |1 drivers/s390/net/qeth_l3_main.c |4 drivers/scsi/hosts.c|7 drivers/scsi/libsas/sas_expander.c | 47 ++ drivers/scsi/scsi_error.c | 14 + drivers/scsi/scsi_lib.c | 43 ++--- drivers/scsi/scsi_priv.h|1 drivers/scsi/scsi_scan.c|3 drivers/scsi/scsi_sysfs.c | 46 +++--- drivers/spi/spi-pl022.c |5 drivers/staging/zsmalloc/zsmalloc-main.c| 33 drivers/target/iscsi/iscsi_target.c | 22 --- drivers/target/iscsi/iscsi_target_core.h|2 drivers/target/iscsi/iscsi_target_login.c | 60 drivers/target/target_core_transport.c | 10 + drivers/usb/core/devio.c| 10 - drivers/usb/core/hub.c | 26 +-- drivers/usb/core/message.c |8 - drivers/usb/core/usb.c
Re: [PATCH 3/3] drivers/char/tpm: Add securityfs support for event log
Hi Ashley,
> diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> index 547509d..b53da57 100644
> --- a/drivers/char/tpm/Makefile
> +++ b/drivers/char/tpm/Makefile
> @@ -2,9 +2,15 @@
> # Makefile for the kernel tpm device drivers.
> #
> obj-$(CONFIG_TCG_TPM) += tpm.o
> +obj-$(CONFIG_TCG_TPM) += tpm_bios.o
> ifdef CONFIG_ACPI
> - obj-$(CONFIG_TCG_TPM) += tpm_bios.o
> tpm_bios-objs += tpm_eventlog.o tpm_acpi.o
> +else
> +ifdef CONFIG_TCG_IBMVTPM
> + tpm_bios-objs += tpm_eventlog.o tpm_of.o
> +else
> + tpm_bios-objs += tpm_eventlog.o tpm_noeventlog.o
tpm_eventlog.c is included in all cases here...
> diff --git a/drivers/char/tpm/tpm_eventlog.h b/drivers/char/tpm/tpm_eventlog.h
> index 8e23ccd..5fbea94 100644
> --- a/drivers/char/tpm/tpm_eventlog.h
> +++ b/drivers/char/tpm/tpm_eventlog.h
> @@ -68,4 +68,28 @@ enum tcpa_pc_event_ids {
> };
>
> int read_log(struct tpm_bios_log *log);
> +
> +#if defined(CONFIG_ACPI) || defined(CONFIG_PPC64)
> +extern struct dentry **tpm_bios_log_setup(char *);
> +extern void tpm_bios_log_teardown(struct dentry **);
> +#else
> +static inline struct dentry **tpm_bios_log_setup(char *name)
> +{
> + return NULL;
> +}
> +static inline void tpm_bios_log_teardown(struct dentry **dir)
> +{
> +}
> +#endif
But here, without acpi or ppc64, we compile in stubs, which breaks
things. It looks like we don't need these stubs at all anymore, and can
rely on TPM_NO_EVENT_LOG to bail out in the cases on x86 where ACPI is
disabled.
Kent
> +
> +#ifdef CONFIG_PPC64
> +#define TPM_NO_EVENT_LOG !of_find_node_by_name(NULL, "ibm,vtpm")
> +#else
> +#ifdef CONFIG_ACPI
> +#define TPM_NO_EVENT_LOG 0
> +#else
> +#define TPM_NO_EVENT_LOG 1
> +#endif
> +#endif
> +
> #endif
> diff --git a/drivers/char/tpm/tpm_noeventlog.c
> b/drivers/char/tpm/tpm_noeventlog.c
> new file mode 100644
> index 000..f30a2bf
> --- /dev/null
> +++ b/drivers/char/tpm/tpm_noeventlog.c
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (C) 2012 IBM Corporation
> + *
> + * Author: Ashley Lai
> + *
> + * Maintained by:
> + *
> + * 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.
> + *
> + */
> +
> +#include
> +#include "tpm_eventlog.h"
> +
> +int read_log(struct tpm_bios_log *log)
> +{
> + return -EINVAL;
> +}
> diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
> new file mode 100644
> index 000..6d44adb
> --- /dev/null
> +++ b/drivers/char/tpm/tpm_of.c
> @@ -0,0 +1,68 @@
> +/*
> + * Copyright 2012 IBM Corporation
> + *
> + * Author: Ashley Lai
> + *
> + * Maintained by:
> + *
> + * Read the event log created by the firmware on PPC64
> + *
> + * 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.
> + *
> + */
> +
> +#include
> +#include
> +
> +#include "tpm.h"
> +#include "tpm_eventlog.h"
> +
> +int read_log(struct tpm_bios_log *log)
> +{
> + struct device_node *np;
> + const u32 *sizep;
> + const __be64 *basep;
> +
> + if (log->bios_event_log != NULL) {
> + pr_err("%s: ERROR - Eventlog already initialized\n", __func__);
> + return -EFAULT;
> + }
> +
> + np = of_find_node_by_name(NULL, "ibm,vtpm");
> + if (!np) {
> + pr_err("%s: ERROR - IBMVTPM not supported\n", __func__);
> + return -ENODEV;
> + }
> +
> + sizep = of_get_property(np, "linux,sml-size", NULL);
> + if (sizep == NULL) {
> + pr_err("%s: ERROR - SML size not found\n", __func__);
> + return -EIO;
> + }
> + if (*sizep == 0) {
> + pr_err("%s: ERROR - event log area empty\n", __func__);
> + return -EIO;
> + }
> +
> + basep = of_get_property(np, "linux,sml-base", NULL);
> + if (basep == NULL) {
> + pr_err(KERN_ERR "%s: ERROR - SML not found\n", __func__);
> + return -EIO;
> + }
> +
> + log->bios_event_log = kmalloc(*sizep, GFP_KERNEL);
> + if (!log->bios_event_log) {
> + pr_err("%s: ERROR - Not enough memory for BIOS measurements\n",
> +__func__);
> + return -ENOMEM;
> + }
> +
> + log->bios_event_log_end = log->bios_event_log + *sizep;
> +
> + memcpy(log->bios_event_log, __va(be64_to_cpup(basep)), *sizep);
> +
> + return 0;
> +}
> --
> 1.7.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 1/1] drivers/rtc/rtc-ab8500.c: Revoke Device Tree enablement
All AB8500 devices are now registered via MFD core, so Device Tree
capability is no longer required for probing. Here we pull the DT
match table to ensure we're no longer probed during Device Tree
start-up.
CC: Alessandro Zummo
CC: rtc-li...@googlegroups.com
Signed-off-by: Lee Jones
---
drivers/rtc/rtc-ab8500.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8500.c
index bf3c2f6..2e5970f 100644
--- a/drivers/rtc/rtc-ab8500.c
+++ b/drivers/rtc/rtc-ab8500.c
@@ -462,16 +462,10 @@ static int __devexit ab8500_rtc_remove(struct
platform_device *pdev)
return 0;
}
-static const struct of_device_id ab8500_rtc_match[] = {
- { .compatible = "stericsson,ab8500-rtc", },
- {}
-};
-
static struct platform_driver ab8500_rtc_driver = {
.driver = {
.name = "ab8500-rtc",
.owner = THIS_MODULE,
- .of_match_table = ab8500_rtc_match,
},
.probe = ab8500_rtc_probe,
.remove = __devexit_p(ab8500_rtc_remove),
--
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/
