Re: Linux 3.7-rc1 (nouveau_bios_score oops).

[Paweł Sikora]

On Sunday 21 of October 2012 00:19:48 Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote: 
> > 
> > > Try this one.
> > 
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> > 
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> > minor 0
> > [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> > [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> > [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for 
> > image...
> > [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> > [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> > end of region [VROM] (length 24) (20120913/exfldio-210)
> > [3.704139] ACPI Error: Method parse/execution 
> > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for 
> > image...
> > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable 
> > image
> > [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 
> > 0x1001, -22
> > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > [3.740523] dracut: Starting plymouth daemon
> 
> Hmm, maybe we can't fetch 3 bytes only...
> 
> Let's check this:
> 
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index 824eea0..8bd71aa 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
>  {
>   struct pci_dev *pdev = nv_device(bios)->pdev;
>   int ret, cnt, i;
> - u8  data[3];
> + u8  *data;
>  
>   if (!nouveau_acpi_rom_supported(pdev))
>   return;
>  
>   bios->size = 0;
> - if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
> + data = kmalloc(4096, GFP_KERNEL);
> + if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
>   bios->size = data[2] * 512;
> + kfree(data);
>   if (!bios->size)
>   return;

with these both patches applied my laptop boots and gui works fine.
here's dmesg:

(...)
[8.751795] nouveau  [   VBIOS][:01:00.0] ... appears to be valid
[8.751798] nouveau  [   VBIOS][:01:00.0] using image from ACPI
[8.751895] nouveau  [   VBIOS][:01:00.0] BIT signature found
[8.751898] nouveau  [   VBIOS][:01:00.0] version 70.08.45.00
[8.752366] nouveau  [ DEVINIT][:01:00.0] adaptor not initialised
[8.752368] nouveau  [   VBIOS][:01:00.0] running init tables
[8.867660] nouveau  [ MXM][:01:00.0] no VBIOS data, nothing to do
[8.867690] nouveau  [ PFB][:01:00.0] RAM type: DDR3
[8.867692] nouveau  [ PFB][:01:00.0] RAM size: 512 MiB
[8.901523] vga_switcheroo: enabled
[8.901979] [TTM] Zone  kernel: Available graphics memory: 6104282 kiB
[8.901980] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[8.901982] [TTM] Initializing pool allocator
[8.902014] [TTM] Initializing DMA pool allocator
[8.902180] mtrr: type mismatch for c000,1000 old: write-back new: 
write-combining
[8.902184] nouveau  [ DRM] VRAM: 512 MiB
[8.902185] nouveau  [ DRM] GART: 512 MiB
[8.902188] nouveau  [ DRM] BIT BIOS found
[8.902190] nouveau  [ DRM] Bios version 70.08.45.00
[8.902192] nouveau  [ DRM] TMDS table version 2.0
[8.902194] nouveau  [ DRM] DCB version 4.0
[8.902196] nouveau  [ DRM] DCB outp 00: 02011300 
[8.902198] nouveau  [ DRM] DCB conn 01: 0100
[8.903540] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[8.903541] [drm] No driver support for vblank timestamp query.
[8.903545] nouveau  [ DRM] ACPI backlight interface available, not 
registering our own
[8.903938] nouveau  [ DRM] 3 available performance level(s)
[8.903941] nouveau  [ DRM] 0: core 50MHz shader 101MHz memory 135MHz 
voltage 830mV
[8.903943] nouveau  [ DRM] 1: c

Re: [PATCH] drivers/tty: Folding Android's keyreset driver in sysRQ

[Dmitry Torokhov]

On Tue, Oct 16, 2012 at 08:35:56PM -0700, Arve Hjønnevåg wrote:
> On Fri, Oct 5, 2012 at 12:48 PM, Mathieu Poirier
>  wrote:
> > On 12-10-05 12:16 PM, Dmitry Torokhov wrote:
> >> On Fri, Oct 05, 2012 at 11:59:29AM -0600, mathieu.poir...@linaro.org wrote:
> >>> From: "Mathieu J. Poirier" 
> >>>
> >>> Andrew,
> >>>
> >>> After requesting a number of changes that, to my understanding
> >>> have been implemented, I have not been able to get the attention
> >>> of the subsystem maintainer on this patch.
> >>>
> >>> If there are still issues, I'm open to making changes but I want
> >>> to make sure it doesn't get forgotten.  If there no objections,
> >>> would you consider queuint it ?
> >>
> >> Mathieu,
> >>
> >> I have the same objection as before: using platform device solely for
> >> the purpose of passing some data from board code to the driver. Surely
> >> there are other ways of passing this bit of data... What about, for
> >> example, making it an empty weak symbol so that board code could
> >> override it with strong one?
> >
> > Thanks for the comments - I will implement a weak function in the
> > keyreset driver.
> >
> 
> A weak symbol does not work. A single kernel can support multiple
> devices that have unique reset key combinations.

Such kernels will surely require device tree and I think everyone have
already agreed that DT is the proper way of supplying this data on newer
boards. So the weak symbol is for legacy boards that do not export
device tree data and thus require per-board kernels.

Thanks.

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

question about context switch on arm Linux

[caiyuqing]

hi, all.
I have some questions about context switch on arm Linux (my target is
ARMv7-a).
1. Does arm linux support FCSE to handle the context switch?
2. If using FCSE, that means the processes number limit is 128 and the
memory limit is 32MB per process, is that right?

Thanks
qing

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] extcon: trivial: kfree missed from remove path

[anish kumar]

From: anish kumar 

Extcon core doesn't free the memory when we do unregister.
Kfree is added in the remove path as it was missing.

Signed-off-by: anish kumar 
---
 drivers/extcon/extcon-max77693.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index e21387e..67bc9ab 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -762,6 +762,7 @@ static int __devexit max77693_muic_remove(struct 
platform_device *pdev)
free_irq(muic_irqs[i].virq, info);
cancel_work_sync(&info->irq_work);
extcon_dev_unregister(info->edev);
+   kfree(info->edev);
kfree(info);
 
return 0;
-- 
1.7.1

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

Re: [PATCH] extcon: driver model release call not needed

[anish kumar]

Hi Choi,

This is based on http://git.infradead.org/users/kmpark/linux-samsung
this branch.
anish
On Sun, 2012-10-21 at 13:46 +0900, anish kumar wrote:
> From: anish kumar 
> 
> There was a case where free and list_del can be called twice
> on the same pointer.So fixed it by re-arranging the code and
> removing a function which was not needed.
> 
> Signed-off-by: anish kumar 
> ---
>  drivers/extcon/extcon-class.c |   71 
> ++---
>  1 files changed, 31 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index 754f133..347db10 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -544,47 +544,10 @@ static int create_extcon_class(void)
>   return 0;
>  }
>  
> -static void extcon_cleanup(struct extcon_dev *edev, bool skip)
> -{
> - mutex_lock(&extcon_dev_list_lock);
> - list_del(&edev->entry);
> - mutex_unlock(&extcon_dev_list_lock);
> -
> - if (!skip && get_device(edev->dev)) {
> - int index;
> -
> - if (edev->mutually_exclusive && edev->max_supported) {
> - for (index = 0; edev->mutually_exclusive[index];
> -  index++)
> - kfree(edev->d_attrs_muex[index].attr.name);
> - kfree(edev->d_attrs_muex);
> - kfree(edev->attrs_muex);
> - }
> -
> - for (index = 0; index < edev->max_supported; index++)
> - kfree(edev->cables[index].attr_g.name);
> -
> - if (edev->max_supported) {
> - kfree(edev->extcon_dev_type.groups);
> - kfree(edev->cables);
> - }
> -
> -#if defined(CONFIG_ANDROID)
> - if (switch_class)
> - class_compat_remove_link(switch_class, edev->dev, NULL);
> -#endif
> - device_unregister(edev->dev);
> - put_device(edev->dev);
> - }
> -
> - kfree(edev->dev);
> -}
> -
>  static void extcon_dev_release(struct device *dev)
>  {
> - struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev);
> -
> - extcon_cleanup(edev, true);
> + struct extcon_dev *edev = dev_get_drvdata(dev);
> + kfree(edev->dev);
>  }
>  
>  static const char *muex_name = "mutually_exclusive";
> @@ -810,7 +773,35 @@ EXPORT_SYMBOL_GPL(extcon_dev_register);
>   */
>  void extcon_dev_unregister(struct extcon_dev *edev)
>  {
> - extcon_cleanup(edev, false);
> + mutex_lock(&extcon_dev_list_lock);
> + list_del(&edev->entry);
> + mutex_unlock(&extcon_dev_list_lock);
> +
> + if (get_device(edev->dev) != NULL) {
> + int index;
> + if (edev->mutually_exclusive && edev->max_supported) {
> + for (index = 0; edev->mutually_exclusive[index];
> + index++)
> + kfree(edev->d_attrs_muex[index].attr.name);
> + kfree(edev->d_attrs_muex);
> + kfree(edev->attrs_muex);
> + }
> +
> + for (index = 0; index < edev->max_supported; index++)
> + kfree(edev->cables[index].attr_g.name);
> +
> + if (edev->max_supported) {
> + kfree(edev->extcon_dev_type.groups);
> + kfree(edev->cables);
> + }
> +
> +#if defined(CONFIG_ANDROID)
> + if (switch_class)
> + class_compat_remove_link(switch_class, edev->dev, NULL);
> +#endif
> + device_unregister(edev->dev);
> + put_device(edev->dev);
> + }
>  }
>  EXPORT_SYMBOL_GPL(extcon_dev_unregister);
>  


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] extcon: driver model release call not needed

[anish kumar]

From: anish kumar 

There was a case where free and list_del can be called twice
on the same pointer.So fixed it by re-arranging the code and
removing a function which was not needed.

Signed-off-by: anish kumar 
---
 drivers/extcon/extcon-class.c |   71 ++---
 1 files changed, 31 insertions(+), 40 deletions(-)

diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 754f133..347db10 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -544,47 +544,10 @@ static int create_extcon_class(void)
return 0;
 }
 
-static void extcon_cleanup(struct extcon_dev *edev, bool skip)
-{
-   mutex_lock(&extcon_dev_list_lock);
-   list_del(&edev->entry);
-   mutex_unlock(&extcon_dev_list_lock);
-
-   if (!skip && get_device(edev->dev)) {
-   int index;
-
-   if (edev->mutually_exclusive && edev->max_supported) {
-   for (index = 0; edev->mutually_exclusive[index];
-index++)
-   kfree(edev->d_attrs_muex[index].attr.name);
-   kfree(edev->d_attrs_muex);
-   kfree(edev->attrs_muex);
-   }
-
-   for (index = 0; index < edev->max_supported; index++)
-   kfree(edev->cables[index].attr_g.name);
-
-   if (edev->max_supported) {
-   kfree(edev->extcon_dev_type.groups);
-   kfree(edev->cables);
-   }
-
-#if defined(CONFIG_ANDROID)
-   if (switch_class)
-   class_compat_remove_link(switch_class, edev->dev, NULL);
-#endif
-   device_unregister(edev->dev);
-   put_device(edev->dev);
-   }
-
-   kfree(edev->dev);
-}
-
 static void extcon_dev_release(struct device *dev)
 {
-   struct extcon_dev *edev = (struct extcon_dev *) dev_get_drvdata(dev);
-
-   extcon_cleanup(edev, true);
+   struct extcon_dev *edev = dev_get_drvdata(dev);
+   kfree(edev->dev);
 }
 
 static const char *muex_name = "mutually_exclusive";
@@ -810,7 +773,35 @@ EXPORT_SYMBOL_GPL(extcon_dev_register);
  */
 void extcon_dev_unregister(struct extcon_dev *edev)
 {
-   extcon_cleanup(edev, false);
+   mutex_lock(&extcon_dev_list_lock);
+   list_del(&edev->entry);
+   mutex_unlock(&extcon_dev_list_lock);
+
+   if (get_device(edev->dev) != NULL) {
+   int index;
+   if (edev->mutually_exclusive && edev->max_supported) {
+   for (index = 0; edev->mutually_exclusive[index];
+   index++)
+   kfree(edev->d_attrs_muex[index].attr.name);
+   kfree(edev->d_attrs_muex);
+   kfree(edev->attrs_muex);
+   }
+
+   for (index = 0; index < edev->max_supported; index++)
+   kfree(edev->cables[index].attr_g.name);
+
+   if (edev->max_supported) {
+   kfree(edev->extcon_dev_type.groups);
+   kfree(edev->cables);
+   }
+
+#if defined(CONFIG_ANDROID)
+   if (switch_class)
+   class_compat_remove_link(switch_class, edev->dev, NULL);
+#endif
+   device_unregister(edev->dev);
+   put_device(edev->dev);
+   }
 }
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
-- 
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: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot

[Jacob Shin]

On Sat, Oct 20, 2012 at 09:01:43PM -0700, Yinghai Lu wrote:
> On Sat, Oct 20, 2012 at 5:17 PM, Tom Rini  wrote:
> > On 10/20/12 17:11, Shin, Jacob wrote:
> >> Hi could you please attach the dmesg output? Before rc2 is fine as well.
> >> I would like to see the E820 table. Thank you,
> >
> > dmesg is quite long so I've put it on pastebin: http://pastebin.com/4eSPEAvB
> >
> > --
> 
> [0.00] BIOS-e820: [mem 0x00011000-0x00042fff] usable
> 
> pre-calculate table size is too small, so it crashes.

Right,

I think just this one patch 3/6 on top of -rc2 should work:

https://lkml.org/lkml/2012/8/29/223

That would be a simpler path for 3.7,

Thanks!

> 
> can you please try
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-x86-mm
> 
> and post bootlog?
> 
> Thanks
> 
> Yinghai
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5 v6] gpio: Add sysfs support to block GPIO API

[Greg KH]

On Sat, Oct 20, 2012 at 12:21:45PM +0200, Roland Stigge wrote:
> This patch adds sysfs support to the block GPIO API.
> 
> Signed-off-by: Roland Stigge 

Thanks for the updates, looks good to me:

Signed-off-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Perf] Adding timeout option

[abhishek agarwal]

sleep does not offer a good timeout resolution and it is not a good
option (according to me) either.
perfmon had "timeout" option and i guess, same do oprofile.

On Sat, Oct 20, 2012 at 1:58 AM, Pádraig Brady  wrote:
> On 10/13/2012 08:54 AM, abhishek agarwal wrote:
>>
>> Hi folks..
>>
>> I was thinking that why cant we have a timeout option in perf stat
>> command.  The timeout feature will help us to profile a process for a
>> stipulated time (preferably in millisecs) and make perf stat return
>> after that time.
>> Eg:
>>
>> perf stat --timeout=10 sleep 100
>>
>> This will make perf return and report stats after 10 ms...
>>
>> Hope anyone can shed some more light on the idea
>
>
> It seems preferable to use the timeout program to do this.
> Either sending a handled signal to the perf process like:
>
> timeout -s HUP 10 perf stat sleep 100
>
> Or even better, just use that to kill the monitored process itself
>
> perf stat timeout 10 sleep 100
>
> cheers,
> Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot

[Yinghai Lu]

On Sat, Oct 20, 2012 at 5:17 PM, Tom Rini  wrote:
> On 10/20/12 17:11, Shin, Jacob wrote:
>> Hi could you please attach the dmesg output? Before rc2 is fine as well.
>> I would like to see the E820 table. Thank you,
>
> dmesg is quite long so I've put it on pastebin: http://pastebin.com/4eSPEAvB
>
> --

[0.00] BIOS-e820: [mem 0x00011000-0x00042fff] usable

pre-calculate table size is too small, so it crashes.

can you please try

git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-x86-mm

and post bootlog?

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] Linux KVM tool for v3.7-rc0

[Yinghai Lu]

On Sat, Oct 20, 2012 at 8:07 PM, Dave Airlie  wrote:
>
> Why couldn't this script just be a wrapper around qemu?
>
> I get the kvm developers developing features that isn't ideal, but for
> the quick boot a kernel tests, I don't see why a well maintained qemu
> wrapper isn't superior. I hate constructing qemu command lines, but a
> script in the kernel repo seems like a good idea.

you can build one iso like:

make isoimage FDARGS="ignore_loglevel debug initcall_debug
acpi.debug_layer=0x pci=routeirq apic=debug
ramdisk_size=262144 root=/dev/ram0 rw ip=dhcp
console=uart8250,io,0x3f8,115200"
FDINITRD=/home/yhlu/xx/xx/rootfs/mydisk14_x86_64_xz.xz

then use kvm to load that iso

/usr/local/kvm/bin/qemu-system-x86_64 -L /usr/local/kvm/share/qemu -m
6144 -net nic,model=e1000,macaddr=00:1c:25:1c:13:e9 -net user -smp 2
-cdrom /home/yhlu/xx/xx/kernel/tip/linux-2.6/arch/x86/boot/image.iso
-boot d -serial telnet:127.0.0.1:,server -monitor stdio

later could use
  telnet 127.0.0.1 
in another terminal to get serial console.

and initrd is converted from opensuse rescue initrd.

hope we can have scripts to create standalone initrd with updated user
program etc.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] Linux KVM tool for v3.7-rc0

[Dave Airlie]

On Sun, Oct 21, 2012 at 4:14 AM, Borislav Petkov  wrote:
> On Sat, Oct 20, 2012 at 06:04:36PM +1100, Stephen Rothwell wrote:
>> So are there any compelling arguments from the proponents, or can
>> I remove this from linux-next (and have it removed from the tip
>> auto-latest branch)?
>
> FWIW, I gave this a run and I have to say, it works as advertized: I
> built it and ran it with the latest kernel and the thing simply boots
> the kernel. Even without a disk image - the simplest command is:
>
> $ ./lkvm run --kernel ../../arch/x86/boot/bzImage
>
> and it gets me a shell in the vm after a second.
>
> So the absolute advantage it gives kernel devs is that they can
> smoke-test whether their stuff boots in seconds.
>
> This is probably not helpful when enabling specific hw features but
> should be pretty helpful for generic arch stuff.

Why couldn't this script just be a wrapper around qemu?

I get the kvm developers developing features that isn't ideal, but for
the quick boot a kernel tests, I don't see why a well maintained qemu
wrapper isn't superior. I hate constructing qemu command lines, but a
script in the kernel repo seems like a good idea.

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

Re: question on NUMA page migration

[Rik van Riel]

On 10/20/2012 10:39 PM, Ni zhan Chen wrote:

On 10/19/2012 11:53 PM, Rik van Riel wrote:

Hi Andrea, Peter,

I have a question on page refcounting in your NUMA
page migration code.

In Peter's case, I wonder why you introduce a new
MIGRATE_FAULT migration mode. If the normal page
migration / compaction logic can do without taking
an extra reference count, why does your code need it?


Hi Rik van Riel,

This is which part of codes? Why I can't find MIGRATE_FAULT in latest
v3.7-rc2?


It is in tip.git in the numa/core branch.


--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: question on NUMA page migration

[Ni zhan Chen]

On 10/19/2012 11:53 PM, Rik van Riel wrote:

Hi Andrea, Peter,

I have a question on page refcounting in your NUMA
page migration code.

In Peter's case, I wonder why you introduce a new
MIGRATE_FAULT migration mode. If the normal page
migration / compaction logic can do without taking
an extra reference count, why does your code need it?


Hi Rik van Riel,

This is which part of codes? Why I can't find MIGRATE_FAULT in latest 
v3.7-rc2?


Regards,
Chen



In Andrea's case, we have a comment suggesting an
extra refcount is needed, immediately followed by
a put_page:

/*
 * Pin the head subpage at least until the first
 * __isolate_lru_page succeeds (__isolate_lru_page pins it
 * again when it succeeds). If we unpin before
 * __isolate_lru_page successd, the page could be freed and
 * reallocated out from under us. Thus our previous checks on
 * the page, and the split_huge_page, would be worthless.
 *
 * We really only need to do this if "ret > 0" but it doesn't
 * hurt to do it unconditionally as nobody can reference
 * "page" anymore after this and so we can avoid an "if (ret >
 * 0)" branch here.
 */
put_page(page);

This also confuses me.

If we do not need the extra refcount (and I do not
understand why NUMA migrate-on-fault needs one more
refcount than normal page migration), we can get
rid of the MIGRATE_FAULT mode.

If we do need the extra refcount, why is normal
page migration safe? :)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Alan Stern]

On Sat, 20 Oct 2012, Artem S. Tashkinov wrote:

> You don't get me - I have *no* VirtualBox (or any proprietary) modules running
> - but I can reproduce this problem using *the same system running under* 
> VirtualBox
> in Windows 7 64.
> 
> It's almost definitely either a USB driver bug or video4linux driver bug:

Does the same thing happen with earlier kernel versions?

What about if you unload snd-usb-audio or ehci-hcd?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: android: checkpatch.pl fixes

[Joe Perches]

On Sun, 2012-10-21 at 12:05 +1000, Cruz Julian Bishop wrote:
> is there currently any way to insert, say,
> a comment that filters out the next line for checkpatch
> errors?
> 
> For example,
> 
> /* checkpatch_ignore_(rulename) */
> (Long line that can't be broken here)

Nope.  checkpatch is a stupid little tool.
It has its place, but it's a very limited one.

If you want to extend it, knock your self out...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: android: checkpatch.pl fixes

[Cruz Julian Bishop]

On Sat, 2012-10-20 at 18:05 -0700, Joe Perches wrote:
> On Sat, 2012-10-20 at 23:33 +0100, Ken O'Brien wrote:
> > Fixed all instances of strings spanning multiple lines from checkpatch.pl.
> []
> > diff --git a/drivers/staging/android/binder.c 
> > b/drivers/staging/android/binder.c
> []
> > @@ -556,7 +556,7 @@ static int binder_update_page_range(struct binder_proc 
> > *proc, int allocate,
> > goto free_range;
> >  
> > if (vma == NULL) {
> > -   pr_err("binder: %d: binder_alloc_buf failed to "
> > +   pr_err("binder: %d: binder_alloc_buf failed to " \
> >"map pages in userspace, no vma\n", proc->pid);
> 
> Hi Ken.
> 
> Nice try, but the "right" way to do this is to coalesce formats like:
> 
>   pr_err("binder: %d: binder_alloc_buf failed to map pages in 
> userspace, no vma\n",
>  proc->pid);
> 
> and ignore 80 column line lengths for these coalesced formats.

Going off that, is there currently any way to insert, say,
a comment that filters out the next line for checkpatch
errors?

For example,

/* checkpatch_ignore_(rulename) */
(Long line that can't be broken here)


> 
> An even better way is to add
> 
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> 
> before any #include and change the format to:
> 
>   pr_err("%d: binder_alloc_buf failed to map pages in userspace, 
> no vma\n",
>  proc->pid);
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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] module_signing: fix printk format warning

[Randy Dunlap]

From: Randy Dunlap 

kernel/module_signing.c:195:2: warning: format '%lu' expects type 'long 
unsigned int', but argument 3 has type 'size_t'

Signed-off-by: Randy Dunlap 
Cc: David Howells 
---
 kernel/module_signing.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-37-rc2.orig/kernel/module_signing.c
+++ lnx-37-rc2/kernel/module_signing.c
@@ -192,7 +192,7 @@ int mod_verify_sig(const void *mod, unsi
size_t modlen = *_modlen, sig_len;
int ret;
 
-   pr_devel("==>%s(,%lu)\n", __func__, modlen);
+   pr_devel("==>%s(,%zu)\n", __func__, modlen);
 
if (modlen <= sizeof(ms))
return -EBADMSG;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Artem S. Tashkinov]

> On Oct 21, 2012, Borislav Petkov wrote: 
> 
> On Sat, Oct 20, 2012 at 11:15:17PM +, Artem S. Tashkinov wrote:
> > You don't get me - I have *no* VirtualBox (or any proprietary) modules
> > running
> 
> Ok, good. We got that out of the way - I wanted to make sure after you
> replied with two other possibilities of the system freezing.
> 
> > - but I can reproduce this problem using *the same system running
> > under* VirtualBox in Windows 7 64.
> 
> That's windoze as host and linux as a guest, correct?

Exactly.

> If so, that's virtualbox's problem, I'd say.

I can reproduce it on my host *alone* as I said in the very first message - 
never
before I tried to run my Linux in a virtual machine. Please, just forget about
VirtualBox - it has nothing to do with this problem.

> > It's almost definitely either a USB driver bug or video4linux driver
> > bug:
> 
> And you're assuming that because the freeze happens when using your usb
> webcam, correct? And not otherwise?

Yes, like I said earlier - only when I try to access its settings using Adobe 
Flash the
system crashes/freezes.

> Maybe you can describe in more detail what exactly you're doing so that
> people could try to reproduce your issue.

I don't think many people have the same webcam so it's going to be a problem. It
can be reproduced easily - just open Flash "Settings" in Google Chrome 22. The
crash will occur immediately.

> > I'm CC'ing linux-media and linux-usb mailing lists, the problem is 
> > described here:
> > https://lkml.org/lkml/2012/10/20/35
> > https://lkml.org/lkml/2012/10/20/148
> 
> Yes, good idea. Maybe the folks there have some more ideas how to debug
> this.
> 
> I'm leaving in the rest for reference.
> 
> What should be pointed out, though, is that you don't have any more
> random corruptions causing oopses now that virtualbox is gone. The
> freeze below is a whole another issue.

The freeze happens on my *host* Linux PC. For an experiment I decided to
check if I could reproduce the freeze under a virtual machine - it turns out the
Linux kernel running under it also freezes.

Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] menuconfig: Replace CIRCLEQ by list_head-style lists.

[Yaakov (Cygwin/X)]

On Sat, 2012-10-20 at 13:56 -0400, Benjamin Poirier wrote:
> From: Benjamin Poirier 
> menuconfig: Replace CIRCLEQ by list_head-style lists
> 
> sys/queue.h and CIRCLEQ in particular have proven to cause portability
> problems (reported on Debian Sarge, Cygwin and FreeBSD)
> 
> Reported-by: Tetsuo Handa 
> Signed-off-by: Benjamin Poirier 


> From: "Yann E. MORIN" 
> kconfig: fix building the qconf frontend
> 
> Also, protect the whole file with the #ifdenf LIST_H, not only the
> macros
> defintions.
> 
> Signed-off-by: "Yann E. MORIN" 

Squash these two together and all frontends build again on Cygwin.

Tested-by: Yaakov Selkowitz 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] menuconfig: Replace CIRCLEQ by list_head-style lists.

[Tetsuo Handa]

Yann E. MORIN wrote:
> Benjamin, All,
> 
> On Saturday 20 October 2012 Benjamin Poirier wrote:
> > From: Benjamin Poirier 
> > 
> > sys/queue.h and CIRCLEQ in particular have proven to cause portability
> > problems (reported on Debian Sarge, Cygwin and FreeBSD)
> > 
> > Reported-by: Tetsuo Handa 
> > Signed-off-by: Benjamin Poirier 
> 
> Tested-by: "Yann E. MORIN" 
> 
> Thank you for this patch! I guess it is the best solution we can get.
> 
> Regards,
> Yann E. MORIN.

This patch solves my problem on Debian Sarge. Thank you.

Tested-by: Tetsuo Handa 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: android: checkpatch.pl fixes

[Joe Perches]

On Sat, 2012-10-20 at 23:33 +0100, Ken O'Brien wrote:
> Fixed all instances of strings spanning multiple lines from checkpatch.pl.
[]
> diff --git a/drivers/staging/android/binder.c 
> b/drivers/staging/android/binder.c
[]
> @@ -556,7 +556,7 @@ static int binder_update_page_range(struct binder_proc 
> *proc, int allocate,
>   goto free_range;
>  
>   if (vma == NULL) {
> - pr_err("binder: %d: binder_alloc_buf failed to "
> + pr_err("binder: %d: binder_alloc_buf failed to " \
>  "map pages in userspace, no vma\n", proc->pid);

Hi Ken.

Nice try, but the "right" way to do this is to coalesce formats like:

pr_err("binder: %d: binder_alloc_buf failed to map pages in 
userspace, no vma\n",
   proc->pid);

and ignore 80 column line lengths for these coalesced formats.

An even better way is to add

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

before any #include and change the format to:

pr_err("%d: binder_alloc_buf failed to map pages in userspace, 
no vma\n",
   proc->pid);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Borislav Petkov]

On Sat, Oct 20, 2012 at 11:15:17PM +, Artem S. Tashkinov wrote:
> You don't get me - I have *no* VirtualBox (or any proprietary) modules
> running

Ok, good. We got that out of the way - I wanted to make sure after you
replied with two other possibilities of the system freezing.

> - but I can reproduce this problem using *the same system running
> under* VirtualBox in Windows 7 64.

That's windoze as host and linux as a guest, correct?

If so, that's virtualbox's problem, I'd say.

> It's almost definitely either a USB driver bug or video4linux driver
> bug:

And you're assuming that because the freeze happens when using your usb
webcam, correct? And not otherwise?

Maybe you can describe in more detail what exactly you're doing so that
people could try to reproduce your issue.

> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described 
> here:
> https://lkml.org/lkml/2012/10/20/35
> https://lkml.org/lkml/2012/10/20/148

Yes, good idea. Maybe the folks there have some more ideas how to debug
this.

I'm leaving in the rest for reference.

What should be pointed out, though, is that you don't have any more
random corruptions causing oopses now that virtualbox is gone. The
freeze below is a whole another issue.

Thanks.

> Here are  the last lines from my dmesg (with usbmon loaded):
> 
> [  292.164833] hub 1-0:1.0: state 7 ports 8 chg  evt 0002
> [  292.168091] ehci_hcd :00:1f.5: GetStatus port:1 status 00100a 0  ACK 
> POWER sig=se0 PEC CSC
> [  292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
> [  292.174883] usb 1-1: USB disconnect, device number 2
> [  292.178045] usb 1-1: unregistering device
> [  292.183539] usb 1-1: unregistering interface 1-1:1.0
> [  292.197034] usb 1-1: unregistering interface 1-1:1.1
> [  292.204317] usb 1-1: unregistering interface 1-1:1.2
> [  292.234519] usb 1-1: unregistering interface 1-1:1.3
> [  292.236175] usb 1-1: usb_disable_device nuking all URBs
> [  292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 
> 0x100
> [  294.364279] hub 1-0:1.0: hub_suspend
> [  294.366045] usb usb1: bus auto-suspend, wakeup 1
> [  294.367375] ehci_hcd :00:1f.5: suspend root hub
> [  296.501084] usb usb1: usb wakeup-resume
> [  296.508311] usb usb1: usb auto-resume
> [  296.509833] ehci_hcd :00:1f.5: resume root hub
> [  296.560149] hub 1-0:1.0: hub_resume
> [  296.562240] ehci_hcd :00:1f.5: GetStatus port:1 status 001003 0  ACK 
> POWER sig=se0 CSC CONNECT
> [  296.566141] hub 1-0:1.0: port 1: status 0501 change 0001
> [  296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt 
> [  296.673222] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s
> [  297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd
> [  300.547237] usb 1-1: skipped 1 descriptor after configuration
> [  300.549443] usb 1-1: skipped 4 descriptors after interface
> [  300.552273] usb 1-1: skipped 2 descriptors after interface
> [  300.556499] usb 1-1: skipped 1 descriptor after endpoint
> [  300.559392] usb 1-1: skipped 2 descriptors after interface
> [  300.560960] usb 1-1: skipped 1 descriptor after endpoint
> [  300.562169] usb 1-1: skipped 2 descriptors after interface
> [  300.563440] usb 1-1: skipped 1 descriptor after endpoint
> [  300.564639] usb 1-1: skipped 2 descriptors after interface
> [  300.565828] usb 1-1: skipped 2 descriptors after endpoint
> [  300.567084] usb 1-1: skipped 9 descriptors after interface
> [  300.569205] usb 1-1: skipped 1 descriptor after endpoint
> [  300.570484] usb 1-1: skipped 53 descriptors after interface
> [  300.595843] usb 1-1: default language 0x0409
> [  300.602503] usb 1-1: USB interface quirks for this device: 2
> [  300.605700] usb 1-1: udev 3, busnum 1, minor = 2
> [  300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d
> [  300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, 
> SerialNumber=1
> [  300.613742] usb 1-1: SerialNumber: 48C5D2B0
> [  300.617703] usb 1-1: usb_probe_device
> [  300.620594] usb 1-1: configuration #1 chosen from 1 choice
> [  300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
> [  300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface
> [  300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id
> [  301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1)
> [  301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2)
> [  301.056934] uvcvideo 1-1:1.2: usb_probe_interface
> [  301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id
> [  301.059395] uvcvideo: Found UVC 1.00 device  (046d:081d)
> [  301.090173] input: UVC Camera (046d:081d) as 
> /devices/pci:00/:00:1f.5/usb1/1-1/1-1:1.2/input/input7
> [  301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3)
> [  301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> [  301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> [  301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule
> [  301.158

Re: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot

[Tom Rini]

On 10/20/12 17:11, Shin, Jacob wrote:
> Hi could you please attach the dmesg output? Before rc2 is fine as well.
> I would like to see the E820 table. Thank you,

dmesg is quite long so I've put it on pastebin: http://pastebin.com/4eSPEAvB

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot

[Tom Rini]

Hello all,

I grabbed 3.7-rc2 and found the following on boot:
PANIC: early exception 08 rip 246:10 error 81441d7f cr2 0

A git bisect says that this problems came from:
1e779aabe1f0768c2bf8f8c0a5583679b54a is the first bad commit
commit 1e779aabe1f0768c2bf8f8c0a5583679b54a
Author: Jacob Shin 
Date:   Thu Oct 20 16:15:26 2011 -0500

x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct 
mapping.

On systems with very large memory (1 TB in our case), BIOS may report a
reserved region or a hole in the E820 map, even above the 4 GB range. 
Exclude
these from the direct mapping.


The box in question is an Asus motherboard with AMD Phenom(tm) II X6
1100T and 16GB memory.  Happy to provide any other information required.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Artem S. Tashkinov]

You don't get me - I have *no* VirtualBox (or any proprietary) modules running
- but I can reproduce this problem using *the same system running under* 
VirtualBox
in Windows 7 64.

It's almost definitely either a USB driver bug or video4linux driver bug:

I'm CC'ing linux-media and linux-usb mailing lists, the problem is described 
here:
https://lkml.org/lkml/2012/10/20/35
https://lkml.org/lkml/2012/10/20/148

Here are  the last lines from my dmesg (with usbmon loaded):

[  292.164833] hub 1-0:1.0: state 7 ports 8 chg  evt 0002
[  292.168091] ehci_hcd :00:1f.5: GetStatus port:1 status 00100a 0  ACK 
POWER sig=se0 PEC CSC
[  292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
[  292.174883] usb 1-1: USB disconnect, device number 2
[  292.178045] usb 1-1: unregistering device
[  292.183539] usb 1-1: unregistering interface 1-1:1.0
[  292.197034] usb 1-1: unregistering interface 1-1:1.1
[  292.204317] usb 1-1: unregistering interface 1-1:1.2
[  292.234519] usb 1-1: unregistering interface 1-1:1.3
[  292.236175] usb 1-1: usb_disable_device nuking all URBs
[  292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 
0x100
[  294.364279] hub 1-0:1.0: hub_suspend
[  294.366045] usb usb1: bus auto-suspend, wakeup 1
[  294.367375] ehci_hcd :00:1f.5: suspend root hub
[  296.501084] usb usb1: usb wakeup-resume
[  296.508311] usb usb1: usb auto-resume
[  296.509833] ehci_hcd :00:1f.5: resume root hub
[  296.560149] hub 1-0:1.0: hub_resume
[  296.562240] ehci_hcd :00:1f.5: GetStatus port:1 status 001003 0  ACK 
POWER sig=se0 CSC CONNECT
[  296.566141] hub 1-0:1.0: port 1: status 0501 change 0001
[  296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt 
[  296.673222] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s
[  297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd
[  300.547237] usb 1-1: skipped 1 descriptor after configuration
[  300.549443] usb 1-1: skipped 4 descriptors after interface
[  300.552273] usb 1-1: skipped 2 descriptors after interface
[  300.556499] usb 1-1: skipped 1 descriptor after endpoint
[  300.559392] usb 1-1: skipped 2 descriptors after interface
[  300.560960] usb 1-1: skipped 1 descriptor after endpoint
[  300.562169] usb 1-1: skipped 2 descriptors after interface
[  300.563440] usb 1-1: skipped 1 descriptor after endpoint
[  300.564639] usb 1-1: skipped 2 descriptors after interface
[  300.565828] usb 1-1: skipped 2 descriptors after endpoint
[  300.567084] usb 1-1: skipped 9 descriptors after interface
[  300.569205] usb 1-1: skipped 1 descriptor after endpoint
[  300.570484] usb 1-1: skipped 53 descriptors after interface
[  300.595843] usb 1-1: default language 0x0409
[  300.602503] usb 1-1: USB interface quirks for this device: 2
[  300.605700] usb 1-1: udev 3, busnum 1, minor = 2
[  300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d
[  300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[  300.613742] usb 1-1: SerialNumber: 48C5D2B0
[  300.617703] usb 1-1: usb_probe_device
[  300.620594] usb 1-1: configuration #1 chosen from 1 choice
[  300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[  300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface
[  300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id
[  301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1)
[  301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2)
[  301.056934] uvcvideo 1-1:1.2: usb_probe_interface
[  301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id
[  301.059395] uvcvideo: Found UVC 1.00 device  (046d:081d)
[  301.090173] input: UVC Camera (046d:081d) as 
/devices/pci:00/:00:1f.5/usb1/1-1/1-1:1.2/input/input7
[  301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3)
[  301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
[  301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
[  301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule
[  301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
[  301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
[  301.196606] set resolution quirk: cval->res = 384
[  371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: 
RX
[  390.729568] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule
f5ade900 2296555[  390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
437 S Ii:1:003:7[  390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 
us]
 -115:128 16 <
f5ade900 2296566256 C Ii:1:003:7 -2:128 0
[  391.100896] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule
[  391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
f5ade900 2296926929 S Ii:1:003:7[  391.104889] usb 1-1: unlink 
qh16-0001/f48d64c0 start 2 [1/0 us]
 -115:128 16 <
f5ade900 2296937889 C Ii:1:003:7 -2:128 0
f5272300 2310382508 S Co:1:003:0 s 01 0b 0004 0001  0
f5272300 2310407888 C Co:1:003:0 0 0
f5272300 2310408051 S Co:1:003:0 s 22 01 0100 0086 

Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Borislav Petkov]

On Sat, Oct 20, 2012 at 10:32:28PM +0200, Pavel Machek wrote:
> On Sat 2012-10-20 17:41:49, Artem S. Tashkinov wrote:
> > On Oct 20, 2012, Borislav Petkov wrote: 
> > 
> > > Yeah, your kernel is tainted with a proprietary module (vbox*, etc). Can
> > > you reproduce your corruptions (this is what it looks like) without that
> > > module?
> > 
> > Yes, I can reproduce this panic with zero proprietary/non-free modules 
> > loaded.
> > 
> > The problem is the kernel doesn't even print a kernel panic - the
> > system just freezes completely - cursor in a text console stops
> > blinking.
> 
> bugtraq? :-).
> 
> If remote website can crash your Linux, that's quite significant news.
> 
> (Cc-ed netdev@ and security@ ... this may be important).

I don't think that's the problem - I rather suspect the fact that he's
using virtualbox which is causing random corruptions by writing to
arbitrary locations.

Artem,

please remove virtualbox completely from your system, rebuild the kernel
and make sure the virtualbox kernel modules don't get loaded - simply
delete them so that they are completely gone; *and* *then* retest again.

Thanks.

-- 
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] workqueue: remove unused argument of wq_worker_waking_up()

[Tejun Heo]

On Sun, Oct 21, 2012 at 01:30:07AM +0900, Joonsoo Kim wrote:
> Commit 63d95a91 ('workqueue: use @pool instead of @gcwq or @cpu where
> applicable') changes an approach to access nr_running.
> Thus, wq_worker_waking_up() doesn't use @cpu anymore.
> Remove it and remove comment related to it.
> 
> Signed-off-by: Joonsoo Kim 

I'm not sure whether I wanna remove or add WARN_ON_ONCE() on it.  That
part has gone through some changes and seen some bugs.  Can we please
do the following instead at least for now?

if (!(worker->flags & WORKER_NOT_RUNNING)) {
WARN_ON_ONCE(worker->pool->gcwq->cpu != cpu);
atomic_inc(get_pool_nr_running(worker->pool));
}

Thanks.

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

Re: [PATCH 2/3] workqueue: trivial fix for return statement in work_busy()

[Tejun Heo]

On Sun, Oct 21, 2012 at 01:30:06AM +0900, Joonsoo Kim wrote:
> Return type of work_busy() is unsigned int.
> There is return statement returning boolean value, 'false' in work_busy().
> It is not problem, because 'false' may be treated '0'.
> However, fixing it would make code robust.
> 
> Signed-off-by: Joonsoo Kim 

Applied 1-2 to wq/for-3.8.

Thanks.

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

Re: [PATCH cgroup/for-3.7-fixes 1/2] Revert "cgroup: Remove task_lock() from cgroup_post_fork()"

[Tejun Heo]

Hello, Frederic.

On Sat, Oct 20, 2012 at 02:21:43PM -0400, Frederic Weisbecker wrote:
> CPU 0
> CPU 1
> 
> cgroup_task_migrate {
> task_lock(p)
> rcu_assign_pointer(tsk->cgroups, newcg);
> task_unlock(tsk);
> 
> write_lock(&css_set_lock);
> if (!list_empty(&tsk->cg_list))
> list_move(&tsk->cg_list, &newcg->tasks);
> write_unlock(&css_set_lock);
> 
>   write_lock(&css_set_lock);
>   put_css_set(oldcg);
>  list_add(&child->cg_list, &child->cgroups->tasks); (1)

Man, that's confusing. :)

> On (1), child->cgroups should have the value of newcg and not oldcg
> due to the memory ordering implied by the locking of css_set_lock. Now
> I can't guarantee that because I'm no memory ordering expert. And even
> if it's safe, it's so very non obvious that I now agree with you:
> let's revert  the patch and restart with a better base by gathering
> all the cgroup fork code in the current cgroup_post_fork place.

Aye aye, let's move everything to cgroup_post_fork() and then we don't
have to worry about grabbing task_lock multiple times.

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/

[PATCH 2/2] staging: android: binder.c: checkpatch.pl

[Ken O'Brien]

Fixed 3 instances of "WARNING: static const char * array should probably be 
static const char * const" warnings from checkpatch

Signed-off-by: Ken O'Brien 
---
 drivers/staging/android/binder.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index 8607628..b17f9ba 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -3218,7 +3218,7 @@ static void print_binder_proc(struct seq_file *m,
m->count = start_pos;
 }
 
-static const char *binder_return_strings[] = {
+static const char *const binder_return_strings[] = {
"BR_ERROR",
"BR_OK",
"BR_TRANSACTION",
@@ -3239,7 +3239,7 @@ static const char *binder_return_strings[] = {
"BR_FAILED_REPLY"
 };
 
-static const char *binder_command_strings[] = {
+static const char *const binder_command_strings[] = {
"BC_TRANSACTION",
"BC_REPLY",
"BC_ACQUIRE_RESULT",
@@ -3259,7 +3259,7 @@ static const char *binder_command_strings[] = {
"BC_DEAD_BINDER_DONE"
 };
 
-static const char *binder_objstat_strings[] = {
+static const char *const binder_objstat_strings[] = {
"proc",
"thread",
"node",
-- 
1.7.12.4

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

[PATCH 1/2] staging: android: checkpatch.pl fixes

[Ken O'Brien]

Fixed all instances of strings spanning multiple lines from checkpatch.pl.

Signed-off-by: Ken O'Brien 
---
 drivers/staging/android/binder.c | 148 +++
 1 file changed, 74 insertions(+), 74 deletions(-)

diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index 7b0ba92..8607628 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -556,7 +556,7 @@ static int binder_update_page_range(struct binder_proc 
*proc, int allocate,
goto free_range;
 
if (vma == NULL) {
-   pr_err("binder: %d: binder_alloc_buf failed to "
+   pr_err("binder: %d: binder_alloc_buf failed to " \
   "map pages in userspace, no vma\n", proc->pid);
goto err_no_vma;
}
@@ -569,7 +569,7 @@ static int binder_update_page_range(struct binder_proc 
*proc, int allocate,
BUG_ON(*page);
*page = alloc_page(GFP_KERNEL | __GFP_ZERO);
if (*page == NULL) {
-   pr_err("binder: %d: binder_alloc_buf failed "
+   pr_err("binder: %d: binder_alloc_buf failed " \
   "for page at %p\n", proc->pid, page_addr);
goto err_alloc_page_failed;
}
@@ -578,7 +578,7 @@ static int binder_update_page_range(struct binder_proc 
*proc, int allocate,
page_array_ptr = page;
ret = map_vm_area(&tmp_area, PAGE_KERNEL, &page_array_ptr);
if (ret) {
-   pr_err("binder: %d: binder_alloc_buf failed "
+   pr_err("binder: %d: binder_alloc_buf failed " \
   "to map page at %p in kernel\n",
   proc->pid, page_addr);
goto err_map_kernel_failed;
@@ -587,7 +587,7 @@ static int binder_update_page_range(struct binder_proc 
*proc, int allocate,
(uintptr_t)page_addr + proc->user_buffer_offset;
ret = vm_insert_page(vma, user_page_addr, page[0]);
if (ret) {
-   pr_err("binder: %d: binder_alloc_buf failed "
+   pr_err("binder: %d: binder_alloc_buf failed " \
   "to map page at %lx in userspace\n",
   proc->pid, user_page_addr);
goto err_vm_insert_page_failed;
@@ -645,7 +645,7 @@ static struct binder_buffer *binder_alloc_buf(struct 
binder_proc *proc,
ALIGN(offsets_size, sizeof(void *));
 
if (size < data_size || size < offsets_size) {
-   binder_user_error("binder: %d: got transaction with invalid "
+   binder_user_error("binder: %d: got transaction with invalid " \
"size %zd-%zd\n", proc->pid, data_size, offsets_size);
return NULL;
}
@@ -674,7 +674,7 @@ static struct binder_buffer *binder_alloc_buf(struct 
binder_proc *proc,
}
}
if (best_fit == NULL) {
-   pr_err("binder: %d: binder_alloc_buf size %zd failed, "
+   pr_err("binder: %d: binder_alloc_buf size %zd failed, " \
   "no address space\n", proc->pid, size);
return NULL;
}
@@ -909,7 +909,7 @@ static int binder_inc_node(struct binder_node *node, int 
strong, int internal,
node->internal_strong_refs == 0 &&
!(node == binder_context_mgr_node &&
node->has_strong_ref)) {
-   pr_err("binder: invalid inc strong "
+   pr_err("binder: invalid inc strong " \
"node for %d\n", node->debug_id);
return -EINVAL;
}
@@ -925,7 +925,7 @@ static int binder_inc_node(struct binder_node *node, int 
strong, int internal,
node->local_weak_refs++;
if (!node->has_weak_ref && list_empty(&node->work.entry)) {
if (target_list == NULL) {
-   pr_err("binder: invalid inc weak node "
+   pr_err("binder: invalid inc weak node " \
"for %d\n", node->debug_id);
return -EINVAL;
}
@@ -1118,7 +1118,7 @@ static int binder_dec_ref(struct binder_ref *ref, int 
strong)
 {
if (strong) {
if (ref->strong == 0) {
-   binder_user_error("binder: %d invalid dec strong, "
+   binder_user_error("binder: %d invalid dec strong, " \
  "ref %d desc %d s %d w %d\n",
  ref->proc->pid, ref->debug_id,
  ref->de

[PATCH] kconfig: fix building the qconf frontend

[Yann E. MORIN]

 - 'offsetof' is already defined in stddef
- to avoid issues with old systems still missing offsetof, just protect
  our definition between #ifndef...#endif

 - 'new' is a reserved keyword in C++:
- rename the variable
- protect the whole file with the usual #ifdef __cplusplus construct

Also, protect the whole file with the #ifdenf LIST_H, not only the macros
defintions.

Signed-off-by: "Yann E. MORIN" 
Cc: Benjamin Poirier 
---
 scripts/kconfig/list.h |   30 --
 1 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/scripts/kconfig/list.h b/scripts/kconfig/list.h
index 934bdba..c4fc349 100644
--- a/scripts/kconfig/list.h
+++ b/scripts/kconfig/list.h
@@ -5,7 +5,13 @@
  * Copied from include/linux/...
  */
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#ifndef offsetof
 #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
+#endif
 
 /**
  * container_of - cast a member of a structure out to the containing structure
@@ -49,8 +55,6 @@ struct list_head {
 &pos->member != (head);\
 pos = list_entry(pos->member.next, typeof(*pos), member))
 
-#endif
-
 /**
  * list_empty - tests whether a list is empty
  * @head: the list to test.
@@ -66,25 +70,31 @@ static inline int list_empty(const struct list_head *head)
  * This is only for internal list manipulation where we know
  * the prev/next entries already!
  */
-static inline void __list_add(struct list_head *new,
+static inline void __list_add(struct list_head *new_e,
  struct list_head *prev,
  struct list_head *next)
 {
-   next->prev = new;
-   new->next = next;
-   new->prev = prev;
-   prev->next = new;
+   next->prev = new_e;
+   new_e->next = next;
+   new_e->prev = prev;
+   prev->next = new_e;
 }
 
 /**
  * list_add_tail - add a new entry
- * @new: new entry to be added
+ * @new_e: new entry to be added
  * @head: list head to add it before
  *
  * Insert a new entry before the specified head.
  * This is useful for implementing queues.
  */
-static inline void list_add_tail(struct list_head *new, struct list_head *head)
+static inline void list_add_tail(struct list_head *new_e, struct list_head 
*head)
 {
-   __list_add(new, head->prev, head);
+   __list_add(new_e, head->prev, head);
 }
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* LIST_H */
-- 
1.7.2.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: Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote: 
> 
> > Try this one.
> 
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
> 
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> minor 0
> [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution 
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon

Hmm, maybe we can't fetch 3 bytes only...

Let's check this:

---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index 824eea0..8bd71aa 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -192,14 +192,16 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
 {
struct pci_dev *pdev = nv_device(bios)->pdev;
int ret, cnt, i;
-   u8  data[3];
+   u8  *data;
 
if (!nouveau_acpi_rom_supported(pdev))
return;
 
bios->size = 0;
-   if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
+   data = kmalloc(4096, GFP_KERNEL);
+   if (data && nouveau_acpi_get_bios_chunk(data, 0, 4096) >= 3)
bios->size = data[2] * 512;
+   kfree(data);
if (!bios->size)
return;
 
---

Please attach acpidump output.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] menuconfig: Replace CIRCLEQ by list_head-style lists.

[Yann E. MORIN]

Benjamin, All,

On Saturday 20 October 2012 Benjamin Poirier wrote:
> From: Benjamin Poirier 
> 
> sys/queue.h and CIRCLEQ in particular have proven to cause portability
> problems (reported on Debian Sarge, Cygwin and FreeBSD)
> 
> Reported-by: Tetsuo Handa 
> Signed-off-by: Benjamin Poirier 

Sorry for my earlier optimistic reply, but...

While menuconfig got fixed with this patch, xconfig is now broken:

First issue:
In file included from /home/ymorin/dev/linux/scripts/kconfig/expr.h:15,
 from /home/ymorin/dev/linux/scripts/kconfig/lkc.h:9,
 from /home/ymorin/dev/linux/scripts/kconfig/qconf.cc:45:
/home/ymorin/dev/linux/scripts/kconfig/list.h:8:1: warning: "offsetof"
redefined
In file included from /usr/include/_G_config.h:15,
 from /usr/include/libio.h:32,
 from /usr/include/stdio.h:75,
 from /usr/include/qt4/QtCore/qtextstream.h:57,
 from /usr/include/qt4/Qt3Support/q3mainwindow.h:47,
 from /home/ymorin/dev/linux/scripts/kconfig/qconf.cc:19:
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include/stddef.h:411:1: warning: this
is the location of the previous definition

[--SNIP--]
> diff --git a/scripts/kconfig/list.h b/scripts/kconfig/list.h
> new file mode 100644
> index 000..934bdba
> --- /dev/null
> +++ b/scripts/kconfig/list.h
> @@ -0,0 +1,90 @@
> +#ifndef LIST_H
> +#define LIST_H
> +
> +/*
> + * Copied from include/linux/...
> + */
> +
> +#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

We could #include , but then we may end up with issues with
old systems (which we are trying to fix!). I suggest we enclose the
definition between a 
#ifndef offsetof
...
#endif


Second issue:
We have further issues with some variable names:
/home/ymorin/dev/linux/scripts/kconfig/list.h:69: error: expected ‘,’ or
‘...’ before ‘new’

[--SNIP--]
> +static inline void __list_add(struct list_head *new,

'new' is a reserved key-word in C++, and xconfig is using qconf, which is
written in C++.

I 'd suggest to:
 1- rename the variable
 2- enclose the whole header in:
#ifdef __cplusplus
extern "C" {
#endif
[.]
#ifdef __cplusplus
}
#endif

Regards,
Yann E. MORIN.

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN |  ___   |
| +33 223 225 172 `.---:  X  AGAINST  |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|   v   conspiracy.  |
'--^---^--^'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Artem S. Tashkinov]

Hi,

I can only reproduce this panic when my USB webcamera is plugged in - when
I click settings in Adobe Flash it sends some commands to my USB webcam using,
presumably, Video4Linux API calls which cause a kernel hard crash.

Your kernel debug features haven't helped at all, even the virtual machine
crashes the way I cannot get any information from it - under Windows 7 64
VirtualBox becomes an unkillable process.

I've no idea what's crashing - it can be the kernel itself, or some of v4l or 
usb
modules.

Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] acpi/cpuidle: reinitialize power_usage values when adding/removing C-states

[Daniel Lezcano]

On 10/19/2012 11:50 PM, Julius Werner wrote:
> When cpuidle drivers do not supply explicit power_usage values,
> cpuidle/driver.c inserts dummy values instead. When a running processor
> dynamically gains new C-states (e.g. after ACPI events), the power_usage
> values of those states will stay uninitialized, and cpuidle governors
> will never choose to enter them.
> 
> This patch ensures that the ACPI cpuidle driver sets those dummy power
> values itself whenever it (re-)initializes its idle states.
> Tested and verified on an Acer AC700 Chromebook, which supports the C3
> state only when it switches from AC to battery power.
> 
> Signed-off-by: Julius Werner 
> ---

I am not against this patch but I am wondering if it is not time to do
some cleanup around this.

The flag 'power_specified' is never used in any driver.

And the field 'power_usage' is used only in the tegra3 driver where
logically as power_specified is not set, it will be overwritten at the
init (could someone could check the
/sys/devices/system/cpu/cpu0/cpuidle/state1/power is different from 600
on tegra3 ?)

The drivers define their states in a power consumption descendant order
making de facto the same ordering than the 'set_power_state' function in
driver.c

The governor looks at the power_usage (which is always filled by
'set_power_state').

static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device
*dev)

[ ... ]

if (s->power_usage < power_usage) {
power_usage = s->power_usage;
data->last_state_idx = i;
data->exit_us = s->exit_latency;
}

[ ... ]

Could we just say this is always true because state[i+1] consumes less
than state[i] ?

And then just remove the 'set_power_state' function, and the field
'driver->power_specified' ?

That will cleanup the code and fix this problem, no ?

Thanks
  -- Daniel

>  drivers/acpi/processor_idle.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index e8086c7..078e22f 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -1090,6 +1090,9 @@ static int acpi_processor_setup_cpuidle_states(struct 
> acpi_processor *pr)
>   state->exit_latency = cx->latency;
>   state->target_residency = cx->latency * latency_factor;
>  
> + /* reinitialize this in case new states are added after boot */
> + state->power_usage = -1 - count;
> +
>   state->flags = 0;
>   switch (cx->type) {
>   case ACPI_STATE_C1:


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 11:42:17PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote: 
> > 
> > > Try this one.
> > 
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your patch on top of 3.7-rc1 is:
> > 
> > [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> > minor 0
> > [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> > [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> > [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> > [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for 
> > image...
> > [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> > [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> > [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> > end of region [VROM] (length 24) (20120913/exfldio-210)
> > [3.704139] ACPI Error: Method parse/execution 
> > failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> > AE_AML_REGION_LIMIT (20120913/psparse-536)
> > [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> > [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for 
> > image...
> > [3.724111] nouveau :01:00.0: Invalid ROM contents
> > [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> > [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable 
> > image
> > [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 
> > 0x1001, -22
> > [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> > [3.736097] nouveau: probe of :01:00.0 failed with error -22
> > [3.740523] dracut: Starting plymouth daemon
> > 
> > And here's the same output with plain vanilla 3.6.2:
> > 
> > [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
> > (0x0a8800b1)
> > [3.599783] vga_switcheroo: enabled
> > [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
> > [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
> > [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
> > [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
> > [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
> > [3.856854] [drm] nouveau :01:00.0: ... appears to be valid
> > [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
> > [3.861907] [drm] nouveau :01:00.0: BIT BIOS found
> > [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
> > [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
> > [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
> > [3.870871] [drm] nouveau :01:00.0: DCB version 4.0
> > [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
> > [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
> > [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
> > [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
> > [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
> > [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
> > [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
> > [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
> > VBIOS init tables.
> > [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at 
> > offset 0xDECD
> > [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
> > [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at 
> > offset 0xE378
> > [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at 
> > offset 0xEF4B
> > [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at 
> > offset 0xEF64
> > [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at 
> > offset 0xF04B
> > [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at 
> > offset 0xF0B0
> > [4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
> > [4.019438] [TTM] Initializing pool allocator
> > [4.020694] [TTM] Initializing DMA pool allocator
> > [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
> > [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
> > [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> > [4.084909] [drm] No driver support for vblank timestamp query.
> > [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface 
> > available, not registering our own
> > 

Re: Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Marcin Slusarz wrote: 
> 
> > Try this one.
> 
> It works, now I can boot again. However, nouveau seems to be dead now.
> The dmesg output with your patch on top of 3.7-rc1 is:
> 
> [3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
> minor 0
> [3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
> [3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
> [3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
> [3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
> [3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
> [3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
> [3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond 
> end of region [VROM] (length 24) (20120913/exfldio-210)
> [3.704139] ACPI Error: Method parse/execution 
> failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), 
> AE_AML_REGION_LIMIT (20120913/psparse-536)
> [3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
> [3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
> [3.724111] nouveau :01:00.0: Invalid ROM contents
> [3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
> [3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
> [3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
> -22
> [3.734231] nouveau E[ DRM] failed to create 0x8080, -22
> [3.736097] nouveau: probe of :01:00.0 failed with error -22
> [3.740523] dracut: Starting plymouth daemon
> 
> And here's the same output with plain vanilla 3.6.2:
> 
> [3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
> (0x0a8800b1)
> [3.599783] vga_switcheroo: enabled
> [3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
> [3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
> [3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
> [3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
> [3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
> [3.856854] [drm] nouveau :01:00.0: ... appears to be valid
> [3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
> [3.861907] [drm] nouveau :01:00.0: BIT BIOS found
> [3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
> [3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
> [3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
> [3.870871] [drm] nouveau :01:00.0: DCB version 4.0
> [3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
> [3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
> [3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
> [3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
> [3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
> [3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
> [3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
> [3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
> VBIOS init tables.
> [3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at 
> offset 0xDECD
> [3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
> [3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at 
> offset 0xE378
> [3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at 
> offset 0xEF4B
> [3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at 
> offset 0xEF64
> [3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at 
> offset 0xF04B
> [3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
> 0xF0B0
> [4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
> [4.019438] [TTM] Initializing pool allocator
> [4.020694] [TTM] Initializing DMA pool allocator
> [4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
> [4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
> [4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [4.084909] [drm] No driver support for vblank timestamp query.
> [4.085985] [drm] nouveau :01:00.0: ACPI backlight interface 
> available, not registering our own
> [4.246449] [drm] nouveau :01:00.0: 3 available performance level(s)
> [4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz 
> memory 135MHz voltage 850mV
> [4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader

Re: [PATCH] RCU: update docs to include kfree_rcu()

[Paul E. McKenney]

On Fri, Oct 19, 2012 at 09:48:30AM -0700, Kees Cook wrote:
> Mention kfree_rcu() in the call_rcu() section. Additionally fix the
> example code for list replacement that used the wrong structure element.

Good catch!  Queued, and thank you for your review and feedback!  ;-)

Thanx, Paul

> Signed-off-by: Kees Cook 
> ---
>  Documentation/RCU/listRCU.txt   |2 +-
>  Documentation/RCU/whatisRCU.txt |   13 +++--
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt
> index 4349c14..adb5a37 100644
> --- a/Documentation/RCU/listRCU.txt
> +++ b/Documentation/RCU/listRCU.txt
> @@ -205,7 +205,7 @@ RCU ("read-copy update") its name.  The RCU code is as 
> follows:
>   audit_copy_rule(&ne->rule, &e->rule);
>   ne->rule.action = newaction;
>   ne->rule.file_count = newfield_count;
> - list_replace_rcu(e, ne);
> + list_replace_rcu(&e->list, &ne->list);
>   call_rcu(&e->rcu, audit_free_rule);
>   return 0;
>   }
> diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
> index bf0f6de..160ac55 100644
> --- a/Documentation/RCU/whatisRCU.txt
> +++ b/Documentation/RCU/whatisRCU.txt
> @@ -499,6 +499,8 @@ The foo_reclaim() function might appear as follows:
>   {
>   struct foo *fp = container_of(rp, struct foo, rcu);
> 
> + foo_cleanup(fp->a);
> +
>   kfree(fp);
>   }
> 
> @@ -521,6 +523,12 @@ oUse call_rcu() -after- removing a data element 
> from an
>   read-side critical sections that might be referencing that
>   data item.
> 
> +If the callback for call_rcu() is not doing anything more than calling
> +kfree() on the structure, you can use kfree_rcu() instead of call_rcu()
> +to avoid having to write your own callback:
> +
> + kfree_rcu(old_fp, rcu);
> +
>  Again, see checklist.txt for additional rules governing the use of RCU.
> 
> 
> @@ -773,8 +781,8 @@ a single atomic update, converting to RCU will require 
> special care.
> 
>  Also, the presence of synchronize_rcu() means that the RCU version of
>  delete() can now block.  If this is a problem, there is a callback-based
> -mechanism that never blocks, namely call_rcu(), that can be used in
> -place of synchronize_rcu().
> +mechanism that never blocks, namely call_rcu() or kfree_rcu(), that can
> +be used in place of synchronize_rcu().
> 
> 
>  7.  FULL LIST OF RCU APIs
> @@ -813,6 +821,7 @@ RCU:  Critical sections   Grace period
> Barrier
>   rcu_read_unlock synchronize_rcu
>   rcu_dereference synchronize_rcu_expedited
>   call_rcu
> + kfree_rcu
> 
> 
>  bh:  Critical sections   Grace periodBarrier
> -- 
> 1.7.9.5
> 
> 
> -- 
> Kees Cook
> Chrome OS Security
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] menuconfig: Replace CIRCLEQ by list_head-style lists.

[Yann E. MORIN]

Benjamin, All,

On Saturday 20 October 2012 Benjamin Poirier wrote:
> From: Benjamin Poirier 
> 
> sys/queue.h and CIRCLEQ in particular have proven to cause portability
> problems (reported on Debian Sarge, Cygwin and FreeBSD)
> 
> Reported-by: Tetsuo Handa 
> Signed-off-by: Benjamin Poirier 

Tested-by: "Yann E. MORIN" 

Thank you for this patch! I guess it is the best solution we can get.

Regards,
Yann E. MORIN.

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN |  ___   |
| +33 223 225 172 `.---:  X  AGAINST  |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|   v   conspiracy.  |
'--^---^--^'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3.7-rc1 (nouveau_bios_score oops).

[Heinz Diehl]

On 20.10.2012, Marcin Slusarz wrote: 

> Try this one.

It works, now I can boot again. However, nouveau seems to be dead now.
The dmesg output with your patch on top of 3.7-rc1 is:

[3.685909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[3.687784] nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x0a8800b1
[3.689960] nouveau  [  DEVICE][:01:00.0] Chipset: GT218 (NVA8)
[3.692471] nouveau  [  DEVICE][:01:00.0] Family : NV50
[3.695716] nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
[3.697087] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.698471] nouveau  [   VBIOS][:01:00.0] checking PROM for image...
[3.699838] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.701223] nouveau  [   VBIOS][:01:00.0] checking ACPI for image...
[3.702684] ACPI Error: Field [ROMI] Base+Offset+Width 0+24+1 is beyond end 
of region [VROM] (length 24) (20120913/exfldio-210)
[3.704139] ACPI Error: Method parse/execution 
failed[\_SB_.PCI0.PEG1.GFX0._ROM] (Node 880142e85cf8), AE_AML_REGION_LIMIT 
(20120913/psparse-536)
[3.716183] failed to evaluate ROM got AE_AML_REGION_LIMIT
[3.718776] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.721349] nouveau  [   VBIOS][:01:00.0] checking PCIROM for image...
[3.724111] nouveau :01:00.0: Invalid ROM contents
[3.726663] nouveau  [   VBIOS][:01:00.0] ... signature not found
[3.729159] nouveau E[   VBIOS][:01:00.0] unable to locate usable image
[3.731677] nouveau E[  DEVICE][:01:00.0] failed to create 0x1001, 
-22
[3.734231] nouveau E[ DRM] failed to create 0x8080, -22
[3.736097] nouveau: probe of :01:00.0 failed with error -22
[3.740523] dracut: Starting plymouth daemon

And here's the same output with plain vanilla 3.6.2:

[3.588791] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x0a8800b1)
[3.599783] vga_switcheroo: enabled
[3.601303] [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
[3.602817] [drm] nouveau :01:00.0: ... BIOS signature not found
[3.604294] [drm] nouveau :01:00.0: Checking PROM for VBIOS
[3.605822] [drm] nouveau :01:00.0: ... BIOS signature not found
[3.607310] [drm] nouveau :01:00.0: Checking ACPI for VBIOS
[3.856854] [drm] nouveau :01:00.0: ... appears to be valid
[3.859409] [drm] nouveau :01:00.0: Using VBIOS from ACPI
[3.861907] [drm] nouveau :01:00.0: BIT BIOS found
[3.864369] [drm] nouveau :01:00.0: Bios version 70.18.5d.00
[3.866829] [drm] nouveau :01:00.0: TMDS table version 2.0
[3.869479] [drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
[3.870871] [drm] nouveau :01:00.0: DCB version 4.0
[3.872220] [drm] nouveau :01:00.0: DCB outp 00: 02014300 
[3.873611] [drm] nouveau :01:00.0: DCB conn 00: 0040
[3.874994] [drm] nouveau :01:00.0: DCB conn 01: 00410146
[3.876367] [drm] nouveau :01:00.0: DCB conn 02: 1261
[3.877719] [drm] nouveau :01:00.0: DCB conn 03: 2330
[3.879043] [drm] nouveau :01:00.0: DCB conn 04: 0400
[3.880355] [drm] nouveau :01:00.0: DCB conn 05: 0560
[3.881662] [drm] nouveau :01:00.0: Adaptor not initialised, running 
VBIOS init tables.
[3.882961] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 
0xDECD
[3.936538] [drm] nouveau :01:00.0: 0xDE34: i2c wr fail: -6
[3.957932] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 
0xE378
[3.987046] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 
0xEF4B
[3.988396] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 
0xEF64
[3.990741] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 
0xF04B
[3.992020] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 
0xF0B0
[4.018084] [TTM] Zone  kernel: Available graphics memory: 1917766 kiB
[4.019438] [TTM] Initializing pool allocator
[4.020694] [TTM] Initializing DMA pool allocator
[4.021914] [drm] nouveau :01:00.0: Detected 1024MiB VRAM (DDR3)
[4.024515] [drm] nouveau :01:00.0: 512 MiB GART (aperture)
[4.083748] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.084909] [drm] No driver support for vblank timestamp query.
[4.085985] [drm] nouveau :01:00.0: ACPI backlight interface available, 
not registering our own
[4.246449] [drm] nouveau :01:00.0: 3 available performance level(s)
[4.247560] [drm] nouveau :01:00.0: 0: core 135MHz shader 270MHz memory 
135MHz voltage 850mV
[4.248707] [drm] nouveau :01:00.0: 1: core 405MHz shader 810MHz memory 
405MHz voltage 850mV
[4.249807] [drm] nouveau :01:00.0: 3: core 606MHz shader 1468MHz memory 
667MHz voltage 1000mV
[4.250946] [drm] nouveau :01:00.0: c: core 405MHz shader 810MHz memory 
405MHz
[4.

Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Artem S. Tashkinov]

On Oct 21, 2012, Borislav Petkov wrote: 

> Ok, here's what you can try:
> 
> * You say this happens with google chrome. Does it happen if you use
> another browser: firefox, etc?
> 
> * Can you build a 64-bit kernel and try the same with it? The 32-bit
> userspace should work in compat mode just fine.
> 
> * Can you run memtest on your machine and check whether your DIMMs
> aren't generating ECC errors? Are your DIMMs ECC, btw?
> ...


I can reproduce this problem in a virtual machine, which means I have found a 
real
kernel or GCC bug. Alas, VirtualBox 4.2.2 hangs entirely when I run this 
virtual machine -
I've never seen anything like that. Windows 7 64 bit which hosts this 
VirtualBox cannot
even kill a VirtualBox instance.

Unfortunately even though I run the kernel with "console=ttyS0,115200 
console=tty0"
parameters they don't help - I see no panic messages on a "virtual" serial 
port, which
looks like we've got a very deep freeze.

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

cryptsetup not working under 3.6 - regression from 3.4?

[Tvrtko Ursulin]

Hi all,

I can't open my LUKS formatted crypto files in 3.6 any more while 3.4 
works fine.


Error is:

# cryptsetup --key-file=- luksOpen /luks.file target
Enter passphrase:
device-mapper: reload ioctl on  failed: No such file or directory
Failed to setup dm-crypt key mapping for device /dev/loop0.
Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for 
more info).

Failed to read from key storage.

I don't think kernel misses any modules because:

a) I built 3.6 from 3.4 config via make oldconfig, and,
b) I checked what crypto modules get loaded under 3.4 and loaded them 
under 3.6 before attempting to run cryptsetup. Those are:


Module  Size  Used by
sha256_generic 10207  0
cryptd  8665  0
aes_x86_64  7614  0
aes_generic26764  1 aes_x86_64

I am not sure module auto-loading for crypto works under 3.6 because if 
I just run the cryptsetup command none of the above gets loaded.


But I repeat, even if I load the required modules before hand things do 
not work.


Kernel says this:
 device-mapper: table: 252:1: crypt: Error allocating crypto tfm
 device-mapper: ioctl: error adding target to table

And strace on cryptsetup says there DM ioctls are issued:
 ioctl(3, DM_VERSION, 0x1d65db0) = 0
 ioctl(3, DM_LIST_VERSIONS, 0x1d65d20) = 0
 ioctl(3, DM_TABLE_STATUS, 0x1d66730) = -1 ENXIO (No such device or 
address)

 ioctl(3, DM_DEV_CREATE, 0x1d78290) = 0
 ioctl(3, DM_TABLE_LOAD, 0x1d78290) = -1 ENOENT (No such file or directory)
 ioctl(3, DM_DEV_REMOVE, 0x1d781d0) = 0

Perhaps I am missing something obvious?

Thanks,

Tvrtko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 10:28:46PM +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Martin Peres wrote: 
> > 
> > > Can you test the attached patch too ? I rebased the previous one I sent on
> > > top on 3.7-rc1 as I accidentally used an older version.
> > 
> > Yes, of course.
> > 
> > Tried it. Unfortunately, the crash remains the same as reported.
> 
> Try this one.
> 
> Now, the question is: could 3.6 kernel get VBIOS by ACPI?
> If yes, please mount debugfs and send vbios.rom to me please.
> (cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)
> 
> ---
> From: Marcin Slusarz 
> Subject: [PATCH] drm/nouveau: validate vbios size
> 
> Without checking, we could detect vbios size as 0, allocate 0-byte array
> (kmalloc returns invalid pointer for such allocation) and crash in
> nouveau_bios_score while checking for vbios signature.
> 
> Reported-by: Heinz Diehl 

And of course:
Reported-by: Paweł Sikora 

> Signed-off-by: Marcin Slusarz 
> ---
>  drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index dcb5c2b..824eea0 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
>   }
>  
>   data = of_get_property(dn, "NVDA,BMP", &size);
> - if (data) {
> + if (data && size) {
>   bios->size = size;
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data)
> @@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
>   goto out;
>  
>   bios->size = nv_rd08(bios, 0x72) * 512;
> + if (!bios->size)
> + goto out;
> +
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data) {
>   for (i = 0; i < bios->size; i++)
> @@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
>  
>   /* read entire bios image to system memory */
>   bios->size = nv_rd08(bios, 0x32) * 512;
> + if (!bios->size)
> + goto out;
> +
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   if (bios->data) {
>   for (i = 0; i < bios->size; i++)
> @@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
>   bios->size = 0;
>   if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
>   bios->size = data[2] * 512;
> + if (!bios->size)
> + return;
>  
>   bios->data = kmalloc(bios->size, GFP_KERNEL);
>   for (i = 0; bios->data && i < bios->size; i += cnt) {
> @@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
>  static int
>  nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
>  {
> - if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
> + if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
> + bios->data[1] != 0xAA) {
>   nv_info(bios, "... signature not found\n");
>   return 0;
>   }
>  
> - if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
> + if (nvbios_checksum(bios->data,
> + min_t(u32, bios->data[2] * 512, bios->size))) {
>   nv_info(bios, "... checksum invalid\n");
>   /* if a ro image is somewhat bad, it's probably all rubbish */
>   return writeable ? 2 : 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: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Pavel Machek]

On Sat 2012-10-20 17:41:49, Artem S. Tashkinov wrote:
> On Oct 20, 2012, Borislav Petkov wrote: 
> 
> > Yeah, your kernel is tainted with a proprietary module (vbox*, etc). Can
> > you reproduce your corruptions (this is what it looks like) without that
> > module?
> 
> Yes, I can reproduce this panic with zero proprietary/non-free modules loaded.
> 
> The problem is the kernel doesn't even print a kernel panic - the
> system just freezes completely - cursor in a text console stops
> blinking.

bugtraq? :-).

If remote website can crash your Linux, that's quite significant news.

(Cc-ed netdev@ and security@ ... this may be important).
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: Linux 3.7-rc1 (nouveau_bios_score oops).

[Marcin Slusarz]

On Sat, Oct 20, 2012 at 12:42:38PM +0200, Heinz Diehl wrote:
> On 20.10.2012, Martin Peres wrote: 
> 
> > Can you test the attached patch too ? I rebased the previous one I sent on
> > top on 3.7-rc1 as I accidentally used an older version.
> 
> Yes, of course.
> 
> Tried it. Unfortunately, the crash remains the same as reported.

Try this one.

Now, the question is: could 3.6 kernel get VBIOS by ACPI?
If yes, please mount debugfs and send vbios.rom to me please.
(cat /sys/kernel/debug/dri/0/vbios.rom > vbios.rom)

---
From: Marcin Slusarz 
Subject: [PATCH] drm/nouveau: validate vbios size

Without checking, we could detect vbios size as 0, allocate 0-byte array
(kmalloc returns invalid pointer for such allocation) and crash in
nouveau_bios_score while checking for vbios signature.

Reported-by: Heinz Diehl 
Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
index dcb5c2b..824eea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
@@ -72,7 +72,7 @@ nouveau_bios_shadow_of(struct nouveau_bios *bios)
}
 
data = of_get_property(dn, "NVDA,BMP", &size);
-   if (data) {
+   if (data && size) {
bios->size = size;
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data)
@@ -104,6 +104,9 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
goto out;
 
bios->size = nv_rd08(bios, 0x72) * 512;
+   if (!bios->size)
+   goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -155,6 +158,9 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios)
 
/* read entire bios image to system memory */
bios->size = nv_rd08(bios, 0x32) * 512;
+   if (!bios->size)
+   goto out;
+
bios->data = kmalloc(bios->size, GFP_KERNEL);
if (bios->data) {
for (i = 0; i < bios->size; i++)
@@ -194,6 +200,8 @@ nouveau_bios_shadow_acpi(struct nouveau_bios *bios)
bios->size = 0;
if (nouveau_acpi_get_bios_chunk(data, 0, 3) == 3)
bios->size = data[2] * 512;
+   if (!bios->size)
+   return;
 
bios->data = kmalloc(bios->size, GFP_KERNEL);
for (i = 0; bios->data && i < bios->size; i += cnt) {
@@ -229,12 +237,14 @@ nouveau_bios_shadow_pci(struct nouveau_bios *bios)
 static int
 nouveau_bios_score(struct nouveau_bios *bios, const bool writeable)
 {
-   if (!bios->data || bios->data[0] != 0x55 || bios->data[1] != 0xAA) {
+   if (bios->size < 3 || !bios->data || bios->data[0] != 0x55 ||
+   bios->data[1] != 0xAA) {
nv_info(bios, "... signature not found\n");
return 0;
}
 
-   if (nvbios_checksum(bios->data, bios->data[2] * 512)) {
+   if (nvbios_checksum(bios->data,
+   min_t(u32, bios->data[2] * 512, bios->size))) {
nv_info(bios, "... checksum invalid\n");
/* if a ro image is somewhat bad, it's probably all rubbish */
return writeable ? 2 : 1;
-- 
1.7.12

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

Linux 3.7-rc2

[Linus Torvalds]

For the last few months, it's almost become a habit of mine to make
the occasional release from the airport while flying out somewhere.
And this is another such one. Go free PDX airport wireless!

Anyway, it's been roughly a week, and -rc2 is out. The most noticeable
thing tends to be fixing various fallout issues - there's lots of
patches to finish up (and fix the fallout) from the UAPI include file
reorganization, for example, but there's also some changes to how
module signing is done etc etc.

In pure lines, the uapi stuff (even with rename detection) dwarfs
everything else, and the diffstat of -rc2 is very unusual. Instead of
the normal "65% drivers, random everything else", it's "50% arch
patches (largely uapi header files), 30% include (more uapi header
file changes, and 20% everything else".

But the appended shortlog is fairly readable, because the uapi changes
don't dominate there. Nothing really particular stands out. DRM and
USB driver changes, and various random fixes all over..

Have fun, and go forth and test,

Linus

---

Al Viro (2):
  fix a leak in replace_fd() users
  bury SEL_{IN,OUT,EX}

Alan Stern (1):
  USB: fix port probing and removal in garmin_gps

Alex Deucher (5):
  drm/radeon: fix compilation with backlight disabled
  drm/radeon: allocate PPLLs from low to high
  drm/radeon: update comments to clarify VM setup (v2)
  drm/radeon/cayman: set VM max pfn at MC init
  drm/radeon: check if pcie gen 2 is already enabled (v2)

Alexander Shiyan (1):
  serial: sccnxp: Allows the driver to be compiled as a module

Alexandre Pereira da Silva (1):
  usb: gadget: lpc32xx_udc: Fix compatibility with STOTG04

Alexis R. Cortes (1):
  usb: host: xhci: New system added for Compliance Mode Patch on
SN65LVPE502CP

Andi Kleen (1):
  FRV: Fix const sections change

Aneesh Kumar K.V (1):
  powerpc: Build fix for powerpc KVM

Antony Pavlov (1):
  MIPS: JZ4740: Fix '#include guard' in serial.h

Arnaldo Carvalho de Melo (4):
  perf python: Initialize 'page_size' variable
  perf python: Link with libtraceevent
  perf hists browser: Add back callchain folding symbol
  perf python: Properly link with libtraceevent

Arnd Bergmann (9):
  SCSI: ARM: ncr5380/oak uses no interrupts
  SCSI: ARM: make fas216_dumpinfo function conditional
  mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
  USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
  pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
  pinctrl: samsung: use __devinit section for init code
  pinctrl: sirf: remove sirfsoc_gpio_set_pull function
  spi/s3c64xx: use correct dma_transfer_direction type
  ARM: s3c: mark s3c2440_clk_add as __init_refok

Ashish Chavan (1):
  ASoC: codecs: da9055: Minor improvement in ALC calibration process

Axel Lin (2):
  gpio: mvebu: Add missing breaks in mvebu_gpio_irq_set_type
  drivers/video/backlight/lm3639_bl.c: return proper error in
lm3639_bled_mode_store() error paths

Ben Collins (1):
  USB: ehci-fsl: Return valid error in ehci_fsl_setup_phy

Ben Skeggs (1):
  drm/nouveau/bios: fix typo in error message

Benjamin Herrenschmidt (1):
  Revert "powerpc/perf: Use pmc_overflow() to detect rolled back events"

Benoit Cousson (1):
  ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck

Bill Pemberton (2):
  staging: dgrp: check for NULL pointer in (un)register_proc_table
  staging: dgrp: check return value of alloc_tty_driver

Bjørn Mork (2):
  USB: option: blacklist net interface on ZTE devices
  USB: option: add more ZTE devices

Borislav Petkov (1):
  x86, MCE: Remove bios_cmci_threshold sysfs attribute

Bryan Wu (1):
  MAINTAINERS: change email after moving for LED subsystem maintaining

Carlos Maiolino (2):
  ext3: fix possible non-initialized variable on htree_dirblock_to_tree()
  ext3: ext3_bread usage audit

Catalin Marinas (5):
  uapi: Allow automatic generation of uapi/asm/ header files
  arm64: Select MODULES_USE_ELF_RELA
  arm64: Fix the update_vsyscall() prototype
  arm64: Ignore memory blocks below PHYS_OFFSET
  arm64: No need to set the x0-x2 registers in start_thread()

Chris Ball (1):
  ARM: pxa: Fix build error caused by sram.h rename

Chris Wilson (2):
  drm/i915: Disallow preallocation of requests
  drm/i915: fixup i915_gem_object_get_page inline helper

Chris Zankel (3):
  xtensa: fix memmove(), bcopy(), and memcpy().
  xtensa: minor compiler warning fix
  xtensa: add missing system calls to the syscall table

Christian König (3):
  drm/radeon: allocate page tables on demand v4
  drm/radeon: don't add the IB pool to all VMs v2
  drm/radeon: separate pt alloc from lru add

Corey Minyard (3):
  IPMI: Remove SMBus driver info from the docs
  IPMI: Fix some uninitialized warning
  IPMI: Detect register spacing on PCI interfaces

Cyrill Gorcuno

[ANNOUNCE] 3.6.2-rt4

[Thomas Gleixner]

Dear RT Folks,

I'm pleased to announce the 3.6.2-rt4 release. rt4 is just an update
to 3.6.2. The not announced 3.6.1-rt3 is an intermediate release with
a single change.

Changes since 3.6.1-rt2:

* Remove the softirq noise printk

The delta patch against 3.6.1-rt2 is appended below and can be found here

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.1-rt2-rt3.patch.xz

The RT patch against 3.6.2 can be found here:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.2-rt4.patch.xz

The split quilt queue is available at:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.2-rt4.tar.xz

Enjoy,

tglx

-->

Index: linux-stable/kernel/softirq.c
===
--- linux-stable.orig/kernel/softirq.c
+++ linux-stable/kernel/softirq.c
@@ -468,8 +468,6 @@ static void do_single_softirq(int which,
  */
 static void do_current_softirqs(int need_rcu_bh_qs)
 {
-   int retry = 0;
-
while (current->softirqs_raised) {
int i = __ffs(current->softirqs_raised);
unsigned int pending, mask = (1U << i);
@@ -496,10 +494,6 @@ static void do_current_softirqs(int need
}
unlock_softirq(i);
WARN_ON(current->softirq_nestcnt != 1);
-   if (++retry == 20) {
-   printk(KERN_ERR "Crap, %s looping forever in softirq\n",
-  current->comm);
-   }
}
 }
 
Index: linux-stable/localversion-rt
===
--- linux-stable.orig/localversion-rt
+++ linux-stable/localversion-rt
@@ -1 +1 @@
--rt2
+-rt3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Initial report on F2FS filesystem performance

[Pavel Machek]

On Tue 2012-10-16 13:07:03, Sooman Jeong wrote:
> 
> This is a brief summary of our initial filesystem performance study of f2fs 
> against existing two filesystems in linux: EXT4, NILFS2, and f2fs.
> 

Hmm, flashes are actually optimized for VFAT, right? Can you compare
against that?

What about something more complex like "untar of kernel tree"?

Ouch and... thanks for doing this.
Pavel   
  
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/

[PATCH v2 2/3] cpusets: add load avgerage interface

[Andrea Righi]

Add the new file loadavg to report the load average of the cpus assigned
to the cpuset cgroup.

The load average is reported using the typical three values as they
appear in /proc/loadavg, averaged over 1, 5 and 15 minutes.

Example:
  # cat /sys/fs/cgroup/cpuset/foo/cpuset.loadavg
  3.98 2.64 1.20

Signed-off-by: Andrea Righi 
---
 kernel/cpuset.c |  108 +++
 1 file changed, 108 insertions(+)

diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index f33c715..1bb10d1 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1465,6 +1465,7 @@ typedef enum {
FILE_MEMORY_PRESSURE,
FILE_SPREAD_PAGE,
FILE_SPREAD_SLAB,
+   FILE_LOADAVG,
 } cpuset_filetype_t;
 
 static int cpuset_write_u64(struct cgroup *cgrp, struct cftype *cft, u64 val)
@@ -1686,6 +1687,107 @@ static s64 cpuset_read_s64(struct cgroup *cont, struct 
cftype *cft)
return 0;
 }
 
+/*
+ * XXX: move all of this to a better place and unify the different
+ * re-definition of these macros.
+ */
+#define LOAD_INT(x) ((x) >> FSHIFT)
+#define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
+
+static void cpuset_show_loadavg(struct seq_file *m, const struct cpuset *cs)
+{
+   unsigned long avnrun[3] = {};
+   int cpu;
+
+   /*
+* The global load average is an exponentially decaying average of:
+*
+*   x(t) = nr_running(t) + nr_uninterruptible(t)
+*
+* The global load average of the system is evaluated as:
+*
+*   load(t) = load(t - 1) * exp_k + x(t) * (1 - exp_k)
+*
+* So, the load average of a cpuset with N CPUS can be evaluated as:
+*
+*   load_cs(t) = load_cs(t - 1) * exp_k + x_cs(t) * (1 - exp_k),
+*   x_cs(t) = \sum{i = 1}^{N} x_i(t)
+*
+* This is equivalent to the sum of all the partial load averages of
+* each CPU assigned to the cpuset:
+*
+*   load_cs(t) = \sum{i = 1}^{N} load_i(t)
+*
+* Proof:
+*
+*   load_1(t) = load_1(t - 1) * exp_k + x_1(t) * (1 - exp_k)
+*   load_2(t) = load_2(t - 1) * exp_k + x_2(t) * (1 - exp_k)
+*   ...
+*   load_N(t) = load_N(t - 1) * exp_k + x_N(t) * (1 - exp_k)
+*
+*   ===>
+*
+*   load_1(t) = x_1(1) * (1 - exp_k) * exp_k^{t - 1} +
+*   x_1(2) * (1 - exp_k) * exp_k^{t - 2} +
+*   ... +
+*   x_1(t)(1 - exp_k)
+*   load_2(t) = x_2(1) * (1 - exp_k) * exp_k^{t - 1} +
+*   x_2(2) * (1 - exp_k) * exp_k^{t - 2} +
+*   ... +
+*   x_2(t)(1 - exp_k)
+*   ...
+*   load_N(t) = x_N(1) * (1 - exp_k) * exp_k^{t - 1} +
+*   x_N(2) * (1 - exp_k) * exp_k^{t - 2} +
+*   ... +
+*   x_N(t)(1 - exp_k)
+*
+*   ===>
+*
+*   load_1(t) + load_2(t) + ... + load_N(t) =
+*   \sum_{i = 1}^{N} x_i(1) * (1 - exp_k) * exp_k^{t - 1} +
+*   \sum_{i = 1}^{N} x_i(2) * (1 - exp_k) * exp_k^{t - 2} +
+*   ... +
+*   \sum_{i = 1}^{N} x_i(t) * (1 - exp_k) = load_cs(t)
+*/
+   for_each_cpu(cpu, cs->cpus_allowed) {
+   unsigned long cpu_avnrun[3];
+   int i;
+
+   get_cpu_avenrun(cpu_avnrun, cpu, FIXED_1/200, 0);
+
+   for (i = 0; i < ARRAY_SIZE(cpu_avnrun); i++)
+   avnrun[i] += cpu_avnrun[i];
+   }
+   /*
+* TODO: also report nr_running/nr_threads and last_pid, producing the
+* same output as /proc/loadavg.
+*
+* For nr_running we can just sum the nr_running_cpu() of the cores
+* assigned to this cs; what should we report in nr_threads? maybe
+* cgroup_task_count()? and what about last_pid?
+*/
+   seq_printf(m, "%lu.%02lu %lu.%02lu %lu.%02lu\n",
+  LOAD_INT(avnrun[0]), LOAD_FRAC(avnrun[0]),
+  LOAD_INT(avnrun[1]), LOAD_FRAC(avnrun[1]),
+  LOAD_INT(avnrun[2]), LOAD_FRAC(avnrun[2]));
+}
+
+static int cpuset_read_seq_string(struct cgroup *cont, struct cftype *cft,
+  struct seq_file *m)
+{
+   struct cpuset *cs = cgroup_cs(cont);
+   cpuset_filetype_t type = cft->private;
+
+   switch (type) {
+   case FILE_LOADAVG:
+   cpuset_show_loadavg(m, cs);
+   break;
+   default:
+   BUG();
+   }
+
+   return 0;
+}
 
 /*
  * for the common functions, 'private' gives the type of file
@@ -1780,6 +1882,12 @@ static struct cftype files[] = {
.private = FILE_MEMORY_PRESSURE_ENABLED,
},
 
+   {
+   .name = "loadavg",
+   .read_seq_string = cpuset_read_seq_string,
+   .private = FILE_LOADAVG,
+   },
+
{ } /* terminate */
 };
 
-

[PATCH v2 1/3] sched: introduce distinct per-cpu load average

[Andrea Righi]

Account load average, nr_running and nr_uninterruptible tasks per-cpu.

The new task_struct attribute on_cpu_uninterruptible is added to
properly keep track of the cpu at deactivate time, when the task is set
to the uninterruptible sleep state.

Moreover, rq->nr_uninterruptible is converted to a percpu variable to
maintain a coherent nr_uninterruptible counter for each CPU (rather than
having a single global counter defined as the sum over all CPUs). This
adds less performance overhead than introducing atomic operations in the
wakeup/sleep path.

This feature is required by the cpusets cgroup subsystem to report the
load average per-cpuset.

Signed-off-by: Andrea Righi 
---
 include/linux/sched.h |6 +++
 kernel/sched/core.c   |  112 ++---
 kernel/sched/debug.c  |3 +-
 kernel/sched/sched.h  |8 +---
 4 files changed, 105 insertions(+), 24 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 0dd42a0..e5dfe2a 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -80,6 +80,8 @@ struct blk_plug;
  */
 extern unsigned long avenrun[];/* Load averages */
 extern void get_avenrun(unsigned long *loads, unsigned long offset, int shift);
+extern void get_cpu_avenrun(unsigned long *loads, int cpu,
+   unsigned long offset, int shift);
 
 #define FSHIFT 11  /* nr of bits of precision */
 #define FIXED_1(1on_cpu_uninterruptible);
+   __this_cpu_dec(*prev_rq->nr_uninterruptible);
+   }
 
enqueue_task(rq, p, flags);
 }
 
 void deactivate_task(struct rq *rq, struct task_struct *p, int flags)
 {
-   if (task_contributes_to_load(p))
-   rq->nr_uninterruptible++;
+   if (task_contributes_to_load(p)) {
+   __this_cpu_inc(*rq->nr_uninterruptible);
+   p->on_cpu_uninterruptible = cpu_of(rq);
+   }
 
dequeue_task(rq, p, flags);
 }
@@ -1277,8 +1281,10 @@ static void
 ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags)
 {
 #ifdef CONFIG_SMP
-   if (p->sched_contributes_to_load)
-   rq->nr_uninterruptible--;
+   if (p->sched_contributes_to_load) {
+   struct rq *prev_rq = cpu_rq(p->on_cpu_uninterruptible);
+   __this_cpu_dec(*prev_rq->nr_uninterruptible);
+   }
 #endif
 
ttwu_activate(rq, p, ENQUEUE_WAKEUP | ENQUEUE_WAKING);
@@ -1916,12 +1922,17 @@ unsigned long nr_running(void)
return sum;
 }
 
+unsigned long nr_running_cpu(int cpu)
+{
+   return cpu_rq(cpu)->nr_running;
+}
+
 unsigned long nr_uninterruptible(void)
 {
unsigned long i, sum = 0;
 
for_each_possible_cpu(i)
-   sum += cpu_rq(i)->nr_uninterruptible;
+   sum += nr_uninterruptible_cpu(i);
 
/*
 * Since we read the counters lockless, it might be slightly
@@ -1933,6 +1944,18 @@ unsigned long nr_uninterruptible(void)
return sum;
 }
 
+unsigned long nr_uninterruptible_cpu(int cpu)
+{
+   struct rq *this = cpu_rq(cpu);
+   unsigned long val = 0;
+   int i;
+
+   for_each_online_cpu(i)
+   val += per_cpu(*this->nr_uninterruptible, i);
+
+   return val;
+}
+
 unsigned long long nr_context_switches(void)
 {
int i;
@@ -1980,7 +2003,8 @@ unsigned long this_cpu_load(void)
  *
  *   nr_active = 0;
  *   for_each_possible_cpu(cpu)
- * nr_active += cpu_of(cpu)->nr_running + cpu_of(cpu)->nr_uninterruptible;
+ * nr_active += cpu_of(cpu)->nr_running +
+ *  (cpu_of(cpu)->nr_uninterruptible;
  *
  *   avenrun[n] = avenrun[0] * exp_n + nr_active * (1 - exp_n)
  *
@@ -2004,13 +2028,6 @@ unsigned long this_cpu_load(void)
  *This places an upper-bound on the IRQ-off latency of the machine. Then
  *again, being late doesn't loose the delta, just wrecks the sample.
  *
- *  - cpu_rq()->nr_uninterruptible isn't accurately tracked per-cpu because
- *this would add another cross-cpu cacheline miss and atomic operation
- *to the wakeup path. Instead we increment on whatever cpu the task ran
- *when it went into uninterruptible state and decrement on whatever cpu
- *did the wakeup. This means that only the sum of nr_uninterruptible over
- *all cpus yields the correct result.
- *
  *  This covers the NO_HZ=n code, for extra head-aches, see the comment below.
  */
 
@@ -2035,12 +2052,15 @@ void get_avenrun(unsigned long *loads, unsigned long 
offset, int shift)
loads[2] = (avenrun[2] + offset) << shift;
 }
 
+static DEFINE_PER_CPU(unsigned long [3], cpu_avenrun);
+
 static long calc_load_fold_active(struct rq *this_rq)
 {
long nr_active, delta = 0;
+   int cpu = cpu_of(this_rq);
 
nr_active = this_rq->nr_running;
-   nr_active += (long) this_rq->nr_uninterruptible;
+   nr

[PATCH v2 3/3] cpusets: add documentation of the loadavg file

[Andrea Righi]

Signed-off-by: Andrea Righi 
---
 Documentation/cgroups/cpusets.txt |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/cgroups/cpusets.txt 
b/Documentation/cgroups/cpusets.txt
index cefd3d8..d5ddc36 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -179,6 +179,7 @@ files describing that cpuset:
  - cpuset.memory_spread_slab flag: if set, spread slab cache evenly on allowed 
nodes
  - cpuset.sched_load_balance flag: if set, load balance within CPUs on that 
cpuset
  - cpuset.sched_relax_domain_level: the searching range when migrating tasks
+ - cpuset.loadavg: the load average of the CPUs in that cpuset
 
 In addition, only the root cpuset has the following file:
  - cpuset.memory_pressure_enabled flag: compute memory_pressure?
-- 
1.7.10.4

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

[PATCH v2 0/3] distinct load average per-cpuset

[Andrea Righi]

Overview

The cpusets subsystem allows to assign a different set of CPUs to a cgroup. A
typical use case is to split large systems in small CPU/memory partitions and
isolate certain users/applications in these subsets of the system.

Sometimes, to have a quick overview of the state of each partition, we may be
interested to get the load average of the CPUs assigned to a particular cpuset,
rather than the global load average of the system.

Proposed solution
~
The proposal is to add a new file in the cpuset subsystem to report the load
average of the CPUs assinged to a particular cpuset cgroup.

Example:

 # echo 0-1 > /sys/fs/cgroup/cpuset/foo/cpuset.cpus
 # echo 2-3 > /sys/fs/cgroup/cpuset/bar/cpuset.cpus

 # echo $$ > /sys/fs/cgroup/cpuset/foo/tasks
 # for i in `seq 4`; do yes > /dev/null & done

 ... after ~5mins ...

 # cat /proc/loadavg /sys/fs/cgroup/cpuset/{foo,bar}/cpuset.loadavg
 3.99 2.66 1.24 6/377 2855
 3.98 2.64 1.20
 0.01 0.02 0.04

In this case we can easily find that the cpuset "foo" is the most busy in the
system.

ChangeLog v1->v2:
 - convert rq->nr_uninterruptible to a percpu variable
 - fix nr_uninterruptible accounting in the wakeup/sleep paths
 - use DEFINE_PER_CPU() instead of NR_CPUS arrays
 - in patch 2/3 add a comment to explain the validity of evaluating the cpuset
   load average as the sum of the individual per-cpu load averages

[ Thanks to Peter Z. for the review and suggestions of v1 ]

TODO:
 - report nr_running and nr_threads in cpuset.loadavg, producing the same
   output as /proc/loadavg; in this way we could do nice things like, for
   example, "mount --bind cpuset.loadavg /proc/loadavg" in a new mount
   namespace for a specific user that we want to isolate into a specific
   cpuset cgroup, etc...

[PATCH v2 1/3] sched: introduce distinct per-cpu load average
[PATCH v2 2/3] cpusets: add load avgerage interface
[PATCH v2 3/3] cpusets: add documentation of the loadavg file

 Documentation/cgroups/cpusets.txt |1 +
 include/linux/sched.h |6 ++
 kernel/cpuset.c   |  108 +++
 kernel/sched/core.c   |  112 +++--
 kernel/sched/debug.c  |3 +-
 kernel/sched/sched.h  |8 +--
 6 files changed, 214 insertions(+), 24 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] lockdep: Use KSYM_NAME_LEN'ed buffer for __get_key_name

[Cyrill Gorcunov]

Not a big deal, but since other __get_key_name callers
use it lets be consistent.

Signed-off-by: Cyrill Gorcunov 
---
 kernel/lockdep_proc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.git/kernel/lockdep_proc.c
===
--- linux-2.6.git.orig/kernel/lockdep_proc.c
+++ linux-2.6.git/kernel/lockdep_proc.c
@@ -39,7 +39,7 @@ static void l_stop(struct seq_file *m, v
 
 static void print_name(struct seq_file *m, struct lock_class *class)
 {
-   char str[128];
+   char str[KSYM_NAME_LEN];
const char *name = class->name;
 
if (!name) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] 3.2.32-rt48

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.2.32-rt48 stable release.


This release is just an update to the new stable 3.2.32 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  Head SHA1: 1b091c287c08b6a18510926dff6424e65391541e


Or to build 3.2.32-rt48 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.32.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.32-rt48.patch.xz



Enjoy,

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

[PATCH 1/4] brd: change module parameters rd_size, rd_nr, max_part to unsigned

[Hannes Frederic Sowa]

All parameters of the module brd are now converted to unsigneds. This
saves some less-than-zero checks.

As the external user of rd_size (arch/arm/kernel/setup.c:setup_ramdisk)
seems to be gone in v3.7-rc1 this variable can later be declared static.

While at it, move the (perhaps automatically) placed brd_mutex out of
the silly constellation between function prelude comment and function.

Cc: Nick Piggin 
Signed-off-by: Hannes Frederic Sowa 
---
 drivers/block/brd.c | 44 +---
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 531ceb3..c4965f5 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -48,10 +48,11 @@ struct brd_device {
struct radix_tree_root  brd_pages;
 };
 
+static DEFINE_MUTEX(brd_mutex);
+
 /*
  * Look up and return a brd's page for a given sector.
  */
-static DEFINE_MUTEX(brd_mutex);
 static struct page *brd_lookup_page(struct brd_device *brd, sector_t sector)
 {
pgoff_t idx;
@@ -429,15 +430,15 @@ static const struct block_device_operations brd_fops = {
 /*
  * And now the modules code and kernel interface.
  */
-static int rd_nr;
-int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
-static int max_part;
-static int part_shift;
-module_param(rd_nr, int, S_IRUGO);
+static unsigned int rd_nr;
+unsigned int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
+static unsigned int max_part;
+static unsigned int part_shift;
+module_param(rd_nr, uint, S_IRUGO);
 MODULE_PARM_DESC(rd_nr, "Maximum number of brd devices");
-module_param(rd_size, int, S_IRUGO);
+module_param(rd_size, uint, S_IRUGO);
 MODULE_PARM_DESC(rd_size, "Size of each RAM disk in kbytes.");
-module_param(max_part, int, S_IRUGO);
+module_param(max_part, uint, S_IRUGO);
 MODULE_PARM_DESC(max_part, "Maximum number of partitions per RAM disk");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(RAMDISK_MAJOR);
@@ -447,7 +448,7 @@ MODULE_ALIAS("rd");
 /* Legacy boot options - nonmodular */
 static int __init ramdisk_size(char *str)
 {
-   rd_size = simple_strtol(str, NULL, 0);
+   rd_size = simple_strtoul(str, NULL, 0);
return 1;
 }
 __setup("ramdisk_size=", ramdisk_size);
@@ -555,7 +556,7 @@ static struct kobject *brd_probe(dev_t dev, int *part, void 
*data)
 
 static int __init brd_init(void)
 {
-   int i, nr;
+   unsigned int i, nr;
unsigned long range;
struct brd_device *brd, *next;
 
@@ -574,20 +575,17 @@ static int __init brd_init(void)
 * kernel automatically instantiate actual device on-demand.
 */
 
-   part_shift = 0;
-   if (max_part > 0) {
-   part_shift = fls(max_part);
+   part_shift = fls(max_part);
 
-   /*
-* Adjust max_part according to part_shift as it is exported
-* to user space so that user can decide correct minor number
-* if [s]he want to create more devices.
-*
-* Note that -1 is required because partition 0 is reserved
-* for the whole disk.
-*/
-   max_part = (1UL << part_shift) - 1;
-   }
+   /*
+* Adjust max_part according to part_shift as it is exported
+* to user space so that user can decide correct minor number
+* if [s]he want to create more devices.
+*
+* Note that -1 is required because partition 0 is reserved
+* for the whole disk.
+*/
+   max_part = (1UL << part_shift) - 1;
 
if ((1UL << part_shift) > DISK_MAX_PARTS)
return -EINVAL;
-- 
1.7.12.4

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

[PATCH 2/4] brd: check for open partitions when BLKFLSBUFing a ram disk

[Hannes Frederic Sowa]

Users of partitions on ram disks could accidentally flush the block
device with ioctl(BLKFLSBUF) while it is in use. This patch prevents
this from happening.

This patch also adds a call to rescan_partitions after BLKFLSBUFing,
for which a EXPORT_SYMBOL_GPL statement was needed. Otherwise some kind
of use-after-free could happen.

After this change BLKFLSBUFing on partitions of a ram disk is never
possible.

Cc: Nick Piggin 
Signed-off-by: Hannes Frederic Sowa 
---
 block/partition-generic.c |  1 +
 drivers/block/brd.c   | 20 +---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/block/partition-generic.c b/block/partition-generic.c
index f1d1451..cd7bc10 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -528,6 +528,7 @@ rescan:
kfree(state);
return 0;
 }
+EXPORT_SYMBOL_GPL(rescan_partitions);
 
 int invalidate_partitions(struct gendisk *disk, struct block_device *bdev)
 {
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index c4965f5..ce1255c 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -385,6 +385,13 @@ static int brd_direct_access(struct block_device *bdev, 
sector_t sector,
 }
 #endif
 
+static int brd_blkdev_in_use(struct block_device *bdev)
+{
+lockdep_assert_held(&bdev->bd_mutex);
+return bdev->bd_part_count > 0
+|| bdev->bd_openers > 1;
+}
+
 static int brd_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
 {
@@ -399,9 +406,15 @@ static int brd_ioctl(struct block_device *bdev, fmode_t 
mode,
 * release and destroy the ramdisk data.
 */
mutex_lock(&brd_mutex);
+   if (bdget_disk(brd->brd_disk, 0) != bdev) {
+   error = -EBUSY;
+   goto out;
+   }
mutex_lock(&bdev->bd_mutex);
-   error = -EBUSY;
-   if (bdev->bd_openers <= 1) {
+   error = brd_blkdev_in_use(bdev);
+   if (error) {
+   error = -EBUSY;
+   } else {
/*
 * Kill the cache first, so it isn't written back to the
 * device.
@@ -411,9 +424,10 @@ static int brd_ioctl(struct block_device *bdev, fmode_t 
mode,
 */
kill_bdev(bdev);
brd_free_pages(brd);
-   error = 0;
+   error = rescan_partitions(brd->brd_disk, bdev);
}
mutex_unlock(&bdev->bd_mutex);
+out:
mutex_unlock(&brd_mutex);
 
return error;
-- 
1.7.12.4

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

[PATCH 3/4] brd: replace list with brd_devices by an idr indexed by minor ids

[Hannes Frederic Sowa]

This patch replaces the list of brd_devices with an idr, thus enabling
easier block ram disk creation and deletion.

Cc: Nick Piggin 
Signed-off-by: Hannes Frederic Sowa 
---
 drivers/block/brd.c | 136 
 1 file changed, 106 insertions(+), 30 deletions(-)

diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index ce1255c..1d0016b 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -34,11 +35,8 @@
  * device).
  */
 struct brd_device {
-   int brd_number;
-
struct request_queue*brd_queue;
struct gendisk  *brd_disk;
-   struct list_headbrd_list;
 
/*
 * Backing store of pages and lock to protect it. This is the contents
@@ -50,6 +48,10 @@ struct brd_device {
 
 static DEFINE_MUTEX(brd_mutex);
 
+static char dummy = -1;
+#define DUMMY ((struct brd_device *)&dummy)
+static DEFINE_IDR(brd_idr);
+
 /*
  * Look up and return a brd's page for a given sector.
  */
@@ -458,6 +460,8 @@ MODULE_LICENSE("GPL");
 MODULE_ALIAS_BLOCKDEV_MAJOR(RAMDISK_MAJOR);
 MODULE_ALIAS("rd");
 
+static struct brd_device *brd_new(int id);
+
 #ifndef MODULE
 /* Legacy boot options - nonmodular */
 static int __init ramdisk_size(char *str)
@@ -472,7 +476,6 @@ __setup("ramdisk_size=", ramdisk_size);
  * The device scheme is derived from loop.c. Keep them in synch where possible
  * (should share code eventually).
  */
-static LIST_HEAD(brd_devices);
 static DEFINE_MUTEX(brd_devices_mutex);
 
 static struct brd_device *brd_alloc(int i)
@@ -483,7 +486,6 @@ static struct brd_device *brd_alloc(int i)
brd = kzalloc(sizeof(*brd), GFP_KERNEL);
if (!brd)
goto out;
-   brd->brd_number = i;
spin_lock_init(&brd->brd_lock);
INIT_RADIX_TREE(&brd->brd_pages, GFP_ATOMIC);
 
@@ -533,27 +535,100 @@ static struct brd_device *brd_init_one(int i)
 {
struct brd_device *brd;
 
-   list_for_each_entry(brd, &brd_devices, brd_list) {
-   if (brd->brd_number == i)
-   goto out;
-   }
+   brd = idr_find(&brd_idr, i);
+   if (brd)
+   return brd;
 
-   brd = brd_alloc(i);
-   if (brd) {
+   brd = brd_new(i);
+   if (!IS_ERR(brd))
add_disk(brd->brd_disk);
-   list_add_tail(&brd->brd_list, &brd_devices);
-   }
-out:
return brd;
 }
 
 static void brd_del_one(struct brd_device *brd)
 {
-   list_del(&brd->brd_list);
del_gendisk(brd->brd_disk);
brd_free(brd);
 }
 
+static int brd_new_id(int min)
+{
+   int id, err;
+   err = idr_pre_get(&brd_idr, GFP_KERNEL);
+   if (!err)
+   return -ENOMEM;
+   err = idr_get_new_above(&brd_idr, DUMMY, min, &id);
+   if (err < 0)
+   return err;
+   return id;
+}
+
+static int brd_new_specific_id(int id)
+{
+   int n;
+   n = brd_new_id(id);
+   if (n < 0)
+   return n;
+   if (id != n) {
+   idr_remove(&brd_idr, n);
+   return -EBUSY;
+   }
+   return n;
+}
+
+static struct brd_device *brd_new(int id)
+{
+   int err;
+   struct brd_device *brd, *p;
+
+   err = brd_new_specific_id(id);
+   if (err < 0)
+   return ERR_PTR(err);
+   brd = brd_alloc(id);
+   if (!brd) {
+   p = ERR_PTR(-ENOMEM);
+   goto out;
+   }
+   p = idr_replace(&brd_idr, brd, id);
+   if (IS_ERR(p))
+   goto out2;
+   if (p != DUMMY) {
+   WARN_ON(1);
+   p = ERR_PTR(-EBUSY);
+   goto out2;
+   }
+   return brd;
+out2:
+   brd_free(brd);
+out:
+   idr_remove(&brd_idr, id);
+   return p;
+}
+
+static int brd_add_disk_idr(int id, void *p, void *data)
+{
+   struct brd_device *brd = (struct brd_device *)p;
+   WARN_ON(brd == DUMMY);
+   add_disk(brd->brd_disk);
+   return 0;
+}
+
+static int brd_free_idr(int id, void *p, void *data)
+{
+   struct brd_device *brd = (struct brd_device *)p;
+   WARN_ON(brd == DUMMY);
+   brd_free(brd);
+   return 0;
+}
+
+static int brd_del_one_idr(int id, void *p, void *data)
+{
+   struct brd_device *brd = (struct brd_device *)p;
+   WARN_ON(brd == DUMMY);
+   brd_del_one(brd);
+   return 0;
+}
+
 static struct kobject *brd_probe(dev_t dev, int *part, void *data)
 {
struct brd_device *brd;
@@ -561,7 +636,7 @@ static struct kobject *brd_probe(dev_t dev, int *part, void 
*data)
 
mutex_lock(&brd_devices_mutex);
brd = brd_init_one(MINOR(dev) >> part_shift);
-   kobj = brd ? get_disk(brd->brd_disk) : ERR_PTR(-ENOMEM);
+   kobj = IS_ERR(brd) ? ERR_PTR(PTR_ERR(brd)) : get_disk(brd->brd_disk);
mutex_unlock(&brd_devices_mutex);
 
*part = 0;
@@ -570,9 +645,10 @@ static struct kobject *brd_probe(dev

[PATCH 0/4] brd: sanity checks and dynamic ram disk creation/destroying

[Hannes Frederic Sowa]

Hi!

While toying around with a library which needs small block devices for
quorum management, I came up with these patches to dynamically create
and destroy ram disks (I wanted to have non-swappable backed devices).

Feedback is appreciated!

Change log (since RFC patch <20121014024836.gb27...@order.stressinduktion.org>):
1) module parameters(rd_nr, rd_size, max_part) are now unsigned ints
2) check for active users of ram disk before BLKFLSBUFing
3) switched from lists to idrs for device management

The patches apply against v3.6.

 Documentation/ioctl/ioctl-number.txt |   1 +
 block/partition-generic.c|   1 +
 drivers/block/brd.c  | 360 +--
 include/linux/Kbuild |   1 +
 include/linux/brd.h  |  12 ++
 include/linux/miscdevice.h   |   1 +
 6 files changed, 313 insertions(+), 63 deletions(-)

Greetings,

  Hannes

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

[PATCH 4/4] brd: add miscdevice to control creation and deletion of ram disks

[Hannes Frederic Sowa]

This patch adds the miscdevice /dev/brd-control with two ioctls:

  1) BRD_CTL_ADD: Instantiates a new ram disk with a given size as
 parameter. This parameter is filled in with the new minor id
 on return.

  2) BRD_CTL_DEL: Deletes a ram disk. Takes the minor id as parameter.

Cc: Nick Piggin 
Signed-off-by: Hannes Frederic Sowa 
---
 Documentation/ioctl/ioctl-number.txt |   1 +
 drivers/block/brd.c  | 170 ---
 include/linux/Kbuild |   1 +
 include/linux/brd.h  |  12 +++
 include/linux/miscdevice.h   |   1 +
 5 files changed, 173 insertions(+), 12 deletions(-)
 create mode 100644 include/linux/brd.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 849b771..b8827eb 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -326,4 +326,5 @@ Code  Seq#(hex) Include FileComments

 0xF6   all LTTng   Linux Trace Toolkit Next Generation

+0xF7   00-01   drivers/block/brd.c block ram device control driver
 0xFD   all linux/dm-ioctl.h
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 1d0016b..5ad25af 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -20,6 +20,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -478,7 +481,7 @@ __setup("ramdisk_size=", ramdisk_size);
  */
 static DEFINE_MUTEX(brd_devices_mutex);
 
-static struct brd_device *brd_alloc(int i)
+static struct brd_device *brd_alloc(int i, unsigned int size_kb)
 {
struct brd_device *brd;
struct gendisk *disk;
@@ -511,7 +514,7 @@ static struct brd_device *brd_alloc(int i)
disk->queue = brd->brd_queue;
disk->flags |= GENHD_FL_SUPPRESS_PARTITION_INFO;
sprintf(disk->disk_name, "ram%d", i);
-   set_capacity(disk, rd_size * 2);
+   set_capacity(disk, size_kb * 2);
 
return brd;
 
@@ -584,7 +587,7 @@ static struct brd_device *brd_new(int id)
err = brd_new_specific_id(id);
if (err < 0)
return ERR_PTR(err);
-   brd = brd_alloc(id);
+   brd = brd_alloc(id, rd_size);
if (!brd) {
p = ERR_PTR(-ENOMEM);
goto out;
@@ -605,6 +608,139 @@ out:
return p;
 }
 
+static int brd_control_add(unsigned int size_kb)
+{
+   int val, err;
+   struct brd_device *brd, *p;
+
+   lockdep_assert_held(&brd_devices_mutex);
+
+   val = brd_new_id(0);
+   if (val < 0)
+   return val;
+   if (val >= (MINORMASK >> part_shift)) {
+   err = -EINVAL;
+   goto out;
+   }
+   brd = brd_alloc(val, size_kb);
+   if (!brd) {
+   err = -ENOMEM;
+   goto out;
+   }
+   p = idr_replace(&brd_idr, brd, val);
+   if (IS_ERR(p)) {
+   err = PTR_ERR(p);
+   goto out2;
+   }
+   if (p != DUMMY) {
+   WARN_ON(1);
+   err = -EBUSY;
+   goto out2;
+   }
+   add_disk(brd->brd_disk);
+   return val;
+out2:
+   brd_free(brd);
+out:
+   idr_remove(&brd_idr, val);
+   return err;
+}
+
+static int brd_control_del(unsigned int val)
+{
+   int err = 0;
+   struct brd_device *brd;
+   struct block_device *bdev;
+
+   lockdep_assert_held(&brd_devices_mutex);
+
+   brd = idr_find(&brd_idr, val);
+   if (!brd)
+   return -ENODEV;
+
+   mutex_lock(&brd_mutex);
+   bdev = bdget_disk(brd->brd_disk, 0);
+   if (!bdev) {
+   err = -ENODEV;
+   goto out;
+   }
+   mutex_lock(&bdev->bd_mutex);
+   err = brd_blkdev_in_use(bdev);
+   if (err) {
+   err = -EBUSY;
+   } else {
+   idr_remove(&brd_idr, val);
+   brd_del_one(brd);
+   err = 0;
+   }
+   mutex_unlock(&bdev->bd_mutex);
+out:
+   mutex_unlock(&brd_mutex);
+   return err;
+}
+
+static long brd_control_ioctl(struct file *file, unsigned int cmd,
+   unsigned long param)
+{
+   int err = -ENOSYS;
+   int val;
+   unsigned int size_kb;
+
+   if (rd_nr)
+   return -EINVAL;
+
+   mutex_lock(&brd_devices_mutex);
+   switch (cmd) {
+   case BRD_CTL_ADD:
+   err = get_user(size_kb, (unsigned int __user *)param);
+   if (err < 0)
+   break;
+   val = brd_control_add(size_kb);
+   if (val < 0) {
+   err = val;
+   break;
+   }
+   err = put_user(val << part_shift, (unsigned int __user *)param);
+   if (err < 0) {
+   brd_control_del(val);
+  

[ANNOUNCE] 3.4.14-rt23

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.4.14-rt23 stable release.


This release is just an update to the new stable 3.4.14 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  Head SHA1: 7d2260fb631a015570a8eaefb6351ac611c418f9


Or to build 3.4.14-rt23 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.14.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.14-rt23.patch.xz



Enjoy,

-- 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: [PATCH cgroup/for-3.7-fixes 1/2] Revert "cgroup: Remove task_lock() from cgroup_post_fork()"

[Frederic Weisbecker]

2012/10/20 Frederic Weisbecker :
> 2012/10/19 Tejun Heo :
>> Hello, Frederic.
>>
>> On Fri, Oct 19, 2012 at 03:44:20PM -0400, Frederic Weisbecker wrote:
>>> > For -stable, I think it's better to revert.  If you want to remove
>>> > task_lock, let's do it for 3.8.
>>>
>>> I don't think that a wrong comment justifies a patch to stable.
>>
>> I'm not really sure whether it's safe or not.  It seems all usages are
>> protected by write locking css_set_lock but maybe I'm missing
>> something and as the commit is born out of confusion, I'm very
>> inclined to revert it by default.  Are you sure this one is safe?
>
> Thinking about it further, one scenario is worrying me but it
> eventually looks safe but by accident.
>
> CPU 0
> CPU 1
>
> cgroup_task_migrate {
> task_lock(p)
> rcu_assign_pointer(tsk->cgroups, newcg);
> task_unlock(tsk);
>
> write_lock(&css_set_lock);
> if (!list_empty(&tsk->cg_list))
> list_move(&tsk->cg_list, &newcg->tasks);
> write_unlock(&css_set_lock);
>
>   write_lock(&css_set_lock);
> put_css_set(oldcg);
>  list_add(&child->cg_list, &child->cgroups->tasks); (1)

gmail mangled everything :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 cgroup/for-3.7-fixes 1/2] Revert "cgroup: Remove task_lock() from cgroup_post_fork()"

[Frederic Weisbecker]

2012/10/19 Tejun Heo :
> Hello, Frederic.
>
> On Fri, Oct 19, 2012 at 03:44:20PM -0400, Frederic Weisbecker wrote:
>> > For -stable, I think it's better to revert.  If you want to remove
>> > task_lock, let's do it for 3.8.
>>
>> I don't think that a wrong comment justifies a patch to stable.
>
> I'm not really sure whether it's safe or not.  It seems all usages are
> protected by write locking css_set_lock but maybe I'm missing
> something and as the commit is born out of confusion, I'm very
> inclined to revert it by default.  Are you sure this one is safe?

Thinking about it further, one scenario is worrying me but it
eventually looks safe but by accident.

CPU 0
CPU 1

cgroup_task_migrate {
task_lock(p)
rcu_assign_pointer(tsk->cgroups, newcg);
task_unlock(tsk);

write_lock(&css_set_lock);
if (!list_empty(&tsk->cg_list))
list_move(&tsk->cg_list, &newcg->tasks);
write_unlock(&css_set_lock);

  write_lock(&css_set_lock);
put_css_set(oldcg);
 list_add(&child->cg_list, &child->cgroups->tasks); (1)

On (1), child->cgroups should have the value of newcg and not oldcg
due to the memory ordering implied by the locking of css_set_lock. Now
I can't guarantee that because I'm no memory ordering expert. And even
if it's safe, it's so very non obvious that I now agree with you:
let's revert  the patch and restart with a better base by gathering
all the cgroup fork code in the current cgroup_post_fork place.

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

[PATCH] kvm, svm: Cleanup error statements

[Borislav Petkov]

Use __func__ instead of the function name in svm_hardware_enable since
those things tend to get out of sync. This also slims down printk line
length in conjunction with using pr_err.

No functionality change.

Cc: Joerg Roedel 
Cc: Avi Kivity 
Signed-off-by: Borislav Petkov 
---
 arch/x86/kvm/svm.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d017df3899ef..e93908fabf46 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -630,15 +630,12 @@ static int svm_hardware_enable(void *garbage)
return -EBUSY;
 
if (!has_svm()) {
-   printk(KERN_ERR "svm_hardware_enable: err EOPNOTSUPP on %d\n",
-  me);
+   pr_err("%s: err EOPNOTSUPP on %d\n", __func__, me);
return -EINVAL;
}
sd = per_cpu(svm_data, me);
-
if (!sd) {
-   printk(KERN_ERR "svm_hardware_enable: svm_data is NULL on %d\n",
-  me);
+   pr_err("%s: svm_data is NULL on %d\n", __func__, me);
return -EINVAL;
}
 
-- 
1.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools/kvm: Add a .s file rule

[Borislav Petkov]

Add a rule to the kvm tool Makefile to build .asm versions of the files.
This is good for debugging purposes.

Cc: Pekka Enberg 
Cc: Sasha Levin 
Cc: Asias He 
Signed-off-by: Borislav Petkov 
---
 tools/kvm/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/kvm/Makefile b/tools/kvm/Makefile
index 903001e80951..64f2646e5966 100644
--- a/tools/kvm/Makefile
+++ b/tools/kvm/Makefile
@@ -314,6 +314,9 @@ util/rbtree.d: ../../lib/rbtree.c
 %.d: %.c
$(Q) $(CC) -M -MT $(patsubst %.d,%.o,$@) $(CFLAGS) $< -o $@
 
+%.s: %.c
+   $(Q) $(CC) -o $@ -S $(CFLAGS) -fverbose-asm $<
+
 # The header file common-cmds.h is needed for compilation of builtin-help.c.
 builtin-help.d: $(KVM_INCLUDE)/common-cmds.h
 
-- 
1.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] Linux KVM tool for v3.7-rc0

[Borislav Petkov]

On Sat, Oct 20, 2012 at 06:04:36PM +1100, Stephen Rothwell wrote:
> So are there any compelling arguments from the proponents, or can
> I remove this from linux-next (and have it removed from the tip
> auto-latest branch)?

FWIW, I gave this a run and I have to say, it works as advertized: I
built it and ran it with the latest kernel and the thing simply boots
the kernel. Even without a disk image - the simplest command is:

$ ./lkvm run --kernel ../../arch/x86/boot/bzImage

and it gets me a shell in the vm after a second.

So the absolute advantage it gives kernel devs is that they can
smoke-test whether their stuff boots in seconds.

This is probably not helpful when enabling specific hw features but
should be pretty helpful for generic arch stuff.

HTH.

-- 
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Borislav Petkov]

On Sat, Oct 20, 2012 at 05:41:49PM +, Artem S. Tashkinov wrote:
> On Oct 20, 2012, Borislav Petkov wrote: 
> 
> > Yeah, your kernel is tainted with a proprietary module (vbox*, etc). Can
> > you reproduce your corruptions (this is what it looks like) without that
> > module?
> 
> Yes, I can reproduce this panic with zero proprietary/non-free modules loaded.
> 
> The problem is the kernel doesn't even print a kernel panic - the
> system just freezes completely - cursor in a text console stops blinking.
> 
> I have no means to debug it using a serial console - what can I do?

Ok, here's what you can try:

* You say this happens with google chrome. Does it happen if you use
another browser: firefox, etc?

* Can you build a 64-bit kernel and try the same with it? The 32-bit
userspace should work in compat mode just fine.

* Can you run memtest on your machine and check whether your DIMMs
aren't generating ECC errors? Are your DIMMs ECC, btw?

* What about netconsole? You only need another machine on the same
network: Documentation/networking/netconsole.txt.

* boot with "pause_on_oops=600" on the kernel command line to stop the
machine for 600 secs after the first oops happens. Then try to make a
photo of the screen. Make sure to disable X or to be on a text console
so that you can see the oops.

* Try enabling a bunch of debugging options in "Kernel hacking". More
specifically,

CONFIG_DETECT_HUNG_TASK
CONFIG_DEBUG_PREEMPT
CONFIG_DEBUG_SPINLOCK
CONFIG_DEBUG_MUTEXES
CONFIG_DEBUG_LOCK_ALLOC
CONFIG_PROVE_LOCKING
CONFIG_PROVE_RCU
CONFIG_DEBUG_ATOMIC_SLEEP
CONFIG_DEBUG_BUGVERBOSE
CONFIG_DEBUG_INFO
CONFIG_DEBUG_VM
CONFIG_DEBUG_VIRTUAL
CONFIG_DEBUG_MEMORY_INIT
CONFIG_DEBUG_LIST
CONFIG_X86_VERBOSE_BOOTUP
CONFIG_DEBUG_RODATA
...

I hope those should scream in case something goes awry.

HTH.

-- 
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] menuconfig: Replace CIRCLEQ by list_head-style lists.

[Benjamin Poirier]

From: Benjamin Poirier 

sys/queue.h and CIRCLEQ in particular have proven to cause portability
problems (reported on Debian Sarge, Cygwin and FreeBSD)

Reported-by: Tetsuo Handa 
Signed-off-by: Benjamin Poirier 
---
 scripts/kconfig/expr.h  |5 +--
 scripts/kconfig/list.h  |   90 +++
 scripts/kconfig/lkc_proto.h |4 +-
 scripts/kconfig/mconf.c |6 +--
 scripts/kconfig/menu.c  |   14 ---
 5 files changed, 105 insertions(+), 14 deletions(-)
 create mode 100644 scripts/kconfig/list.h

diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index bd2e098..cdd4860 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -12,7 +12,7 @@ extern "C" {
 
 #include 
 #include 
-#include 
+#include "list.h"
 #ifndef __cplusplus
 #include 
 #endif
@@ -175,12 +175,11 @@ struct menu {
 #define MENU_ROOT  0x0002
 
 struct jump_key {
-   CIRCLEQ_ENTRY(jump_key) entries;
+   struct list_head entries;
size_t offset;
struct menu *target;
int index;
 };
-CIRCLEQ_HEAD(jk_head, jump_key);
 
 #define JUMP_NB9
 
diff --git a/scripts/kconfig/list.h b/scripts/kconfig/list.h
new file mode 100644
index 000..934bdba
--- /dev/null
+++ b/scripts/kconfig/list.h
@@ -0,0 +1,90 @@
+#ifndef LIST_H
+#define LIST_H
+
+/*
+ * Copied from include/linux/...
+ */
+
+#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
+
+/**
+ * container_of - cast a member of a structure out to the containing structure
+ * @ptr:the pointer to the member.
+ * @type:   the type of the container struct this is embedded in.
+ * @member: the name of the member within the struct.
+ *
+ */
+#define container_of(ptr, type, member) ({  \
+   const typeof( ((type *)0)->member ) *__mptr = (ptr);\
+   (type *)( (char *)__mptr - offsetof(type,member) );})
+
+
+struct list_head {
+   struct list_head *next, *prev;
+};
+
+
+#define LIST_HEAD_INIT(name) { &(name), &(name) }
+
+#define LIST_HEAD(name) \
+   struct list_head name = LIST_HEAD_INIT(name)
+
+/**
+ * list_entry - get the struct for this entry
+ * @ptr:   the &struct list_head pointer.
+ * @type:  the type of the struct this is embedded in.
+ * @member:the name of the list_struct within the struct.
+ */
+#define list_entry(ptr, type, member) \
+   container_of(ptr, type, member)
+
+/**
+ * list_for_each_entry -   iterate over list of given type
+ * @pos:   the type * to use as a loop cursor.
+ * @head:  the head for your list.
+ * @member:the name of the list_struct within the struct.
+ */
+#define list_for_each_entry(pos, head, member) \
+   for (pos = list_entry((head)->next, typeof(*pos), member);  \
+&pos->member != (head);\
+pos = list_entry(pos->member.next, typeof(*pos), member))
+
+#endif
+
+/**
+ * list_empty - tests whether a list is empty
+ * @head: the list to test.
+ */
+static inline int list_empty(const struct list_head *head)
+{
+   return head->next == head;
+}
+
+/*
+ * Insert a new entry between two known consecutive entries.
+ *
+ * This is only for internal list manipulation where we know
+ * the prev/next entries already!
+ */
+static inline void __list_add(struct list_head *new,
+ struct list_head *prev,
+ struct list_head *next)
+{
+   next->prev = new;
+   new->next = next;
+   new->prev = prev;
+   prev->next = new;
+}
+
+/**
+ * list_add_tail - add a new entry
+ * @new: new entry to be added
+ * @head: list head to add it before
+ *
+ * Insert a new entry before the specified head.
+ * This is useful for implementing queues.
+ */
+static inline void list_add_tail(struct list_head *new, struct list_head *head)
+{
+   __list_add(new, head->prev, head);
+}
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 1d1c085..ef1a738 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -21,9 +21,9 @@ P(menu_get_root_menu,struct menu *,(struct menu *menu));
 P(menu_get_parent_menu,struct menu *,(struct menu *menu));
 P(menu_has_help,bool,(struct menu *menu));
 P(menu_get_help,const char *,(struct menu *menu));
-P(get_symbol_str, void, (struct gstr *r, struct symbol *sym, struct jk_head
+P(get_symbol_str, void, (struct gstr *r, struct symbol *sym, struct list_head
 *head));
-P(get_relations_str, struct gstr, (struct symbol **sym_arr, struct jk_head
+P(get_relations_str, struct gstr, (struct symbol **sym_arr, struct list_head
   *head));
 P(menu_get_ext_help,void,(struct menu *menu, struct gstr *help));
 
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 48f6744..53975cf 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -312,7 +312,7 @@ static void set_config_filename(const char

Re: [RFC PATCH 8/8] printk: Wake up klogd using irq_work

[Frederic Weisbecker]

2012/10/20 Joe Perches :
> On Sat, 2012-10-20 at 12:22 -0400, Frederic Weisbecker wrote:
>> lets implement the printk tick using irq work.
>
> Hi Frederic.
>
> Can you redo this change please against -next in a few days?
>
> Andrew Morton picked up this series,
> https://lkml.org/lkml/2012/10/17/41
> but it's not yet in -next.
>
> https://lkml.org/lkml/2012/10/18/600
>
> kernel/printk.c has been moved to kernel/printk/printk.c
> and broken up into multiple files.

Sure, I will rebase to your work on the next version.

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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

[Al Viro]

On Sat, Oct 20, 2012 at 04:34:01PM +0100, Al Viro wrote:
> On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote:
> > First, the compat_sys_execve() declaration provided in
> > arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only
> > deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve).
> > 
> > However, then arch/tile/kernel/compat.c failed to build, because
> >  is included before , and 
> > provides __ARCH_WANT_SYS_EXECVE, and so we end up with no declaration at
> > all for compat_sys_execve.  For most platforms this is no big deal, but on
> > tile we use the __SYSCALL #define to provide the actual syscall table, and
> > for that to work we need a declaration in scope for each syscall at the
> > time we create the table.
> > 
> > The best solution seems likely to be to copy the other place in
> >  where we need to do something configurable (that is,
> > CONFIG_ARCH_WANT_OLD_COMPAT_IPC), and just convert __ARCH_WANT_SYS_EXECVE
> > to be a Kconfig option.
> 
> Frankly, I hope to get rid of the damn thing completely.  By now we have
> at least some variant of execve conversions for just about everything;
> I certainly hope that by the beginning of the next cycle we'll have it
> defined on everything.  And put unconditional declarations in syscalls.h
> and compat.h
> 
> Actually, we can make the declaration in linux/compat.h unconditional
> right now.  The only obstacle is the situation on arm64; there the mainline
> has C variant of that sucker (with struct pt_regs * in arguments) in
> arch/arm64/kernel/sys_compat.c.  So we could ask Linus to pull
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 execve
> and then do the following in one patch:
>   introduce current_pt_regs() on tile (from your commit)
>   get rid of pt_regs * argument in tile compat_sys_execve(), making it
> use current_pt_regs(); kill its wrapper
>   kill the declarations of compat_sys_execve()/_compat_sys_execve()
> in tile asm/compat.h
>   make declaration in linux/compat.h unconditional
> Note that this does *not* depend on kernel_thread/kernel_execve patch -
> kernel_execve() is never going to hit compat_sys_execve(), since it's
> only called from kernel threads and those are not going to be 32bit.
> After that we can do kernel_thread/kernel_execve commit and
> sys_execve() conversion with nothing outside of arch/tile touched.

Another possible variant is for you to merge that branch from arm64 tree
(only 3 commits it it) and then do as described above.  I.e. on top of
that apply the thing below, followed by your kernel_thread()/kernel_execve()
patch (sans current_pt_regs() part), followed by obviously massaged parts
of generic sys_execve for tile patch I've sent.  FWIW, I've put the
whole series (based at the end of arm64 branch) in signal.git#arch-tile.
Comments?

Drop struct pt_regs * argument in compat_sys_execve()

Signed-off-by: Al Viro 
---
diff --git a/arch/tile/include/asm/compat.h b/arch/tile/include/asm/compat.h
index 3063e6f..3bcf1b9 100644
--- a/arch/tile/include/asm/compat.h
+++ b/arch/tile/include/asm/compat.h
@@ -275,9 +275,6 @@ extern int compat_setup_rt_frame(int sig, struct 
k_sigaction *ka,
 struct compat_sigaction;
 struct compat_siginfo;
 struct compat_sigaltstack;
-long compat_sys_execve(const char __user *path,
-  compat_uptr_t __user *argv,
-  compat_uptr_t __user *envp, struct pt_regs *);
 long compat_sys_rt_sigaction(int sig, struct compat_sigaction __user *act,
 struct compat_sigaction __user *oact,
 size_t sigsetsize);
@@ -304,9 +301,6 @@ long compat_sys_sched_rr_get_interval(compat_pid_t pid,
  struct compat_timespec __user *interval);
 
 /* These are the intvec_64.S trampolines. */
-long _compat_sys_execve(const char __user *path,
-   const compat_uptr_t __user *argv,
-   const compat_uptr_t __user *envp);
 long _compat_sys_sigaltstack(const struct compat_sigaltstack __user *uss_ptr,
struct compat_sigaltstack __user *uoss_ptr);
 long _compat_sys_rt_sigreturn(void);
diff --git a/arch/tile/include/asm/processor.h 
b/arch/tile/include/asm/processor.h
index 8c4dd9f..9a83e53 100644
--- a/arch/tile/include/asm/processor.h
+++ b/arch/tile/include/asm/processor.h
@@ -239,6 +239,9 @@ unsigned long get_wchan(struct task_struct *p);
 #define KSTK_TOP(task) (task_ksp0(task) - STACK_TOP_DELTA)
 #define task_pt_regs(task) \
   ((struct pt_regs *)(task_ksp0(task) - KSTK_PTREGS_GAP) - 1)
+#define current_pt_regs()   \
+  ((struct pt_regs *)((stack_pointer | (THREAD_SIZE - 1)) - \
+  (KSTK_PTREGS_GAP - 1)) - 1)
 #define task_sp(task)  (task_pt_regs(task)->sp)
 #define task_pc(task)  (task_pt_regs(task)->pc)
 /* Aliases for pc and sp (used in fs/proc/array.c) */
diff --git a/arch/tile/kern

WARNING: at fs/sysfs/inode.c:324 sysfs_hash_and_remove+0xa9/0xb0()

[Richard Weinberger]

Hi!

I can reliably trigger the following warning by physically detaching my disk 
array after
stopping md1.

---cut---
[  149.780554] md: md1 stopped.
[  149.780559] md: unbind
[  149.782025] md: export_rdev(sdh1)
[  149.782039] md: unbind
[  149.786026] md: export_rdev(sdg1)
[  149.786038] md: unbind
[  149.786122] md: export_rdev(sdf1)
[  149.786135] md: unbind
[  149.786220] md: export_rdev(sde1)
[  149.786232] md: unbind
[  149.786320] md: export_rdev(sdd1)
[  149.786332] md: unbind
[  149.786414] md: export_rdev(sdc1)
[  162.884735] sd 6:0:1:0: [sdc] Synchronizing SCSI cache
[  162.884778] sd 6:0:1:0: [sdc]
[  162.884781] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  162.885424] mpt2sas0: removing handle(0x000b), sas_addr(0x5003048001804ded)
[  162.887671] sd 6:0:2:0: [sdd] Synchronizing SCSI cache
[  162.887715] sd 6:0:2:0: [sdd]
[  162.887719] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  162.888733] mpt2sas0: removing handle(0x000c), sas_addr(0x5003048001804dee)
[  162.890003] sd 6:0:3:0: [sde] Synchronizing SCSI cache
[  162.890041] sd 6:0:3:0: [sde]
[  162.890044] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  162.890676] mpt2sas0: removing handle(0x000d), sas_addr(0x5003048001804df0)
[  162.891345] sd 6:0:4:0: [sdf] Synchronizing SCSI cache
[  162.891383] sd 6:0:4:0: [sdf]
[  162.891385] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  162.892590] mpt2sas0: removing handle(0x000e), sas_addr(0x5003048001804df1)
[  162.896152] sd 6:0:5:0: [sdg] Synchronizing SCSI cache
[  162.896197] sd 6:0:5:0: [sdg]
[  162.896201] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  162.896891] mpt2sas0: removing handle(0x000f), sas_addr(0x5003048001804df4)
[  162.896896] mpt2sas0: removing handle(0x000a), sas_addr(0x5003048001804dfd)
[  162.896899] mpt2sas0: removing handle(0x0010), sas_addr(0x5003048001804df7)
[  162.898097] [ cut here ]
[  162.898105] WARNING: at /home/abuild/rpmbuild/BUILD/kernel-vanilla-3.6.2/linux-3.6/fs/sysfs/inode.c:324 
sysfs_hash_and_remove+0xa9/0xb0()

[  162.898107] Hardware name: X9SCL/X9SCM
[  162.898108] sysfs: can not remove 'device', no directory
[  162.898110] Modules linked in: ses enclosure cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq 
mperf coretemp crc32c_intel ghash_clmulni_intel i2c_i801 iTCO_wdt kvm_intel sg iTCO_vendor_support e1000e lpc_ich 
mfd_core serio_raw joydev sr_mod kvm aesni_intel button cdrom ablk_helper cryptd video aes_x86_64 pcspkr microcode 
autofs4 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid10 raid1 hid_generic usbhid 
raid0 mgag200 ttm drm_kms_helper drm ehci_hcd i2c_algo_bit sysimgblt sysfillrect syscopyarea usbcore usb_common thermal 
fan processor thermal_sys scsi_dh_emc scsi_dh_rdac scsi_dh_alua scsi_dh_hp_sw scsi_dh mpt2sas scsi_transport_sas raid_class

[  162.898159] Pid: 84, comm: kworker/u:7 Not tainted 3.6.2-7-vanilla #1
[  162.898161] Call Trace:
[  162.898166]  [] ? sysfs_hash_and_remove+0xa0/0xb0
[  162.898172]  [] warn_slowpath_common+0x7a/0xb0
[  162.898176]  [] warn_slowpath_fmt+0x41/0x50
[  162.898180]  [] sysfs_hash_and_remove+0xa9/0xb0
[  162.898184]  [] sysfs_remove_link+0x21/0x30
[  162.898189]  [] enclosure_remove_links+0x68/0x80 
[enclosure]
[  162.898192]  [] ? remove_dir+0x2e/0x40
[  162.898196]  [] enclosure_component_release+0x1f/0x40 
[enclosure]
[  162.898200]  [] device_release+0x22/0x90
[  162.898205]  [] kobject_cleanup+0x82/0x1b0
[  162.898209]  [] kobject_put+0x2b/0x60
[  162.898212]  [] put_device+0x12/0x20
[  162.898215]  [] device_unregister+0x25/0x60
[  162.898218]  [] enclosure_unregister+0x82/0xb0 [enclosure]
[  162.898222]  [] ses_intf_remove+0x7d/0xe0 [ses]
[  162.898226]  [] device_del+0xc9/0x1b0
[  162.898230]  [] device_unregister+0x1d/0x60
[  162.898236]  [] __scsi_remove_device+0xa5/0xc0
[  162.898241]  [] scsi_remove_device+0x2a/0x40
[  162.898246]  [] scsi_remove_target+0x148/0x200
[  162.898256]  [] sas_rphy_remove+0x55/0x60 
[scsi_transport_sas]
[  162.898264]  [] sas_rphy_delete+0x11/0x20 
[scsi_transport_sas]
[  162.898273]  [] sas_port_delete+0x25/0x130 
[scsi_transport_sas]
[  162.898281]  [] ? sas_port_delete+0x130/0x130 
[scsi_transport_sas]
[  162.898290]  [] do_sas_phy_delete+0x45/0x50 
[scsi_transport_sas]
[  162.898294]  [] device_for_each_child+0x36/0x70
[  162.898302]  [] sas_remove_children+0x1a/0x40 
[scsi_transport_sas]
[  162.898310]  [] sas_rphy_remove+0x4a/0x60 
[scsi_transport_sas]
[  162.898318]  [] sas_rphy_delete+0x11/0x20 
[scsi_transport_sas]
[  162.898325]  [] sas_port_delete+0x25/0x130 
[scsi_transport_sas]
[  162.898337]  [] mpt2sas_transport_port_remove+0x1b9/0x1d0 
[mpt2sas]
[  162.898348]  [] _scsih_expander_node_remove+0x80/0xc0 
[mpt2sas]
[  162.898357]  [] mpt2sas_expander_remove+0xcc/0xe0 [mpt2sas]
[  162.898367]  [] _firmware_event_work+0x11e7/0x14b0 
[mpt2sas]
[  162.898372]  [] ? cwq_activate_delayed_work+0x38/0x80
[  162.898376]  [] proc

Re: [PATCH] kconfig/menuconfig: use TAILQ instead of CIRCLEQ

[Yann E. MORIN]

Tetuso, All,

On Saturday 20 October 2012 Tetsuo Handa wrote:
> Michal Marek wrote:
> > On 19.10.2012 14:10, Tetsuo Handa wrote:
> > > Yann E. MORIN wrote:
> > >> So, switch to using TAILQ instead, which are more portable.
> > [...]
> > > Excuse me, but your patch does not solve my problem because kconfig 
> > > started
> > > using macros which does not exist in "@(#)queue.h 8.3 (Berkeley) 
> > > 12/13/93".
> > > Kconfig still fails after applying your patch:
> > > 
> > >   HOSTCC  scripts/kconfig/mconf.o
> > > scripts/kconfig/mconf.c: In function `update_text':
> > > scripts/kconfig/mconf.c:326: warning: implicit declaration of function 
> > > `TAILQ_FOREACH'
> > [...]
> > > scripts/kconfig/mconf.c:378: warning: implicit declaration of function 
> > > `TAILQ_HEAD_INITIALIZER'
> > > 
> > > So, would you add something which looks like "sed -e 's/CIRCLEQ/TAILQ/g'" 
> > > upon
> > > https://lkml.org/lkml/2012/10/16/274 ?
> > 
> > Could you reduce that patch to not copy all of queue.h?
> > TAILQ_HEAD_INITIALIZER can be replaced by a TAILQ_INIT() call after
> > variable definitions, and we do not need stuff like
> > TAILQ_FOREACH_REVERSE. The other option is to reimplement the needed
> > operations under a different name, so that people don't accidentally use
> > other macros that are missing in old queue.h revisions.
> > 
> > Michal
> > 
> 
> I'm fine to manually add missing macros to /usr/include/sys/queue.h of
> "@(#)queue.h 8.3 (Berkeley) 12/13/93" in my environment instead of adding
> define-as-needed lines to scripts/kconfig/expr.h, for missing macros are
> available with that of "@(#)queue.h 8.5 (Berkeley) 8/20/94".

Are you OK with this s/CIRCLEQ/TAILQ/ patch, then?
http://marc.info/?l=linux-kbuild&m=135058165015518&w=2

Regards,
Yann E. MORIN.

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN |  ___   |
| +33 223 225 172 `.---:  X  AGAINST  |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|   v   conspiracy.  |
'--^---^--^'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Perf] Adding timeout option

[Pádraig Brady]

On 10/13/2012 08:54 AM, abhishek agarwal wrote:

Hi folks..

I was thinking that why cant we have a timeout option in perf stat
command.  The timeout feature will help us to profile a process for a
stipulated time (preferably in millisecs) and make perf stat return
after that time.
Eg:

perf stat --timeout=10 sleep 100

This will make perf return and report stats after 10 ms...

Hope anyone can shed some more light on the idea


It seems preferable to use the timeout program to do this.
Either sending a handled signal to the perf process like:

timeout -s HUP 10 perf stat sleep 100

Or even better, just use that to kill the monitored process itself

perf stat timeout 10 sleep 100

cheers,
Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/8] printk: Wake up klogd using irq_work

[Joe Perches]

On Sat, 2012-10-20 at 12:22 -0400, Frederic Weisbecker wrote:
> lets implement the printk tick using irq work.

Hi Frederic.

Can you redo this change please against -next in a few days? 

Andrew Morton picked up this series,
https://lkml.org/lkml/2012/10/17/41
but it's not yet in -next.

https://lkml.org/lkml/2012/10/18/600

kernel/printk.c has been moved to kernel/printk/printk.c
and broken up into multiple files.

thanks,  Joe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sign the modules at install time

[Linus Torvalds]

On Sat, Oct 20, 2012 at 9:41 AM, Romain Francoise  wrote:
>
> Yes, however the key generation itself is horribly verbose and doesn't mix
> very well with the output of a parallel build. Now that the modules are
> signed at install time, presumably the key should be generated then as
> well, and the output cleaned up to look like normal Kbuild messages (with
> support for V=1 for the curious).

No, the key needs to be built before the kernel is built, since the
public part (for verification) needs to be built into the kernel (and
we don't want to make "make install" complicated).

Making it less verbose is clearly an option, though. Right now I like
seeing it just to see when the key gets recreated and so people are
aware of it, but the excitement of that will certainly pall quickly
enough ;)

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sign the modules at install time

[Romain Francoise]

Linus Torvalds  writes:

> I like how the default makefiles do that "create and use random key"
> thing by default. THAT is what I want to see.

Yes, however the key generation itself is horribly verbose and doesn't mix
very well with the output of a parallel build. Now that the modules are
signed at install time, presumably the key should be generated then as
well, and the output cleaned up to look like normal Kbuild messages (with
support for V=1 for the curious).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/tty: Folding Android's keyreset driver in sysRQ

[Mathieu Poirier]

On 12-10-16 09:35 PM, Arve Hjønnevåg wrote:
> On Fri, Oct 5, 2012 at 12:48 PM, Mathieu Poirier
>  wrote:
>> On 12-10-05 12:16 PM, Dmitry Torokhov wrote:
>>> On Fri, Oct 05, 2012 at 11:59:29AM -0600, mathieu.poir...@linaro.org wrote:
 From: "Mathieu J. Poirier" 

 Andrew,

 After requesting a number of changes that, to my understanding
 have been implemented, I have not been able to get the attention
 of the subsystem maintainer on this patch.

 If there are still issues, I'm open to making changes but I want
 to make sure it doesn't get forgotten.  If there no objections,
 would you consider queuint it ?
>>>
>>> Mathieu,
>>>
>>> I have the same objection as before: using platform device solely for
>>> the purpose of passing some data from board code to the driver. Surely
>>> there are other ways of passing this bit of data... What about, for
>>> example, making it an empty weak symbol so that board code could
>>> override it with strong one?
>>
>> Thanks for the comments - I will implement a weak function in the
>> keyreset driver.
>>
> 
> A weak symbol does not work. A single kernel can support multiple
> devices that have unique reset key combinations.
> 

I'm afraid Arve has a point here...  His comment about supporting
multiple combinations got me thinking and forced me to dive back in the
code.

The original keyreset driver can indeed be instantiated multiple times
while the sysrq driver is a one instance model.  In its current
implementation the keyreset extension can only support one reset sequence.

But does a system realistically need to support more than one reset
sequence ?

If so then I can enhance the keyreset extension of the sysrq driver but
that will also mean, as stated by Arve, that we will need to keep the
platform data.  On the flip side it is deemed sufficient to support a
single reset sequence then I'll implement the weak symbol method.

The subject is up for debate, please chime in with your opinion.

Mathieu.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rtc: davinci: clean up probe/remove routines

[Hannu Heikkinen]

Hi,

Sekhar and others, any comments regarding this devm patch for Da Vinci?

br,
Hannu

On 14/10/12 17:03 +0300, Hannu Heikkinen wrote:
> Use the devres managed resource functions in the probe routine.
> Also affects the remove routine where the previously used free and
> release functions are not needed.
> 
> The devm_* functions eliminate the need for manual resource releasing and
> simplify error handling.  Resources allocated by devm_* are freed
> automatically on driver detach.
> 
> Signed-off-by: Hannu Heikkinen 
> ---
>  drivers/rtc/rtc-davinci.c | 59 
> +--
>  1 file changed, 16 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-davinci.c b/drivers/rtc/rtc-davinci.c
> index 14c2109..4a10b4b 100644
> --- a/drivers/rtc/rtc-davinci.c
> +++ b/drivers/rtc/rtc-davinci.c
> @@ -119,8 +119,6 @@ static DEFINE_SPINLOCK(davinci_rtc_lock);
>  struct davinci_rtc {
>   struct rtc_device   *rtc;
>   void __iomem*base;
> - resource_size_t pbase;
> - size_t  base_size;
>   int irq;
>  };
>  
> @@ -482,46 +480,32 @@ static int __init davinci_rtc_probe(struct 
> platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
>   struct davinci_rtc *davinci_rtc;
> - struct resource *res, *mem;
> + struct resource *res;
>   int ret = 0;
>  
> - davinci_rtc = kzalloc(sizeof(struct davinci_rtc), GFP_KERNEL);
> + davinci_rtc = devm_kzalloc(&pdev->dev, sizeof(struct davinci_rtc),
> + GFP_KERNEL);
>   if (!davinci_rtc) {
>   dev_dbg(dev, "could not allocate memory for private data\n");
>   return -ENOMEM;
>   }
>  
> - davinci_rtc->irq = platform_get_irq(pdev, 0);
> - if (davinci_rtc->irq < 0) {
> - dev_err(dev, "no RTC irq\n");
> - ret = davinci_rtc->irq;
> - goto fail1;
> - }
> -
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   if (!res) {
>   dev_err(dev, "no mem resource\n");
> - ret = -EINVAL;
> - goto fail1;
> + return -EINVAL;
>   }
>  
> - davinci_rtc->pbase = res->start;
> - davinci_rtc->base_size = resource_size(res);
> -
> - mem = request_mem_region(davinci_rtc->pbase, davinci_rtc->base_size,
> -  pdev->name);
> - if (!mem) {
> - dev_err(dev, "RTC registers at %08x are not free\n",
> - davinci_rtc->pbase);
> - ret = -EBUSY;
> - goto fail1;
> + davinci_rtc->base = devm_request_and_ioremap(&pdev->dev, res);
> + if (!davinci_rtc->base) {
> + dev_err(&pdev->dev, "Unable to request mem region and grab IOs 
> for device.\n");
> + return -EBUSY;
>   }
>  
> - davinci_rtc->base = ioremap(davinci_rtc->pbase, davinci_rtc->base_size);
> - if (!davinci_rtc->base) {
> - dev_err(dev, "unable to ioremap MEM resource\n");
> - ret = -ENOMEM;
> - goto fail2;
> + davinci_rtc->irq = platform_get_irq(pdev, 0);
> + if (davinci_rtc->irq < 0) {
> + dev_err(dev, "no RTC irq\n");
> + return davinci_rtc->irq;
>   }
>  
>   platform_set_drvdata(pdev, davinci_rtc);
> @@ -529,9 +513,10 @@ static int __init davinci_rtc_probe(struct 
> platform_device *pdev)
>   davinci_rtc->rtc = rtc_device_register(pdev->name, &pdev->dev,
>   &davinci_rtc_ops, THIS_MODULE);
>   if (IS_ERR(davinci_rtc->rtc)) {
> + ret = PTR_ERR(davinci_rtc->rtc);
>   dev_err(dev, "unable to register RTC device, err %ld\n",
>   PTR_ERR(davinci_rtc->rtc));
> - goto fail3;
> + return ret;
>   }
>  
>   rtcif_write(davinci_rtc, PRTCIF_INTFLG_RTCSS, PRTCIF_INTFLG);
> @@ -545,7 +530,7 @@ static int __init davinci_rtc_probe(struct 
> platform_device *pdev)
> 0, "davinci_rtc", davinci_rtc);
>   if (ret < 0) {
>   dev_err(dev, "unable to register davinci RTC interrupt\n");
> - goto fail4;
> + goto err_dev_unreg;
>   }
>  
>   /* Enable interrupts */
> @@ -559,15 +544,8 @@ static int __init davinci_rtc_probe(struct 
> platform_device *pdev)
>  
>   return 0;
>  
> -fail4:
> +err_dev_unreg:
>   rtc_device_unregister(davinci_rtc->rtc);
> -fail3:
> - platform_set_drvdata(pdev, NULL);
> - iounmap(davinci_rtc->base);
> -fail2:
> - release_mem_region(davinci_rtc->pbase, davinci_rtc->base_size);
> -fail1:
> - kfree(davinci_rtc);
>  
>   return ret;
>  }
> @@ -584,13 +562,8 @@ static int __devexit davinci_rtc_remove(struct 
> platform_device *pdev)
>  
>   rtc_device_unregister(davinci_rtc->rtc);
>  
> - iounmap(davinci_rtc->base);
> - release_mem_region(davinci_rtc->pbase, davinci_

[PATCH 2/3] workqueue: trivial fix for return statement in work_busy()

[Joonsoo Kim]

Return type of work_busy() is unsigned int.
There is return statement returning boolean value, 'false' in work_busy().
It is not problem, because 'false' may be treated '0'.
However, fixing it would make code robust.

Signed-off-by: Joonsoo Kim 

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c57358e..27a6dee 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3479,7 +3479,7 @@ unsigned int work_busy(struct work_struct *work)
unsigned int ret = 0;
 
if (!gcwq)
-   return false;
+   return 0;
 
spin_lock_irqsave(&gcwq->lock, flags);
 
-- 
1.7.9.5

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

[PATCH 3/3] workqueue: remove unused argument of wq_worker_waking_up()

[Joonsoo Kim]

Commit 63d95a91 ('workqueue: use @pool instead of @gcwq or @cpu where
applicable') changes an approach to access nr_running.
Thus, wq_worker_waking_up() doesn't use @cpu anymore.
Remove it and remove comment related to it.

Signed-off-by: Joonsoo Kim 

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2d8927f..30a23d0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1243,7 +1243,7 @@ static void ttwu_activate(struct rq *rq, struct 
task_struct *p, int en_flags)
 
/* if a worker is waking up, notify workqueue */
if (p->flags & PF_WQ_WORKER)
-   wq_worker_waking_up(p, cpu_of(rq));
+   wq_worker_waking_up(p);
 }
 
 /*
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 27a6dee..daf101c 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -727,7 +727,6 @@ static void wake_up_worker(struct worker_pool *pool)
 /**
  * wq_worker_waking_up - a worker is waking up
  * @task: task waking up
- * @cpu: CPU @task is waking up to
  *
  * This function is called during try_to_wake_up() when a worker is
  * being awoken.
@@ -735,7 +734,7 @@ static void wake_up_worker(struct worker_pool *pool)
  * CONTEXT:
  * spin_lock_irq(rq->lock)
  */
-void wq_worker_waking_up(struct task_struct *task, unsigned int cpu)
+void wq_worker_waking_up(struct task_struct *task)
 {
struct worker *worker = kthread_data(task);
 
diff --git a/kernel/workqueue_sched.h b/kernel/workqueue_sched.h
index 2d10fc9..c1b45a5 100644
--- a/kernel/workqueue_sched.h
+++ b/kernel/workqueue_sched.h
@@ -4,6 +4,6 @@
  * Scheduler hooks for concurrency managed workqueue.  Only to be
  * included from sched.c and workqueue.c.
  */
-void wq_worker_waking_up(struct task_struct *task, unsigned int cpu);
+void wq_worker_waking_up(struct task_struct *task);
 struct task_struct *wq_worker_sleeping(struct task_struct *task,
   unsigned int cpu);
-- 
1.7.9.5

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

[PATCH 1/3] workqueue: optimize mod_delayed_work_on() when @delay == 0

[Joonsoo Kim]

After try_to_grab_pending(), __queue_delayed_work() is invoked
in mod_delayed_work_on(). When @delay == 0, we can call __queue_work()
directly in order to avoid setting useless timer.

Signed-off-by: Joonsoo Kim 

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index d951daa..c57358e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1477,7 +1477,11 @@ bool mod_delayed_work_on(int cpu, struct 
workqueue_struct *wq,
} while (unlikely(ret == -EAGAIN));
 
if (likely(ret >= 0)) {
-   __queue_delayed_work(cpu, wq, dwork, delay);
+   if (!delay)
+   __queue_work(cpu, wq, &dwork->work);
+   else
+   __queue_delayed_work(cpu, wq, dwork, delay);
+
local_irq_restore(flags);
}
 
-- 
1.7.9.5

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

[PATCH 0/3] workqueue: minor cleanup

[Joonsoo Kim]

This patchset do minor cleanup for workqueue code.

First patch makes minor behavior change, however, it is trivial.
Others doesn't makes any functional difference.
These are based on v3.7-rc1

Joonsoo Kim (3):
  workqueue: optimize mod_delayed_work_on() when @delay == 0
  workqueue: trivial fix for return statement in work_busy()
  workqueue: remove unused argument of wq_worker_waking_up()

 kernel/sched/core.c  |2 +-
 kernel/workqueue.c   |   11 +++
 kernel/workqueue_sched.h |2 +-
 3 files changed, 9 insertions(+), 6 deletions(-)

-- 
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: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Borislav Petkov]

On Sat, Oct 20, 2012 at 12:06:55PM +, Artem S. Tashkinov wrote:
> Hello,
> 
> I'm running vanilla Linux 3.6.2 x86 on top of CentOS 6.3 userspace.
> 
> Every time when I enter the chat roulette website, right click anywhere and 
> choose "Settings",
>  my PC crashes (with or without NVIDIA drivers running, it happens even when 
> I'm running Vesa).
> 
> Web browser: google-chrome-stable-22.0.1229.94-161065.i386.rpm
> OS: Linux 3.6.2 vanilla x86
> CPU: Intel Core i5 2500 (non-overclocked)
> GCC: 4.7.2 vanilla
> 
> The latest crash:
> 
> Oct 20 07:15:22 localhost kernel: [  224.293756] Modules linked in: pppoe 
> pppox ppp_synctty ppp_async crc_ccitt ppp_generic slhc ipv6 nf_conntrack_ftp 
> nf_conntrack_netbios_ns nf_conntrack_broadcast xt_LOG xt_limit 
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp xt_pkttype 
> ipt_ULOG xt_owner xt_multiport iptable_filter ip_tables x_tables w83627ehf 
> adt7475 hwmon_vid vboxpci(O) 
> vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc fuse hid_generic 
> snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi uvcvideo videobuf2_core 
> videodev 
> videobuf2_vmalloc videobuf2_memops usbhid hid sr_mod cdrom coretemp 
> aesni_intel ablk_helper cryptd aes_i586 aes_generic microcode agpgart pcspkr 
> snd_hda_codec_realtek 
> snd_hda_intel snd_hda_codec snd_seq_oss snd_seq_midi_event snd_seq 
> snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc 
> i2c_i801 sg xhci_hcd fan ehci_hcd e1000e evdev [last unloaded: nvidia]
> 
> Oct 20 07:15:22 localhost kernel: [  224.293811] Pid: 2569, comm: 
> console-kit-dae Tainted: P   O 3.6.2-ic #2

Yeah, your kernel is tainted with a proprietary module (vbox*, etc). Can
you reproduce your corruptions (this is what it looks like) without that
module?

Thanks.

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

[RFC PATCH 1/8] irq_work: Move irq_work_raise() declaration/default definition to arch headers

[Frederic Weisbecker]

This optimization doesn't matter much. But this prepares the
arch headers that we need to add a new API in order to detect
when the arch can trigger self IPIs to implement the irq work.

This is necessary later to make printk working in nohz CPUs.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Steven Rostedt 
Cc: Paul Gortmaker 
---
 arch/alpha/include/asm/irq_work.h|6 ++
 arch/arm/include/asm/irq_work.h  |1 +
 arch/arm64/include/asm/irq_work.h|1 +
 arch/blackfin/include/asm/irq_work.h |1 +
 arch/frv/include/asm/irq_work.h  |1 +
 arch/hexagon/include/asm/irq_work.h  |1 +
 arch/mips/include/asm/irq_work.h |1 +
 arch/parisc/include/asm/irq_work.h   |1 +
 arch/powerpc/include/asm/irq_work.h  |6 ++
 arch/s390/include/asm/irq_work.h |1 +
 arch/sh/include/asm/irq_work.h   |1 +
 arch/sparc/include/asm/irq_work.h|6 ++
 arch/x86/include/asm/irq_work.h  |   10 ++
 arch/x86/kernel/irq_work.c   |4 ++--
 include/asm-generic/irq_work.h   |9 +
 include/linux/irq_work.h |1 +
 kernel/irq_work.c|7 ---
 17 files changed, 49 insertions(+), 9 deletions(-)
 create mode 100644 arch/alpha/include/asm/irq_work.h
 create mode 100644 arch/arm/include/asm/irq_work.h
 create mode 100644 arch/arm64/include/asm/irq_work.h
 create mode 100644 arch/blackfin/include/asm/irq_work.h
 create mode 100644 arch/frv/include/asm/irq_work.h
 create mode 100644 arch/hexagon/include/asm/irq_work.h
 create mode 100644 arch/mips/include/asm/irq_work.h
 create mode 100644 arch/parisc/include/asm/irq_work.h
 create mode 100644 arch/powerpc/include/asm/irq_work.h
 create mode 100644 arch/s390/include/asm/irq_work.h
 create mode 100644 arch/sh/include/asm/irq_work.h
 create mode 100644 arch/sparc/include/asm/irq_work.h
 create mode 100644 arch/x86/include/asm/irq_work.h
 create mode 100644 include/asm-generic/irq_work.h

diff --git a/arch/alpha/include/asm/irq_work.h 
b/arch/alpha/include/asm/irq_work.h
new file mode 100644
index 000..814ff3d
--- /dev/null
+++ b/arch/alpha/include/asm/irq_work.h
@@ -0,0 +1,6 @@
+#ifndef _ALPHA_IRQ_WORK_H
+#define _ALPHA_IRQ_WORK_H
+
+extern void arch_irq_work_raise(void);
+
+#endif
diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/arm/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/arm64/include/asm/irq_work.h 
b/arch/arm64/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/arm64/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/blackfin/include/asm/irq_work.h 
b/arch/blackfin/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/blackfin/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/frv/include/asm/irq_work.h b/arch/frv/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/frv/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/hexagon/include/asm/irq_work.h 
b/arch/hexagon/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/hexagon/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/mips/include/asm/irq_work.h b/arch/mips/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/mips/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/parisc/include/asm/irq_work.h 
b/arch/parisc/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/parisc/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h
new file mode 100644
index 000..8b9927f
--- /dev/null
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_POWERPC_IRQ_WORK_H
+#define _ASM_POWERPC_IRQ_WORK_H
+
+extern void arch_irq_work_raise(void);
+
+#endif
diff --git a/arch/s390/include/asm/irq_work.h b/arch/s390/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/s390/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/sh/include/asm/irq_work.h b/arch/sh/include/asm/irq_work.h
new file mode 100644
index 000..f1bffa2
--- /dev/null
+++ b/arch/sh/include/asm/irq_work.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/sparc/include/asm/irq_work.h 
b/arch/sparc/include/asm/irq_work.h
new file mode 100644
index 000..1d062a6
--- /dev/null
+++ b/arch/sparc/include/asm/irq_work.h
@@ -0,0 +1,6 @@
+#ifndef ___ASM_SPARC_IRQ_H
+#define ___ASM_SPARC_IRQ_H
+
+extern void arch_irq_work_raise(void);
+
+#endif
diff --git a/arch/x86/include/asm/irq_work.h b/arch/x86/include/asm/irq_work.h
new file mode 100644
index 000..38eed96
--- /dev/null
+++ b/arch/x86/include/asm/irq_w

[RFC PATCH 2/8] irq_work: Let the arch tell us about self-IPI support

[Frederic Weisbecker]

This prepares us to make printk working on nohz CPUs
using irq work.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Steven Rostedt 
Cc: Paul Gortmaker 
---
 arch/alpha/include/asm/irq_work.h   |5 -
 arch/alpha/kernel/time.c|2 +-
 arch/powerpc/include/asm/irq_work.h |4 +++-
 arch/powerpc/kernel/time.c  |2 +-
 arch/sparc/include/asm/irq_work.h   |4 +++-
 arch/sparc/kernel/pcr.c |2 +-
 arch/x86/include/asm/irq_work.h |9 +
 arch/x86/kernel/irq_work.c  |2 +-
 include/asm-generic/irq_work.h  |   14 ++
 9 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/arch/alpha/include/asm/irq_work.h 
b/arch/alpha/include/asm/irq_work.h
index 814ff3d..3d32132 100644
--- a/arch/alpha/include/asm/irq_work.h
+++ b/arch/alpha/include/asm/irq_work.h
@@ -1,6 +1,9 @@
 #ifndef _ALPHA_IRQ_WORK_H
 #define _ALPHA_IRQ_WORK_H
 
-extern void arch_irq_work_raise(void);
+extern void __arch_irq_work_raise(void);
+#define arch_irq_work_raise __arch_irq_work_raise
+
+#include 
 
 #endif
diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c
index e336694..91c5eec 100644
--- a/arch/alpha/kernel/time.c
+++ b/arch/alpha/kernel/time.c
@@ -90,7 +90,7 @@ DEFINE_PER_CPU(u8, irq_work_pending);
 #define test_irq_work_pending()  __get_cpu_var(irq_work_pending)
 #define clear_irq_work_pending() __get_cpu_var(irq_work_pending) = 0
 
-void arch_irq_work_raise(void)
+void __arch_irq_work_raise(void)
 {
set_irq_work_pending_flag();
 }
diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h
index 8b9927f..8aa36aa 100644
--- a/arch/powerpc/include/asm/irq_work.h
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -1,6 +1,8 @@
 #ifndef _ASM_POWERPC_IRQ_WORK_H
 #define _ASM_POWERPC_IRQ_WORK_H
 
-extern void arch_irq_work_raise(void);
+extern void __arch_irq_work_raise(void);
+#define arch_irq_work_raise __arch_irq_work_raise
 
+#include 
 #endif
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index c9986fd..31565ac 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -466,7 +466,7 @@ DEFINE_PER_CPU(u8, irq_work_pending);
 
 #endif /* 32 vs 64 bit */
 
-void arch_irq_work_raise(void)
+void __arch_irq_work_raise(void)
 {
preempt_disable();
set_irq_work_pending_flag();
diff --git a/arch/sparc/include/asm/irq_work.h 
b/arch/sparc/include/asm/irq_work.h
index 1d062a6..383772d 100644
--- a/arch/sparc/include/asm/irq_work.h
+++ b/arch/sparc/include/asm/irq_work.h
@@ -1,6 +1,8 @@
 #ifndef ___ASM_SPARC_IRQ_H
 #define ___ASM_SPARC_IRQ_H
 
-extern void arch_irq_work_raise(void);
+extern void __arch_irq_work_raise(void);
+#define arch_irq_work_raise __arch_irq_work_raise
 
+#include 
 #endif
diff --git a/arch/sparc/kernel/pcr.c b/arch/sparc/kernel/pcr.c
index 269af58..d1e1ecf 100644
--- a/arch/sparc/kernel/pcr.c
+++ b/arch/sparc/kernel/pcr.c
@@ -43,7 +43,7 @@ void __irq_entry deferred_pcr_work_irq(int irq, struct 
pt_regs *regs)
set_irq_regs(old_regs);
 }
 
-void arch_irq_work_raise(void)
+void __arch_irq_work_raise(void)
 {
set_softint(1 << PIL_DEFERRED_PCR_WORK);
 }
diff --git a/arch/x86/include/asm/irq_work.h b/arch/x86/include/asm/irq_work.h
index 38eed96..dad8266 100644
--- a/arch/x86/include/asm/irq_work.h
+++ b/arch/x86/include/asm/irq_work.h
@@ -1,10 +1,11 @@
 #ifndef _ASM_X86_IRQ_WORK_H
 #define _ASM_X86_IRQ_WORK_H
 
-#ifndef CONFIG_X86_LOCAL_APIC
-#include 
-# else
-extern void arch_irq_work_raise(void);
+#ifdef CONFIG_X86_LOCAL_APIC
+extern void __arch_irq_work_raise(void);
+#define arch_irq_work_raise __arch_irq_work_raise
 #endif
 
+#include 
+
 #endif
diff --git a/arch/x86/kernel/irq_work.c b/arch/x86/kernel/irq_work.c
index 95f5d4e..7389d5e 100644
--- a/arch/x86/kernel/irq_work.c
+++ b/arch/x86/kernel/irq_work.c
@@ -19,7 +19,7 @@ void smp_irq_work_interrupt(struct pt_regs *regs)
 }
 
 #ifdef CONFIG_X86_LOCAL_APIC
-void arch_irq_work_raise(void)
+void __arch_irq_work_raise(void)
 {
if (!cpu_has_apic)
return;
diff --git a/include/asm-generic/irq_work.h b/include/asm-generic/irq_work.h
index a2d4108..e3e4f02 100644
--- a/include/asm-generic/irq_work.h
+++ b/include/asm-generic/irq_work.h
@@ -4,6 +4,20 @@
 /*
  * Lame architectures will get the timer tick callback
  */
+#ifndef arch_irq_work_raise
 static inline void arch_irq_work_raise(void) { }
+#endif
+
+/*
+ * Unless told otherwise, consider the arch doesn't implement irq work
+ * using self IPIs but through another way like defaulting to the hook
+ * on the sched tick.
+ */
+#ifndef arch_irq_work_has_ipi
+static inline bool arch_irq_work_has_ipi(void)
+{
+   return false;
+}
+#endif
 
 #endif
-- 
1.7.5.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.kerne

[RFC PATCH 5/8] irq_work: Make self-IPIs optable

[Frederic Weisbecker]

While queuing an irq work, let the caller choose between
triggering a self-IPI right away, provided the arch is able
to do so, or waiting for the next timer interrupt to run the work.

Some non-urgent enqueuers like printk may prefer not to raise
an IPI storm in case of frequent calls on short periods of
time.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Steven Rostedt 
Cc: Paul Gortmaker 
---
 arch/x86/kernel/cpu/mcheck/mce.c |2 +-
 arch/x86/kvm/pmu.c   |2 +-
 drivers/acpi/apei/ghes.c |2 +-
 drivers/staging/iio/trigger/iio-trig-sysfs.c |2 +-
 include/linux/irq_work.h |8 +-
 kernel/events/core.c |4 +-
 kernel/events/ring_buffer.c  |2 +-
 kernel/irq_work.c|   32 +-
 kernel/time/tick-sched.c |2 +-
 9 files changed, 41 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 29e87d3..3020e95 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -549,7 +549,7 @@ static void mce_report_event(struct pt_regs *regs)
return;
}
 
-   irq_work_queue(&__get_cpu_var(mce_irq_work));
+   irq_work_queue(&__get_cpu_var(mce_irq_work), true);
 }
 
 /*
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index cfc258a..0dfc716 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -128,7 +128,7 @@ static void kvm_perf_overflow_intr(struct perf_event 
*perf_event,
 * NMI context. Do it from irq work instead.
 */
if (!kvm_is_in_guest())
-   irq_work_queue(&pmc->vcpu->arch.pmu.irq_work);
+   irq_work_queue(&pmc->vcpu->arch.pmu.irq_work, true);
else
kvm_make_request(KVM_REQ_PMI, pmc->vcpu);
}
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1599566..44be554 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -874,7 +874,7 @@ next:
ghes_clear_estatus(ghes);
}
 #ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
-   irq_work_queue(&ghes_proc_irq_work);
+   irq_work_queue(&ghes_proc_irq_work, true);
 #endif
 
 out:
diff --git a/drivers/staging/iio/trigger/iio-trig-sysfs.c 
b/drivers/staging/iio/trigger/iio-trig-sysfs.c
index 3bac972..7d6f9a9 100644
--- a/drivers/staging/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/staging/iio/trigger/iio-trig-sysfs.c
@@ -105,7 +105,7 @@ static ssize_t iio_sysfs_trigger_poll(struct device *dev,
struct iio_trigger *trig = to_iio_trigger(dev);
struct iio_sysfs_trig *sysfs_trig = trig->private_data;
 
-   irq_work_queue(&sysfs_trig->work);
+   irq_work_queue(&sysfs_trig->work, true);
 
return count;
 }
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index b39ea0b..71a33b7 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -17,8 +17,14 @@ void init_irq_work(struct irq_work *work, void 
(*func)(struct irq_work *))
work->func = func;
 }
 
-bool irq_work_queue(struct irq_work *work);
+bool irq_work_queue(struct irq_work *work, bool ipi);
 void irq_work_run(void);
 void irq_work_sync(struct irq_work *work);
 
+#ifdef CONFIG_IRQ_WORK
+bool irq_work_needs_cpu(void);
+#else
+static bool irq_work_needs_cpu(void) { return false; }
+#endif
+
 #endif /* _LINUX_IRQ_WORK_H */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index cda3ebd..e7cbbcc 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4900,7 +4900,7 @@ static int __perf_event_overflow(struct perf_event *event,
ret = 1;
event->pending_kill = POLL_HUP;
event->pending_disable = 1;
-   irq_work_queue(&event->pending);
+   irq_work_queue(&event->pending, true);
}
 
if (event->overflow_handler)
@@ -4910,7 +4910,7 @@ static int __perf_event_overflow(struct perf_event *event,
 
if (event->fasync && event->pending_kill) {
event->pending_wakeup = 1;
-   irq_work_queue(&event->pending);
+   irq_work_queue(&event->pending, true);
}
 
return ret;
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index 23cb34f..620df7a 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -39,7 +39,7 @@ static void perf_output_wakeup(struct perf_output_handle 
*handle)
atomic_set(&handle->rb->poll, POLL_IN);
 
handle->event->pending_wakeup = 1;
-   irq_work_queue(&handle->event->pending);
+   irq_work_queue(&handle->event->pending, true);
 }
 
 /*
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 44a5b19..19f537b 100644
--- a/kernel/irq_work.c
+++ b

[RFC PATCH 0/8] printk: Make it usable on nohz CPUs v2

[Frederic Weisbecker]

Hi,

So the design is not quite the same here. Instead of using the ad hoc
printk_tick() in periodic mode and irq_work on nohz mode, printk
is now always using irq_work.

In turn, irq_work subsystem is able to let enqueuers choose between IPI
or lazy tick hook to execute works, and that in order to avoid IPI storm
when we have lots of enqueuing of non-urgent works like klogd wakeup
in short period of time so this keeps the old printk_tick behaviour.

It also teaches irq_work to handle nohz mode.

Warning: only compile tested in x86 for now.

Frederic Weisbecker (8):
  irq_work: Move irq_work_raise() declaration/default definition to
arch headers
  irq_work: Let the arch tell us about self-IPI support
  x86: Implement arch_irq_work_has_ipi()
  nohz: Add API to check tick state
  irq_work: Make self-IPIs optable
  irq_work: Handle queuing without IPI support in dyntick idle mode
  irq_work: Remove CONFIG_HAVE_IRQ_WORK
  printk: Wake up klogd using irq_work

 arch/alpha/Kconfig   |1 -
 arch/alpha/include/asm/irq_work.h|9 +
 arch/alpha/kernel/time.c |2 +-
 arch/arm/Kconfig |1 -
 arch/arm/include/asm/irq_work.h  |1 +
 arch/arm64/Kconfig   |1 -
 arch/arm64/include/asm/irq_work.h|1 +
 arch/blackfin/Kconfig|1 -
 arch/blackfin/include/asm/irq_work.h |1 +
 arch/frv/Kconfig |1 -
 arch/frv/include/asm/irq_work.h  |1 +
 arch/hexagon/Kconfig |1 -
 arch/hexagon/include/asm/irq_work.h  |1 +
 arch/mips/Kconfig|1 -
 arch/mips/include/asm/irq_work.h |1 +
 arch/parisc/Kconfig  |1 -
 arch/parisc/include/asm/irq_work.h   |1 +
 arch/powerpc/Kconfig |1 -
 arch/powerpc/include/asm/irq_work.h  |8 
 arch/powerpc/kernel/time.c   |2 +-
 arch/s390/Kconfig|1 -
 arch/s390/include/asm/irq_work.h |1 +
 arch/sh/Kconfig  |1 -
 arch/sh/include/asm/irq_work.h   |1 +
 arch/sparc/Kconfig   |1 -
 arch/sparc/include/asm/irq_work.h|8 
 arch/sparc/kernel/pcr.c  |2 +-
 arch/x86/Kconfig |1 -
 arch/x86/include/asm/irq_work.h  |   15 
 arch/x86/kernel/cpu/mcheck/mce.c |2 +-
 arch/x86/kernel/irq_work.c   |6 ++--
 arch/x86/kvm/pmu.c   |2 +-
 drivers/acpi/apei/ghes.c |2 +-
 drivers/staging/iio/trigger/Kconfig  |1 -
 drivers/staging/iio/trigger/iio-trig-sysfs.c |2 +-
 include/asm-generic/irq_work.h   |   23 
 include/linux/irq_work.h |9 -
 include/linux/printk.h   |3 --
 include/linux/tick.h |   17 -
 init/Kconfig |5 +--
 kernel/events/core.c |4 +-
 kernel/events/ring_buffer.c  |2 +-
 kernel/irq_work.c|   48 +++--
 kernel/printk.c  |   14 
 kernel/time/tick-sched.c |6 ++--
 kernel/timer.c   |1 -
 46 files changed, 156 insertions(+), 59 deletions(-)
 create mode 100644 arch/alpha/include/asm/irq_work.h
 create mode 100644 arch/arm/include/asm/irq_work.h
 create mode 100644 arch/arm64/include/asm/irq_work.h
 create mode 100644 arch/blackfin/include/asm/irq_work.h
 create mode 100644 arch/frv/include/asm/irq_work.h
 create mode 100644 arch/hexagon/include/asm/irq_work.h
 create mode 100644 arch/mips/include/asm/irq_work.h
 create mode 100644 arch/parisc/include/asm/irq_work.h
 create mode 100644 arch/powerpc/include/asm/irq_work.h
 create mode 100644 arch/s390/include/asm/irq_work.h
 create mode 100644 arch/sh/include/asm/irq_work.h
 create mode 100644 arch/sparc/include/asm/irq_work.h
 create mode 100644 arch/x86/include/asm/irq_work.h
 create mode 100644 include/asm-generic/irq_work.h

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

[RFC PATCH 6/8] irq_work: Handle queuing without IPI support in dyntick idle mode

[Frederic Weisbecker]

If we enqueue a work while in dyntick idle mode and the arch doesn't
have self-IPI support, we may not find an opportunity to run the work
before a while.

In this case, exit the idle loop to re-evaluate irq_work_needs_cpu()
and restart the tick.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Steven Rostedt 
Cc: Paul Gortmaker 
---
 kernel/irq_work.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 19f537b..f3bdcf4 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -71,6 +71,17 @@ static void __irq_work_queue(struct irq_work *work, bool ipi)
 */
if (ipi || !arch_irq_work_has_ipi() || tick_nohz_tick_stopped())
arch_irq_work_raise();
+
+   /*
+* If we rely on the timer tick or some obscure way to run the 
work
+* while the CPU is in dyntick idle mode, we may not have an 
opportunity
+* to do so before a while. Let's just exit the idle loop and 
hope we
+* haven't yet reached the last need_resched() check before the 
CPU goes
+* to low power mode.
+*/
+   if (!arch_irq_work_has_ipi() && tick_nohz_tick_stopped()
+   && is_idle_task(current))
+   set_need_resched();
}
preempt_enable();
 }
-- 
1.7.5.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/

[RFC PATCH 8/8] printk: Wake up klogd using irq_work

[Frederic Weisbecker]

klogd is woken up asynchronously from the tick in order
to do it safely.

However if printk is called when the tick is stopped, the reader
won't be woken up until the next interrupt, which might not fire
before a while. As a result, the user may miss some message.

To fix this, lets implement the printk tick using irq work.
This subsystem takes care of the timer tick state and can
fix up accordingly.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Steven Rostedt 
Cc: Paul Gortmaker 
---
 include/linux/printk.h   |3 ---
 init/Kconfig |1 +
 kernel/printk.c  |   14 +++---
 kernel/time/tick-sched.c |2 +-
 kernel/timer.c   |1 -
 5 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9afc01e..86c4b62 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -98,9 +98,6 @@ int no_printk(const char *fmt, ...)
 extern asmlinkage __printf(1, 2)
 void early_printk(const char *fmt, ...);
 
-extern int printk_needs_cpu(int cpu);
-extern void printk_tick(void);
-
 #ifdef CONFIG_PRINTK
 asmlinkage __printf(5, 0)
 int vprintk_emit(int facility, int level,
diff --git a/init/Kconfig b/init/Kconfig
index 8ba9fc3..9c42e6a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1184,6 +1184,7 @@ config HOTPLUG
 config PRINTK
default y
bool "Enable support for printk" if EXPERT
+   select IRQ_WORK
help
  This option enables normal printk support. Removing it
  eliminates most of the message strings from the kernel image
diff --git a/kernel/printk.c b/kernel/printk.c
index 66a2ea3..721f760 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -1956,7 +1957,7 @@ int is_console_locked(void)
 static DEFINE_PER_CPU(int, printk_pending);
 static DEFINE_PER_CPU(char [PRINTK_BUF_SIZE], printk_sched_buf);
 
-void printk_tick(void)
+static void wake_up_klogd_work_func(struct irq_work *irq_work)
 {
if (__this_cpu_read(printk_pending)) {
int pending = __this_cpu_xchg(printk_pending, 0);
@@ -1969,17 +1970,16 @@ void printk_tick(void)
}
 }
 
-int printk_needs_cpu(int cpu)
-{
-   if (cpu_is_offline(cpu))
-   printk_tick();
-   return __this_cpu_read(printk_pending);
-}
+static struct irq_work wake_up_klogd_work = {
+   .func = wake_up_klogd_work_func
+};
 
 void wake_up_klogd(void)
 {
if (waitqueue_active(&log_wait))
this_cpu_or(printk_pending, PRINTK_PENDING_WAKEUP);
+
+   irq_work_queue(&wake_up_klogd_work, false);
 }
 
 static void console_cont_flush(char *text, size_t size)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 5f87bb5..04dd027 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -288,7 +288,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched 
*ts,
time_delta = timekeeping_max_deferment();
} while (read_seqretry(&xtime_lock, seq));
 
-   if (rcu_needs_cpu(cpu, &rcu_delta_jiffies) || printk_needs_cpu(cpu) ||
+   if (rcu_needs_cpu(cpu, &rcu_delta_jiffies) ||
arch_needs_cpu(cpu) || irq_work_needs_cpu()) {
next_jiffies = last_jiffies + 1;
delta_jiffies = 1;
diff --git a/kernel/timer.c b/kernel/timer.c
index d5de1b2..5d6d0f1 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1349,7 +1349,6 @@ void update_process_times(int user_tick)
account_process_tick(p, user_tick);
run_local_timers();
rcu_check_callbacks(cpu, user_tick);
-   printk_tick();
 #ifdef CONFIG_IRQ_WORK
if (in_irq())
irq_work_run();
-- 
1.7.5.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/

[RFC PATCH 7/8] irq_work: Remove CONFIG_HAVE_IRQ_WORK

[Frederic Weisbecker]

irq work is supposed to work everywhere because of the irq work
hook in the generic timer tick function.

I might be missing something though...

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Steven Rostedt 
Cc: Paul Gortmaker 
---
 arch/alpha/Kconfig  |1 -
 arch/arm/Kconfig|1 -
 arch/arm64/Kconfig  |1 -
 arch/blackfin/Kconfig   |1 -
 arch/frv/Kconfig|1 -
 arch/hexagon/Kconfig|1 -
 arch/mips/Kconfig   |1 -
 arch/parisc/Kconfig |1 -
 arch/powerpc/Kconfig|1 -
 arch/s390/Kconfig   |1 -
 arch/sh/Kconfig |1 -
 arch/sparc/Kconfig  |1 -
 arch/x86/Kconfig|1 -
 drivers/staging/iio/trigger/Kconfig |1 -
 init/Kconfig|4 
 15 files changed, 0 insertions(+), 18 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 7da9124..ea86275 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -5,7 +5,6 @@ config ALPHA
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS
-   select HAVE_IRQ_WORK
select HAVE_PCSPKR_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_DMA_ATTRS
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 767aae8..44bdbfe 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -30,7 +30,6 @@ config ARM
select HAVE_KERNEL_LZO
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_XZ
-   select HAVE_IRQ_WORK
select HAVE_PERF_EVENTS
select PERF_USE_VMALLOC
select HAVE_REGS_AND_STACK_ACCESS_API
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7ff68c9..efa0627 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -17,7 +17,6 @@ config ARM64
select HAVE_GENERIC_DMA_COHERENT
select HAVE_GENERIC_HARDIRQS
select HAVE_HW_BREAKPOINT if PERF_EVENTS
-   select HAVE_IRQ_WORK
select HAVE_MEMBLOCK
select HAVE_PERF_EVENTS
select HAVE_SPARSE_IRQ
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index ccd9193..9c588f7 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -24,7 +24,6 @@ config BLACKFIN
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_TRACE_MCOUNT_TEST
select HAVE_IDE
-   select HAVE_IRQ_WORK
select HAVE_KERNEL_GZIP if RAMKERNEL
select HAVE_KERNEL_BZIP2 if RAMKERNEL
select HAVE_KERNEL_LZMA if RAMKERNEL
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 9d26264..17df48f 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -3,7 +3,6 @@ config FRV
default y
select HAVE_IDE
select HAVE_ARCH_TRACEHOOK
-   select HAVE_IRQ_WORK
select HAVE_PERF_EVENTS
select HAVE_UID16
select HAVE_GENERIC_HARDIRQS
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index b2fdfb7..8a902a7 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -14,7 +14,6 @@ config HEXAGON
# select HAVE_CLK
# select IRQ_PER_CPU
# select GENERIC_PENDING_IRQ if SMP
-   select HAVE_IRQ_WORK
select GENERIC_ATOMIC64
select HAVE_PERF_EVENTS
select HAVE_GENERIC_HARDIRQS
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 35453ea..045bf4d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -4,7 +4,6 @@ config MIPS
select HAVE_GENERIC_DMA_COHERENT
select HAVE_IDE
select HAVE_OPROFILE
-   select HAVE_IRQ_WORK
select HAVE_PERF_EVENTS
select PERF_USE_VMALLOC
select HAVE_ARCH_KGDB
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index b87438b..abbdb7a 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -9,7 +9,6 @@ config PARISC
select RTC_DRV_GENERIC
select INIT_ALL_POSSIBLE
select BUG
-   select HAVE_IRQ_WORK
select HAVE_PERF_EVENTS
select GENERIC_ATOMIC64 if !64BIT
select HAVE_GENERIC_HARDIRQS
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index df7edb8..c071bcb 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -118,7 +118,6 @@ config PPC
select HAVE_SYSCALL_WRAPPERS if PPC64
select GENERIC_ATOMIC64 if PPC32
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
-   select HAVE_IRQ_WORK
select HAVE_PERF_EVENTS
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 99d2d79..d3e251b 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -78,7 +78,6 @@ config S390
select HAVE_KVM if 64BIT
select HAVE_ARCH_TRACEHOOK
select INIT_ALL_POSSIBLE
-   select HAVE_IRQ_WORK
select HAVE_PERF_EVENTS

[RFC PATCH 4/8] nohz: Add API to check tick state

[Frederic Weisbecker]

We need some quick way to check if the CPU has stopped
its tick. This will be useful to implement the printk tick
using the irq work subsystem.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Steven Rostedt 
Cc: Paul Gortmaker 
---
 include/linux/tick.h |   17 -
 kernel/time/tick-sched.c |2 +-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/include/linux/tick.h b/include/linux/tick.h
index f37fceb..2307dd3 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -8,6 +8,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
 
@@ -122,13 +124,26 @@ static inline int tick_oneshot_mode_active(void) { return 
0; }
 #endif /* !CONFIG_GENERIC_CLOCKEVENTS */
 
 # ifdef CONFIG_NO_HZ
+DECLARE_PER_CPU(struct tick_sched, tick_cpu_sched);
+
+static inline int tick_nohz_tick_stopped(void)
+{
+   return __this_cpu_read(tick_cpu_sched.tick_stopped);
+}
+
 extern void tick_nohz_idle_enter(void);
 extern void tick_nohz_idle_exit(void);
 extern void tick_nohz_irq_exit(void);
 extern ktime_t tick_nohz_get_sleep_length(void);
 extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
 extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
-# else
+
+# else /* !CONFIG_NO_HZ */
+static inline int tick_nohz_tick_stopped(void)
+{
+   return 0;
+}
+
 static inline void tick_nohz_idle_enter(void) { }
 static inline void tick_nohz_idle_exit(void) { }
 
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index f423bdd..ccc1971 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -28,7 +28,7 @@
 /*
  * Per cpu nohz control structure
  */
-static DEFINE_PER_CPU(struct tick_sched, tick_cpu_sched);
+DEFINE_PER_CPU(struct tick_sched, tick_cpu_sched);
 
 /*
  * The time, when the last jiffy update happened. Protected by xtime_lock.
-- 
1.7.5.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/

[RFC PATCH 3/8] x86: Implement arch_irq_work_has_ipi()

[Frederic Weisbecker]

Most of the time, x86 can trigger self-IPIs. Tell
irq work subsystem about it.

Signed-off-by: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Steven Rostedt 
Cc: Paul Gortmaker 
---
 arch/x86/include/asm/irq_work.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/irq_work.h b/arch/x86/include/asm/irq_work.h
index dad8266..c7489cd 100644
--- a/arch/x86/include/asm/irq_work.h
+++ b/arch/x86/include/asm/irq_work.h
@@ -2,8 +2,12 @@
 #define _ASM_X86_IRQ_WORK_H
 
 #ifdef CONFIG_X86_LOCAL_APIC
+#include 
+
 extern void __arch_irq_work_raise(void);
 #define arch_irq_work_raise __arch_irq_work_raise
+
+#define arch_irq_work_has_ipi() (cpu_has_apic)
 #endif
 
 #include 
-- 
1.7.5.4

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

[PATCH] ixgbe: Use is_valid_ether_addr

[Joe Perches]

Use the normal kernel test instead of a module specific one.

Signed-off-by: Joe Perches 
---
found when doing that larger style conversion,
might as well submit it.

 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c  |  2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 27 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.h |  1 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c   |  2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_type.h   |  9 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c   |  2 +-
 6 files changed, 4 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index 1077cb2..89fe00d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -1022,7 +1022,7 @@ mac_reset_top:
hw->mac.ops.get_san_mac_addr(hw, hw->mac.san_addr);
 
/* Add the SAN MAC address to the RAR only if it's a valid address */
-   if (ixgbe_validate_mac_addr(hw->mac.san_addr) == 0) {
+   if (is_valid_ether_addr(hw->mac.san_addr)) {
hw->mac.ops.set_rar(hw, hw->mac.num_rar_entries - 1,
hw->mac.san_addr, 0, IXGBE_RAH_AV);
 
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index dbf37e4..2d8f76d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -1762,30 +1762,6 @@ s32 ixgbe_update_eeprom_checksum_generic(struct ixgbe_hw 
*hw)
 }
 
 /**
- *  ixgbe_validate_mac_addr - Validate MAC address
- *  @mac_addr: pointer to MAC address.
- *
- *  Tests a MAC address to ensure it is a valid Individual Address
- **/
-s32 ixgbe_validate_mac_addr(u8 *mac_addr)
-{
-   s32 status = 0;
-
-   /* Make sure it is not a multicast address */
-   if (IXGBE_IS_MULTICAST(mac_addr))
-   status = IXGBE_ERR_INVALID_MAC_ADDR;
-   /* Not a broadcast address */
-   else if (IXGBE_IS_BROADCAST(mac_addr))
-   status = IXGBE_ERR_INVALID_MAC_ADDR;
-   /* Reject the zero address */
-   else if (mac_addr[0] == 0 && mac_addr[1] == 0 && mac_addr[2] == 0 &&
-mac_addr[3] == 0 && mac_addr[4] == 0 && mac_addr[5] == 0)
-   status = IXGBE_ERR_INVALID_MAC_ADDR;
-
-   return status;
-}
-
-/**
  *  ixgbe_set_rar_generic - Set Rx address register
  *  @hw: pointer to hardware structure
  *  @index: Receive address register to write
@@ -1889,8 +1865,7 @@ s32 ixgbe_init_rx_addrs_generic(struct ixgbe_hw *hw)
 * to the permanent address.
 * Otherwise, use the permanent address from the eeprom.
 */
-   if (ixgbe_validate_mac_addr(hw->mac.addr) ==
-   IXGBE_ERR_INVALID_MAC_ADDR) {
+   if (!is_valid_ether_addr(hw->mac.addr)) {
/* Get the MAC address from the RAR0 for later reference */
hw->mac.ops.get_mac_addr(hw, hw->mac.addr);
 
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index d813d11..f49ca84 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -80,7 +80,6 @@ s32 ixgbe_enable_rx_dma_generic(struct ixgbe_hw *hw, u32 
regval);
 s32 ixgbe_fc_enable_generic(struct ixgbe_hw *hw);
 void ixgbe_fc_autoneg(struct ixgbe_hw *hw);
 
-s32 ixgbe_validate_mac_addr(u8 *mac_addr);
 s32 ixgbe_acquire_swfw_sync(struct ixgbe_hw *hw, u16 mask);
 void ixgbe_release_swfw_sync(struct ixgbe_hw *hw, u16 mask);
 s32 ixgbe_get_san_mac_addr_generic(struct ixgbe_hw *hw, u8 *san_mac_addr);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index e2a6691..3bb3485 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7345,7 +7345,7 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
memcpy(netdev->dev_addr, hw->mac.perm_addr, netdev->addr_len);
memcpy(netdev->perm_addr, hw->mac.perm_addr, netdev->addr_len);
 
-   if (ixgbe_validate_mac_addr(netdev->perm_addr)) {
+   if (!is_valid_ether_addr(netdev->perm_addr)) {
e_dev_err("invalid MAC address\n");
err = -EIO;
goto err_sw_init;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 0722f33..9ddac64 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -1833,15 +1833,6 @@ enum {
 /* Number of 100 microseconds we wait for PCI Express master disable */
 #define IXGBE_PCI_MASTER_DISABLE_TIMEOUT 800
 
-/* Check whether address is multicast.  This is little-endian specific check.*/
-#define IXGBE_IS_MULTICAST(Address) \
-(bool)(((u8 *)(Address))[0] & ((u8)0x01))
-
-/* Check whether an a

Re: [PATCH net-next 04/21] wireless: Convert is__ether_addr uses to eth_addr_

[Arend van Spriel]

On 10/19/2012 05:55 AM, Joe Perches wrote:

Convert the old ether_addr tests to eth_addr_.
Adds api consistency.


Acked-by: Arend van Spriel 

Signed-off-by: Joe Perches 
---
  .../net/wireless/brcm80211/brcmfmac/dhd_linux.c|4 ++--
  .../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c  |2 +-
  .../net/wireless/brcm80211/brcmsmac/mac80211_if.c  |2 +-
  drivers/net/wireless/brcm80211/brcmsmac/main.c |   16 



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

[GIT PULL] arm64: Fixes for 3.7

[Catalin Marinas]

Hi Linus,

Please pull the arm64-fixes tag below. Thanks.

The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git 
tags/arm64-fixes

for you to fetch changes up to aeed41a9371ee02257b608eb06a9058507a7d0f4:

  arm64: fix alignment padding in assembly code (2012-10-20 11:12:01 +0100)


Main changes:
- AArch64 Linux compilation fixes following 3.7-rc1 changes
  (MODULES_USE_ELF_RELA, update_vsyscall() prototype)
- Unnecessary register setting in start_thread() (thanks to Al Viro)
- ptrace fixes


Catalin Marinas (4):
  arm64: Select MODULES_USE_ELF_RELA
  arm64: Fix the update_vsyscall() prototype
  arm64: Ignore memory blocks below PHYS_OFFSET
  arm64: No need to set the x0-x2 registers in start_thread()

Marc Zyngier (1):
  arm64: fix alignment padding in assembly code

Sachin Kamat (1):
  arm64: Remove duplicate inclusion of mmu_context.h in smp.c

Will Deacon (2):
  arm64: ptrace: make structure padding explicit for debug registers
  arm64: ptrace: use HW_BREAKPOINT_EMPTY type for disabled breakpoints

 arch/arm64/Kconfig   |  1 +
 arch/arm64/include/asm/Kbuild|  1 -
 arch/arm64/include/asm/linkage.h |  7 
 arch/arm64/include/asm/processor.h   | 10 -
 arch/arm64/include/uapi/asm/ptrace.h |  3 +-
 arch/arm64/kernel/ptrace.c   | 73 +---
 arch/arm64/kernel/setup.c| 12 ++
 arch/arm64/kernel/smp.c  |  1 -
 arch/arm64/kernel/vdso.c | 20 +-
 9 files changed, 83 insertions(+), 45 deletions(-)
 create mode 100644 arch/arm64/include/asm/linkage.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Build bug because of binutils 2.21

[Steven Rostedt]

Peter,

Thomas suggested that I email you to decide if a bug I stumbled on with
binutils should be cause to blacklist version 2.21. Note, testing
against 2.22 does not show this issue.

A couple of days ago I went to test 3.6.1-rt2 and while building the
i386 kernel, the build failed. I first thought it was a bug in the -rt
patch, but then I tested vanilla 3.6.1 and that failed too. I then went
to debug this in my non -rt development repo but the build completed
without failure.

With more investigation, it seemed that one repo would cause the issue
but the other did not. A diff -r showed that the two repos were
identical (besides the .git files and my patches directory).

The build was basically:

  cd good
  make ARCH=i386 O=/work/build clean
  make ARCH=i386 O=/work/build
  
  cd ../bad
  make ARCH=i386 O=/work/build clean
  make ARCH=i386 O=/work/build
  

The error was:

lib/lib.a(decompress.o):(.rodata+0x44): undefined reference to `unlzo'

In desperation to figure out what was happening, I did the following:

 cp -r bad test
 cd test
 make ARCH=i386 O=/work/build

And it worked! Note, I could go back and forth between the directories
and the test always worked and the 'bad' directory always failed.

Doing a make V=1, I was able to find that the problem happened during
the compile of decompress_unlzo.c. Strange that the file was identical
in both directories. I even removed the file from the good directory and
made it a softlink to the bad one, and the good directory still worked.
I even removed it again and made it a hard link and it still worked!

Finally I found that the output of the assembly from decompress_unlzo.c
was slightly different. By doing the make V=1 code by hand, I could
start with the output of the .s (by making it with the -S gcc option)
that .s created by the good directory would succeed the final link, and
the .s created by the bad directory would fail the final link.

Here's the diff between the two .s files:

--- lib/decompress_unlzo.stable-rt.git.s2012-10-20 09:37:22.0 
-0400
+++ lib/decompress_unlzo.stable-xt.git.s2012-10-20 09:37:22.0 
-0400
@@ -63,7 +63,7 @@
.type   parse_header, @function
 parse_header:
 .LFB1043:
-   .file 3 "/work/rt/stable-rt.git/lib/decompress_unlzo.c"
+   .file 3 "/work/rt/stable-xt.git/lib/decompress_unlzo.c"
.loc 3 55 0
.cfi_startproc
 .LVL3:
@@ -3942,6 +3942,8 @@
.string "GNU C 4.6.0"
 .LASF187:
.string "acpi_disabled"
+.LASF204:
+   .string "/work/rt/stable-xt.git/lib/decompress_unlzo.c"
 .LASF87:
.string "NR_INACTIVE_FILE"
 .LASF42:
@@ -3996,8 +3998,6 @@
.string "long long int"
 .LASF101:
.string "NR_BOUNCE"
-.LASF57:
-   .string "PCPU_FC_EMBED"
 .LASF182:
.string "ioport_resource"
 .LASF119:
@@ -4308,8 +4308,8 @@
.string "kmalloc"
 .LASF147:
.string "unlzo"
-.LASF204:
-   .string "/work/rt/stable-rt.git/lib/decompress_unlzo.c"
+.LASF57:
+   .string "PCPU_FC_EMBED"
 .LASF192:
.string "x86_bios_cpu_apicid"
 .LASF77:

Note, the stable-rt.git file was the 'bad' directory and the
'stable-xt.git' file was from the good copied directory.

I tarballed all the necessary files and placed them here:
http://rostedt.homelinux.com/private/broken.tar.bz2

If you untar this and go into the broken directory, you will find a
'compile' file. Edit the GCC_PATH and GCC_PREFIX to point to a gcc with
2.21 binutils and you should be able to see this same bug. Note, my gcc
and my binutils were compiled from scratch, and I've been using this for
years and this is the first time I've had issues with it. I tested this
on both a Debian box and a Fedora F14 box, and they both showed the
issue (same version of gcc/binutils for both as I built them
individually for both boxes).

If you run ./compile with no arguments, it will compile, archive and
link the good .s file and should succeed. If you run ./compile with an
argument (any argument), it will compile, archive and link the bad .s
file and should give you that error message. If you run it with an
argument but also define GCC_AR_PATH and GCC_AR_PREFIX to be the path
and prefix of ar from binutils 2.22, it will then work.

It looks like there is a bug with 'ar' in binutils 2.21 that can cause
linking issues with these .s files.

As I said, Thomas suggested to ask you if this should be cause to
blacklist 2.21 as a 'reliable' toolchain for building the kernel. Makes
no difference to me. I've just finished upgrading my distcc farm to
2.22.

-- 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: question on NUMA page migration

[Rik van Riel]

On 10/19/2012 09:23 PM, Ingo Molnar wrote:


* Rik van Riel  wrote:


On 10/19/2012 01:53 PM, Peter Zijlstra wrote:

On Fri, 2012-10-19 at 13:13 -0400, Rik van Riel wrote:



Another alternative might be to do the put_page inside
do_prot_none_numa().  That would be analogous to do_wp_page
disposing of the old page for the caller.


It'd have to be inside migrate_misplaced_page(), can't do before
isolate_lru_page() or the page might disappear. Doing it after is
(obviously) too late.


Keeping an extra refcount on the page might _still_
result in it disappearing from the process by some
other means, in-between you grabbing the refcount
and invoking migration of the page.


I am not real happy about NUMA migration introducing its own
migration mode...


You didn't seem to mind too much earlier, but I can remove it if you
want.


Could have been reviewing fatigue :)


:-)


And yes, it would have been nice to not have a special
migration mode for sched/numa.

Speaking of, when do you guys plan to submit a (cleaned up)
version of the sched/numa patch series for review on lkml?


Which commit(s) worry you specifically?


One of them would be the commit that introduces MIGRATE_FAULT.
Adding it in one patch, and removing it into a next just makes
things harder on the reviewers.

03a040f6c17ab81659579ba6abe267c0562097e4


If the changesets with NUMA syscalls are still in your tree's
history, they should not be submitted as part of the patch
series, either.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: ab8500: add devicetree support for fuelgauge

[Francesco Lavra]

Hi Rajanikanth,

On 10/16/2012 05:36 AM, Rajanikanth H.V wrote:
> From: "Rajanikanth H.V" 
> 
> - This patch adds device tree support for fuelgauge driver
> - optimize bm devices platform_data usage and of_probe(...)
>   Note: of_probe() routine for battery managed devices is made
>   common across all bm drivers.
> - test status:
>   - interrupt numbers assigned differs between legacy and FDT mode.
> 
> Legacy platform_data Mode:
> root@ME:/ cat /proc/interrupts
>CPU0   CPU1
> 483:  0  0ab8500  ab8500-ponkey-dbf
> 484:  0  0ab8500  ab8500-ponkey-dbr
> 485:  0  0ab8500  BATT_OVV
> 494:  0  1ab8500
> 495:  0  0ab8500  ab8500-rtc
> 501:  0 13ab8500  NCONV_ACCU
> 503:  7 22ab8500  CCEOC
> 504:  0  1ab8500  CC_INT_CALIB
> 505:  0  0ab8500  LOW_BAT_F
> 516:  0 34ab8500  ab8500-gpadc
> 556:  0  0ab8500  usb-link-status
> 
> FDT Mode:
> root@ME:/ cat /proc/interrupts
>CPU0   CPU1
>   6:  0  0ab8500  ab8500-ponkey-dbf
>   7:  0  0ab8500  ab8500-ponkey-dbr
>   8:  0  0ab8500  BATT_OVV
> 162:  0  7ab8500  ab8500-gpadc
> 163:  0  1ab8500
> 164:  0  0ab8500  ab8500-rtc
> 484:  0  0ab8500  usb-link-status
> 499:  0  4ab8500  NCONV_ACCU
> 500:  0  0ab8500  LOW_BAT_F
> 502:  0  1ab8500  CC_INT_CALIB
> 503:  0  6ab8500  CCEOC
> 
> Signed-off-by: Rajanikanth H.V 
[...]
> +int __devinit
> +bmdevs_of_probe(struct device *dev,
> + struct device_node *np,
> + struct abx500_bm_data **battery)
> +{
> + struct  abx500_battery_type *btype;
> + struct  device_node *np_bat_supply;
> + struct  abx500_bm_data *bat;
> + int i, thermistor;
> + char*bat_tech = "UNKNOWN";

This initialization is useless.

> +
> + *battery = devm_kzalloc(dev, sizeof(*bat), GFP_KERNEL);
> + if (!*battery) {
> + dev_err(dev, "%s no mem for plat_data\n", __func__);
> + return -ENOMEM;
> + }
> + *battery = &ab8500_bm_data;

Looks like dynamic allocation here is not what you need, since you are
overwriting the pointer to the allocated data.

> +
> + /* get phandle to 'battery-info' node */
> + np_bat_supply = of_parse_phandle(np, "battery", 0);
> + if (!np_bat_supply) {
> + dev_err(dev, "missing property battery\n");
> + return -EINVAL;
> + }
> + if (of_property_read_bool(np_bat_supply,
> + "thermistor-on-batctrl"))
> + thermistor = NTC_INTERNAL;
> + else
> + thermistor = NTC_EXTERNAL;
> +
> + bat = *battery;
> + if (thermistor == NTC_EXTERNAL) {
> + bat->n_btypes  = 4;
> + bat->bat_type  = bat_type_ext_thermistor;
> + bat->adc_therm = ABx500_ADC_THERM_BATTEMP;
> + }
> + bat_tech = (char *)of_get_property(
> + np_bat_supply, "stericsson,battery-type", NULL);

No need to cast a void * to a char *.

> + if (!bat_tech) {
> + dev_warn(dev, "missing property battery-name/type\n");
> + strncpy(bat_tech, "UNKNOWN", 7);

You are writing at a NULL pointer here...

> + }
> + of_node_put(np_bat_supply);

You can't call of_node_put here, because you are going to use bat_tech
later on. You have to call it at the end of this function, after you are
done with bat_tech.

> +
> + if (strncmp(bat_tech, "LION", 4) == 0) {
> + bat->no_maintenance  = true;
> + bat->chg_unknown_bat = true;
> + bat->bat_type[BATTERY_UNKNOWN].charge_full_design = 2600;
> + bat->bat_type[BATTERY_UNKNOWN].termination_vol= 4150;
> + bat->bat_type[BATTERY_UNKNOWN].recharge_vol   = 4130;
> + bat->bat_type[BATTERY_UNKNOWN].normal_cur_lvl = 520;
> + bat->bat_type[BATTERY_UNKNOWN].normal_vol_lvl = 4200;
> + }
> + /* select the battery resolution table */
> + for (i = 0; i < bat->n_btypes; ++i) {
> + btype = (bat->bat_type + i);
> + if (thermistor == NTC_EXTERNAL) {
> + btype->batres_tbl =
> + temp_to_batres_tbl_ext_thermistor;
> + } else if (strncmp(bat_tech, "LION", 4) == 0) {
> + btype->batres_tbl =
> + temp_to_batres_tbl_9100;
> + } else {
> + btype->batres_tbl =
> + temp_to_batres_tbl_thermistor;
> + }
> + }
> + return 0;
> +}
[...]
> diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
> index bf02225..ff64dd4 100644
> 

[PATCH for-v3.7 2/2] slub: optimize kmalloc* inlining for GFP_DMA

[Joonsoo Kim]

kmalloc() and kmalloc_node() of the SLUB isn't inlined when @flags = __GFP_DMA.
This patch optimize this case,
so when @flags = __GFP_DMA, it will be inlined into generic code.

Cc: Christoph Lameter 
Signed-off-by: Joonsoo Kim 

diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index 4c75f2b..4adf50b 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -147,6 +147,7 @@ struct kmem_cache {
  * 2^x bytes of allocations.
  */
 extern struct kmem_cache *kmalloc_caches[SLUB_PAGE_SHIFT];
+extern struct kmem_cache *kmalloc_dma_caches[SLUB_PAGE_SHIFT];
 
 /*
  * Sorry that the following has to be that ugly but some versions of GCC
@@ -266,19 +267,24 @@ static __always_inline void *kmalloc_large(size_t size, 
gfp_t flags)
 
 static __always_inline void *kmalloc(size_t size, gfp_t flags)
 {
+   struct kmem_cache *s;
+   int index;
+
if (__builtin_constant_p(size)) {
if (size > SLUB_MAX_SIZE)
return kmalloc_large(size, flags);
 
-   if (!(flags & SLUB_DMA)) {
-   int index = kmalloc_index(size);
-   struct kmem_cache *s = kmalloc_caches[index];
-
-   if (!index)
-   return ZERO_SIZE_PTR;
+   index = kmalloc_index(size);
+   if (!index)
+   return ZERO_SIZE_PTR;
+#ifdef CONFIG_ZONE_DMA
+   if (unlikely(flags & SLUB_DMA)) {
+   s = kmalloc_dma_caches[index];
+   } else
+#endif
+   s = kmalloc_caches[index];
 
-   return kmem_cache_alloc_trace(s, flags, size);
-   }
+   return kmem_cache_alloc_trace(s, flags, size);
}
return __kmalloc(size, flags);
 }
@@ -303,13 +309,19 @@ kmem_cache_alloc_node_trace(struct kmem_cache *s,
 
 static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
 {
-   if (__builtin_constant_p(size) &&
-   size <= SLUB_MAX_SIZE && !(flags & SLUB_DMA)) {
-   int index = kmalloc_index(size);
-   struct kmem_cache *s = kmalloc_caches[index];
+   struct kmem_cache *s;
+   int index;
 
+   if (__builtin_constant_p(size) && size <= SLUB_MAX_SIZE) {
+   index = kmalloc_index(size);
if (!index)
return ZERO_SIZE_PTR;
+#ifdef CONFIG_ZONE_DMA
+   if (unlikely(flags & SLUB_DMA)) {
+   s = kmalloc_dma_caches[index];
+   } else
+#endif
+   s = kmalloc_caches[index];
 
return kmem_cache_alloc_node_trace(s, flags, node, size);
}
diff --git a/mm/slub.c b/mm/slub.c
index a0d6984..a94533c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3222,7 +3222,8 @@ struct kmem_cache *kmalloc_caches[SLUB_PAGE_SHIFT];
 EXPORT_SYMBOL(kmalloc_caches);
 
 #ifdef CONFIG_ZONE_DMA
-static struct kmem_cache *kmalloc_dma_caches[SLUB_PAGE_SHIFT];
+struct kmem_cache *kmalloc_dma_caches[SLUB_PAGE_SHIFT];
+EXPORT_SYMBOL(kmalloc_dma_caches);
 #endif
 
 static int __init setup_slub_min_order(char *str)
-- 
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/