[PATCH] perf: Add --objdump option to perf top

[Sukadev Bhattiprolu]

perf: Add objdump option to 'perf top'

Like with 'perf annotate' add the --objdump option to perf top so users
can specify an alternate path to the /usr/bin/objdump binary.

Reported-by: David A. Gilbert 
Signed-off-by: Sukadev Bhattiprolu 
---
 tools/perf/builtin-top.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 67bdb9f..820caeb 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -40,6 +40,7 @@
 #include "util/xyarray.h"
 #include "util/sort.h"
 #include "util/intlist.h"
+#include "arch/common.h"
 
 #include "util/debug.h"
 
@@ -942,6 +943,12 @@ static int __cmd_top(struct perf_top *top)
if (top->session == NULL)
return -ENOMEM;
 
+   if (!objdump_path) {
+   ret = 
perf_session_env__lookup_objdump(>session->header.env);
+   if (ret)
+   goto out_delete;
+   }
+
ret = perf_top__setup_sample_type(top);
if (ret)
goto out_delete;
@@ -1107,6 +1114,8 @@ int cmd_top(int argc, const char **argv, const char 
*prefix __maybe_unused)
"Interleave source code with assembly code (default)"),
OPT_BOOLEAN(0, "asm-raw", _conf.annotate_asm_raw,
"Display raw encoding of assembly instructions (default)"),
+   OPT_STRING(0, "objdump", _path, "path",
+   "objdump binary to use for disassembly and annotations"),
OPT_STRING('M', "disassembler-style", _style, 
"disassembler style",
   "Specify disassembler style (e.g. -M intel for intel 
syntax)"),
OPT_STRING('u', "uid", >uid_str, "user", "user to profile"),
-- 
1.7.1

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

Re: [PATCH V5 0/5] Queue work on power efficient wq

[Viresh Kumar]

On 14 May 2013 23:24, Tejun Heo  wrote:
> On Wed, Apr 24, 2013 at 05:12:52PM +0530, Viresh Kumar wrote:
>> This patchset was called: "Create sched_select_cpu() and use it for 
>> workqueues"
>> for the first three versions.
>
> Applied to wq/for-3.11 with some updates to comments and
> documentation.  Will post the applied versions.  If something is awry,
> please let me know.

Thanks. All looks good.
--
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 2/3] Documentation: virtio: Add emergency write (emerg_wr) config register in virtio console.

[Amit Shah]

On (Wed) 15 May 2013 [13:59:29], Rusty Russell wrote:
> Pranavkumar Sawargaonkar  writes:
> > Hi Rusty,
> >
> > On 13 May 2013 08:22, Rusty Russell  wrote:
> >> Pranavkumar Sawargaonkar  writes:
> >>> Signed-off-by: Pranavkumar Sawargaonkar 
> >>> Signed-off-by: Anup Patel 
> >>> ---
> >>>  Documentation/virtual/virtio-spec.txt |8 +++-
> >>>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> OK, I applied this to the lyx master, with three changes:
> >> 1) Changed "filed" to "field".
> >> 2) Added ", or even acknowledging the feature" after "without
> >>initializing virtio queues".
> >> 3) Added an initial point to the Device Initialization section:
> >>
> >>1. If the VIRTIO_CONSOLE_F_EMERG_WRITE feature is offered, the
> >>emerg_wr field of the configuration can be written at any time. Thus
> >>it should work for very early boot debugging output as well as
> >>catastophic OS failures (eg. virtio ring corruption).
> >
> > Thanks for applying this patch.
> > Have you also applied first patch ([PATCH V2 1/3] virtio: console: Add
> > emergency writeonly register to config space)
> > with this?  (https://lkml.org/lkml/2013/5/6/169)
> 
> Would like Amit's Ack, since he's de-facto console maintainer.

I've been away, and am reviewing the discussions here.  Expect a
response later today.

Thanks,

Amit
--
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] ARM:dts:omap4-panda:Update the LED support for the panda DTS

[Nishanth Menon]

$subject - add a space?
s/ARM:dts:omap4-panda:Update/ARM: dts: omap4-panda: Update/ ?

On 09:17-20130514, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
> 
> A1-A3 = gpio_wk7
Thanks for fixing this - this is a key fix else, GPIO_7 which controls
VSEL for VDD_MPU on PandaBoard-ES will create all kind of ruckus (change
voltage on heartbeat)!
> ES = gpio_110
> 
> There is no change to LED D2
> 
> Abstract away the pinmux and the LED definitions for the two boards into
> the respective DTS files.
> 
> Signed-off-by: Dan Murphy 
> ---
[...]
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index f1d8c21..8d1ba03 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -34,3 +34,43 @@
>   0x5e 0x100  /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>   >;
>  };
> +
> + {
> + compatible = "gpio-leds";
> + heartbeat {
> + label = "pandaboard::status1";
> + gpios = < 14 0>;
> + linux,default-trigger = "heartbeat";
> + };
> + mmc {
> + label = "pandaboard::status2";
> + gpios = < 8 0>;
> + linux,default-trigger = "gpio";
mmc0?
> + };
> +};
> +
Other that that,
Tested-by: Nishanth Menon 
-- 
Regards,
Nishanth Menon
--
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: 3.9.0: panic during boot - kernel BUG at include/linux/gfp.h:323!

[Lingzhu Xiang]

On 05/15/2013 02:35 AM, Tejun Heo wrote:

Hello,

On Tue, May 14, 2013 at 11:35:29AM +0800, Lingzhu Xiang wrote:

On 05/06/2013 03:55 PM, CAI Qian wrote:

[0.928031] [ cut here ]
[0.934231] kernel BUG at include/linux/gfp.h:323!

...

[1.662913]  [] alloc_cpumask_var_node+0x28/0x90
[1.671224]  [] wq_numa_init+0x10d/0x1be
[1.686085]  [] init_workqueues+0x64/0x341


Does the following patch make the problem go away?  The dynamic paths
should be safe as they are synchronized against CPU hot plug paths and
don't allocate anything on nodes w/o any CPUs.


Yes, no more panics.



diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 4aa9f5b..232c1bb 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4895,7 +4895,8 @@ static void __init wq_numa_init(void)
BUG_ON(!tbl);

for_each_node(node)
-   BUG_ON(!alloc_cpumask_var_node([node], GFP_KERNEL, node));
+   BUG_ON(!alloc_cpumask_var_node([node], GFP_KERNEL,
+   node_online(node) ? node : NUMA_NO_NODE));

for_each_possible_cpu(cpu) {
node = cpu_to_node(cpu);



--
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] vhost-scsi: Depend on NET for memcpy_fromiovec

[Rusty Russell]

Asias He  writes:
> scsi.c includes vhost.c which uses memcpy_fromiovec.
>
> This patch fixes this build failure.
>
>From Randy Dunlap:
>'''
>on x86_64:
>
>ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
>
>It needs to depend on NET since net/core/ provides that function.
>'''

Proper fix please.

Though I can't see why you thought this was a good idea.  Nonetheless, I
shan't highlight why: I have far too much respect for your intellects
and abilities.

No, don't thank me!
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: [PATCH] module: Add section ".ref.data" into kmemleak-scan-area.

[Rusty Russell]

Catalin Marinas  writes:
> On Mon, May 13, 2013 at 03:24:09AM +0100, Rusty Russell wrote:
>> majianpeng  writes:
>> 
>> > In commit 523c81135,it used "__refdata" on event_class_ftrace_##call.
>> > It will cause kmemleak to misjudge because when loading module it did
>> > not add '.ref.data' into kmemleak-scan-area.
>> > 
>> > Signed-off-by: Jianpeng Ma 
>> > ---
>> >  kernel/module.c |3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> Catalin?
>> 
>> Acked-by: Rusty Russell 
>
> Looks good, thanks for cc'ing me.
>
> Acked-by: Catalin Marinas 

I use "Acked-by" to mean "it touches my code so normally it'd go in my
tree, but it's not".

Since you replied the same, I defer to your wishes and put it in my
fixes branch (or Linus will grab it now).  I also removed the extra
trailing space ('git am' complained).

Thanks,
Rusty.

From: Jianpeng Ma 
Date: Sat, 11 May 2013 10:04:14 +0800
Subject: [PATCH] module: Add section ".ref.data" into kmemleak-scan-area.

In commit 523c81135,it used "__refdata" on event_class_ftrace_##call.
It will cause kmemleak to misjudge because when loading module it did
not add '.ref.data' into kmemleak-scan-area.

Signed-off-by: Jianpeng Ma 
Acked-by: Catalin Marinas 
Tested-by: Steven Rostedt 
Signed-off-by: Rusty Russell 

diff --git a/kernel/module.c b/kernel/module.c
index b049939..e4ee1bf 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2434,7 +2434,8 @@ static void kmemleak_load_module(const struct module *mod,
const char *name = info->secstrings + info->sechdrs[i].sh_name;
if (!(info->sechdrs[i].sh_flags & SHF_ALLOC))
continue;
-   if (!strstarts(name, ".data") && !strstarts(name, ".bss"))
+   if (!strstarts(name, ".data") && !strstarts(name, ".bss") &&
+   !strstarts(name, ".ref.data"))
continue;
 
kmemleak_scan_area((void *)info->sechdrs[i].sh_addr,
--
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 2/3] Documentation: virtio: Add emergency write (emerg_wr) config register in virtio console.

[Rusty Russell]

Pranavkumar Sawargaonkar  writes:
> Hi Rusty,
>
> On 13 May 2013 08:22, Rusty Russell  wrote:
>> Pranavkumar Sawargaonkar  writes:
>>> Signed-off-by: Pranavkumar Sawargaonkar 
>>> Signed-off-by: Anup Patel 
>>> ---
>>>  Documentation/virtual/virtio-spec.txt |8 +++-
>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> OK, I applied this to the lyx master, with three changes:
>> 1) Changed "filed" to "field".
>> 2) Added ", or even acknowledging the feature" after "without
>>initializing virtio queues".
>> 3) Added an initial point to the Device Initialization section:
>>
>>1. If the VIRTIO_CONSOLE_F_EMERG_WRITE feature is offered, the
>>emerg_wr field of the configuration can be written at any time. Thus
>>it should work for very early boot debugging output as well as
>>catastophic OS failures (eg. virtio ring corruption).
>
> Thanks for applying this patch.
> Have you also applied first patch ([PATCH V2 1/3] virtio: console: Add
> emergency writeonly register to config space)
> with this?  (https://lkml.org/lkml/2013/5/6/169)

Would like Amit's Ack, since he's de-facto console maintainer.

I've reproduced it below.

Cheers,
Rusty.

Subject: [PATCH V2 1/3] virtio: console: Add emergency writeonly register to 
config space
Date: Mon,  6 May 2013 17:49:49 +0530
Message-Id: <1367842791-30285-2-git-send-email-pranavku...@linaro.org>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1367842791-30285-1-git-send-email-pranavku...@linaro.org>
References: <1367842791-30285-1-git-send-email-pranavku...@linaro.org>
X-Gm-Message-State: 
ALoCoQmDOoCdPmDpT+VgLwYAlJHmkUTB8sEAHVSbrNxWBzYgPHFT9rQ2A9dR8fToM81cHDZDppGx

This patch adds an emerg_wr register (writeonly) in config space
of virtio console device which can be used for debugging.

Signed-off-by: Pranavkumar Sawargaonkar 
Signed-off-by: Anup Patel 
Signed-off-by: Rusty Russell 
---
 include/uapi/linux/virtio_console.h |3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/virtio_console.h 
b/include/uapi/linux/virtio_console.h
index ee13ab6..3fd0dce 100644
--- a/include/uapi/linux/virtio_console.h
+++ b/include/uapi/linux/virtio_console.h
@@ -38,6 +38,7 @@
 /* Feature bits */
 #define VIRTIO_CONSOLE_F_SIZE  0   /* Does host provide console size? */
 #define VIRTIO_CONSOLE_F_MULTIPORT 1   /* Does host provide multiple ports? */
+#define VIRTIO_CONSOLE_F_EMERG_WRITE 2 /* Does host support emergency write? */
 
 #define VIRTIO_CONSOLE_BAD_ID  (~(u32)0)
 
@@ -48,6 +49,8 @@ struct virtio_console_config {
__u16 rows;
/* max. number of ports this device can hold */
__u32 max_nr_ports;
+   /* emergency write register */
+   __u32 emerg_wr;
 } __attribute__((packed));
 
 /*


--
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: regression: from 3.8 to 3.9: headphones output no sound on Intel HDA, codec VIA VT1802

[Takashi Iwai]

At Tue, 14 May 2013 21:55:43 +0200,
Alex Riesen wrote:
> 
> On Tue, May 14, 2013 at 12:58 PM, Takashi Iwai  wrote:
> >> OK, then we know the place to fix now.
> >> Try the patch below instead.  Does it fix the problem as well?
> >
> > The below is the revised patch, fixing not only for VT1802 but other
> > VIA codecs, too.  Please let me know if it works.
> 
> With this patch headphones work, but Auto-Mute is inverted, as it was before.

OK, could you give again alsa-info.sh outputs at HP plugged and
unplugged?


thanks,

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

Re: [PATCH 5/5] media: i2c: tvp7002: add OF support

[Prabhakar Lad]

Hi Laurent,

Thanks for the review.

On Tue, May 14, 2013 at 9:04 PM, Laurent Pinchart
 wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Tuesday 14 May 2013 16:15:34 Lad Prabhakar wrote:
>> From: Lad, Prabhakar 
>>
>> add OF support for the tvp7002 driver.
>>
>> Signed-off-by: Lad, Prabhakar 
>> Cc: Hans Verkuil 
>> Cc: Laurent Pinchart 
>> Cc: Mauro Carvalho Chehab 
>> Cc: Guennadi Liakhovetski 
>> Cc: Sylwester Nawrocki 
>> Cc: Sakari Ailus 
>> Cc: Grant Likely 
>> Cc: Rob Herring 
>> Cc: Rob Landley 
>> Cc: devicetree-disc...@lists.ozlabs.org
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: davinci-linux-open-sou...@linux.davincidsp.com
>> ---
>>  .../devicetree/bindings/media/i2c/tvp7002.txt  |   42 +
>>  drivers/media/i2c/tvp7002.c|   64 +++--
>>  2 files changed, 99 insertions(+), 7 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
>> b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt new file mode
>> 100644
>> index 000..1ebd8b1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
>> @@ -0,0 +1,42 @@
>> +* Texas Instruments TV7002 video decoder
>> +
>> +The TVP7002 device supports digitizing of video and graphics signal in RGB
>> and
>> +YPbPr color space.
>> +
>> +Required Properties :
>> +- compatible : Must be "ti,tvp7002"
>> +
>> +- hsync-active: HSYNC Polarity configuration for endpoint.
>> +
>> +- vsync-active: VSYNC Polarity configuration for endpoint.
>> +
>> +- pclk-sample: Clock polarity of the endpoint.
>> +
>> +- ti,tvp7002-fid-polarity: Active-high Field ID polarity of the endpoint.
>> +
>> +- ti,tvp7002-sog-polarity: Sync on Green output polarity of the endpoint.
>
> Would it make sense to define field-active and sog-active properties in the
> V4L2 bindings instead of having per-chip properties ?
>
yes you are right these properties need to be in the device node
rather than the
port node. I'll send alone this patch of the series as v2 fixing the above.

Regards,
--Prabhakar Lad
--
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] ASoC: remove saarb and tavorevb3 machine drivers

[Mark Brown]

On Tue, May 14, 2013 at 05:07:21PM +0200, Paul Bolle wrote:
> Support for PXA95x was removed in v3.8. This means that the Kconfig
> symbols MACH_SAARB and MACH_TAVOREVB3 are no longer available. This
> leaves the SoC Audio support for Marvell Saarb and Marvell Tavor EVB3
> unbuildable. Remove these drivers too.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] ARM: PL011: add support for extended FIFO-size of PL011-r1p5

[Stephen Warren]

On 05/14/2013 07:00 PM, Jongsung Kim wrote:
> Stephen Warren  :
>> Looking at BCM2835-ARM-Peripherals.pdf (i.e. the public documentation for
>> the BCM2835 chip), I see:
>>
>> =
>> The UART provides:
>> * Separate 16x8 transmit and 16x12 receive FIFO memory.
>> ...
>> For the in-depth UART overview, please, refer to the ARM PrimeCell UART
>> (PL011) Revision: r1p5 Technical Reference Manual.
>> =
>>
>> That seems to imply that not all r1p5 PL011s actually have a depth-32 FIFO.
>> Perhaps this is a configurable property of the IP block, not something that
>> all r1p5 have?
> 
> All r1p5 have 32-byte FIFO depth and it's not configurable. From the PL011
> TRM:
> 
> r1p4-r1p5 Contains the following differences in functionality:
>   * The receive and transmit FIFOs are increased to a depth of 32.
>   * The Revision field in the UARTPeriphID2 Register on page 3-24
> bits [7:4] now reads back as 0x3.

Well, that certainly isn't true in practice. I think we should revert
this commit until we can determine what the problem is.

I validated that the periphid register in HW contains the r1p5 revision
(3), and the pcellid register does indeed contain the expected
0xb105f00d value. However, if I run the following hacky code in U-Boot
to determine the FIFO depth, it comes out as 16, which explains the
symptoms I'm seeing:

void find_fifo_depth(void)
{
volatile u8 *uart = 0x20201000;
int depth = 0;

/* Wait for TX FIFO empty */
while (!(uart[0x18] & 0x80))
;

/* Disable UART */
uart[0x30] &= ~1;

/* Push chars into TX FIFO until full */
for (;;) {
uart[0] = 'A' + depth;
depth++;
/* Done if FIFO full */
if (uart[0x18] & 0x20)
break;
if (depth > 64) {
depth = -1;
break;
}
}

/* Re-enable UART */
uart[0x30] |= 1;

printf("FIFO depth: %d\n", depth);
}
--
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: EnhanceIO kernel driver

[Amit Kale]

Hi Jens,

That's fair. We do have a strong belief in the value of EnhanceIO driver. We'll 
send more information soon.

Thanks.
-Amit

> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Wednesday, May 15, 2013 1:36 AM
> To: OS Engineering
> Cc: LKML; Sanoj Unnikrishnan; Carlos Alonso; Amit Phansalkar
> Subject: Re: EnhanceIO kernel driver
> 
> On Tue, May 14 2013, OS Engineering wrote:
> > Hi Jens,
> >
> > Kindly find an updated EnhanceIO(TM) software kernel driver attached
> > herewith. Continuing with our previous communication: we request you
> > to include it in Linux kernel.
> 
> The situation has changed a bit since last. We know have both dm-cache
> and bcache in the kernel. What does this solution bring to the table,
> that those two do not already cover?
> 
> IOW, we need a bit of a better sales pitch than "here it is".
> 
> --
> Jens Axboe


PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED



This electronic transmission, and any documents attached hereto, may contain 
confidential, proprietary and/or legally privileged information. The 
information is intended only for use by the recipient named above. If you 
received this electronic message in error, please notify the sender and delete 
the electronic message. Any disclosure, copying, distribution, or use of the 
contents of information received in error is strictly prohibited, and violators 
will be pursued legally.
--
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: Fans at full speed after resume

[Sonny Rao]

On Tue, May 14, 2013 at 9:34 PM, Sonny Rao  wrote:
> On Tue, May 14, 2013 at 9:29 PM, Zhang Rui  wrote:
>> On Wed, 2013-05-15 at 12:26 +0800, Zhang Rui wrote:
>>> please
>>>
>>> On Tue, 2013-05-14 at 21:18 -0700, Sonny Rao wrote:
>>> > Hi, I've seen a regression in kernels since 3.7 on x86 devices where
>>> > the kernel turns the system fans on to max speed after resuming from
>>> > ram.  Other people have noticed it as well, for example see
>>> > https://bugzilla.redhat.com/show_bug.cgi?id=895276
>>> >
>>> please check if this is a duplicate of bug
>>> https://bugzilla.kernel.org/show_bug.cgi?id=56591
>> or you can try 3.10-rc1 to see if the problem still exists or not.
>
> Ok, I patched in the fix from that bugzilla --
> 928c5edbe6f7cb0d1c71bc2353d091bc5b114fe3
> but I'm still seeing the issue, I'll try 3.10-rc1 next
>

3.10-rc1 seems good
3.9.2 is okay, though fans do seem to be on more for a while after
resume, it eventually turns off
3.8.13 seems to still be broken, with fans at maximum

>>
>> thanks,
>> rui
>>> > For example on the Samsung 550 Chromebook, we have one thermal zone
>>> > and have 5 cooling_devices, 0-4, which correspond to 5 possible fan
>>> > speeds.  Under typical idle, only cooling_device4 and maybe
>>> > cooling_device3 are active, depending on temperature:
>>> >
>>> > cat /sys/class/thermal/cooling_device[01234]/cur_state
>>> > /sys/class/thermal/thermal_zone0/temp
>>> > 0
>>> > 0
>>> > 0
>>> > 0
>>> > 1
>>> > 57000
>>> >
>>> > however after a suspend/resume, we see that cooling_devices 0 and 1
>>> > become active:
>>> > cat /sys/class/thermal/cooling_device[01234]/cur_state
>>> > /sys/class/thermal/thermal_zone0/temp
>>> > 1
>>> > 1
>>> > 0
>>> > 0
>>> > 1
>>> > 54000
>>> >
>>> > and it seems to stay that way, even though the temperature is low
>>> > enough that the fan shouldn't be running at that speed.  If I manually
>>> > disable cooling_devices 0 and 1 then fan control works normally again.
>>> >
>>> > I started bisecting it and was able to do so up until this commit:
>>> > commit 29b19e250434c6193c8b8e4c34c9c6284dd4f101
>>> > Merge: 125c4c7 c072fed
>>> > Author: Len Brown 
>>> > AuthorDate: Tue Oct 9 01:35:52 2012 -0400
>>> > Commit: Len Brown 
>>> > CommitDate: Tue Oct 9 01:35:52 2012 -0400
>>> >
>>> > Merge branch 'release' of
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux into
>>> > thermal
>>> >
>>> > unfortunately, I'm not able to successfully do a suspend/resume on the
>>> > commits in that merge, so I wasn't able to bisect down to the exact
>>> > commit.
>>> >
>>> > I did confirm that one parent of the merge is okay: commit
>>> > 125c4c706b680c7831f0966ff873c1ad0354ec25 idr: rename MAX_LEVEL to
>>> > MAX_IDR_LEVEL
>>> >
>>> > so I think it falls somewhere in this list of commits:
>>> > c072fed95c9855a920c114d7fa3351f0f54ea06e...e3f25e6e5836c4790fbe395ff42e241f372d859d
>>> >
>>> > c072fed9 thermal: Exynos: Fix NULL pointer dereference in
>>> > exynos_unregister_thermal()
>>> > a4b6fec9 Thermal: Fix bug on cpu_cooling, cooling device's id conflict 
>>> > problem.
>>> > 79e093c3 thermal: exynos: Use devm_* functions
>>> > 17be868e ARM: exynos: add thermal sensor driver platform data support
>>> > 7e0b55e6 thermal: exynos: register the tmu sensor with the kernel thermal 
>>> > layer
>>> > f22d9c03c thermal: exynos5: add exynos5250 thermal sensor driver support
>>> > c48cbba6 hwmon: exynos4: move thermal sensor driver to driver/thermal 
>>> > directory
>>> > 02361418 thermal: add generic cpufreq cooling implementation
>>> > a7a3b8c8 Fix a build error.
>>> > 204dd1d3 thermal: Fix potential NULL pointer accesses
>>> > 1e426ffdd thermal: add Renesas R-Car thermal sensor support
>>> > 79a49168 thermal: fix potential out-of-bounds memory access
>>> > f4a821ce6 Thermal: Introduce locking for cdev.thermal_instances list.
>>> > 908b9fb79 Thermal: Unify the code for both active and passive cooling
>>> > ce119f832 Thermal: Introduce simple arbitrator for setting device cooling 
>>> > state
>>> > b5e4ae62 Thermal: List thermal_instance in thermal_cooling_device.
>>> > cddf31b3b Thermal: Rename thermal_instance.node to 
>>> > thermal_instance.tz_node.
>>> > 2d374139 Thermal: Rename thermal_zone_device.cooling_devices
>>> > b81b6ba3 Thermal: rename structure thermal_cooling_device_instance to
>>> > thermal_instance
>>> > 4ae46befb Thermal: Introduce thermal_zone_trip_update()
>>> > 1b7ddb84 Thermal: Remove tc1/tc2 in generic thermal layer.
>>> > 601f3d424 Thermal: Introduce .get_trend() callback.
>>> > 9d99842f9 Thermal: set upper and lower limits
>>> > 74051ba5 Thermal: Introduce cooling states range support
>>> >
>>> > When I get time, I'll try to rebase those commits onto the IDR commit
>>> > and see if I can get a better bisect.  Any insights into the problem
>>> > would be appreciated, thanks.
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>>> the body of a message to majord...@vger.kernel.org
>>> More 

Re: Ricoh DMAR bug returns? (WAS Re: [PATCH v4] Quirk for buggy dma source tags with Intel IOMMU.)

[Pat Erley]

On 04/05/2013 01:50 AM, Pat Erley wrote:

On 04/05/2013 12:44 AM, Andrew Cooks wrote:

On Tue, Apr 2, 2013 at 11:47 PM, Pat Erley  wrote:

On 04/02/2013 10:50 AM, Andrew Cooks wrote:


On 2 Apr 2013 15:37, "Pat Erley" mailto:pat-l...@erley.org>> wrote:
  >
  > On 03/07/2013 09:35 PM, Andrew Cooks wrote:
  >>
  >> --- a/drivers/pci/quirks.c
  >> +++ b/drivers/pci/quirks.c
  >>
  >> +/* Table of multiple (ghost) source functions. This is similar
to the
  >> + * translated sources above, but with the following differences:
  >> + * 1. the device may use multiple functions as DMA sources,
  >> + * 2. these functions cannot be assumed to be actual devices,
they're simply
  >> + * incorrect DMA tags.
  >> + * 3. the specific ghost function for a request can not always be
predicted.
  >> + * For example, the actual device could be xx:yy.1 and it
could use
  >> + * both 0 and 1 for different requests, with no obvious way to
tell
when
  >> + * DMA will be tagged as comming from xx.yy.0 and and when it
will
be tagged
  >> + * as comming from xx.yy.1.
  >> + * The bitmap contains all of the functions used in DMA tags,
including the
  >> + * actual device.
  >> + * See https://bugzilla.redhat.com/show_bug.cgi?id=757166,
  >> + * https://bugzilla.kernel.org/show_bug.cgi?id=42679
  >> + * https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1089768
  >> + */
  >> +static const struct pci_dev_dma_multi_func_sources {
  >> +   u16 vendor;
  >> +   u16 device;
  >> +   u8 func_map;/* bit map. lsb is fn 0. */
  >> +} pci_dev_dma_multi_func_sources[] = {
  >> +   { PCI_VENDOR_ID_MARVELL_2, 0x9123, (1<<0)|(1<<1)},
  >> +   { PCI_VENDOR_ID_MARVELL_2, 0x9125, (1<<0)|(1<<1)},
  >> +   { PCI_VENDOR_ID_MARVELL_2, 0x9128, (1<<0)|(1<<1)},
  >> +   { PCI_VENDOR_ID_MARVELL_2, 0x9130, (1<<0)|(1<<1)},
  >> +   { PCI_VENDOR_ID_MARVELL_2, 0x9143, (1<<0)|(1<<1)},
  >> +   { PCI_VENDOR_ID_MARVELL_2, 0x9172, (1<<0)|(1<<1)},
  >> +   { 0 }
  >> +};
  >
  >
  > Adding another buggy device.  I have a Ricoh multifunction device:
  >
  > 17:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller
(rev
01)
  > 17:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394
  > Controller (rev 01)
  >
  > 17:00.0 0805: 1180:e822 (rev 01)
  > 17:00.3 0c00: 1180:e832 (rev 01)
  >

The Ricoh device issue has been known for some time and a quirk has
been
available since commit 12ea6cad1c7d046 in June 2012.  It's slightly
different than the problem this patch tries to work around [1].



Hmm, I've had this problem with many recent (vanilla) kernels, up to and
including 3.9-rc5



  > that adding entries for also fixed booting.  I don't have any SD
cards or firewire devices handy to test that they work, but the system
now boots, which was not the case without your patch and IOMMU/DMAR
enabled.

That is really strange. Could you tell us what kernel version you
tested
and provide dmesg output?



I'll capture a vanilla 3.8.5 boot without any patches and iommu=off,
then
try to find another machine to catch what I can of a netconsole boot
with
iommu=on.  What's the preferred way to send these?  pastebin links?

I'd been running the 'dirty' fix that's in the redhat bugzilla entry.  I
checked my .config and have CONFIG_PCI_QUIRKS=y, and verified my
devices are
in the quirks table for the pci_func_0_dma_source fixup.


Do you mean that even though your hardware is specifically listed in
the quirk table, the quirk simply hasn't worked for you? That would be
unfortunate, to say the least.


Precisely.


The fedora kernel included a separate patch for this issue until
recently (see https://bugzilla.redhat.com/show_bug.cgi?id=880051).  It
basically just disabled DMAR when the Ricoh device is present, the
same as the patch to the mailing list you mentioned.


Yes, that's what I've been avoiding doing.  Every new release, I boot
once with iommu=on, and firewire blacklisted, boot up, load the firewire
driver.  This has caused the 'Ricoh DMAR' bug on every kernel since I
got the laptop.  I then reboot and 


Is the dirty fix you're referring to comment 7?
https://bugzilla.redhat.com/show_bug.cgi?id=605888#c7


Apply this patch, which has worked fine for me, but per a commend in a
thread I created here on 10/19/2012[1], this has a potential significant
performance impact.  In my use case, a performance hit is worth the cost
for the features.

However, your patch(while not intended to be the fix), actually solves
the issue on my machine.  I don't know if it also has the potential
performance impact, but it's certainly not noticeably worse in my use case.

Pat Erley

[1] http://marc.info/?l=linux-pci=135094489232548=2


As a follow up, I still have this problem in 3.10.0-rc1+ (and the patch 
by Andrew to fix buggy dma source devices still fixes it).


Andrew, have you done anything with your DMA source patch since you last 
posted it?  I'm still using it and it still makes my computer happy. 
I'd happily 

[PATCH] msm: iommu: fix leak and invalid access

[Libo Chen]

This patch merge two patch that I sended before:
1. msm: iommu: add missing platform_device_unregister() in err case
2. msm: iommu: no need kfree before kzalloc successful

It fixes two obvious problems:
1. We have registered msm_iommu_driver first, and need unregister it when
registered msm_iommu_ctx_driver fail

2. We don`t need to kfree drvdata before kzalloc successful

Signed-off-by: Libo Chen 
---
 drivers/iommu/msm_iommu_dev.c |   11 +--
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/msm_iommu_dev.c b/drivers/iommu/msm_iommu_dev.c
index 8e8fb07..bae0b23 100644
--- a/drivers/iommu/msm_iommu_dev.c
+++ b/drivers/iommu/msm_iommu_dev.c
@@ -292,22 +292,20 @@ static int msm_iommu_ctx_probe(struct platform_device 
*pdev)
struct msm_iommu_ctx_drvdata *ctx_drvdata = NULL;
int i, ret;
if (!c || !pdev->dev.parent) {
-   ret = -EINVAL;
-   goto fail;
+   return -EINVAL;
}

drvdata = dev_get_drvdata(pdev->dev.parent);

if (!drvdata) {
-   ret = -ENODEV;
-   goto fail;
+   return -ENODEV;
}

ctx_drvdata = kzalloc(sizeof(*ctx_drvdata), GFP_KERNEL);
if (!ctx_drvdata) {
-   ret = -ENOMEM;
-   goto fail;
+   return -ENOMEM;
}
+
ctx_drvdata->num = c->num;
ctx_drvdata->pdev = pdev;

@@ -401,6 +399,7 @@ static int __init msm_iommu_driver_init(void)

ret = platform_driver_register(_iommu_ctx_driver);
if (ret != 0) {
+   platform_driver_unregister(_iommu_driver);
pr_err("Failed to register IOMMU context driver\n");
goto error;
}
-- 
1.7.1


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

Re: [PATCH] x86: mm: Remove unnecessary assignment for max_pfn_mapped

[Zhang Yanfei]

于 2013年05月10日 22:57, Yinghai Lu 写道:
> On Fri, May 10, 2013 at 3:28 AM, Zhang Yanfei
>  wrote:
>> 于 2013年05月10日 17:27, Yinghai Lu 写道:
>>> On Fri, May 10, 2013 at 2:01 AM, Zhang Yanfei
>>>  wrote:
 init_memory_mapping will set max_pfn_mapped:
 int_memory_mapping
   --> add_pfn_range_mapped
 --> max_pfn_mapped = max(max_pfn_mapped, end_pfn)

 In init_mem_mapping, before we set max_pfn_mapped to 0, we
 have already called init_memory_mapping to setup pagetable
 for [0, ISA_END_ADDRESS], and that sets max_pfn_mapped. So
 the assignment to 0 is not necessary, remove it.
>>>
>>> NAK.
>>>
>>> for 32bit or Xen, max_pfn_mapped is set way before in head_32.S and
>>> xen-enlighen.
>>
>> Hi Yinghai
>>
>> I might be wrong, but just from the code in init_mem_mapping only:
>>
>>  410 /* the ISA range is always mapped regardless of memory holes */
>>  411 init_memory_mapping(0, ISA_END_ADDRESS);
>>  412
>>  413 /* xen has big range in reserved near end of ram, skip it at 
>> first.*/
>>  414 addr = memblock_find_in_range(ISA_END_ADDRESS, end, PMD_SIZE, 
>> PMD_SIZE);
>>  415 real_end = addr + PMD_SIZE;
>>  416
>>  417 /* step_size need to be small so pgt_buf from BRK could cover 
>> it */
>>  418 step_size = PMD_SIZE;
>>  419 max_pfn_mapped = 0; /* will get exact value next */
>>
>> Line 411 set max_pfn_mapped, and then line 419 set it to zero again, so
>> why keep the later assignment?
> 
> the comment says: /* will get exact value next */
> 
> For x86 32bit path, and xen set bigger max_pfn_mapped before.
> 

Hello Yinghai,

I kindly understand what you mean now. But I think we can put the reset of
max_pfn_mapped at the beginning of init_mem_mapping. That looks more logical.

See patch below, please.

Thanks
Zhang

--
>From dbd213301d800299d256c5da65a1d598902ed826 Mon Sep 17 00:00:00 2001
From: Zhang Yanfei 
Date: Wed, 15 May 2013 11:48:19 +0800
Subject: [PATCH] x86, mm: Reset max_pfn_mapped before we create direct mappings

We use init_mem_mapping to create direct mappings from scratch. But
in 32bit or xen, we may have already set max_pfn_mapped before in
head_32.S and or xen-enlighten. So put the reset at beginning not
in the middle of init_mem_mapping seems more logical.

Also add comments to explain the reset.

Signed-off-by: Zhang Yanfei 
---
 arch/x86/mm/init.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index fdc5dca..f2e5d28 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -407,6 +407,14 @@ void __init init_mem_mapping(void)
end = max_low_pfn << PAGE_SHIFT;
 #endif
 
+   /*
+* In 32bit or xen, max_pfn_mapped has been set way before in
+* head_32.S or xen-enlighten. So here we reset it since we will
+* create direct mappings from scratch. And it will get its finally
+* exact value after we finish the direct mapping in this function.
+*/
+   max_pfn_mapped = 0;
+
/* the ISA range is always mapped regardless of memory holes */
init_memory_mapping(0, ISA_END_ADDRESS);
 
@@ -416,7 +424,6 @@ void __init init_mem_mapping(void)
 
/* step_size need to be small so pgt_buf from BRK could cover it */
step_size = PMD_SIZE;
-   max_pfn_mapped = 0; /* will get exact value next */
min_pfn_mapped = real_end >> PAGE_SHIFT;
last_start = start = real_end;
while (last_start > ISA_END_ADDRESS) {
-- 
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] clk: Introduce userspace clock driver

[Mark Brown]

On Tue, May 14, 2013 at 02:09:47PM -0400, Philip Balister wrote:

> First of all, the driver that loads the bitstream into the fpga
> fabric does not know ANYTHING about what the bitstream does. So it
> cannot do any setup based on the contents of the file that is
> loaded. (And this can also be loaded during the SoC bootup,
> bypassing this driver completely)

This is a problem that is going to need to be fixed - there will be some
things going on the FPGAs that do need drivers and so there needs to be
some way to instantiate a driver for a FPGA image.  Things like adding
extra DT blobs along with the FPGA image have been talked about

> Second, there are four clocks that feed the FPGA fabric. We will
> want to set these clocks from user space somehow. It is perfectly
> valid to use a uio driver to interface with logic in the fpga. If we
> take the approach of using such general purpose techniques to
> interface with fpga logic, we must have ways for the user to control
> the fpga clocks.

Right, and if the specific device is being controlled by UIO then having
UIO create some clocks makes sense but then that should be integrated
into the UIO instantiation rather than done as a separate thing.


signature.asc
Description: Digital signature

Re: [PATCH 2/2] f2fs: fix the inconsistent state of data pages

[Jaegeuk Kim]

2013-05-15 (수), 13:04 +0900, Namjae Jeon:
> 2013/5/15, Jaegeuk Kim :
> > In get_lock_data_page, if there is a data race between get_dnode_of_data
> > for
> > node and grab_cache_page for data, f2fs is able to face with the following
> > BUG_ON(dn.data_blkaddr == NEW_ADDR).
> >
> > kernel BUG at /home/zeus/f2fs_test/src/fs/f2fs/data.c:251!
> >  [] get_lock_data_page+0x1ec/0x210 [f2fs]
> > Call Trace:
> >  [] f2fs_readdir+0x89/0x210 [f2fs]
> >  [] ? fillonedir+0x100/0x100
> >  [] ? fillonedir+0x100/0x100
> >  [] vfs_readdir+0xb8/0xe0
> >  [] sys_getdents+0x8f/0x110
> >  [] system_call_fastpath+0x16/0x1b
> >
> > This bug is able to be occurred when the block address of the data block is
> > changed after f2fs_put_dnode().
> > In order to avoid that, this patch fixes the lock order of node and data
> > blocks in which the node block lock is covered by the data block lock.
> >
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/data.c | 17 +++--
> >  1 file changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 91ff93b..05fb5c6 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -233,18 +233,23 @@ struct page *get_lock_data_page(struct inode *inode,
> > pgoff_t index)
> > struct page *page;
> > int err;
> >
> > +repeat:
> > +   page = grab_cache_page(mapping, index);
> > +   if (!page)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > set_new_dnode(, inode, NULL, NULL, 0);
> > err = get_dnode_of_data(, index, LOOKUP_NODE);
> > -   if (err)
> > +   if (err) {
> > +   f2fs_put_page(page, 1);
> > return ERR_PTR(err);
> > +   }
> > f2fs_put_dnode();
> >
> > -   if (dn.data_blkaddr == NULL_ADDR)
> > +   if (dn.data_blkaddr == NULL_ADDR) {
> > +   f2fs_put_page(page, 1);
> > return ERR_PTR(-ENOENT);
> > -repeat:
> > -   page = grab_cache_page(mapping, index);
> > -   if (!page)
> > -   return ERR_PTR(-ENOMEM);
> > +   }
> >
> > if (PageUptodate(page))
> > return page;
> Is there no need to move PageUptodate condition checking to
> grab_cache_page next ?

For the data consistency, I'd like to check index in its node block
prior to this.
Thanks,

> 
> Thanks.
> > --
> > 1.8.1.3.566.gaa39828
> >
> > --
> > 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/
> >

-- 
Jaegeuk Kim
Samsung


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

Re: [PATCH v2 6/7] PCI: Make sure VF's driver get attached after PF's

[Alexander Duyck]

On 05/14/2013 07:48 PM, Yinghai Lu wrote:
> Found kernel try to load mlx4 drivers for VFs before
> PF's is loaded when the drivers are built-in, and kernel
> command line include probe_vfs=63, num_vfs=63.
> 
> [  169.581682] calling  mlx4_init+0x0/0x119 @ 1
> [  169.595681] mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011)
> [  169.600194] mlx4_core: Initializing :02:00.0
> [  169.616322] mlx4_core :02:00.0: Enabling SR-IOV with 63 VFs
> [  169.724084] pci :02:00.1: [15b3:1002] type 00 class 0x0c0600
> [  169.732442] mlx4_core: Initializing :02:00.1
> [  169.734345] mlx4_core :02:00.1: enabling device ( -> 0002)
> [  169.747060] mlx4_core :02:00.1: enabling bus mastering
> [  169.764283] mlx4_core :02:00.1: Detected virtual function - running in 
> slave mode
> [  169.767409] mlx4_core :02:00.1: with iommu 3 : domain 11
> [  169.785589] mlx4_core :02:00.1: Sending reset
> [  179.790131] mlx4_core :02:00.1: Got slave FLRed from Communication 
> channel (ret:0x1)
> [  181.798661] mlx4_core :02:00.1: slave is currently in themiddle of 
> FLR. retrying...(try num:1)
> [  181.803336] mlx4_core :02:00.1: Communication channel is not idle.my 
> toggle is 1 (cmd:0x0)
> ...
> [  182.078710] mlx4_core :02:00.1: slave is currently in themiddle of 
> FLR. retrying...(try num:10)
> [  182.096657] mlx4_core :02:00.1: Communication channel is not idle.my 
> toggle is 1 (cmd:0x0)
> [  182.104935] mlx4_core :02:00.1: slave driver version is not supported 
> by the master
> [  182.118570] mlx4_core :02:00.1: Communication channel is not idle.my 
> toggle is 1 (cmd:0x0)
> [  182.138190] mlx4_core :02:00.1: Failed to initialize slave
> [  182.141728] mlx4_core: probe of :02:00.1 failed with error -5
> 
> It turns that this also happen for hotadd path even drivers are
> compiled as modules and if they are loaded. Esp some VF share the
> same driver with PF.
> 
> calling path:
>   device driver probe
>   ==> pci_enable_sriov
>   ==> virtfn_add
>   ==> pci_dev_add
>   ==> pci_bus_device_add
> when pci_bus_device_add is called, the VF's driver will be attached.
> and at that time PF's driver does not finish yet.
> 
> Need to move out pci_bus_device_add from virtfn_add and call it
> later.
> 
> bnx2x and qlcnic are ok, because it does not modules command line
> to enable sriov. They must use sysfs to enable it.
> 
> be2net is ok, according to Sathya Perla,
> he fixed this issue in be2net with the following patch (commit b4c1df93)
>   http://marc.info/?l=linux-netdev=136801459808765=2
> 
> For igb and ixgbe is ok, as Alex Duyck said:
> | The VF driver should be able to be loaded when the PF driver is not
> | present.  We handle it in igb and ixgbe last I checked, and I don't see
> | any reason why it cannot be handled in all other VF drivers.  I'm not
> | saying the VF has to be able to fully functional, but it should be able
> | to detect the PF becoming enabled and then bring itself to a fully
> | functional state.  To not handle that case is a bug.
> 
> Looks like the patch will help enic, mlx4, efx, vxge and lpfc now.
> 
> -v2: don't use schedule_callback, and initcall after Alex's patch.
>   pci: Avoid reentrant calls to work_on_cpu
> 
> Signed-off-by: Yinghai Lu 
> Cc: Alexander Duyck 
> Cc: Yan Burman 
> Cc: Sathya Perla 
> Cc: net...@vger.kernel.org
> 

This is a driver bug in mlx4 and possibly a few others, not a bug in the
SR-IOV code.  My concern is your patch may introduce issues in all of
the drivers, especially the ones that don't need this workaround.
Fixing the kernel to make this work is just encouraging a poor design model.

The problem is the mlx4 driver is enabling SR-IOV before it is ready to
support VFs.  The mlx4 driver should probably be fixed by either,
changing over to sysfs, provisioning the resources before enabling
SR-IOV like be2net, or via the igb/ixgbe approach where the VF
gracefully handles the PF not being present.

Thanks,

Alex




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

Re: [PATCH 1/2] f2fs: fix inconsistency of block count during recovery

[Jaegeuk Kim]

2013-05-15 (수), 12:47 +0900, Namjae Jeon:
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index 3df43b4..9641534 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1492,6 +1492,8 @@ int recover_inode_page(struct f2fs_sb_info *sbi,
> > struct page *page)
> > new_ni = old_ni;
> > new_ni.ino = ino;
> >
> Hi. Jaegeuk.
> 
> I have a minor comment.
> > +   if (!inc_valid_node_count(sbi, NULL, 1))
> > +   WARN_ON(1);

Hi Namjae,

Negative since inc_valid_node_count() is not for debugging.
IMO, for readability, we need to make clear what the function call is
used for.
Thank you for the review. :)

> How about change WARN_ON(!inc_valid_node_count(sbi, NULL, 1)); ?
> 
> Reviewed-by: Namjae Jeon 
> Thanks.
> > set_node_addr(sbi, _ni, NEW_ADDR);
> > inc_valid_inode_count(sbi);
> >
> > --
> > 1.8.1.3.566.gaa39828
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

-- 
Jaegeuk Kim
Samsung


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

Re: Fans at full speed after resume

[Sonny Rao]

On Tue, May 14, 2013 at 9:29 PM, Zhang Rui  wrote:
> On Wed, 2013-05-15 at 12:26 +0800, Zhang Rui wrote:
>> please
>>
>> On Tue, 2013-05-14 at 21:18 -0700, Sonny Rao wrote:
>> > Hi, I've seen a regression in kernels since 3.7 on x86 devices where
>> > the kernel turns the system fans on to max speed after resuming from
>> > ram.  Other people have noticed it as well, for example see
>> > https://bugzilla.redhat.com/show_bug.cgi?id=895276
>> >
>> please check if this is a duplicate of bug
>> https://bugzilla.kernel.org/show_bug.cgi?id=56591
> or you can try 3.10-rc1 to see if the problem still exists or not.

Ok, I patched in the fix from that bugzilla --
928c5edbe6f7cb0d1c71bc2353d091bc5b114fe3
but I'm still seeing the issue, I'll try 3.10-rc1 next

>
> thanks,
> rui
>> > For example on the Samsung 550 Chromebook, we have one thermal zone
>> > and have 5 cooling_devices, 0-4, which correspond to 5 possible fan
>> > speeds.  Under typical idle, only cooling_device4 and maybe
>> > cooling_device3 are active, depending on temperature:
>> >
>> > cat /sys/class/thermal/cooling_device[01234]/cur_state
>> > /sys/class/thermal/thermal_zone0/temp
>> > 0
>> > 0
>> > 0
>> > 0
>> > 1
>> > 57000
>> >
>> > however after a suspend/resume, we see that cooling_devices 0 and 1
>> > become active:
>> > cat /sys/class/thermal/cooling_device[01234]/cur_state
>> > /sys/class/thermal/thermal_zone0/temp
>> > 1
>> > 1
>> > 0
>> > 0
>> > 1
>> > 54000
>> >
>> > and it seems to stay that way, even though the temperature is low
>> > enough that the fan shouldn't be running at that speed.  If I manually
>> > disable cooling_devices 0 and 1 then fan control works normally again.
>> >
>> > I started bisecting it and was able to do so up until this commit:
>> > commit 29b19e250434c6193c8b8e4c34c9c6284dd4f101
>> > Merge: 125c4c7 c072fed
>> > Author: Len Brown 
>> > AuthorDate: Tue Oct 9 01:35:52 2012 -0400
>> > Commit: Len Brown 
>> > CommitDate: Tue Oct 9 01:35:52 2012 -0400
>> >
>> > Merge branch 'release' of
>> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux into
>> > thermal
>> >
>> > unfortunately, I'm not able to successfully do a suspend/resume on the
>> > commits in that merge, so I wasn't able to bisect down to the exact
>> > commit.
>> >
>> > I did confirm that one parent of the merge is okay: commit
>> > 125c4c706b680c7831f0966ff873c1ad0354ec25 idr: rename MAX_LEVEL to
>> > MAX_IDR_LEVEL
>> >
>> > so I think it falls somewhere in this list of commits:
>> > c072fed95c9855a920c114d7fa3351f0f54ea06e...e3f25e6e5836c4790fbe395ff42e241f372d859d
>> >
>> > c072fed9 thermal: Exynos: Fix NULL pointer dereference in
>> > exynos_unregister_thermal()
>> > a4b6fec9 Thermal: Fix bug on cpu_cooling, cooling device's id conflict 
>> > problem.
>> > 79e093c3 thermal: exynos: Use devm_* functions
>> > 17be868e ARM: exynos: add thermal sensor driver platform data support
>> > 7e0b55e6 thermal: exynos: register the tmu sensor with the kernel thermal 
>> > layer
>> > f22d9c03c thermal: exynos5: add exynos5250 thermal sensor driver support
>> > c48cbba6 hwmon: exynos4: move thermal sensor driver to driver/thermal 
>> > directory
>> > 02361418 thermal: add generic cpufreq cooling implementation
>> > a7a3b8c8 Fix a build error.
>> > 204dd1d3 thermal: Fix potential NULL pointer accesses
>> > 1e426ffdd thermal: add Renesas R-Car thermal sensor support
>> > 79a49168 thermal: fix potential out-of-bounds memory access
>> > f4a821ce6 Thermal: Introduce locking for cdev.thermal_instances list.
>> > 908b9fb79 Thermal: Unify the code for both active and passive cooling
>> > ce119f832 Thermal: Introduce simple arbitrator for setting device cooling 
>> > state
>> > b5e4ae62 Thermal: List thermal_instance in thermal_cooling_device.
>> > cddf31b3b Thermal: Rename thermal_instance.node to 
>> > thermal_instance.tz_node.
>> > 2d374139 Thermal: Rename thermal_zone_device.cooling_devices
>> > b81b6ba3 Thermal: rename structure thermal_cooling_device_instance to
>> > thermal_instance
>> > 4ae46befb Thermal: Introduce thermal_zone_trip_update()
>> > 1b7ddb84 Thermal: Remove tc1/tc2 in generic thermal layer.
>> > 601f3d424 Thermal: Introduce .get_trend() callback.
>> > 9d99842f9 Thermal: set upper and lower limits
>> > 74051ba5 Thermal: Introduce cooling states range support
>> >
>> > When I get time, I'll try to rebase those commits onto the IDR commit
>> > and see if I can get a better bisect.  Any insights into the problem
>> > would be appreciated, thanks.
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
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: Fans at full speed after resume

[Olof Johansson]

2013/5/14 Zhang Rui 
>
> On Wed, 2013-05-15 at 12:26 +0800, Zhang Rui wrote:
> > please
> >
> > On Tue, 2013-05-14 at 21:18 -0700, Sonny Rao wrote:
> > > Hi, I've seen a regression in kernels since 3.7 on x86 devices where
> > > the kernel turns the system fans on to max speed after resuming from
> > > ram.  Other people have noticed it as well, for example see
> > > https://bugzilla.redhat.com/show_bug.cgi?id=895276
> > >
> > please check if this is a duplicate of bug
> > https://bugzilla.kernel.org/show_bug.cgi?id=56591
> or you can try 3.10-rc1 to see if the problem still exists or not.
>

Or 3.8.12, from the looks of it (we're on 3.8.11 now, d'oh!).

-Olof
--
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: Fans at full speed after resume

[Zhang Rui]

On Wed, 2013-05-15 at 12:26 +0800, Zhang Rui wrote:
> please
> 
> On Tue, 2013-05-14 at 21:18 -0700, Sonny Rao wrote:
> > Hi, I've seen a regression in kernels since 3.7 on x86 devices where
> > the kernel turns the system fans on to max speed after resuming from
> > ram.  Other people have noticed it as well, for example see
> > https://bugzilla.redhat.com/show_bug.cgi?id=895276
> > 
> please check if this is a duplicate of bug
> https://bugzilla.kernel.org/show_bug.cgi?id=56591
or you can try 3.10-rc1 to see if the problem still exists or not.

thanks,
rui
> > For example on the Samsung 550 Chromebook, we have one thermal zone
> > and have 5 cooling_devices, 0-4, which correspond to 5 possible fan
> > speeds.  Under typical idle, only cooling_device4 and maybe
> > cooling_device3 are active, depending on temperature:
> > 
> > cat /sys/class/thermal/cooling_device[01234]/cur_state
> > /sys/class/thermal/thermal_zone0/temp
> > 0
> > 0
> > 0
> > 0
> > 1
> > 57000
> > 
> > however after a suspend/resume, we see that cooling_devices 0 and 1
> > become active:
> > cat /sys/class/thermal/cooling_device[01234]/cur_state
> > /sys/class/thermal/thermal_zone0/temp
> > 1
> > 1
> > 0
> > 0
> > 1
> > 54000
> > 
> > and it seems to stay that way, even though the temperature is low
> > enough that the fan shouldn't be running at that speed.  If I manually
> > disable cooling_devices 0 and 1 then fan control works normally again.
> > 
> > I started bisecting it and was able to do so up until this commit:
> > commit 29b19e250434c6193c8b8e4c34c9c6284dd4f101
> > Merge: 125c4c7 c072fed
> > Author: Len Brown 
> > AuthorDate: Tue Oct 9 01:35:52 2012 -0400
> > Commit: Len Brown 
> > CommitDate: Tue Oct 9 01:35:52 2012 -0400
> > 
> > Merge branch 'release' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux into
> > thermal
> > 
> > unfortunately, I'm not able to successfully do a suspend/resume on the
> > commits in that merge, so I wasn't able to bisect down to the exact
> > commit.
> > 
> > I did confirm that one parent of the merge is okay: commit
> > 125c4c706b680c7831f0966ff873c1ad0354ec25 idr: rename MAX_LEVEL to
> > MAX_IDR_LEVEL
> > 
> > so I think it falls somewhere in this list of commits:
> > c072fed95c9855a920c114d7fa3351f0f54ea06e...e3f25e6e5836c4790fbe395ff42e241f372d859d
> > 
> > c072fed9 thermal: Exynos: Fix NULL pointer dereference in
> > exynos_unregister_thermal()
> > a4b6fec9 Thermal: Fix bug on cpu_cooling, cooling device's id conflict 
> > problem.
> > 79e093c3 thermal: exynos: Use devm_* functions
> > 17be868e ARM: exynos: add thermal sensor driver platform data support
> > 7e0b55e6 thermal: exynos: register the tmu sensor with the kernel thermal 
> > layer
> > f22d9c03c thermal: exynos5: add exynos5250 thermal sensor driver support
> > c48cbba6 hwmon: exynos4: move thermal sensor driver to driver/thermal 
> > directory
> > 02361418 thermal: add generic cpufreq cooling implementation
> > a7a3b8c8 Fix a build error.
> > 204dd1d3 thermal: Fix potential NULL pointer accesses
> > 1e426ffdd thermal: add Renesas R-Car thermal sensor support
> > 79a49168 thermal: fix potential out-of-bounds memory access
> > f4a821ce6 Thermal: Introduce locking for cdev.thermal_instances list.
> > 908b9fb79 Thermal: Unify the code for both active and passive cooling
> > ce119f832 Thermal: Introduce simple arbitrator for setting device cooling 
> > state
> > b5e4ae62 Thermal: List thermal_instance in thermal_cooling_device.
> > cddf31b3b Thermal: Rename thermal_instance.node to thermal_instance.tz_node.
> > 2d374139 Thermal: Rename thermal_zone_device.cooling_devices
> > b81b6ba3 Thermal: rename structure thermal_cooling_device_instance to
> > thermal_instance
> > 4ae46befb Thermal: Introduce thermal_zone_trip_update()
> > 1b7ddb84 Thermal: Remove tc1/tc2 in generic thermal layer.
> > 601f3d424 Thermal: Introduce .get_trend() callback.
> > 9d99842f9 Thermal: set upper and lower limits
> > 74051ba5 Thermal: Introduce cooling states range support
> > 
> > When I get time, I'll try to rebase those commits onto the IDR commit
> > and see if I can get a better bisect.  Any insights into the problem
> > would be appreciated, thanks.
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
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: Fans at full speed after resume

[Zhang Rui]

please

On Tue, 2013-05-14 at 21:18 -0700, Sonny Rao wrote:
> Hi, I've seen a regression in kernels since 3.7 on x86 devices where
> the kernel turns the system fans on to max speed after resuming from
> ram.  Other people have noticed it as well, for example see
> https://bugzilla.redhat.com/show_bug.cgi?id=895276
> 
please check if this is a duplicate of bug
https://bugzilla.kernel.org/show_bug.cgi?id=56591
> For example on the Samsung 550 Chromebook, we have one thermal zone
> and have 5 cooling_devices, 0-4, which correspond to 5 possible fan
> speeds.  Under typical idle, only cooling_device4 and maybe
> cooling_device3 are active, depending on temperature:
> 
> cat /sys/class/thermal/cooling_device[01234]/cur_state
> /sys/class/thermal/thermal_zone0/temp
> 0
> 0
> 0
> 0
> 1
> 57000
> 
> however after a suspend/resume, we see that cooling_devices 0 and 1
> become active:
> cat /sys/class/thermal/cooling_device[01234]/cur_state
> /sys/class/thermal/thermal_zone0/temp
> 1
> 1
> 0
> 0
> 1
> 54000
> 
> and it seems to stay that way, even though the temperature is low
> enough that the fan shouldn't be running at that speed.  If I manually
> disable cooling_devices 0 and 1 then fan control works normally again.
> 
> I started bisecting it and was able to do so up until this commit:
> commit 29b19e250434c6193c8b8e4c34c9c6284dd4f101
> Merge: 125c4c7 c072fed
> Author: Len Brown 
> AuthorDate: Tue Oct 9 01:35:52 2012 -0400
> Commit: Len Brown 
> CommitDate: Tue Oct 9 01:35:52 2012 -0400
> 
> Merge branch 'release' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux into
> thermal
> 
> unfortunately, I'm not able to successfully do a suspend/resume on the
> commits in that merge, so I wasn't able to bisect down to the exact
> commit.
> 
> I did confirm that one parent of the merge is okay: commit
> 125c4c706b680c7831f0966ff873c1ad0354ec25 idr: rename MAX_LEVEL to
> MAX_IDR_LEVEL
> 
> so I think it falls somewhere in this list of commits:
> c072fed95c9855a920c114d7fa3351f0f54ea06e...e3f25e6e5836c4790fbe395ff42e241f372d859d
> 
> c072fed9 thermal: Exynos: Fix NULL pointer dereference in
> exynos_unregister_thermal()
> a4b6fec9 Thermal: Fix bug on cpu_cooling, cooling device's id conflict 
> problem.
> 79e093c3 thermal: exynos: Use devm_* functions
> 17be868e ARM: exynos: add thermal sensor driver platform data support
> 7e0b55e6 thermal: exynos: register the tmu sensor with the kernel thermal 
> layer
> f22d9c03c thermal: exynos5: add exynos5250 thermal sensor driver support
> c48cbba6 hwmon: exynos4: move thermal sensor driver to driver/thermal 
> directory
> 02361418 thermal: add generic cpufreq cooling implementation
> a7a3b8c8 Fix a build error.
> 204dd1d3 thermal: Fix potential NULL pointer accesses
> 1e426ffdd thermal: add Renesas R-Car thermal sensor support
> 79a49168 thermal: fix potential out-of-bounds memory access
> f4a821ce6 Thermal: Introduce locking for cdev.thermal_instances list.
> 908b9fb79 Thermal: Unify the code for both active and passive cooling
> ce119f832 Thermal: Introduce simple arbitrator for setting device cooling 
> state
> b5e4ae62 Thermal: List thermal_instance in thermal_cooling_device.
> cddf31b3b Thermal: Rename thermal_instance.node to thermal_instance.tz_node.
> 2d374139 Thermal: Rename thermal_zone_device.cooling_devices
> b81b6ba3 Thermal: rename structure thermal_cooling_device_instance to
> thermal_instance
> 4ae46befb Thermal: Introduce thermal_zone_trip_update()
> 1b7ddb84 Thermal: Remove tc1/tc2 in generic thermal layer.
> 601f3d424 Thermal: Introduce .get_trend() callback.
> 9d99842f9 Thermal: set upper and lower limits
> 74051ba5 Thermal: Introduce cooling states range support
> 
> When I get time, I'll try to rebase those commits onto the IDR commit
> and see if I can get a better bisect.  Any insights into the problem
> would be appreciated, thanks.


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

Fans at full speed after resume

[Sonny Rao]

Hi, I've seen a regression in kernels since 3.7 on x86 devices where
the kernel turns the system fans on to max speed after resuming from
ram.  Other people have noticed it as well, for example see
https://bugzilla.redhat.com/show_bug.cgi?id=895276

For example on the Samsung 550 Chromebook, we have one thermal zone
and have 5 cooling_devices, 0-4, which correspond to 5 possible fan
speeds.  Under typical idle, only cooling_device4 and maybe
cooling_device3 are active, depending on temperature:

cat /sys/class/thermal/cooling_device[01234]/cur_state
/sys/class/thermal/thermal_zone0/temp
0
0
0
0
1
57000

however after a suspend/resume, we see that cooling_devices 0 and 1
become active:
cat /sys/class/thermal/cooling_device[01234]/cur_state
/sys/class/thermal/thermal_zone0/temp
1
1
0
0
1
54000

and it seems to stay that way, even though the temperature is low
enough that the fan shouldn't be running at that speed.  If I manually
disable cooling_devices 0 and 1 then fan control works normally again.

I started bisecting it and was able to do so up until this commit:
commit 29b19e250434c6193c8b8e4c34c9c6284dd4f101
Merge: 125c4c7 c072fed
Author: Len Brown 
AuthorDate: Tue Oct 9 01:35:52 2012 -0400
Commit: Len Brown 
CommitDate: Tue Oct 9 01:35:52 2012 -0400

Merge branch 'release' of
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux into
thermal

unfortunately, I'm not able to successfully do a suspend/resume on the
commits in that merge, so I wasn't able to bisect down to the exact
commit.

I did confirm that one parent of the merge is okay: commit
125c4c706b680c7831f0966ff873c1ad0354ec25 idr: rename MAX_LEVEL to
MAX_IDR_LEVEL

so I think it falls somewhere in this list of commits:
c072fed95c9855a920c114d7fa3351f0f54ea06e...e3f25e6e5836c4790fbe395ff42e241f372d859d

c072fed9 thermal: Exynos: Fix NULL pointer dereference in
exynos_unregister_thermal()
a4b6fec9 Thermal: Fix bug on cpu_cooling, cooling device's id conflict problem.
79e093c3 thermal: exynos: Use devm_* functions
17be868e ARM: exynos: add thermal sensor driver platform data support
7e0b55e6 thermal: exynos: register the tmu sensor with the kernel thermal layer
f22d9c03c thermal: exynos5: add exynos5250 thermal sensor driver support
c48cbba6 hwmon: exynos4: move thermal sensor driver to driver/thermal directory
02361418 thermal: add generic cpufreq cooling implementation
a7a3b8c8 Fix a build error.
204dd1d3 thermal: Fix potential NULL pointer accesses
1e426ffdd thermal: add Renesas R-Car thermal sensor support
79a49168 thermal: fix potential out-of-bounds memory access
f4a821ce6 Thermal: Introduce locking for cdev.thermal_instances list.
908b9fb79 Thermal: Unify the code for both active and passive cooling
ce119f832 Thermal: Introduce simple arbitrator for setting device cooling state
b5e4ae62 Thermal: List thermal_instance in thermal_cooling_device.
cddf31b3b Thermal: Rename thermal_instance.node to thermal_instance.tz_node.
2d374139 Thermal: Rename thermal_zone_device.cooling_devices
b81b6ba3 Thermal: rename structure thermal_cooling_device_instance to
thermal_instance
4ae46befb Thermal: Introduce thermal_zone_trip_update()
1b7ddb84 Thermal: Remove tc1/tc2 in generic thermal layer.
601f3d424 Thermal: Introduce .get_trend() callback.
9d99842f9 Thermal: set upper and lower limits
74051ba5 Thermal: Introduce cooling states range support

When I get time, I'll try to rebase those commits onto the IDR commit
and see if I can get a better bisect.  Any insights into the problem
would be appreciated, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] Kernel/time: Introduce a new timestamp function local_time_seconds()

[Gu Zheng]

On 05/14/2013 11:57 PM, John Stultz wrote:

> On 05/14/2013 12:45 AM, Gu Zheng wrote:
>>  From 18072c1c3506a7e37ee485307a2c343efe5af4d0 Mon Sep 17 00:00:00 2001
>> From: Gu Zheng 
>> Date: Mon, 13 May 2013 15:45:24 +0900
>> Subject: [PATCH 1/2] Kernel/time: Introduce a new timestamp function 
>> local_time_seconds()
>>
>> Introduce a new timestamp function local_time_seconds() to hide the 
>> conversion of system time in UTC to local time seconds.
> 
> So, why is this useful/needed?

Hi John,
   There are some subsystems use local time seconds as a timestamp, such as 
scsi(refer to:http://www.spinics.net/lists/linux-scsi/msg66089.html),
and so do many out-of-kernel-tree code I think.

Best regards,
Gu

> 
> thanks
> -john
> 
> 


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

Re: dynticks: CONFIG_VIRT_CPU_ACCOUNTING + CONFIG_CONTEXT_TRACKING breaks accounting on core2 CPUs only

[Mike Galbraith]

On Wed, 2013-05-15 at 02:26 +0200, Frederic Weisbecker wrote: 
> On Tue, May 14, 2013 at 04:07:20PM +0200, Mike Galbraith wrote:
> > On Tue, 2013-05-14 at 02:57 +0200, Frederic Weisbecker wrote: 
> > > On Sun, May 12, 2013 at 10:17:49AM +0200, Mike Galbraith wrote:
> > > > Greetings,
> > > > 
> > > > Turning on new NO_HZ feature on my Q6600 box in master, I see that tasks
> > > > accrue zero utime/stime.  However, the same exact kernel on E5620 box
> > > > works fine, so it would appear there's a CPU dependency somewhere.
> > > 
> > > Ah indeed, I just managed to reproduce the same issue.
> > > 
> > > > 
> > > > Is core2 expected to go dysfunctional with context tracking enabled?
> > > > CONFIG_VIRT_CPU_ACCOUNTING alone works fine in 3.9-stable, turn on
> > > > CONFIG_CONTEXT_TRACKING_FORCE, and CPU accounting stops working on core2
> > > > boxen only, same exact kernel continues to work just fine on E5620
> > > > (Westmere) box.
> > > 
> > > There was no known issue with core2. The box where I'm seeing the it
> > > is a Phenom quad core that had NR_CPUS=2. May be the issue is more
> > > likely to happen with this low number. I don't know.
> > > 
> > > I'm investigating further.
> > 
> > So with CONFIG_HAVE_UNSTABLE_SCHED_CLOCK, you can't mix sched_clock()
> > (pure tsc) with local_clock()/sched_clock_cpu(cpu).  The former is
> > always quite a bit ahead of the later, so mixing clocks is a nogo on
> > crusty old (but beloved) core2 box.
> 
> Right I have the same issue. So let's use local_clock() everywhere here,
> it takes care of unstable tsc.
> 
> Does the following fix the issue for you?

Yeah, both can use sched_clock_cpu() instead though.

> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index cc2dc3e..1ce322f 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -747,7 +748,7 @@ void arch_vtime_task_switch(struct task_struct *prev)
>  
>   write_seqlock(>vtime_seqlock);
>   current->vtime_snap_whence = VTIME_SYS;
> - current->vtime_snap = sched_clock();
> + current->vtime_snap = local_clock();
>   write_sequnlock(>vtime_seqlock);
>  }
>  
> @@ -757,7 +758,7 @@ void vtime_init_idle(struct task_struct *t)
>  
>   write_seqlock_irqsave(>vtime_seqlock, flags);
>   t->vtime_snap_whence = VTIME_SYS;
> - t->vtime_snap = sched_clock();
> + t->vtime_snap = local_clock();
>   write_sequnlock_irqrestore(>vtime_seqlock, flags);
>  }
>  


--
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] f2fs: fix the inconsistent state of data pages

[Namjae Jeon]

2013/5/15, Jaegeuk Kim :
> In get_lock_data_page, if there is a data race between get_dnode_of_data
> for
> node and grab_cache_page for data, f2fs is able to face with the following
> BUG_ON(dn.data_blkaddr == NEW_ADDR).
>
> kernel BUG at /home/zeus/f2fs_test/src/fs/f2fs/data.c:251!
>  [] get_lock_data_page+0x1ec/0x210 [f2fs]
> Call Trace:
>  [] f2fs_readdir+0x89/0x210 [f2fs]
>  [] ? fillonedir+0x100/0x100
>  [] ? fillonedir+0x100/0x100
>  [] vfs_readdir+0xb8/0xe0
>  [] sys_getdents+0x8f/0x110
>  [] system_call_fastpath+0x16/0x1b
>
> This bug is able to be occurred when the block address of the data block is
> changed after f2fs_put_dnode().
> In order to avoid that, this patch fixes the lock order of node and data
> blocks in which the node block lock is covered by the data block lock.
>
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/data.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 91ff93b..05fb5c6 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -233,18 +233,23 @@ struct page *get_lock_data_page(struct inode *inode,
> pgoff_t index)
>   struct page *page;
>   int err;
>
> +repeat:
> + page = grab_cache_page(mapping, index);
> + if (!page)
> + return ERR_PTR(-ENOMEM);
> +
>   set_new_dnode(, inode, NULL, NULL, 0);
>   err = get_dnode_of_data(, index, LOOKUP_NODE);
> - if (err)
> + if (err) {
> + f2fs_put_page(page, 1);
>   return ERR_PTR(err);
> + }
>   f2fs_put_dnode();
>
> - if (dn.data_blkaddr == NULL_ADDR)
> + if (dn.data_blkaddr == NULL_ADDR) {
> + f2fs_put_page(page, 1);
>   return ERR_PTR(-ENOENT);
> -repeat:
> - page = grab_cache_page(mapping, index);
> - if (!page)
> - return ERR_PTR(-ENOMEM);
> + }
>
>   if (PageUptodate(page))
>   return page;
Is there no need to move PageUptodate condition checking to
grab_cache_page next ?

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

Re: [PATCH] usb: xhci: Consolidate XHCI TD Size calculation

[Sarah Sharp]

On Thu, May 09, 2013 at 09:42:51PM -0700, Julius Werner wrote:
> The TD Size field in an XHCI TRB is calculated in two different ways,
> depending on the XHCI version. The current code does this version check
> in every caller, which makes it easy to forget (such as in the function
> for control transfers, which still erroneously uses the old calculation
> for its data stage TRB). The 1.0 calculation has also been corrected and
> amended several times, growing slightly more complicated than necessary.

Does this patch fix the control transfer data stage issue?  Please break
this into a bug fix for that, with your refactoring on top of that.  We
need to backport the bug fix to the stable kernels, and queue the
refactoring for 3.11.

Sarah Sharp

> 
> This patch moves the XHCI version check into a single, unified (and
> slightly simplified) xhci_td_remainder() function, which deduplicates
> code and looks cleaner in the callers.
> 
> Signed-off-by: Julius Werner 
> ---
>  drivers/usb/host/xhci-ring.c | 111 
> +++
>  1 file changed, 29 insertions(+), 82 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 1969c00..32629b2 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3074,54 +3074,33 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t 
> mem_flags,
>  }
>  
>  /*
> - * The TD size is the number of bytes remaining in the TD (including this 
> TRB),
> - * right shifted by 10.
> - * It must fit in bits 21:17, so it can't be bigger than 31.
> - */
> -static u32 xhci_td_remainder(unsigned int remainder)
> -{
> - u32 max = (1 << (21 - 17 + 1)) - 1;
> -
> - if ((remainder >> 10) >= max)
> - return max << 17;
> - else
> - return (remainder >> 10) << 17;
> -}
> -
> -/*
> - * For xHCI 1.0 host controllers, TD size is the number of max packet sized
> - * packets remaining in the TD (*not* including this TRB).
> - *
> - * Total TD packet count = total_packet_count =
> - * DIV_ROUND_UP(TD size in bytes / wMaxPacketSize)
> + * Calculate the TD Size field of a TRB, shifted to its correct position
> + * in bits 21:17. In pre-1.0 XHCI versions, this field contains the
> + * number of bytes left in the TD, including the current TRB, in kB.
>   *
> - * Packets transferred up to and including this TRB = packets_transferred =
> - * rounddown(total bytes transferred including this TRB / wMaxPacketSize)
> + * In XHCI 1.0, it contains the amount of packets left in the TD,
> + * excluding the current TRB. Even though the spec explains this in a
> + * roundabout way, the end result is just the amount of bytes left after
> + * this TRB divided by the maximum packet size, rounded up. For the last
> + * TRB this is naturally zero since there cannot be any more bytes left.
>   *
> - * TD size = total_packet_count - packets_transferred
> - *
> - * It must fit in bits 21:17, so it can't be bigger than 31.
> - * The last TRB in a TD must have the TD size set to zero.
> + * @running_total:   amount of bytes in the TD before this TRB
> + * @trb_len: amount of bytes in the current TRB
> + * @total_len:   total amount of bytes in the TD
>   */
> -static u32 xhci_v1_0_td_remainder(int running_total, int trb_buff_len,
> - unsigned int total_packet_count, struct urb *urb,
> - unsigned int num_trbs_left)
> +static u32 xhci_td_remainder(int running_total, int trb_len, int total_len,
> + struct urb *urb)
>  {
> - int packets_transferred;
> + u32 result;
>  
> - /* One TRB with a zero-length data packet. */
> - if (num_trbs_left == 0 || (running_total == 0 && trb_buff_len == 0))
> - return 0;
> -
> - /* All the TRB queueing functions don't count the current TRB in
> -  * running_total.
> -  */
> - packets_transferred = (running_total + trb_buff_len) /
> - GET_MAX_PACKET(usb_endpoint_maxp(>ep->desc));
> + if (hcd_to_xhci(bus_to_hcd(urb->dev->bus))->hci_version < 0x100)
> + result = (total_len - running_total) >> 10;
> + else
> + result = DIV_ROUND_UP(total_len - running_total - trb_len,
> + GET_MAX_PACKET(usb_endpoint_maxp(>ep->desc)));
>  
> - if ((total_packet_count - packets_transferred) > 31)
> - return 31 << 17;
> - return (total_packet_count - packets_transferred) << 17;
> + /* TD size field is only 5 bit wide, so cap this at 31 */
> + return min(result, 31u) << 17;
>  }
>  
>  static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
> @@ -3134,7 +3113,6 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, 
> gfp_t mem_flags,
>   struct scatterlist *sg;
>   int num_sgs;
>   int trb_buff_len, this_sg_len, running_total;
> - unsigned int total_packet_count;
>   bool first_trb;
>   u64 addr;
>   bool more_trbs_coming;
> @@ -3148,8 +3126,6 @@ static 

Re: [PATCH 1/2] f2fs: fix inconsistency of block count during recovery

[Namjae Jeon]

>
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 3df43b4..9641534 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1492,6 +1492,8 @@ int recover_inode_page(struct f2fs_sb_info *sbi,
> struct page *page)
>   new_ni = old_ni;
>   new_ni.ino = ino;
>
Hi. Jaegeuk.

I have a minor comment.
> + if (!inc_valid_node_count(sbi, NULL, 1))
> + WARN_ON(1);
How about change WARN_ON(!inc_valid_node_count(sbi, NULL, 1)); ?

Reviewed-by: Namjae Jeon 
Thanks.
>   set_node_addr(sbi, _ni, NEW_ADDR);
>   inc_valid_inode_count(sbi);
>
> --
> 1.8.1.3.566.gaa39828
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
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] target: simplify target_wait_for_sess_cmds()

[Jörn Engel]

On Tue, 14 May 2013 20:05:30 -0700, Nicholas A. Bellinger wrote:
> On Tue, 2013-05-14 at 12:29 -0400, Jörn Engel wrote:
> > On Mon, 13 May 2013 20:08:44 -0700, Nicholas A. Bellinger wrote:
> > > On Mon, 2013-05-13 at 18:00 -0400, Jörn Engel wrote:
> > > > 
> > > > I agree that the overhead doesn't matter.  The msleep(100) spells this
> > > > out rather explicitly.  What does matter is that a) the patch retains
> > > > old behaviour with much simpler code and b) it fixes a race that kills
> > > > the machine.  I can live without a, but very much want to keep b. ;)
> > > 
> > > Fucking around with ->sess_cmd_lock during each loop of ->sess_cmd_list
> > > in target_wait_for_sess_cmds is not simpler code..
> > 
> > I could argue that fucking around with ->sess_cmd_lock during each
> > loop is simpler than the communication through cmd_wait_set and
> > cmd_wait_comp.  But simplicity is ultimately subjective and we can
> > argue all day.
> 
> What I don't like is the endless loop in target_wait_for_sess_cmds()
> that acquires and releases ->sess_cmd_lock for every command, with a
> hard-coded msleep thrown in.

Not for every command.  If the list is empty, it waits exactly 0x.  If
all the commands finish within 100ms, it waits exactly 1x.  Otherwise
it waits for as long as it takes, plus up to 100ms.

I agree this sucks, but the alternative was more code and we got it
wrong.  The old adage is that for every 20 lines of code you add a
bug, and these 32 lines definitely had one.  Which is why I almost
always prefer less code.

There is more to complexity than mere line count.  Your original code
also made it impossible to judge the correctness of the code without
using grep.  My loop is "either the commands eventually all complete,
or we hang forever."  Your loop was "grep for cmd_wait_set, grep for
cmd_wait_comp and check every function that lights up.  Assuming all
of that is correct, either the commands eventually all complete, or we
hang forever."

But if I cannot convince you, I guess we have to live with the bug
as-is.  Telling management that I have to spend another week of my
time and several weeks of testing for a bug that is already fixed is a
hard sell.  And even if I had that much free time and my wife didn't
complain, I don't have the necessary equipment.  So the decision is
yours.  You are the maintainer and have every right to block my patch.

Jörn

--
Modules are evil. They are a security issue, and they encourage a
"distro kernel" approach that takes forever to compile. Just say no.
Build a lean and mean kernel that actually has what you need, and nothing
more. And don't spend stupid time compiling modules you won't need.
-- 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] vhost-scsi: Depend on NET for memcpy_fromiovec

[Asias He]

On Tue, May 14, 2013 at 08:10:20PM -0700, Nicholas A. Bellinger wrote:
> On Wed, 2013-05-15 at 08:59 +0800, Asias He wrote:
> > scsi.c includes vhost.c which uses memcpy_fromiovec.
> > 
> > This patch fixes this build failure.
> > 
> >From Randy Dunlap:
> >'''
> >on x86_64:
> > 
> >ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
> > 
> >It needs to depend on NET since net/core/ provides that function.
> >'''
> > 
> > Reported-by: Randy Dunlap 
> > Signed-off-by: Asias He 
> 
> Hey Asias & MST,
> 
> FYI, I'll be sending a PULL request to Linus in the next couple of days
> for -rc2.
> 
> Let me know if you'd like this to be picked up.

Yes, this is 3.10 material. Sounds good to me.

> --nab
> 
> > ---
> >  drivers/vhost/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > index 8b9226d..0403323 100644
> > --- a/drivers/vhost/Kconfig
> > +++ b/drivers/vhost/Kconfig
> > @@ -12,7 +12,7 @@ config VHOST_NET
> >  
> >  config VHOST_SCSI
> > tristate "VHOST_SCSI TCM fabric driver"
> > -   depends on TARGET_CORE && EVENTFD && m
> > +   depends on NET && TARGET_CORE && EVENTFD && m
> > select VHOST_RING
> > default n
> > ---help---
> 
> 

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

linux-next: Tree for May 15

[Stephen Rothwell]

Hi all,

Changes since 20130514:

I have started doing some builds with gcc 4.8.0 and while I can't easily
tell if I am getting more or less warnings, the ones I do get are now
much more verbose.   This is a hint to people to clean some of them up,
please!



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 225 trees (counting Linus' and 31 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (b973425 Merge tag 'ext4_for_linus_stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4)
Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (f722406 Linux 3.10-rc1)
Merging arc-current/for-curr (85a53d1 ARC: [TB10x] Remove redundant 
abilis,simple-pinctrl mechanism)
Merging arm-current/fixes (6eabb33 ARM: 7720/1: ARM v6/v7 cmpxchg64 shouldn't 
clear upper 32 bits of the old/new value)
Merging m68k-current/for-linus (f722406 Linux 3.10-rc1)
Merging powerpc-merge/merge (e34166a powerpc: Set show_unhandled_signals to 1 
by default)
Merging sparc/master (de9c9f8 Merge tag 'remoteproc-3.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc)
Merging net/master (581df9e net/macb: fix ISR clear-on-write behavior only for 
some SoC)
Merging ipsec/master (da241ef Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (a62ee23 sound: Fix make allmodconfig on MIPS 
correctly)
Merging pci-current/for-linus (e253aaf PCI: Delay final fixups until resources 
are assigned)
Merging wireless/master (ccd384b mwifiex: fix setting of multicast filter)
Merging driver-core.current/driver-core-linus (9affd6b arm: fix mismerge of 
arch/arm/mach-omap2/timer.c)
Merging tty.current/tty-linus (f722406 Linux 3.10-rc1)
Merging usb.current/usb-linus (f722406 Linux 3.10-rc1)
Merging staging.current/staging-linus (c2b62f6 staging: nvec: cleanup childs on 
remove)
Merging char-misc.current/char-misc-linus (f722406 Linux 3.10-rc1)
Merging input-current/for-linus (f0aacea Input: wacom - add a few new styli for 
Cintiq series)
Merging md-current/for-linus (32f9f57 MD: ignore discard request for hard disks 
of hybid raid1/raid10 array)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (286233e crypto: caam - fix inconsistent assoc 
dma mapping direction)
Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe())
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (0d2d0cc spi/davinci: fix module build error)
Merging gpio-current/gpio/merge (e97f9b5 gpio/gpio-ich: fix 
ichx_gpio_check_available() return what callers expect)
Merging rr-fixes/fixes (c1be5a5 Linux 3.9)
Merging mfd-fixes/master (51a26ae Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/dav

linux-next: build warning after merge of the final tree (in Linus' tree)

[Stephen Rothwell]

Hi ,

After merging the final tree, today's linux-next build (i386 defconfig)
produced this warning:

kernel/auditfilter.c: In function 'audit_data_to_entry':
kernel/auditfilter.c:426:3: warning: this decimal constant is unsigned only in 
ISO C90 [enabled by default]

Introduced by commit 780a7654cee8 ("audit: Make testing for a valid
loginuid explicit") from Linus' tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpuFHDZOZrOx.pgp
Description: PGP signature

Re: V3.10-rc1 memory leak

[Larry Finger]

On 05/14/2013 07:57 PM, Steven Rostedt wrote:

On Tue, 2013-05-14 at 17:20 -0400, Steven Rostedt wrote:

On Tue, 2013-05-14 at 16:10 -0500, Larry Finger wrote:

On 05/14/2013 03:30 PM, Catalin Marinas wrote:


I just got a patch today:

https://lkml.org/lkml/2013/5/10/607

which could be related. If Rusty doesn't push it I'll do. But please let
me know if it does not solve the problem.


This patch fixes my problem. Now I can see the next new problem reported by
kmemleak. :)

Thanks to you and Jianpeng Ma,

Larry



It goes away on my testing too. So you can add:

Tested-by: Steven Rostedt 



But we are not out of the woods yet. I'm also getting these:

unreferenced object 0x88007800efc0 (size 32):
   comm "modprobe", pid 1309, jiffies 4294697214 (age 188.356s)
   hex dump (first 32 bytes):
 00 00 00 00 00 00 00 00 a8 d0 3e a0 ff ff ff ff  ..>.
 30 d1 3e a0 ff ff ff ff 00 00 00 00 00 00 00 00  0.>.
   backtrace:
 [] kmemleak_alloc+0x73/0x98
 [] kmemleak_alloc_recursive.constprop.42+0x16/0x18
 [] kmem_cache_alloc_trace+0xc0/0x10b
 [] jump_label_module_notify+0xce/0x1d5
 [] notifier_call_chain+0x37/0x63
 [] __blocking_notifier_call_chain+0x4b/0x60
 [] blocking_notifier_call_chain+0x14/0x16
 [] load_module+0x1d7f/0x20d3
 [] SyS_init_module+0xd9/0xdb
 [] tracesys+0xdd/0xe2
 [] 0x

Where it points to the allocation in jump_label_add_module() where it
allocates the jlm. And this does get freed in jump_label_del_module(). I
put in printks in add_module():

printk("alloc %p (%s)\n", jlm, mod->name);

and in del_module:

printk("free %p (%s)\n", jlm, mod->name);

And got this:

[   29.917577] alloc 88007800efc0 (kvm_intel)


And removing kvm_intel, I got:

[  364.965916] free 88007800efc0 (kvm_intel)


Thus it seems to be yet another false positive :-(


I do not see that particular one; however, I see 4 instances of

unreferenced object 0x8800b7979750 (size 8):
  comm "swapper/0", pid 1, jiffies 4294892402 (age 21888.316s)
  hex dump (first 8 bytes):
31 38 00 b7 00 88 ff ff  18..
  backtrace:
[] kmemleak_alloc+0x21/0x50
[] __kmalloc_track_caller+0x140/0x2b0
[] kstrdup+0x35/0x70
[] acpi_set_pnp_ids+0xd0/0x304
[] acpi_scan_init_hotplug+0x47/0xa1
[] acpi_bus_check_add+0x66/0xd7
[] acpi_ns_walk_namespace+0xb9/0x173
[] acpi_walk_namespace+0x93/0xc6
[] acpi_bus_scan+0x48/0x9a
[] acpi_scan_init+0x57/0x14b
[] acpi_init+0x244/0x286
[] do_one_initcall+0x10a/0x160
[] kernel_init_freeable+0x103/0x192
[] kernel_init+0x9/0xf0
[] ret_from_fork+0x7c/0xb0
[] 0x

All four were allocated early in the bootup, and are the only leaks reported in 
my system. I have not yet tested to see if they are false.


Larry


--
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 v3 3/3] driver: provide sysfs interfaces to access SMX parameter

[Qiaowei Ren]

These interfaces are located in /sys/devices/platform/intel_txt/parameter/,
showing specific parameter information for SMX features supported by
the processor.

Safer Mode Extensions (SMX) provide a processor's programming
interface in an Intel TXT platform for system software to establish
a measured environment within the platform to support trust decisions
by end users.

Signed-off-by: Qiaowei Ren 
Signed-off-by: Xiaoyan Zhang 
Signed-off-by: Gang Wei 
---
 Documentation/ABI/testing/sysfs-platform-intel-txt |   73 ++
 drivers/platform/x86/intel_txt/Makefile|2 +-
 drivers/platform/x86/intel_txt/txt-parameter.c |  254 
 drivers/platform/x86/intel_txt/txt-parameter.h |   39 +++
 drivers/platform/x86/intel_txt/txt-sysfs.c |5 +
 5 files changed, 372 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/x86/intel_txt/txt-parameter.c
 create mode 100644 drivers/platform/x86/intel_txt/txt-parameter.h

diff --git a/Documentation/ABI/testing/sysfs-platform-intel-txt 
b/Documentation/ABI/testing/sysfs-platform-intel-txt
index fa20a9f..b445f5d 100644
--- a/Documentation/ABI/testing/sysfs-platform-intel-txt
+++ b/Documentation/ABI/testing/sysfs-platform-intel-txt
@@ -307,3 +307,76 @@ Contact:   "Qiaowei Ren" 
 Description:   0 = Chipset acknowledges that no secrets are in memory.
1 = Chipset believes that secrets are in memory and will
provide reset protection.
+
+What:  /sys/devices/platform/intel_txt/parameter/
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The parameter/ directory exposes specific parameter
+   information for SMX features supported by the processor.
+
+   Safer Mode Extensions (SMX) provide a processor's
+   programming interface in an Intel TXT platform for
+   system software to establish a measured environment
+   within the platform to support trust decisions by
+   end users.
+
+What:  /sys/devices/platform/intel_txt/parameter/acm_max_size
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The "acm_max_size" property will show max size of
+   authenticated code execution area.
+
+What:  /sys/devices/platform/intel_txt/parameter/acm_mem_types
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The "acm_max_types" property will show supportable memory
+   types for memory mapped outside of the authenticated code
+   execution area.
+
+What:  /sys/devices/platform/intel_txt/parameter/senter_controls
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The "senter_controls" property will show selective SENTER
+   functionality control.
+
+What:  /sys/devices/platform/intel_txt/parameter/preserve_mce
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The "preserve_mce" property produces a '1' if machine
+   check status registers can be preserved through ENTERACCS
+   and SENTER.
+
+What:  /sys/devices/platform/intel_txt/parameter/proc_based_scrtm
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The "proc_based_scrtm" property produces a '1' if this
+   processor implements a processorrooted S-CRTM capability
+   and '0' if not (S-CRTM is rooted in BIOS).
+
+What:  /sys/devices/platform/intel_txt/parameter/n_versions
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The "n_versions" property will show AC module version
+   numbers supported.
+
+What:  /sys/devices/platform/intel_txt/parameter/acm_version
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The "acm_version" property will output supported AC
+   module version, including version comparison mask and
+   version index.
+
+What:  /sys/devices/platform/intel_txt/parameter/acm_version_index
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The "acm_version_index" property allows you to set the
+   version index for output.
diff --git a/drivers/platform/x86/intel_txt/Makefile 
b/drivers/platform/x86/intel_txt/Makefile
index 8d5258e..8370582 100644
--- a/drivers/platform/x86/intel_txt/Makefile
+++ b/drivers/platform/x86/intel_txt/Makefile
@@ -2,4 +2,4 @@
 # Makefile for the intel TXT drivers.
 #
 obj-$(CONFIG_INTEL_TXT_DRIVER) += intel_txt.o
-intel_txt-y := txt-sysfs.o txt-config.o
+intel_txt-y := txt-sysfs.o txt-config.o txt-parameter.o
diff --git a/drivers/platform/x86/intel_txt/txt-parameter.c 
b/drivers/platform/x86/intel_txt/txt-parameter.c
new file mode 100644
index 

[PATCH v3 2/3] driver: provide sysfs interfaces to access TXT config space

[Qiaowei Ren]

These interfaces are located in /sys/devices/platform/intel_txt/config,
and including totally 37 files, providing access to Intel TXT
configuration registers.

Signed-off-by: Qiaowei Ren 
Signed-off-by: Xiaoyan Zhang 
Signed-off-by: Gang Wei 
---
 Documentation/ABI/testing/sysfs-platform-intel-txt |  309 ++
 drivers/platform/x86/intel_txt/Makefile|2 +-
 drivers/platform/x86/intel_txt/txt-config.c| 1029 
 drivers/platform/x86/intel_txt/txt-config.h|  138 +++
 drivers/platform/x86/intel_txt/txt-sysfs.c |   12 +
 5 files changed, 1489 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-txt
 create mode 100644 drivers/platform/x86/intel_txt/txt-config.c
 create mode 100644 drivers/platform/x86/intel_txt/txt-config.h

diff --git a/Documentation/ABI/testing/sysfs-platform-intel-txt 
b/Documentation/ABI/testing/sysfs-platform-intel-txt
new file mode 100644
index 000..fa20a9f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-intel-txt
@@ -0,0 +1,309 @@
+What:  /sys/devices/platform/intel_txt/config/
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The config/ directory exposes Intel TXT configuration
+   registers. These registers are a subset of chipset registers.
+   They are mapped into two regions of memory, representing the
+   public and private configuration spaces.
+
+   Registers in the private space can only be accessed after a
+   measured environment has been established and before the
+   TXT.CMD.CLOSE-PRIVATE command has been issued. The public space
+   registers are available before, during and after a measured
+   environment launch. All registers are available within both
+   spaces, though with different permissions.
+
+What:  /sys/devices/platform/intel_txt/config/STS_raw
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   TXT.STS is the general status register. This read-only register
+   is used by AC modules and the MLE to get the status of various
+   Intel TXT features.
+
+What:  /sys/devices/platform/intel_txt/config/STS_enter_done
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   The chipset sets SENTER.DONE.STS status bit when it sees all
+   of the threads have done an TXT.CYC.SENTER-ACK.
+
+What:  /sys/devices/platform/intel_txt/config/STS_sexit_done
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   SEXIT.DONE.STS status bit is set when all of the bits in the
+   TXT.THREADS.JOIN register are clear. Thus, this bit will be
+   set immediately after reset.
+
+What:  /sys/devices/platform/intel_txt/config/STS_mem_config_lock
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   MEM-CONFIG-LOCK.STS status bit will be set to 1 when the memory
+   configuration has been locked. Cleared by
+   TXT.CMD.UNLOCK.MEMCONFIG or by a system reset.
+
+What:  /sys/devices/platform/intel_txt/config/STS_private_open
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   PRIVATE-OPEN.STS status bit will be set to 1 when
+   TXT.CMD.OPEN-PRIVATE is performed. Cleared by
+   TXT.CMD.CLOSE-PRIVATE or by a system reset.
+
+What:  /sys/devices/platform/intel_txt/config/STS_locality_1_open
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   TXT.LOCALITY1.OPEN.STS status bit is set when the
+   TXT.CMD.OPEN.LOCALITY1 command is seen by the chipset.
+   It is cleared on reset or when TXT.CMD.CLOSE.LOCALITY1 is seen.
+
+What:  /sys/devices/platform/intel_txt/config/STS_locality_2_open
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   TXT.LOCALITY2.OPEN.STS status bit is set when either the
+   TXT.CMD.OPEN.LOCALITY2 command or the TXT.CMD.OPEN.PRIVATE
+   is seen by the chipset. It is cleared on reset, when either
+   TXT.CMD.CLOSE.LOCALITY2 or TXT.CMD.CLOSE.PRIVATE is seen,
+   and by the GETSEC[SEXIT] instruction.
+
+What:  /sys/devices/platform/intel_txt/config/ESTS_raw
+Date:  May 2013
+KernelVersion: 3.9
+Contact:   "Qiaowei Ren" 
+Description:   TXT.ESTS is the error status register which contains status
+   information associated with various error conditions. The
+   contents of this read-only register are preserved across
+   soft resets.
+
+What:  /sys/devices/platform/intel_txt/config/ESTS_intel_txt_reset
+Date:  May 2013
+KernelVersion: 3.9

[PATCH v3 1/3] driver: add TXT driver in kernel

[Qiaowei Ren]

TXT driver can be used to access below resources:
  - TXT config space
  - SMX parameter

Intel TXT (Trusted Execution Technology) will provide higher
assurance of system configuration and initial state as well as
data reset protection. It also helps solve real end user concerns
about having confidence that their hardware is running the VMM
or kernel that it was configured with, especially since they may
be responsible for providing such assurances to VMs and services
running on it.

See Documentation/intel_txt.txt for more information about
Intel TXT.

Intel TXT configuration registers are a subset of chipset registers.
These chipset registers that interact with SMX are accessed from two
regions of memory, which represent the public and private configuration
spaces, by system software using memory read/write protocols.

Safer Mode Extensions (SMX) provide a processor's programming
interface in an Intel TXT platform for system software to establish
a measured environment within the platform to support trust decisions
by end users.

Signed-off-by: Qiaowei Ren 
Signed-off-by: Xiaoyan Zhang 
Signed-off-by: Gang Wei 
---
 drivers/platform/x86/Kconfig   |2 +
 drivers/platform/x86/Makefile  |1 +
 drivers/platform/x86/intel_txt/Kconfig |   27 
 drivers/platform/x86/intel_txt/Makefile|5 +++
 drivers/platform/x86/intel_txt/txt-sysfs.c |   63 
 5 files changed, 98 insertions(+)
 create mode 100644 drivers/platform/x86/intel_txt/Kconfig
 create mode 100644 drivers/platform/x86/intel_txt/Makefile
 create mode 100644 drivers/platform/x86/intel_txt/txt-sysfs.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 8577261..97173e3 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -693,6 +693,8 @@ config INTEL_IPS
  functionality.  If in doubt, say Y here; it will only load on
  supported platforms.
 
+source "drivers/platform/x86/intel_txt/Kconfig"
+
 config IBM_RTL
tristate "Device driver to enable PRTL support"
depends on X86 && PCI
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index ef0ec74..91541ac 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_INTEL_SCU_IPC)   += intel_scu_ipc.o
 obj-$(CONFIG_INTEL_SCU_IPC_UTIL) += intel_scu_ipcutil.o
 obj-$(CONFIG_INTEL_MFLD_THERMAL) += intel_mid_thermal.o
 obj-$(CONFIG_INTEL_IPS)+= intel_ips.o
+obj-$(CONFIG_INTEL_TXT_DRIVER) += intel_txt/
 obj-$(CONFIG_GPIO_INTEL_PMIC)  += intel_pmic_gpio.o
 obj-$(CONFIG_XO1_RFKILL)   += xo1-rfkill.o
 obj-$(CONFIG_XO15_EBOOK)   += xo15-ebook.o
diff --git a/drivers/platform/x86/intel_txt/Kconfig 
b/drivers/platform/x86/intel_txt/Kconfig
new file mode 100644
index 000..dd81b21
--- /dev/null
+++ b/drivers/platform/x86/intel_txt/Kconfig
@@ -0,0 +1,27 @@
+#
+# intel TXT driver configuration
+#
+
+config INTEL_TXT_DRIVER
+   tristate "INTEL TXT sysfs driver"
+   default m
+   depends on INTEL_TXT
+   select SECURITYFS
+   ---help---
+ TXT Driver can be used to access below resources:
+   - TXT config space
+   - SMX parameter
+
+ Intel TXT configuration registers are a subset of chipset
+ registers. These chipset registers that interact with SMX
+ are accessed from two regions of memory, which represent
+ the public and private configuration spaces, by system
+ software using memory read/write protocols.
+
+ Safer Mode Extensions (SMX) provide a processor's programming
+ interface in an Intel TXT platform for system software to
+ establish a measured environment within the platform to support
+ trust decisions by end users.
+
+ To compile this driver as a module, choose M here; the module
+ will be called intel_txt.
diff --git a/drivers/platform/x86/intel_txt/Makefile 
b/drivers/platform/x86/intel_txt/Makefile
new file mode 100644
index 000..a130308
--- /dev/null
+++ b/drivers/platform/x86/intel_txt/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the intel TXT drivers.
+#
+obj-$(CONFIG_INTEL_TXT_DRIVER) += intel_txt.o
+intel_txt-y := txt-sysfs.o
diff --git a/drivers/platform/x86/intel_txt/txt-sysfs.c 
b/drivers/platform/x86/intel_txt/txt-sysfs.c
new file mode 100644
index 000..def33cb
--- /dev/null
+++ b/drivers/platform/x86/intel_txt/txt-sysfs.c
@@ -0,0 +1,63 @@
+/*
+ * txt-sysfs.c
+ *
+ * This module can be used to access below resources
+ *   - TXT config space
+ *   - SMX parameter
+ *
+ * Intel TXT (Trusted Execution Technology) will provide higher
+ * assurance of system configuration and initial state as well as
+ * data reset protection. It also helps solve real end user concerns
+ * about having confidence that their hardware is running the VMM
+ * or kernel that it was configured with, especially since they may
+ * be 

[PATCH v3 0/3] Intel TXT driver

[Qiaowei Ren]

Changeslog from v2:
  * add MODULE_ALIAS() 

Changeslog from v1:
  * remove tboot log code
  * add terms description in commit log and comment at the top of the driver
  * check whether a platform has TXT support before registering a device 

This module is expected to be a better tool to access below resources
  - TXT config space
  - SMX parameter

Intel TXT (Trusted Execution Technology) will provide higher assurance
of system configuration and initial state as well as data reset
protection. It also helps solve real end user concerns about having
confidence that their hardware is running the VMM or kernel that
it was configured with, especially since they may be responsible for
providing such assurances to VMs and services running on it.

See Documentation/intel_txt.txt for more information about Intel TXT.

Intel TXT configuration registers are a subset of chipset registers.
These chipset registers that interact with SMX are accessed from two
regions of memory, which represent the public and private configuration
spaces, by system software using memory read/write protocols.

Safer Mode Extensions (SMX) provide a processor's programming
interface in an Intel TXT platform for system software to establish
a measured environment within the platform to support trust decisions
by end users.

With this module, it will be easier to access TXT related information.

Qiaowei Ren (3):
  driver: add TXT driver in kernel
  driver: provide sysfs interfaces to access TXT config space
  driver: provide sysfs interfaces to access SMX parameter

 Documentation/ABI/testing/sysfs-platform-intel-txt |  382 
 drivers/platform/x86/Kconfig   |2 +
 drivers/platform/x86/Makefile  |1 +
 drivers/platform/x86/intel_txt/Kconfig |   27 +
 drivers/platform/x86/intel_txt/Makefile|5 +
 drivers/platform/x86/intel_txt/txt-config.c| 1029 
 drivers/platform/x86/intel_txt/txt-config.h|  138 +++
 drivers/platform/x86/intel_txt/txt-parameter.c |  254 +
 drivers/platform/x86/intel_txt/txt-parameter.h |   39 +
 drivers/platform/x86/intel_txt/txt-sysfs.c |   80 ++
 10 files changed, 1957 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-txt
 create mode 100644 drivers/platform/x86/intel_txt/Kconfig
 create mode 100644 drivers/platform/x86/intel_txt/Makefile
 create mode 100644 drivers/platform/x86/intel_txt/txt-config.c
 create mode 100644 drivers/platform/x86/intel_txt/txt-config.h
 create mode 100644 drivers/platform/x86/intel_txt/txt-parameter.c
 create mode 100644 drivers/platform/x86/intel_txt/txt-parameter.h
 create mode 100644 drivers/platform/x86/intel_txt/txt-sysfs.c

-- 
1.7.9.5

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

Re: Kernel 3.10-rc1 build warning on 32-bit ppc associated with commit 3925f46

[Larry Finger]

On 05/14/2013 06:33 PM, Benjamin Herrenschmidt wrote:

On Tue, 2013-05-14 at 10:29 -0500, Larry Finger wrote:

Hi,

When building 3.10-rc1 on a PowerBook G4, I get the following warning:


Thanks. Should be fixed now, let me know if it's not.


It is now fixed. Thanks for a quick response.

Larry


--
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] vhost-scsi: Depend on NET for memcpy_fromiovec

[Nicholas A. Bellinger]

On Wed, 2013-05-15 at 08:59 +0800, Asias He wrote:
> scsi.c includes vhost.c which uses memcpy_fromiovec.
> 
> This patch fixes this build failure.
> 
>From Randy Dunlap:
>'''
>on x86_64:
> 
>ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
> 
>It needs to depend on NET since net/core/ provides that function.
>'''
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Asias He 

Hey Asias & MST,

FYI, I'll be sending a PULL request to Linus in the next couple of days
for -rc2.

Let me know if you'd like this to be picked up.

--nab

> ---
>  drivers/vhost/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> index 8b9226d..0403323 100644
> --- a/drivers/vhost/Kconfig
> +++ b/drivers/vhost/Kconfig
> @@ -12,7 +12,7 @@ config VHOST_NET
>  
>  config VHOST_SCSI
>   tristate "VHOST_SCSI TCM fabric driver"
> - depends on TARGET_CORE && EVENTFD && m
> + depends on NET && TARGET_CORE && EVENTFD && m
>   select VHOST_RING
>   default n
>   ---help---


--
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/3] target: close target_put_sess_cmd() vs. core_tmr_abort_task() race v5

[Nicholas A. Bellinger]

On Tue, 2013-05-14 at 15:04 -0400, Greg Kroah-Hartman wrote:
> On Mon, May 13, 2013 at 04:30:06PM -0400, Joern Engel wrote:
> > It is possible for one thread to to take se_sess->sess_cmd_lock in
> > core_tmr_abort_task() before taking a reference count on
> > se_cmd->cmd_kref, while another thread in target_put_sess_cmd() drops
> > se_cmd->cmd_kref before taking se_sess->sess_cmd_lock.
> > 
> > This introduces kref_put_spinlock_irqsave() and uses it in
> > target_put_sess_cmd() to close the race window.
> > 
> > Signed-off-by: Joern Engel 
> 
> For the kref.h part, please feel free to add:
> 
> Acked-by: Greg Kroah-Hartman 

Applied to target-pending/queue

Since this fixes a real long-standing bug within tcm_qla2xxx code, I'm
adding a CC' to stable as well.

Thanks Joern + Greg-KH!

--nab


--
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] target: simplify target_wait_for_sess_cmds()

[Nicholas A. Bellinger]

On Tue, 2013-05-14 at 12:29 -0400, Jörn Engel wrote:
> On Mon, 13 May 2013 20:08:44 -0700, Nicholas A. Bellinger wrote:
> > On Mon, 2013-05-13 at 18:00 -0400, Jörn Engel wrote:
> > > 
> > > I agree that the overhead doesn't matter.  The msleep(100) spells this
> > > out rather explicitly.  What does matter is that a) the patch retains
> > > old behaviour with much simpler code and b) it fixes a race that kills
> > > the machine.  I can live without a, but very much want to keep b. ;)
> > 
> > Fucking around with ->sess_cmd_lock during each loop of ->sess_cmd_list
> > in target_wait_for_sess_cmds is not simpler code..
> 
> I could argue that fucking around with ->sess_cmd_lock during each
> loop is simpler than the communication through cmd_wait_set and
> cmd_wait_comp.  But simplicity is ultimately subjective and we can
> argue all day.
> 

What I don't like is the endless loop in target_wait_for_sess_cmds()
that acquires and releases ->sess_cmd_lock for every command, with a
hard-coded msleep thrown in.

> 
> 
>  drivers/infiniband/ulp/srpt/ib_srpt.c  |2 +-
>  drivers/scsi/qla2xxx/tcm_qla2xxx.c |2 +-
>  drivers/target/target_core_transport.c |   64 
> +---
>  include/target/target_core_base.h  |2 -
>  include/target/target_core_fabric.h|2 +-
>  5 files changed, 20 insertions(+), 52 deletions(-)
> 
> But diffstat is reasonably objective.  Do you really want me to come
> up with an alternative patch that adds code instead of removing it?
> 

What I want is the part of Roland's commit reverted that introduced the
regression, that started you down this particular path of adding
unnecessary locking to target_wait_for_sess_cmds().

And if your using diffstat as a guide, after re-adding the handful of
parts for ->sess_wait_list from commit 1c7b13fe6 plus removing the dead
code in target_wait_for_sess_cmds(), the number of changed lines will
still be a net minus.

--nab

--
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] x86, 64bit: Correct phys_addr in cleanup_highmap comment

[Zhang Yanfei]

For x86_64, we have phys_base, which means the delta between the
the address kernel is actually running at and the address kernel
is compiled to run at. Not phys_addr so correct it.

Signed-off-by: Zhang Yanfei 
---
 arch/x86/mm/init_64.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index bb00c46..b3940b6 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -368,7 +368,7 @@ void __init init_extra_mapping_uc(unsigned long phys, 
unsigned long size)
  *
  *   from __START_KERNEL_map to __START_KERNEL_map + size (== _end-_text)
  *
- * phys_addr holds the negative offset to the kernel, which is added
+ * phys_base holds the negative offset to the kernel, which is added
  * to the compile time generated pmds. This results in invalid pmds up
  * to the point where we hit the physaddr 0 mapping.
  *
-- 
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Build regressions/improvements in v3.10-rc1 (um)

[Stephen Rothwell]

On Mon, 13 May 2013 22:15:52 +1000 Michael Ellerman  
wrote:
>
> On Mon, 2013-05-13 at 12:07 +0200, richard -rw- weinberger wrote:
> > On Mon, May 13, 2013 at 11:54 AM, Michael Ellerman
> >  wrote:
> > >
> > >
> > > Geert Uytterhoeven  wrote:
> > >
> > >>On Sun, May 12, 2013 at 11:17 PM, richard -rw- weinberger
> > >> wrote:
> > >>> On Sun, May 12, 2013 at 10:47 PM, Geert Uytterhoeven
> > >>>  wrote:
> >  On Sun, 12 May 2013, Geert Uytterhoeven wrote:
> > > However, the full list of errors isn't that unmanageable, so I'm
> > >>following
> > > up with a digested list...
> > 
> >  arch/um/drivers/cow_user.c:216: error: implicit declaration of
> > >>function 'htobe32': 1 errors in 1 logs
> >  arch/um/drivers/cow_user.c:249: error: implicit declaration of
> > >>function 'htobe64': 1 errors in 1 logs
> >  arch/um/drivers/cow_user.c:303: error: implicit declaration of
> > >>function 'be32toh': 1 errors in 1 logs
> >  arch/um/drivers/cow_user.c:330: error: implicit declaration of
> > >>function 'be64toh': 1 errors in 1 logs
> >  v3.10-rc1/um-i386/um-defconfig
> >  Old host environment on kissb?
> > >>>
> > >>> This really looks like a host environment issue.
> > >>> PTRACE_O_TRACESYSGOOD for example is defined in
> > >>/usr/include/linux/ptrace.h
> > >>
> > >>Yep, just like e.g. htobe32().
> > >>
> > >>Michael, Stephen: Any chance this can be fixed?
> > >
> > > Possibly. We're cross compiling these on powerpc so perhaps we need to 
> > > update the cross compiler.
> > 
> > Looks like you are the first man on planet earth who tries do build
> > UML/x86 on powerpc. :D
> 
> :)  It has given us some trouble over the years.
> 
> I'll talk to Stephen tomorrow about it and see if we can get it working
> again.

So htobe32 etc were introduced in glibc 2.9 - our build environment is
glibc 2.3 ... Documentation/Changes does not specify a minimum version of
glibc.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpunrYIJ0JCR.pgp
Description: PGP signature

Re: [PATCH] pci: Avoid reentrant calls to work_on_cpu

[Yinghai Lu]

On Tue, May 14, 2013 at 3:26 PM, Alexander Duyck
 wrote:
> This change is meant to fix a deadlock seen when pci_enable_sriov was
> called from within a driver's probe routine.  The issue was that
> work_on_cpu calls flush_work which attempts to flush a work queue for a
> cpu that we are currently working in.  In order to avoid the reentrant
> path we just skip the call to work_on_cpu in the case that the device
> node matches our current node.
>
> Reported-by: Yinghai Lu 
> Signed-off-by: Alexander Duyck 
> ---
>
> This patch is meant to address the issue pointed out in an earlier patch
> sent by Yinghai Lu titled:
>   [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's

Yes, that help. my v2 patch will not need to device schecdule and
device_initicall to wait
first work_on_cpu is done.

Tested-by: Yinghai Lu 

>
>  drivers/pci/pci-driver.c |   14 +-
>  1 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 79277fb..caeb1c0 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -277,12 +277,16 @@ static int pci_call_probe(struct pci_driver *drv, 
> struct pci_dev *dev,
> int error, node;
> struct drv_dev_and_id ddi = { drv, dev, id };
>
> -   /* Execute driver initialization on node where the device's
> -  bus is attached to.  This way the driver likely allocates
> -  its local memory on the right node without any need to
> -  change it. */
> +   /*
> +* Execute driver initialization on the node where the device's
> +* bus is attached.  This way the driver likely allocates
> +* its local memory on the right node without any need to
> +* change it.  If the node is the current node just call
> +* local_pci_probe and avoid the possibility of reentrant
> +* calls to work_on_cpu.
> +*/
> node = dev_to_node(>dev);
> -   if (node >= 0) {
> +   if ((node >= 0) && (node != numa_node_id())) {
> int cpu;
>
> get_online_cpus();
>
--
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 6/7] PCI: Make sure VF's driver get attached after PF's

[Yinghai Lu]

Found kernel try to load mlx4 drivers for VFs before
PF's is loaded when the drivers are built-in, and kernel
command line include probe_vfs=63, num_vfs=63.

[  169.581682] calling  mlx4_init+0x0/0x119 @ 1
[  169.595681] mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011)
[  169.600194] mlx4_core: Initializing :02:00.0
[  169.616322] mlx4_core :02:00.0: Enabling SR-IOV with 63 VFs
[  169.724084] pci :02:00.1: [15b3:1002] type 00 class 0x0c0600
[  169.732442] mlx4_core: Initializing :02:00.1
[  169.734345] mlx4_core :02:00.1: enabling device ( -> 0002)
[  169.747060] mlx4_core :02:00.1: enabling bus mastering
[  169.764283] mlx4_core :02:00.1: Detected virtual function - running in 
slave mode
[  169.767409] mlx4_core :02:00.1: with iommu 3 : domain 11
[  169.785589] mlx4_core :02:00.1: Sending reset
[  179.790131] mlx4_core :02:00.1: Got slave FLRed from Communication 
channel (ret:0x1)
[  181.798661] mlx4_core :02:00.1: slave is currently in themiddle of FLR. 
retrying...(try num:1)
[  181.803336] mlx4_core :02:00.1: Communication channel is not idle.my 
toggle is 1 (cmd:0x0)
...
[  182.078710] mlx4_core :02:00.1: slave is currently in themiddle of FLR. 
retrying...(try num:10)
[  182.096657] mlx4_core :02:00.1: Communication channel is not idle.my 
toggle is 1 (cmd:0x0)
[  182.104935] mlx4_core :02:00.1: slave driver version is not supported by 
the master
[  182.118570] mlx4_core :02:00.1: Communication channel is not idle.my 
toggle is 1 (cmd:0x0)
[  182.138190] mlx4_core :02:00.1: Failed to initialize slave
[  182.141728] mlx4_core: probe of :02:00.1 failed with error -5

It turns that this also happen for hotadd path even drivers are
compiled as modules and if they are loaded. Esp some VF share the
same driver with PF.

calling path:
device driver probe
==> pci_enable_sriov
==> virtfn_add
==> pci_dev_add
==> pci_bus_device_add
when pci_bus_device_add is called, the VF's driver will be attached.
and at that time PF's driver does not finish yet.

Need to move out pci_bus_device_add from virtfn_add and call it
later.

bnx2x and qlcnic are ok, because it does not modules command line
to enable sriov. They must use sysfs to enable it.

be2net is ok, according to Sathya Perla,
he fixed this issue in be2net with the following patch (commit b4c1df93)
  http://marc.info/?l=linux-netdev=136801459808765=2

For igb and ixgbe is ok, as Alex Duyck said:
| The VF driver should be able to be loaded when the PF driver is not
| present.  We handle it in igb and ixgbe last I checked, and I don't see
| any reason why it cannot be handled in all other VF drivers.  I'm not
| saying the VF has to be able to fully functional, but it should be able
| to detect the PF becoming enabled and then bring itself to a fully
| functional state.  To not handle that case is a bug.

Looks like the patch will help enic, mlx4, efx, vxge and lpfc now.

-v2: don't use schedule_callback, and initcall after Alex's patch.
pci: Avoid reentrant calls to work_on_cpu

Signed-off-by: Yinghai Lu 
Cc: Alexander Duyck 
Cc: Yan Burman 
Cc: Sathya Perla 
Cc: net...@vger.kernel.org

---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c|7 ++
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c  |4 +
 drivers/net/ethernet/cisco/enic/enic_main.c  |2 
 drivers/net/ethernet/emulex/benet/be_main.c  |4 +
 drivers/net/ethernet/intel/igb/igb_main.c|   11 +++-
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c|2 
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c   |9 ++-
 drivers/net/ethernet/mellanox/mlx4/main.c|3 +
 drivers/net/ethernet/neterion/vxge/vxge-main.c   |3 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c |5 +-
 drivers/net/ethernet/sfc/efx.c   |1 
 drivers/pci/iov.c|   47 ---
 drivers/scsi/lpfc/lpfc_init.c|2 
 include/linux/pci.h  |4 +
 14 files changed, 90 insertions(+), 14 deletions(-)

Index: linux-2.6/drivers/net/ethernet/mellanox/mlx4/main.c
===
--- linux-2.6.orig/drivers/net/ethernet/mellanox/mlx4/main.c
+++ linux-2.6/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -2308,6 +2308,9 @@ slave_start:
priv->pci_dev_data = pci_dev_data;
pci_set_drvdata(pdev, dev);
 
+   if (dev->flags & MLX4_FLAG_SRIOV)
+   pci_bus_add_device_vfs(pdev);
+
return 0;
 
 err_port:
Index: linux-2.6/drivers/pci/iov.c
===
--- linux-2.6.orig/drivers/pci/iov.c
+++ linux-2.6/drivers/pci/iov.c
@@ -66,7 +66,8 @@ static void virtfn_remove_bus(struct pci

Re: Build regressions/improvements in v3.10-rc1 (um)

[Stephen Rothwell]

Hi all,

On Mon, 13 May 2013 12:20:24 +0200 richard -rw- weinberger 
 wrote:
>
> On Mon, May 13, 2013 at 12:18 PM, Geert Uytterhoeven
>  wrote:
> > On Mon, May 13, 2013 at 12:07 PM, richard -rw- weinberger
> >  wrote:
> >> On Mon, May 13, 2013 at 11:54 AM, Michael Ellerman
> >>  wrote:
> >
> >>> Possibly. We're cross compiling these on powerpc so perhaps we need to 
> >>> update the cross compiler.
> >>
> >> Looks like you are the first man on planet earth who tries do build
> >> UML/x86 on powerpc. :D
> >
> > Well, it used to work: http://kisskb.ellerman.id.au/kisskb/target/2974/
> 
> Cool!

We started getting these PTRACE_ errors on Nov 4, 2011.  Just before
that, we have commit 966e803ab125 ("um: unify ptrace_user.h") which seems
to have lost the include of linux/ptrace.h and now only includes
sys/ptrace.h ...
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpynhEVt3bWF.pgp
Description: PGP signature

Re: [PATCH] kernel/workqueue.c: better to free related resources when failure occurs in wq_numa_init()

[Chen Gang]

On 05/14/2013 11:17 PM, Tejun Heo wrote:
> On Tue, May 14, 2013 at 08:25:20PM +0800, Chen Gang wrote:
>>
>> When NUMA node mapping not available for one cpu, need disabling NUMA
>> support and proceed.
>>
>> Also better to release unused resources (the original code can not
>> cause issue, only waste some memory).
>>
>>
>> Signed-off-by: Chen Gang 
>> ---
>>  kernel/workqueue.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index 1ae6028..a763079 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -4911,6 +4911,9 @@ static void __init wq_numa_init(void)
>>  if (WARN_ON(node == NUMA_NO_NODE)) {
>>  pr_warn("workqueue: NUMA node mapping not available for 
>> cpu%d, disabling NUMA support\n", cpu);
>>  /* happens iff arch is bonkers, let's just proceed */
>> +for_each_node(node)
>> +free_cpumask_var(tbl[node]);
>> +kfree(tbl);
> 
> Eh... let's just leave it alone.  The path is taken iff the whole
> thing is seriously broken and we're triggering WARN.  I don't think we
> need to worry about small memory wastage there.
> 
> Thanks.
> 

OK, I can understand. I will continue to try to find and make another
patches.


Thanks.
-- 
Chen Gang

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

Re: [PATCH V2 1/2] mm: hotplug: implement non-movable version of get_user_pages() called get_user_pages_non_movable()

[Tang Chen]

Hi Benjamin, Mel,

Please see below.

On 05/14/2013 09:58 PM, Benjamin LaHaise wrote:

On Tue, May 14, 2013 at 09:24:58AM +0800, Tang Chen wrote:

Hi Mel, Benjamin, Jeff,

On 05/13/2013 11:01 PM, Benjamin LaHaise wrote:

On Mon, May 13, 2013 at 10:54:03AM -0400, Jeff Moyer wrote:

How do you propose to move the ring pages?


It's the same problem as doing a TLB shootdown: flush the old pages from
userspace's mapping, copy any existing data to the new pages, then
repopulate the page tables.  It will likely require the addition of
address_space_operations for the mapping, but that's not too hard to do.



I think we add migrate_unpin() callback to decrease page->count if
necessary,
and migrate the page to a new page, and add migrate_pin() callback to pin
the new page again.


You can't just decrease the page count for this to work.  The pages are
pinned because aio_complete() can occur at any time and needs to have a
place to write the completion events.  When changing pages, aio has to
take the appropriate lock when changing one page for another.


In aio_complete(),

aio_complete() {
..
spin_lock_irqsave(>completion_lock, flags);
//write the completion event.
spin_unlock_irqrestore(>completion_lock, flags);
..
}

So for this problem, I think we can hold ctx->completion_lock in the aio
callbacks to prevent aio subsystem accessing pages who are being migrated.




The migrate procedure will work just as before. We use callbacks to
decrease
the page->count before migration starts, and increase it when the migration
is done.

And migrate_pin() and migrate_unpin() callbacks will be added to
struct address_space_operations.


I think the existing migratepage operation in address_space_operations can
be used.  Does it get called when hot unplug occurs?  That is: is testing
with the migrate_pages syscall similar enough to the memory removal case?



But as I said, for anonymous pages such as aio ring buffer, they don't have
address_space_operations. So where should we put the callbacks' pointers ?

Add something like address_space_operations to struct anon_vma ?

Thanks. :)






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

Re: [PATCH] ASoC: remove saarb and tavorevb3 machine drivers

[Haojian Zhuang]

On Tue, May 14, 2013 at 11:07 PM, Paul Bolle  wrote:
> Support for PXA95x was removed in v3.8. This means that the Kconfig
> symbols MACH_SAARB and MACH_TAVOREVB3 are no longer available. This
> leaves the SoC Audio support for Marvell Saarb and Marvell Tavor EVB3
> unbuildable. Remove these drivers too.
>
> Signed-off-by: Paul Bolle 

Acked-by: Haojian Zhuang 
--
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] pci: Avoid reentrant calls to work_on_cpu

[Alexander Duyck]

On 05/14/2013 05:32 PM, Or Gerlitz wrote:
> On Tue, May 14, 2013 at 6:26 PM, Alexander Duyck
>  wrote:
>>
>> This change is meant to fix a deadlock seen when pci_enable_sriov was
>> called from within a driver's probe routine.  The issue was that
>> work_on_cpu calls flush_work which attempts to flush a work queue for a
>> cpu that we are currently working in.  In order to avoid the reentrant
>> path we just skip the call to work_on_cpu in the case that the device
>> node matches our current node.
>>
>> Reported-by: Yinghai Lu 
>> Signed-off-by: Alexander Duyck 
>> ---
>>
>> This patch is meant to address the issue pointed out in an earlier patch
>> sent by Yinghai Lu titled:
>>   [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's
>>
>>  drivers/pci/pci-driver.c |   14 +-
>>  1 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>> index 79277fb..caeb1c0 100644
>> --- a/drivers/pci/pci-driver.c
>> +++ b/drivers/pci/pci-driver.c
>> @@ -277,12 +277,16 @@ static int pci_call_probe(struct pci_driver *drv,
>> struct pci_dev *dev,
>> int error, node;
>> struct drv_dev_and_id ddi = { drv, dev, id };
>>
>> -   /* Execute driver initialization on node where the device's
>> -  bus is attached to.  This way the driver likely allocates
>> -  its local memory on the right node without any need to
>> -  change it. */
>> +   /*
>> +* Execute driver initialization on the node where the device's
>> +* bus is attached.  This way the driver likely allocates
>> +* its local memory on the right node without any need to
>> +* change it.  If the node is the current node just call
>> +* local_pci_probe and avoid the possibility of reentrant
>> +* calls to work_on_cpu.
>> +*/
>> node = dev_to_node(>dev);
>> -   if (node >= 0) {
>> +   if ((node >= 0) && (node != numa_node_id())) {
>> int cpu;
>>
>> get_online_cpus();
> 
> 
> Alex, FWIW a similar patch was posted by Michael during the last rc
> cycles of 3.9 see
> http://marc.info/?l=linux-netdev=136569426119644=2

Did his patch ever get applied anywhere?  I don't see it in any of the
trees.

The advantage this approach has over the one in the similar patch is
that this covers a broader set of CPUs since anything on the same node
is local versus just the first CPU in a given NUMA node.

Thanks,

Alex



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

Re: [PATCH 05/20] ARM: shmobile: ape6evm: Remove init_irq declaration in machine description

[Simon Horman]

On Wed, May 15, 2013 at 10:46:04AM +0900, Simon Horman wrote:
> On Wed, May 15, 2013 at 09:59:07AM +0900, Simon Horman wrote:
> > On Tue, May 14, 2013 at 05:38:38PM +0200, Maxime Ripard wrote:
> > > Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> > > specified") removed the need to explictly setup the init_irq field in
> > > the machine description when using only irqchip_init. Remove that
> > > declaration for shmobile as well.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  arch/arm/mach-shmobile/board-ape6evm.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/mach-shmobile/board-ape6evm.c 
> > > b/arch/arm/mach-shmobile/board-ape6evm.c
> > > index 55b8c9f..8dfbdba 100644
> > > --- a/arch/arm/mach-shmobile/board-ape6evm.c
> > > +++ b/arch/arm/mach-shmobile/board-ape6evm.c
> > > @@ -20,7 +20,6 @@
> > >  
> > >  #include 
> > >  #include 
> > > -#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -87,7 +86,6 @@ static const char *ape6evm_boards_compat_dt[] 
> > > __initdata = {
> > >  };
> > >  
> > >  DT_MACHINE_START(APE6EVM_DT, "ape6evm")
> > > - .init_irq   = irqchip_init,
> > >   .init_time  = shmobile_timer_init,
> > >   .init_machine   = ape6evm_add_standard_devices,
> > >   .dt_compat  = ape6evm_boards_compat_dt,
> > 
> > Signed-off-by: Simon Horman 
> 
> Sorry, what I should have said is:
> 
> Queued up for v3.11 in the boards-spe6evm branch of my renesas tree

s/spe6evm/ape6evm/

> on kernel.org. It is included in the renesas-next-20130515 tag of
> that tree and should appear in linux-next in the not to distant future.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
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 11/20] ARM: shmobile: sh73a0: Remove init_irq declaration in machine description

[Simon Horman]

On Tue, May 14, 2013 at 05:38:44PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for shmobile as well.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/mach-shmobile/setup-sh73a0.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c 
> b/arch/arm/mach-shmobile/setup-sh73a0.c
> index fdf3894..73dd75b 100644
> --- a/arch/arm/mach-shmobile/setup-sh73a0.c
> +++ b/arch/arm/mach-shmobile/setup-sh73a0.c
> @@ -22,7 +22,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -1035,7 +1034,6 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened 
> Device Tree)")
>   .map_io = sh73a0_map_io,
>   .init_early = sh73a0_init_delay,
>   .nr_irqs= NR_IRQS_LEGACY,
> - .init_irq   = irqchip_init,
>   .init_machine   = sh73a0_add_standard_devices_dt,
>   .dt_compat  = sh73a0_boards_compat_dt,
>  MACHINE_END

Queued up for v3.11 in the soc-sh73a0 branch of my renesas tree
on kernel.org. It is included in the renesas-next-20130515 tag of
that tree and should appear in linux-next in the not to distant future.

--
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 10/20] ARM: shmobile: r8a7790: Remove init_irq declaration in machine description

[Simon Horman]

On Tue, May 14, 2013 at 05:38:43PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for shmobile as well.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/mach-shmobile/setup-r8a7790.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c 
> b/arch/arm/mach-shmobile/setup-r8a7790.c
> index 49de2d5..2a7a276 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7790.c
> @@ -19,7 +19,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -142,7 +141,6 @@ static const char *r8a7790_boards_compat_dt[] __initdata 
> = {
>  };
>  
>  DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
> - .init_irq   = irqchip_init,
>   .init_machine   = r8a7790_add_standard_devices_dt,
>   .init_time  = r8a7790_timer_init,
>   .dt_compat  = r8a7790_boards_compat_dt,

Queued up for v3.11 in the soc-r8a7790 branch of my renesas tree
on kernel.org. It is included in the renesas-next-20130515 tag of
that tree and should appear in linux-next in the not to distant future.

--
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/20] ARM: shmobile: r8a73a4: Remove init_irq declaration in machine description

[Simon Horman]

On Tue, May 14, 2013 at 05:38:42PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for shmobile as well.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/mach-shmobile/setup-r8a73a4.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c 
> b/arch/arm/mach-shmobile/setup-r8a73a4.c
> index c5a75a7..0b78896 100644
> --- a/arch/arm/mach-shmobile/setup-r8a73a4.c
> +++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
> @@ -18,7 +18,6 @@
>   * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
>   */
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -194,7 +193,6 @@ static const char *r8a73a4_boards_compat_dt[] __initdata 
> = {
>  };
>  
>  DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
> - .init_irq   = irqchip_init,
>   .init_machine   = r8a73a4_add_standard_devices_dt,
>   .init_time  = shmobile_timer_init,
>   .dt_compat  = r8a73a4_boards_compat_dt,

Queued up for v3.11 in the boards-r8a73a4 branch of my renesas tree
on kernel.org. It is included in the renesas-next-20130515 tag of
that tree and should appear in linux-next in the not to distant future.

--
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 08/20] ARM: shmobile: emev2: Remove init_irq declaration in machine description

[Simon Horman]

On Wed, May 15, 2013 at 09:59:38AM +0900, Simon Horman wrote:
> On Tue, May 14, 2013 at 05:38:41PM +0200, Maxime Ripard wrote:
> > Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> > specified") removed the need to explictly setup the init_irq field in
> > the machine description when using only irqchip_init. Remove that
> > declaration for shmobile as well.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  arch/arm/mach-shmobile/setup-emev2.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-shmobile/setup-emev2.c 
> > b/arch/arm/mach-shmobile/setup-emev2.c
> > index 899a86c..66694e0 100644
> > --- a/arch/arm/mach-shmobile/setup-emev2.c
> > +++ b/arch/arm/mach-shmobile/setup-emev2.c
> > @@ -20,7 +20,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -454,7 +453,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 
> > (Flattened Device Tree)")
> > .smp= smp_ops(emev2_smp_ops),
> > .init_early = emev2_init_delay,
> > .nr_irqs= NR_IRQS_LEGACY,
> > -   .init_irq   = irqchip_init,
> > .init_machine   = emev2_add_standard_devices_dt,
> > .dt_compat  = emev2_boards_compat_dt,
> >  MACHINE_END
> 
> Signed-off-by: Simon Horman 

Sorry, what I should have said is:

Queued up for v3.11 in the soc-emev2 branch of my renesas tree
on kernel.org. It is included in the renesas-next-20130515 tag of
that tree and should appear in linux-next in the not to distant future.

--
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 07/20] ARM: shmobile: lager: Remove init_irq declaration in machine description

[Simon Horman]

On Tue, May 14, 2013 at 05:38:40PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for shmobile as well.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/mach-shmobile/board-lager.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-lager.c 
> b/arch/arm/mach-shmobile/board-lager.c
> index f587187..b7488b8 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -19,7 +19,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -39,7 +38,6 @@ static const char *lager_boards_compat_dt[] __initdata = {
>  };
>  
>  DT_MACHINE_START(LAGER_DT, "lager")
> - .init_irq   = irqchip_init,
>   .init_time  = r8a7790_timer_init,
>   .init_machine   = lager_add_standard_devices,
>   .dt_compat  = lager_boards_compat_dt,

Sorry, what I should have said is:

Queued up for v3.11 in the boards-lager branch of my renesas tree
on kernel.org. It is included in the renesas-next-20130515 tag of
that tree and should appear in linux-next in the not to distant future.

--
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/20] ARM: shmobile: kzm9g: Remove init_irq declaration in machine description

[Simon Horman]

On Wed, May 15, 2013 at 09:59:17AM +0900, Simon Horman wrote:
> On Tue, May 14, 2013 at 05:38:39PM +0200, Maxime Ripard wrote:
> > Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> > specified") removed the need to explictly setup the init_irq field in
> > the machine description when using only irqchip_init. Remove that
> > declaration for shmobile as well.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  arch/arm/mach-shmobile/board-kzm9g-reference.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c 
> > b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > index aefa50d..b7ee96e 100644
> > --- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > +++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> > @@ -24,7 +24,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -100,7 +99,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
> > .map_io = sh73a0_map_io,
> > .init_early = sh73a0_init_delay,
> > .nr_irqs= NR_IRQS_LEGACY,
> > -   .init_irq   = irqchip_init,
> > .init_machine   = kzm_init,
> > .init_time  = shmobile_timer_init,
> > .dt_compat  = kzm9g_boards_compat_dt,
> 
> Signed-off-by: Simon Horman 

Sorry, what I should have said is:

Queued up for v3.11 in the boards-kzm9g branch of my renesas tree
on kernel.org. It is included in the renesas-next-20130515 tag of
that tree and should appear in linux-next in the not to distant future.

--
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/20] ARM: shmobile: ape6evm: Remove init_irq declaration in machine description

[Simon Horman]

On Wed, May 15, 2013 at 09:59:07AM +0900, Simon Horman wrote:
> On Tue, May 14, 2013 at 05:38:38PM +0200, Maxime Ripard wrote:
> > Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> > specified") removed the need to explictly setup the init_irq field in
> > the machine description when using only irqchip_init. Remove that
> > declaration for shmobile as well.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  arch/arm/mach-shmobile/board-ape6evm.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-shmobile/board-ape6evm.c 
> > b/arch/arm/mach-shmobile/board-ape6evm.c
> > index 55b8c9f..8dfbdba 100644
> > --- a/arch/arm/mach-shmobile/board-ape6evm.c
> > +++ b/arch/arm/mach-shmobile/board-ape6evm.c
> > @@ -20,7 +20,6 @@
> >  
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -87,7 +86,6 @@ static const char *ape6evm_boards_compat_dt[] __initdata 
> > = {
> >  };
> >  
> >  DT_MACHINE_START(APE6EVM_DT, "ape6evm")
> > -   .init_irq   = irqchip_init,
> > .init_time  = shmobile_timer_init,
> > .init_machine   = ape6evm_add_standard_devices,
> > .dt_compat  = ape6evm_boards_compat_dt,
> 
> Signed-off-by: Simon Horman 

Sorry, what I should have said is:

Queued up for v3.11 in the boards-spe6evm branch of my renesas tree
on kernel.org. It is included in the renesas-next-20130515 tag of
that tree and should appear in linux-next in the not to distant future.

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

Re: [PATCH 1/3] x86/sched/context_tracking: Call new schedule_preempt_user() from entry_64.S

[Li Zhong]

On Tue, 2013-05-14 at 16:13 +0200, Frederic Weisbecker wrote:
> On Fri, May 10, 2013 at 05:12:26PM -0400, Steven Rostedt wrote:
> > +/*
> > + * This is a entry point to the scheduler() just before going
> > + * back to user space. This is called with irqs disabled
> > + * which prevents races with the CONTEXT_TRACKING updates.
> > + */
> > +asmlinkage void __sched schedule_preempt_user(void)
> > +{
> > +   enum ctx_state prev_state;
> > +
> > +   prev_state = exception_enter();
> > +
> > +   local_irq_enable();
> > +   __schedule();
> > +   local_irq_disable();
> > +
> > +   exception_exit(prev_state);
> > +}
> 
> Ok I just had a look at how ARM and PPC64 are handling user preemption and it 
> seems
> that irqs are disabled around the call to schedule() on these archs too. 
> Although
> do_work_pending() in ARM surprisingly doesn't re-enable irqs before calling 
> schedule?
> 
> Anyway having irqs disabled around user preemption seem to be a requirement 
> to make
> sure the TIF_NEED_RESCHED check is not racy against irqs and return to 
> userspace.
> So I guess we can keep the above function as it is.
> 
> But perhaps we should queue this for 3.11 given that it's a bit of a 
> sensitive change
> in the x86 user return path.
> 
> Look, I'm just going to make a seperate pull request with this patch based on 
> 3.10-rc1
> and let Ingo choose the target.

Could the deletion of schedule_user() be separated to another patch. So
for other archs, such as ppc64, we could have both
schedule_preempt_user() and schedule_user() there for the conversion?

Or are there some better ways to avoid the conflict with arch trees? 

Thanks, Zhong

> 
> (Meanwhile I still think it would be a good idea to keep LOCKDEP_SYS_EXIT in 
> the loop :-)
> 
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


--
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] usb: omap2430: fix memleak in err case

[Libo Chen]

when omap_get_control_dev fail, we should release relational platform_device

Signed-off-by: Libo Chen 
---
 drivers/usb/musb/omap2430.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3551f1a..b626f19 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -549,7 +549,8 @@ static int omap2430_probe(struct platform_device *pdev)
glue->control_otghs = omap_get_control_dev();
if (IS_ERR(glue->control_otghs)) {
dev_vdbg(>dev, "Failed to get control device\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err2;
}
} else {
glue->control_otghs = ERR_PTR(-ENODEV);
-- 
1.7.1

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

Re: [PATCH] kernel/workqueue.c: kfree issue, need check flag 'WQ_UNBOUND' when processing failure.

[Chen Gang]

On 05/14/2013 11:20 PM, Tejun Heo wrote:
> On Tue, May 14, 2013 at 09:06:40PM +0800, Chen Gang wrote:
>>  err_destroy:
>>  destroy_workqueue(wq);
>> +if (flags & WQ_UNBOUND) {
>> +err_free_wq:
>> +free_workqueue_attrs(wq->unbound_attrs);
>> +kfree(wq);
>> +}
> 
> Doesn't the above make the code free wq twice on after err_destroy?
> 

Oh, it is my fault. I did not see the put_pwq_unlocked() in details,
next I should read the code carefully.


Thanks.
-- 
Chen Gang

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

NULL pointer dereference in inode_has_perm on 3.4

[Vinson Lee]

Hi.

I'm seeing a NULL pointer deference in inode_has_perm with Linux
kernel 3.4.27. Does anyone have any ideas what this issue might be? As
another point of reference, I've also seen this on 2.6.39.4.

[63314.38] BUG: unable to handle kernel NULL pointer dereference
at 0020
[63314.400270] IP: [] inode_has_perm+0x1b/0x36
[63314.400471] PGD 610cad067 PUD 610cae067 PMD 0
[63314.400635] Oops:  [#1] SMP
[63314.400756] CPU 7
[63314.400821] Modules linked in: ipv6 dm_multipath video sbs sbshc
hed acpi_pad acpi_memhotplug acpi_ipmi parport_pc lp parport tcp_diag
inet_diag ipmi_si ipmi_devintf ipmi_msghandler dell_rbu snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss joydev snd_pcm ioatdma snd_timer snd soundcore
snd_page_alloc igb pcspkr dca dcdbas i2c_i801 shpchp i2c_core iTCO_wdt
i7core_edac iTCO_vendor_support edac_core microcode
[63314.402381]
[63314.402435] Pid: 15274, comm: python2.6 Not tainted 3.4.27 #1 Dell
   C6100   /0D61XP
[63314.402740] RIP: 0010:[]  []
inode_has_perm+0x1b/0x36
[63314.403012] RSP: 0018:88032cba1ba8  EFLAGS: 00010246
[63314.403187] RAX:  RBX: 8805d621ca20 RCX: 88032cba1bb8
[63314.403418] RDX: 0080 RSI: 8805d621ca20 RDI: 8805ee9c1500
[63314.403649] RBP: 88032cba1ba8 R08: 0080 R09: 0080
[63314.403880] R10: 0080 R11: 88032cba1b48 R12: 8805ee9c1500
[63314.404111] R13: 0081 R14:  R15: 880183945b40
[63314.404343] FS:  49bb5940(0063) GS:88063fc6()
knlGS:
[63314.404604] CS:  0010 DS:  ES:  CR0: 80050033
[63314.404791] CR2: 0020 CR3: 000610cac000 CR4: 07e0
[63314.405022] DR0:  DR1:  DR2: 
[63314.405253] DR3:  DR6: 0ff0 DR7: 0400
[63314.405484] Process python2.6 (pid: 15274, threadinfo
88032cba, task 880183945b40)
[63314.405762] Stack:
[63314.405831]  88032cba1c18 81220631 0009

[63314.406096]  8805d621ca20  88032cba1be8
0010
[63314.406359]    88032cba1c48
8805d621ca20
[63314.406623] Call Trace:
[63314.406710]  [] selinux_inode_permission+0x85/0x90
[63314.406920]  [] security_inode_permission+0x1e/0x20
[63314.407133]  [] inode_permission+0xd3/0xdf
[63314.407318]  [] link_path_walk+0x6c/0x4b4
[63314.407503]  [] ? dput+0x2f/0xe2
[63314.407661]  [] ? path_init+0xd4/0x2ea
[63314.407836]  [] path_lookupat+0x59/0x330
[63314.408019]  [] ? kmem_cache_alloc+0x31/0x103
[63314.408212]  [] do_path_lookup+0x28/0xa4
[63314.408393]  [] user_path_at_empty+0x55/0x94
[63314.408586]  [] ? wake_up_state+0x10/0x12
[63314.408772]  [] ? wake_futex+0x64/0x69
[63314.408947]  [] ? futex_wake+0xf0/0x102
[63314.409124]  [] user_path_at+0x11/0x13
[63314.409301]  [] vfs_fstatat+0x42/0x6d
[63314.409473]  [] vfs_stat+0x1b/0x1d
[63314.409636]  [] sys_newstat+0x1f/0x3d
[63314.409812]  [] system_call_fastpath+0x16/0x1b
[63314.410007] Code: fe 48 c7 40 68 07 00 00 00 e8 6c d8 f0 ff c9 c3
55 48 89 e5 66 66 66 66 90 31 c0 41 89 d2 f6 46 0d 02 75 20 48 8b 46
38 45 89 c1 <0f> b7 50 20 8b 70 1c 49 89 c8 48 8b 47 68 44 89 d1 8b 78
04 e8
[63314.410998] RIP  [] inode_has_perm+0x1b/0x36
[63314.411195]  RSP 
[63314.411310] CR2: 0020
[63314.411846] ---[ end trace fa4043a7d7cc37e7 ]---

Cheers,
Vinson
--
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] vhost-scsi: Depend on NET for memcpy_fromiovec

[Asias He]

scsi.c includes vhost.c which uses memcpy_fromiovec.

This patch fixes this build failure.

   From Randy Dunlap:
   '''
   on x86_64:

   ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!

   It needs to depend on NET since net/core/ provides that function.
   '''

Reported-by: Randy Dunlap 
Signed-off-by: Asias He 
---
 drivers/vhost/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 8b9226d..0403323 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -12,7 +12,7 @@ config VHOST_NET
 
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
-   depends on TARGET_CORE && EVENTFD && m
+   depends on NET && TARGET_CORE && EVENTFD && m
select VHOST_RING
default n
---help---
-- 
1.8.1.4

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

Re: [RFC v0 0/4] sys_copy_range() rough draft

[Dave Chinner]

On Tue, May 14, 2013 at 03:04:40PM -0700, Zach Brown wrote:
> On Wed, May 15, 2013 at 07:42:51AM +1000, Dave Chinner wrote:
> > On Tue, May 14, 2013 at 02:15:22PM -0700, Zach Brown wrote:
> > > I'm going to keep hacking away at this.  My next step is to get ext4
> > > supporting .copy_range, probably with a quick hack to copy the
> > > contents of bios.  Hopefully that'll give enough time to also integrate
> > > review feedback.
> > 
> > Wouldn't the easiest "support all filesystems" hack just be to add
> > a destination offset parameter to do_splice_direct() and call that
> > when the filesystem doesn't supply a ->copy_range method? i.e. use
> > the mechanisms we already have for copying from one file to another
> > via the page cache as efficiently as possible?
> 
> Probably; and this in-kernel buffered fallback is particularly desirable
> for nfsd when the exported fs doesn't provide .copy_range.  Having nfsd
> service the COPY op is still a significant win over having the client
> move the data backand forth over the wire.

Sure. That's kind of what I was thinking to make it easy to test and
have widespread support up front.

> But in that quote above I was talking about implementing .copy_range in
> ext4 as though it could use XCOPY today.  I'd like to get a feel for how
> bad it's going to be to juggle the bio XCOPY IO with unwritten extent
> conversion, RMW with overlapping existing blocks, i_size advancing, etc.
> (It's so much like O_DIRECT that I'm already crying a little.)

Toss anything that is hard back to the page cache path. Overlapping
blocks, partial blocks and so can be handled by the slow path
without making the offload path complex.

Make the offload do the simple stuff fast - the mapping and
completion callbacks should be no different to the direct IO bits we
have now, and if you only handle filesystem block aligned ranges in
the offload (rather than sector alignment) most of the grot that DIO
code has to handle goes away

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/

RE: [PATCH] ARM: PL011: add support for extended FIFO-size of PL011-r1p5

[Jongsung Kim]

Stephen Warren  :
> Looking at BCM2835-ARM-Peripherals.pdf (i.e. the public documentation for
> the BCM2835 chip), I see:
>
> =
> The UART provides:
> * Separate 16x8 transmit and 16x12 receive FIFO memory.
> ...
> For the in-depth UART overview, please, refer to the ARM PrimeCell UART
> (PL011) Revision: r1p5 Technical Reference Manual.
> =
>
> That seems to imply that not all r1p5 PL011s actually have a depth-32
FIFO.
> Perhaps this is a configurable property of the IP block, not something
that
> all r1p5 have?

All r1p5 have 32-byte FIFO depth and it's not configurable. From the PL011
TRM:

r1p4-r1p5   Contains the following differences in functionality:
* The receive and transmit FIFOs are increased to a depth of
32.
* The Revision field in the UARTPeriphID2 Register on page
3-24
  bits [7:4] now reads back as 0x3.

--
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 08/20] ARM: shmobile: emev2: Remove init_irq declaration in machine description

[Simon Horman]

On Tue, May 14, 2013 at 05:38:41PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for shmobile as well.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/mach-shmobile/setup-emev2.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/setup-emev2.c 
> b/arch/arm/mach-shmobile/setup-emev2.c
> index 899a86c..66694e0 100644
> --- a/arch/arm/mach-shmobile/setup-emev2.c
> +++ b/arch/arm/mach-shmobile/setup-emev2.c
> @@ -20,7 +20,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -454,7 +453,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 
> (Flattened Device Tree)")
>   .smp= smp_ops(emev2_smp_ops),
>   .init_early = emev2_init_delay,
>   .nr_irqs= NR_IRQS_LEGACY,
> - .init_irq   = irqchip_init,
>   .init_machine   = emev2_add_standard_devices_dt,
>   .dt_compat  = emev2_boards_compat_dt,
>  MACHINE_END

Signed-off-by: Simon Horman 
--
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 07/20] ARM: shmobile: lager: Remove init_irq declaration in machine description

[Simon Horman]

On Tue, May 14, 2013 at 05:38:40PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for shmobile as well.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/mach-shmobile/board-lager.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-lager.c 
> b/arch/arm/mach-shmobile/board-lager.c
> index f587187..b7488b8 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -19,7 +19,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -39,7 +38,6 @@ static const char *lager_boards_compat_dt[] __initdata = {
>  };
>  
>  DT_MACHINE_START(LAGER_DT, "lager")
> - .init_irq   = irqchip_init,
>   .init_time  = r8a7790_timer_init,
>   .init_machine   = lager_add_standard_devices,
>   .dt_compat  = lager_boards_compat_dt,

Signed-off-by: Simon Horman 

--
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/20] ARM: shmobile: kzm9g: Remove init_irq declaration in machine description

[Simon Horman]

On Tue, May 14, 2013 at 05:38:39PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for shmobile as well.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/mach-shmobile/board-kzm9g-reference.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c 
> b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> index aefa50d..b7ee96e 100644
> --- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
> +++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
> @@ -24,7 +24,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -100,7 +99,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
>   .map_io = sh73a0_map_io,
>   .init_early = sh73a0_init_delay,
>   .nr_irqs= NR_IRQS_LEGACY,
> - .init_irq   = irqchip_init,
>   .init_machine   = kzm_init,
>   .init_time  = shmobile_timer_init,
>   .dt_compat  = kzm9g_boards_compat_dt,

Signed-off-by: Simon Horman 

--
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/20] ARM: shmobile: ape6evm: Remove init_irq declaration in machine description

[Simon Horman]

On Tue, May 14, 2013 at 05:38:38PM +0200, Maxime Ripard wrote:
> Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
> specified") removed the need to explictly setup the init_irq field in
> the machine description when using only irqchip_init. Remove that
> declaration for shmobile as well.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm/mach-shmobile/board-ape6evm.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/board-ape6evm.c 
> b/arch/arm/mach-shmobile/board-ape6evm.c
> index 55b8c9f..8dfbdba 100644
> --- a/arch/arm/mach-shmobile/board-ape6evm.c
> +++ b/arch/arm/mach-shmobile/board-ape6evm.c
> @@ -20,7 +20,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -87,7 +86,6 @@ static const char *ape6evm_boards_compat_dt[] __initdata = {
>  };
>  
>  DT_MACHINE_START(APE6EVM_DT, "ape6evm")
> - .init_irq   = irqchip_init,
>   .init_time  = shmobile_timer_init,
>   .init_machine   = ape6evm_add_standard_devices,
>   .dt_compat  = ape6evm_boards_compat_dt,

Signed-off-by: Simon Horman 

--
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: V3.10-rc1 memory leak

[Steven Rostedt]

On Tue, 2013-05-14 at 17:20 -0400, Steven Rostedt wrote:
> On Tue, 2013-05-14 at 16:10 -0500, Larry Finger wrote:
> > On 05/14/2013 03:30 PM, Catalin Marinas wrote:
> > >
> > > I just got a patch today:
> > >
> > > https://lkml.org/lkml/2013/5/10/607
> > >
> > > which could be related. If Rusty doesn't push it I'll do. But please let
> > > me know if it does not solve the problem.
> > 
> > This patch fixes my problem. Now I can see the next new problem reported by 
> > kmemleak. :)
> > 
> > Thanks to you and Jianpeng Ma,
> > 
> > Larry
> > 
> 
> It goes away on my testing too. So you can add:
> 
> Tested-by: Steven Rostedt 
> 

But we are not out of the woods yet. I'm also getting these:

unreferenced object 0x88007800efc0 (size 32):
  comm "modprobe", pid 1309, jiffies 4294697214 (age 188.356s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 a8 d0 3e a0 ff ff ff ff  ..>.
30 d1 3e a0 ff ff ff ff 00 00 00 00 00 00 00 00  0.>.
  backtrace:
[] kmemleak_alloc+0x73/0x98
[] kmemleak_alloc_recursive.constprop.42+0x16/0x18
[] kmem_cache_alloc_trace+0xc0/0x10b
[] jump_label_module_notify+0xce/0x1d5
[] notifier_call_chain+0x37/0x63
[] __blocking_notifier_call_chain+0x4b/0x60
[] blocking_notifier_call_chain+0x14/0x16
[] load_module+0x1d7f/0x20d3
[] SyS_init_module+0xd9/0xdb
[] tracesys+0xdd/0xe2
[] 0x

Where it points to the allocation in jump_label_add_module() where it
allocates the jlm. And this does get freed in jump_label_del_module(). I
put in printks in add_module():

printk("alloc %p (%s)\n", jlm, mod->name);

and in del_module:

printk("free %p (%s)\n", jlm, mod->name);

And got this:

[   29.917577] alloc 88007800efc0 (kvm_intel)


And removing kvm_intel, I got:

[  364.965916] free 88007800efc0 (kvm_intel)


Thus it seems to be yet another false positive :-(

-- Steve


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

Re: [RFC PATCH v2, part 2 09/18] PCI, PPC: use hotplug-safe iterators to walk PCI buses

[Benjamin Herrenschmidt]

On Wed, 2013-05-15 at 00:51 +0800, Jiang Liu wrote:
> Enhance PPC architecture specific code to use hotplug-safe iterators
> to walk PCI buses.

I was about to ack it but then I saw:

> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> index 51a133a..a41c6dd 100644
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
> @@ -208,7 +208,6 @@ long sys_pciconfig_iobase(long which, unsigned long 
> in_bus,
> unsigned long in_devfn)
>  {
>   struct pci_controller* hose;
> - struct list_head *ln;
>   struct pci_bus *bus = NULL;
>   struct device_node *hose_node;
>  
> @@ -229,18 +228,16 @@ long sys_pciconfig_iobase(long which, unsigned long 
> in_bus,
>   /* That syscall isn't quite compatible with PCI domains, but it's
>* used on pre-domains setup. We return the first match
>*/
> -
> - for (ln = pci_root_buses.next; ln != _root_buses; ln = ln->next) {
> - bus = pci_bus_b(ln);
> - if (in_bus >= bus->number && in_bus <= bus->busn_res.end)
> + for_each_pci_root_bus(bus)
> + if (in_bus >= bus->number && in_bus <= bus->busn_res.end &&
> + bus->dev.of_node)
>   break;
> - bus = NULL;
> - }
> - if (bus == NULL || bus->dev.of_node == NULL)
> + if (bus == NULL)
>   return -ENODEV;

You just removed the NULL check for the of_node field...
 
>   hose_node = bus->dev.of_node;
>   hose = PCI_DN(hose_node)->phb;

Which is dereferrenced here.

> + pci_bus_put(bus);

On the other hand, the whole thing can probably be using
pci_bus_to_host() instead the above code is bitrotted.

>   switch (which) {
>   case IOBASE_BRIDGE_NUMBER:
 
Cheeers,
Ben.


--
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, part4 31/41] mm/ppc: prepare for removing num_physpages and simplify mem_init()

[Benjamin Herrenschmidt]

On Wed, 2013-05-08 at 23:51 +0800, Jiang Liu wrote:
> Prepare for removing num_physpages and simplify mem_init().

No objection, I haven't had a chance to actually build/boot test though.

BTW. A recommended way of doing so which is pretty easy even if you
don't have access to powerpc hardware nowadays is to use
qemu-system-ppc64 with -M pseries.

You can find cross compilers for the kernel on kernel.org and you can
feed qemu with some distro installer ISO.

Cheers,
Ben.

> Signed-off-by: Jiang Liu 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/powerpc/mm/mem.c |   56 
> +++--
>  1 file changed, 12 insertions(+), 44 deletions(-)
> 
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index b890245..4e24f1c 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -299,46 +299,27 @@ void __init paging_init(void)
>  
>  void __init mem_init(void)
>  {
> -#ifdef CONFIG_NEED_MULTIPLE_NODES
> - int nid;
> -#endif
> - pg_data_t *pgdat;
> - unsigned long i;
> - struct page *page;
> - unsigned long reservedpages = 0, codesize, initsize, datasize, bsssize;
> -
>  #ifdef CONFIG_SWIOTLB
>   swiotlb_init(0);
>  #endif
>  
> - num_physpages = memblock_phys_mem_size() >> PAGE_SHIFT;
>   high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
>  
>  #ifdef CONFIG_NEED_MULTIPLE_NODES
> -for_each_online_node(nid) {
> - if (NODE_DATA(nid)->node_spanned_pages != 0) {
> - printk("freeing bootmem node %d\n", nid);
> - free_all_bootmem_node(NODE_DATA(nid));
> - }
> + {
> + pg_data_t *pgdat;
> +
> + for_each_online_pgdat(pgdat)
> + if (pgdat->node_spanned_pages != 0) {
> + printk("freeing bootmem node %d\n",
> + pgdat->node_id);
> + free_all_bootmem_node(pgdat);
> + }
>   }
>  #else
>   max_mapnr = max_pfn;
>   free_all_bootmem();
>  #endif
> - for_each_online_pgdat(pgdat) {
> - for (i = 0; i < pgdat->node_spanned_pages; i++) {
> - if (!pfn_valid(pgdat->node_start_pfn + i))
> - continue;
> - page = pgdat_page_nr(pgdat, i);
> - if (PageReserved(page))
> - reservedpages++;
> - }
> - }
> -
> - codesize = (unsigned long)&_sdata - (unsigned long)&_stext;
> - datasize = (unsigned long)&_edata - (unsigned long)&_sdata;
> - initsize = (unsigned long)&__init_end - (unsigned long)&__init_begin;
> - bsssize = (unsigned long)&__bss_stop - (unsigned long)&__bss_start;
>  
>  #ifdef CONFIG_HIGHMEM
>   {
> @@ -348,13 +329,9 @@ void __init mem_init(void)
>   for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
>   phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT;
>   struct page *page = pfn_to_page(pfn);
> - if (memblock_is_reserved(paddr))
> - continue;
> - free_highmem_page(page);
> - reservedpages--;
> + if (!memblock_is_reserved(paddr))
> + free_highmem_page(page);
>   }
> - printk(KERN_DEBUG "High memory: %luk\n",
> -totalhigh_pages << (PAGE_SHIFT-10));
>   }
>  #endif /* CONFIG_HIGHMEM */
>  
> @@ -367,16 +344,7 @@ void __init mem_init(void)
>   (mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) - 1;
>  #endif
>  
> - printk(KERN_INFO "Memory: %luk/%luk available (%luk kernel code, "
> -"%luk reserved, %luk data, %luk bss, %luk init)\n",
> - nr_free_pages() << (PAGE_SHIFT-10),
> - num_physpages << (PAGE_SHIFT-10),
> - codesize >> 10,
> - reservedpages << (PAGE_SHIFT-10),
> - datasize >> 10,
> - bsssize >> 10,
> - initsize >> 10);
> -
> + mem_init_print_info(NULL);
>  #ifdef CONFIG_PPC32
>   pr_info("Kernel virtual memory layout:\n");
>   pr_info("  * 0x%08lx..0x%08lx  : fixmap\n", FIXADDR_START, FIXADDR_TOP);


--
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] pci: Avoid reentrant calls to work_on_cpu

[Or Gerlitz]

On Tue, May 14, 2013 at 6:26 PM, Alexander Duyck
 wrote:
>
> This change is meant to fix a deadlock seen when pci_enable_sriov was
> called from within a driver's probe routine.  The issue was that
> work_on_cpu calls flush_work which attempts to flush a work queue for a
> cpu that we are currently working in.  In order to avoid the reentrant
> path we just skip the call to work_on_cpu in the case that the device
> node matches our current node.
>
> Reported-by: Yinghai Lu 
> Signed-off-by: Alexander Duyck 
> ---
>
> This patch is meant to address the issue pointed out in an earlier patch
> sent by Yinghai Lu titled:
>   [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's
>
>  drivers/pci/pci-driver.c |   14 +-
>  1 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 79277fb..caeb1c0 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -277,12 +277,16 @@ static int pci_call_probe(struct pci_driver *drv,
> struct pci_dev *dev,
> int error, node;
> struct drv_dev_and_id ddi = { drv, dev, id };
>
> -   /* Execute driver initialization on node where the device's
> -  bus is attached to.  This way the driver likely allocates
> -  its local memory on the right node without any need to
> -  change it. */
> +   /*
> +* Execute driver initialization on the node where the device's
> +* bus is attached.  This way the driver likely allocates
> +* its local memory on the right node without any need to
> +* change it.  If the node is the current node just call
> +* local_pci_probe and avoid the possibility of reentrant
> +* calls to work_on_cpu.
> +*/
> node = dev_to_node(>dev);
> -   if (node >= 0) {
> +   if ((node >= 0) && (node != numa_node_id())) {
> int cpu;
>
> get_online_cpus();


Alex, FWIW a similar patch was posted by Michael during the last rc
cycles of 3.9 see
http://marc.info/?l=linux-netdev=136569426119644=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: dynticks: CONFIG_VIRT_CPU_ACCOUNTING + CONFIG_CONTEXT_TRACKING breaks accounting on core2 CPUs only

[Frederic Weisbecker]

On Tue, May 14, 2013 at 04:07:20PM +0200, Mike Galbraith wrote:
> On Tue, 2013-05-14 at 02:57 +0200, Frederic Weisbecker wrote: 
> > On Sun, May 12, 2013 at 10:17:49AM +0200, Mike Galbraith wrote:
> > > Greetings,
> > > 
> > > Turning on new NO_HZ feature on my Q6600 box in master, I see that tasks
> > > accrue zero utime/stime.  However, the same exact kernel on E5620 box
> > > works fine, so it would appear there's a CPU dependency somewhere.
> > 
> > Ah indeed, I just managed to reproduce the same issue.
> > 
> > > 
> > > Is core2 expected to go dysfunctional with context tracking enabled?
> > > CONFIG_VIRT_CPU_ACCOUNTING alone works fine in 3.9-stable, turn on
> > > CONFIG_CONTEXT_TRACKING_FORCE, and CPU accounting stops working on core2
> > > boxen only, same exact kernel continues to work just fine on E5620
> > > (Westmere) box.
> > 
> > There was no known issue with core2. The box where I'm seeing the it
> > is a Phenom quad core that had NR_CPUS=2. May be the issue is more
> > likely to happen with this low number. I don't know.
> > 
> > I'm investigating further.
> 
> So with CONFIG_HAVE_UNSTABLE_SCHED_CLOCK, you can't mix sched_clock()
> (pure tsc) with local_clock()/sched_clock_cpu(cpu).  The former is
> always quite a bit ahead of the later, so mixing clocks is a nogo on
> crusty old (but beloved) core2 box.

Right I have the same issue. So let's use local_clock() everywhere here,
it takes care of unstable tsc.

Does the following fix the issue for you?

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index cc2dc3e..1ce322f 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -747,7 +748,7 @@ void arch_vtime_task_switch(struct task_struct *prev)
 
write_seqlock(>vtime_seqlock);
current->vtime_snap_whence = VTIME_SYS;
-   current->vtime_snap = sched_clock();
+   current->vtime_snap = local_clock();
write_sequnlock(>vtime_seqlock);
 }
 
@@ -757,7 +758,7 @@ void vtime_init_idle(struct task_struct *t)
 
write_seqlock_irqsave(>vtime_seqlock, flags);
t->vtime_snap_whence = VTIME_SYS;
-   t->vtime_snap = sched_clock();
+   t->vtime_snap = local_clock();
write_sequnlock_irqrestore(>vtime_seqlock, flags);
 }
 
--
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] clk: Fix race condition between clk_set_parent and clk_enable()

[Tomasz Figa]

On Tuesday 14 of May 2013 15:46:33 Saravana Kannan wrote:
> On 05/14/2013 03:10 PM, Tomasz Figa wrote:
> > Hi,
> > 
> > On Tuesday 14 of May 2013 11:54:17 Mike Turquette wrote:
> >> Quoting Saravana Kannan (2013-04-30 21:42:08)
> >> 
> >>> Without this patch, the following race conditions are possible.
> >>> 
> >>> Race condition 1:
> >>> * clk-A has two parents - clk-X and clk-Y.
> >>> * All three are disabled and clk-X is current parent.
> >>> * Thread A: clk_set_parent(clk-A, clk-Y).
> >>> * Thread A: 
> >>> * Thread A: Grabs enable lock.
> >>> * Thread A: Sees enable count of clk-A is 0, so doesn't enable
> >>> clk-Y.
> >>> * Thread A: Updates clk-A SW parent to clk-Y
> >>> * Thread A: Releases enable lock.
> >>> * Thread B: clk_enable(clk-A).
> >>> * Thread B: clk_enable() enables clk-Y, then enabled clk-A and
> >>> returns.
> >>> 
> >>> clk-A is now enabled in software, but not clocking in hardware since
> >>> the hardware parent is still clk-X.
> >>> 
> >>> The only way to avoid race conditions between clk_set_parent() and
> >>> clk_enable/disable() is to ensure that clk_enable/disable() calls
> >>> don't
> >>> require changes to hardware enable state between changes to software
> >>> clock topology and hardware clock topology.
> >>> 
> >>> There are options to achieve the above:
> >>> 1. Grab the enable lock before changing software/hardware topology
> >>> and
> >>> 
> >>> release it afterwards.
> >>> 
> >>> 2. Keep the clock enabled for the duration of software/hardware
> >>> topology>
> >>> 
> >>> change so that any additional enable/disable calls don't try to
> >>> change
> >>> the hardware state. Once the topology change is complete, the
> >>> clock
> >>> can
> >>> be put back in its original enable state.
> >>> 
> >>> Option (1) is not an acceptable solution since the set_parent() ops
> >>> might need to sleep.
> >>> 
> >>> Therefore, this patch implements option (2).
> >>> 
> >>> This patch doesn't violate any API semantics. clk_disable() doesn't
> >>> guarantee that the clock is actually disabled. So, no clients of a
> >>> clock can assume that a clock is disabled after their last call to
> >>> clk_disable(). So, enabling the clock during a parent change is not
> >>> a
> >>> violation of any API semantics.
> >>> 
> >>> This also has the nice side effect of simplifying the error handling
> >>> code.
> >>> 
> >>> Signed-off-by: Saravana Kannan 
> >> 
> >> I've taken this patch into clk-next for testing.  The code itself
> >> looks
> >> fine.  The only thing that remains to be seen is if any platforms
> >> have a problem with disabled clocks getting turned on during a
> >> reparent operation.
> > 
> > IMHO this behavior should be documented somewhere, with a note that
> > the
> > clock must not be prepared to keep it disabled during reparent
> > operation and possibly also pointing to the CLK_SET_PARENT_GATE flag.
> 
> Reasonable request. I can update the documentation of clk_set_parent()
> to indicate that the clock might get turned on for the duration of the
> call and if they need a guarantee the GATE flag should be used.
> 
> >> On platforms that I have worked on this is OK, but I suppose there
> >> could be some platform out there where a clock is prepared and
> >> disabled, and briefly enabling the clock during the reparent
> >> operation somehow puts the hardware in a bad state.
> > 
> > Well, on any platform where default clock settings are not completely
> > correct this is likely to cause problems, because some device might
> > get
> > too high frequency for some period of time, which might crash it alone
> > as well as the whole system.
> 
> I don't think this is really a problem with this patch. It's present
> even without this patch.
> 
> The patch doesn't switch to some other unspecified parent. It only
> switches between the new/old parent. Even without this patch, if a clock
> is prepared while you reparent it, clk_enable() could be called at
> anytime between the parent switch and the future clock API calls to set
> up the new parent correctly. I think that's just crappy driver code to
> switch to a new parent before setting it up correctly. There's
> absolutely no good reason to do it that way.

This is not exactly what I meant. I was just giving an example problem of 
turning a clock on, if it's not set up correctly yet.

AFAIK most (if not all) of current code either does necessary reparenting 
and initial rate setting early, before clk_prepare(), so it is not a 
problem or already after clk_enable() (in case of reparenting dynamically 
at runtime), so there shouldn't be any problem.

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/

r8169 on 3.8.13, 3.9.2, 3.10-rc1, was Re: [ 00/73] 3.8.13-stable review

[Ken Moffat]

On Fri, May 10, 2013 at 12:54:27PM +0200, Holger Hoffstaette wrote:

 Cc'ing to netdev because I don't think this has had a response, and
I care because I *might* be seeing the same problem on both 3.9.2
and 3.10-rc1, but my take on the problem is slightly different [
details after Holger's posting ]

> On Thu, 09 May 2013 15:31:23 -0700, Greg Kroah-Hartman wrote:
> 
> > This is the start of the stable review cycle for the 3.8.13 release. There
> 
> This patchset broke my internet, with all sorts of weird effects like
> Samba clients having problems to talk to the server and only partially
> working DNS resolution (CDNs broken, Amazon unreachable).
> 
> After two reboots to/from .12/.13 (to rule out temporary internet
> brokenness) the problem has been identified as:
> 
> > Stefan Bader 
> > r8169: fix 8168evl frame padding.
> 
> After reverting only this patch (turning r8169 back to 3.8.12) things
> again behave as expected with the rest of .13. So far no other regressions
> detected.
> 
> This patch should probably be removed from 3.9.2-rc as well.
> 
> -h
> 
 For me, I'm seeing what might be a similar problem in about 2/5 of
my boots of 3.9.2 and 3.10-rc1 : in my case, r8169 is a module [ most
things are built in ], I use dhclient to get an ip address, and I
have separate nfs shares for /sources [ in /etc/mtab ] and my user's
~/notes [ mounted from ~/.bashrc ].

 On a good boot, everything mounts.  On a bad boot, /sources is NOT
mounted because eth0 is not up, but by the time anyone logs in it
_is_ up so mounting ~/notes [and manually mounting /sources as root]
works.  What seems to be happening is that eth0 is coming up
slightly later on some occasions (about 11 seconds from booting,
instead of 10.5 seconds) and somehow the dhclient script seems to
have ended *before* that.

 For me, this isn't bisectable (so far, 10 boots of 3.9.2 and
3.10-rc1 on this box, and 4 were problematic).  On this box, 3.9.0
itself was perfect.

Holger : apologies if I've hijacked this thread with what turns out
to be a different problem.

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce
--
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] f2fs: fix the inconsistent state of data pages

[Jaegeuk Kim]

In get_lock_data_page, if there is a data race between get_dnode_of_data for
node and grab_cache_page for data, f2fs is able to face with the following
BUG_ON(dn.data_blkaddr == NEW_ADDR).

kernel BUG at /home/zeus/f2fs_test/src/fs/f2fs/data.c:251!
 [] get_lock_data_page+0x1ec/0x210 [f2fs]
Call Trace:
 [] f2fs_readdir+0x89/0x210 [f2fs]
 [] ? fillonedir+0x100/0x100
 [] ? fillonedir+0x100/0x100
 [] vfs_readdir+0xb8/0xe0
 [] sys_getdents+0x8f/0x110
 [] system_call_fastpath+0x16/0x1b

This bug is able to be occurred when the block address of the data block is
changed after f2fs_put_dnode().
In order to avoid that, this patch fixes the lock order of node and data
blocks in which the node block lock is covered by the data block lock.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 91ff93b..05fb5c6 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -233,18 +233,23 @@ struct page *get_lock_data_page(struct inode *inode, 
pgoff_t index)
struct page *page;
int err;
 
+repeat:
+   page = grab_cache_page(mapping, index);
+   if (!page)
+   return ERR_PTR(-ENOMEM);
+
set_new_dnode(, inode, NULL, NULL, 0);
err = get_dnode_of_data(, index, LOOKUP_NODE);
-   if (err)
+   if (err) {
+   f2fs_put_page(page, 1);
return ERR_PTR(err);
+   }
f2fs_put_dnode();
 
-   if (dn.data_blkaddr == NULL_ADDR)
+   if (dn.data_blkaddr == NULL_ADDR) {
+   f2fs_put_page(page, 1);
return ERR_PTR(-ENOENT);
-repeat:
-   page = grab_cache_page(mapping, index);
-   if (!page)
-   return ERR_PTR(-ENOMEM);
+   }
 
if (PageUptodate(page))
return page;
-- 
1.8.1.3.566.gaa39828

--
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] f2fs: fix inconsistency of block count during recovery

[Jaegeuk Kim]

Currently f2fs recovers the dentry of fsynced files.
When power-off-recovery is conducted, this newly recovered inode should increase
node block count as well as inode block count.

This patch resolves this inconsistency that results in:

1. create a file
2. write data
3. fsync
4. reboot without sync
5. mount and recover the file
6. node block count is 1 and inode block count is 2
 : fall into the inconsistent state
7. unlink the file
 : trigger the following BUG_ON

[ cut here ]
kernel BUG at /home/zeus/f2fs_test/src/fs/f2fs/f2fs.h:716!
Call Trace:
 [] ? get_node_page+0x50/0x1a0 [f2fs]
 [] remove_inode_page+0x8c/0x100 [f2fs]
 [] ? f2fs_evict_inode+0x180/0x2d0 [f2fs]
 [] f2fs_evict_inode+0x1be/0x2d0 [f2fs]
 [] evict+0xa7/0x1a0
 [] iput+0x105/0x190
 [] d_kill+0xe0/0x120
 [] dput+0xe7/0x1e0
 [] __fput+0x19d/0x2d0
 [] fput+0xe/0x10
 [] task_work_run+0xb5/0xe0
 [] do_notify_resume+0x71/0xb0
 [] int_signal+0x12/0x17

Reported-by: Chris Fries 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/node.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 3df43b4..9641534 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1492,6 +1492,8 @@ int recover_inode_page(struct f2fs_sb_info *sbi, struct 
page *page)
new_ni = old_ni;
new_ni.ino = ino;
 
+   if (!inc_valid_node_count(sbi, NULL, 1))
+   WARN_ON(1);
set_node_addr(sbi, _ni, NEW_ADDR);
inc_valid_inode_count(sbi);
 
-- 
1.8.1.3.566.gaa39828

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

Re: [RFC PATCH 1/2] ARM: delay: print dummy values for bogomips

[Nicolas Pitre]

On Tue, 14 May 2013, Rob Herring wrote:

> On Tue, May 14, 2013 at 2:54 PM, Nicolas Pitre  wrote:
> > [ Yes, I'm late to the party ]
> >
> > On Tue, 7 May 2013, Marc Zyngier wrote:
> >
> >> On 07/05/13 00:16, Pavel Machek wrote:
> >>
> >> Hi Pawel,
> >>
> >> >> Now that we support a timer-backed delay loop, I'm quickly getting sick
> >> >> and tired of people complaining that their beloved bogomips value has
> >> >> decreased. You know who you are!
> >> >
> >> >> Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
> >> >> will likely break fragile userspace code which is parsing that stuff, so
> >> >> instead replace it with a dummy value that can be chosen in the
> >> >> Kconfig.
> >> >
> >> > So, instead of removing it you silently report invalid value? Note
> >>
> >> Removing it would be an ABI breakage. Unfortunately.
> >
> > Did you really write this with a straight face?
> >
> >> Name one userspace application that extracts meaningful information out
> >> of the BogoMIPS field. Just one.
> >
> > Waitaminute... Didn't you just claim this would be an ABI break?
> >
> > So if no application can be found, where is the ABI breakage?
> 
> lscpu
> 
> But that is already "broken" on ARM because x86 uses "bogomips" and
> ARM uses "BogoMIPS". 

So basically it won't be any more broken if the field disappears 
entirely, right?

> I agree reporting BogoMIPS is silly, but there
> are more differences between x86 and ARM. Somewhat meaningful fields
> like "cpu MHz" are missing on ARM for example. These are mainly useful
> for h/w inventory use which server folks tend to care about.

So... the tool must be coping well with missing fields already?  If 
/proc/cpuinfo is missing "important" fields on ARM then this is a 
different issue.

> > This thread must be a joke.  Please just kill the damn thing out of
> > /proc/cpuinfo and see if any application notices.  And if some do then
> > they are already broken *today* and should be fixed.
> 
> And please do so for all arches then.

Why?  It happens that the bogomips reporting on ARM is even more 
"broken" than on other architectures and therefore it deserves to be 
removed even more than on other architectures.  Who knows, maybe it 
still has some semblance of a meaning on those other architectures and 
that should be up to their respective maintainers to decide.


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

Re: linux-next: Tree for May 14 (vhost_scsi)

[Stephen Rothwell]

[Adding Michael to cc]

On Tue, 14 May 2013 12:16:20 -0700 Randy Dunlap  wrote:
>
> on x86_64:
> 
> ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined!
> 
> 
> It needs to depend on NET since net/core/ provides that function.
> 
> -- 
> ~Randy

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpQu61yG7oQY.pgp
Description: PGP signature

[PATCH] [media] rtl28xxu: Add USB ID for Leadtek WinFast DTV Dongle mini

[Miroslav Šustek]

USB ID 0413:6a03 is Leadtek WinFast DTV Dongle mini.
Decoder Realtek RTL2832U and tuner Infineon TUA9001.

Signed-off-by: Miroslav Šustek 
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 22015fe..d220ccc 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1408,6 +1408,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
_props, "Compro VideoMate U620F", NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd394,
_props, "MaxMedia HU394-T", NULL) },
+   { DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6a03,
+   _props, "WinFast DTV Dongle mini", NULL) },
{ }
 };
 MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
-- 
1.8.1.4

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

Re: [PATCH] [media] rtl28xxu: Add USB ID for Leadtek WinFast DTV Dongle mini

[Antti Palosaari]

On 05/15/2013 02:42 AM, Miroslav Šustek wrote:

USB ID 0413:6a03 is Leadtek WinFast DTV Dongle mini.
Decoder Realtek RTL2832U and tuner Infineon TUA9001.

Signed-off-by: Miroslav Šustek 


Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 


---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 22015fe..d220ccc 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1408,6 +1408,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
_props, "Compro VideoMate U620F", NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd394,
_props, "MaxMedia HU394-T", NULL) },
+   { DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6a03,
+   _props, "WinFast DTV Dongle mini", NULL) },
{ }
  };
  MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);




--
http://palosaari.fi/
--
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: Kernel 3.10-rc1 build warning on 32-bit ppc associated with commit 3925f46

[Benjamin Herrenschmidt]

On Tue, 2013-05-14 at 10:29 -0500, Larry Finger wrote:
> Hi,
> 
> When building 3.10-rc1 on a PowerBook G4, I get the following warning:

Thanks. Should be fixed now, let me know if it's not.

Cheers,
Ben.

> cc1: warnings being treated as errors
> arch/powerpc/perf/core-book3s.c: In function ‘power_pmu_bhrb_read’:
> arch/powerpc/perf/core-book3s.c:1479: error: integer constant is too large 
> for 
> ‘long’ type
> make[2]: *** [arch/powerpc/perf/core-book3s.o] Error 1
> make[1]: *** [arch/powerpc/perf] Error 2
> make[1]: *** Waiting for unfinished jobs
>LD  arch/powerpc/platforms/powermac/built-in.o
>LD  arch/powerpc/platforms/built-in.o
> make[1]: Leaving directory `/home/finger/wireless-testing'
> make: *** [debian/stamp/build/kernel] Error 2
> 
> The code in question came from commit 3925f46 entitled "powerpc/perf: Enable 
> branch stack sampling framework". The gcc version is 4.4.5 running with a 
> Mint 9 
> distribution.
> 
> I have disabled the "-Werror" switch so that the build can continue. That 
> Kconfig question about disabling WERROR is a bit confusing with its double 
> negative construction.
> 
> Thanks,
> 
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


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

linux-next: comment on the kbuild tree

[Stephen Rothwell]

Hi Michal,

Since the kbuild tree now consists only of merge commits (relative to
v3.10-rc1), you might as well just reset it to v3.10-rc1 and have a nice
clean tree to start from.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpGBB3qUuAIO.pgp
Description: PGP signature

Re: PROBLEM: modprobe hang at startup (3.8.x, 3.9.x, IBM x3550)

[Robert Norris]

On Mon, May 13, 2013 at 11:22:32AM +1000, Robert Norris wrote:
> We have a number of Intel x3550 servers (Intel 5000-series). They've
> been running 3.7.2 fine.
> 
> In the last week I've run 3.8.11, 3.8.12 and 3.9.2 on them. All have
> long hangs at boot, and later hung tasks in modprobe.

I bisected this and tracked it to this commit:

commit 6676a847d48ac48908cf467b42da9045b5463a6e
Author: Jean Delvare 
Date:   Sun Dec 16 21:11:55 2012 +0100

i2c-i801: Enable interrupts for all post-ICH5 chips

I did not receive a single bug report after interrupt support was
added for a limited number of chips. So I'd say the code is good and
should be enabled for all supported chips, that is: ICH5 and later.

Signed-off-by: Jean Delvare 
Reviewed-by: Daniel Kurtz 

I've tested by building 3.9.2 with that single commit reverted, and it
boots without issue.

According to lspci I have:

00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus 
Controller (rev 09)

Which has PCI ID 0x269b (ie PCI_DEVICE_ID_INTEL_ESB2_17).

For now I will either revert this commit in my kernel builds or
blacklist the module on these machines (I haven't decided which I prefer
yet).

Obviously, I can reproduce this reliably, and am happy to test.

Cheers,
Rob N.
--
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: [PATCHv11 3/4] zswap: add to mm/

[Seth Jennings]

On Tue, May 14, 2013 at 01:18:48PM -0700, Dan Magenheimer wrote:
> > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> > Subject: Re: [PATCHv11 3/4] zswap: add to mm/
> > 
> > 
> >
> > > > +/* The maximum percentage of memory that the compressed pool can 
> > > > occupy */
> > > > +static unsigned int zswap_max_pool_percent = 20;
> > > > +module_param_named(max_pool_percent,
> > > > +   zswap_max_pool_percent, uint, 0644);
> > 
> > 
> >
> > > This limit, along with the code that enforces it (by calling reclaim
> > > when the limit is reached), is IMHO questionable.  Is there any
> > > other kernel memory allocation that is constrained by a percentage
> > > of total memory rather than dynamically according to current
> > > system conditions?  As Mel pointed out (approx.), if this limit
> > > is reached by a zswap-storm and filled with pages of long-running,
> > > rarely-used processes, 20% of RAM (by default here) becomes forever
> > > clogged.
> > 
> > So there are two comments here 1) dynamic pool limit and 2) writeback
> > of pages in zswap that won't be faulted in or forced out by pressure.
> > 
> > Comment 1 feeds from the point of view that compressed pages should just be
> > another type of memory managed by the core MM.  While ideal, very hard to
> > implement in practice.  We are starting to realize that even the policy
> > governing to active vs inactive list is very hard to get right. Then 
> > shrinkers
> > add more complexity to the policy problem.  Throwing another type in the mix
> > would just that much more complex and hard to get right (assuming there even
> > _is_ a "right" policy for everyone in such a complex system).
> > 
> > This max_pool_percent policy is simple, works well, and provides a
> > deterministic policy that users can understand. Users can be assured that a
> > dynamic policy heuristic won't go nuts and allow the compressed pool to grow
> > unbounded or be so aggressively reclaimed that it offers no value.
> 
> Hi Seth --
> 
> Hmmm... I'm not sure how to politely say "bullshit". :-)
> 
> The default 20% was randomly pulled out of the air long ago for zcache
> experiments.  If you can explain why 20% is better than 19% or 21%, or
> better than 10% or 30% or even 50%, that would be a start.  Then please try
> to explain -- in terms an average sysadmin can understand -- under
> what circumstances this number should be higher or lower, that would
> be even better.  In fact if you can explain it in even very broadbrush
> terms like "higher for embedded" and "lower for server" that would be
> useful.  If the top Linux experts in compression can't answer these
> questions (and the default is a random number, which it is), I don't
> know how we can expect users to be "assured".

20% is a default maximum.  There really isn't a particular reason for the
selection other than to supply reasonable default to a tunable.  20% is enough
to show the benefit while assuring the user zswap won't eat more than that
amount of memory under any circumstance.  The point is to make it a tunable,
not to launch an incredibly in-depth study on what the default should be.

As guidance on how to tune it, switching to zbud actually made the math simpler
by bounding the best case to 2 and the expected density to very near 2.  I have
two methods, one based on calculation and another based on experimentation.

Yes, I understand that there are many things to consider, but for the sake of
those that honestly care about the answer to the question, I'll answer it.

Method 1:

If you have a workload running on a machine with x GB of RAM and an anonymous
working set of y GB of pages where x < y, a good starting point for
max_pool_percent is ((y/x)-1)*100.

For example, if you have 10GB of RAM and 12GB anon working set, (12/10-1)*100 =
20.  During operation there would be 8GB in uncompressed memory, and 4GB worth
of compressed memory occupying 2GB (i.e. 20%) of RAM.  This will reduce swap I/O
to near zero assuming the pages compress <50% on average.

Bear in mind that this formula provides a lower bound on max_pool_percent if
you want to avoid swap I/0.  Setting max_pool_percent to >20 would produce
the same situation.

Method 2:

Experimentally, one can just watch swap I/O rates while the workload is running
and increase max_pool_percent until no (or acceptable level of) swap I/O is
occurring.

As max_pool_percent increases, however, there is less and less room for
uncompressed memory, the only kind of memory on which the kernel can actually
operate. Compression/decompression activity might start dominating over useful
work.  Going over 80 is probably not advised.  If swap I/O is still observed
for high values of max_pool_percent, then the memory load should be reduced,
memory capacity should be increased, or performance degradation should be 
accepted.

> 
> What you mean is "works well"... on the two benchmarks you've tried it
> on.  You say it's too hard to do dynamically... even 

Re: [PATCH] ARM: PL011: add support for extended FIFO-size of PL011-r1p5

[Russell King - ARM Linux]

On Tue, May 14, 2013 at 03:03:14PM -0600, Stephen Warren wrote:
> On 05/14/2013 01:15 AM, Jongsung Kim wrote:
> > Stephen Warren  :
> >> For reference, the AMBA periphid of the UART device there is 0x00341011.
> >> The nibble "3" is the revision being tested in:
> > 
> > The UART device has periphid 0x00341011, and is compatible with the
> > original PL011 prior to r1p5. Not with r1p5. It could be a possible
> > way to specify the compatible periphid (such as 0x00241011) instead
> > of just 0x0 when initializing the amba_device for the UART.
> > 
> >>> +static unsigned int get_fifosize_arm(unsigned int periphid)
> >>> +{
> >>> + unsigned int rev = (periphid >> 20) & 0xf;
> >>> + return rev < 3 ? 16 : 32;
> >>> +}
> ...
> > Doesn't the BCM2835 UART have anything different from the ARM PL011?
> > What about the UARTPCellID registers? They are set to 0xb105f00d with
> > the ARM PL011.
> 
> Looking at BCM2835-ARM-Peripherals.pdf (i.e. the public documentation
> for the BCM2835 chip), I see:
> 
> =
> The UART provides:
> * Separate 16x8 transmit and 16x12 receive FIFO memory.
> ...
> For the in-depth UART overview, please, refer to the ARM PrimeCell UART
> (PL011) Revision: r1p5 Technical Reference Manual.
> =
> 
> That seems to imply that not all r1p5 PL011s actually have a depth-32
> FIFO. Perhaps this is a configurable property of the IP block, not
> something that all r1p5 have?
> 
> I can't check the UARTPCellID registers right now.

The PCellID value is a marker for primecells, and is common to all primecells
which implement the ID scheme.  It's the other ID registers you want. :)
--
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] clk: Fix race condition between clk_set_parent and clk_enable()

[Saravana Kannan]

On 05/14/2013 03:10 PM, Tomasz Figa wrote:

Hi,

On Tuesday 14 of May 2013 11:54:17 Mike Turquette wrote:

Quoting Saravana Kannan (2013-04-30 21:42:08)


Without this patch, the following race conditions are possible.

Race condition 1:
* clk-A has two parents - clk-X and clk-Y.
* All three are disabled and clk-X is current parent.
* Thread A: clk_set_parent(clk-A, clk-Y).
* Thread A: 
* Thread A: Grabs enable lock.
* Thread A: Sees enable count of clk-A is 0, so doesn't enable clk-Y.
* Thread A: Updates clk-A SW parent to clk-Y
* Thread A: Releases enable lock.
* Thread B: clk_enable(clk-A).
* Thread B: clk_enable() enables clk-Y, then enabled clk-A and
returns.

clk-A is now enabled in software, but not clocking in hardware since
the hardware parent is still clk-X.

The only way to avoid race conditions between clk_set_parent() and
clk_enable/disable() is to ensure that clk_enable/disable() calls
don't
require changes to hardware enable state between changes to software
clock topology and hardware clock topology.

There are options to achieve the above:
1. Grab the enable lock before changing software/hardware topology and

release it afterwards.

2. Keep the clock enabled for the duration of software/hardware
topology>
change so that any additional enable/disable calls don't try to
change
the hardware state. Once the topology change is complete, the clock
can
be put back in its original enable state.

Option (1) is not an acceptable solution since the set_parent() ops
might need to sleep.

Therefore, this patch implements option (2).

This patch doesn't violate any API semantics. clk_disable() doesn't
guarantee that the clock is actually disabled. So, no clients of a
clock can assume that a clock is disabled after their last call to
clk_disable(). So, enabling the clock during a parent change is not a
violation of any API semantics.

This also has the nice side effect of simplifying the error handling
code.

Signed-off-by: Saravana Kannan 


I've taken this patch into clk-next for testing.  The code itself looks
fine.  The only thing that remains to be seen is if any platforms have a
problem with disabled clocks getting turned on during a reparent
operation.


IMHO this behavior should be documented somewhere, with a note that the
clock must not be prepared to keep it disabled during reparent operation
and possibly also pointing to the CLK_SET_PARENT_GATE flag.


Reasonable request. I can update the documentation of clk_set_parent() 
to indicate that the clock might get turned on for the duration of the 
call and if they need a guarantee the GATE flag should be used.





On platforms that I have worked on this is OK, but I suppose there could
be some platform out there where a clock is prepared and disabled, and
briefly enabling the clock during the reparent operation somehow puts
the hardware in a bad state.


Well, on any platform where default clock settings are not completely
correct this is likely to cause problems, because some device might get
too high frequency for some period of time, which might crash it alone as
well as the whole system.



I don't think this is really a problem with this patch. It's present 
even without this patch.


The patch doesn't switch to some other unspecified parent. It only 
switches between the new/old parent. Even without this patch, if a clock 
is prepared while you reparent it, clk_enable() could be called at 
anytime between the parent switch and the future clock API calls to set 
up the new parent correctly. I think that's just crappy driver code to 
switch to a new parent before setting it up correctly. There's 
absolutely no good reason to do it that way.


-Saravana

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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] mtip32xx: Correctly handle bio->bi_idx != 0 conditions

[Sam Bradshaw]

Stacking drivers may append bvecs to existing bio's, resulting
in non-zero bi_idx conditions.  This patch counts the loops of
bio_for_each_segment() rather than inheriting the bi_idx value
to pass as a segment count to the hardware submission routine.

Signed-off-by: Sam Bradshaw 
---
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 847107e..7c77ae1 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3863,7 +3863,7 @@ static void mtip_make_request(struct request_queue
*queue, struct bio *bio)
struct driver_data *dd = queue->queuedata;
struct scatterlist *sg;
struct bio_vec *bvec;
-   int nents = 0;
+   int i, nents = 0;
int tag = 0, unaligned = 0;

if (unlikely(dd->dd_flag & MTIP_DDF_STOP_IO)) {
@@ -3921,11 +3921,12 @@ static void mtip_make_request(struct
request_queue *queue, struct bio *bio)
}

/* Create the scatter list for this bio. */
-   bio_for_each_segment(bvec, bio, nents) {
+   bio_for_each_segment(bvec, bio, i) {
sg_set_page([nents],
bvec->bv_page,
bvec->bv_len,
bvec->bv_offset);
+   nents++;
}

/* Issue the read/write. */
--
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] pci: Avoid reentrant calls to work_on_cpu

[Alexander Duyck]

This change is meant to fix a deadlock seen when pci_enable_sriov was
called from within a driver's probe routine.  The issue was that
work_on_cpu calls flush_work which attempts to flush a work queue for a
cpu that we are currently working in.  In order to avoid the reentrant
path we just skip the call to work_on_cpu in the case that the device
node matches our current node.

Reported-by: Yinghai Lu 
Signed-off-by: Alexander Duyck 
---

This patch is meant to address the issue pointed out in an earlier patch
sent by Yinghai Lu titled:
  [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's

 drivers/pci/pci-driver.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 79277fb..caeb1c0 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -277,12 +277,16 @@ static int pci_call_probe(struct pci_driver *drv, struct 
pci_dev *dev,
int error, node;
struct drv_dev_and_id ddi = { drv, dev, id };
 
-   /* Execute driver initialization on node where the device's
-  bus is attached to.  This way the driver likely allocates
-  its local memory on the right node without any need to
-  change it. */
+   /*
+* Execute driver initialization on the node where the device's
+* bus is attached.  This way the driver likely allocates
+* its local memory on the right node without any need to
+* change it.  If the node is the current node just call
+* local_pci_probe and avoid the possibility of reentrant
+* calls to work_on_cpu.
+*/
node = dev_to_node(>dev);
-   if (node >= 0) {
+   if ((node >= 0) && (node != numa_node_id())) {
int cpu;
 
get_online_cpus();

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

Re: [RFC PATCH 1/2] ARM: delay: print dummy values for bogomips

[Rob Herring]

On Tue, May 14, 2013 at 2:54 PM, Nicolas Pitre  wrote:
> [ Yes, I'm late to the party ]
>
> On Tue, 7 May 2013, Marc Zyngier wrote:
>
>> On 07/05/13 00:16, Pavel Machek wrote:
>>
>> Hi Pawel,
>>
>> >> Now that we support a timer-backed delay loop, I'm quickly getting sick
>> >> and tired of people complaining that their beloved bogomips value has
>> >> decreased. You know who you are!
>> >
>> >> Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
>> >> will likely break fragile userspace code which is parsing that stuff, so
>> >> instead replace it with a dummy value that can be chosen in the
>> >> Kconfig.
>> >
>> > So, instead of removing it you silently report invalid value? Note
>>
>> Removing it would be an ABI breakage. Unfortunately.
>
> Did you really write this with a straight face?
>
>> Name one userspace application that extracts meaningful information out
>> of the BogoMIPS field. Just one.
>
> Waitaminute... Didn't you just claim this would be an ABI break?
>
> So if no application can be found, where is the ABI breakage?

lscpu

But that is already "broken" on ARM because x86 uses "bogomips" and
ARM uses "BogoMIPS". I agree reporting BogoMIPS is silly, but there
are more differences between x86 and ARM. Somewhat meaningful fields
like "cpu MHz" are missing on ARM for example. These are mainly useful
for h/w inventory use which server folks tend to care about.

> This thread must be a joke.  Please just kill the damn thing out of
> /proc/cpuinfo and see if any application notices.  And if some do then
> they are already broken *today* and should be fixed.

And please do so for all arches then.

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

bug in DH77EB spurious reboot quirk handling (drivers/usb/host/xhci.c)

[Patrick Gosling]

There is a known bios problem with Intel DH77EB motherboards, described
here: 

I have such a board, and am running the 3.8.0-ish kernel distributed
in the ubuntu 13.04 linux-image-3.8.0-19-generic package.  I apologise
for not having (yet) tried a more vanilla kernel source;  I will do
so imminently.

However, the ubuntu kernel includes the patch described in the url above,
and I can see no obvious reason why it should fail to have effect.

Observably, the patch didn't work on my machine - attempts to power the
machine off, while wake-on-lan was supported, would result in a spurious
reboot.

In attempting to identify the problem, I added (among some debugging
prints), an msleep(1000) immediately after the usb_disable_xhci_ports()
call in drivers/usb/host/xhci.c .

This fixed the problem;  I am now running a kernel whose only change is
the insertion of that "msleep(1000);".  The machine now powers off 
correctly.

This leads me to suspect that (possibly because the machine is quite fast
at shutting down), there is a timing issue with this quirk fix.

I don't think that just adding a 1s sleep is very satisfactory, however.

I could try tweaking the duration of the sleep downwards until it
stopped working, but this would seem likely to result in finding that
"it _usually_ works", which isn't at all satisfactory. 

I wonder if anyone has any ideas as to what one might want to wait
for, to ensure that the disabling of the xhci ports has actually taken
effect, before continuing the shutdown ...

With best wishes,

-patrick.
--
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/21] Generic percpu refcounting

[Tejun Heo]

Hello, again, continuing the brain diarrehea,

On Tue, May 14, 2013 at 02:59:45PM -0700, Tejun Heo wrote:
> So, while I do like the simplicity of put() returning %true on the
> final put, I suspect it's more likely to slowing down fast paths due
> to its interface compared to having separate ->release function
> combined with void put().  Any ideas?

Maybe we can structure put in a way that's difficult to get wrong for
the compiler?

bool put()
{
preempt_disable();
if (likely(not killed yet)) {
this_cpu_dec();
preempt_enable();
return false;
}
return put_slowpath();
}

This doesn't solve the caller not inlining hot path but well I suppose
we can consider that the caller's problem.  The above at least
wouldn't introduce an unnecessary branch on its own.

Thanks.

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

Re: [RFC PATCH v2, part 2 16/18] PCI, iommu: use hotplug-safe iterators to walk PCI buses

[Don Dutile]

On 05/14/2013 12:52 PM, Jiang Liu wrote:

Enhance iommu drviers to use hotplug-safe iterators to walk
PCI buses.

Signed-off-by: Jiang Liu
Cc: Joerg Roedel
Cc: Ingo Molnar
Cc: Donald Dutile
Cc: Hannes Reinecke
Cc: "Li, Zhen-Hua"
Cc: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
---
  drivers/iommu/amd_iommu.c | 4 +++-
  drivers/iommu/dmar.c  | 6 --
  2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index e046d7a..d6fdf94 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -357,6 +357,7 @@ static int init_iommu_group(struct device *dev)
struct iommu_dev_data *dev_data;
struct iommu_group *group;
struct pci_dev *dma_pdev;
+   struct pci_bus *b = NULL;
int ret;

group = iommu_group_get(dev);
@@ -393,7 +394,7 @@ static int init_iommu_group(struct device *dev)
 * the alias.  Be careful to also test the parent device if
 * we think the alias is the root of the group.
 */
-   bus = pci_find_bus(0, alias>>  8);
+   b = bus = pci_find_bus(0, alias>>  8);
if (!bus)
goto use_group;

@@ -413,6 +414,7 @@ static int init_iommu_group(struct device *dev)
dma_pdev = get_isolation_root(pci_dev_get(to_pci_dev(dev)));
  use_pdev:
ret = use_pdev_iommu_group(dma_pdev, dev);
+   pci_bus_put(b);

pci_find_bus() does a pci_bus_put() after the pci_get_bus();
is this needed, or did you mean to make the above patch pci_get_bus() ?


pci_dev_put(dma_pdev);
return ret;
  use_group:
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index e5cdaf8..5bb3cdc 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -67,12 +67,12 @@ static void __init dmar_register_drhd_unit(struct 
dmar_drhd_unit *drhd)
  static int __init dmar_parse_one_dev_scope(struct acpi_dmar_device_scope 
*scope,
   struct pci_dev **dev, u16 segment)
  {
-   struct pci_bus *bus;
+   struct pci_bus *b, *bus;
struct pci_dev *pdev = NULL;
struct acpi_dmar_pci_path *path;
int count;

-   bus = pci_find_bus(segment, scope->bus);
+   b = bus = pci_find_bus(segment, scope->bus);
path = (struct acpi_dmar_pci_path *)(scope + 1);
count = (scope->length - sizeof(struct acpi_dmar_device_scope))
/ sizeof(struct acpi_dmar_pci_path);
@@ -97,6 +97,8 @@ static int __init dmar_parse_one_dev_scope(struct 
acpi_dmar_device_scope *scope,
count --;
bus = pdev->subordinate;
}
+   pci_bus_put(b);

ditto.


+
if (!pdev) {
pr_warn("Device scope device [%04x:%02x:%02x.%02x] not found\n",
segment, scope->bus, path->dev, path->fn);


--
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] clk: Fix race condition between clk_set_parent and clk_enable()

[Tomasz Figa]

Hi,

On Tuesday 14 of May 2013 11:54:17 Mike Turquette wrote:
> Quoting Saravana Kannan (2013-04-30 21:42:08)
> 
> > Without this patch, the following race conditions are possible.
> > 
> > Race condition 1:
> > * clk-A has two parents - clk-X and clk-Y.
> > * All three are disabled and clk-X is current parent.
> > * Thread A: clk_set_parent(clk-A, clk-Y).
> > * Thread A: 
> > * Thread A: Grabs enable lock.
> > * Thread A: Sees enable count of clk-A is 0, so doesn't enable clk-Y.
> > * Thread A: Updates clk-A SW parent to clk-Y
> > * Thread A: Releases enable lock.
> > * Thread B: clk_enable(clk-A).
> > * Thread B: clk_enable() enables clk-Y, then enabled clk-A and
> > returns.
> > 
> > clk-A is now enabled in software, but not clocking in hardware since
> > the hardware parent is still clk-X.
> > 
> > The only way to avoid race conditions between clk_set_parent() and
> > clk_enable/disable() is to ensure that clk_enable/disable() calls
> > don't
> > require changes to hardware enable state between changes to software
> > clock topology and hardware clock topology.
> > 
> > There are options to achieve the above:
> > 1. Grab the enable lock before changing software/hardware topology and
> > 
> >release it afterwards.
> > 
> > 2. Keep the clock enabled for the duration of software/hardware
> > topology> 
> >change so that any additional enable/disable calls don't try to
> >change
> >the hardware state. Once the topology change is complete, the clock
> >can
> >be put back in its original enable state.
> > 
> > Option (1) is not an acceptable solution since the set_parent() ops
> > might need to sleep.
> > 
> > Therefore, this patch implements option (2).
> > 
> > This patch doesn't violate any API semantics. clk_disable() doesn't
> > guarantee that the clock is actually disabled. So, no clients of a
> > clock can assume that a clock is disabled after their last call to
> > clk_disable(). So, enabling the clock during a parent change is not a
> > violation of any API semantics.
> > 
> > This also has the nice side effect of simplifying the error handling
> > code.
> > 
> > Signed-off-by: Saravana Kannan 
> 
> I've taken this patch into clk-next for testing.  The code itself looks
> fine.  The only thing that remains to be seen is if any platforms have a
> problem with disabled clocks getting turned on during a reparent
> operation.

IMHO this behavior should be documented somewhere, with a note that the 
clock must not be prepared to keep it disabled during reparent operation 
and possibly also pointing to the CLK_SET_PARENT_GATE flag.

> On platforms that I have worked on this is OK, but I suppose there could
> be some platform out there where a clock is prepared and disabled, and
> briefly enabling the clock during the reparent operation somehow puts
> the hardware in a bad state.

Well, on any platform where default clock settings are not completely 
correct this is likely to cause problems, because some device might get 
too high frequency for some period of time, which might crash it alone as 
well as the whole system.

Best regards,
Tomasz

> Anyways that's a long shot and this look OK until somebody screams.
> 
> Regards,
> Mike
> 
> > ---
> > It's been a while since I submitted a patch. So, apologies if I'm
> > cc'ing people who no longer care about the state of the common clock
> > framework.> 
> >  drivers/clk/clk.c |   72
> >  +++- 1 files
> >  changed, 32 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 934cfd1..fe4055f 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -1377,67 +1377,59 @@ static int __clk_set_parent(struct clk *clk,
> > struct clk *parent, u8 p_index)> 
> > unsigned long flags;
> > int ret = 0;
> > struct clk *old_parent = clk->parent;
> > 
> > -   bool migrated_enable = false;
> > 
> > -   /* migrate prepare */
> > -   if (clk->prepare_count)
> > +   /*
> > +* Migrate prepare state between parents and prevent race with
> > +* clk_enable().
> > +*
> > +* If the clock is not prepared, then a race with
> > +* clk_enable/disable() is impossible since we already have
> > the
> > +* prepare lock (future calls to clk_enable() need to be
> > preceded by +* a clk_prepare()).
> > +*
> > +* If the clock is prepared, migrate the prepared state to the
> > new +* parent and also protect against a race with
> > clk_enable() by +* forcing the clock and the new parent on. 
> > This ensures that all +* future calls to clk_enable() are
> > practically NOPs with respect to +* hardware and software
> > states.
> > +*/
> > +   if (clk->prepare_count) {
> > 
> > __clk_prepare(parent);
> > 
> > -
> > -   flags = clk_enable_lock();
> > -
> > -   /* migrate enable */
> > -   if 

Re: [RFC v0 0/4] sys_copy_range() rough draft

[Zach Brown]

On Wed, May 15, 2013 at 07:42:51AM +1000, Dave Chinner wrote:
> On Tue, May 14, 2013 at 02:15:22PM -0700, Zach Brown wrote:
> > I'm going to keep hacking away at this.  My next step is to get ext4
> > supporting .copy_range, probably with a quick hack to copy the
> > contents of bios.  Hopefully that'll give enough time to also integrate
> > review feedback.
> 
> Wouldn't the easiest "support all filesystems" hack just be to add
> a destination offset parameter to do_splice_direct() and call that
> when the filesystem doesn't supply a ->copy_range method? i.e. use
> the mechanisms we already have for copying from one file to another
> via the page cache as efficiently as possible?

Probably; and this in-kernel buffered fallback is particularly desirable
for nfsd when the exported fs doesn't provide .copy_range.  Having nfsd
service the COPY op is still a significant win over having the client
move the data backand forth over the wire.

But in that quote above I was talking about implementing .copy_range in
ext4 as though it could use XCOPY today.  I'd like to get a feel for how
bad it's going to be to juggle the bio XCOPY IO with unwritten extent
conversion, RMW with overlapping existing blocks, i_size advancing, etc.
(It's so much like O_DIRECT that I'm already crying a little.)

- z
--
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] PCI: Reset PCIe devices to stop ongoing DMA

[Eric W. Biederman]

Takao Indoh  writes:

> This patch resets PCIe devices on boot to stop ongoing DMA. When
> "pci=pcie_reset_endpoint_devices" is specified, a hot reset is triggered
> on each PCIe root port and downstream port to reset its downstream
> endpoint.
>
> Problem:
> This patch solves the problem that kdump can fail when intel_iommu=on is
> specified. When intel_iommu=on is specified, many dma-remapping errors
> occur in second kernel and it causes problems like driver error or PCI
> SERR, at last kdump fails. This problem is caused as follows.
> 1) Devices are working on first kernel.
> 2) Switch to second kernel(kdump kernel). The devices are still working
>and its DMA continues during this switch.
> 3) iommu is initialized during second kernel boot and ongoing DMA causes
>dma-remapping errors.
>
> Solution:
> All DMA transactions have to be stopped before iommu is initialized. By
> this patch devices are reset and in-flight DMA is stopped before
> pci_iommu_init.
>
> To invoke hot reset on an endpoint, its upstream link need to be reset.
> reset_pcie_endpoints() is called from fs_initcall_sync, and it finds
> root port/downstream port whose child is PCIe endpoint, and then reset
> link between them. If the endpoint is VGA device, it is skipped because
> the monitor blacks out if VGA controller is reset.

At a quick skim this patch looks reasonable.

Acked-by: "Eric W. Biederman" 

> Changelog:
> v2:
> - Read pci config before de-assert secondary bus reset to flush previous
>   write
> - Change function/variable name
> - Make a list of devices to be reset
>
> v1:
> https://patchwork.kernel.org/patch/2482291/
>
> Signed-off-by: Takao Indoh 
> ---
>  Documentation/kernel-parameters.txt |2 +
>  drivers/pci/pci.c   |  113 
> +++
>  2 files changed, 115 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index c3bfacb..8c9e8e4 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2321,6 +2321,8 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   any pair of devices, possibly at the cost of
>   reduced performance.  This also guarantees
>   that hot-added devices will work.
> + pcie_reset_endpoint_devices Reset PCIe endpoint on boot by
> + hot reset
>   cbiosize=nn[KMG]The fixed amount of bus space which is
>   reserved for the CardBus bridge's IO window.
>   The default value is 256 bytes.
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index a899d8b..70c1205 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3873,6 +3873,116 @@ void __weak pci_fixup_cardbus(struct pci_bus *bus)
>  }
>  EXPORT_SYMBOL(pci_fixup_cardbus);
>  
> +/*
> + * Return true if dev is PCIe root port or downstream port whose child is 
> PCIe
> + * endpoint except VGA device.
> + */
> +static int __init need_reset(struct pci_dev *dev)
> +{
> + struct pci_bus *subordinate;
> + struct pci_dev *child;
> +
> + if (!pci_is_pcie(dev) || !dev->subordinate ||
> + list_empty(>subordinate->devices) ||
> + ((pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT) &&
> +  (pci_pcie_type(dev) != PCI_EXP_TYPE_DOWNSTREAM)))
> + return 0;
> +
> + subordinate = dev->subordinate;
> + list_for_each_entry(child, >devices, bus_list) {
> + if ((pci_pcie_type(child) == PCI_EXP_TYPE_UPSTREAM) ||
> + (pci_pcie_type(child) == PCI_EXP_TYPE_PCI_BRIDGE) ||
> + ((child->class >> 16) == PCI_BASE_CLASS_DISPLAY))
> + /* Don't reset switch, bridge, VGA device */
> + return 0;
> + }
> +
> + return 1;
> +}
> +
> +static void __init save_downstream_configs(struct pci_dev *dev)
> +{
> + struct pci_bus *subordinate;
> + struct pci_dev *child;
> +
> + subordinate = dev->subordinate;
> + list_for_each_entry(child, >devices, bus_list) {
> + dev_info(>dev, "save state\n");
> + pci_save_state(child);
> + }
> +}
> +
> +static void __init restore_downstream_configs(struct pci_dev *dev)
> +{
> + struct pci_bus *subordinate;
> + struct pci_dev *child;
> +
> + subordinate = dev->subordinate;
> + list_for_each_entry(child, >devices, bus_list) {
> + dev_info(>dev, "restore state\n");
> + pci_restore_state(child);
> + }
> +}
> +
> +static void __init do_downstream_device_reset(struct pci_dev *dev)
> +{
> + u16 ctrl;
> +
> + dev_info(>dev, "Reset Secondary bus\n");
> +
> + /* Assert Secondary Bus Reset */
> + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, );
> + ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
> + pci_write_config_word(dev,