* [PATCH v3 01/21 resend] serial: rewrite pxa2xx-uart to use 8250_core
From: Sergei Ianovich @ 2013-12-19 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387445713.31516.30.camel@host5.omatika.ru>
On Thu, 2013-12-19 at 13:35 +0400, Sergei Ianovich wrote:
> Hi Heikki,
>
> On Thu, 2013-12-19 at 10:51 +0200, Heikki Krogerus wrote:
> > I noticed one more thing. I'm sorry about commenting this late.
> >
> > Since you set the type PORT_XSCALE, don's you want to use
> > UPF_FIXED_TYPE flag instead of the UPF_SKIP_TEST here? Otherwise the
> > type will just get overridden and autoconfig() will be executed.
>
> UPF_FIXED_PORT was my first guess. However, it didn't work.
>
> I've also tried to do ioremap in serial_pxa_probe instead of using
> UPF_IOREMAP. This didn't work as well.
I didn't clarify properly.
UPF_SKIP_TEST skips only the loopback test. This test could work on PXA,
but requires PXA-specific pre-initialization. There are more test after
the loopback one, which will fail if we are not on PXA. So I decided
that skipping it is easier than tricky rewriting of autoconfig().
^ permalink raw reply
* Re: [PATCH] mm/memory-failure.c: transfer page count from head page to tail page after split thp
From: Wanpeng Li @ 2013-12-19 9:59 UTC (permalink / raw)
To: Naoya Horiguchi; +Cc: Andi Kleen, Andrew Morton, linux-mm, linux-kernel
In-Reply-To: <1387444174-16752-1-git-send-email-n-horiguchi@ah.jp.nec.com>
On Thu, Dec 19, 2013 at 04:09:34AM -0500, Naoya Horiguchi wrote:
>Memory failures on thp tail pages cause kernel panic like below:
>
> [ 317.361821] mce: [Hardware Error]: Machine check events logged
> [ 317.361831] MCE exception done on CPU 7
> [ 317.362007] BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
> [ 317.362015] IP: [<ffffffff811b7cd1>] dequeue_hwpoisoned_huge_page+0x131/0x1e0
> [ 317.362017] PGD bae42067 PUD ba47d067 PMD 0
> [ 317.362019] Oops: 0000 [#1] SMP
> ...
> [ 317.362052] CPU: 7 PID: 128 Comm: kworker/7:2 Tainted: G M O 3.13.0-rc4-131217-1558-00003-g83b7df08e462 #25
> ...
> [ 317.362083] Call Trace:
> [ 317.362091] [<ffffffff811d9bae>] me_huge_page+0x3e/0x50
> [ 317.362094] [<ffffffff811dab9b>] memory_failure+0x4bb/0xc20
> [ 317.362096] [<ffffffff8106661e>] mce_process_work+0x3e/0x70
> [ 317.362100] [<ffffffff810b1e21>] process_one_work+0x171/0x420
> [ 317.362102] [<ffffffff810b2c1b>] worker_thread+0x11b/0x3a0
> [ 317.362105] [<ffffffff810b2b00>] ? manage_workers.isra.25+0x2b0/0x2b0
> [ 317.362109] [<ffffffff810b93c4>] kthread+0xe4/0x100
> [ 317.362112] [<ffffffff810b92e0>] ? kthread_create_on_node+0x190/0x190
> [ 317.362117] [<ffffffff816e3c6c>] ret_from_fork+0x7c/0xb0
> [ 317.362119] [<ffffffff810b92e0>] ? kthread_create_on_node+0x190/0x190
> ...
> [ 317.362162] RIP [<ffffffff811b7cd1>] dequeue_hwpoisoned_huge_page+0x131/0x1e0
> [ 317.362163] RSP <ffff880426699cf0>
> [ 317.362164] CR2: 0000000000000058
>
>The reasoning of this problem is shown below:
> - when we have a memory error on a thp tail page, the memory error
> handler grabs a refcount of the head page to keep the thp under us.
> - Before unmapping the error page from processes, we split the thp,
> where page refcounts of both of head/tail pages don't change.
> - Then we call try_to_unmap() over the error page (which was a tail
> page before). We didn't pin the error page to handle the memory error,
> this error page is freed and removed from LRU list.
> - We never have the error page on LRU list, so the first page state
> check returns "unknown page," then we move to the second check
> with the saved page flag.
> - The saved page flag have PG_tail set, so the second page state check
> returns "hugepage."
> - We call me_huge_page() for freed error page, then we hit the above panic.
>
>The root cause is that we didn't move refcount from the head page to
>the tail page after split thp. So this patch suggests to do this.
>
>This panic was introduced by commit 524fca1e73 "HWPOISON: fix misjudgement
>of page_action() for errors on mlocked pages." Note that we did have
>the same refcount problem before this commit, but it was just ignored
>because we had only first page state check which returned "unknown page."
>The commit changed the refcount problem from "doesn't work" to "kernel panic."
>
>Cc: stable@vger.kernel.org # 3.9+
>Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
>---
> mm/memory-failure.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
>diff --git v3.13-rc4.orig/mm/memory-failure.c v3.13-rc4/mm/memory-failure.c
>index db08af92c6fc..fabe55046c1d 100644
>--- v3.13-rc4.orig/mm/memory-failure.c
>+++ v3.13-rc4/mm/memory-failure.c
>@@ -938,6 +938,16 @@ static int hwpoison_user_mappings(struct page *p, unsigned long pfn,
> BUG_ON(!PageHWPoison(p));
> return SWAP_FAIL;
> }
>+ /*
>+ * We pinned the head page for hwpoison handling,
>+ * now we split the thp and we are interested in
>+ * the hwpoisoned raw page, so move the refcount
>+ * to it.
>+ */
>+ if (hpage != p) {
>+ put_page(hpage);
>+ get_page(p);
>+ }
> /* THP is split, so ppage should be the real poisoned page. */
> ppage = p;
> }
>--
>1.8.3.1
>
>--
>To unsubscribe, send a message with 'unsubscribe linux-mm' in
>the body to majordomo@kvack.org. For more info on Linux MM,
>see: http://www.linux-mm.org/ .
>Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 13/13] drivers: block: Remove unused function in genl_magic_func.h
From: Josh Triplett @ 2013-12-19 9:59 UTC (permalink / raw)
To: Rashika Kheria; +Cc: linux-kernel, David S. Miller, Johannes Berg
In-Reply-To: <6ad65a8d9a9f0467f2ad080e0a4db7ea49142371.1387445397.git.rashika.kheria@gmail.com>
On Thu, Dec 19, 2013 at 03:22:10PM +0530, Rashika Kheria wrote:
> Remove unused function CONCAT_(GENL_MAGIC_FAMILY, _genl_cmd_to_str) in
> include/linux/genl_magic_func.h.
>
> This eliminates the following warning in
> include/linux/genl_magic_func.h:
> include/linux/genl_magic_func.h:221:1: warning: no previous prototype for ‘drbd_genl_cmd_to_str’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> include/linux/genl_magic_func.h | 16 ----------------
> 1 file changed, 16 deletions(-)
>
> diff --git a/include/linux/genl_magic_func.h b/include/linux/genl_magic_func.h
> index c0894dd..0456ad8 100644
> --- a/include/linux/genl_magic_func.h
> +++ b/include/linux/genl_magic_func.h
> @@ -214,22 +214,6 @@ static int s_name ## _from_attrs_for_change(struct s_name *s, \
> #undef GENL_struct
> #define GENL_struct(tag_name, tag_number, s_name, s_fields)
>
> -/*
> - * Magic: define op number to op name mapping {{{1
> - * {{{2
> - */
> -const char *CONCAT_(GENL_MAGIC_FAMILY, _genl_cmd_to_str)(__u8 cmd)
> -{
> - switch (cmd) {
> -#undef GENL_op
> -#define GENL_op(op_name, op_num, handler, tla_list) \
> - case op_num: return #op_name;
> -#include GENL_MAGIC_INCLUDE_FILE
> - default:
> - return "unknown";
> - }
> -}
> -
> #ifdef __KERNEL__
> #include <linux/stringify.h>
> /*
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup
From: Jiri Kosina @ 2013-12-19 9:59 UTC (permalink / raw)
To: David Herrmann
Cc: Joseph Salisbury, Dan Carpenter, thomas, list, Haiyang Zhang,
LKML, open, HID CORE LAYER,
driverdev-devel@linuxdriverproject.org
In-Reply-To: <CANq1E4QriATWbfruwj7oVnEBHvtLe_s2yhSSU5COXFjomt5R_A@mail.gmail.com>
On Thu, 19 Dec 2013, David Herrmann wrote:
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > index 253fe23..81eacd3 100644
> > --- a/drivers/hid/hid-core.c
> > +++ b/drivers/hid/hid-core.c
> > @@ -1334,7 +1334,7 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size,
> > csize--;
> > }
> >
> > - rsize = ((report->size - 1) >> 3) + 1;
> > + rsize = ((report->size - 1) >> 3) + 1 + (report->id > 0) + 7;
>
> Isn't "report->id" already covered by "if (report_enum->numbered)"
> above? The test for "id > 0" won't work here as in this case
> "report_enum->numbered" must already be set to true by the hid-desc
> parser, doesn't it?
Right, that one is not correct here, thanks.
> Where exactly did you get the +7 from?
Please see commit (the one I am not really proud of) 27ce405039bfe6d3.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH 1/4] perf tools: Add support of guest in synthesize_threads.
From: Dongsheng Yang @ 2013-12-19 22:54 UTC (permalink / raw)
To: linux-kernel, eranian, dsahern, adrian.hunter, acme
Cc: mingo, paulus, a.p.zijlstra, Dongsheng Yang
In-Reply-To: <cover.1387493396.git.yangds.fnst@cn.fujitsu.com>
We are using XXX__synthesize_threads() function to synthesize the
symbols of user space for host. This patch add support of guest
for these functions.
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
---
tools/perf/util/event.c | 33 +++++++++++++++++++++++++++------
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 6948768..6e36bbb 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -106,8 +106,12 @@ static pid_t perf_event__synthesize_comm(struct perf_tool *tool,
memset(&event->comm, 0, sizeof(event->comm));
- tgid = perf_event__get_comm_tgid(pid, event->comm.comm,
- sizeof(event->comm.comm));
+ if (machine__is_host(machine))
+ tgid = perf_event__get_comm_tgid(pid, event->comm.comm,
+ sizeof(event->comm.comm));
+ else
+ tgid = machine->pid;
+
if (tgid < 0)
goto out;
@@ -129,7 +133,11 @@ static pid_t perf_event__synthesize_comm(struct perf_tool *tool,
goto out;
}
- snprintf(filename, sizeof(filename), "/proc/%d/task", pid);
+ if (machine__is_default_guest(machine))
+ return 0;
+
+ snprintf(filename, sizeof(filename), "%s/proc/%d/task",
+ machine->root_dir, pid);
tasks = opendir(filename);
if (tasks == NULL) {
@@ -178,7 +186,11 @@ static int perf_event__synthesize_mmap_events(struct perf_tool *tool,
FILE *fp;
int rc = 0;
- snprintf(filename, sizeof(filename), "/proc/%d/maps", pid);
+ if (machine__is_default_guest(machine))
+ return 0;
+
+ snprintf(filename, sizeof(filename), "%s/proc/%d/maps",
+ machine->root_dir, pid);
fp = fopen(filename, "r");
if (fp == NULL) {
@@ -218,7 +230,10 @@ static int perf_event__synthesize_mmap_events(struct perf_tool *tool,
/*
* Just like the kernel, see __perf_event_mmap in kernel/perf_event.c
*/
- event->header.misc = PERF_RECORD_MISC_USER;
+ if (machine__is_host(machine))
+ event->header.misc = PERF_RECORD_MISC_USER;
+ else
+ event->header.misc = PERF_RECORD_MISC_GUEST_USER;
if (prot[2] != 'x') {
if (!mmap_data || prot[0] != 'r')
@@ -387,6 +402,7 @@ int perf_event__synthesize_threads(struct perf_tool *tool,
struct machine *machine, bool mmap_data)
{
DIR *proc;
+ char proc_path[PATH_MAX];
struct dirent dirent, *next;
union perf_event *comm_event, *mmap_event;
int err = -1;
@@ -399,7 +415,12 @@ int perf_event__synthesize_threads(struct perf_tool *tool,
if (mmap_event == NULL)
goto out_free_comm;
- proc = opendir("/proc");
+ if (machine__is_default_guest(machine))
+ return 0;
+
+ snprintf(proc_path, sizeof(proc_path), "%s/proc", machine->root_dir);
+ proc = opendir(proc_path);
+
if (proc == NULL)
goto out_free_mmap;
--
1.8.2.1
^ permalink raw reply related
* [PATCH 3/4] perf tools: Add support of user space symbols for guest in perf kvm top.
From: Dongsheng Yang @ 2013-12-19 22:54 UTC (permalink / raw)
To: linux-kernel, eranian, dsahern, adrian.hunter, acme
Cc: mingo, paulus, a.p.zijlstra, Dongsheng Yang
In-Reply-To: <cover.1387493396.git.yangds.fnst@cn.fujitsu.com>
# perf kvm --guestmount /tmp/guestmount/ top
Samples: 1K of event 'cycles', Event count (approx.): 259112905
17.34% libcrypto.so.1.0.1e [u] 0x000000000007d971
5.60% [guest.kernel] [g] kallsyms_expand_symbol
5.44% libcrypto.so.1.0.1e [u] md5_block_asm_data_order
4.09% [guest.kernel] [g] number.isra.1
3.59% [guest.kernel] [g] vsnprintf
3.52% sshd [u] 0x00000000000441c0
2.37% [guest.kernel] [g] format_decode
2.36% [guest.kernel] [g] memcpy
2.11% [guest.kernel] [g] strnlen
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
---
tools/perf/builtin-top.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 03d37a7..670bd0b 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -821,11 +821,9 @@ static void perf_top__mmap_read_idx(struct perf_top *top, int idx)
break;
case PERF_RECORD_MISC_GUEST_USER:
++top->guest_us_samples;
- /*
- * TODO: we don't process guest user from host side
- * except simple counting.
- */
- /* Fall thru */
+ machine = perf_session__find_machine(session,
+ sample.pid);
+ break;
default:
goto next_event;
}
@@ -912,6 +910,7 @@ static int __cmd_top(struct perf_top *top)
struct perf_record_opts *opts = &top->record_opts;
pthread_t thread;
int ret;
+ struct rb_node *nd;
top->session = perf_session__new(NULL, false, NULL);
if (top->session == NULL)
@@ -931,6 +930,12 @@ static int __cmd_top(struct perf_top *top)
machine__synthesize_threads(&top->session->machines.host, &opts->target,
top->evlist->threads, false);
+
+ for (nd = rb_first(&top->session->machines.guests); nd; nd = rb_next(nd)) {
+ struct machine *pos = rb_entry(nd, struct machine, rb_node);
+ machine__synthesize_threads(pos, &opts->target, top->evlist->threads, false);
+ }
+
ret = perf_top__start_counters(top);
if (ret)
goto out_delete;
--
1.8.2.1
^ permalink raw reply related
* [PATCH 2/4] perf tools: Add support for PERF_RECORD_MISC_GUEST_USER in thread__find_addr_map().
From: Dongsheng Yang @ 2013-12-19 22:54 UTC (permalink / raw)
To: linux-kernel, eranian, dsahern, adrian.hunter, acme
Cc: mingo, paulus, a.p.zijlstra, Dongsheng Yang
In-Reply-To: <cover.1387493396.git.yangds.fnst@cn.fujitsu.com>
This patch remove a TODO in thread__find_addr_map() and add support of PERF_RECORD_MISC_GUEST_USER.
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
---
tools/perf/util/event.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 6e36bbb..598b73e 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -679,15 +679,10 @@ void thread__find_addr_map(struct thread *thread,
al->level = 'g';
mg = &machine->kmaps;
load_map = true;
+ } else if (cpumode == PERF_RECORD_MISC_GUEST_USER && perf_guest) {
+ al->level = 'u';
} else {
- /*
- * 'u' means guest os user space.
- * TODO: We don't support guest user space. Might support late.
- */
- if (cpumode == PERF_RECORD_MISC_GUEST_USER && perf_guest)
- al->level = 'u';
- else
- al->level = 'H';
+ al->level = 'H';
al->map = NULL;
if ((cpumode == PERF_RECORD_MISC_GUEST_USER ||
--
1.8.2.1
^ permalink raw reply related
* [PATCH 4/4] perf tools: Add support of user space symbols for guest in perf kvm record.
From: Dongsheng Yang @ 2013-12-19 22:54 UTC (permalink / raw)
To: linux-kernel, eranian, dsahern, adrian.hunter, acme
Cc: mingo, paulus, a.p.zijlstra, Dongsheng Yang
In-Reply-To: <cover.1387493396.git.yangds.fnst@cn.fujitsu.com>
# perf kvm --guestmount /tmp/guestmount/ record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.828 MB perf.data.guest (~36163 samples) ]
# perf kvm --guestmount /tmp/guestmount/ report
Samples: 4K of event 'cycles', Event count (approx.): 2662750816
8.67% [guest/9217] dd [u] 0x0000000000004e90
6.62% [guest/9217] [guest.kernel.kallsyms.9217] [g] fget_light
6.17% [guest/9217] [guest.kernel.kallsyms.9217] [g] system_call
5.97% [guest/9217] [guest.kernel.kallsyms.9217] [g] __srcu_read_lock
5.53% [guest/9217] [guest.kernel.kallsyms.9217] [g] __srcu_read_unlock
5.47% [guest/9217] [guest.kernel.kallsyms.9217] [g] __audit_syscall_exit
5.38% [guest/9217] [guest.kernel.kallsyms.9217] [g] fsnotify
5.32% [guest/9217] [guest.kernel.kallsyms.9217] [g] system_call_after_swapgs
4.45% [guest/9217] libc-2.17.so [u] __GI___libc_write
4.15% [guest/9217] [guest.kernel.kallsyms.9217] [g] sys_write
3.97% [guest/9217] [guest.kernel.kallsyms.9217] [g] vfs_read
3.78% [guest/9217] libc-2.17.so [u] __GI___libc_read
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
---
tools/perf/builtin-record.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c1c1200..ac1e540 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -279,6 +279,9 @@ static void perf_event__synthesize_guest_os(struct machine *machine, void *data)
{
int err;
struct perf_tool *tool = data;
+ struct perf_record *rec = container_of(tool, struct perf_record, tool);
+ struct perf_record_opts *opts = &rec->opts;
+ struct perf_evlist *evsel_list = rec->evlist;
/*
*As for guest kernel when processing subcommand record&report,
*we arrange module mmap prior to guest kernel mmap and trigger
@@ -305,6 +308,13 @@ static void perf_event__synthesize_guest_os(struct machine *machine, void *data)
if (err < 0)
pr_err("Couldn't record guest kernel [%d]'s reference"
" relocation symbol.\n", machine->pid);
+
+ err = __machine__synthesize_threads(machine, tool, &opts->target, evsel_list->threads,
+ process_synthesized_event, opts->sample_address);
+
+ if (err < 0)
+ pr_err("Couldn't record guest userspace [%d]'s reference"
+ " relocation symbol.\n", machine->pid);
}
static struct perf_event_header finished_round_event = {
--
1.8.2.1
^ permalink raw reply related
* [PATCH 0/4] Add support of guest user space symbols for perf kvm command.
From: Dongsheng Yang @ 2013-12-19 22:54 UTC (permalink / raw)
To: linux-kernel, eranian, dsahern, adrian.hunter, acme
Cc: mingo, paulus, a.p.zijlstra, Dongsheng Yang
Hi all,
This patch add support of guest user space symbols for perf kvm command.
Example:
# perf kvm --guestmount /tmp/guestmount/ top
Samples: 1K of event 'cycles', Event count (approx.): 259112905
17.34% libcrypto.so.1.0.1e [u] 0x000000000007d971
5.60% [guest.kernel] [g] kallsyms_expand_symbol
5.44% libcrypto.so.1.0.1e [u] md5_block_asm_data_order
4.09% [guest.kernel] [g] number.isra.1
3.59% [guest.kernel] [g] vsnprintf
3.52% sshd [u] 0x00000000000441c0
2.37% [guest.kernel] [g] format_decode
2.36% [guest.kernel] [g] memcpy
2.11% [guest.kernel] [g] strnlen
# perf kvm --guestmount /tmp/guestmount/ record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.828 MB perf.data.guest (~36163 samples) ]
# perf kvm --guestmount /tmp/guestmount/ report
Samples: 4K of event 'cycles', Event count (approx.): 2662750816
8.67% [guest/9217] dd [u] 0x0000000000004e90
6.62% [guest/9217] [guest.kernel.kallsyms.9217] [g] fget_light
6.17% [guest/9217] [guest.kernel.kallsyms.9217] [g] system_call
5.97% [guest/9217] [guest.kernel.kallsyms.9217] [g] __srcu_read_lock
5.53% [guest/9217] [guest.kernel.kallsyms.9217] [g] __srcu_read_unlock
5.47% [guest/9217] [guest.kernel.kallsyms.9217] [g] __audit_syscall_exit
5.38% [guest/9217] [guest.kernel.kallsyms.9217] [g] fsnotify
5.32% [guest/9217] [guest.kernel.kallsyms.9217] [g] system_call_after_swapgs
4.45% [guest/9217] libc-2.17.so [u] __GI___libc_write
4.15% [guest/9217] [guest.kernel.kallsyms.9217] [g] sys_write
3.97% [guest/9217] [guest.kernel.kallsyms.9217] [g] vfs_read
3.78% [guest/9217] libc-2.17.so [u] __GI___libc_read
Dongsheng Yang (4):
perf tools: Add support of guest in synthesize_threads.
perf tools: Add support for PERF_RECORD_MISC_GUEST_USER in
thread__find_addr_map().
perf tools: Add support of user space symbols for guest in perf kvm
top.
perf tools: Add support of user space symbols for guest in perf kvm
record.
tools/perf/builtin-record.c | 10 ++++++++++
tools/perf/builtin-top.c | 15 ++++++++++-----
tools/perf/util/event.c | 44 ++++++++++++++++++++++++++++++--------------
3 files changed, 50 insertions(+), 19 deletions(-)
--
1.8.2.1
^ permalink raw reply
* [PATCH] tgtd: fix memory access overrun on array of pthread_t type data
From: Ryusuke Konishi @ 2013-12-19 9:56 UTC (permalink / raw)
To: stgt; +Cc: Ryusuke Konishi
bs_thread_close function accesses memory outside allocated region
because it reads each array element with an index before confirming
that the index is within the range of the array.
This fixes the issue and gets rid of the following warning detected by
valgrind:
==10848== Invalid read of size 8
==10848== at 0x42AF91: bs_thread_close (bs.c:461)
==10848== by 0x42BD94: bs_sheepdog_exit (bs_sheepdog.c:1275)
==10848== by 0x4183B7: tgt_device_destroy (target.c:739)
==10848== by 0x41608D: mtask_received (mgmt.c:251)
==10848== by 0x4164CB: mtask_recv_send_handler (mgmt.c:670)
==10848== by 0x4141F8: event_loop (tgtd.c:428)
==10848== by 0x414899: main (tgtd.c:611)
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
---
usr/bs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/usr/bs.c b/usr/bs.c
index b0ee66f..13d3b4e 100644
--- a/usr/bs.c
+++ b/usr/bs.c
@@ -458,7 +458,7 @@ void bs_thread_close(struct bs_thread_info *info)
info->stop = 1;
pthread_cond_broadcast(&info->pending_cond);
- for (i = 0; info->worker_thread[i] && i < info->nr_worker_threads; i++)
+ for (i = 0; i < info->nr_worker_threads && info->worker_thread[i]; i++)
pthread_join(info->worker_thread[i], NULL);
pthread_cond_destroy(&info->pending_cond);
--
1.7.9.3
^ permalink raw reply related
* Re: [PATCH RFC v2 06/11] backports: igb fixes for linux-3.5
From: Stefan Assmann @ 2013-12-19 9:55 UTC (permalink / raw)
To: Hauke Mehrtens, mcgrof; +Cc: backports
In-Reply-To: <52B206F9.3020702@hauke-m.de>
On 18.12.2013 21:35, Hauke Mehrtens wrote:
> On 12/18/2013 05:08 PM, Stefan Assmann wrote:
>> - add EEE defines
>> - add struct ethtool_eee
>> - backport __skb_alloc_page and __skb_alloc_pages
>> - add patches/collateral-evolutions/network/82-ethernet/0006-igb_eee.patch
>>
>> Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
>> ---
>> backport/backport-include/linux/ethtool.h | 31 +++++++++++++++
>> backport/backport-include/linux/gfp.h | 10 +++++
>> backport/backport-include/linux/mdio.h | 23 ++++++++++-
>> backport/backport-include/linux/skbuff.h | 46 ++++++++++++++++++++++
>> .../network/82-ethernet/0006-igb_eee.patch | 15 +++++++
>> 5 files changed, 124 insertions(+), 1 deletion(-)
>> create mode 100644 backport/backport-include/linux/gfp.h
>> create mode 100644 patches/collateral-evolutions/network/82-ethernet/0006-igb_eee.patch
>>
>> diff --git a/backport/backport-include/linux/ethtool.h b/backport/backport-include/linux/ethtool.h
>> index 647fbf6..4f13cb9 100644
>> --- a/backport/backport-include/linux/ethtool.h
>> +++ b/backport/backport-include/linux/ethtool.h
>> @@ -42,4 +42,35 @@ static inline __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
>> }
>> #endif
>>
>> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,0,0) && LINUX_VERSION_CODE < KERNEL_VERSION(3,6,0)
>> +/**
>> + * struct ethtool_eee - Energy Efficient Ethernet information
>> + * @cmd: ETHTOOL_{G,S}EEE
>> + * @supported: Mask of %SUPPORTED_* flags for the speed/duplex combinations
>> + * for which there is EEE support.
>> + * @advertised: Mask of %ADVERTISED_* flags for the speed/duplex combinations
>> + * advertised as eee capable.
>> + * @lp_advertised: Mask of %ADVERTISED_* flags for the speed/duplex
>> + * combinations advertised by the link partner as eee capable.
>> + * @eee_active: Result of the eee auto negotiation.
>> + * @eee_enabled: EEE configured mode (enabled/disabled).
>> + * @tx_lpi_enabled: Whether the interface should assert its tx lpi, given
>> + * that eee was negotiated.
>> + * @tx_lpi_timer: Time in microseconds the interface delays prior to asserting
>> + * its tx lpi (after reaching 'idle' state). Effective only when eee
>> + * was negotiated and tx_lpi_enabled was set.
>> + */
>> +struct ethtool_eee {
>> + __u32 cmd;
>> + __u32 supported;
>> + __u32 advertised;
>> + __u32 lp_advertised;
>> + __u32 eee_active;
>> + __u32 eee_enabled;
>> + __u32 tx_lpi_enabled;
>> + __u32 tx_lpi_timer;
>> + __u32 reserved[2];
>> +};
>> +#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(3,0,0) && LINUX_VERSION_CODE < KERNEL_VERSION(3,6,0) */
>
> The get_eee and set_eee callbacks in struct ethtool_ops are not
> available on this kernel, you could also add a #ifdef <kernel version>
> around igb_get_eee() and igb_set_eee() and remove the struct here.
True, but that would result in more ifdefs in igb and I'd like to keep
the number at a minimum. Results in less maintenance work if upstream
changes.
Stefan
^ permalink raw reply
* Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup
From: David Herrmann @ 2013-12-19 9:55 UTC (permalink / raw)
To: Jiri Kosina
Cc: Joseph Salisbury, Dan Carpenter, thomas, list, Haiyang Zhang,
LKML, open, HID CORE LAYER,
driverdev-devel@linuxdriverproject.org
In-Reply-To: <alpine.LNX.2.00.1312161401100.12882@pobox.suse.cz>
Hi
On Mon, Dec 16, 2013 at 2:01 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Fri, 27 Sep 2013, Joseph Salisbury wrote:
>
>> >> commit b1a1442a23776756b254b69786848a94d92445ba
>> >> Author: Jiri Kosina <jkosina@suse.cz>
>> >> Date: Mon Jun 3 11:27:48 2013 +0200
>> >>
>> >> HID: core: fix reporting of raw events
>> >>
>> >> Reverting this commit in v3.12-rc2 prevents the system from locking up,
>> >> which happens when connecting a bluetooth trackpad.
>> >>
>> >> Jiri, do you think we should revert this patch, or is there some further
>> >> debugging/data collecting you would like to do?
>> > Hi Joseph,
>> >
>> > in this mail:
>> >
>> > Message-ID: <5241992E.3090805@canonical.com>
>> > Date: Tue, 24 Sep 2013 09:52:46 -0400
>> >
>> > you said that reverting this commit doesn't prevent the lockups, so I am
>> > rather confused ... ?
>> >
>> > Thanks,
>> >
>> The testing was invalid. Reverting commit b1a1442 does resolve the bug
>> and stop the lockups.
>
> Okay, I finally got some sense of this, sorry for the delay.
>
> Could you please test with the patch below, instead of reverting
> b1a1442a23? Thanks a lot.
>
>
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 253fe23..81eacd3 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1334,7 +1334,7 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size,
> csize--;
> }
>
> - rsize = ((report->size - 1) >> 3) + 1;
> + rsize = ((report->size - 1) >> 3) + 1 + (report->id > 0) + 7;
Isn't "report->id" already covered by "if (report_enum->numbered)"
above? The test for "id > 0" won't work here as in this case
"report_enum->numbered" must already be set to true by the hid-desc
parser, doesn't it?
Where exactly did you get the +7 from?
What worries me here is that we write over the @data buffer from the
hid-ll-driver if the report is too short. I don't think the BT driver
accounts for that, mhh.
David
> if (rsize > HID_MAX_BUFFER_SIZE)
> rsize = HID_MAX_BUFFER_SIZE;
>
> --
> Jiri Kosina
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* ext4 inline data (Re: grub-2.02~beta1 happened)
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-19 9:53 UTC (permalink / raw)
To: The development of GNU GRUB
In-Reply-To: <CAA91j0VJJ5QV957zFMe2CQk8i4Pijeo4+XzD6Ndn-K1iNvxs6w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]
On 19.12.2013 07:38, Andrey Borzenkov wrote:
> On Thu, Dec 19, 2013 at 5:51 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>> Hello, all. I've just uploaded 2.02~beta1. This also means that we're
>> now in freeze. I'm willing to consider exceptions on case-by-case basis
>> but it would be exceptions.
>
> You did not answer my question whether I should commit ext4 inline
> data support. Do I understand it correctly you do not plan to include
> it in release?
>
There were several problems with it:
- Apparently the format isn't completely stable. A discussion dated of
December 2013 proposes to change format in order to squeeze in a little
bit more data.
- Patch would crash on ARM due to misaligned access
- There are memory leaks.
For 2nd and 3rd I've uploaded fixes to andrey/ext4_inline_data but then
because lack of support in version packaged by Debian sid I couldn't
test it.
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]
^ permalink raw reply
* Re: [PATCH] ALSA: hda - Don't be too specific for conflicting boost ctl names
From: Raymond Yau @ 2013-12-19 9:54 UTC (permalink / raw)
To: Takashi Iwai; +Cc: ALSA Development Mailing List
In-Reply-To: <1387388362-1005-1-git-send-email-tiwai@suse.de>
When a boost control influences on multiple input paths, we shouldn't
> pick up the name string specific to one input but rather choose a more
> generic name. A problem seen often is that a single mic boost
> controls both internal and external mics although the driver picks up
> the very first name randomly like "Internal Mic Boost". This should
> have been "Mic Boost", instead.
>
> This patch tries to correct that behavior: when a boost control is
> available, check whether it conflicts with other inputs. If it does,
> use a common string ("Mic", "Line") as long as possible, or take a
> generic name "Input".
>
> +
> /* create a boost control */
> + if (!conflict) {
> + pfx = spec->input_labels[idx];
> + idx = spec->input_label_idxs[idx];
> + } else {
> + pfx = input_type_labels[type];
> + idx = input_type_idxs[type]++;
> + }
> +
> snprintf(boost_label, sizeof(boost_label),
> - "%s Boost Volume", spec->input_labels[idx]);
> - if (!add_control(spec, HDA_CTL_WIDGET_VOL, boost_label,
> - spec->input_label_idxs[idx], val))
> + "%s Boost Volume", pfx);
>
should "Boost Volume" change to "Boost Capture Volume" if loopback path not
exist ?
if (spec->mixer_nid)
"Boost Volume"
^ permalink raw reply
* Re: [PATCH] irq-renesas-irqc: simplify irq_set_type() method
From: Magnus Damm @ 2013-12-19 9:53 UTC (permalink / raw)
To: Simon Horman; +Cc: Sergei Shtylyov, Thomas Gleixner, SH-Linux, linux-kernel
In-Reply-To: <20131219082453.GA12239@verge.net.au>
On Thu, Dec 19, 2013 at 5:24 PM, Simon Horman <horms@verge.net.au> wrote:
> On Sat, Dec 14, 2013 at 03:09:31AM +0300, Sergei Shtylyov wrote:
>> Value 0 of the sense selection field of CONFIG_n register means "disable event
>> detection" and serves in irqc_sense[] for marking the invalid values of the IRQ
>> type (by just omitting initializers). There is no need for INTC_IRQ_SENSE_VALID
>> and hence INTC_IRQ_SENSE() as all field values matching to the valid IRQ types
>> are non-zero anyway.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Magnus, could you review this?
The patch is IMO only cosmetic so I can't say I care that much. But
since you ask. =)
Acked-by: Magnus Damm <damm@opensource.se>
Cheers,
/ magnus
^ permalink raw reply
* Re: [PATCH] irq-renesas-irqc: simplify irq_set_type() method
From: Magnus Damm @ 2013-12-19 9:53 UTC (permalink / raw)
To: Simon Horman; +Cc: Sergei Shtylyov, Thomas Gleixner, SH-Linux, linux-kernel
In-Reply-To: <20131219082453.GA12239@verge.net.au>
On Thu, Dec 19, 2013 at 5:24 PM, Simon Horman <horms@verge.net.au> wrote:
> On Sat, Dec 14, 2013 at 03:09:31AM +0300, Sergei Shtylyov wrote:
>> Value 0 of the sense selection field of CONFIG_n register means "disable event
>> detection" and serves in irqc_sense[] for marking the invalid values of the IRQ
>> type (by just omitting initializers). There is no need for INTC_IRQ_SENSE_VALID
>> and hence INTC_IRQ_SENSE() as all field values matching to the valid IRQ types
>> are non-zero anyway.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Magnus, could you review this?
The patch is IMO only cosmetic so I can't say I care that much. But
since you ask. =)
Acked-by: Magnus Damm <damm@opensource.se>
Cheers,
/ magnus
^ permalink raw reply
* Re: [PATCH 3/6] memcg, slab: cleanup barrier usage when accessing memcg_caches
From: Vladimir Davydov @ 2013-12-19 9:53 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-kernel, linux-mm, cgroups, devel, Johannes Weiner,
Glauber Costa, Christoph Lameter, Pekka Enberg, Andrew Morton
In-Reply-To: <20131219093619.GA10855@dhcp22.suse.cz>
On 12/19/2013 01:36 PM, Michal Hocko wrote:
> On Thu 19-12-13 13:29:59, Vladimir Davydov wrote:
>> On 12/19/2013 01:21 PM, Michal Hocko wrote:
>>> On Thu 19-12-13 13:16:01, Vladimir Davydov wrote:
>>>> On 12/19/2013 01:10 PM, Michal Hocko wrote:
>>>>> On Thu 19-12-13 10:37:27, Vladimir Davydov wrote:
>>>>>> On 12/18/2013 09:14 PM, Michal Hocko wrote:
>>>>>>> On Wed 18-12-13 17:16:54, Vladimir Davydov wrote:
>>>>>>>> First, in memcg_create_kmem_cache() we should issue the write barrier
>>>>>>>> after the kmem_cache is initialized, but before storing the pointer to
>>>>>>>> it in its parent's memcg_params.
>>>>>>>>
>>>>>>>> Second, we should always issue the read barrier after
>>>>>>>> cache_from_memcg_idx() to conform with the write barrier.
>>>>>>>>
>>>>>>>> Third, its better to use smp_* versions of barriers, because we don't
>>>>>>>> need them on UP systems.
>>>>>>> Please be (much) more verbose on Why. Barriers are tricky and should be
>>>>>>> documented accordingly. So if you say that we should issue a barrier
>>>>>>> always be specific why we should do it.
>>>>>> In short, we have kmem_cache::memcg_params::memcg_caches is an array of
>>>>>> pointers to per-memcg caches. We access it lock-free so we should use
>>>>>> memory barriers during initialization. Obviously we should place a write
>>>>>> barrier just before we set the pointer in order to make sure nobody will
>>>>>> see a partially initialized structure. Besides there must be a read
>>>>>> barrier between reading the pointer and accessing the structure, to
>>>>>> conform with the write barrier. It's all that similar to rcu_assign and
>>>>>> rcu_deref. Currently the barrier usage looks rather strange:
>>>>>>
>>>>>> memcg_create_kmem_cache:
>>>>>> initialize kmem
>>>>>> set the pointer in memcg_caches
>>>>>> wmb() // ???
>>>>>>
>>>>>> __memcg_kmem_get_cache:
>>>>>> <...>
>>>>>> read_barrier_depends() // ???
>>>>>> cachep = root_cache->memcg_params->memcg_caches[memcg_id]
>>>>>> <...>
>>>>> Why do we need explicit memory barriers when we can use RCU?
>>>>> __memcg_kmem_get_cache already dereferences within rcu_read_lock.
>>>> Because it's not RCU, IMO. RCU implies freeing the old version after a
>>>> grace period, while kmem_caches are freed immediately. We simply want to
>>>> be sure the kmem_cache is fully initialized. And we do not require
>>>> calling this in an RCU critical section.
>>> And you can use rcu_dereference and rcu_assign for that as well.
>> rcu_dereference() will complain if called outside an RCU critical
>> section, while cache_from_memcg_idx() is called w/o RCU protection from
>> some places.
> Does anything prevents us from using RCU from those callers as well?
Yes, take a look at kmem_cache_destroy_memcg_children(), for instance.
We call cancel_work_sync() there on a cache obtained via
cache_from_memcg_idx().
Thanks.
^ permalink raw reply
* Re: [PATCH 3/6] memcg, slab: cleanup barrier usage when accessing memcg_caches
From: Vladimir Davydov @ 2013-12-19 9:53 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-kernel, linux-mm, cgroups, devel, Johannes Weiner,
Glauber Costa, Christoph Lameter, Pekka Enberg, Andrew Morton
In-Reply-To: <20131219093619.GA10855@dhcp22.suse.cz>
On 12/19/2013 01:36 PM, Michal Hocko wrote:
> On Thu 19-12-13 13:29:59, Vladimir Davydov wrote:
>> On 12/19/2013 01:21 PM, Michal Hocko wrote:
>>> On Thu 19-12-13 13:16:01, Vladimir Davydov wrote:
>>>> On 12/19/2013 01:10 PM, Michal Hocko wrote:
>>>>> On Thu 19-12-13 10:37:27, Vladimir Davydov wrote:
>>>>>> On 12/18/2013 09:14 PM, Michal Hocko wrote:
>>>>>>> On Wed 18-12-13 17:16:54, Vladimir Davydov wrote:
>>>>>>>> First, in memcg_create_kmem_cache() we should issue the write barrier
>>>>>>>> after the kmem_cache is initialized, but before storing the pointer to
>>>>>>>> it in its parent's memcg_params.
>>>>>>>>
>>>>>>>> Second, we should always issue the read barrier after
>>>>>>>> cache_from_memcg_idx() to conform with the write barrier.
>>>>>>>>
>>>>>>>> Third, its better to use smp_* versions of barriers, because we don't
>>>>>>>> need them on UP systems.
>>>>>>> Please be (much) more verbose on Why. Barriers are tricky and should be
>>>>>>> documented accordingly. So if you say that we should issue a barrier
>>>>>>> always be specific why we should do it.
>>>>>> In short, we have kmem_cache::memcg_params::memcg_caches is an array of
>>>>>> pointers to per-memcg caches. We access it lock-free so we should use
>>>>>> memory barriers during initialization. Obviously we should place a write
>>>>>> barrier just before we set the pointer in order to make sure nobody will
>>>>>> see a partially initialized structure. Besides there must be a read
>>>>>> barrier between reading the pointer and accessing the structure, to
>>>>>> conform with the write barrier. It's all that similar to rcu_assign and
>>>>>> rcu_deref. Currently the barrier usage looks rather strange:
>>>>>>
>>>>>> memcg_create_kmem_cache:
>>>>>> initialize kmem
>>>>>> set the pointer in memcg_caches
>>>>>> wmb() // ???
>>>>>>
>>>>>> __memcg_kmem_get_cache:
>>>>>> <...>
>>>>>> read_barrier_depends() // ???
>>>>>> cachep = root_cache->memcg_params->memcg_caches[memcg_id]
>>>>>> <...>
>>>>> Why do we need explicit memory barriers when we can use RCU?
>>>>> __memcg_kmem_get_cache already dereferences within rcu_read_lock.
>>>> Because it's not RCU, IMO. RCU implies freeing the old version after a
>>>> grace period, while kmem_caches are freed immediately. We simply want to
>>>> be sure the kmem_cache is fully initialized. And we do not require
>>>> calling this in an RCU critical section.
>>> And you can use rcu_dereference and rcu_assign for that as well.
>> rcu_dereference() will complain if called outside an RCU critical
>> section, while cache_from_memcg_idx() is called w/o RCU protection from
>> some places.
> Does anything prevents us from using RCU from those callers as well?
Yes, take a look at kmem_cache_destroy_memcg_children(), for instance.
We call cancel_work_sync() there on a cache obtained via
cache_from_memcg_idx().
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 3/6] memcg, slab: cleanup barrier usage when accessing memcg_caches
From: Vladimir Davydov @ 2013-12-19 9:53 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, cgroups-u79uwXL29TY76Z2rM5mHXA,
devel-GEFAQzZX7r8dnm+yROfE0A, Johannes Weiner, Glauber Costa,
Christoph Lameter, Pekka Enberg, Andrew Morton
In-Reply-To: <20131219093619.GA10855-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On 12/19/2013 01:36 PM, Michal Hocko wrote:
> On Thu 19-12-13 13:29:59, Vladimir Davydov wrote:
>> On 12/19/2013 01:21 PM, Michal Hocko wrote:
>>> On Thu 19-12-13 13:16:01, Vladimir Davydov wrote:
>>>> On 12/19/2013 01:10 PM, Michal Hocko wrote:
>>>>> On Thu 19-12-13 10:37:27, Vladimir Davydov wrote:
>>>>>> On 12/18/2013 09:14 PM, Michal Hocko wrote:
>>>>>>> On Wed 18-12-13 17:16:54, Vladimir Davydov wrote:
>>>>>>>> First, in memcg_create_kmem_cache() we should issue the write barrier
>>>>>>>> after the kmem_cache is initialized, but before storing the pointer to
>>>>>>>> it in its parent's memcg_params.
>>>>>>>>
>>>>>>>> Second, we should always issue the read barrier after
>>>>>>>> cache_from_memcg_idx() to conform with the write barrier.
>>>>>>>>
>>>>>>>> Third, its better to use smp_* versions of barriers, because we don't
>>>>>>>> need them on UP systems.
>>>>>>> Please be (much) more verbose on Why. Barriers are tricky and should be
>>>>>>> documented accordingly. So if you say that we should issue a barrier
>>>>>>> always be specific why we should do it.
>>>>>> In short, we have kmem_cache::memcg_params::memcg_caches is an array of
>>>>>> pointers to per-memcg caches. We access it lock-free so we should use
>>>>>> memory barriers during initialization. Obviously we should place a write
>>>>>> barrier just before we set the pointer in order to make sure nobody will
>>>>>> see a partially initialized structure. Besides there must be a read
>>>>>> barrier between reading the pointer and accessing the structure, to
>>>>>> conform with the write barrier. It's all that similar to rcu_assign and
>>>>>> rcu_deref. Currently the barrier usage looks rather strange:
>>>>>>
>>>>>> memcg_create_kmem_cache:
>>>>>> initialize kmem
>>>>>> set the pointer in memcg_caches
>>>>>> wmb() // ???
>>>>>>
>>>>>> __memcg_kmem_get_cache:
>>>>>> <...>
>>>>>> read_barrier_depends() // ???
>>>>>> cachep = root_cache->memcg_params->memcg_caches[memcg_id]
>>>>>> <...>
>>>>> Why do we need explicit memory barriers when we can use RCU?
>>>>> __memcg_kmem_get_cache already dereferences within rcu_read_lock.
>>>> Because it's not RCU, IMO. RCU implies freeing the old version after a
>>>> grace period, while kmem_caches are freed immediately. We simply want to
>>>> be sure the kmem_cache is fully initialized. And we do not require
>>>> calling this in an RCU critical section.
>>> And you can use rcu_dereference and rcu_assign for that as well.
>> rcu_dereference() will complain if called outside an RCU critical
>> section, while cache_from_memcg_idx() is called w/o RCU protection from
>> some places.
> Does anything prevents us from using RCU from those callers as well?
Yes, take a look at kmem_cache_destroy_memcg_children(), for instance.
We call cancel_work_sync() there on a cache obtained via
cache_from_memcg_idx().
Thanks.
^ permalink raw reply
* [PATCH 13/13] drivers: block: Remove unused function in genl_magic_func.h
From: Rashika Kheria @ 2013-12-19 9:52 UTC (permalink / raw)
To: linux-kernel; +Cc: David S. Miller, Johannes Berg, Rashika Kheria, josh
In-Reply-To: <f460591345e87defe53122cf056991c7f2eefa10.1387445396.git.rashika.kheria@gmail.com>
Remove unused function CONCAT_(GENL_MAGIC_FAMILY, _genl_cmd_to_str) in
include/linux/genl_magic_func.h.
This eliminates the following warning in
include/linux/genl_magic_func.h:
include/linux/genl_magic_func.h:221:1: warning: no previous prototype for ‘drbd_genl_cmd_to_str’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
---
include/linux/genl_magic_func.h | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/include/linux/genl_magic_func.h b/include/linux/genl_magic_func.h
index c0894dd..0456ad8 100644
--- a/include/linux/genl_magic_func.h
+++ b/include/linux/genl_magic_func.h
@@ -214,22 +214,6 @@ static int s_name ## _from_attrs_for_change(struct s_name *s, \
#undef GENL_struct
#define GENL_struct(tag_name, tag_number, s_name, s_fields)
-/*
- * Magic: define op number to op name mapping {{{1
- * {{{2
- */
-const char *CONCAT_(GENL_MAGIC_FAMILY, _genl_cmd_to_str)(__u8 cmd)
-{
- switch (cmd) {
-#undef GENL_op
-#define GENL_op(op_name, op_num, handler, tla_list) \
- case op_num: return #op_name;
-#include GENL_MAGIC_INCLUDE_FILE
- default:
- return "unknown";
- }
-}
-
#ifdef __KERNEL__
#include <linux/stringify.h>
/*
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH RFC v2 05/11] backports: igb fixes for linux-3.6
From: Stefan Assmann @ 2013-12-19 9:50 UTC (permalink / raw)
To: Hauke Mehrtens, mcgrof; +Cc: backports
In-Reply-To: <52B20530.2040204@hauke-m.de>
On 18.12.2013 21:27, Hauke Mehrtens wrote:
> On 12/18/2013 05:08 PM, Stefan Assmann wrote:
>> - backport ethtool_cmd
>> - backport ethtool_ops
>> - backport mmd_eee_adv_to_ethtool_adv_t
>> - add patches/collateral-evolutions/network/82-ethernet/0003-igb_ptp.patch
>> - add patches/collateral-evolutions/network/82-ethernet/0004-igb_err_handler.patch
>> - add patches/collateral-evolutions/network/82-ethernet/0005-igb_mdi.patch
>>
>> Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
>> ---
>> backport/backport-include/linux/mdio.h | 35 ++++++++++++++++
>> .../network/82-ethernet/0003-igb_ptp.patch | 17 ++++++++
>> .../network/82-ethernet/0004-igb_err_handler.patch | 16 +++++++
>> .../network/82-ethernet/0005-igb_mdi.patch | 49 ++++++++++++++++++++++
>> 4 files changed, 117 insertions(+)
>> create mode 100644 backport/backport-include/linux/mdio.h
>> create mode 100644 patches/collateral-evolutions/network/82-ethernet/0003-igb_ptp.patch
>> create mode 100644 patches/collateral-evolutions/network/82-ethernet/0004-igb_err_handler.patch
>> create mode 100644 patches/collateral-evolutions/network/82-ethernet/0005-igb_mdi.patch
>>
>> diff --git a/backport/backport-include/linux/mdio.h b/backport/backport-include/linux/mdio.h
>> new file mode 100644
>> index 0000000..2a38121
>> --- /dev/null
>> +++ b/backport/backport-include/linux/mdio.h
>> @@ -0,0 +1,35 @@
>> +#ifndef __BACKPORT_LINUX_MDIO_H
>> +#define __BACKPORT_LINUX_MDIO_H
>> +#include_next <linux/mdio.h>
>> +
>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3,7,0)
>> +/**
>> + * mmd_eee_adv_to_ethtool_adv_t
>> + * @eee_adv: value of the MMD EEE Advertisement/Link Partner Ability registers
>> + *
>> + * A small helper function that translates the MMD EEE Advertisment (7.60)
>> + * and MMD EEE Link Partner Ability (7.61) bits to ethtool advertisement
>> + * settings.
>> + */
>> +static inline u32 mmd_eee_adv_to_ethtool_adv_t(u16 eee_adv)
>> +{
>> + u32 adv = 0;
>> +
>> + if (eee_adv & MDIO_EEE_100TX)
>> + adv |= ADVERTISED_100baseT_Full;
>> + if (eee_adv & MDIO_EEE_1000T)
>> + adv |= ADVERTISED_1000baseT_Full;
>> + if (eee_adv & MDIO_EEE_10GT)
>> + adv |= ADVERTISED_10000baseT_Full;
>> + if (eee_adv & MDIO_EEE_1000KX)
>> + adv |= ADVERTISED_1000baseKX_Full;
>> + if (eee_adv & MDIO_EEE_10GKX4)
>> + adv |= ADVERTISED_10000baseKX4_Full;
>> + if (eee_adv & MDIO_EEE_10GKR)
>> + adv |= ADVERTISED_10000baseKR_Full;
>> +
>> + return adv;
>> +}
>> +#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(3,7,0) */
>> +
>> +#endif /* __BACKPORT_LINUX_MDIO_H */
>> diff --git a/patches/collateral-evolutions/network/82-ethernet/0003-igb_ptp.patch b/patches/collateral-evolutions/network/82-ethernet/0003-igb_ptp.patch
>> new file mode 100644
>> index 0000000..9799466
>> --- /dev/null
>> +++ b/patches/collateral-evolutions/network/82-ethernet/0003-igb_ptp.patch
>> @@ -0,0 +1,17 @@
>> +diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
>> +index 5a54e3d..97bb1cf 100644
>> +--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
>> ++++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
>> +@@ -802,8 +802,12 @@ void igb_ptp_init(struct igb_adapter *adapter)
>> + wr32(E1000_IMS, E1000_IMS_TS);
>> + }
>> +
>> ++#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,7,0)
>> + adapter->ptp_clock = ptp_clock_register(&adapter->ptp_caps,
>> + &adapter->pdev->dev);
>> ++#else
>> ++ adapter->ptp_clock = ptp_clock_register(&adapter->ptp_caps);
>> ++#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(3,7,0) */
>
> This could be replaced with in a header file:
> #if LINUX_VERSION_CODE < KERNEL_VERSION(3,7,0)
> #define ptp_clock_register(info,parent) ptp_clock_register(info)
> #endif
Yes that's better, going to be included in next version.
Stefan
^ permalink raw reply
* Re: [RFC PATCH 00/10] Xen VMware tools support
From: Ian Campbell @ 2013-12-19 9:50 UTC (permalink / raw)
To: Don Slutz
Cc: Keir Fraser, Jun Nakajima, Stefano Stabellini, Ian Jackson,
Eddie Dong, xen-devel, Jan Beulich, Boris Ostrovsky,
Suravee Suthikulpanit
In-Reply-To: <52B241D5.5070204@terremark.com>
On Wed, 2013-12-18 at 19:46 -0500, Don Slutz wrote:
> On 12/17/13 14:03, Konrad Rzeszutek Wilk wrote:
> > On Thu, Dec 12, 2013 at 02:15:08PM -0500, Don Slutz wrote:
> >> From: Don Slutz <dslutz@verizon.com>
> >>
> >> See
> >>
> >> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458
> > Can you say how this benefits Xen to detect this and take
> > advantage of it? Or is this Xen emulating VMWare so to a guest
> > it looks like its running under VMWare?
> This is Xen emulating part of VMWare. Some parts of guests will think
> it is running on VMware.
That doesn't answer the important part Konrad's question though: how
this benefits Xen.
A series like this should have a cover letter which explains what the
feature is, what use case it solves, why this is a useful thing and why
it is worth the burden of maintaining it going forward.
Ian.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] piix: do not reset APIC base address (0x80) on piix4_reset.
From: Marcel Apfelbaum @ 2013-12-19 9:49 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Gal Hammer, Paolo Bonzini, seabios@seabios.org, qemu-devel
In-Reply-To: <1387445872.28892.5.camel@localhost.localdomain>
On Thu, 2013-12-19 at 11:37 +0200, Marcel Apfelbaum wrote:
> On Wed, 2013-12-18 at 19:20 +0200, Michael S. Tsirkin wrote:
> > On Wed, Dec 18, 2013 at 06:49:24PM +0200, Marcel Apfelbaum wrote:
> > > On Wed, 2013-12-18 at 18:33 +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Dec 18, 2013 at 06:27:12PM +0200, Marcel Apfelbaum wrote:
> > > > > On Wed, 2013-12-18 at 17:22 +0200, Michael S. Tsirkin wrote:
> > > > > > On Wed, Dec 18, 2013 at 03:22:59PM +0100, Paolo Bonzini wrote:
> > > > > > > Il 11/12/2013 10:21, Gal Hammer ha scritto:
> > > > > > > > Fix a bug that was introduced in commit c046e8c4. QEMU fails to
> > > > > > > > resume from suspend mode (S3).
> > > > > > > >
> > > > > > > > Signed-off-by: Gal Hammer <ghammer@redhat.com>
> > > > > > > > ---
> > > > > > > > hw/acpi/piix4.c | 1 -
> > > > > > > > 1 file changed, 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> > > > > > > > index 93849c8..5c736a4 100644
> > > > > > > > --- a/hw/acpi/piix4.c
> > > > > > > > +++ b/hw/acpi/piix4.c
> > > > > > > > @@ -376,7 +376,6 @@ static void piix4_reset(void *opaque)
> > > > > > > > pci_conf[0x5b] = 0;
> > > > > > > >
> > > > > > > > pci_conf[0x40] = 0x01; /* PM io base read only bit */
> > > > > > > > - pci_conf[0x80] = 0;
> > > > > > > >
> > > > > > > > if (s->kvm_enabled) {
> > > > > > > > /* Mark SMM as already inited (until KVM supports SMM). */
> > > > > > >
> > > > > > > Note this is not the APIC base address, that one is 80h on the ISA
> > > > > > > bridge (function 0). You're changing the behavior for 80h on the power
> > > > > > > management function, which is function 3. The register is "PMBA—POWER
> > > > > > > MANAGEMENT BASE ADDRESS" and it is indeed initialized by SeaBIOS in
> > > > > > > piix4_pm_setup (src/fw/pciinit.c).
> > > > > > >
> > > > > > > Michael, perhaps a part of pci_setup (same file) should run on S3 resume?
> > > > > > >
> > > > > > > Paolo
> > > > > >
> > > > > > Seems reasonable: either seabios or guest OS must do it, and
> > > > > > guest does not seem to.
> > > > > I was looking into this today, but it seems that we have a problem.
> > > > > We cannot run pci_setup() in init section:
> > > > > .data.varinit.seabios/src/hw/pci.h.66 is VARVERIFY32INIT but used from ['.text.runtime.seabios/src/resume.c.150', '.text.pci_setup']
> > > > >
> > > > > Any thoughts how to get around this?
> > > > > Thanks,
> > > > > Marcel
> > > >
> > > > We defintely don't want to do full pci enumeration.
> > > > Just pci_bios_init_platform or even less.
> > > The problem still remains, we have to use pci_bios_init_device that
> > > in turn uses the PCIDevices list.
> > >
> > > Thanks,
> > > Marcel
> >
> > It does but it does not have to. We can use a chunk out of
> > pci_probe_devices to initialize struct pci_device on stack.
> >
> > Basically something like the below (warning: completely untested,
> > sorry).
> I tested and it works fine for both windows and linux guests!
Actually it doesn't work :(
I was testing a "working hack", not the master branch.
I still think it is the right direction.
Thanks,
Marcel
> Also I agree this is the right thing to do after s3.
> Do you want to submit the patch? (or I can do it, no problem)
>
> Thanks,
> Marcel
>
> >
> > Seems much easier and more robust than building up
> > the list of devices in memory.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> >
> > diff --git a/src/hw/pci.h b/src/hw/pci.h
> > index 9c7351d..a64f7c5 100644
> > --- a/src/hw/pci.h
> > +++ b/src/hw/pci.h
> > @@ -66,6 +66,7 @@ extern u64 pcimem64_start, pcimem64_end;
> > extern struct hlist_head PCIDevices;
> > extern int MaxPCIBus;
> > int pci_probe_host(void);
> > +void pci_probe_device(int bdf, struct pci_device *dev);
> > void pci_probe_devices(void);
> > static inline u32 pci_classprog(struct pci_device *pci) {
> > return (pci->class << 8) | pci->prog_if;
> > diff --git a/src/util.h b/src/util.h
> > index e6a6cb5..a8c71a8 100644
> > --- a/src/util.h
> > +++ b/src/util.h
> > @@ -28,6 +28,7 @@ void boot_add_cbfs(void *data, const char *desc, int prio);
> > void interactive_bootmenu(void);
> > void bcv_prepboot(void);
> > struct pci_device;
> > +void pci_bios_init_device(struct pci_device *pci);
> > int bootprio_find_pci_device(struct pci_device *pci);
> > int bootprio_find_scsi_device(struct pci_device *pci, int target, int lun);
> > int bootprio_find_ata_device(struct pci_device *pci, int chanid, int slave);
> > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> > index 34279a4..a35b58d 100644
> > --- a/src/fw/pciinit.c
> > +++ b/src/fw/pciinit.c
> > @@ -293,7 +293,7 @@ static const struct pci_device_id pci_device_tbl[] = {
> > PCI_DEVICE_END,
> > };
> >
> > -static void pci_bios_init_device(struct pci_device *pci)
> > +void pci_bios_init_device(struct pci_device *pci)
> > {
> > u16 bdf = pci->bdf;
> > dprintf(1, "PCI: init bdf=%02x:%02x.%x id=%04x:%04x\n"
> > diff --git a/src/hw/pci.c b/src/hw/pci.c
> > index 6c9aa81..d22804f 100644
> > --- a/src/hw/pci.c
> > +++ b/src/hw/pci.c
> > @@ -105,6 +105,24 @@ pci_probe_host(void)
> > return 0;
> > }
> >
> > +void
> > +pci_probe_device(int bdf, struct pci_device *dev)
> > +{
> > + dev->bdf = bdf;
> > + u32 vendev = pci_config_readl(bdf, PCI_VENDOR_ID);
> > + dev->vendor = vendev & 0xffff;
> > + dev->device = vendev >> 16;
> > + u32 classrev = pci_config_readl(bdf, PCI_CLASS_REVISION);
> > + dev->class = classrev >> 16;
> > + dev->prog_if = classrev >> 8;
> > + dev->revision = classrev & 0xff;
> > + dev->header_type = pci_config_readb(bdf, PCI_HEADER_TYPE);
> > + u8 v = dev->header_type & 0x7f;
> > + if (v == PCI_HEADER_TYPE_BRIDGE || v == PCI_HEADER_TYPE_CARDBUS) {
> > + u8 secbus = pci_config_readb(bdf, PCI_SECONDARY_BUS);
> > + dev->secondary_bus = secbus;
> > + }
> > +}
> > // Find all PCI devices and populate PCIDevices linked list.
> > void
> > pci_probe_devices(void)
> > @@ -145,21 +163,12 @@ pci_probe_devices(void)
> > }
> >
> > // Populate pci_device info.
> > - dev->bdf = bdf;
> > + pci_probe_device(bdf, dev);
> > dev->parent = parent;
> > dev->rootbus = rootbus;
> > - u32 vendev = pci_config_readl(bdf, PCI_VENDOR_ID);
> > - dev->vendor = vendev & 0xffff;
> > - dev->device = vendev >> 16;
> > - u32 classrev = pci_config_readl(bdf, PCI_CLASS_REVISION);
> > - dev->class = classrev >> 16;
> > - dev->prog_if = classrev >> 8;
> > - dev->revision = classrev & 0xff;
> > - dev->header_type = pci_config_readb(bdf, PCI_HEADER_TYPE);
> > u8 v = dev->header_type & 0x7f;
> > if (v == PCI_HEADER_TYPE_BRIDGE || v == PCI_HEADER_TYPE_CARDBUS) {
> > - u8 secbus = pci_config_readb(bdf, PCI_SECONDARY_BUS);
> > - dev->secondary_bus = secbus;
> > + u8 secbus = dev->secondary_bus;
> > if (secbus > bus && !busdevs[secbus])
> > busdevs[secbus] = dev;
> > if (secbus > MaxPCIBus)
> > diff --git a/src/resume.c b/src/resume.c
> > index fc2fee9..f6c8b3b 100644
> > --- a/src/resume.c
> > +++ b/src/resume.c
> > @@ -101,6 +101,14 @@ s3_resume(void)
> > pic_setup();
> > smm_setup();
> >
> > + int bdf;
> > + foreachbdf(bdf, 0) {
> > + struct pci_device pci;
> > +
> > + pci_probe_device(bdf, &pci);
> > + pci_bios_init_device(&pci);
> > + }
> > +
> > s3_resume_vga();
> >
> > make_bios_readonly();
>
>
>
>
^ permalink raw reply
* [U-Boot] [PATCH 1/2] doc: README.fuse: Add an example on how to use the fuse API on mx6q
From: Stefano Babic @ 2013-12-19 9:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <261565228.157501.1387315088236.JavaMail.zimbra@advansee.com>
Hi Beno?t, hi Fabio,
On 17/12/2013 22:18, Beno?t Th?baudeau wrote:
> Hi Fabio,
>
> On Tuesday, December 17, 2013 9:03:40 PM, Fabio Estevam wrote:
>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>
>> When using the fuse API in U-boot user must calculate the 'bank' and 'word'
>> values.
>>
>> Provide a real example on how to calculate such values for the mx6q.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>> ---
>> doc/README.fuse | 57
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>>
>> diff --git a/doc/README.fuse b/doc/README.fuse
>> index 1bc91c4..aca1e5e 100644
>> --- a/doc/README.fuse
>> +++ b/doc/README.fuse
>> @@ -65,3 +65,60 @@ Configuration:
>>
>> CONFIG_CMD_FUSE
>> Define this to enable the fuse commands.
>> +
>> +Example:
>> +
>> +For reading the MAC address fuses on a MX6Q:
>> +
>> +- The MAC address are stored in two fuse addresses (the fuse addresses are
>> +described in the Fusemap Descriptions table from the mx6q Reference Manual):
>> +
>> +0x620[31:0] - MAC_ADDR[31:0]
>> +0x630[15:0] - MAC_ADDR[47:32]
>> +
>> +In order to use the fuse API, we need to pass the bank and word values,
>> which
>> +are calculated as below:
>> +
>> +Fuse address for the lower MAC address: 0x620
>> +Base address for the fuses: 0x400
>> +
>> +(0x620 - 0x400)/0x10 = 0x22 = 34 decimal
>> +
>> +As the fuses are arranged in banks of 8 words:
>> +
>> +34 / 8 = 4 and the remainder is 2, so in this case:
>> +
>> +bank = 4
>> +word = 2
>> +
>> +And the U-boot command would be:
>> +
>> +=> fuse read 4 2
>> +Reading bank 4:
>> +
>> +Word 0x00000002: 9f027772
>> +
>> +Doing the same for the upper MAC address:
>> +
>> +Fuse address for the upper MAC address: 0x630
>> +Base address for the fuses: 0x400
>> +
>> +(0x630 - 0x400)/0x10 = 0x23 = 35 decimal
>> +
>> +As the fuses are arranged in banks of 8 words:
>> +
>> +35 / 8 = 4 and the remainder is 3, so in this case:
>> +
>> +bank = 4
>> +word = 3
>> +
>> +And the U-boot command would be:
>> +
>> +=> fuse read 4 3
>> +Reading bank 4:
>> +
>> +Word 0x00000003: 00000004
>> +
>> +,which matches the ethaddr value:
>> +=> echo ${ethaddr}
>> +00:04:9f:02:77:72
>> --
>> 1.8.1.2
>
> Note that the documentation in this file is also completed for i.MX6 by
> doc/README.mxc_ocotp and doc/README.imx6, as explained in each README. The
> information that you add here regarding the location of the MAC fuses for i.MX6Q
> is already present in doc/README.imx6.
This is true, but the current documentation is poor. I like that Fabio
adds a real example, providing a better understanding.
IMHO we should avoid to add a new file, if (as it is), this patch is
only for i.MX6. Putting it in README.imx6 seems the best solution.
>
> Regarding the 'calculation' part, it is actually not needed since the values
> obtained with these calculations are already given by the reference manual in
> '46.5 OCOTP Memory Map/Register Definition'.
A reference is not bad, but of course documentation is changing. I was
working with manual 04/2013, and there is not an example - only "empty
example".
Anyway, most people is searching exactly how to store in SOC the MAC
address - not how to write another fuse. I think it is a good idea to
add the MAC's example, because it is what most people are looking for.
>
> Examples could still be interesting though. What do you think?
> - Should the calculation part be removed and replaced with a reference to the
> RM ?46.5 be added?
I will add only a refererence, but I will let the example.
> - Should this example be moved to doc/README.imx6,
+1, as the example is only for i.MX6.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
^ permalink raw reply
* [PATCH Resend 7/7] clk: max77686: Remove redundant break
From: jonghwa3.lee at samsung.com @ 2013-12-19 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387443241-5694-7-git-send-email-sachin.kamat@linaro.org>
On 2013? 12? 19? 17:54, Sachin Kamat wrote:
> 'break' after 'goto' is redundant. Remove it.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Jonghwa Lee <jonghwa3.lee@samsung.com>
> ---
> drivers/clk/clk-max77686.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
> index 9f57bc37cd60..b4a1a9719ab0 100644
> --- a/drivers/clk/clk-max77686.c
> +++ b/drivers/clk/clk-max77686.c
> @@ -157,11 +157,9 @@ static int max77686_clk_probe(struct platform_device *pdev)
> case MAX77686_CLK_AP:
> dev_err(&pdev->dev, "Fail to register CLK_AP\n");
> goto err_clk_ap;
> - break;
> case MAX77686_CLK_CP:
> dev_err(&pdev->dev, "Fail to register CLK_CP\n");
> goto err_clk_cp;
> - break;
> case MAX77686_CLK_PMIC:
> dev_err(&pdev->dev, "Fail to register CLK_PMIC\n");
> goto err_clk_pmic;
Acked-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Thanks,
Jonghwa
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.