Vážení E-mail užívatela

[webmail update 2013]

Vážení E-mail užívatela;
Prekrocili ste 23432 boxy nastavit svoje
Webová služba / Administrátor, a budete mat problémy pri odosielaní a
prijímat e-maily, kým znova overit. Musíte aktualizovat kliknutím na
odkaz nižšie a vyplnte údaje pre overenie vášho úctu
Prosím, kliknite na odkaz nižšie alebo skopírovat vložit do
e-prehliadac pre overenie Schránky.

 http://webmailupdateonline689.jimdo.com/

Pozor!
Ak tak neurobíte, budú mat obmedzený prístup k e-mailu schránky. Ak
sa
nepodarí aktualizovat svoj ??úcet do troch dní od aktualizácie
oznámenia,
bude váš úcet natrvalo uzavretá.
S pozdravom,
System Administrator ®





--
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] drivers: staging: bcm: removed a developer debug message per the TODO list.

[Chuong Ngo]

Removed a debug message as outlined in the TODO list.
---
 drivers/staging/bcm/Bcmchar.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/bcm/Bcmchar.c b/drivers/staging/bcm/Bcmchar.c
index f91bc1f..526594b 100644
--- a/drivers/staging/bcm/Bcmchar.c
+++ b/drivers/staging/bcm/Bcmchar.c
@@ -50,8 +50,6 @@ static int bcm_char_release(struct inode *inode, struct file 
*filp)
pTarang = (struct bcm_tarang_data *)filp->private_data;
 
if (pTarang == NULL) {
-   BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0,
-   "ptarang is null\n");
return 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: [PATCH 2/2] i2c-designware-pci: Index Haswell ULT bus names from 0

[Mika Westerberg]

On Sun, Oct 20, 2013 at 08:26:50PM -0700, Benson Leung wrote:
> Rather than having the bus names be "i2c-designware-pci--1" because
> we have set the .bus_num to -1 to force dynamic allocation, lets have
> the busses named "i2c-designware-pci-0" and "i2c-designware-pci-1"
> to correspond to the correct names of these busses.
> 
> The adapter number will still be dynamically assigned.

Is there any real value in having names like "i2c-designware-pci-0"
available? I would just drop the whole naming dance instead...
--
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] i2c-designware-pci: Add Haswell ULT device IDs

[Mika Westerberg]

On Sun, Oct 20, 2013 at 08:26:49PM -0700, Benson Leung wrote:
> From: Duncan Laurie 
> 
> Add the necessary PCI Device IDs to use the Haswell ULT
> I2C controller in PCI mode.
> 
> Set the bus numbers to -1 so it will use dynamic assignment
> rather than hardcoded.
> 
> Signed-off-by: Duncan Laurie 
> Signed-off-by: Benson Leung 

Looks good to me, except one thing...

> ---
>  drivers/i2c/busses/i2c-designware-pcidrv.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
> b/drivers/i2c/busses/i2c-designware-pcidrv.c
> index f6ed06c..e4cbbdf 100644
> --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
> +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
> @@ -54,6 +54,9 @@ enum dw_pci_ctl_id_t {
>   medfield_3,
>   medfield_4,
>   medfield_5,
> +
> + haswell_0,
> + haswell_1,
>  };
>  
>  struct dw_pci_controller {
> @@ -132,6 +135,20 @@ static struct  dw_pci_controller  dw_pci_controllers[] = 
> {
>   .rx_fifo_depth = 32,
>   .clk_khz  = 25000,
>   },
> + [haswell_0] = {
> + .bus_num = -1,
> + .bus_cfg   = INTEL_MID_STD_CFG | DW_IC_CON_SPEED_STD,
> + .tx_fifo_depth = 32,
> + .rx_fifo_depth = 32,
> + .clk_khz  = 25000,

The input clock for I2C in Haswell is 100MHz, not 25MHz.

> + },
> + [haswell_1] = {
> + .bus_num = -1,
> + .bus_cfg   = INTEL_MID_STD_CFG | DW_IC_CON_SPEED_STD,
> + .tx_fifo_depth = 32,
> + .rx_fifo_depth = 32,
> + .clk_khz  = 25000,

Ditto.

> + },
>  };
--
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] kernel/rcutorture.c: be sure of enough memory for result printing.

[Chen Gang]

Oh, sorry, I forgot to let it pass "./scripts/checkpatch.pl", after
finish checking, it finds a style issue (which is pointed out below), if
necessary to send patch v2, please let me know.

Thanks.

On 10/21/2013 01:51 PM, Chen Gang wrote:
> If the contents is more than 4096 bytes (e.g. if have 1K cpus), current
> sprintf() will cause memory overflow. And this fix patch is to be sure
> of memory large enough.
> 
> Benefit:
> 
>  - do not truncate printing contents.
>  - extensible, it is large enough for printing various related contents.
>  - simple and clear enough for both source code readers and writers.
> 
> Shortcoming:
> 
>  - It will waste some memory:
> 1 cpu may waste 24KB,
> 10 cpus may waste 96KB,
> 100 cpus may waste 816KB,
> 1K cpus may waste 8MB
> ...
>after finish printing, it will free the related memory, quickly.
>it is a test module, so wast a little memory for extensible is OK.
> 
> Related  test (Fedora16 2 CPUs, 2GB RAM x86_64)
> 
>  - as module, with/without "torture_type=srcu".
>  - build-in not boot runnable, with/without "torture_type=srcu".
>  - build-in let boot runnable, with/without "torture_type=srcu".
> 
> 
> Signed-off-by: Chen Gang 
> ---
>  kernel/rcutorture.c |   67 
> ++-
>  1 files changed, 34 insertions(+), 33 deletions(-)
> 
> diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
> index be63101..3413bc1 100644
> --- a/kernel/rcutorture.c
> +++ b/kernel/rcutorture.c
> @@ -133,8 +133,6 @@ MODULE_PARM_DESC(verbose, "Enable verbose debugging 
> printk()s");
>  #define VERBOSE_PRINTK_ERRSTRING(s) \
>   do { if (verbose) pr_alert("%s" TORTURE_FLAG "!!! " s "\n", 
> torture_type); } while (0)
>  
> -static char printk_buf[4096];
> -
>  static int nrealreaders;
>  static struct task_struct *writer_task;
>  static struct task_struct **fakewriter_tasks;
> @@ -370,7 +368,7 @@ struct rcu_torture_ops {
>   void (*call)(struct rcu_head *head, void (*func)(struct rcu_head *rcu));
>   void (*cb_barrier)(void);
>   void (*fqs)(void);
> - int (*stats)(char *page);
> + void (*stats)(char *page);
>   int irq_capable;
>   int can_boost;
>   const char *name;
> @@ -572,21 +570,19 @@ static void srcu_torture_barrier(void)
>   srcu_barrier(&srcu_ctl);
>  }
>  
> -static int srcu_torture_stats(char *page)
> +static void srcu_torture_stats(char *page)
>  {
> - int cnt = 0;
>   int cpu;
>   int idx = srcu_ctl.completed & 0x1;
>  
> - cnt += sprintf(&page[cnt], "%s%s per-CPU(idx=%d):",
> + page += sprintf(page, "%s%s per-CPU(idx=%d):",
>  torture_type, TORTURE_FLAG, idx);
>   for_each_possible_cpu(cpu) {
> - cnt += sprintf(&page[cnt], " %d(%lu,%lu)", cpu,
> + page += sprintf(page, " %d(%lu,%lu)", cpu,
>  per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[!idx],
>  per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[idx]);
>   }
> - cnt += sprintf(&page[cnt], "\n");
> - return cnt;
> + sprintf(page, "\n");
>  }
>  
>  static void srcu_torture_synchronize_expedited(void)
> @@ -1046,10 +1042,9 @@ rcu_torture_reader(void *arg)
>  /*
>   * Create an RCU-torture statistics message in the specified buffer.
>   */
> -static int
> +static void
>  rcu_torture_printk(char *page)
>  {
> - int cnt = 0;
>   int cpu;
>   int i;
>   long pipesummary[RCU_TORTURE_PIPE_LEN + 1] = { 0 };
> @@ -1065,8 +1060,8 @@ rcu_torture_printk(char *page)
>   if (pipesummary[i] != 0)
>   break;
>   }
> - cnt += sprintf(&page[cnt], "%s%s ", torture_type, TORTURE_FLAG);
> - cnt += sprintf(&page[cnt],
> + page += sprintf(page, "%s%s ", torture_type, TORTURE_FLAG);
> + page += sprintf(page,
>  "rtc: %p ver: %lu tfle: %d rta: %d rtaf: %d rtf: %d ",
>  rcu_torture_current,
>  rcu_torture_current_version,
> @@ -1074,53 +1069,52 @@ rcu_torture_printk(char *page)
>  atomic_read(&n_rcu_torture_alloc),
>  atomic_read(&n_rcu_torture_alloc_fail),
>  atomic_read(&n_rcu_torture_free));
> - cnt += sprintf(&page[cnt], "rtmbe: %d rtbke: %ld rtbre: %ld ",
> + page += sprintf(page, "rtmbe: %d rtbke: %ld rtbre: %ld ",
>  atomic_read(&n_rcu_torture_mberror),
>  n_rcu_torture_boost_ktrerror,
>  n_rcu_torture_boost_rterror);
> - cnt += sprintf(&page[cnt], "rtbf: %ld rtb: %ld nt: %ld ",
> + page += sprintf(page, "rtbf: %ld rtb: %ld nt: %ld ",
>  n_rcu_torture_boost_failure,
>  n_rcu_torture_boosts,
>  n_rcu_torture_timers);
> - cnt += sprintf(&page[cnt],
> + page += sprintf(page,
>  "onoff: %ld/%ld:%ld/%ld %d,%d:%d,%d %lu:%lu (HZ=%d) ",
>  n_online_suc

RE: kprobe pre_handler change return IP

[Liuyongan]

> -Original Message-
> From: Masami Hiramatsu [mailto:masami.hiramatsu...@hitachi.com]
> Sent: Sunday, October 20, 2013 12:00 AM
> To: Liuyongan
> Cc: linux-kernel@vger.kernel.org; Qianhuibin
> Subject: Re: kprobe pre_handler change return IP
> 
> (2013/10/17 21:57), Liuyongan wrote:
> > I use kprobe to probe a function suppose:
> >   int is_winter(int num) { ... }
> >   int replace_is_winter(int num) { ...}
> > I want to replace is_winter() with replace_is_winter(), so when we call
> is_winter, replace_is_winter will be called.
> >
> > so:
> >int my_pre_handler(struct kprobe *p, struct pt_regs *regs)
> >{
> > regs->ip = (unsigned long)&replace_is_winter;
> > return 1;
> >}
> >
> > and echo 0 > /proc/sys/debug/kprobes-optimization so that jump instruction
> will not be used.
> >
> > I got a exception in fault_handler, and trap number is 14.
> >
> >fault_handler: p->addr = 0xa08e201a, ip = 8021c59d, trap
> #14n
> >
> > Anyone here can help me ?
> 
> If you want to replace something with kprobes, the pre_handler must clean
> current_kprobe up.
> Actually the same thing has been done in setup_detour_execution(). So, what
> you need to do is

Great! It works. 
As my_pre_handler() in another modules,  I should export current_kprobe using

EXPORT_PER_CPU_SYMBOL(current_kprobe);

in arch/x86/kernel/kprobes.c right after current_kprobe's definition.

> 
> >int my_pre_handler(struct kprobe *p, struct pt_regs *regs)
> >{
> > regs->ip = (unsigned long)&replace_is_winter;
> 
>   reset_current_kprobe();
>   preempt_enable_no_resched();
> 
> > return 1;
> >}
> 
> Happy hacking! ;)
> 
> 
> Thank you,
> 
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu...@hitachi.com
> 

Fwd: CPU usage

[王神]

Hi

I am running a userspace tool that reads/writes ISO data from a USB
device. ( ISO means periodic data). I am measuring load created by the
tool using 'top' tool which shows CPU usage as 0% sometimes and 40%
sometimes.

If the data is periodic why the CPU usage vary so much ? Can any one
point out what is the missing link ? Does any have a better approach
to measure CPU usage.

Thanks in Advance
--
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 03/19] perf record: Improve write_output error message

[Adrian Hunter]

On 20/10/13 23:43, Jiri Olsa wrote:
> On Fri, Oct 18, 2013 at 03:29:00PM +0300, Adrian Hunter wrote:
>> Improve the error message from write_output() to say
>> what failed to write and give the error number.
>>
>> Signed-off-by: Adrian Hunter 
>> ---
>>  tools/perf/builtin-record.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index 92ca541..d269dfa 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -88,7 +88,7 @@ static int write_output(struct perf_record *rec, void 
>> *buf, size_t size)
>>  int ret = write(rec->output, buf, size);
>>  
>>  if (ret < 0) {
>> -pr_err("failed to write\n");
>> +pr_err("failed to write perf data, error: %m\n");
> 
> is this some kind of format magic? ;-) you wanted

It is a glibc extension.

> to print out 'ret' value, right?

No, errno

--
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: PROBLEM: special sense code asc,ascq=04h,0Ch abort scsi scan in the middle

[vaughan]

On 10/16/2013 02:52 PM, Hannes Reinecke wrote:
> But seeing that this approach raises quite some issues I've attached a
> different patch. Vaughan, could you test with that, too? Should be
> functionally equivalent to the previous one. Cheers, Hannes 
Hi Hannes,

We only tested the later patch which returns _TARGET_PRESENT after
parsing sense, it works as expected.

About the cause of this issue, admin said he is configuring a
active-active cluster mode storage. Each node has it own LUN pool and a
set of rule to control which node can access the pool.
LUN7 is owned and can only be able to manipulated by the other node, but
can be seen by this node for a misconfig. So it presents itself in
REPORT_LUN but return NOT_READY when accessed through this node.
Do you still regard this as a misbehave in response to INQUIRY?

Thanks,
Vaughan
--
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 09/19] perf tools: Fix 32-bit cross build

[Adrian Hunter]

On 20/10/13 23:42, Jiri Olsa wrote:
> On Fri, Oct 18, 2013 at 03:29:06PM +0300, Adrian Hunter wrote:
>> Setting EXTRA_CFLAGS=-m32 did not work because CFLAGS
>> was not passed around.
> 
> this breaks feature detection for me on x86_64,
> I've got following errors misdetection with this patch:
> 
> ...   libperl: [ OFF ]
> ...   on-exit: [ OFF ]
> 
> and the build fails as well:
> 
>   CC   builtin-stat.o
> builtin-record.c:42:12: error: static declaration of ‘on_exit’ follows 
> non-static declaration
> In file included from util/util.h:51:0,
>  from builtin.h:4,
>  from builtin-record.c:8:
> /usr/include/stdlib.h:536:12: note: previous declaration of ‘on_exit’ was here
> make[1]: *** [builtin-record.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make: *** [all] Error 2

That is fixed in patch 11: perf tools: Fix test_on_exit for 32-bit build

--
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] kernel/rcutorture.c: be sure of enough memory for result printing.

[Chen Gang]

If the contents is more than 4096 bytes (e.g. if have 1K cpus), current
sprintf() will cause memory overflow. And this fix patch is to be sure
of memory large enough.

Benefit:

 - do not truncate printing contents.
 - extensible, it is large enough for printing various related contents.
 - simple and clear enough for both source code readers and writers.

Shortcoming:

 - It will waste some memory:
1 cpu may waste 24KB,
10 cpus may waste 96KB,
100 cpus may waste 816KB,
1K cpus may waste 8MB
...
   after finish printing, it will free the related memory, quickly.
   it is a test module, so wast a little memory for extensible is OK.

Related  test (Fedora16 2 CPUs, 2GB RAM x86_64)

 - as module, with/without "torture_type=srcu".
 - build-in not boot runnable, with/without "torture_type=srcu".
 - build-in let boot runnable, with/without "torture_type=srcu".


Signed-off-by: Chen Gang 
---
 kernel/rcutorture.c |   67 ++-
 1 files changed, 34 insertions(+), 33 deletions(-)

diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
index be63101..3413bc1 100644
--- a/kernel/rcutorture.c
+++ b/kernel/rcutorture.c
@@ -133,8 +133,6 @@ MODULE_PARM_DESC(verbose, "Enable verbose debugging 
printk()s");
 #define VERBOSE_PRINTK_ERRSTRING(s) \
do { if (verbose) pr_alert("%s" TORTURE_FLAG "!!! " s "\n", 
torture_type); } while (0)
 
-static char printk_buf[4096];
-
 static int nrealreaders;
 static struct task_struct *writer_task;
 static struct task_struct **fakewriter_tasks;
@@ -370,7 +368,7 @@ struct rcu_torture_ops {
void (*call)(struct rcu_head *head, void (*func)(struct rcu_head *rcu));
void (*cb_barrier)(void);
void (*fqs)(void);
-   int (*stats)(char *page);
+   void (*stats)(char *page);
int irq_capable;
int can_boost;
const char *name;
@@ -572,21 +570,19 @@ static void srcu_torture_barrier(void)
srcu_barrier(&srcu_ctl);
 }
 
-static int srcu_torture_stats(char *page)
+static void srcu_torture_stats(char *page)
 {
-   int cnt = 0;
int cpu;
int idx = srcu_ctl.completed & 0x1;
 
-   cnt += sprintf(&page[cnt], "%s%s per-CPU(idx=%d):",
+   page += sprintf(page, "%s%s per-CPU(idx=%d):",
   torture_type, TORTURE_FLAG, idx);
for_each_possible_cpu(cpu) {
-   cnt += sprintf(&page[cnt], " %d(%lu,%lu)", cpu,
+   page += sprintf(page, " %d(%lu,%lu)", cpu,
   per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[!idx],
   per_cpu_ptr(srcu_ctl.per_cpu_ref, cpu)->c[idx]);
}
-   cnt += sprintf(&page[cnt], "\n");
-   return cnt;
+   sprintf(page, "\n");
 }
 
 static void srcu_torture_synchronize_expedited(void)
@@ -1046,10 +1042,9 @@ rcu_torture_reader(void *arg)
 /*
  * Create an RCU-torture statistics message in the specified buffer.
  */
-static int
+static void
 rcu_torture_printk(char *page)
 {
-   int cnt = 0;
int cpu;
int i;
long pipesummary[RCU_TORTURE_PIPE_LEN + 1] = { 0 };
@@ -1065,8 +1060,8 @@ rcu_torture_printk(char *page)
if (pipesummary[i] != 0)
break;
}
-   cnt += sprintf(&page[cnt], "%s%s ", torture_type, TORTURE_FLAG);
-   cnt += sprintf(&page[cnt],
+   page += sprintf(page, "%s%s ", torture_type, TORTURE_FLAG);
+   page += sprintf(page,
   "rtc: %p ver: %lu tfle: %d rta: %d rtaf: %d rtf: %d ",
   rcu_torture_current,
   rcu_torture_current_version,
@@ -1074,53 +1069,52 @@ rcu_torture_printk(char *page)
   atomic_read(&n_rcu_torture_alloc),
   atomic_read(&n_rcu_torture_alloc_fail),
   atomic_read(&n_rcu_torture_free));
-   cnt += sprintf(&page[cnt], "rtmbe: %d rtbke: %ld rtbre: %ld ",
+   page += sprintf(page, "rtmbe: %d rtbke: %ld rtbre: %ld ",
   atomic_read(&n_rcu_torture_mberror),
   n_rcu_torture_boost_ktrerror,
   n_rcu_torture_boost_rterror);
-   cnt += sprintf(&page[cnt], "rtbf: %ld rtb: %ld nt: %ld ",
+   page += sprintf(page, "rtbf: %ld rtb: %ld nt: %ld ",
   n_rcu_torture_boost_failure,
   n_rcu_torture_boosts,
   n_rcu_torture_timers);
-   cnt += sprintf(&page[cnt],
+   page += sprintf(page,
   "onoff: %ld/%ld:%ld/%ld %d,%d:%d,%d %lu:%lu (HZ=%d) ",
   n_online_successes, n_online_attempts,
   n_offline_successes, n_offline_attempts,
   min_online, max_online,
   min_offline, max_offline,
   sum_online, sum_offline, HZ);
-   cnt += sprintf(&page[cnt], "barrier: %ld/%ld:%ld",
+   page += sprintf(page, "barrier: %ld/%ld:%ld",
   n_ba

[PATCH -next] staging: sep: add missing misc_deregister() on error in sep_register_driver_with_fs()

[Wei Yongjun]

From: Wei Yongjun 

Add the missing misc_deregister() before return from
sep_register_driver_with_fs() in the error handling case.

Signed-off-by: Wei Yongjun 
---
 drivers/staging/sep/sep_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/sep/sep_main.c b/drivers/staging/sep/sep_main.c
index 11f5b21..5f8c0a8 100644
--- a/drivers/staging/sep/sep_main.c
+++ b/drivers/staging/sep/sep_main.c
@@ -4075,6 +4075,7 @@ static int sep_register_driver_with_fs(struct sep_device 
*sep)
if (ret_val) {
dev_warn(&sep->pdev->dev, "sysfs attribute1 fails for SEP %x\n",
ret_val);
+   misc_deregister(&sep->miscdev_sep);
return ret_val;
}
 

--
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/3] x86/vdso: Optimize setup_additional_pages()

[Ingo Molnar]

* Davidlohr Bueso  wrote:

> > 2)
> > 
> > I don't see the justification: this code gets executed in exec() where 
> > a new mm has just been allocated. There's only a single user of the mm 
> > and thus the critical section width of mmap_sem is more or less 
> > irrelevant.
> > 
> > mmap_sem critical section size only matters for codepaths that 
> > threaded programs can hit.
> 
> Yes, I was surprised by the performance boost I noticed when running 
> this patch. This weekend I re-ran the tests (including your 4/3 patch) 
> and noticed that while we're still getting some benefits (more like in 
> the +5% throughput range), it's not as good as I originally reported. I 
> believe the reason is because I had ran the tests on the vanilla kernel 
> without the max clock frequency, so the comparison was obviously not 
> fair. That said, I still think it's worth adding this patch, as it does 
> help at a micro-optimization level, and it's one less mmap_sem user we 
> have to worry about.

But it's a mmap_sem user that is essentially _guaranteed_ to have only a 
single user at that point, in the exec() path!

So I don't see how this can show _any_ measurable speedup, let alone a 5% 
speedup in a macro test. If our understanding is correct then the patch 
does nothing but shuffle around a flag setting operation. (the mmap_sem is 
equivalent to setting a single flag, in the single-user case.)

Now, if our understanding is incorrect then we need to improve our 
understanding.

Thanks,

Ingo
--
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] NTB: remove duplicate defines

[Michael Opdenacker]

Remove duplicate defines in drivers/ntb/ntb_regs.h

Signed-off-by: Michael Opdenacker 
---
 drivers/ntb/ntb_regs.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/ntb/ntb_regs.h b/drivers/ntb/ntb_regs.h
index aa4bdd3..caa5975 100644
--- a/drivers/ntb/ntb_regs.h
+++ b/drivers/ntb/ntb_regs.h
@@ -75,9 +75,6 @@
 #define SNB_SBAR2XLAT_OFFSET   0x0030
 #define SNB_SBAR4XLAT_OFFSET   0x0038
 #define SNB_SBAR0BASE_OFFSET   0x0040
-#define SNB_SBAR0BASE_OFFSET   0x0040
-#define SNB_SBAR2BASE_OFFSET   0x0048
-#define SNB_SBAR4BASE_OFFSET   0x0050
 #define SNB_SBAR2BASE_OFFSET   0x0048
 #define SNB_SBAR4BASE_OFFSET   0x0050
 #define SNB_NTBCNTL_OFFSET 0x0058
-- 
1.8.1.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/

[PATCH v2] chelsio: remove duplicate defines

[Michael Opdenacker]

This removes multiple duplicate definitions
in drivers/net/ethernet/chelsio/cxgb3/regs.h

Signed-off-by: Michael Opdenacker 
---
 drivers/net/ethernet/chelsio/cxgb3/regs.h | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb3/regs.h 
b/drivers/net/ethernet/chelsio/cxgb3/regs.h
index 6990f6c..81029b8 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb3/regs.h
@@ -685,10 +685,6 @@
 #define V_BUSY(x) ((x) << S_BUSY)
 #define F_BUSYV_BUSY(1U)
 
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
 #define A_MC7_EXT_MODE1 0x108
 
 #define A_MC7_EXT_MODE2 0x10c
@@ -749,14 +745,6 @@
 
 #define A_MC7_CAL 0x128
 
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
 #define S_CAL_FAULT30
 #define V_CAL_FAULT(x) ((x) << S_CAL_FAULT)
 #define F_CAL_FAULTV_CAL_FAULT(1U)
@@ -815,9 +803,6 @@
 #define V_OP(x) ((x) << S_OP)
 #define F_OPV_OP(1U)
 
-#define F_OPV_OP(1U)
-#define A_SF_OP 0x6dc
-
 #define A_MC7_BIST_ADDR_BEG 0x168
 
 #define A_MC7_BIST_ADDR_END 0x16c
@@ -830,8 +815,6 @@
 #define V_CONT(x) ((x) << S_CONT)
 #define F_CONTV_CONT(1U)
 
-#define F_CONTV_CONT(1U)
-
 #define A_MC7_INT_ENABLE 0x178
 
 #define S_AE17
@@ -1017,8 +1000,6 @@
 #define V_NICMODE(x) ((x) << S_NICMODE)
 #define F_NICMODEV_NICMODE(1U)
 
-#define F_NICMODEV_NICMODE(1U)
-
 #define S_IPV6ENABLE15
 #define V_IPV6ENABLE(x) ((x) << S_IPV6ENABLE)
 #define F_IPV6ENABLEV_IPV6ENABLE(1U)
@@ -1562,27 +1543,15 @@
 #define A_ULPRX_STAG_ULIMIT 0x530
 
 #define A_ULPRX_RQ_LLIMIT 0x534
-#define A_ULPRX_RQ_LLIMIT 0x534
 
 #define A_ULPRX_RQ_ULIMIT 0x538
-#define A_ULPRX_RQ_ULIMIT 0x538
 
 #define A_ULPRX_PBL_LLIMIT 0x53c
 
 #define A_ULPRX_PBL_ULIMIT 0x540
-#define A_ULPRX_PBL_ULIMIT 0x540
 
 #define A_ULPRX_TDDP_TAGMASK 0x524
 
-#define A_ULPRX_RQ_LLIMIT 0x534
-#define A_ULPRX_RQ_LLIMIT 0x534
-
-#define A_ULPRX_RQ_ULIMIT 0x538
-#define A_ULPRX_RQ_ULIMIT 0x538
-
-#define A_ULPRX_PBL_ULIMIT 0x540
-#define A_ULPRX_PBL_ULIMIT 0x540
-
 #define A_ULPTX_CONFIG 0x580
 
 #define S_CFG_CQE_SOP_MASK1
@@ -2053,8 +2022,6 @@
 #define V_TMMODE(x) ((x) << S_TMMODE)
 #define F_TMMODEV_TMMODE(1U)
 
-#define F_TMMODEV_TMMODE(1U)
-
 #define A_MC5_DB_ROUTING_TABLE_INDEX 0x70c
 
 #define A_MC5_DB_FILTER_TABLE 0x710
@@ -2454,8 +2421,6 @@
 #define V_TXACTENABLE(x) ((x) << S_TXACTENABLE)
 #define F_TXACTENABLEV_TXACTENABLE(1U)
 
-#define A_XGM_SERDES_CTRL0 0x8e0
-
 #define S_RESET323
 #define V_RESET3(x) ((x) << S_RESET3)
 #define F_RESET3V_RESET3(1U)
-- 
1.8.1.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] chelsio: remove duplicate defines

[Michael Opdenacker]

On 10/21/2013 06:55 AM, Michael Opdenacker wrote:
> This removes duplicate definitions of S_BUSY, V_BUSY() and F_BUSY
> in drivers/net/ethernet/chelsio/cxgb3/regs.h
Forget this version. There are other duplicates in this file. I'll
submit a new version of this patch.
>
> Signed-off-by: Michael Opdenacker 
> ---
>  drivers/net/ethernet/chelsio/cxgb3/regs.h | 12 
>  1 file changed, 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb3/regs.h 
> b/drivers/net/ethernet/chelsio/cxgb3/regs.h
> index 6990f6c..b8367ec 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/regs.h
> +++ b/drivers/net/ethernet/chelsio/cxgb3/regs.h
> @@ -685,10 +685,6 @@
>  #define V_BUSY(x) ((x) << S_BUSY)
>  #define F_BUSYV_BUSY(1U)
>  
> -#define S_BUSY31
> -#define V_BUSY(x) ((x) << S_BUSY)
> -#define F_BUSYV_BUSY(1U)
> -
>  #define A_MC7_EXT_MODE1 0x108
>  
>  #define A_MC7_EXT_MODE2 0x10c
> @@ -749,14 +745,6 @@
>  
>  #define A_MC7_CAL 0x128
>  
> -#define S_BUSY31
> -#define V_BUSY(x) ((x) << S_BUSY)
> -#define F_BUSYV_BUSY(1U)
> -
> -#define S_BUSY31
> -#define V_BUSY(x) ((x) << S_BUSY)
> -#define F_BUSYV_BUSY(1U)
> -
>  #define S_CAL_FAULT30
>  #define V_CAL_FAULT(x) ((x) << S_CAL_FAULT)
>  #define F_CAL_FAULTV_CAL_FAULT(1U)


-- 
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098

--
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] cpufreq: create per policy rwsem instead of per CPU cpu_policy_rwsem

[Viresh Kumar]

On 18 October 2013 21:45, Andrew Lunn  wrote:

> Hi Viresh
>
> I tested on my Marvell Dove, which crashed and burned before with
> cpufreq-bench. This version works fine so far. The benchmark has been
> running for ten minutes, whereas before it was lucky to reach ten
> seconds.
>
> Tested-by: Andrew Lunn 

Hi Andrew,

Thanks a lot for reporting and testing this patch :) ..
Hopefully it will not cause any issues ones Rafael applies it for linux-next.
--
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] chelsio: remove duplicate defines

[Michael Opdenacker]

This removes duplicate definitions of S_BUSY, V_BUSY() and F_BUSY
in drivers/net/ethernet/chelsio/cxgb3/regs.h

Signed-off-by: Michael Opdenacker 
---
 drivers/net/ethernet/chelsio/cxgb3/regs.h | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb3/regs.h 
b/drivers/net/ethernet/chelsio/cxgb3/regs.h
index 6990f6c..b8367ec 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb3/regs.h
@@ -685,10 +685,6 @@
 #define V_BUSY(x) ((x) << S_BUSY)
 #define F_BUSYV_BUSY(1U)
 
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
 #define A_MC7_EXT_MODE1 0x108
 
 #define A_MC7_EXT_MODE2 0x10c
@@ -749,14 +745,6 @@
 
 #define A_MC7_CAL 0x128
 
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
 #define S_CAL_FAULT30
 #define V_CAL_FAULT(x) ((x) << S_CAL_FAULT)
 #define F_CAL_FAULTV_CAL_FAULT(1U)
-- 
1.8.1.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/

[PATCH] HID: i2c-hid: Stop querying for init reports

[Bibek Basu]

According to specifications, HID over I2C devices
are not bound to respond to query for INPUT
REPORTS. Thus dropping the call during init
as many devices does not respond causing error
messages during boot.

Signed-off-by: Bibek Basu 
---
 drivers/hid/i2c-hid/i2c-hid.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index fd7ce37..ae48d18 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -455,10 +455,6 @@ static void i2c_hid_init_reports(struct hid_device *hid)
}
 
list_for_each_entry(report,
-   &hid->report_enum[HID_INPUT_REPORT].report_list, list)
-   i2c_hid_init_report(report, inbuf, ihid->bufsize);
-
-   list_for_each_entry(report,
&hid->report_enum[HID_FEATURE_REPORT].report_list, list)
i2c_hid_init_report(report, inbuf, ihid->bufsize);
 
-- 
1.8.1.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] HID: i2c-hid: Stop querying for init reports

[Bibek Basu]

Hi Benjamin,


> -Original Message-
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Sent: Thursday, October 17, 2013 11:27 PM
> To: Bibek Basu
> Cc: Jiri Kosina; linux-input; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] HID: i2c-hid: Stop querying for init reports
> 
> Hi Bibek,
> 
> On Tue, Oct 15, 2013 at 4:28 AM, Bibek Basu  wrote:
> > According to specifications, HID over I2C devices are not bound to
> > respond to query for INPUT REPORTS. Thus dropping the call during init
> > as many devices does not respond causing error messages during boot.
> >
> 
> This time, the patch is removing too many things that are correct. :)
> 
> see below to know what to remove and what to keep:
> 
> > Signed-off-by: Bibek Basu 
> > ---
> >  drivers/hid/i2c-hid/i2c-hid.c | 59
> > ---
> >  1 file changed, 59 deletions(-)
> >
> > diff --git a/drivers/hid/i2c-hid/i2c-hid.c
> > b/drivers/hid/i2c-hid/i2c-hid.c index fd7ce37..58a4f12 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid.c
> > @@ -409,62 +409,6 @@ static int i2c_hid_get_report_length(struct
> hid_report *report)
> > report->device->report_enum[report->type].numbered +
> > 2;  }
> >
> > -static void i2c_hid_init_report(struct hid_report *report, u8 *buffer,
> > -   size_t bufsize)
> > -{
> > -   struct hid_device *hid = report->device;
> > -   struct i2c_client *client = hid->driver_data;
> > -   struct i2c_hid *ihid = i2c_get_clientdata(client);
> > -   unsigned int size, ret_size;
> > -
> > -   size = i2c_hid_get_report_length(report);
> > -   if (i2c_hid_get_report(client,
> > -   report->type == HID_FEATURE_REPORT ? 0x03 : 0x01,
> > -   report->id, buffer, size))
> > -   return;
> > -
> > -   i2c_hid_dbg(ihid, "report (len=%d): %*ph\n", size, size, 
> > ihid->inbuf);
> > -
> > -   ret_size = buffer[0] | (buffer[1] << 8);
> > -
> > -   if (ret_size != size) {
> > -   dev_err(&client->dev, "error in %s size:%d / ret_size:%d\n",
> > -   __func__, size, ret_size);
> > -   return;
> > -   }
> > -
> > -   /* hid->driver_lock is held as we are in probe function,
> > -* we just need to setup the input fields, so using
> > -* hid_report_raw_event is safe. */
> > -   hid_report_raw_event(hid, report->type, buffer + 2, size - 2, 1);
> > -}
> 
> This function should be kept
> 
> > -
> > -/*
> > - * Initialize all reports
> > - */
> > -static void i2c_hid_init_reports(struct hid_device *hid) -{
> > -   struct hid_report *report;
> > -   struct i2c_client *client = hid->driver_data;
> > -   struct i2c_hid *ihid = i2c_get_clientdata(client);
> > -   u8 *inbuf = kzalloc(ihid->bufsize, GFP_KERNEL);
> > -
> > -   if (!inbuf) {
> > -   dev_err(&client->dev, "can not retrieve initial reports\n");
> > -   return;
> > -   }
> > -
> 
> Above should be kept
> 
> > -   list_for_each_entry(report,
> > -   &hid->report_enum[HID_INPUT_REPORT].report_list, list)
> > -   i2c_hid_init_report(report, inbuf, ihid->bufsize);
> > -
> 
> these for lines should be removed (they are the one giving the errors in the
> logs)
> 
> and please keep the rest of the code as is.
> 
> 
> > -   list_for_each_entry(report,
> > -   &hid->report_enum[HID_FEATURE_REPORT].report_list, list)
> > -   i2c_hid_init_report(report, inbuf, ihid->bufsize);
> 
> Actually, this part is very important because we have no spontaneous events
> emitted by features, so we don't know the value of the feature until we
> probed it. So please keep this part as mentioned above.

Thanks for the inputs. I am repushing  the patch. Unfortunately, looks like I 
need to upgrade the firmware of my HID keyboard, as it does not responds to the 
FEATURE_REPORT
query:(

regards
Bibek
> 
> Cheers,
> Benjamin
> 
> > -
> > -   kfree(inbuf);
> > -}
> > -
> >  /*
> >   * Traverse the supplied list of reports and find the longest
> >   */
> > @@ -683,9 +627,6 @@ static int i2c_hid_start(struct hid_device *hid)
> > return ret;
> > }
> >
> > -   if (!(hid->quirks & HID_QUIRK_NO_INIT_REPORTS))
> > -   i2c_hid_init_reports(hid);
> > -
> > return 0;
> >  }
> >
> > --
> > 1.8.1.5
> >

[RFC PATCH] fb: reorder the lock sequence to fix a potential lockdep

[Gu Zheng]

Following commits:
50e244cc79 fb: rework locking to fix lock ordering on takeover
e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
054430e773 fbcon: fix locking harder
reworked locking to fix related lock ordering on takeover, and introduced 
console_lock
into fbmem, but it seems that the new lock sequence(fb_info->lock ---> 
console_lock)
is against with the one in console_callback(console_lock ---> fb_info->lock), 
and leads to
a potential deadlock as following:
[  601.079000] ==
[  601.079000] [ INFO: possible circular locking dependency detected ]
[  601.079000] 3.11.0 #189 Not tainted
[  601.079000] ---
[  601.079000] kworker/0:3/619 is trying to acquire lock:
[  601.079000]  (&fb_info->lock){+.+.+.}, at: [] 
lock_fb_info+0x26/0x60
[  601.079000]
but task is already holding lock:
[  601.079000]  (console_lock){+.+.+.}, at: [] 
console_callback+0x13/0x160
[  601.079000]
which lock already depends on the new lock.

[  601.079000]
the existing dependency chain (in reverse order) is:
[  601.079000]
-> #1 (console_lock){+.+.+.}:
[  601.079000][] lock_acquire+0xa1/0x140
[  601.079000][] console_lock+0x77/0x80
[  601.079000][] register_framebuffer+0x1d8/0x320
[  601.079000][] efifb_probe+0x408/0x48f
[  601.079000][] platform_drv_probe+0x43/0x80
[  601.079000][] driver_probe_device+0x8b/0x390
[  601.079000][] __driver_attach+0xab/0xb0
[  601.079000][] bus_for_each_dev+0x5d/0xa0
[  601.079000][] driver_attach+0x1e/0x20
[  601.079000][] bus_add_driver+0x117/0x290
[  601.079000][] driver_register+0x7a/0x170
[  601.079000][] __platform_driver_register+0x4a/0x50
[  601.079000][] platform_driver_probe+0x1d/0xb0
[  601.079000][] efifb_init+0x273/0x292
[  601.079000][] do_one_initcall+0x102/0x1c0
[  601.079000][] kernel_init_freeable+0x15d/0x1ef
[  601.079000][] kernel_init+0xe/0xf0
[  601.079000][] ret_from_fork+0x7c/0xb0
[  601.079000]
-> #0 (&fb_info->lock){+.+.+.}:
[  601.079000][] __lock_acquire+0x1e18/0x1f10
[  601.079000][] lock_acquire+0xa1/0x140
[  601.079000][] mutex_lock_nested+0x7a/0x3b0
[  601.079000][] lock_fb_info+0x26/0x60
[  601.079000][] fbcon_blank+0x29b/0x2e0
[  601.079000][] do_blank_screen+0x1d8/0x280
[  601.079000][] console_callback+0x64/0x160
[  601.079000][] process_one_work+0x1f5/0x540
[  601.079000][] worker_thread+0x11c/0x370
[  601.079000][] kthread+0xed/0x100
[  601.079000][] ret_from_fork+0x7c/0xb0
[  601.079000]
other info that might help us debug this:

[  601.079000]  Possible unsafe locking scenario:

[  601.079000]CPU0CPU1
[  601.079000]
[  601.079000]   lock(console_lock);
[  601.079000]lock(&fb_info->lock);
[  601.079000]lock(console_lock);
[  601.079000]   lock(&fb_info->lock);
[  601.079000]
 *** DEADLOCK ***

so we reorder the lock sequence the same as it in console_callback() to
avoid this issue.
Not very sure this change is suitable, any comments is welcome.

Signed-off-by: Gu Zheng 
---
 drivers/video/fbmem.c |   50 +++-
 1 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index dacaf74..010d191 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1108,14 +1108,16 @@ static long do_fb_ioctl(struct fb_info *info, unsigned 
int cmd,
case FBIOPUT_VSCREENINFO:
if (copy_from_user(&var, argp, sizeof(var)))
return -EFAULT;
-   if (!lock_fb_info(info))
-   return -ENODEV;
console_lock();
+   if (!lock_fb_info(info)) {
+   console_unlock();
+   return -ENODEV;
+   }
info->flags |= FBINFO_MISC_USEREVENT;
ret = fb_set_var(info, &var);
info->flags &= ~FBINFO_MISC_USEREVENT;
-   console_unlock();
unlock_fb_info(info);
+   console_unlock();
if (!ret && copy_to_user(argp, &var, sizeof(var)))
ret = -EFAULT;
break;
@@ -1144,12 +1146,14 @@ static long do_fb_ioctl(struct fb_info *info, unsigned 
int cmd,
case FBIOPAN_DISPLAY:
if (copy_from_user(&var, argp, sizeof(var)))
return -EFAULT;
-   if (!lock_fb_info(info))
-   return -ENODEV;
console_lock();
+   if (!lock_fb_info(info)) {
+   console_unlock();
+   return -ENODEV;
+   }
ret = fb_pan_

Re: [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support

[Sandeepa Prabhu]

On 18 October 2013 14:02, Masami Hiramatsu
 wrote:
> (2013/10/17 20:17), Sandeepa Prabhu wrote:
>> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
>> and return probes(kretprobes) support for ARM64.
>>
>> Kprobes mechanism make use of software breakpoint and single stepping
>> support available in ARM v8 kernel.
>>
>
> Thank you! This looks much better for me now. ;)
>
>> This patchset make use of (and dependant upon) dynamic kernel patching
>> feature published in patch series: https://lkml.org/lkml/2013/10/15/891
>>
>> changes: v1 -> v2
>>  1. Implemented review comments on v1
>>  2. Debug montior hooks implementation is changed to use rwlocks
>> instead of rcu and spinlock.
>
> Eventually, we'd better reconsider using rcu there, or prohibit probing
> readlock related functions. For the first step, this will be good.
Okay, can be done while optimizing kprobes right, since systemtap/ktap
is yet to be verified on this patchset,
so can expect more scope for optimizing the paths for performance.
>
>>  3. Enabled recursing in kprobes handler for kprobes re-enter support.
>>  4. Re-split the patchset to seperate single-stepping, simulation and
>> kretprobes features.
>>  5. instruction simulation is made independent of 'struct kprobes'
>>  6. Added 'Linaro Copyright' statements in new added files.
>>  7. Used arm64 instead of aarch64 in file names and comments.
>>
>> Tested on ARM v8 fast model with sample modules from: samples/kprobes/
>>
>> Sandeepa Prabhu (6):
>>   arm64: support single-step and breakpoint handler hooks
>>   arm64: Kprobes with single stepping support
>>   arm64: Kprobes instruction simulation support
>>   arm64: Add kernel return probes support(kretprobes)
>>   arm64: Enable kprobes support for arm64 platform
>>   kprobes: Add cases for arm and arm64 in sample module
>>
>>  arch/arm64/Kconfig  |   2 +
>>  arch/arm64/configs/defconfig|  20 +-
>>  arch/arm64/include/asm/debug-monitors.h |  21 +
>>  arch/arm64/include/asm/kprobes.h|  60 +++
>>  arch/arm64/include/asm/probes.h |  50 +++
>>  arch/arm64/include/asm/ptrace.h |   6 +
>>  arch/arm64/kernel/Makefile  |   2 +
>>  arch/arm64/kernel/condn-helpers.c   | 120 ++
>>  arch/arm64/kernel/debug-monitors.c  |  86 +++-
>>  arch/arm64/kernel/entry.S   |   2 +
>
>
>>  arch/arm64/kernel/kprobes-arm64.c   | 313 +++
>>  arch/arm64/kernel/kprobes-arm64.h   |  30 ++
>
> One comment, this name looks a bit wired. Since it seems that these are
> for instruction decoding, can we merge it with probe-decode.h and
> rename it as probe-decode.{h,c}? When we implement uprobes, we still
> can expand it (add the decoding table for uprobes in the probe-decode.c).
probe-decode.c looks fine, as uprobes decode table can be added in
same place. -TODO for the next version.

>
>>  arch/arm64/kernel/kprobes.c | 682 
>> 
>>  arch/arm64/kernel/kprobes.h |  30 ++
>>  arch/arm64/kernel/probes-decode.h   | 110 ++
>>  arch/arm64/kernel/simulate-insn.c   | 184 +
>>  arch/arm64/kernel/simulate-insn.h   |  33 ++
>>  arch/arm64/kernel/vmlinux.lds.S |   1 +
>>  samples/kprobes/kprobe_example.c|  16 +
>>  19 files changed, 1756 insertions(+), 12 deletions(-)
>
> BTW, is there any public git repository which has this series?
Yes, uploaded on linaro git:
https://git.linaro.org/gitweb?p=people/sandeepa.prabhu/linux-aarch64.git;a=shortlog;h=refs/heads/arm64-kprobes-v2

>
> Thank you again!
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu...@hitachi.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 -next] xfs: remove duplicated include from xfs_bmap.c

[Dave Chinner]

On Mon, Oct 21, 2013 at 10:56:15AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Remove duplicated include.
> 
> Signed-off-by: Wei Yongjun 

That's fixed in a series of patches that has already been posted for
review. See:

http://oss.sgi.com/archives/xfs/2013-10/msg00374.html

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/6] Platform: x86: chromeos_laptop - Deferring and Haswell

[Benson Leung]

The following patch series refactors the dmi check system and
returns -EPROBE_DEFER when an expected i2c adapter is not present
at probe time.

This will allow the touchpad, touchscreen, and light sensors on
Pixel to load even if the i915 DDC and PANEL buses are instantiated
after chromeos_laptop.

The deferred probing patches were sent previously, and have been cleaned up
slightly since.

Also one patch to clean up the placement of __initdata for the dmi_table.

Finally, add support for the Haswell generation Chromebook systems' 
peripherals over the new native i2c-designware-pci busses.

The last three patches depend on this patch series :
https://lkml.org/lkml/2013/10/20/136

[PATCH 1/6] Platform: x86: chromeos_laptop - Restructure device associations
[PATCH 2/6] Platform: x86: chromeos_laptop - Use deferred probing
[PATCH 3/6] Platform: x86: chromeos_laptop - fix incorrect placement of 
__initdata tag
[PATCH 4/6] Platform: x86: chromeos_laptop - Add names of Haswell ULT i2c busses
[PATCH 5/6] Platform: x86: chromeos_laptop - Add HP Chromebook 14
[PATCH 6/6] Platform: x86: chromeos_laptop - Add Acer C720

Regards,
Benson
--
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/6] Platform: x86: chromeos_laptop - Use deferred probing

[Benson Leung]

Further refactor chromeos_laptop, adding a probe function.
Init will call dmi_check_system, but will only use the match to select
a chromeos_laptop structure of the current board.

Probe will add the devices, and on errors return -EPROBE_DEFER.
If i2c adapters are loaded after chromeos_laptop inits, the deferred
probe will instantiate the peripherals when the bus appears.

Signed-off-by: Benson Leung 
Reviewed-by: Aaron Durbin 
---
 drivers/platform/x86/chromeos_laptop.c | 144 +++--
 1 file changed, 101 insertions(+), 43 deletions(-)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index 5c69cfd..e542330 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define ATMEL_TP_I2C_ADDR  0x4b
 #define ATMEL_TP_I2C_BL_ADDR   0x25
@@ -54,7 +55,7 @@ enum i2c_adapter_type {
 };
 
 struct i2c_peripheral {
-   void (*add)(enum i2c_adapter_type type);
+   int (*add)(enum i2c_adapter_type type);
enum i2c_adapter_type type;
 };
 
@@ -64,20 +65,22 @@ struct chromeos_laptop {
struct i2c_peripheral i2c_peripherals[MAX_I2C_PERIPHERALS];
 };
 
-static struct i2c_board_info __initdata cyapa_device = {
+static struct chromeos_laptop *cros_laptop;
+
+static struct i2c_board_info cyapa_device = {
I2C_BOARD_INFO("cyapa", CYAPA_TP_I2C_ADDR),
.flags  = I2C_CLIENT_WAKE,
 };
 
-static struct i2c_board_info __initdata isl_als_device = {
+static struct i2c_board_info isl_als_device = {
I2C_BOARD_INFO("isl29018", ISL_ALS_I2C_ADDR),
 };
 
-static struct i2c_board_info __initdata tsl2583_als_device = {
+static struct i2c_board_info tsl2583_als_device = {
I2C_BOARD_INFO("tsl2583", TAOS_ALS_I2C_ADDR),
 };
 
-static struct i2c_board_info __initdata tsl2563_als_device = {
+static struct i2c_board_info tsl2563_als_device = {
I2C_BOARD_INFO("tsl2563", TAOS_ALS_I2C_ADDR),
 };
 
@@ -100,7 +103,7 @@ static struct mxt_platform_data atmel_224s_tp_platform_data 
= {
.config_length  = 0,
 };
 
-static struct i2c_board_info __initdata atmel_224s_tp_device = {
+static struct i2c_board_info atmel_224s_tp_device = {
I2C_BOARD_INFO("atmel_mxt_tp", ATMEL_TP_I2C_ADDR),
.platform_data = &atmel_224s_tp_platform_data,
.flags  = I2C_CLIENT_WAKE,
@@ -121,13 +124,13 @@ static struct mxt_platform_data atmel_1664s_platform_data 
= {
.config_length  = 0,
 };
 
-static struct i2c_board_info __initdata atmel_1664s_device = {
+static struct i2c_board_info atmel_1664s_device = {
I2C_BOARD_INFO("atmel_mxt_ts", ATMEL_TS_I2C_ADDR),
.platform_data = &atmel_1664s_platform_data,
.flags  = I2C_CLIENT_WAKE,
 };
 
-static struct i2c_client __init *__add_probed_i2c_device(
+static struct i2c_client *__add_probed_i2c_device(
const char *name,
int bus,
struct i2c_board_info *info,
@@ -180,7 +183,7 @@ static struct i2c_client __init *__add_probed_i2c_device(
return client;
 }
 
-static int __init __find_i2c_adap(struct device *dev, void *data)
+static int __find_i2c_adap(struct device *dev, void *data)
 {
const char *name = data;
static const char *prefix = "i2c-";
@@ -191,7 +194,7 @@ static int __init __find_i2c_adap(struct device *dev, void 
*data)
return (strncmp(adapter->name, name, strlen(name)) == 0);
 }
 
-static int __init find_i2c_adapter_num(enum i2c_adapter_type type)
+static int find_i2c_adapter_num(enum i2c_adapter_type type)
 {
struct device *dev = NULL;
struct i2c_adapter *adapter;
@@ -200,8 +203,9 @@ static int __init find_i2c_adapter_num(enum 
i2c_adapter_type type)
dev = bus_find_device(&i2c_bus_type, NULL, (void *)name,
  __find_i2c_adap);
if (!dev) {
-   pr_err("%s: i2c adapter %s not found on system.\n", __func__,
-  name);
+   /* Adapters may appear later. Deferred probing will retry */
+   pr_notice("%s: i2c adapter %s not found on system.\n", __func__,
+ name);
return -ENODEV;
}
adapter = to_i2c_adapter(dev);
@@ -216,7 +220,7 @@ static int __init find_i2c_adapter_num(enum 
i2c_adapter_type type)
  * Returns NULL if no devices found.
  * See Documentation/i2c/instantiating-devices for more information.
  */
-static __init struct i2c_client *add_probed_i2c_device(
+static struct i2c_client *add_probed_i2c_device(
const char *name,
enum i2c_adapter_type type,
struct i2c_board_info *info,
@@ -233,7 +237,7 @@ static __init struct i2c_client *add_probed_i2c_device(
  * info->addr.
  * Returns NULL if no device found.
  */
-static __init struct i2c_client *add_i2c_device(const char *name,
+static struct i2c_client *add_i2c_d

[PATCH 1/6] Platform: x86: chromeos_laptop - Restructure device associations

[Benson Leung]

From: Aaron Durbin 

The previous code had a single DMI matching entry
for each device on a board. Instead provide a single
DMI entry for each board which references a structure
about each board that lists the associated peripherals.
This allows for a lower number of DMI matching sequences
as well making it easier to add new boards.

Signed-off-by: Aaron Durbin 
Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 197 +
 1 file changed, 126 insertions(+), 71 deletions(-)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index 3e5b4497..5c69cfd 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -53,6 +53,17 @@ enum i2c_adapter_type {
I2C_ADAPTER_PANEL,
 };
 
+struct i2c_peripheral {
+   void (*add)(enum i2c_adapter_type type);
+   enum i2c_adapter_type type;
+};
+
+#define MAX_I2C_PERIPHERALS 3
+
+struct chromeos_laptop {
+   struct i2c_peripheral i2c_peripherals[MAX_I2C_PERIPHERALS];
+};
+
 static struct i2c_board_info __initdata cyapa_device = {
I2C_BOARD_INFO("cyapa", CYAPA_TP_I2C_ADDR),
.flags  = I2C_CLIENT_WAKE,
@@ -233,149 +244,193 @@ static __init struct i2c_client *add_i2c_device(const 
char *name,
   addr_list);
 }
 
-
-static struct i2c_client __init *add_smbus_device(const char *name,
- struct i2c_board_info *info)
-{
-   return add_i2c_device(name, I2C_ADAPTER_SMBUS, info);
-}
-
-static int __init setup_cyapa_smbus_tp(const struct dmi_system_id *id)
+static int __init setup_cyapa_tp(enum i2c_adapter_type type)
 {
-   /* add cyapa touchpad on smbus */
-   tp = add_smbus_device("trackpad", &cyapa_device);
+   /* add cyapa touchpad */
+   tp = add_i2c_device("trackpad", type, &cyapa_device);
return 0;
 }
 
-static int __init setup_atmel_224s_tp(const struct dmi_system_id *id)
+static int __init setup_atmel_224s_tp(enum i2c_adapter_type type)
 {
const unsigned short addr_list[] = { ATMEL_TP_I2C_BL_ADDR,
 ATMEL_TP_I2C_ADDR,
 I2C_CLIENT_END };
 
-   /* add atmel mxt touchpad on VGA DDC GMBus */
-   tp = add_probed_i2c_device("trackpad", I2C_ADAPTER_VGADDC,
+   /* add atmel mxt touchpad */
+   tp = add_probed_i2c_device("trackpad", type,
   &atmel_224s_tp_device, addr_list);
return 0;
 }
 
-static int __init setup_atmel_1664s_ts(const struct dmi_system_id *id)
+static int __init setup_atmel_1664s_ts(enum i2c_adapter_type type)
 {
const unsigned short addr_list[] = { ATMEL_TS_I2C_BL_ADDR,
 ATMEL_TS_I2C_ADDR,
 I2C_CLIENT_END };
 
-   /* add atmel mxt touch device on PANEL GMBus */
-   ts = add_probed_i2c_device("touchscreen", I2C_ADAPTER_PANEL,
+   /* add atmel mxt touch device */
+   ts = add_probed_i2c_device("touchscreen", type,
   &atmel_1664s_device, addr_list);
return 0;
 }
 
-
-static int __init setup_isl29018_als(const struct dmi_system_id *id)
+static int __init setup_isl29018_als(enum i2c_adapter_type type)
 {
/* add isl29018 light sensor */
-   als = add_smbus_device("lightsensor", &isl_als_device);
+   als = add_i2c_device("lightsensor", type, &isl_als_device);
return 0;
 }
 
-static int __init setup_isl29023_als(const struct dmi_system_id *id)
+static int __init setup_tsl2583_als(enum i2c_adapter_type type)
 {
-   /* add isl29023 light sensor on Panel GMBus */
-   als = add_i2c_device("lightsensor", I2C_ADAPTER_PANEL,
-&isl_als_device);
+   /* add tsl2583 light sensor */
+   als = add_i2c_device(NULL, type, &tsl2583_als_device);
return 0;
 }
 
-static int __init setup_tsl2583_als(const struct dmi_system_id *id)
+static int __init setup_tsl2563_als(enum i2c_adapter_type type)
 {
-   /* add tsl2583 light sensor on smbus */
-   als = add_smbus_device(NULL, &tsl2583_als_device);
+   /* add tsl2563 light sensor */
+   als = add_i2c_device(NULL, type, &tsl2563_als_device);
return 0;
 }
 
-static int __init setup_tsl2563_als(const struct dmi_system_id *id)
+static int __init
+chromeos_laptop_add_peripherals(const struct dmi_system_id *id)
 {
-   /* add tsl2563 light sensor on smbus */
-   als = add_smbus_device(NULL, &tsl2563_als_device);
-   return 0;
+   int i;
+   struct chromeos_laptop *cros_laptop = (void *)id->driver_data;
+
+   pr_debug("Adding peripherals for %s.\n", id->ident);
+
+   for (i = 0; i < MAX_I2C_PERIPHERALS; i++) {
+   struct i2c_peripheral *i2c_dev;
+
+   i2c_dev = &cros_laptop->i2c_peripherals[i];
+
+   /* No more peri

[PATCH 5/6] Platform: x86: chromeos_laptop - Add HP Chromebook 14

[Benson Leung]

Add support for the trackpad on HP Chromebook 14.

Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index 57ded03..a9ab335 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -378,6 +378,13 @@ static struct chromeos_laptop chromebook_pixel = {
},
 };
 
+static struct chromeos_laptop hp_chromebook_14 = {
+   .i2c_peripherals = {
+   /* Touchpad. */
+   { .add = setup_cyapa_tp, I2C_ADAPTER_I2C0 },
+   },
+};
+
 static struct chromeos_laptop acer_c7_chromebook = {
.i2c_peripherals = {
/* Touchpad. */
@@ -435,6 +442,13 @@ static struct dmi_system_id chromeos_laptop_dmi_table[] 
__initdata = {
_CBDD(chromebook_pixel),
},
{
+   .ident = "HP Chromebook 14",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "Falco"),
+   },
+   _CBDD(hp_chromebook_14),
+   },
+   {
.ident = "Acer C7 Chromebook",
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "Parrot"),
-- 
1.8.3.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/

[PATCH 3/6] Platform: x86: chromeos_laptop - fix incorrect placement of __initdata tag

[Benson Leung]

__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.

Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index e542330..1c2747f 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -406,7 +406,7 @@ static struct chromeos_laptop cr48 = {
.callback = chromeos_laptop_dmi_matched, \
.driver_data = (void *)&board_
 
-static struct dmi_system_id __initdata chromeos_laptop_dmi_table[] = {
+static struct dmi_system_id chromeos_laptop_dmi_table[] __initdata = {
{
.ident = "Samsung Series 5 550",
.matches = {
-- 
1.8.3.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/

[PATCH 4/6] Platform: x86: chromeos_laptop - Add names of Haswell ULT i2c busses

[Benson Leung]

The designware-pci i2c busses will be named "i2c-designware-pci-0"
and "i2c-designware-pci-1" accordingly.

Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index 1c2747f..57ded03 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -45,6 +45,8 @@ const char *i2c_adapter_names[] = {
"SMBus I801 adapter",
"i915 gmbus vga",
"i915 gmbus panel",
+   "i2c-designware-pci-0",
+   "i2c-designware-pci-1",
 };
 
 /* Keep this enum consistent with i2c_adapter_names */
@@ -52,6 +54,8 @@ enum i2c_adapter_type {
I2C_ADAPTER_SMBUS = 0,
I2C_ADAPTER_VGADDC,
I2C_ADAPTER_PANEL,
+   I2C_ADAPTER_I2C0,
+   I2C_ADAPTER_I2C1,
 };
 
 struct i2c_peripheral {
-- 
1.8.3.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/

[PATCH 6/6] Platform: x86: chromeos_laptop - Add Acer C720

[Benson Leung]

Add the Acer C720 entries for trackpad and light sensor.

Signed-off-by: Benson Leung 
---
 drivers/platform/x86/chromeos_laptop.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/platform/x86/chromeos_laptop.c 
b/drivers/platform/x86/chromeos_laptop.c
index a9ab335..6e2e7fd 100644
--- a/drivers/platform/x86/chromeos_laptop.c
+++ b/drivers/platform/x86/chromeos_laptop.c
@@ -385,6 +385,15 @@ static struct chromeos_laptop hp_chromebook_14 = {
},
 };
 
+static struct chromeos_laptop acer_c720 = {
+   .i2c_peripherals = {
+   /* Light Sensor. */
+   { .add = setup_isl29018_als, I2C_ADAPTER_I2C1 },
+   /* Touchpad. */
+   { .add = setup_cyapa_tp, I2C_ADAPTER_I2C0 },
+   },
+};
+
 static struct chromeos_laptop acer_c7_chromebook = {
.i2c_peripherals = {
/* Touchpad. */
@@ -449,6 +458,13 @@ static struct dmi_system_id chromeos_laptop_dmi_table[] 
__initdata = {
_CBDD(hp_chromebook_14),
},
{
+   .ident = "Acer C720",
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "Peppy"),
+   },
+   _CBDD(acer_c720),
+   },
+   {
.ident = "Acer C7 Chromebook",
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "Parrot"),
-- 
1.8.3.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 4/3] x86/vdso: Optimize setup_additional_pages()

[Davidlohr Bueso]

Hi Ingo,

On Fri, 2013-10-18 at 08:05 +0200, Ingo Molnar wrote:
> * Davidlohr Bueso  wrote:
> 
> > --- a/arch/x86/vdso/vma.c
> > +++ b/arch/x86/vdso/vma.c
> > @@ -154,12 +154,17 @@ static int setup_additional_pages(struct linux_binprm 
> > *bprm,
> >   unsigned size)
> >  {
> > struct mm_struct *mm = current->mm;
> > +   struct vm_area_struct *vma;
> > unsigned long addr;
> > int ret;
> >  
> > if (!vdso_enabled)
> > return 0;
> >  
> > +   vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
> > +   if (unlikely(!vma))
> > +   return -ENOMEM;
> > +
> > down_write(&mm->mmap_sem);
> > addr = vdso_addr(mm->start_stack, size);
> > addr = get_unmapped_area(NULL, addr, size, 0, 0);
> > @@ -173,14 +178,17 @@ static int setup_additional_pages(struct linux_binprm 
> > *bprm,
> > ret = install_special_mapping(mm, addr, size,
> >   VM_READ|VM_EXEC|
> >   VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
> > - pages);
> > + pages, &vma);
> > if (ret) {
> > current->mm->context.vdso = NULL;
> > goto up_fail;
> > }
> >  
> > +   up_write(&mm->mmap_sem);
> > +   return ret;
> >  up_fail:
> > up_write(&mm->mmap_sem);
> > +   kmem_cache_free(vm_area_cachep, vma);
> > return ret;
> >  }
> >  
> 
> 1)
> 
> Beyond the simplification that Linus suggested, why not introduce a new 
> function, named 'install_special_mapping_vma()' or so, and convert 
> architectures one by one, without pressure to get it all done (and all 
> correct) in a single patch?
> 

Hmm I'd normally take this approach but updating the callers from all
architectures was so straightforward and monotonous that I think it's
easier to just do it all at once. Andrew had suggested using linux-next
for testing, so if some arch breaks (in the not-compiling sense), the
maintainer or I can easily address the issue.

> 2)
> 
> I don't see the justification: this code gets executed in exec() where a 
> new mm has just been allocated. There's only a single user of the mm and 
> thus the critical section width of mmap_sem is more or less irrelevant.
> 
> mmap_sem critical section size only matters for codepaths that threaded 
> programs can hit.
> 

Yes, I was surprised by the performance boost I noticed when running
this patch. This weekend I re-ran the tests (including your 4/3 patch)
and noticed that while we're still getting some benefits (more like in
the +5% throughput range), it's not as good as I originally reported. I
believe the reason is because I had ran the tests on the vanilla kernel
without the max clock frequency, so the comparison was obviously not
fair. That said, I still think it's worth adding this patch, as it does
help at a micro-optimization level, and it's one less mmap_sem user we
have to worry about.

> 3)
> 
> But, if we do all that, a couple of other (micro-)optimizations are 
> possible in setup_additional_pages() as well:

I've rebased your patch on top of mine and things ran fine over the
weekend, didn't notice anything unusual - see below. I've *not* added
your SoB tag, so if you think it's good to go, please go ahead and add
it.

> 
>  - vdso_addr(), which is actually much _more_ expensive than kmalloc() 
>because on most distros it will call into the RNG, can also be done 
>outside the mmap_sem.
> 
>  - the error paths can all be merged and the common case can be made 
>fall-through.
> 
>  - use 'mm' consistently instead of repeating 'current->mm'
> 
>  - set 'mm->context.vdso' only once we know it's all a success, and do it 
>outside the lock
> 
>  - add a few comments about which operations are locked, which unlocked, 
>and why. Please double check the assumptions I documented there.
> 
> See the diff attached below. (Totally untested and all that.)
> 
> Also note that I think, in theory, if exec() guaranteed the privacy and 
> single threadedness of the new mm, we could probably do _all_ of this 
> unlocked. Right now I don't think this is guaranteed: ptrace() users might 
> look up the new PID and might interfere on the MM via 
> PTRACE_PEEK*/PTRACE_POKE*.
> 
> ( Furthermore, /proc/ might also give early access to aspects of the mm - 
>   although no manipulation of the mm is possible there. )

I was not aware of this, thanks for going into more details.

> 
> If such privacy of the new mm was guaranteed then that would also remove 
> the need to move the allocation out of install_special_mapping().
> 
> But, I don't think it all matters, due to #2 - and your changes actively 
> complicate setup_pages(), which makes this security sensitive code a bit 
> more fragile. We can still do it out of sheer principle, I just don't see 
> where it's supposed to help scale better.

I think that trying to guarantee new mm privacy would actually
complicate things much more than this patch, which 

Re: [PATCH] init: fix in-place parameter modification regression

[Rusty Russell]

Krzysztof Mazur  writes:
> On Fri, Oct 18, 2013 at 02:20:38PM +1030, Rusty Russell wrote:
>> Back when there was almost no parameter parsing support, everyone got
>> used to keeping pointers into the original.  Making everyone kstrdup()
>> seems like gratuitous churn which is likely to make more bugs.
>> 
>> Your fix means __setup() gets treated specially, in that only it can
>> mangle the command line.  That makes sense.  But it introduces another
>> regression: normal parsing functions can't keep pointers, since that's
>> now __initdata.
>> 
>> There are two possible solutions:
>> (1) Audit all __setup to make sure they copy if they want to mangle.
>> There are about 750 of them, but many are trivial.
>> (2) alloc_bootmem() a third commandline for parsing.
>> 
>> Now, many functions of form __setup("XXX=") should be turned into
>> module_param anyway.
>> 
>> I suggest we do (2) for the moment, and start sweeping through cleaning
>> up __setup() in the longer term.
>> 
>
> Yes, the buffer cannot be __initdata. I'm sending an updated patch.
>
>
> However, keeping pointers to buffer, that will be reinitialized
> in next initcall parameters parsing pass, might cause some race
> conditions.

Thanks, applied.

Cheers,
Rusty.

> Thanks,
> Krzysiek
>
> -- >8 --
> Subject: [PATCH v2] init: fix in-place parameter modification regression
>
> Before commit 026cee0086fe1df4cf74691cf273062cc769617d
> ("params: _initcall-like kernel parameters") the __setup
> parameter parsing code could modify parameter in the
> static_command_line buffer and such modifications were kept. After
> that commit such modifications are destroyed during per-initcall level
> parameter parsing because the same static_command_line buffer is used
> and only parameters for appropriate initcall level are parsed.
>
> That change broke at least parsing "ubd" parameter in the ubd driver
> when the COW file is used.
>
> Now the separate buffer is used for per-initcall parameter parsing.
>
> Signed-off-by: Krzysztof Mazur 
> ---
>  init/main.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index 63d3e8f..c093b5c 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -132,6 +132,8 @@ char __initdata boot_command_line[COMMAND_LINE_SIZE];
>  char *saved_command_line;
>  /* Command line for parameter parsing */
>  static char *static_command_line;
> +/* Command line for per-initcall parameter parsing */
> +static char *initcall_command_line;
>  
>  static char *execute_command;
>  static char *ramdisk_execute_command;
> @@ -348,6 +350,7 @@ static inline void smp_prepare_cpus(unsigned int maxcpus) 
> { }
>  static void __init setup_command_line(char *command_line)
>  {
>   saved_command_line = alloc_bootmem(strlen (boot_command_line)+1);
> + initcall_command_line = alloc_bootmem(strlen (boot_command_line)+1);
>   static_command_line = alloc_bootmem(strlen (command_line)+1);
>   strcpy (saved_command_line, boot_command_line);
>   strcpy (static_command_line, command_line);
> @@ -745,9 +748,9 @@ static void __init do_initcall_level(int level)
>   extern const struct kernel_param __start___param[], __stop___param[];
>   initcall_t *fn;
>  
> - strcpy(static_command_line, saved_command_line);
> + strcpy(initcall_command_line, saved_command_line);
>   parse_args(initcall_level_names[level],
> -static_command_line, __start___param,
> +initcall_command_line, __start___param,
>  __stop___param - __start___param,
>  level, level,
>  &repair_env_string);
> -- 
> 1.8.4.1.635.g6a5
--
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: module: Documentation/module-signing.txt?

[Rusty Russell]

Paul Bolle  writes:
> Rusty,
>
> Since v3.7 there's a link to Documentation/module-signing.txt in
> init/Kconfig. It was added by your commit 106a4ee258d1 ("module:
> signature checking hook"). It seems that this file was never added to
> the tree. Is it perhaps queued somewhere?

Well spotted.  David?

Thanks,
Rusty.
--
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: [sched] WARNING: CPU: 0 PID: 3166 at kernel/cpu.c:84 put_online_cpus()

[Michael wang]

Hi, Fengguang

On 10/19/2013 08:51 AM, Fengguang Wu wrote:
> Greetings,

Will this do any helps?

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c06b8d3..7c61f31 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3716,7 +3716,6 @@ long sched_setaffinity(pid_t pid, const struct
cpumask *in_mask)
p = find_process_by_pid(pid);
if (!p) {
rcu_read_unlock();
-   put_online_cpus();
return -ESRCH;
}

Regards,
Michael Wang

> 
> I got the below dmesg and the first bad commit is
> 
> commit 6acce3ef84520537f8a09a12c9ddbe814a584dd2
> Author: Peter Zijlstra 
> Date:   Fri Oct 11 14:38:20 2013 +0200
> 
> sched: Remove get_online_cpus() usage
> 
> Remove get_online_cpus() usage from the scheduler; there's 4 sites that
> use it:
> 
>  - sched_init_smp(); where its completely superfluous since we're in
>'early' boot and there simply cannot be any hotplugging.
> 
>  - sched_getaffinity(); we already take a raw spinlock to protect the
>task cpus_allowed mask, this disables preemption and therefore
>also stabilizes cpu_online_mask as that's modified using
>stop_machine. However switch to active mask for symmetry with
>sched_setaffinity()/set_cpus_allowed_ptr(). We guarantee active
>mask stability by inserting sync_rcu/sched() into _cpu_down.
> 
>  - sched_setaffinity(); we don't appear to need get_online_cpus()
>either, there's two sites where hotplug appears relevant:
> * cpuset_cpus_allowed(); for the !cpuset case we use possible_mask,
>   for the cpuset case we hold task_lock, which is a spinlock and
>   thus for mainline disables preemption (might cause pain on RT).
> * set_cpus_allowed_ptr(); Holds all scheduler locks and thus has
>   preemption properly disabled; also it already deals with hotplug
>   races explicitly where it releases them.
> 
>  - migrate_swap(); we can make stop_two_cpus() do the heavy lifting for
>us with a little trickery. By adding a sync_sched/rcu() after the
>CPU_DOWN_PREPARE notifier we can provide preempt/rcu guarantees for
>cpu_active_mask. Use these to validate that both our cpus are active
>when queueing the stop work before we queue the stop_machine works
>for take_cpu_down().
> 
> Signed-off-by: Peter Zijlstra 
> Cc: "Srivatsa S. Bhat" 
> Cc: Paul McKenney 
> Cc: Mel Gorman 
> Cc: Rik van Riel 
> Cc: Srikar Dronamraju 
> Cc: Andrea Arcangeli 
> Cc: Johannes Weiner 
> Cc: Linus Torvalds 
> Cc: Andrew Morton 
> Cc: Steven Rostedt 
> Cc: Oleg Nesterov 
> Link: 
> http://lkml.kernel.org/r/20131011123820.gv3...@twins.programming.kicks-ass.net
> Signed-off-by: Ingo Molnar 
> 
> [3165] Watchdog is alive
> [3159] Started watchdog thread 3165
> [   58.695502] [ cut here ]
> [   58.697835] WARNING: CPU: 0 PID: 3166 at kernel/cpu.c:84 
> put_online_cpus+0x43/0x70()
> [   58.702423] Modules linked in:
> [   58.704404] CPU: 0 PID: 3166 Comm: trinity-child0 Not tainted 
> 3.12.0-rc5-01882-gf3db366 #1172
> [   58.708530] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [   58.710992]   88000acfbe50 81a24643 
> 
> [   58.715410]  88000acfbe88 810c3e6b 810c3fef 
> 
> [   58.719826]   6ee0 0ffc 
> 88000acfbe98
> [   58.724348] Call Trace:
> [   58.726190]  [] dump_stack+0x4d/0x66
> [   58.728531]  [] warn_slowpath_common+0x7f/0x98
> [   58.731069]  [] ? put_online_cpus+0x43/0x70
> [   58.733664]  [] warn_slowpath_null+0x1a/0x1c
> [   58.736258]  [] put_online_cpus+0x43/0x70
> [   58.738686]  [] sched_setaffinity+0x7d/0x1f9
> [   58.741210]  [] ? sched_setaffinity+0x5/0x1f9
> [   58.743775]  [] ? _raw_spin_unlock_irq+0x2c/0x3e
> [   58.746417]  [] ? do_setitimer+0x194/0x1f5
> [   58.748899]  [] SyS_sched_setaffinity+0x62/0x71
> [   58.751481]  [] system_call_fastpath+0x16/0x1b
> [   58.754070] ---[ end trace 034818a1f6f06868 ]---
> [   58.757521] [ cut here ]
> 
> git bisect start f3db36699379159b761cdbc093347822a633c616 
> 2fe80d3bbf1c8bd9efc5b8154207c8dd104e7306 --
> git bisect good 0f2a02d75d0f37f1624585c50c3250b6d096f050  # 12:02 21+ 
> 19  kvm tools: fix function name
> git bisect good ee6946e6810792f208662507055e6f9c32f42898  # 13:47 21+ 
>  0  x86: perf -- Allow perf watchdog to use perfmon bit for msr index 
> computation
> git bisect good 2eb3090631e1f3c5920e27e0a51ed876e88fe871  # 15:07 21+ 
>  0  Merge branch 'linus'
> git bisect good bf2575c121ca11247ef07fd02b43f7430834f7b1  # 15:58 21+ 
>  0  perf trace: Add summary option to dump syscall statistics
> git bisect good d6099aeb4a9aad5e7ab1c72eb119ebd52dee0d52  # 16:36 21+ 
>  0  Merge branch 'fi

[PATCH 1/2] i2c-designware-pci: Add Haswell ULT device IDs

[Benson Leung]

From: Duncan Laurie 

Add the necessary PCI Device IDs to use the Haswell ULT
I2C controller in PCI mode.

Set the bus numbers to -1 so it will use dynamic assignment
rather than hardcoded.

Signed-off-by: Duncan Laurie 
Signed-off-by: Benson Leung 
---
 drivers/i2c/busses/i2c-designware-pcidrv.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index f6ed06c..e4cbbdf 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -54,6 +54,9 @@ enum dw_pci_ctl_id_t {
medfield_3,
medfield_4,
medfield_5,
+
+   haswell_0,
+   haswell_1,
 };
 
 struct dw_pci_controller {
@@ -132,6 +135,20 @@ static struct  dw_pci_controller  dw_pci_controllers[] = {
.rx_fifo_depth = 32,
.clk_khz  = 25000,
},
+   [haswell_0] = {
+   .bus_num = -1,
+   .bus_cfg   = INTEL_MID_STD_CFG | DW_IC_CON_SPEED_STD,
+   .tx_fifo_depth = 32,
+   .rx_fifo_depth = 32,
+   .clk_khz  = 25000,
+   },
+   [haswell_1] = {
+   .bus_num = -1,
+   .bus_cfg   = INTEL_MID_STD_CFG | DW_IC_CON_SPEED_STD,
+   .tx_fifo_depth = 32,
+   .rx_fifo_depth = 32,
+   .clk_khz  = 25000,
+   },
 };
 static struct i2c_algorithm i2c_dw_algo = {
.master_xfer= i2c_dw_xfer,
@@ -321,6 +338,9 @@ static DEFINE_PCI_DEVICE_TABLE(i2_designware_pci_ids) = {
{ PCI_VDEVICE(INTEL, 0x082C), medfield_0 },
{ PCI_VDEVICE(INTEL, 0x082D), medfield_1 },
{ PCI_VDEVICE(INTEL, 0x082E), medfield_2 },
+   /* Haswell ULT */
+   { PCI_VDEVICE(INTEL, 0x9c61), haswell_0 },
+   { PCI_VDEVICE(INTEL, 0x9c62), haswell_1 },
{ 0,}
 };
 MODULE_DEVICE_TABLE(pci, i2_designware_pci_ids);
-- 
1.8.3.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/

[PATCH 0/2] i2c-designware-pci: Add Haswell ULT device support

[Benson Leung]

Add the Haswell ULT device IDs for i2c-designware-pci. These are used,
for example, in Haswell generation Chromebooks, the HP Chromebook 14
and the Acer C720.

[PATCH 1/2] i2c-designware-pci: Add Haswell ULT device IDs
[PATCH 2/2] i2c-designware-pci: Index Haswell ULT bus names from 0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] i2c-designware-pci: Index Haswell ULT bus names from 0

[Benson Leung]

Rather than having the bus names be "i2c-designware-pci--1" because
we have set the .bus_num to -1 to force dynamic allocation, lets have
the busses named "i2c-designware-pci-0" and "i2c-designware-pci-1"
to correspond to the correct names of these busses.

The adapter number will still be dynamically assigned.

Signed-off-by: Benson Leung 
---
 drivers/i2c/busses/i2c-designware-pcidrv.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index e4cbbdf..d08b2d9 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -229,7 +229,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
 {
struct dw_i2c_dev *dev;
struct i2c_adapter *adap;
-   int r;
+   int r, adapter_num;
struct  dw_pci_controller *controller;
 
if (id->driver_data >= ARRAY_SIZE(dw_pci_controllers)) {
@@ -287,8 +287,18 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
adap->algo = &i2c_dw_algo;
adap->dev.parent = &pdev->dev;
adap->nr = controller->bus_num;
-   snprintf(adap->name, sizeof(adap->name), "i2c-designware-pci-%d",
-   adap->nr);
+
+   switch (id->driver_data) {
+   case haswell_0:
+   case haswell_1:
+   adapter_num = id->driver_data - haswell_0;
+   break;
+   default:
+   adapter_num = adap->nr;
+   break;
+   }
+   snprintf(adap->name, sizeof(adap->name), "i2c-designware-pci-%ld",
+adapter_num);
 
r = devm_request_irq(&pdev->dev, pdev->irq, i2c_dw_isr, IRQF_SHARED,
adap->name, dev);
-- 
1.8.3.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 3/3] vdso: preallocate new vmas

[Davidlohr Bueso]

From: Davidlohr Bueso 
Subject: [PATCH v2 3/3] vdso: preallocate new vmas

With the exception of um and tile, architectures that use
the install_special_mapping() function, when setting up a
new vma at program startup, do so with the mmap_sem lock
held for writing. Unless there's an error, this process
ends up allocating a new vma through kmem_cache_zalloc,
and inserting it in the task's address space.

This patch moves the vma's space allocation outside of
install_special_mapping(), and leaves the callers to do so
explicitly, without depending on mmap_sem. The same goes for
freeing: if the new vma isn't used (and thus the process fails
at some point), it's caller's responsibility to free it -
currently this is done inside install_special_mapping.

Furthermore, uprobes behaves exactly the same and thus now the
xol_add_vma() function also preallocates the new vma.

While the changes to x86 vdso handling have been tested on both
large and small 64-bit systems, the rest of the architectures
are totally *untested*. Note that all changes are quite similar
from architecture to architecture.

Signed-off-by: Davidlohr Bueso 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Richard Kuo 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Paul Mundt 
Cc: Chris Metcalf 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Peter Zijlstra 
---
v2:
- Simplify install_special_mapping interface (Linus Torvalds)
- Fix return for uml_setup_stubs when mem allocation fails (Richard Weinberger)

 arch/arm/kernel/process.c  | 22 --
 arch/arm64/kernel/vdso.c   | 21 +
 arch/hexagon/kernel/vdso.c | 16 
 arch/mips/kernel/vdso.c| 10 +-
 arch/powerpc/kernel/vdso.c | 11 ---
 arch/s390/kernel/vdso.c| 19 +++
 arch/sh/kernel/vsyscall/vsyscall.c | 11 ++-
 arch/tile/kernel/vdso.c| 13 ++---
 arch/um/kernel/skas/mmu.c  | 16 +++-
 arch/unicore32/kernel/process.c| 17 -
 arch/x86/um/vdso/vma.c | 18 ++
 arch/x86/vdso/vdso32-setup.c   | 16 +++-
 arch/x86/vdso/vma.c| 10 +-
 include/linux/mm.h |  3 ++-
 kernel/events/uprobes.c| 14 --
 mm/mmap.c  | 17 ++---
 16 files changed, 178 insertions(+), 56 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 94f6b05..d1eb115 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -480,6 +481,7 @@ extern struct page *get_signal_page(void);
 int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 {
struct mm_struct *mm = current->mm;
+   struct vm_area_struct *vma;
unsigned long addr;
int ret;
 
@@ -488,6 +490,10 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
if (!signal_page)
return -ENOMEM;
 
+   vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
+   if (unlikely(!vma))
+   return -ENOMEM;
+
down_write(&mm->mmap_sem);
addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
if (IS_ERR_VALUE(addr)) {
@@ -496,14 +502,18 @@ int arch_setup_additional_pages(struct linux_binprm 
*bprm, int uses_interp)
}
 
ret = install_special_mapping(mm, addr, PAGE_SIZE,
-   VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
-   &signal_page);
-
-   if (ret == 0)
-   mm->context.sigpage = addr;
+ VM_READ | VM_EXEC | VM_MAYREAD |
+ VM_MAYWRITE | VM_MAYEXEC,
+ &signal_page, vma);
+   if (ret)
+   goto up_fail;
 
- up_fail:
+   mm->context.sigpage = addr;
+   up_write(&mm->mmap_sem);
+   return 0;
+up_fail:
up_write(&mm->mmap_sem);
+   kmem_cache_free(vm_area_cachep, vma);
return ret;
 }
 #endif
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 6a389dc..06a01ea 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -83,20 +83,26 @@ arch_initcall(alloc_vectors_page);
 
 int aarch32_setup_vectors_page(struct linux_binprm *bprm, int uses_interp)
 {
+   struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
unsigned long addr = AARCH32_VECTORS_BASE;
int ret;
 
+   vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
+   if (unlikely(!vma))
+   return -ENOMEM;
+
down_write(&mm->mmap_sem);
current->mm->context.vdso = (void *)addr;
 
/* Map vectors

Re: [PATCH 1/3] ACPI: add module autoloading support for ACPI enumerated devices

[Aaron Lu]

On 10/14/2013 05:10 PM, Zhang Rui wrote:
> An ACPI enumerated device may have its compatible id strings.
> 
> To support the compatible ACPI ids (acpi_device->pnp.ids),
> we introduced acpi_driver_match_device() to match
> the driver->acpi_match_table and acpi_device->pnp.ids.
> 
> For those drivers, MODULE_DEVICE_TABLE(acpi, xxx) is used to
> exports the driver module alias in the format of
> "acpi:device_compatible_ids".
> But in the mean time, the current code does not export the
> ACPI compatible strings as part of the module_alias for the
> ACPI enumerated devices, which will break the module autoloading.
> 
> Take the following piece of code for example,
> static const struct acpi_device_id xxx_acpi_match[] = {
> { "INTABCD", 0 },
> { }
> };
> MODULE_DEVICE_TABLE(acpi, xxx_acpi_match);
> 
> If this piece of code is used in a platform driver for
> an ACPI enumerated platform device, the platform driver module_alias
> is "acpi:INTABCD", but the uevent attribute of its platform device node
> is "platform:INTABCD:00" (PREFIX:pdev->name).
> If this piece of code is used in an i2c driver for an ACPI enumerated
> i2c device, the i2c driver module_alias is "acpi:INTABCD", but
> the uevent of its i2c device node is "i2c:INTABCD:00" (PREFIX:client->name).
> 
> The reason why the module autoloading is not broken for now is that
> the uevent file of the ACPI device node is "acpi:INTABCD".
> Thus it is the ACPI device node creation that loads the platform/i2c driver.
> 
> So this is a problem that will affect us the day when the ACPI bus
> is removed from device model.
> 
> This patch introduces a new function to exporting ACPI ids as the
> module_alias, for the ACPI enumerate devices.
> 
> For any drivers using MODULE_DEVICE_TALBE(acpi, blabla), the uevent file
> of its associated device must be fixed by invoking this function.
> 
> Signed-off-by: Zhang Rui 
> ---
>  drivers/acpi/scan.c  |   24 
>  include/linux/acpi.h |8 
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 407ad13..db6f879 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -111,6 +111,30 @@ static int create_modalias(struct acpi_device *acpi_dev, 
> char *modalias,
>   return len;
>  }
>  
> +int acpi_device_uevent_modalias(struct device *dev, struct kobj_uevent_env 
> *env)
> +{
> + struct acpi_device *acpi_dev;
> + int result;
> + int len;
> +
> + result = acpi_bus_get_device(ACPI_HANDLE(dev), &acpi_dev);
> + if (result)
> + return result;
> +
> + if (list_empty(&acpi_dev->pnp.ids))
> + return 0;
> +
> + if (add_uevent_var(env, "MODALIAS="))
> + return -ENOMEM;
> + len = create_modalias(acpi_dev, &env->buf[env->buflen - 1],
> + sizeof(env->buf) - env->buflen);
> + if (len >= (sizeof(env->buf) - env->buflen))
> + return -ENOMEM;
> + env->buflen += len;
> + return 0;
> +}
> +EXPORT_SYMBOL(acpi_device_uevent_modalias);

Looks like this function shares a lot with the existing
acpi_device_uevent, so perhaps worth making some resue of the exising
code? e.g. seperate the common code into a function and then have the
two functions call it.

-Aaron

> +
>  static ssize_t
>  acpi_device_modalias_show(struct device *dev, struct device_attribute *attr, 
> char *buf) {
>   struct acpi_device *acpi_dev = to_acpi_device(dev);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index a5db4ae..117fa26 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -401,6 +401,8 @@ static inline bool acpi_driver_match_device(struct device 
> *dev,
>   return !!acpi_match_device(drv->acpi_match_table, dev);
>  }
>  
> +int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
> +
>  #define ACPI_PTR(_ptr)   (_ptr)
>  
>  #else/* !CONFIG_ACPI */
> @@ -471,6 +473,12 @@ static inline bool acpi_driver_match_device(struct 
> device *dev,
>   return false;
>  }
>  
> +static inline int acpi_device_uevent_modalias(struct device *dev,
> + struct kobj_uevent_env *env)
> +{
> + return -ENODEV;
> +}
> +
>  #define ACPI_PTR(_ptr)   (NULL)
>  
>  #endif   /* !CONFIG_ACPI */
> 

--
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: [tip:sched/core] sched, idle: Fix the idle polling state logic

[Yuanhan Liu]

On Wed, Sep 25, 2013 at 09:38:19AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID:  ea8117478918a4734586d35ff530721b682425be
> Gitweb: http://git.kernel.org/tip/ea8117478918a4734586d35ff530721b682425be
> Author: Peter Zijlstra 
> AuthorDate: Wed, 11 Sep 2013 12:43:13 +0200
> Committer:  Ingo Molnar 
> CommitDate: Wed, 25 Sep 2013 13:53:10 +0200
> 
> sched, idle: Fix the idle polling state logic
> 
> Mike reported that commit 7d1a9417 ("x86: Use generic idle loop")
> regressed several workloads and caused excessive reschedule
> interrupts.

Hi,

JFYI, this patch does reduce interruptes in our test:

   platform: Sandbridge
   testcase: aim7/creat-clo

   * --  with this patch
   O --  without this patch
interrupts.RES

   1.2e+08 ++---+
   ||
 1e+08 O+   OOOOOOOOOO  |
   ||
   ||
 8e+07 ++   |
   ||
 6e+07 ++   |
   ||
 4e+07 ++   |
   ||
   ||
 2e+07 ++   |
   ******   ..*******
 0 ++*--+



   vmstat.system.in

   16 +++
  O O O |
   14 ++   O   OO OOOO  |
   12 ++ O  |
  | |
   10 ++|
  | |
8 ++|
  | |
6 ++|
4 ++|
  | |
2 *+...***** ..******
  | *.*..   |
0 +++


--yliu

> 
> The patch in question failed to notice that the x86 code had an
> inverted sense of the polling state versus the new generic code (x86:
> default polling, generic: default !polling).
> 
> Fix the two prominent x86 mwait based idle drivers and introduce a few
> new generic polling helpers (fixing the wrong smp_mb__after_clear_bit
> usage).
> 
> Also switch the idle routines to using tif_need_resched() which is an
> immediate TIF_NEED_RESCHED test as opposed to need_resched which will
> end up being slightly different.
> 
> Reported-by: Mike Galbraith 
> Signed-off-by: Peter Zijlstra 
> Cc: l...@kernel.org
> Cc: t...@linutronix.de
> Link: http://lkml.kernel.org/n/tip-nc03imb0etuefmzybzj7s...@git.kernel.org
> Signed-off-by: Ingo Molnar 
> ---
>  arch/x86/kernel/process.c |  6 ++--
>  drivers/acpi/processor_idle.c | 46 ++---
>  drivers/idle/intel_idle.c |  2 +-
>  include/linux/sched.h | 78 
> +++
>  include/linux/thread_info.h   |  2 ++
>  kernel/cpu/idle.c |  9 +++--
>  6 files changed, 91 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index c83516b..3fb8d95 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -391,9 +391,9 @@ static void amd_e400_idle(void)
>* The switch back from broadcast mode needs to be
>* called with interrupts disabled.
>*/
> -  local_irq_disable();
> -  clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> -  local_irq_enable();
> + local_irq_disable();
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
> + local_irq_enable();
>   } else
>

[PATCH -next] xfs: remove duplicated include from xfs_bmap.c

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 fs/xfs/xfs_bmap.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c
index e6b4202..92b97f7 100644
--- a/fs/xfs/xfs_bmap.c
+++ b/fs/xfs/xfs_bmap.c
@@ -34,7 +34,6 @@
 #include "xfs_dinode.h"
 #include "xfs_inode.h"
 #include "xfs_btree.h"
-#include "xfs_mount.h"
 #include "xfs_itable.h"
 #include "xfs_inode_item.h"
 #include "xfs_extfree_item.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/

[PATCH -next] pinctrl: tb10x: use module_platform_driver to simplify the code

[Wei Yongjun]

From: Wei Yongjun 

module_platform_driver() makes the code simpler by eliminating
boilerplate code.

Signed-off-by: Wei Yongjun 
---
 drivers/pinctrl/pinctrl-tb10x.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-tb10x.c b/drivers/pinctrl/pinctrl-tb10x.c
index 2e1ea56..abf55c9 100644
--- a/drivers/pinctrl/pinctrl-tb10x.c
+++ b/drivers/pinctrl/pinctrl-tb10x.c
@@ -870,17 +870,7 @@ static struct platform_driver tb10x_pinctrl_pdrv = {
}
 };
 
-static int __init tb10x_iopinctrl_init(void)
-{
-   return platform_driver_register(&tb10x_pinctrl_pdrv);
-}
-
-static void __exit tb10x_iopinctrl_exit(void)
-{
-   platform_driver_unregister(&tb10x_pinctrl_pdrv);
-}
+module_platform_driver(tb10x_pinctrl_pdrv);
 
 MODULE_AUTHOR("Christian Ruppert ");
 MODULE_LICENSE("GPL");
-module_init(tb10x_iopinctrl_init);
-module_exit(tb10x_iopinctrl_exit);

--
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 -next] pinctrl: tb10x: fix the error handling in tb10x_pinctrl_probe()

[Wei Yongjun]

From: Wei Yongjun 

This patch fix the error handling in tb10x_pinctrl_probe():
 - devm_ioremap_resource() return ERR_PTR() and never return NULL
 - remove the dev_err call to avoid redundant error message
 - pinctrl_register() returns NULL not ERR_PTR()

Signed-off-by: Wei Yongjun 
---
 drivers/pinctrl/pinctrl-tb10x.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-tb10x.c b/drivers/pinctrl/pinctrl-tb10x.c
index 2e1ea56..9f7fa9b 100644
--- a/drivers/pinctrl/pinctrl-tb10x.c
+++ b/drivers/pinctrl/pinctrl-tb10x.c
@@ -806,9 +806,8 @@ static int tb10x_pinctrl_probe(struct platform_device *pdev)
mutex_init(&state->mutex);
 
state->base = devm_ioremap_resource(dev, mem);
-   if (!state->base) {
-   dev_err(dev, "Request register region failed.\n");
-   ret = -EBUSY;
+   if (IS_ERR(state->base)) {
+   ret = PTR_ERR(state->base);
goto fail;
}
 
@@ -830,9 +829,9 @@ static int tb10x_pinctrl_probe(struct platform_device *pdev)
}
 
state->pctl = pinctrl_register(&tb10x_pindesc, dev, state);
-   if (IS_ERR(state->pctl)) {
+   if (!state->pctl) {
dev_err(dev, "could not register TB10x pin driver\n");
-   ret = PTR_ERR(state->pctl);
+   ret = -EINVAL;
goto fail;
}
 

--
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/

[for-next][PATCH 4/6] ftrace: Introduce struct ftrace_graph_data

[Steven Rostedt]

From: Namhyung Kim 

The struct ftrace_graph_data is for generalizing the access to
set_graph_function file.  This is a preparation for adding support to
set_graph_notrace.

Link: 
http://lkml.kernel.org/r/1381739066-7531-3-git-send-email-namhy...@kernel.org

Signed-off-by: Namhyung Kim 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/ftrace.c | 81 +++
 1 file changed, 62 insertions(+), 19 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index a77e4a0..0ff3449 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3641,7 +3641,7 @@ __setup("ftrace_filter=", set_ftrace_filter);
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 static char ftrace_graph_buf[FTRACE_FILTER_SIZE] __initdata;
-static int ftrace_set_func(unsigned long *array, int *idx, char *buffer);
+static int ftrace_set_func(unsigned long *array, int *idx, int size, char 
*buffer);
 
 static int __init set_graph_function(char *str)
 {
@@ -3659,7 +3659,7 @@ static void __init set_ftrace_early_graph(char *buf)
func = strsep(&buf, ",");
/* we allow only one expression at a time */
ret = ftrace_set_func(ftrace_graph_funcs, &ftrace_graph_count,
- func);
+ FTRACE_GRAPH_MAX_FUNCS, func);
if (ret)
printk(KERN_DEBUG "ftrace: function %s not "
  "traceable\n", func);
@@ -3778,12 +3778,21 @@ static DEFINE_MUTEX(graph_lock);
 int ftrace_graph_count;
 unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
 
+struct ftrace_graph_data {
+   unsigned long *table;
+   size_t size;
+   int *count;
+   const struct seq_operations *seq_ops;
+};
+
 static void *
 __g_next(struct seq_file *m, loff_t *pos)
 {
-   if (*pos >= ftrace_graph_count)
+   struct ftrace_graph_data *fgd = m->private;
+
+   if (*pos >= *fgd->count)
return NULL;
-   return &ftrace_graph_funcs[*pos];
+   return &fgd->table[*pos];
 }
 
 static void *
@@ -3795,10 +3804,12 @@ g_next(struct seq_file *m, void *v, loff_t *pos)
 
 static void *g_start(struct seq_file *m, loff_t *pos)
 {
+   struct ftrace_graph_data *fgd = m->private;
+
mutex_lock(&graph_lock);
 
/* Nothing, tell g_show to print all functions are enabled */
-   if (!ftrace_graph_count && !*pos)
+   if (!*fgd->count && !*pos)
return (void *)1;
 
return __g_next(m, pos);
@@ -3834,37 +3845,68 @@ static const struct seq_operations ftrace_graph_seq_ops 
= {
 };
 
 static int
-ftrace_graph_open(struct inode *inode, struct file *file)
+__ftrace_graph_open(struct inode *inode, struct file *file,
+   struct ftrace_graph_data *fgd)
 {
int ret = 0;
 
-   if (unlikely(ftrace_disabled))
-   return -ENODEV;
-
mutex_lock(&graph_lock);
if ((file->f_mode & FMODE_WRITE) &&
(file->f_flags & O_TRUNC)) {
-   ftrace_graph_count = 0;
-   memset(ftrace_graph_funcs, 0, sizeof(ftrace_graph_funcs));
+   *fgd->count = 0;
+   memset(fgd->table, 0, fgd->size * sizeof(*fgd->table));
}
mutex_unlock(&graph_lock);
 
-   if (file->f_mode & FMODE_READ)
-   ret = seq_open(file, &ftrace_graph_seq_ops);
+   if (file->f_mode & FMODE_READ) {
+   ret = seq_open(file, fgd->seq_ops);
+   if (!ret) {
+   struct seq_file *m = file->private_data;
+   m->private = fgd;
+   }
+   } else
+   file->private_data = fgd;
 
return ret;
 }
 
 static int
+ftrace_graph_open(struct inode *inode, struct file *file)
+{
+   struct ftrace_graph_data *fgd;
+
+   if (unlikely(ftrace_disabled))
+   return -ENODEV;
+
+   fgd = kmalloc(sizeof(*fgd), GFP_KERNEL);
+   if (fgd == NULL)
+   return -ENOMEM;
+
+   fgd->table = ftrace_graph_funcs;
+   fgd->size = FTRACE_GRAPH_MAX_FUNCS;
+   fgd->count = &ftrace_graph_count;
+   fgd->seq_ops = &ftrace_graph_seq_ops;
+
+   return __ftrace_graph_open(inode, file, fgd);
+}
+
+static int
 ftrace_graph_release(struct inode *inode, struct file *file)
 {
-   if (file->f_mode & FMODE_READ)
+   if (file->f_mode & FMODE_READ) {
+   struct seq_file *m = file->private_data;
+
+   kfree(m->private);
seq_release(inode, file);
+   } else {
+   kfree(file->private_data);
+   }
+
return 0;
 }
 
 static int
-ftrace_set_func(unsigned long *array, int *idx, char *buffer)
+ftrace_set_func(unsigned long *array, int *idx, int size, char *buffer)
 {
struct dyn_ftrace *rec;
struct ftrace_page *pg;
@@ -3877,7 +3919,7 @@ ftrace_set_func(unsigned long *array, int *idx, char 
*buffer)
 
/* decode 

[for-next][PATCH 5/6] ftrace: Narrow down the protected area of graph_lock

[Steven Rostedt]

From: Namhyung Kim 

The parser set up is just a generic utility that uses local variables
allocated by the function. There's no need to hold the graph_lock for
this set up.

This also makes the code simpler.

Link: 
http://lkml.kernel.org/r/1381739066-7531-4-git-send-email-namhy...@kernel.org

Signed-off-by: Namhyung Kim 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/ftrace.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 0ff3449..26a229a 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3973,37 +3973,33 @@ ftrace_graph_write(struct file *file, const char __user 
*ubuf,
   size_t cnt, loff_t *ppos)
 {
struct trace_parser parser;
-   ssize_t read, ret;
+   ssize_t read, ret = 0;
struct ftrace_graph_data *fgd = file->private_data;
 
if (!cnt)
return 0;
 
-   mutex_lock(&graph_lock);
-
-   if (trace_parser_get_init(&parser, FTRACE_BUFF_MAX)) {
-   ret = -ENOMEM;
-   goto out_unlock;
-   }
+   if (trace_parser_get_init(&parser, FTRACE_BUFF_MAX))
+   return -ENOMEM;
 
read = trace_get_user(&parser, ubuf, cnt, ppos);
 
if (read >= 0 && trace_parser_loaded((&parser))) {
parser.buffer[parser.idx] = 0;
 
+   mutex_lock(&graph_lock);
+
/* we allow only one expression at a time */
ret = ftrace_set_func(fgd->table, fgd->count, fgd->size,
  parser.buffer);
-   if (ret)
-   goto out_free;
+
+   mutex_unlock(&graph_lock);
}
 
-   ret = read;
+   if (!ret)
+   ret = read;
 
-out_free:
trace_parser_put(&parser);
-out_unlock:
-   mutex_unlock(&graph_lock);
 
return ret;
 }
-- 
1.8.4.rc3


--
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/

[for-next][PATCH 6/6] ftrace: Add set_graph_notrace filter

[Steven Rostedt]

From: Namhyung Kim 

The set_graph_notrace filter is analogous to set_ftrace_notrace and
can be used for eliminating uninteresting part of function graph trace
output.  It also works with set_graph_function nicely.

  # cd /sys/kernel/debug/tracing/
  # echo do_page_fault > set_graph_function
  # perf ftrace live true
   2)   |  do_page_fault() {
   2)   |__do_page_fault() {
   2)   0.381 us|  down_read_trylock();
   2)   0.055 us|  __might_sleep();
   2)   0.696 us|  find_vma();
   2)   |  handle_mm_fault() {
   2)   |handle_pte_fault() {
   2)   |  __do_fault() {
   2)   |filemap_fault() {
   2)   |  find_get_page() {
   2)   0.033 us|__rcu_read_lock();
   2)   0.035 us|__rcu_read_unlock();
   2)   1.696 us|  }
   2)   0.031 us|  __might_sleep();
   2)   2.831 us|}
   2)   |_raw_spin_lock() {
   2)   0.046 us|  add_preempt_count();
   2)   0.841 us|}
   2)   0.033 us|page_add_file_rmap();
   2)   |_raw_spin_unlock() {
   2)   0.057 us|  sub_preempt_count();
   2)   0.568 us|}
   2)   |unlock_page() {
   2)   0.084 us|  page_waitqueue();
   2)   0.126 us|  __wake_up_bit();
   2)   1.117 us|}
   2)   7.729 us|  }
   2)   8.397 us|}
   2)   8.956 us|  }
   2)   0.085 us|  up_read();
   2) + 12.745 us   |}
   2) + 13.401 us   |  }
  ...

  # echo handle_mm_fault > set_graph_notrace
  # perf ftrace live true
   1)   |  do_page_fault() {
   1)   |__do_page_fault() {
   1)   0.205 us|  down_read_trylock();
   1)   0.041 us|  __might_sleep();
   1)   0.344 us|  find_vma();
   1)   0.069 us|  up_read();
   1)   4.692 us|}
   1)   5.311 us|  }
  ...

Link: 
http://lkml.kernel.org/r/1381739066-7531-5-git-send-email-namhy...@kernel.org

Signed-off-by: Namhyung Kim 
Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace.h   |  1 +
 kernel/trace/ftrace.c| 33 +
 kernel/trace/trace.h | 22 ++
 kernel/trace/trace_functions_graph.c | 56 ++--
 4 files changed, 109 insertions(+), 3 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 9f15c00..ec85d48 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -721,6 +721,7 @@ ftrace_push_return_trace(unsigned long ret, unsigned long 
func, int *depth,
 extern char __irqentry_text_start[];
 extern char __irqentry_text_end[];
 
+#define FTRACE_NOTRACE_DEPTH 65536
 #define FTRACE_RETFUNC_DEPTH 50
 #define FTRACE_RETSTACK_ALLOC_SIZE 32
 extern int register_ftrace_graph(trace_func_graph_ret_t retfunc,
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 26a229a..44e826a 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3776,7 +3776,9 @@ static const struct file_operations ftrace_notrace_fops = 
{
 static DEFINE_MUTEX(graph_lock);
 
 int ftrace_graph_count;
+int ftrace_graph_notrace_count;
 unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
+unsigned long ftrace_graph_notrace_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
 
 struct ftrace_graph_data {
unsigned long *table;
@@ -3891,6 +3893,26 @@ ftrace_graph_open(struct inode *inode, struct file *file)
 }
 
 static int
+ftrace_graph_notrace_open(struct inode *inode, struct file *file)
+{
+   struct ftrace_graph_data *fgd;
+
+   if (unlikely(ftrace_disabled))
+   return -ENODEV;
+
+   fgd = kmalloc(sizeof(*fgd), GFP_KERNEL);
+   if (fgd == NULL)
+   return -ENOMEM;
+
+   fgd->table = ftrace_graph_notrace_funcs;
+   fgd->size = FTRACE_GRAPH_MAX_FUNCS;
+   fgd->count = &ftrace_graph_notrace_count;
+   fgd->seq_ops = &ftrace_graph_seq_ops;
+
+   return __ftrace_graph_open(inode, file, fgd);
+}
+
+static int
 ftrace_graph_release(struct inode *inode, struct file *file)
 {
if (file->f_mode & FMODE_READ) {
@@ -4011,6 +4033,14 @@ static const struct file_operations ftrace_graph_fops = {
.llseek = ftrace_filter_lseek,
.release= ftrace_graph_release,
 };
+
+static const struct file_operations ftrace_graph_notrace_fops = {
+   .open   = ftrace_graph_notrace_open,
+   .read   = seq_read,
+   .write  = ftrace_graph_write,
+   .llseek = ftrace_filter_lseek,
+   .release= ftrace_graph_release,
+};
 #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
 
 static __init int ftrace_init_dyn_debugfs(struct dentry *d_tracer)
@@ -4032,6 +4062,9 @@ static __in

[for-next][PATCH 2/6] tracing: Fix potential out-of-bounds in trace_get_user()

[Steven Rostedt]

From: Steven Rostedt 

Andrey reported the following report:

ERROR: AddressSanitizer: heap-buffer-overflow on address 8800359c99f3
8800359c99f3 is located 0 bytes to the right of 243-byte region 
[8800359c9900, 8800359c99f3)
Accessed by thread T13003:
  #0 810dd2da (asan_report_error+0x32a/0x440)
  #1 810dc6b0 (asan_check_region+0x30/0x40)
  #2 810dd4d3 (__tsan_write1+0x13/0x20)
  #3 811cd19e (ftrace_regex_release+0x1be/0x260)
  #4 812a1065 (__fput+0x155/0x360)
  #5 812a12de (fput+0x1e/0x30)
  #6 8111708d (task_work_run+0x10d/0x140)
  #7 810ea043 (do_exit+0x433/0x11f0)
  #8 810eaee4 (do_group_exit+0x84/0x130)
  #9 810eafb1 (SyS_exit_group+0x21/0x30)
  #10 81928782 (system_call_fastpath+0x16/0x1b)

Allocated by thread T5167:
  #0 810dc778 (asan_slab_alloc+0x48/0xc0)
  #1 8128337c (__kmalloc+0xbc/0x500)
  #2 811d9d54 (trace_parser_get_init+0x34/0x90)
  #3 811cd7b3 (ftrace_regex_open+0x83/0x2e0)
  #4 811cda7d (ftrace_filter_open+0x2d/0x40)
  #5 8129b4ff (do_dentry_open+0x32f/0x430)
  #6 8129b668 (finish_open+0x68/0xa0)
  #7 812b66ac (do_last+0xb8c/0x1710)
  #8 812b7350 (path_openat+0x120/0xb50)
  #9 812b8884 (do_filp_open+0x54/0xb0)
  #10 8129d36c (do_sys_open+0x1ac/0x2c0)
  #11 8129d4b7 (SyS_open+0x37/0x50)
  #12 81928782 (system_call_fastpath+0x16/0x1b)

Shadow bytes around the buggy address:
  8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb
  8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap redzone:  fa
  Heap kmalloc redzone:  fb
  Freed heap region: fd
  Shadow gap:fe

The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;'

Although the crash happened in ftrace_regex_open() the real bug
occurred in trace_get_user() where there's an incrementation to
parser->idx without a check against the size. The way it is triggered
is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop
that reads the last character stores it and then breaks out because
there is no more characters. Then the last character is read to determine
what to do next, and the index is incremented without checking size.

Then the caller of trace_get_user() usually nulls out the last character
with a zero, but since the index is equal to the size, it writes a nul
character after the allocated space, which can corrupt memory.

Luckily, only root user has write access to this file.

Link: http://lkml.kernel.org/r/20131009222323.04fd1...@gandalf.local.home

Reported-by: Andrey Konovalov 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d5f7c4d..063a92b 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -843,9 +843,12 @@ int trace_get_user(struct trace_parser *parser, const char 
__user *ubuf,
if (isspace(ch)) {
parser->buffer[parser->idx] = 0;
parser->cont = false;
-   } else {
+   } else if (parser->idx < parser->size - 1) {
parser->cont = true;
parser->buffer[parser->idx++] = ch;
+   } else {
+   ret = -EINVAL;
+   goto out;
}
 
*ppos += read;
-- 
1.8.4.rc3


--
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/

[for-next][PATCH 0/6] tracing: Various updates

[Steven Rostedt]

This has been a long time coming. I'm sure there's more patches that
I missed, as my inbox got a bit large while I worked on some internal
stuff.

Anyway, I got this part out. If you sent me a patch and it's not here,
please ping me again, otherwise I'll probably miss the 3.12 window for it.
I will get to it eventually, but there's a lot of noise to sort through.

-- Steve

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next

Head SHA1: 29ad23b00474c34e3b5040dda508c78d33a1a3eb
29ad23b00474c34e3b5040dda508c78d33a1a3eb


Namhyung Kim (4):
  ftrace: Get rid of ftrace_graph_filter_enabled
  ftrace: Introduce struct ftrace_graph_data
  ftrace: Narrow down the protected area of graph_lock
  ftrace: Add set_graph_notrace filter

Steven Rostedt (1):
  tracing: Fix potential out-of-bounds in trace_get_user()

Wang YanQing (1):
  tracing: Show more exact help information about snapshot


 include/linux/ftrace.h   |   1 +
 kernel/trace/ftrace.c| 140 ++-
 kernel/trace/trace.c |   7 +-
 kernel/trace/trace.h |  25 ++-
 kernel/trace/trace_functions_graph.c |  56 +-
 5 files changed, 186 insertions(+), 43 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/

[for-next][PATCH 3/6] ftrace: Get rid of ftrace_graph_filter_enabled

[Steven Rostedt]

From: Namhyung Kim 

The ftrace_graph_filter_enabled means that user sets function filter
and it always has same meaning of ftrace_graph_count > 0.

Link: 
http://lkml.kernel.org/r/1381739066-7531-2-git-send-email-namhy...@kernel.org

Signed-off-by: Namhyung Kim 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/ftrace.c | 6 +-
 kernel/trace/trace.h  | 3 +--
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 03cf44a..a77e4a0 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3776,7 +3776,6 @@ static const struct file_operations ftrace_notrace_fops = 
{
 static DEFINE_MUTEX(graph_lock);
 
 int ftrace_graph_count;
-int ftrace_graph_filter_enabled;
 unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
 
 static void *
@@ -3799,7 +3798,7 @@ static void *g_start(struct seq_file *m, loff_t *pos)
mutex_lock(&graph_lock);
 
/* Nothing, tell g_show to print all functions are enabled */
-   if (!ftrace_graph_filter_enabled && !*pos)
+   if (!ftrace_graph_count && !*pos)
return (void *)1;
 
return __g_next(m, pos);
@@ -3845,7 +3844,6 @@ ftrace_graph_open(struct inode *inode, struct file *file)
mutex_lock(&graph_lock);
if ((file->f_mode & FMODE_WRITE) &&
(file->f_flags & O_TRUNC)) {
-   ftrace_graph_filter_enabled = 0;
ftrace_graph_count = 0;
memset(ftrace_graph_funcs, 0, sizeof(ftrace_graph_funcs));
}
@@ -3925,8 +3923,6 @@ out:
if (fail)
return -EINVAL;
 
-   ftrace_graph_filter_enabled = !!(*idx);
-
return 0;
 }
 
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 10c86fb..40211ce 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -730,7 +730,6 @@ extern void __trace_graph_return(struct trace_array *tr,
 #ifdef CONFIG_DYNAMIC_FTRACE
 /* TODO: make this variable */
 #define FTRACE_GRAPH_MAX_FUNCS 32
-extern int ftrace_graph_filter_enabled;
 extern int ftrace_graph_count;
 extern unsigned long ftrace_graph_funcs[FTRACE_GRAPH_MAX_FUNCS];
 
@@ -738,7 +737,7 @@ static inline int ftrace_graph_addr(unsigned long addr)
 {
int i;
 
-   if (!ftrace_graph_filter_enabled)
+   if (!ftrace_graph_count)
return 1;
 
for (i = 0; i < ftrace_graph_count; i++) {
-- 
1.8.4.rc3


--
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/

[for-next][PATCH 1/6] tracing: Show more exact help information about snapshot

[Steven Rostedt]

From: Wang YanQing 

The current "help" that comes out of the snapshot file when it is
not allocated looks like this:

 # * Snapshot is freed *
 #
 # Snapshot commands:
 # echo 0 > snapshot : Clears and frees snapshot buffer
 # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
 #  Takes a snapshot of the main buffer.
 # echo 2 > snapshot : Clears snapshot buffer (but does not allocate)
 #  (Doesn't have to be '2' works with any number that
 #   is not a '0' or '1')

Echo 2 says that it does not allocate the buffer, which is correct,
but to be more consistent with "echo 0" it should also state
that it does not free.

Link: http://lkml.kernel.org/r/20130914045916.GA4243@udknight

Signed-off-by: Wang YanQing 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7974ba2..d5f7c4d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2760,7 +2760,7 @@ static void show_snapshot_main_help(struct seq_file *m)
seq_printf(m, "# echo 0 > snapshot : Clears and frees snapshot 
buffer\n");
seq_printf(m, "# echo 1 > snapshot : Allocates snapshot buffer, if not 
already allocated.\n");
seq_printf(m, "#  Takes a snapshot of the main 
buffer.\n");
-   seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does 
not allocate)\n");
+   seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does 
not allocate or free)\n");
seq_printf(m, "#  (Doesn't have to be '2' works 
with any number that\n");
seq_printf(m, "#   is not a '0' or '1')\n");
 }
-- 
1.8.4.rc3


--
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: A review of dm-writeboost

[Dave Chinner]

On Sat, Oct 19, 2013 at 07:59:55PM +0900, Akira Hayakawa wrote:
> Dave,
> 
> # -EIO retuned corrupts XFS
> I turned up
> lockdep, frame pointer, xfs debug
> and also changed to 3.12.0-rc5 from rc1.
> 
> What's changed is that
> the problem we discussed in previous mails
> *never* reproduce.
> 
> However, if I turn off the lockdep only
> it hangs up by setting blockup to 1 and then to 0 after that.

Which indicates that the corruption is likely to be caused by a race
condition, and that adding lockdep slows things down enough to
change the timing and hence not hit the race condition...

e.g. the use after free that causes the memory corruption now occurs
after the critical point where XFS can get stuck on it.

> The underlying device once became dead revives
> may confuse the filesystem but
> this looks not related to locking things.
> This problem may be producible using dm-flakey.

I use dm-flakey quite a bit, and I haven't seen this

> This behavior is not reproducible with ext4.
> 
> 
> root@Lyle:/home/akira# virsh console Hercules
> Connected to domain Hercules
> Escape character is ^]
> [  143.042980] device-mapper: writeboost: info@modulator_proc() reactivated 
> after blockup
> [  143.042999] device-mapper: writeboost: info@dm_safe_io_internal() 
> reactivated after blockup
> [  143.043006] device-mapper: writeboost: info@migrate_proc() reactivated 
> after blockup
> [  143.045328] XFS: metadata I/O error: block 0x300d0f ("xlog_iodone") error 
> 5 numblks 64
> [  143.045333] XFS: xfs_do_force_shutdown(0x2) called from line 1161 of file 
> fs/xfs/xfs_log.c.  Return address = 0xa0430f9c
> [  143.045335] XFS: Log I/O Error Detected.  Shutting down filesystem
> [  143.045335] XFS: Please umount the filesystem and rectify the problem(s)
> [  143.045338] XFS: Assertion failed: atomic_read(&iclog->ic_refcnt) == 0, 
> file: fs/xfs/xfs_log.c, line: 2751
.
> [  143.045465] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
.
> [  143.045558]  [] xlog_state_done_syncing+0x6d/0xe4 [xfs]
> [  143.045590]  [] xlog_iodone+0xd0/0xd9 [xfs]
> [  143.045609]  [] xfs_buf_iodone_work+0x57/0xa2 [xfs]
> [  143.045627]  [] process_one_work+0x18b/0x297
> [  143.045631]  [] worker_thread+0x12e/0x1fb
> [  143.045634]  [] ? rescuer_thread+0x268/0x268
> [  143.045638]  [] kthread+0x88/0x90
> [  143.045641]  [] ? __kthread_parkme+0x60/0x60

So that has got through xlog_iodone() and has found that the
reference count of the iclog was not zero when it went to run the
log IO completion callbacks.

We asserted that the reference count was zero before issuing the IO,
and we only ever increment the reference count when the iclog is in
an active state. We cannot increment the reference count while the
log is under IO because the state of the iclog is "syncing", not
"active".

Once the log is shut down, the iclog state goes to
XLOG_STATE_IOERROR and never goes out of that state. The assert just
prior to the one that tripped above indicates that we are either in
an ACTIVE state or IOERROR:

ASSERT(iclog->ic_state == XLOG_STATE_SYNCING ||
   iclog->ic_state == XLOG_STATE_IOERROR);
>>  ASSERT(atomic_read(&iclog->ic_refcnt) == 0);

It was the second assert that failed, and hence it's clear that
in either state the reference count cannot be incremented until the
IO is fully completed and it transitioned back the active state.

> [  143.045333] XFS: xfs_do_force_shutdown(0x2) called from line 1161 of file 
> fs/xfs/xfs_log.c.  Return address = 0xa0430f9c

This indicates that the shutdown was called from xlog_iodone() as a
result of an IO error on the iclog buffer, and the call to
xlog_state_done_syncing() happens 5 lines of code later, which
immediately assert fails with a corrupt iclog state.

Because we shutdown with SHUTDOWN_LOG_IO_ERROR set, we call into
xfs_log_force_umount() with logerror = true. This first call ends up
setting the log flag XLOG_IO_ERROR, then calling
xlog_state_ioerror() which sets ic_state on all iclogs to
XLOG_STATE_IOERROR.

The shutdown then runs xlog_state_do_callback() which aborts the
completions on all the iclogs that have callbacks attached, and
wakes anyone waiting on log space or log forces so they can get
errors returned to them.

We now return to xlog_iodone() in a shutdown state, with all the
iclog buffers in with ic_state = XLOG_STATE_IOERROR. So, there is
absolutely no opportunity for anyone to take a new reference to the
iclog in the 10 *microseconds* between the IO error being detected,
the shutdown being processed and the call to
xlog_state_done_syncing() where the assert fails. At this point, I
cannot see how this can occur in the XFS code.

Indeed, I can trigger this error path easily under heavy load just
using the godown utility in xfstests:

[1044535.986040] XFS (vdc): Mounting Filesystem
[1044536.040630] XFS (vdc): Ending clean mount
[1044536.059299] XFS: Clearing xfsstats
# src/xfstests-dev/src/godown -v 

Re: [PATCH v2] mmc: sdhci-pci: add Intel Merrifield support

[Chris Ball]

Hi David,

On Tue, Oct 01 2013, David Cohen wrote:
> Implement initial SDHCI Intel Merrifield support.
> This patch is based on previous one from Yunpeng Gao 
>
> Signed-off-by: David Cohen 
> ---
>  drivers/mmc/host/sdhci-pci.c | 30 ++
>  1 file changed, 30 insertions(+)

Thanks, pushed to mmc-next for 3.13.

- Chris.
-- 
Chris Ball  
--
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: [PATCHv2] x86: add kconfig options for newer 64-bit processors

[Austin S Hemmelgarn]

On 10/20/2013 05:18 AM, Borislav Petkov wrote:
> On Sat, Oct 19, 2013 at 08:37:29PM -0400, Austin S Hemmelgarn wrote:
>> This patch adds options to specifically optimize for a number of newer
>> 64-bit microarchitectures; specifically, Intel's Nehalem, Westmere,
>> Ivy Bridge, and Sandy Bridge, and AMD's Family 10h, Bobcat, Jaguar,
>> Bulldozer, Piledriver, and Steamroller. This serves primarily as an
>> attempt to render this particular sub-menu up-to-date with respect to
>> the options offered by current versions of GCC.
> 
> I'm sorry but did I miss anything from the last time where we determined
> that those don't bring any sensible speedup and don't mean whit on
> distros?
> 
> Thanks.
> 

I am not trying to say that this provides any improvement in speed (or
at least the AMD options, the one for Intel Ivy Bridge processors does
appear to do better in this respect).  As I stated in the comments just
before the patch itself, "...testing of MPILEDRIVER seems to indicate an
improvement to energy efficiency over GENERIC_CPU as it causes the on
cpu power sensor to consistently read an average of 1.5 watts lower
under idle load than when using GENERIC_CPU (this corresponds to about
5% decrease in power consumption on a idle-tickless system, and about 2%
on a non-dynticks system.).".  While this result is dependent on a large
number of factors (not the least of which being that I have my CPU
over-clocked to the point that the lowest C-state runs at 1.4GHz, which
really hurts energy efficiency) it is still a positive result, and most
of the equivalent options primarily improve energy efficiency.

Also, you have to understand that my target audience isn't the
mainstream distros, it's HPC users, data-centers, scientific computing,
and other areas where a 0.01% increase in efficiency is significant
because if you need a million servers to do a job, a 0.01% boost in
efficiency means that you need ten-thousand fewer systems to do the same
amount of work.
--
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/

[no subject]

[Piyus Kedia]

unsubscribe kvm
--
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/

[no subject]

[Piyus Kedia]

unsubscribe linux-kernel
--
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: Classifying user and kernel pages

[Piyus Kedia]

The user pages are generally allocated using GFP_USER or GFP_HIGHMEM
flags. The linux kernel treats GFP_USER and GFP_KERNEL as same. So,
there is no way you can tell whether a physical page belongs to user
process or not using physical frame number.

Piyus

On Fri, Oct 4, 2013 at 12:19 AM, Piyus Kedia  wrote:
> Hi All,
>
> Does anybody know if there is a way in Linux Kernel to find whether a
> physical page is a user page or it is kernel page. A kernel page is
> only accessed by kernel and it doesn't belong to any user process.
>
> Thanks,
> Piyus
--
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] [SCSI] sg: late O_EXCL fix for lk 3.12-rc

[Douglas Gilbert]

On 13-10-20 01:31 PM, Bart Van Assche wrote:

On 10/20/13 18:09, Douglas Gilbert wrote:

Given that lk 3.12.0 release is not far away, the safest path
may still be to revert Vaughan Cao's patch. I'll leave that
decision to the maintainers.


Hello Doug,

Thanks for looking into this. But I would appreciate it if you could address the
whitespace errors reported by checkpatch:

ERROR: space prohibited after that '!' (ctx:BxW)
#24: FILE: drivers/scsi/sg.c:241:
+(excl_case ? (! sdp->exclude) : sfds_list_empty(sdp;
^

ERROR: space prohibited after that '!' (ctx:BxW)
#55: FILE: drivers/scsi/sg.c:289:
+if (! alone) {
  ^

ERROR: code indent should use tabs where possible
#59: FILE: drivers/scsi/sg.c:292:
+}$

WARNING: please, no spaces at the start of a line
#59: FILE: drivers/scsi/sg.c:292:
+}$

ERROR: space prohibited after that '!' (ctx:BxW)
#73: FILE: drivers/scsi/sg.c:301:
+while (! alone) {
 ^

WARNING: suspect code indent for conditional statements (8, 12)
#144: FILE: drivers/scsi/sg.c:375:
+if (excl || sfds_list_empty(sdp))
+wake_up_interruptible(&sdp->open_wait);



I'd prefer people to test the patch or find logical flaws.

Doug Gilbert

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Improve firmware loading times on AMD and Intel

[Andi Kleen]

Prarit Bhargava  writes:
>
> Using request_firmware_nowait() seems more appropriate here and then we
> can avoid these delays, resulting in very quick load times for the
> microcode.

It would  be probably also good to remember if the loading failed for a 
given CPU and then don't try it on any other.

Just need to cache the exact stepping too to handle different steppings.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH next] md: bcache: Add missing newlines to logging messages, & misc neatening

[Joe Perches]

Logging messages require terminating newlines to avoid possible
interleaving by other messages.  Add them.

Convert bch_cache_set_error printk/vprintk/printk sequence
to use vsprintf extension %pV to eliminate any possible
interleaving.

Convert some variadic macro uses of ... to fmt, ... to
make clear the message use of the macro.

Signed-off-by: Joe Perches 
---
 drivers/md/bcache/bcache.h   | 20 ++---
 drivers/md/bcache/bset.c |  5 ++--
 drivers/md/bcache/btree.c|  8 ++---
 drivers/md/bcache/io.c   |  2 +-
 drivers/md/bcache/journal.c  | 14 -
 drivers/md/bcache/movinggc.c |  2 +-
 drivers/md/bcache/request.c  |  4 +--
 drivers/md/bcache/super.c| 71 +++-
 drivers/md/bcache/sysfs.c|  2 +-
 9 files changed, 66 insertions(+), 62 deletions(-)

diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index 4beb55a..c10cfaa 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -801,34 +801,34 @@ static inline void bkey_init(struct bkey *k)
 
 /* Error handling macros */
 
-#define btree_bug(b, ...)  \
+#define btree_bug(b, fmt, ...) \
 do {   \
-   if (bch_cache_set_error((b)->c, __VA_ARGS__))   \
+   if (bch_cache_set_error((b)->c, fmt, ##__VA_ARGS__))\
dump_stack();   \
 } while (0)
 
-#define cache_bug(c, ...)  \
+#define cache_bug(c, fmt, ...) \
 do {   \
-   if (bch_cache_set_error(c, __VA_ARGS__))\
+   if (bch_cache_set_error(c, fmt, ##__VA_ARGS__)) \
dump_stack();   \
 } while (0)
 
-#define btree_bug_on(cond, b, ...) \
+#define btree_bug_on(cond, b, fmt, ...)
\
 do {   \
if (cond)   \
-   btree_bug(b, __VA_ARGS__);  \
+   btree_bug(b, fmt, ##__VA_ARGS__);   \
 } while (0)
 
-#define cache_bug_on(cond, c, ...) \
+#define cache_bug_on(cond, c, fmt, ...)
\
 do {   \
if (cond)   \
-   cache_bug(c, __VA_ARGS__);  \
+   cache_bug(c, fmt, ##__VA_ARGS__);   \
 } while (0)
 
-#define cache_set_err_on(cond, c, ...) \
+#define cache_set_err_on(cond, c, fmt, ...)\
 do {   \
if (cond)   \
-   bch_cache_set_error(c, __VA_ARGS__);\
+   bch_cache_set_error(c, fmt, ##__VA_ARGS__); \
 } while (0)
 
 /* Looping macros */
diff --git a/drivers/md/bcache/bset.c b/drivers/md/bcache/bset.c
index 7d388b8..7c6a681 100644
--- a/drivers/md/bcache/bset.c
+++ b/drivers/md/bcache/bset.c
@@ -401,8 +401,9 @@ void inorder_test(void)
unsigned i = 1, j = rounddown_pow_of_two(size - 1);
 
if (!(size % 4096))
-   printk(KERN_NOTICE "loop %u, %llu per us\n", size,
-  done / ktime_us_delta(ktime_get(), start));
+   pr_notice("loop %u, %llu per us\n",
+ size,
+ done / ktime_us_delta(ktime_get(), start));
 
while (1) {
if (__inorder_to_tree(i, size, extra) != j)
diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 1ccb702..ca132e5 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -1612,7 +1612,7 @@ static void bch_btree_gc(struct cache_set *c)
closure_sync(&writes);
 
if (ret && ret != -EAGAIN)
-   pr_warn("gc failed!");
+   pr_warn("gc failed!\n");
} while (ret);
 
available = bch_btree_gc_finish(c);
@@ -2134,7 +2134,7 @@ err:
n1 == ERR_PTR(-EAGAIN))
return -EAGAIN;
 
-   pr_warn("couldn't split");
+   pr_warn("couldn't split\n");
return -ENOMEM;
 }
 
@@ -2251,7 +2251,7 @@ int bch_btree_insert(struct cache_set *c, struct keylist 
*keys,
if (ret) {
struct bkey *k;
 
-   pr_err

Re: [PATCH] ARM: s3c64xx: mini6410: Correct card detect type for HSMMC1

[Tomasz Figa]

Hi Kukjin,

On Monday 21 of October 2013 07:01:00 Kukjin Kim wrote:
> On 10/18/13 08:38, Kukjin Kim wrote:
> > Tomasz Figa wrote:
> >> Hi Kukjin,
> > 
> > Hi,
> > 
> >> On Sunday 29 of September 2013 18:12:01 Tomasz Figa wrote:
> >>> According to board schematics, for HSMMC1 a GPIO line is used to
> >>> detect
> >>> card presence, while currently it is being configured for internal
> >>> card
> >>> detect line, which is multiplexed with card detect line of HSMMC0 and
> >>> thus breaking it.
> >>> 
> >>> This patch adds proper sdhci platform data setting card detect type
> >>> to
> >>> external GPIO and fixing operation of HSMMC0.
> >>> 
> >>> Signed-off-by: Tomasz Figa
> >>> ---
> >>> 
> >>>   arch/arm/mach-s3c64xx/mach-mini6410.c | 10 ++
> >>>   1 file changed, 10 insertions(+)
> >> 
> >> Would you mind taking this patch to your tree?
> > 
> > Applied, thanks.
> > Kukjin
> 
> Uhm...just small concern...it's possible to support dt for mini6410 but
> basic. I need to hold this on...

May I ask you to explain your concern about this?

I believe this bug fix is fine, since we still support board files for 
s3c64xx and DT based support is experimental at the moment.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/4] perf-top: add --max-stack option to limit callchain stack scan

[Davidlohr Bueso]

On Fri, 2013-10-18 at 10:38 -0400, Waiman Long wrote:
> When the callgraph function is enabled (-G), it may take a long time to
> scan all the stack data and merge them accordingly.
> 
> This patch adds a new --max-stack option to perf-top to limit the depth
> of callchain stack data to look at to reduce the time it takes for
> perf-top to finish its processing. It reduces the amount of information
> provided to the user in exchange for faster speed.
> 
> Signed-off-by: Waiman Long 

Tested-by: Davidlohr Bueso 

> ---
>  tools/perf/Documentation/perf-top.txt |8 
>  tools/perf/builtin-top.c  |8 ++--
>  tools/perf/util/top.h |1 +
>  3 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/Documentation/perf-top.txt 
> b/tools/perf/Documentation/perf-top.txt
> index 58d6598..3fd911c 100644
> --- a/tools/perf/Documentation/perf-top.txt
> +++ b/tools/perf/Documentation/perf-top.txt
> @@ -155,6 +155,14 @@ Default is to monitor all CPUS.
>  
>   Default: fractal,0.5,callee.
>  
> +--max-stack::
> + Set the stack depth limit when parsing the callchain, anything
> + beyond the specified depth will be ignored. This is a trade-off
> + between information loss and faster processing especially for
> + workloads that can have a very long callchain stack.
> +
> + Default: 127
> +
>  --ignore-callees=::
>  Ignore callees of the function(s) matching the given regex.
>  This has the effect of collecting the callers of each such
> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> index 2725aca..14902b0 100644
> --- a/tools/perf/builtin-top.c
> +++ b/tools/perf/builtin-top.c
> @@ -772,7 +772,7 @@ static void perf_event__process_sample(struct perf_tool 
> *tool,
>   err = machine__resolve_callchain(machine, evsel,
>al.thread, sample,
>&parent, &al,
> -  PERF_MAX_STACK_DEPTH);
> +  top->max_stack);
>   if (err)
>   return;
>   }
> @@ -1052,10 +1052,11 @@ int cmd_top(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>   .user_freq  = UINT_MAX,
>   .user_interval  = ULLONG_MAX,
>   .freq   = 4000, /* 4 KHz */
> - .target  = {
> + .target = {
>   .uses_mmap   = true,
>   },
>   },
> + .max_stack   = PERF_MAX_STACK_DEPTH,
>   .sym_pcnt_filter = 5,
>   };
>   struct perf_record_opts *opts = &top.record_opts;
> @@ -1110,6 +,9 @@ int cmd_top(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>   OPT_CALLBACK_DEFAULT('G', "call-graph", &top.record_opts,
>"mode[,dump_size]", record_callchain_help,
>&parse_callchain_opt, "fp"),
> + OPT_INTEGER(0, "max-stack", &top.max_stack,
> + "Set the maximum stack depth when parsing the callchain. "
> + "Default: " __stringify(PERF_MAX_STACK_DEPTH)),
>   OPT_CALLBACK(0, "ignore-callees", NULL, "regex",
>  "ignore callees of these functions in call graphs",
>  report_parse_ignore_callees_opt),
> diff --git a/tools/perf/util/top.h b/tools/perf/util/top.h
> index b554ffc..88cfeaf 100644
> --- a/tools/perf/util/top.h
> +++ b/tools/perf/util/top.h
> @@ -24,6 +24,7 @@ struct perf_top {
>   u64exact_samples;
>   u64guest_us_samples, guest_kernel_samples;
>   intprint_entries, count_filter, delay_secs;
> + intmax_stack;
>   bool   hide_kernel_symbols, hide_user_symbols, zero;
>   bool   use_tui, use_stdio;
>   bool   kptr_restrict_warned;


--
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: When USB PHY framework should be used?

[Arokux X]

Dear all,

may I please draw your attention to this thread?

Thank you,
Arokux
--
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 0/3] New descriptor-based GPIO interface

[Alexandre Courbot]

On Sat, Oct 19, 2013 at 2:26 PM, Linus Walleij  wrote:
> On Fri, Oct 18, 2013 at 7:37 PM, Alexandre Courbot  wrote:
>> On Fri, Oct 18, 2013 at 4:23 AM, Linus Walleij  
>> wrote:
>
>>> We might have to take this as the first thing after the merge
>>> window and targeted for v3.14.
>>
>> No particular pressure from my side to get this in 3.13. Do for the
>> best, and don't hesitate to delay them to 3.14 if you feel they are
>> not tested enough. I'll already feel better once I know they are under
>> your tree. ;)
>
> I applied it now anyway, I will try to also apply the ACPI stuff
> making use of this interface and then throw it at the autobuild
> to see what happens.

Autobuild was unfortunately not too happy with one of the patches,
sorry about that. I have sent a small series that addresses the issues
it highlighted. Not sure if you are ok with squashing the first two
into bae48da2, but IMHO that would be the preferred way.

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/

[PATCH 2/3] gpiolib: devres: add missing headers

[Alexandre Courbot]

Add missing headers for drivers/gpiolib/devres.c.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/devres.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index fceebdc..307464f 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -15,7 +15,9 @@
  */
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
-- 
1.8.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/

[PATCH 0/3] Fixup patches for gpiod interface

[Alexandre Courbot]

These patches fix a few issues of the gpiod series highlighted by the
autobuild system. They take root in the fact that devres.c was compiled
even when gpiolib is not to be built, which should obviously not happen.
But they also reveal missing includes in the same file, and sparse also
pointed out a suspiscious line that happened to be completely wrong.

Patch 1/3 and 2/3 can be applied on their own, but would probably better
be squashed into bae48da2 "add gpiod_get() and gpiod_put() functions".

Patch 3/3 stands on its own, and should preferably be applied before the
rest of the gpiod series. It would not hurt to apply it after if 1/3 and
2/3 are properly squashed.

Apologies for these issues that could have been caught earlier had I been
less negligent.

Alexandre Courbot (3):
  gpiolib: devres: fix devm_gpiod_get_index()
  gpiolib: devres: add missing headers
  gpiolib: make GPIO_DEVRES depend on GPIOLIB

 drivers/gpio/Kconfig  | 8 
 drivers/gpio/devres.c | 4 +++-
 2 files changed, 7 insertions(+), 5 deletions(-)

-- 
1.8.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/

[PATCH 1/3] gpiolib: devres: fix devm_gpiod_get_index()

[Alexandre Courbot]

Fix the return value if devm_gpiod_get_index(). It was returning 0 while
it should return the obtained GPIO descriptor.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/devres.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 2caa257..fceebdc 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -80,7 +80,7 @@ struct gpio_desc *__must_check devm_gpiod_get_index(struct 
device *dev,
*dr = desc;
devres_add(dev, dr);
 
-   return 0;
+   return desc;
 }
 EXPORT_SYMBOL(devm_gpiod_get_index);
 
-- 
1.8.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/

[PATCH 3/3] gpiolib: make GPIO_DEVRES depend on GPIOLIB

[Alexandre Courbot]

Current Kconfig allows GPIO_DEVRES to be selected and compiled without
GPIOLIB. This does not make sense anymore since GPIOLIB has become the
exclusive way to deal with GPIOs. This patch makes GPIO_DEVRES available
only if GPIOLIB is selected.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpio/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 92e258c..62eb9ef 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -30,10 +30,6 @@ config ARCH_REQUIRE_GPIOLIB
  Selecting this from the architecture code will cause the gpiolib
  code to always get built in.
 
-config GPIO_DEVRES
-   def_bool y
-   depends on HAS_IOMEM
-
 
 menuconfig GPIOLIB
bool "GPIO Support"
@@ -47,6 +43,10 @@ menuconfig GPIOLIB
 
 if GPIOLIB
 
+config GPIO_DEVRES
+   def_bool y
+   depends on HAS_IOMEM
+
 config OF_GPIO
def_bool y
depends on OF
-- 
1.8.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] ARM: s3c64xx: mini6410: Correct card detect type for HSMMC1

[Kukjin Kim]

On 10/18/13 08:38, Kukjin Kim wrote:

Tomasz Figa wrote:


Hi Kukjin,


Hi,


On Sunday 29 of September 2013 18:12:01 Tomasz Figa wrote:

According to board schematics, for HSMMC1 a GPIO line is used to detect
card presence, while currently it is being configured for internal card
detect line, which is multiplexed with card detect line of HSMMC0 and
thus breaking it.

This patch adds proper sdhci platform data setting card detect type to
external GPIO and fixing operation of HSMMC0.

Signed-off-by: Tomasz Figa
---
  arch/arm/mach-s3c64xx/mach-mini6410.c | 10 ++
  1 file changed, 10 insertions(+)


Would you mind taking this patch to your tree?


Applied, thanks.
Kukjin

Uhm...just small concern...it's possible to support dt for mini6410 but 
basic. I need to hold this on...



Best regards,
Tomasz


diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c
b/arch/arm/mach-s3c64xx/mach-mini6410.c index 58d46a3..97ae470 100644
--- a/arch/arm/mach-s3c64xx/mach-mini6410.c
+++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
@@ -36,7 +36,9 @@
  #include
  #include
  #include
+#include
  #include
+#include
  #include

  #include
@@ -214,6 +216,13 @@ static struct platform_device mini6410_lcd_powerdev
= { .dev.platform_data  =&mini6410_lcd_power_data,
  };

+static struct s3c_sdhci_platdata mini6410_hsmmc1_pdata = {
+   .max_width  = 4,
+   .cd_type= S3C_SDHCI_CD_GPIO,
+   .ext_cd_gpio= S3C64XX_GPN(10),
+   .ext_cd_gpio_invert = true,
+};
+
  static struct platform_device *mini6410_devices[] __initdata = {
&mini6410_device_eth,
&s3c_device_hsmmc0,
@@ -321,6 +330,7 @@ static void __init mini6410_machine_init(void)

s3c_nand_set_platdata(&mini6410_nand_info);
s3c_fb_set_platdata(&mini6410_lcd_pdata[features.lcd_index]);
+   s3c_sdhci1_set_platdata(&mini6410_hsmmc1_pdata);
s3c24xx_ts_set_platdata(NULL);

/* configure nCS1 width to 16 bits */

--
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/2] firmware, fix request_firmware_nowait() freeze with no uevent

[Prarit Bhargava]

If request_firmware_nowait() is called with uevent == NULL, the firmware
completion is never marked complete resulting in a hang in the process.

If uevent is undefined, that means we're not waiting on anything and the
process should just clean up and complete.  While we're at it, add a
debug dev_dbg() to indicate that the FW has not been found.

Signed-off-by: Prarit Bhargava 
Cc: x...@kernel.org
Cc: herrmann.der.u...@googlemail.com
Cc: ming@canonical.com
Cc: tig...@aivazian.fsnet.co.uk
---
 drivers/base/firmware_class.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 10a4467..95778dc 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -335,7 +335,8 @@ static bool fw_get_filesystem_firmware(struct device 
*device,
set_bit(FW_STATUS_DONE, &buf->status);
complete_all(&buf->completion);
mutex_unlock(&fw_lock);
-   }
+   } else
+   dev_dbg(device, "firmware: %s not found\n", buf->fw_id);
 
return success;
 }
@@ -886,6 +887,9 @@ static int _request_firmware_load(struct firmware_priv 
*fw_priv, bool uevent,
schedule_delayed_work(&fw_priv->timeout_work, timeout);
 
kobject_uevent(&fw_priv->dev.kobj, KOBJ_ADD);
+   } else {
+   /* if there is no uevent then just cleanup */
+   schedule_delayed_work(&fw_priv->timeout_work, 0);
}
 
wait_for_completion(&buf->completion);
-- 
1.7.9.3

--
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 0/2] Improve firmware loading times on AMD and Intel

[Prarit Bhargava]

If no firmware is found on the system that matches the processor, the
microcode module can take hours to load.  For example on recent kernels
when loading the microcode module on an Intel system:

[  239.532116] microcode: CPU0 sig=0x306e4, pf=0x1, revision=0x413
[  299.693447] microcode: CPU1 sig=0x306e4, pf=0x1, revision=0x413
[  359.821972] microcode: CPU2 sig=0x306e4, pf=0x1, revision=0x413
[  419.960263] microcode: CPU3 sig=0x306e4, pf=0x1, revision=0x413
[  480.090024] microcode: CPU4 sig=0x306e4, pf=0x1, revision=0x413
...
[ 2825.151364] microcode: CPU43 sig=0x306e4, pf=0x1, revision=0x413
[ 2885.280863] microcode: CPU44 sig=0x306e4, pf=0x1, revision=0x413
[ 2945.410719] microcode: CPU45 sig=0x306e4, pf=0x1, revision=0x413
[ 3005.540541] microcode: CPU46 sig=0x306e4, pf=0x1, revision=0x413
[ 3065.670405] microcode: CPU47 sig=0x306e4, pf=0x1, revision=0x413
...
etc.

Since this takes 1 minute per cpu, the microcode module requires two hours to
load on a 120 cpu Intel box.

Similarly there is a 60 second "hang" when loading the AMD module, which
isn't as bad as the Intel situation, but it is a noticeable delay in the
system boot.

Using request_firmware_nowait() seems more appropriate here and then we
can avoid these delays, resulting in very quick load times for the
microcode.

Signed-off-by: Prarit Bhargava 
Cc: x...@kernel.org
Cc: herrmann.der.u...@googlemail.com
Cc: ming@canonical.com
Cc: tig...@aivazian.fsnet.co.uk

Prarit Bhargava (2):
  firmware, fix request_firmware_nowait() freeze with no uevent
  intel_microcode, Fix long microcode load time when firmware file is
missing

 arch/x86/include/asm/microcode.h  |7 
 arch/x86/kernel/microcode_amd.c   |   79 +++--
 arch/x86/kernel/microcode_core.c  |7 
 arch/x86/kernel/microcode_intel.c |   67 +--
 drivers/base/firmware_class.c |6 ++-
 5 files changed, 132 insertions(+), 34 deletions(-)

-- 
1.7.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] intel_microcode, Fix long microcode load time when firmware file is missing

[Prarit Bhargava]

If no firmware is found on the system that matches the processor, the
microcode module can take hours to load.  For example on recent kernels
when loading the microcode module on an Intel system:

[  239.532116] microcode: CPU0 sig=0x306e4, pf=0x1, revision=0x413
[  299.693447] microcode: CPU1 sig=0x306e4, pf=0x1, revision=0x413
[  359.821972] microcode: CPU2 sig=0x306e4, pf=0x1, revision=0x413
[  419.960263] microcode: CPU3 sig=0x306e4, pf=0x1, revision=0x413
[  480.090024] microcode: CPU4 sig=0x306e4, pf=0x1, revision=0x413
...
[ 2825.151364] microcode: CPU43 sig=0x306e4, pf=0x1, revision=0x413
[ 2885.280863] microcode: CPU44 sig=0x306e4, pf=0x1, revision=0x413
[ 2945.410719] microcode: CPU45 sig=0x306e4, pf=0x1, revision=0x413
[ 3005.540541] microcode: CPU46 sig=0x306e4, pf=0x1, revision=0x413
[ 3065.670405] microcode: CPU47 sig=0x306e4, pf=0x1, revision=0x413
...
etc.

Similarly there is a 60 second "hang" when loading the AMD module, which
isn't as bad as the Intel situation, but it is a noticeable delay in the
system boot and can be improved upon.

Using request_firmware_nowait() seems more appropriate here and then we
can avoid these delays, resulting in very quick load times for the
microcode.

Signed-off-by: Prarit Bhargava 
Cc: x...@kernel.org
Cc: herrmann.der.u...@googlemail.com
Cc: ming@canonical.com
Cc: tig...@aivazian.fsnet.co.uk
---
 arch/x86/include/asm/microcode.h  |7 
 arch/x86/kernel/microcode_amd.c   |   79 +++--
 arch/x86/kernel/microcode_core.c  |7 
 arch/x86/kernel/microcode_intel.c |   67 +--
 4 files changed, 127 insertions(+), 33 deletions(-)

diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index f98bd66..461a66f 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -11,6 +11,12 @@ struct device;
 
 enum ucode_state { UCODE_ERROR, UCODE_OK, UCODE_NFOUND };
 
+/* data struct for request_firmware_nowait callback */
+struct microcode_request_data {
+   unsigned long cpu;
+   char name[36];
+};
+
 struct microcode_ops {
enum ucode_state (*request_microcode_user) (int cpu,
const void __user *buf, size_t size);
@@ -34,6 +40,7 @@ struct ucode_cpu_info {
struct cpu_signaturecpu_sig;
int valid;
void*mc;
+   struct completion   completion;
 };
 extern struct ucode_cpu_info ucode_cpu_info[];
 
diff --git a/arch/x86/kernel/microcode_amd.c b/arch/x86/kernel/microcode_amd.c
index af99f71..17a2a09 100644
--- a/arch/x86/kernel/microcode_amd.c
+++ b/arch/x86/kernel/microcode_amd.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -399,6 +400,40 @@ enum ucode_state load_microcode_amd(u8 family, const u8 
*data, size_t size)
return ret;
 }
 
+static void amd_apply_firmware(const struct firmware *fw, void *context)
+{
+   struct microcode_request_data *mrd =
+  (struct microcode_request_data *)context;
+   int cpu = mrd->cpu;
+   int ret = UCODE_ERROR;
+   struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
+   struct cpuinfo_x86 *c = &cpu_data(cpu);
+
+   if (!fw) {
+   pr_warn("firmware %s not found\n", mrd->name);
+   goto out;
+   }
+
+   if (!fw->data || !fw->size) {
+   pr_warn("firmware %s invalid\n", mrd->name);
+   goto out;
+   }
+
+   if (*(u32 *)fw->data != UCODE_MAGIC) {
+   pr_err("invalid magic value (0x%08x)\n", *(u32 *)fw->data);
+   goto out;
+   }
+
+   ret = load_microcode_amd(c->x86, fw->data, fw->size);
+   if (ret == UCODE_OK)
+   pr_info("firmware %s is ready for cpu %d\n", mrd->name, cpu);
+out:
+   complete_all(&uci->completion);
+   if (fw)
+   release_firmware(fw);
+   vfree(mrd);
+}
+
 /*
  * AMD microcode firmware naming convention, up to family 15h they are in
  * the legacy file:
@@ -418,36 +453,38 @@ enum ucode_state load_microcode_amd(u8 family, const u8 
*data, size_t size)
 static enum ucode_state request_microcode_amd(int cpu, struct device *device,
  bool refresh_fw)
 {
-   char fw_name[36] = "amd-ucode/microcode_amd.bin";
struct cpuinfo_x86 *c = &cpu_data(cpu);
-   enum ucode_state ret = UCODE_NFOUND;
-   const struct firmware *fw;
+   struct device *cpu_device;
+   struct microcode_request_data *mrd;
 
-   /* reload ucode container only on the boot cpu */
-   if (!refresh_fw || c->cpu_index != boot_cpu_data.cpu_index)
+   if (!refresh_fw)
return UCODE_OK;
 
-   if (c->x86 >= 0x15)
-   snprintf(fw_name, sizeof(fw_name), 
"amd-ucode/microcode_amd_fam%.2xh.bin", c->x86);
+   mrd = vmalloc(sizeof(mrd));
+   if (!mrd)
+   return 

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

[Stephen Warren]

On 10/20/2013 01:41 PM, Laurent Pinchart wrote:
> Hi Grant,
> 
> On Tuesday 17 September 2013 17:36:32 Grant Likely wrote:
>> On Thu, 12 Sep 2013 17:57:00 +0200, Alexander Holler wrote:
>>> Am 12.09.2013 17:19, schrieb Stephen Warren:
 IRQs, DMA channels, and GPIOs are all different things. Their bindings
 are defined independently. While it's good to define new types of
 bindings consistently with other bindings, this hasn't always happened,
 so you can make zero assumptions about the IRQ bindings by reading the
 documentation for any other kind of binding.

 Multiple interrupts are defined as follows:
// Optional; otherwise inherited from parent/grand-parent/...
interrupt-parent = <&gpio6>;
// Must be in a fixed order, unless binding defines that the
// optional interrupt-names property is to be used.
interrupts = <1 IRQF_TRIGGER_HIGH> <2 IRQF_TRIGGER_LOW>;
// Optional; binding for device defines whether it must
// be present
interrupt-names = "foo", "bar";

 If you need multiple interrupts, each with a different parent, you need
 to use an interrupt-map property...
...
>> Actually, I think it is solveable but doing so requires a new binding
>> for interrupts. I took a shot at implementing it earlier this week and
>> I've got working patches that I'll be posting soon. I created a new
>> "interrupts-extended" property that uses a phandle+args type of
>> binding like this:
...
>> device@3000 {
>>  interrupts-extended = <&intc1 5> <&intc2 3 4> <&intc1 6>;
>> };
...
> Any progress on this ? I'll need to use multiple interrupts with different 
> parents in the near future, I can take this over if needed.
> 
> I've also been thinking that we could possibly reuse the "interrupts" 
> property 
> without defining a new "interrupts-extended". When parsing the property the 
> code would use the current DT bindings if an interrupt-parent is present, and 
> the new DT bindings if it isn't.

interrupt-parents doesn't have to be present in individual nodes; it can
be inherited from the parent. That means you'd have to convert whole
sub-trees at once. It seems much more flexible to use a new property and
hence make it explicit what format the data is in.
--
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: Build regressions/improvements in v3.12-rc6

[Geert Uytterhoeven]

On Sun, Oct 20, 2013 at 11:30 PM, Geert Uytterhoeven
 wrote:
> JFYI, when comparing v3.12-rc6 to v3.12-rc5[3], the summaries are:
>   - build errors: +9/-13

  + /scratch/kisskb/src/drivers/i2c/busses/i2c-pca-platform.c: error:
implicit declaration of function 'ioread8'
[-Werror=implicit-function-declaration]cc1: some warnings being
treated as errors:  => 46:2

cris-allmodconfig/cris-allyesconfig

  + error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]:  => N/A

x86_64-randconfig

  + error: No rule to make target include/config/auto.conf:  => N/A

powerpc-randconfig

> [1] http://kisskb.ellerman.id.au/kisskb/head/6796/ (all 120 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6776/ (all 120 configs)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 01/15] ARM: tegra30: add missing CLK IDs

[Stephen Warren]

On 10/18/2013 02:25 PM, Peter De Schrijver wrote:
> The Tegra30 clock bindings lack few IDs for audio and clk_out muxes.

Is there a list of changes for V5?

Don't forget that I gave tested-by/acked-by for V4(?), unless you've
changed so much you consider that to no longer apply?
--
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] x86: Run checksumming in parallel accross multiple alu's

[Neil Horman]

On Fri, Oct 18, 2013 at 02:15:52PM -0700, Eric Dumazet wrote:
> On Fri, 2013-10-18 at 16:11 -0400, Neil Horman wrote:
> 
> > #define BUFSIZ_ORDER 4
> > #define BUFSIZ ((2 << BUFSIZ_ORDER) * (1024*1024*2))
> > static int __init csum_init_module(void)
> > {
> > int i;
> > __wsum sum = 0;
> > struct timespec start, end;
> > u64 time;
> > struct page *page;
> > u32 offset = 0;
> > 
> > page = alloc_pages((GFP_TRANSHUGE & ~__GFP_MOVABLE), BUFSIZ_ORDER);
> 
> Not sure what you are doing here, but its not correct.
> 
Why not?  You asked for a test with 32 hugepages, so I allocated 32 hugepages.

> You have a lot of variations in your results, I suspect a NUMA affinity
> problem.
> 
I do have some variation, you're correct, but I don't think its a numa issue

> You can try the following code, and use taskset to make sure you run
> this on a cpu on node 0
> 
I did run this with taskset to do exactly that (hence my comment above).  I'll
be glad to run your variant on monday morning though and provide results.


Best
Neil


> #define BUFSIZ 2*1024*1024
> #define NBPAGES 16
> 
> static int __init csum_init_module(void)
> {
> int i;
> __wsum sum = 0;
> u64 start, end;
>   void *base, *addrs[NBPAGES];
> u32 rnd, offset;
> 
>   memset(addrs, 0, sizeof(addrs));
>   for (i = 0; i < NBPAGES; i++) {
>   addrs[i] = kmalloc_node(BUFSIZ, GFP_KERNEL, 0);
>   if (!addrs[i])
>   goto out;
>   }
> 
> local_bh_disable();
> pr_err("STARTING ITERATIONS on cpu %d\n", smp_processor_id());
> start = ktime_to_ns(ktime_get());
> 
> for (i = 0; i < 10; i++) {
>   rnd = prandom_u32();
>   base = addrs[rnd % NBPAGES];
>   rnd /= NBPAGES;
>   offset = rnd % (BUFSIZ - 1500);
> offset &= ~1U;
> sum = csum_partial_opt(base + offset, 1500, sum);
> }
> end = ktime_to_ns(ktime_get());
> local_bh_enable();
> 
> pr_err("COMPLETED 10 iterations of csum %x in %llu nanosec\n", 
> sum, end - start);
> 
> out:
>   for (i = 0; i < NBPAGES; i++)
>   kfree(addrs[i]);
> 
> return 0;
> }
> 
> static void __exit csum_cleanup_module(void)
> {
> return;
> }
> 
> 
> 
> 
--
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: Allow ftracing perf code

[Andi Kleen]

From: Andi Kleen 

According to Stephen there is no reason left not to allow
function trace in perf code.  Don't disable the function
tracer instrumentation for the perf files. Changes the
generic and the x86 files.

I've been using variants of this patch for a long time and
haven't seen any problems.  It's really useful to figure
out why a complex perf_event_open() syscall fails.

Cc: rost...@goodmis.org
Cc: pet...@infradead.org
Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/Makefile | 1 -
 kernel/events/Makefile   | 4 
 2 files changed, 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 47b56a7..190bf4a 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -5,7 +5,6 @@
 # Don't trace early stages of a secondary CPU boot
 ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_common.o = -pg
-CFLAGS_REMOVE_perf_event.o = -pg
 endif
 
 # Make sure load_percpu_segment has no stackprotector
diff --git a/kernel/events/Makefile b/kernel/events/Makefile
index 103f5d1..a630994 100644
--- a/kernel/events/Makefile
+++ b/kernel/events/Makefile
@@ -1,7 +1,3 @@
-ifdef CONFIG_FUNCTION_TRACER
-CFLAGS_REMOVE_core.o = -pg
-endif
-
 obj-y := core.o ring_buffer.o callchain.o
 
 obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
-- 
1.8.3.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 v2] irqchip: exynos-combiner: remove hard-coded irq_base value

[Kukjin Kim]

On 10/18/13 02:53, Tomasz Figa wrote:

Hi Kukjin,

On Thursday 26 of September 2013 14:05:09 Kukjin Kim wrote:

Chander Kashyap wrote:

Replace irq_domain_add_simple with "irq_domain_add_linear" in order to
use linear irq domain, and to remove hardcoded irq_base_value.

Signed-off-by: Chander Kashyap
---

Changes since v1:
- Replaced irq_domain_add_simple with irq_domain_add_linear,

  as suggested by Tomasz

  drivers/irqchip/exynos-combiner.c |   15 +++
  1 file changed, 3 insertions(+), 12 deletions(-)

[snip]


Looks nice to me, applied with Tomasz's review.


I don't see this patch in your tree. Did you apply it in the end?


Thanks for your gentle reminder.

Applied.
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 0/3] ARM: S5PV210: move to common clk framework

[Kukjin Kim]

On 10/20/13 01:03, Tomasz Figa wrote:

Hi Mike, Kukjin, Rafael,

On Tuesday 24 of September 2013 14:50:06 Mateusz Krawczuk wrote:

This patch series is the new s5pv210 clock implementation
(using common clk framework).

This implementation is compatible with device tree definition and board
files.

This patch series is based on linux-next and has been tested on goni and
aquila
boards using board file.

Since v4:
Corrected mux flags for finpll.

Since v3:

Replace s5pv210_clk_register_finpll, by creating mux finpll
with xusbxti and xxti as parrents.


Mateusz Krawczuk (3):
   clk: samsung: Add clock driver for s5pc110/s5pv210
   Cpufreq: s5pv210 cpufreq fixes for CCF
   ARM: s5pv210: Migrate clock handling to Common Clock Framework

  .../bindings/clock/samsung,s5pv210-clock.txt   |  75 +++
  arch/arm/mach-s5pv210/Kconfig  |   9 +
  arch/arm/mach-s5pv210/Makefile |   4 +-
  arch/arm/mach-s5pv210/common.c |  17 +
  arch/arm/mach-s5pv210/common.h |  10 +
  arch/arm/mach-s5pv210/mach-goni.c  |   2 +-
  arch/arm/mach-s5pv210/mach-smdkv210.c  |   2 +-
  arch/arm/plat-samsung/Kconfig  |   2 +-
  drivers/clk/samsung/Makefile   |   3 +
  drivers/clk/samsung/clk-s5pv210.c  | 673
+ drivers/cpufreq/s5pv210-cpufreq.c
  |   6 +-
  include/dt-bindings/clock/samsung,s5pv210-clock.h  | 224 +++
  12 files changed, 1019 insertions(+), 8 deletions(-)
  create mode 100644
Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt
create mode 100644 drivers/clk/samsung/clk-s5pv210.c
  create mode 100644 include/dt-bindings/clock/samsung,s5pv210-clock.h


I believe this series is reasonable to be applied. Could we agree on
the tree it would go through and get all tne required acks?

Best regards,
Tomasz


I agree.

Mike, how do you think the common clk stuff for s5pv210?

- Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/19] perf session: Add missing members to perf_event__attr_swap()

[Jiri Olsa]

On Fri, Oct 18, 2013 at 03:29:03PM +0300, Adrian Hunter wrote:
> perf_event__attr_swap() needs to swap all members of
> struct perf_event_attr.  Add mssing ones.

Acked-by: Jiri Olsa 

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/19] perf session: Add missing sample flush for piped events

[Jiri Olsa]

On Fri, Oct 18, 2013 at 03:29:02PM +0300, Adrian Hunter wrote:
> Piped events can be sorted so a final flush is needed.
> Add that and remove a redundant 'err = 0'.
> 
> Signed-off-by: Adrian Hunter 

seems ok,
Reviewed-by: Jiri Olsa 

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/19] perf evsel: Add missing decrement in id sample parsing

[Jiri Olsa]

On Fri, Oct 18, 2013 at 03:29:01PM +0300, Adrian Hunter wrote:
> The final array decrement in id sample parsing is missing,
> which may trip up the next person adding a sample format,
> so add it in.

Acked-by: Jiri Olsa 

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 14/19] perf evlist: Add a debug print if event buffer mmap fails

[Jiri Olsa]

On Fri, Oct 18, 2013 at 03:29:11PM +0300, Adrian Hunter wrote:
> Add a debug print if mmap of the perf event
> ring buffer fails.
> 
> Signed-off-by: Adrian Hunter 
> ---
>  tools/perf/util/evlist.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 07ba0a4..52e434a 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -600,6 +600,7 @@ static int __perf_evlist__mmap(struct perf_evlist *evlist,
>   evlist->mmap[idx].base = mmap(NULL, evlist->mmap_len, prot,
> MAP_SHARED, fd, 0);
>   if (evlist->mmap[idx].base == MAP_FAILED) {
> + pr_debug2("failed to mmap perf event ring buffer\n");

while at it, we could display errno

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 13/19] perf tools: Fix libunwind build and feature detection for 32-bit build

[Jiri Olsa]

On Fri, Oct 18, 2013 at 03:29:10PM +0300, Adrian Hunter wrote:
> Use -lunwind-x86 instead of -lunwind-x86_64 for
> 32-bit build.
> 
> Signed-off-by: Adrian Hunter 

Acked-by: Jiri Olsa 

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/19] perf tools: Fix 32-bit cross build

[Jiri Olsa]

On Fri, Oct 18, 2013 at 03:29:06PM +0300, Adrian Hunter wrote:
> Setting EXTRA_CFLAGS=-m32 did not work because CFLAGS
> was not passed around.

this breaks feature detection for me on x86_64,
I've got following errors misdetection with this patch:

...   libperl: [ OFF ]
...   on-exit: [ OFF ]

and the build fails as well:

  CC   builtin-stat.o
builtin-record.c:42:12: error: static declaration of ‘on_exit’ follows 
non-static declaration
In file included from util/util.h:51:0,
 from builtin.h:4,
 from builtin-record.c:8:
/usr/include/stdlib.h:536:12: note: previous declaration of ‘on_exit’ was here
make[1]: *** [builtin-record.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [all] Error 2


jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/19] perf record: Improve write_output error message

[Jiri Olsa]

On Fri, Oct 18, 2013 at 03:29:00PM +0300, Adrian Hunter wrote:
> Improve the error message from write_output() to say
> what failed to write and give the error number.
> 
> Signed-off-by: Adrian Hunter 
> ---
>  tools/perf/builtin-record.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 92ca541..d269dfa 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -88,7 +88,7 @@ static int write_output(struct perf_record *rec, void *buf, 
> size_t size)
>   int ret = write(rec->output, buf, size);
>  
>   if (ret < 0) {
> - pr_err("failed to write\n");
> + pr_err("failed to write perf data, error: %m\n");

is this some kind of format magic? ;-) you wanted
to print out 'ret' value, right?

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] iio: (max1363) support SMBus for 8-bit devices

[Jonathan Cameron]

On 10/20/13 19:02, Vivien Didelot wrote:
> The driver currently supports only I2C access. But some devices with an
> accuracy of 8-bit are compatible with the SMBus byte access routines.
> 
> This patch wraps the send and receive routines depending on the chip
> accuracy and fonctionnalities of its adapter.
> 
> For instance, this allows us to use a MAX11603 on a ICH7 controller.
> 
> This patch also simplifies the max1363_write_basic_config() routine to
> use the struct max1363_state fields directly.
> 
> Signed-off-by: Vivien Didelot 
Sensible change given I am guessing you have a usecase that needs to
run it as described.  I've slightly changed the description to make it clear 
that
this is applies for all supported 8 bit devices.

> ---
>  drivers/iio/adc/max1363.c | 76 
> +++
>  1 file changed, 57 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/iio/adc/max1363.c b/drivers/iio/adc/max1363.c
> index cc07b37..6118dce 100644
> --- a/drivers/iio/adc/max1363.c
> +++ b/drivers/iio/adc/max1363.c
> @@ -165,6 +165,8 @@ struct max1363_chip_info {
>   * @thresh_low:  low threshold values
>   * @vref:Reference voltage regulator
>   * @vref_uv: Actual (external or internal) reference voltage
> + * @send:function used to send data to the chip
> + * @recv:function used to receive data from the chip
>   */
>  struct max1363_state {
>   struct i2c_client   *client;
> @@ -186,6 +188,10 @@ struct max1363_state {
>   s16 thresh_low[8];
>   struct regulator*vref;
>   u32 vref_uv;
> + int (*send)(const struct i2c_client *client,
> + const char *buf, int count);
> + int (*recv)(const struct i2c_client *client,
> + char *buf, int count);
>  };
>  
>  #define MAX1363_MODE_SINGLE(_num, _mask) {   \
> @@ -311,13 +317,37 @@ static const struct max1363_mode
>   return NULL;
>  }
>  
> -static int max1363_write_basic_config(struct i2c_client *client,
> -   unsigned char d1,
> -   unsigned char d2)
> +static int max1363_smbus_send(const struct i2c_client *client, const char 
> *buf,
> + int count)
>  {
> - u8 tx_buf[2] = {d1, d2};
> + int i, err;
>  
> - return i2c_master_send(client, tx_buf, 2);
> + for (i = err = 0; err == 0 && i < count; ++i)
> + err = i2c_smbus_write_byte(client, buf[i]);
> +
> + return err ? err : count;
> +}
> +
> +static int max1363_smbus_recv(const struct i2c_client *client, char *buf,
> + int count)
> +{
> + int i, ret;
> +
> + for (i = 0; i < count; ++i) {
> + ret = i2c_smbus_read_byte(client);
> + if (ret < 0)
> + return ret;
> + buf[i] = ret;
> + }
> +
> + return count;
> +}
> +
> +static int max1363_write_basic_config(struct max1363_state *st)
> +{
> + u8 tx_buf[2] = { st->setupbyte, st->configbyte };
> +
> + return st->send(st->client, tx_buf, 2);
>  }
>  
>  static int max1363_set_scan_mode(struct max1363_state *st)
> @@ -327,9 +357,7 @@ static int max1363_set_scan_mode(struct max1363_state *st)
>   | MAX1363_SE_DE_MASK);
>   st->configbyte |= st->current_mode->conf;
>  
> - return max1363_write_basic_config(st->client,
> -   st->setupbyte,
> -   st->configbyte);
> + return max1363_write_basic_config(st);
>  }
>  
>  static int max1363_read_single_chan(struct iio_dev *indio_dev,
> @@ -366,7 +394,7 @@ static int max1363_read_single_chan(struct iio_dev 
> *indio_dev,
>   }
>   if (st->chip_info->bits != 8) {
>   /* Get reading */
> - data = i2c_master_recv(client, rxbuf, 2);
> + data = st->recv(client, rxbuf, 2);
>   if (data < 0) {
>   ret = data;
>   goto error_ret;
> @@ -375,7 +403,7 @@ static int max1363_read_single_chan(struct iio_dev 
> *indio_dev,
> ((1 << st->chip_info->bits) - 1);
>   } else {
>   /* Get reading */
> - data = i2c_master_recv(client, rxbuf, 1);
> + data = st->recv(client, rxbuf, 1);
>   if (data < 0) {
>   ret = data;
>   goto error_ret;
> @@ -772,11 +800,11 @@ static irqreturn_t max1363_event_handler(int irq, void 
> *private)
>   u8 tx[2] = { st->setupbyte,
>MAX1363_MON_INT_ENABLE | (st->monitor_speed << 1) | 0xF0 };
>  
> - i2c_master_recv(st->client, &rx, 1);
> + st->recv(st->client, &rx, 1);
>   mask = rx;
>   for_each_set_bit(loc, &mask, 8)
>

[PATCH v2] vsprintf: add Bluetooth UUID %pU[rR] format specifier

[Marcel Holtmann]

The Bluetooth UUID is used in big endian reversed order. Add new
modifier to print a UUID in big endian, but where the input byte
stream is actually in reversed order.

This is similar to %pMR that allows to print a MAC address in
reversed order since that is how the Bluetooth BD_ADDR is
actually represented in a byte stream.

Signed-off-by: Marcel Holtmann 
---
v2: Allow combinations of %pUlr etc.

 Documentation/printk-formats.txt |  6 ++
 lib/vsprintf.c   | 40 
 2 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 445ad74..1fd0e43 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -159,12 +159,18 @@ UUID/GUID addresses:
%pUB00010203-0405-0607-0809-0A0B0C0D0E0F
%pUl03020100-0504-0706-0809-0a0b0c0e0e0f
%pUL03020100-0504-0706-0809-0A0B0C0E0E0F
+   %pUr0f0e0d0c-0b0a-0908-0706-050403020100
+   %pUR0F0E0D0C-0B0A-0908-0706-050403020100
 
For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L',
'b' and 'B' specifiers are used to specify a little endian order in
lower ('l') or upper case ('L') hex characters - and big endian order
in lower ('b') or upper case ('B') hex characters.
 
+   The additional 'r' and 'R' specifiers are used to specify reversed
+   big endian order in either lower ('r') or upper case ('R') hex
+   characters. This is useful for Bluetooth UUID addresses.
+
Where no additional specifiers are used the default little endian
order with lower case hex characters will be printed.
 
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..d0f9188 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1106,20 +1106,32 @@ char *uuid_string(char *buf, char *end, const u8 *addr,
static const u8 le[16] = {3,2,1,0,5,4,7,6,8,9,10,11,12,13,14,15};
const u8 *index = be;
bool uc = false;
+   bool reversed = false;
 
-   switch (*(++fmt)) {
-   case 'L':
-   uc = true;  /* fall-through */
-   case 'l':
-   index = le;
-   break;
-   case 'B':
-   uc = true;
-   break;
+   while (isalpha(*++fmt)) {
+   switch (*fmt) {
+   case 'L':
+   uc = true;  /* fall-through */
+   case 'l':
+   index = le;
+   break;
+   case 'B':
+   uc = true;
+   break;
+   case 'R':
+   uc = true;  /* fall-through */
+   case 'r':
+   reversed = true;
+   break;
+   }
}
 
for (i = 0; i < 16; i++) {
-   p = hex_byte_pack(p, addr[index[i]]);
+   if (reversed)
+   p = hex_byte_pack(p, addr[index[15 - i]]);
+   else
+   p = hex_byte_pack(p, addr[index[i]]);
+
switch (i) {
case 3:
case 5:
@@ -1199,10 +1211,14 @@ int kptr_restrict __read_mostly;
  * B big endian UPPER case hex
  * l little endian lower case hex
  * L little endian UPPER case hex
+ * r big endian lower case hex, reverse order (Bluetooth)
+ * R big endian UPPER case hex, reverse order (Bluetooth)
  *   big endian output byte order is:
  * [0][1][2][3]-[4][5]-[6][7]-[8][9]-[10][11][12][13][14][15]
  *   little endian output byte order is:
  * [3][2][1][0]-[5][4]-[7][6]-[8][9]-[10][11][12][13][14][15]
+ *   big endian, reverse order output byte order is:
+ * [15][14][13][12]-[11][10]-[9][8]-[7][6]-[5][4][3][2][1][0]
  * - 'V' For a struct va_format which contains a format string * and va_list *,
  *   call vsnprintf(->format, *->va_list).
  *   Implements a "recursive vsnprintf".
@@ -1572,8 +1588,8 @@ qualifier:
  * %pI6c print an IPv6 address as specified by RFC 5952
  * %pIS depending on sa_family of 'struct sockaddr *' print IPv4/IPv6 address
  * %piS depending on sa_family of 'struct sockaddr *' print IPv4/IPv6 address
- * %pU[bBlL] print a UUID/GUID in big or little endian using lower or upper
- *   case.
+ * %pU[bBlLrR] print a UUID/GUID in big or little endian or reversed order
+ *   big endian using lower or upper case.
  * %*ph[CDN] a variable-length hex string with a separator (supports up to 64
  *   bytes of the input)
  * %n is ignored
-- 
1.8.3.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/

[tip:perf/urgent] perf: Disable PERF_RECORD_MMAP2 support

[tip-bot for Stephane Eranian]

Commit-ID:  3090ffb5a2515990182f3f55b0688a7817325488
Gitweb: http://git.kernel.org/tip/3090ffb5a2515990182f3f55b0688a7817325488
Author: Stephane Eranian 
AuthorDate: Thu, 17 Oct 2013 19:32:15 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 17 Oct 2013 16:27:14 -0300

perf: Disable PERF_RECORD_MMAP2 support

For now, we disable the extended MMAP record support (MMAP2).

We have identified cases where it would not report the correct mapping
information, clone(VM_CLONE) but with separate pids.  We will revisit
the support once we find a solution for this case.

The patch changes the kernel to return EINVAL if attr->mmap2 is set. The
patch also modifies the perf tool to use regular PERF_RECORD_MMAP for
synthetic events and it also prevents the tool from requesting
attr->mmap2 mode because the kernel would reject it.

The support will be revisited once the kenrel interface is updated.

In V2, we reduce the patch to the strict minimum.

In V3, we avoid calling perf_event_open() with mmap2 set because we know
it will fail and require fallback retry.

Signed-off-by: Stephane Eranian 
Cc: Andi Kleen 
Cc: David Ahern 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20131017173215.GA8820@quad
Signed-off-by: Arnaldo Carvalho de Melo 
---
 kernel/events/core.c|  4 
 tools/perf/util/event.c | 30 +-
 tools/perf/util/evsel.c |  1 -
 3 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index d49a9d2..953c143 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6767,6 +6767,10 @@ static int perf_copy_attr(struct perf_event_attr __user 
*uattr,
if (ret)
return -EFAULT;
 
+   /* disabled for now */
+   if (attr->mmap2)
+   return -EINVAL;
+
if (attr->__reserved_1)
return -EINVAL;
 
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 9b393e7..63df031 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -187,7 +187,7 @@ static int perf_event__synthesize_mmap_events(struct 
perf_tool *tool,
return -1;
}
 
-   event->header.type = PERF_RECORD_MMAP2;
+   event->header.type = PERF_RECORD_MMAP;
/*
 * Just like the kernel, see __perf_event_mmap in kernel/perf_event.c
 */
@@ -198,7 +198,6 @@ static int perf_event__synthesize_mmap_events(struct 
perf_tool *tool,
char prot[5];
char execname[PATH_MAX];
char anonstr[] = "//anon";
-   unsigned int ino;
size_t size;
ssize_t n;
 
@@ -209,13 +208,10 @@ static int perf_event__synthesize_mmap_events(struct 
perf_tool *tool,
strcpy(execname, "");
 
/* 0040-0040c000 r-xp  fd:01 41038  /bin/cat */
-   n = sscanf(bf, "%"PRIx64"-%"PRIx64" %s %"PRIx64" %x:%x %u %s\n",
-  &event->mmap2.start, &event->mmap2.len, prot,
-  &event->mmap2.pgoff, &event->mmap2.maj,
-  &event->mmap2.min,
-  &ino, execname);
-
-   event->mmap2.ino = (u64)ino;
+   n = sscanf(bf, "%"PRIx64"-%"PRIx64" %s %"PRIx64" %*x:%*x %*u 
%s\n",
+  &event->mmap.start, &event->mmap.len, prot,
+  &event->mmap.pgoff,
+  execname);
 
if (n != 8)
continue;
@@ -227,15 +223,15 @@ static int perf_event__synthesize_mmap_events(struct 
perf_tool *tool,
strcpy(execname, anonstr);
 
size = strlen(execname) + 1;
-   memcpy(event->mmap2.filename, execname, size);
+   memcpy(event->mmap.filename, execname, size);
size = PERF_ALIGN(size, sizeof(u64));
-   event->mmap2.len -= event->mmap.start;
-   event->mmap2.header.size = (sizeof(event->mmap2) -
-   (sizeof(event->mmap2.filename) - size));
-   memset(event->mmap2.filename + size, 0, machine->id_hdr_size);
-   event->mmap2.header.size += machine->id_hdr_size;
-   event->mmap2.pid = tgid;
-   event->mmap2.tid = pid;
+   event->mmap.len -= event->mmap.start;
+   event->mmap.header.size = (sizeof(event->mmap) -
+   (sizeof(event->mmap.filename) - size));
+   memset(event->mmap.filename + size, 0, machine->id_hdr_size);
+   event->mmap.header.size += machine->id_hdr_size;
+   event->mmap.pid = tgid;
+   event->mmap.tid = pid;
 
if (process(tool, event, &synth_sample, machine) != 0) {
rc = -1;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0ce9feb..9f1ef9b 100644
--- a/tools/perf/util/evsel.c
+++ b/too

[tip:perf/urgent] perf scripting perl: Fix build error on Fedora 12

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  3b16ff89676d9902dc39976aee3cb0314ee37d93
Gitweb: http://git.kernel.org/tip/3b16ff89676d9902dc39976aee3cb0314ee37d93
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 14 Oct 2013 18:25:12 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 17 Oct 2013 16:24:26 -0300

perf scripting perl: Fix build error on Fedora 12

Cast __u64 to u64 to silence this warning on older distros, such as
Fedora 12:

CC   /tmp/build/perf/util/scripting-engines/trace-event-perl.o
  cc1: warnings being treated as errors
  util/scripting-engines/trace-event-perl.c: In function 
‘perl_process_tracepoint’:
  util/scripting-engines/trace-event-perl.c:285: error: format ‘%lu’ expects 
type ‘long unsigned int’, but argument 2 has type ‘__u64’
  make[1]: *** [/tmp/build/perf/util/scripting-engines/trace-event-perl.o] 
Error 1
  make: *** [install] Error 2
  make: Leaving directory `/home/acme/git/linux/tools/perf'
  [acme@fedora12 linux]$

Reported-by: Waiman Long 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Mike Galbraith 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Tom Zanussi 
Cc: Waiman Long 
Link: http://lkml.kernel.org/n/tip-nlxofdqcdjfm0w9o6bgq4...@git.kernel.org
Link: 
http://lkml.kernel.org/r/1381265120-58532-1-git-send-email-waiman.l...@hp.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/scripting-engines/trace-event-perl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-perl.c 
b/tools/perf/util/scripting-engines/trace-event-perl.c
index a85e4ae..c0c9795 100644
--- a/tools/perf/util/scripting-engines/trace-event-perl.c
+++ b/tools/perf/util/scripting-engines/trace-event-perl.c
@@ -282,7 +282,7 @@ static void perl_process_tracepoint(union perf_event 
*perf_event __maybe_unused,
 
event = find_cache_event(evsel);
if (!event)
-   die("ug! no event found for type %" PRIu64, evsel->attr.config);
+   die("ug! no event found for type %" PRIu64, 
(u64)evsel->attr.config);
 
pid = raw_field_value(event, "common_pid", data);
 
--
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/

[tip:irq/urgent] irq: DocBook/genericirq.tmpl: Correct various typos

[tip-bot for Randy Dunlap]

Commit-ID:  fd2f3b7ee1cf4b5fa77659c5ed4aa3cf5d1b3731
Gitweb: http://git.kernel.org/tip/fd2f3b7ee1cf4b5fa77659c5ed4aa3cf5d1b3731
Author: Randy Dunlap 
AuthorDate: Fri, 18 Oct 2013 17:36:16 -0700
Committer:  Ingo Molnar 
CommitDate: Sat, 19 Oct 2013 10:25:17 +0200

irq: DocBook/genericirq.tmpl: Correct various typos

Typo corrections for DocBook/genericirq.tmpl.

Signed-off-by: Randy Dunlap 
Link: http://lkml.kernel.org/r/5261d400.30...@infradead.org
Signed-off-by: Ingo Molnar 
---
 Documentation/DocBook/genericirq.tmpl | 64 +--
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/Documentation/DocBook/genericirq.tmpl 
b/Documentation/DocBook/genericirq.tmpl
index d16d21b..46347f6 100644
--- a/Documentation/DocBook/genericirq.tmpl
+++ b/Documentation/DocBook/genericirq.tmpl
@@ -87,7 +87,7 @@
   
 Rationale

-   The original implementation of interrupt handling in Linux is using
+   The original implementation of interrupt handling in Linux uses
the __do_IRQ() super-handler, which is able to deal with every
type of interrupt logic.

@@ -111,19 +111,19 @@



-   This split implementation of highlevel IRQ handlers allows us to
+   This split implementation of high-level IRQ handlers allows us to
optimize the flow of the interrupt handling for each specific
-   interrupt type. This reduces complexity in that particular codepath
+   interrupt type. This reduces complexity in that particular code path
and allows the optimized handling of a given type.


The original general IRQ implementation used hw_interrupt_type
structures and their ->ack(), ->end() [etc.] callbacks to
differentiate the flow control in the super-handler. This leads to
-   a mix of flow logic and lowlevel hardware logic, and it also leads
-   to unnecessary code duplication: for example in i386, there is a
-   ioapic_level_irq and a ioapic_edge_irq irq-type which share many
-   of the lowlevel details but have different flow handling.
+   a mix of flow logic and low-level hardware logic, and it also leads
+   to unnecessary code duplication: for example in i386, there is an
+   ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
+   of the low-level details but have different flow handling.


A more natural abstraction is the clean separation of the
@@ -132,23 +132,23 @@

Analysing a couple of architecture's IRQ subsystem implementations
reveals that most of them can use a generic set of 'irq flow'
-   methods and only need to add the chip level specific code.
+   methods and only need to add the chip-level specific code.
The separation is also valuable for (sub)architectures
-   which need specific quirks in the irq flow itself but not in the
-   chip-details - and thus provides a more transparent IRQ subsystem
+   which need specific quirks in the IRQ flow itself but not in the
+   chip details - and thus provides a more transparent IRQ subsystem
design.


-   Each interrupt descriptor is assigned its own highlevel flow
+   Each interrupt descriptor is assigned its own high-level flow
handler, which is normally one of the generic
-   implementations. (This highlevel flow handler implementation also
+   implementations. (This high-level flow handler implementation also
makes it simple to provide demultiplexing handlers which can be
found in embedded platforms on various architectures.)


The separation makes the generic interrupt handling layer more
flexible and extensible. For example, an (sub)architecture can
-   use a generic irq-flow implementation for 'level type' interrupts
+   use a generic IRQ-flow implementation for 'level type' interrupts
and add a (sub)architecture specific 'edge type' implementation.


@@ -172,9 +172,9 @@
 
There are three main levels of abstraction in the interrupt code:

- Highlevel driver API
- Highlevel IRQ flow handlers
- Chiplevel hardware encapsulation
+ High-level driver API
+ High-level IRQ flow handlers
+ Chip-level hardware encapsulation

 
 
@@ -189,16 +189,16 @@
which are assigned to this interrupt.


-   Whenever an interrupt triggers, the lowlevel arch code calls into
-   the generic interrupt code by calling desc->handle_irq().
-   This highlevel IRQ handling function only uses desc->irq_data.chip
+   Whenever an interrupt triggers, the low-level architecture code calls
+   into the generic interrupt code by calling desc->handle_irq().
+   This high-level IRQ handling function only uses desc->irq_data.chip
primitives referenc

[tip:core/urgent] mutex: Avoid gcc version dependent __builtin_constant_p() usage

[tip-bot for Tetsuo Handa]

Commit-ID:  b0267507dfd0187fb7840a0ec461a510a7f041c5
Gitweb: http://git.kernel.org/tip/b0267507dfd0187fb7840a0ec461a510a7f041c5
Author: Tetsuo Handa 
AuthorDate: Thu, 17 Oct 2013 19:45:29 +0900
Committer:  Ingo Molnar 
CommitDate: Fri, 18 Oct 2013 21:58:54 +0200

mutex: Avoid gcc version dependent __builtin_constant_p() usage

Commit 040a0a37 ("mutex: Add support for wound/wait style locks")
used "!__builtin_constant_p(p == NULL)" but gcc 3.x cannot
handle such expression correctly, leading to boot failure when
built with CONFIG_DEBUG_MUTEXES=y.

Fix it by explicitly passing a bool which tells whether p != NULL
or not.

[ PeterZ: This is a sad patch, but provided it actually generates
  similar code I suppose its the best we can do bar whole
  sale deprecating gcc-3. ]

Signed-off-by: Tetsuo Handa 
Acked-by: Peter Zijlstra 
Acked-by: Maarten Lankhorst 
Cc: pet...@infradead.org
Cc: imir...@alum.mit.edu
Cc: daniel.vet...@ffwll.ch
Cc: robdcl...@gmail.com
Cc: Linus Torvalds 
Cc: Andrew Morton 
Link: 
http://lkml.kernel.org/r/201310171945.agb17114.fsqvthojfoo...@i-love.sakura.ne.jp
Signed-off-by: Ingo Molnar 
---
 kernel/mutex.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/kernel/mutex.c b/kernel/mutex.c
index 6d647ae..d24105b 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -410,7 +410,7 @@ ww_mutex_set_context_fastpath(struct ww_mutex *lock,
 static __always_inline int __sched
 __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
struct lockdep_map *nest_lock, unsigned long ip,
-   struct ww_acquire_ctx *ww_ctx)
+   struct ww_acquire_ctx *ww_ctx, const bool use_ww_ctx)
 {
struct task_struct *task = current;
struct mutex_waiter waiter;
@@ -450,7 +450,7 @@ __mutex_lock_common(struct mutex *lock, long state, 
unsigned int subclass,
struct task_struct *owner;
struct mspin_node  node;
 
-   if (!__builtin_constant_p(ww_ctx == NULL) && ww_ctx->acquired > 
0) {
+   if (use_ww_ctx && ww_ctx->acquired > 0) {
struct ww_mutex *ww;
 
ww = container_of(lock, struct ww_mutex, base);
@@ -480,7 +480,7 @@ __mutex_lock_common(struct mutex *lock, long state, 
unsigned int subclass,
if ((atomic_read(&lock->count) == 1) &&
(atomic_cmpxchg(&lock->count, 1, 0) == 1)) {
lock_acquired(&lock->dep_map, ip);
-   if (!__builtin_constant_p(ww_ctx == NULL)) {
+   if (use_ww_ctx) {
struct ww_mutex *ww;
ww = container_of(lock, struct ww_mutex, base);
 
@@ -551,7 +551,7 @@ slowpath:
goto err;
}
 
-   if (!__builtin_constant_p(ww_ctx == NULL) && ww_ctx->acquired > 
0) {
+   if (use_ww_ctx && ww_ctx->acquired > 0) {
ret = __mutex_lock_check_stamp(lock, ww_ctx);
if (ret)
goto err;
@@ -575,7 +575,7 @@ skip_wait:
lock_acquired(&lock->dep_map, ip);
mutex_set_owner(lock);
 
-   if (!__builtin_constant_p(ww_ctx == NULL)) {
+   if (use_ww_ctx) {
struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
struct mutex_waiter *cur;
 
@@ -615,7 +615,7 @@ mutex_lock_nested(struct mutex *lock, unsigned int subclass)
 {
might_sleep();
__mutex_lock_common(lock, TASK_UNINTERRUPTIBLE,
-   subclass, NULL, _RET_IP_, NULL);
+   subclass, NULL, _RET_IP_, NULL, 0);
 }
 
 EXPORT_SYMBOL_GPL(mutex_lock_nested);
@@ -625,7 +625,7 @@ _mutex_lock_nest_lock(struct mutex *lock, struct 
lockdep_map *nest)
 {
might_sleep();
__mutex_lock_common(lock, TASK_UNINTERRUPTIBLE,
-   0, nest, _RET_IP_, NULL);
+   0, nest, _RET_IP_, NULL, 0);
 }
 
 EXPORT_SYMBOL_GPL(_mutex_lock_nest_lock);
@@ -635,7 +635,7 @@ mutex_lock_killable_nested(struct mutex *lock, unsigned int 
subclass)
 {
might_sleep();
return __mutex_lock_common(lock, TASK_KILLABLE,
-  subclass, NULL, _RET_IP_, NULL);
+  subclass, NULL, _RET_IP_, NULL, 0);
 }
 EXPORT_SYMBOL_GPL(mutex_lock_killable_nested);
 
@@ -644,7 +644,7 @@ mutex_lock_interruptible_nested(struct mutex *lock, 
unsigned int subclass)
 {
might_sleep();
return __mutex_lock_common(lock, TASK_INTERRUPTIBLE,
-  subclass, NULL, _RET_IP_, NULL);
+  subclass, NULL, _RET_IP_, NULL, 0);
 }
 
 EXPORT_SYMBOL_GPL(mutex_lock_interruptible_nested);
@@ -682,7 +682,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct 
ww_acquire_ctx *ctx)
 
might_sl

[tip:perf/urgent] perf probe: Fix to initialize fname always before use it

[tip-bot for Masami Hiramatsu]

Commit-ID:  1b286bdd5b7684c681b63d5e75cada037064c315
Gitweb: http://git.kernel.org/tip/1b286bdd5b7684c681b63d5e75cada037064c315
Author: Masami Hiramatsu 
AuthorDate: Fri, 11 Oct 2013 12:23:17 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 15 Oct 2013 14:37:38 -0300

perf probe: Fix to initialize fname always before use it

Fix perf probe --list to initialize fname local var always before
use it. This may cause a SEGV if there is a probe which is in
the function body but not in any inline function.

Problem introduced in:

commit e08cfd4bda76
Author: Masami Hiramatsu 
Date:   Mon Sep 30 18:21:44 2013 +0900

perf probe: Fix to find line information for probe list

Signed-off-by: Masami Hiramatsu 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/20131011122317.9662.29736.stgit@kbuild-fedora.novalocal
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-finder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index c09e0a9..f069273 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1357,10 +1357,10 @@ int debuginfo__find_probe_point(struct debuginfo *self, 
unsigned long addr,
goto post;
}
 
+   fname = dwarf_decl_file(&spdie);
if (addr == (unsigned long)baseaddr) {
/* Function entry - Relative line number is 0 */
lineno = baseline;
-   fname = dwarf_decl_file(&spdie);
goto post;
}
 
--
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: [000/121] 3.2.51-rc1 review

[Guenter Roeck]

On 10/20/2013 11:05 AM, Ben Hutchings wrote:

On Sun, 2013-10-20 at 09:23 -0700, Guenter Roeck wrote:

On 10/20/2013 04:56 AM, Ben Hutchings wrote:

On Sun, 2013-09-08 at 09:52 -0700, Guenter Roeck wrote:

On 09/08/2013 01:18 AM, Geert Uytterhoeven wrote:

On Sun, Sep 8, 2013 at 9:10 AM, Guenter Roeck  wrote:

m68k-linux-ld: error: no memory region specified for loadable section
`.note.gnu.build-id'


I can't seem to find an explicit fix for that since v3.2.
Perhaps the fix is a side effect of f84f52a5c15db7d14a534815f27253b001735183
("m68knommu: clean up linker script").



Kind of. Turns out it requires the following patches.

40c1b9cf (m68k: consolidate the vmlinux.lds linker scripts)
ed865e31 (m68k: use non-MMU linker script for ColdFire MMU builds)
f84f52a5 (m68knommu: clean up linker script)

With those patches applied, all my m68k builds (mmu and nommu) pass with 3.2.


I've queued these up for 3.2.  The first looks quite a big change in
terms of lines, but most of that is just renaming a file so I think it's
within the spirit of the stable rules.  The third is also pretty big as
m68knommu seems so broken in 3.2 that I suppose it is OK.

Ben.


Hi Ben,

is that in your patch list yet ? Just wondering, because the latest nommu build 
still failed.


I've only just pushed them.



Yes, I see that m68k-nommu build failures are all gone now.

Great!

Thanks,
Guenter

--
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 3/5] slab: restrict the number of objects in a slab

[Christoph Lameter]

On Sat, 19 Oct 2013, JoonSoo Kim wrote:

> > Ok so that results in a mininum size object size of 2^(12 - 8) = 2^4 ==
> > 16 bytes on x86. This is not true for order 1 pages (which SLAB also
> > supports) where we need 32 bytes.
>
> According to current slab size calculating logic, slab whose object size is
> less or equal to 16 bytes use only order 0 page. So there is no problem.

Ok then lets add a VM_BUG_ON to detect the situation when someone tries
something different.

> > Problems may arise on PPC or IA64 where the page size may be larger than
> > 64K. With 64K we have a mininum size of 2^(16 - 8) = 256 bytes. For those
> > arches we may need 16 bit sized indexes. Maybe make that compile time
> > determined base on page size? > 64KByte results in 16 bit sized indexes?
>
> Okay. I will try it.

Again compile time. You had runtime in some earlier patches which adds new
branches to key functions.

--
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: [000/121] 3.2.51-rc1 review

[Ben Hutchings]

On Sun, 2013-10-20 at 09:23 -0700, Guenter Roeck wrote:
> On 10/20/2013 04:56 AM, Ben Hutchings wrote:
> > On Sun, 2013-09-08 at 09:52 -0700, Guenter Roeck wrote:
> >> On 09/08/2013 01:18 AM, Geert Uytterhoeven wrote:
> >>> On Sun, Sep 8, 2013 at 9:10 AM, Guenter Roeck  wrote:
>  m68k-linux-ld: error: no memory region specified for loadable section
>  `.note.gnu.build-id'
> >>>
> >>> I can't seem to find an explicit fix for that since v3.2.
> >>> Perhaps the fix is a side effect of 
> >>> f84f52a5c15db7d14a534815f27253b001735183
> >>> ("m68knommu: clean up linker script").
> >>>
> >>
> >> Kind of. Turns out it requires the following patches.
> >>
> >> 40c1b9cf (m68k: consolidate the vmlinux.lds linker scripts)
> >> ed865e31 (m68k: use non-MMU linker script for ColdFire MMU builds)
> >> f84f52a5 (m68knommu: clean up linker script)
> >>
> >> With those patches applied, all my m68k builds (mmu and nommu) pass with 
> >> 3.2.
> >
> > I've queued these up for 3.2.  The first looks quite a big change in
> > terms of lines, but most of that is just renaming a file so I think it's
> > within the spirit of the stable rules.  The third is also pretty big as
> > m68knommu seems so broken in 3.2 that I suppose it is OK.
> >
> > Ben.
> >
> Hi Ben,
> 
> is that in your patch list yet ? Just wondering, because the latest nommu 
> build still failed.

I've only just pushed them.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.


signature.asc
Description: This is a digitally signed message part

kernel BUG at mm/slub.c:3338! RIP [] kfree+0x20c/0x210

[Sander Eikelenboom]

Hi,

With i 3.12.0-rc6 kernel i encounterd this splat:

[19424.151472] [ cut here ]
[19424.151496] kernel BUG at mm/slub.c:3338!
[19424.151506] invalid opcode:  [#1] PREEMPT SMP
[19424.151520] Modules linked in:
[19424.151532] CPU: 1 PID: 2824 Comm: glusterfs Not tainted 3.12.0-rc6-20131020 
#1
[19424.151549] task: 88001d14 ti: 88001df4c000 task.ti: 
88001df4c000
[19424.151561] RIP: e030:[]  [] 
kfree+0x20c/0x210
[19424.151580] RSP: e02b:88001df4dde8  EFLAGS: 00010246
[19424.151589] RAX: 0040 RBX: 88001df4de68 RCX: 
[19424.151600] RDX:  RSI: 0001 RDI: 88001df4de68
[19424.151611] RBP: 88001df4de28 R08: 88001e0f7930 R09: 0058
[19424.151622] R10:  R11:  R12: 88001cf4de68
[19424.151633] R13: ea77d340 R14: 88001e317a00 R15: 0058
[19424.151649] FS:  7f549af8c700() GS:88001fd0() 
knlGS:
[19424.151661] CS:  e033 DS:  ES:  CR0: 8005003b
[19424.151671] CR2: 7f549f026000 CR3: 1c891000 CR4: 0660
[19424.151683] Stack:
[19424.151689]  00020050   

[19424.151708]  88001cf4de68 0002 88001e317a00 
0058
[19424.151726]  88001df4df18 81186b01 88001df4ded8 
810f0edf
[19424.151744] Call Trace:
[19424.151756]  [] do_readv_writev+0x111/0x250
[19424.151771]  [] ? lock_release_non_nested+0xaf/0x320
[19424.151784]  [] ? lock_release+0x12f/0x250
[19424.151796]  [] vfs_readv+0x2d/0x50
[19424.151807]  [] SyS_readv+0x54/0xd0
[19424.151820]  [] system_call_fastpath+0x16/0x1b
[19424.151830] Code: 89 4d 8b 6d 30 e9 7e fe ff ff 48 8b 4d c0 48 89 da 4c 89 
ee 4c 89 e7 e8 54 e4 8c 00 e9 69 ff ff ff e8 19 a2 8d 00 e9 2f ff ff ff <0f> 0b 
66 90 55 48 89 e5 48 83 ec 30 48 89 5d d8 4c 89 75 f0 48
[19424.151954] RIP  [] kfree+0x20c/0x210
[19424.151970]  RSP 
[19424.151983] ---[ end trace 225a70bf87bd3a82 ]---


--
Sander

--
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 13/15] slab: use struct page for slab management

[Christoph Lameter]

On Sat, 19 Oct 2013, JoonSoo Kim wrote:

> I search the history of struct page and find that the SLUB use mapping field
> in past (2007 year). At that time, you inserted VM_BUG_ON(PageSlab(page))
> ('b5fab14') into page_mapping() function to find remaining use. Recently,
> I never hear that this is triggered and 6 years have passed since inserting
> VM_BUG_ON(), so I guess there is no problem to use it.
> If this argument is reasonable, please give me an ACK :)
>
> Thanks.

Acked-by: Christoph Lameter 

--
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] iio: (max1363) support SMBus for 8-bit devices

[Vivien Didelot]

The driver currently supports only I2C access. But some devices with an
accuracy of 8-bit are compatible with the SMBus byte access routines.

This patch wraps the send and receive routines depending on the chip
accuracy and fonctionnalities of its adapter.

For instance, this allows us to use a MAX11603 on a ICH7 controller.

This patch also simplifies the max1363_write_basic_config() routine to
use the struct max1363_state fields directly.

Signed-off-by: Vivien Didelot 
---
 drivers/iio/adc/max1363.c | 76 +++
 1 file changed, 57 insertions(+), 19 deletions(-)

diff --git a/drivers/iio/adc/max1363.c b/drivers/iio/adc/max1363.c
index cc07b37..6118dce 100644
--- a/drivers/iio/adc/max1363.c
+++ b/drivers/iio/adc/max1363.c
@@ -165,6 +165,8 @@ struct max1363_chip_info {
  * @thresh_low:low threshold values
  * @vref:  Reference voltage regulator
  * @vref_uv:   Actual (external or internal) reference voltage
+ * @send:  function used to send data to the chip
+ * @recv:  function used to receive data from the chip
  */
 struct max1363_state {
struct i2c_client   *client;
@@ -186,6 +188,10 @@ struct max1363_state {
s16 thresh_low[8];
struct regulator*vref;
u32 vref_uv;
+   int (*send)(const struct i2c_client *client,
+   const char *buf, int count);
+   int (*recv)(const struct i2c_client *client,
+   char *buf, int count);
 };
 
 #define MAX1363_MODE_SINGLE(_num, _mask) { \
@@ -311,13 +317,37 @@ static const struct max1363_mode
return NULL;
 }
 
-static int max1363_write_basic_config(struct i2c_client *client,
- unsigned char d1,
- unsigned char d2)
+static int max1363_smbus_send(const struct i2c_client *client, const char *buf,
+   int count)
 {
-   u8 tx_buf[2] = {d1, d2};
+   int i, err;
 
-   return i2c_master_send(client, tx_buf, 2);
+   for (i = err = 0; err == 0 && i < count; ++i)
+   err = i2c_smbus_write_byte(client, buf[i]);
+
+   return err ? err : count;
+}
+
+static int max1363_smbus_recv(const struct i2c_client *client, char *buf,
+   int count)
+{
+   int i, ret;
+
+   for (i = 0; i < count; ++i) {
+   ret = i2c_smbus_read_byte(client);
+   if (ret < 0)
+   return ret;
+   buf[i] = ret;
+   }
+
+   return count;
+}
+
+static int max1363_write_basic_config(struct max1363_state *st)
+{
+   u8 tx_buf[2] = { st->setupbyte, st->configbyte };
+
+   return st->send(st->client, tx_buf, 2);
 }
 
 static int max1363_set_scan_mode(struct max1363_state *st)
@@ -327,9 +357,7 @@ static int max1363_set_scan_mode(struct max1363_state *st)
| MAX1363_SE_DE_MASK);
st->configbyte |= st->current_mode->conf;
 
-   return max1363_write_basic_config(st->client,
- st->setupbyte,
- st->configbyte);
+   return max1363_write_basic_config(st);
 }
 
 static int max1363_read_single_chan(struct iio_dev *indio_dev,
@@ -366,7 +394,7 @@ static int max1363_read_single_chan(struct iio_dev 
*indio_dev,
}
if (st->chip_info->bits != 8) {
/* Get reading */
-   data = i2c_master_recv(client, rxbuf, 2);
+   data = st->recv(client, rxbuf, 2);
if (data < 0) {
ret = data;
goto error_ret;
@@ -375,7 +403,7 @@ static int max1363_read_single_chan(struct iio_dev 
*indio_dev,
  ((1 << st->chip_info->bits) - 1);
} else {
/* Get reading */
-   data = i2c_master_recv(client, rxbuf, 1);
+   data = st->recv(client, rxbuf, 1);
if (data < 0) {
ret = data;
goto error_ret;
@@ -772,11 +800,11 @@ static irqreturn_t max1363_event_handler(int irq, void 
*private)
u8 tx[2] = { st->setupbyte,
 MAX1363_MON_INT_ENABLE | (st->monitor_speed << 1) | 0xF0 };
 
-   i2c_master_recv(st->client, &rx, 1);
+   st->recv(st->client, &rx, 1);
mask = rx;
for_each_set_bit(loc, &mask, 8)
iio_push_event(indio_dev, max1363_event_codes[loc], timestamp);
-   i2c_master_send(st->client, tx, 2);
+   st->send(st->client, tx, 2);
 
return IRQ_HANDLED;
 }
@@ -812,9 +840,7 @@ static int max1363_monitor_mode_update(struct max1363_state 
*st, int enabled)
st->setupbyte &= ~MAX1363_SETUP_MONITOR_SETUP;
st->co

Re: fanotify: don't merge permission events

[Ben Hutchings]

On Tue, 2013-09-24 at 20:41 +0300, Mihai Donțu wrote:
> Ben, Greg,
> 
> Can you pull this[1] patch into your stable kernels (3.2, 3.4)? It
> fixes an unfortunate bug in fanotify where a multithreaded application
> can end up in an interruptible state, a situation which only a reboot
> can fix. Ultimately, I'm hoping that the fix ends up in Ubuntu's
> kernels (for which I have also created a request[2]).
> 
> Thank you,
> 
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/fs/notify/fanotify?id=03a1cec1f17ac1a6041996b3e40f96b5a2f90e1b
> [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1148084

Queued up for 3.2, thanks.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 2/3] mm: Fix some trivial typos in comments

[Christoph Lameter]

Acked-by: Christoph Lameter 
--
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/