Re: [ACPI/PCI] possible recursive locking detected

[Yinghai Lu]

On Fri, Sep 21, 2012 at 9:53 PM, Yinghai Lu  wrote:
> On Fri, Sep 21, 2012 at 5:35 PM, Fengguang Wu  wrote:
>> Hi Taku,
>>
>> The below oops is pretty reproducible, and shows up first in:
>>
>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
>> pci/taku-acpi-pci-host-bridge-v3
>> head:   e3faec8ea9c8aa683c56fa20ff2c58a4c5857960
>> commit: d3c663236318a43fed5d86a643e6ea2534e9220e [5/7] PCI/ACPI: Protect 
>> acpi_pci_roots list with mutex
>>
>> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
>> acpi_pci_register_driver+0x21/0x79
>> [8.613239]   lock(acpi_pci_root_lock);
>> [8.613239]   lock(acpi_pci_root_lock);
>> [8.613239]  #0:  (acpi_pci_root_lock){+.+.+.}, at: [] 
>> acpi_pci_register_driver+0x21/0x79
>> [8.613239]  [] ? 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  [] ? 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  [] ? 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  [] acpi_get_pci_rootbridge_handle+0x22/0x63
>>
>> [8.610859]
>> [8.611385] =
>> [8.612505] [ INFO: possible recursive locking detected ]
>> [8.613239] 3.6.0-rc1-00022-gd3c6632 #7512 Not tainted
>> [8.613239] -
>> [8.613239] swapper/0/1 is trying to acquire lock:
>> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]
>> [8.613239] but task is already holding lock:
>> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
>> acpi_pci_register_driver+0x21/0x79
>> [8.613239]
>> [8.613239] other info that might help us debug this:
>> [8.613239]  Possible unsafe locking scenario:
>> [8.613239]
>> [8.613239]CPU0
>> [8.613239]
>> [8.613239]   lock(acpi_pci_root_lock);
>> [8.613239]   lock(acpi_pci_root_lock);
>> [8.613239]
>> [8.613239]  *** DEADLOCK ***
>> [8.613239]
>> [8.613239]  May be due to missing lock nesting notation
>> [8.613239]
>> [8.613239] 1 lock held by swapper/0/1:
>> [8.613239]  #0:  (acpi_pci_root_lock){+.+.+.}, at: [] 
>> acpi_pci_register_driver+0x21/0x79
>> [8.613239]
>> [8.613239] stack backtrace:
>> [8.613239] Pid: 1, comm: swapper/0 Not tainted 3.6.0-rc1-00022-gd3c6632 
>> #7512
>> [8.613239] Call Trace:
>> [8.613239]  [] __lock_acquire+0xbef/0xd04
>> [8.613239]  [] ? kvm_clock_read+0x2e/0x36
>> [8.613239]  [] lock_acquire+0xd5/0x119
>> [8.613239]  [] ? 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  [] ? 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  [] __mutex_lock_common+0x58/0x387
>> [8.613239]  [] ? 
>> acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  [] ? kvm_clock_read+0x2e/0x36
>> [8.613239]  [] ? irq_trace+0x14/0x21
>> [8.613239]  [] mutex_lock_nested+0x40/0x45
>> [8.613239]  [] acpi_get_pci_rootbridge_handle+0x22/0x63
>> [8.613239]  [] acpi_pci_get_bridge_handle+0x2c/0x2e
>> [8.613239]  [] acpi_pci_check_ejectable+0x18/0x49
>> [8.613239]  [] ? _raw_spin_unlock_irqrestore+0x45/0x61
>> [8.613239]  [] register_slot+0x2f/0x460
>> [8.613239]  [] ? up+0x39/0x3e
>> [8.613239]  [] acpi_ns_walk_namespace+0xbe/0x179
>> [8.613239]  [] ? acpi_os_wait_semaphore+0x45/0x5a
>> [8.613239]  [] ? kzalloc.constprop.14+0x10/0x10
>> [8.613239]  [] ? kzalloc.constprop.14+0x10/0x10
>> [8.613239]  [] acpi_walk_namespace+0x98/0xcb
>> [8.613239]  [] init_bridge_misc+0x4c/0xd5
>> [8.613239]  [] add_bridge+0xe9/0x138
>> [8.613239]  [] acpi_pci_register_driver+0x52/0x79
>> [8.613239]  [] ? shpcd_init+0xf0/0xf0
>> [8.613239]  [] acpiphp_glue_init+0x48/0x51
>> [8.613239]  [] acpiphp_init+0x2b/0x50
>> [8.613239]  [] do_one_initcall+0x7f/0x13a
>> [8.613239]  [] kernel_init+0x13c/0x1c0
>> [8.613239]  [] ? do_early_param+0x8c/0x8c
>> [8.613239]  [] kernel_thread_helper+0x4/0x10
>> [8.613239]  [] ? retint_restore_args+0x13/0x13
>> [8.613239]  [] ? start_kernel+0x3d1/0x3d1
>> [8.613239]  [] ? gs_change+0x13/0x13
>
> Please check attached patch that should fix the problem.

updated more aggressive version. two patches.

-Yinghai


pci_root_bus_to_handle_1.patch
Description: Binary data


pci_root_bus_to_handle_2.patch
Description: Binary data

Re: [PATCH 6/7] mm: add CONFIG_DEBUG_VM_RB build option

[Jiri Slaby]

On 09/16/2012 09:07 PM, Hugh Dickins wrote:
>> What was the way that
>> Hugh used to reproduce the other issue?
> 
> I've lost track of which issue is "other".

The other was meant to be the BUG I hit.

> To reproduce Sasha's interval_tree.c warnings, all I had to do was switch
> on CONFIG_DEBUG_VM_RB (I regret not having done so before) and boot up.
> 
> I didn't look to see what was doing the mremap which caused the warning
> until now: surprisingly, it's microcode_ctl.  I've not made much effort
> to get the right set of sources and work out why that would be using
> mremap (a realloc inside a library?).
> 
> I failed to reproduce your BUG in huge_memory.c, but what I was trying
> was SuSE update via yast2, on several machines; but perhaps because
> they were all fairly close to up-to-date, I didn't hit a problem.
> (That was before I turned on DEBUG_VM_RB for Sasha's.)

The good news are that I cannot reproduce either with the patch applied.

thanks,
-- 
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: Add devm_clk_{register,unregister}()

[Stephen Boyd]

On 9/21/2012 6:07 PM, Mike Turquette wrote
> I'm not taking any more changes for 3.7, so in the interest of me being
> lazy can you resend with the fixup?

Sure. I'll pick up Mark's acks too and send the whole series again.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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

Re: [PATCH v2 2/5] unicore32: pwm: Use module_platform_driver()

[Thierry Reding]

On Sat, Sep 22, 2012 at 10:56:30AM +0800, guanxue...@mprc.pku.edu.cn wrote:
> > Some of the boilerplate code can be eliminated by using this macro. The
> > driver was previously registered with an arch_initcall(), so technically
> > this is no longer the same, but when the driver is moved to the PWM
> > framework, deferred probing will take care of any driver probe ordering
> > issues.
> >
> > Signed-off-by: Thierry Reding 
> 
> Tested-by: Qin Rui 
> Acked-by: Guan Xuetao 
> 
> Thanks & Regards,
> Guan Xuetao

Great! If you don't mind I'll take this through the PWM tree with your
Acked-by.

Thierry


pgpIVtSYTQq8c.pgp
Description: PGP signature

Re: [PATCH v2 0/3] MIPS: JZ4740: Move PWM driver to PWM framework

[Thierry Reding]

On Mon, Sep 10, 2012 at 02:05:16PM +0200, Thierry Reding wrote:
> Hi,
> 
> This small series fixes a build error due to a circular header
> dependency, exports the timer API so it can be used outside of
> the arch/mips/jz4740 tree and finally moves and converts the
> JZ4740 PWM driver to the PWM framework.
> 
> Note that I don't have any hardware to test this on, so I had to
> rely on compile tests only. Patches 1 and 2 should probably go
> through the MIPS tree, while I can take patch 3 through the PWM
> tree. It touches a couple of files in arch/mips but the changes
> are unlikely to cause conflicts.
> 
> Thierry
> 
> Thierry Reding (3):
>   MIPS: JZ4740: Break circular header dependency
>   MIPS: JZ4740: Export timer API
>   pwm: Add Ingenic JZ4740 support
> 
>  arch/mips/include/asm/mach-jz4740/irq.h  |   5 +
>  arch/mips/include/asm/mach-jz4740/platform.h |   1 +
>  arch/mips/include/asm/mach-jz4740/timer.h| 113 ++
>  arch/mips/jz4740/Kconfig |   3 -
>  arch/mips/jz4740/Makefile|   2 +-
>  arch/mips/jz4740/board-qi_lb60.c |   1 +
>  arch/mips/jz4740/irq.h   |  23 ---
>  arch/mips/jz4740/platform.c  |   6 +
>  arch/mips/jz4740/pwm.c   | 177 -
>  arch/mips/jz4740/time.c  |   2 +-
>  arch/mips/jz4740/timer.c |   4 +-
>  arch/mips/jz4740/timer.h | 136 -
>  drivers/pwm/Kconfig  |  12 +-
>  drivers/pwm/Makefile |   1 +
>  drivers/pwm/pwm-jz4740.c | 221 
> +++
>  15 files changed, 363 insertions(+), 344 deletions(-)
>  delete mode 100644 arch/mips/jz4740/irq.h
>  delete mode 100644 arch/mips/jz4740/pwm.c
>  delete mode 100644 arch/mips/jz4740/timer.h
>  create mode 100644 drivers/pwm/pwm-jz4740.c

Hi Ralf,

Have you had a chance to look at this? It is the last remaining PWM
driver that isn't moved to the PWM framework yet. All the others are
either in linux-next already and queued for 3.7 or have recently got
Acked-by the respective maintainers (Unicore32). Patches 2 and 3 were
already acked and tested by Lars-Peter who did the initial porting.
Patch 1 can probably be dropped since I seem to be the only one running
into that issue.

I really want to take this in for 3.7 so I can use the 3.7 cycle to
transition from the legacy API to the new API and possibly even get rid
of the legacy parts altogether. However I don't want to do this without
the Acked-by from the MIPS maintainer.

Thierry


pgpnZlxvYAd9g.pgp
Description: PGP signature

Re: Status of arm-soc for 3.7

[Olof Johansson]

Quick update:

On Thu, Sep 20, 2012 at 11:21 PM, Olof Johansson  wrote:

> What's left to deal with is:
>
> * smp_ops branch, since multiplatform depends on it to allow building
> more than one platform.

smp_ops and platform_data have both been merged into
next/multiplatform now, and I have been successful at building a
kernel that includes all current multiplatform-enabled platforms.


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

Re: [PATCH 1/1] HID: Fix missing Unifying device issue

[Jiri Kosina]

On Fri, 21 Sep 2012, Nestor Lopez Casado wrote:

> This patch fixes an issue introduced after commit 4ea5454203d991ec
> 
> After that commit, hid-core silently discards any incoming packet
> that arrives while any hid driver's probe function is being executed.
> 
> This broke the enumeration process of hid-logitech-dj, that must
> receive control packets in-band with the mouse and keyboard
> packets. Discarding mouse or keyboard data at the very begining is
> usually fine, but it is not the case for control packets.
> 
> This patch forces a re-enumeration of the paired devices when a packet
> arrives that comes from an unknown device.
> 
> Based on a patch originally written by Benjamin Tissoires.
> 
> Signed-off-by: Nestor Lopez Casado 

I am now applying it, will be pushing to Linus very soon, and am also 
marking it for stable 3.2+

Thanks to everyone involved.

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

Re: [PATCH net-next v1] net: use a per task frag allocator

[Eric Dumazet]

On Fri, 2012-09-21 at 13:27 -0700, Vijay Subramanian wrote:
> I get the following compile error with the newer version of the patch
> 
> net/sched/em_meta.c: In function ‘meta_int_sk_sendmsg_off’:
> net/sched/em_meta.c:464: error: ‘struct sock’ has no member named
> ‘sk_sndmsg_off’
> make[1]: *** [net/sched/em_meta.o] Error 1
> make: *** [net/sched/em_meta.o] Error 2
> 
> 
> 
> Vijay

Oh well, I wonder what's the expected use of this crap...

Thanks, I'll fix this on v3 !


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: OOPS/panic in iio_dummy (v3.6-rc6-176-gabef3bd)

[Lars-Peter Clausen]

On 09/22/2012 04:13 AM, Peter Hüwe wrote:
> Hi,
> 
> loading iio_dummy results in kernel panic as the call to 
> iio_buffer_register in iio_dummy_probe is performed with indio_dev->buffer == 
> NULL and thus the access to indio_dev->buffer->attrs results in this 
> oops/panic.
> 
> Thanks,
> Peter
> 

Hi,

I sent a patch or this a couple of days ago. See
http://comments.gmane.org/gmane.linux.kernel.iio/5550

- Lars


> Steps to reproduce:
> 
> #modprobe iio_dummy
> iio_dummy: module is from the staging directory, the quality is unknown, you 
> have been warned.
> 
> Modules linked in: iio_dummy(C+) industrialio
> Pid: 615, comm: modprobe Tainted: G C   3.6.0-rc6-00180-g68d0383-dirty
> RIP: 0033:[]
> RSP: 9f4ffd30  EFLAGS: 00010206
> RAX: 0004 RBX: a08be6a0 RCX: 
> RDX: 6036a320 RSI: 0008 RDI: 
> RBP: 9f4ffda0 R08: 9f4ff900 R09: 60406da8
> R10: 004a R11: 0246 R12: 602a58bc
> R13: 0005 R14: 6005f170 R15: 9f6b0400
> Call Trace: 
> 603675d8:  [<6001d53d>] segv+0x1bd/0x340
> 603675f8:  [<6008b8ab>] handle_irq_event_percpu+0xab/0x1b0
> 60367620:  [<6008b9b0>] handle_irq_event+0x0/0x40
> 60367630:  [<6002e09c>] os_waiting_for_events+0x0/0xc5
> 60367658:  [<6008fccf>] rcu_irq_exit+0x5f/0xb0
> 603676a8:  [<6001d713>] segv_handler+0x53/0xb0
> 603676c8:  [<60019b5c>] sigio_handler+0xac/0xc0
> 603676f8:  [<6002ff5a>] sig_handler_common+0xa4/0xb9
> 60367708:  [<6005f170>] __mutex_init+0x0/0x20
> 60367718:  [<602a58bc>] printk+0x0/0xa8
> 60367780:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 60367818:  [<60016c34>] _einittext+0x2572/0x38f6
> 60367828:  [<60016728>] _einittext+0x2066/0x38f6
> 60367908:  [<60016c34>] _einittext+0x2572/0x38f6
> 603679a8:  [<60019b70>] to_irq_stack+0x0/0xe0
> 60367a28:  [<60019b70>] to_irq_stack+0x0/0xe0
> 60367a38:  [<600300b5>] sig_handler+0x4a/0x5d
> 60367a58:  [<6002fb81>] hard_handler+0x89/0xd8
> 60367a90:  [<602a58bc>] printk+0x0/0xa8
> 60367aa0:  [<6005f170>] __mutex_init+0x0/0x20
> 60367b08:  [<602a58bc>] printk+0x0/0xa8
> 60367b18:  [<6005f170>] __mutex_init+0x0/0x20
> 60367b68:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 
> Kernel panic - not syncing: Kernel mode fault at addr 0x68, ip 0xa089d846
> Call Trace: 
> 603674b0:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 603674c8:  [<602a5751>] panic+0x146/0x2b1
> 60367500:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 60367508:  [<602a560b>] panic+0x0/0x2b1
> 60367520:  [<6007a4d4>] __module_text_address+0x14/0x70
> 60367538:  [<6007ec20>] is_module_text_address+0x10/0x20
> 60367548:  [<600582c7>] __kernel_text_address+0x87/0xc0
> 60367568:  [<6001bc1f>] show_trace+0x7f/0xf0
> 60367598:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 603675c0:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 603675d8:  [<6001d55b>] segv+0x1db/0x340
> 603675f8:  [<6008b8ab>] handle_irq_event_percpu+0xab/0x1b0
> 60367620:  [<6008b9b0>] handle_irq_event+0x0/0x40
> 60367630:  [<6002e09c>] os_waiting_for_events+0x0/0xc5
> 60367658:  [<6008fccf>] rcu_irq_exit+0x5f/0xb0
> 603676a8:  [<6001d713>] segv_handler+0x53/0xb0
> 603676c8:  [<60019b5c>] sigio_handler+0xac/0xc0
> 603676f8:  [<6002ff5a>] sig_handler_common+0xa4/0xb9
> 60367708:  [<6005f170>] __mutex_init+0x0/0x20
> 60367718:  [<602a58bc>] printk+0x0/0xa8
> 60367780:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 60367818:  [<60016c34>] _einittext+0x2572/0x38f6
> 60367828:  [<60016728>] _einittext+0x2066/0x38f6
> 60367908:  [<60016c34>] _einittext+0x2572/0x38f6
> 603679a8:  [<60019b70>] to_irq_stack+0x0/0xe0
> 60367a28:  [<60019b70>] to_irq_stack+0x0/0xe0
> 60367a38:  [<600300b5>] sig_handler+0x4a/0x5d
> 60367a58:  [<6002fb81>] hard_handler+0x89/0xd8
> 60367a90:  [<602a58bc>] printk+0x0/0xa8
> 60367aa0:  [<6005f170>] __mutex_init+0x0/0x20
> 60367b08:  [<602a58bc>] printk+0x0/0xa8
> 60367b18:  [<6005f170>] __mutex_init+0x0/0x20
> 60367b68:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 
> 
> Modules linked in: iio_dummy(C+) industrialio
> Pid: 615, comm: modprobe Tainted: G C   3.6.0-rc6-00180-g68d0383-dirty
> RIP: 0033:[<402eff9a>]
> RSP: 007fbfbf6798  EFLAGS: 0246
> RAX: ffda RBX:  RCX: 
> RDX: 0060e110 RSI: 000148c9 RDI: 40024000
> RBP: 00611b70 R08: 0060e100 R09: 
> R10:  R11: 0246 R12: 0060e110
> R13:  R14: 0060e010 R15: 00611b88
> Call Trace: 
> 60367448:  [<6001db1e>] panic_exit+0x3e/0x60
> 60367478:  [<600616ad>] notifier_call_chain+0x4d/0x70
> 603674a0:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 603674b8:  [<60061708>] atomic_notifier_call_chain+0x18/0x20
> 603674c8:  [<602a5784>] panic+0x179/0x2b1
> 60367500:  [] iio_buffer_register+0x46/0x610 [industrialio]
> 603675

Re: RCU idle CPU detection is broken in linux-next

[Sasha Levin]

On 09/21/2012 05:18 PM, Sasha Levin wrote:
> On 09/21/2012 05:12 PM, Paul E. McKenney wrote:
>> On Fri, Sep 21, 2012 at 03:26:27PM +0200, Sasha Levin wrote:
>>> On 09/21/2012 02:13 PM, Paul E. McKenney wrote:
> This might be unrelated, but I got the following dump as well when trinity
>> decided it's time to reboot my guest:
 OK, sounds like we should hold off until you reproduce, then.
>>>
>>> I'm not sure what you mean.
>>>
>>> There are basically two issues I'm seeing now, which reproduce pretty much 
>>> every
>>> time:
>>>
>>>  1. The "using when idle" warning.
>>>  2. The rcu related hangs during shutdown.
>>>
>>> The first one appears early on when I start fuzzing, the other one happens 
>>> when
>>> shutting down - so both of them are reproducible in the same session.
>>
>> Ah, I misunderstood the "reboot my guest" -- I thought that you were
>> doing something like repeated modprobe/rmmod cycles on rcutorture while
>> running the guest for an extended time period.  That will teach me not
>> to reply to email so soon after waking up.  ;-)
>>
>> That said, #2 is expected behavior given the RCU CPU stall warnings in
>> your Sept. 20 dmesg.  This is because rcutorture does rcu_barrier() on
>> the way out, which cannot complete if grace periods are not completing.
>> And the later soft lockup is also likely a consequence of the stall,
>> because CPU hotplug does a synchronize_sched() while holding the hotplug
>> lock, which will then cause get_online_cpus() to hang.
>>
>> Looking further down, there are hung tasks that are waiting for a
>> timeout, but this is also a consequence of the hang because they
>> are waiting for MAX_SCHEDULE_TIMEOUT -- in other words, they are
>> waiting to be killed at shutdown time.  I could suppress this by using
>> schedule_timeout_interruptible() in a loop in order to reduce the noise
>> in this case.
>>
>> The remaining traces in that email are also consequences of the stall.
>>
>> So why the stall?
>>
>> Using RCU from a CPU that RCU believes to be idle can cause arbitrary
>> bad behavior (possibly including stalls), but with very low probability.
>> The reason that things can go arbitrarily bad is that RCU is ignoring
>> the CPU, and thus not waiting for any RCU read-side critical sections.
>> This could of course result in abitrary corruption of memory.  The reason
>> for the low probability is that grace periods tend to be long and RCU
>> read-side critical sections tend to be short.
>>
>> It looks like you are running -next, which has RCU grace periods driven
>> by a kthread.  Is it possible that this kthread is not getting a chance
>> to run (in fact, the "Stall ended before state dump start" is consistent
>> with that possibility), but in that case I would expect to see a soft
>> lockup from it.  Furthermore, in that case, it would be expected to
>> start running again as soon as things started going idle during shutdown.
>>
>> Or did the system somehow manage to stay busy despite being in shutdown?
>> Or, for that matter, are you overcommitting the physical CPUs on your
>> trinity test setup?
> 
> Nope, I originally had 4 vcpus in the guest with the host running 4 physical
> cpus, but I've also tested it with just 2 vcpus and still see the warnings.

Some more info that might help, I'm also occasionally seeing:

[   42.389345] [ cut here ]
[   42.389348] WARNING: at kernel/rcutree.c:375 rcu_eqs_enter+0x5c/0xc0()
[   42.389350] Pid: 0, comm: swapper/2 Tainted: GW
3.6.0-rc6-next-20120921-sasha-2-ge9c9495-dirty #378
[   42.389351] Call Trace:
[   42.389354]  [] ? rcu_eqs_enter+0x5c/0xc0
[   42.389356]  [] warn_slowpath_common+0x86/0xb0
[   42.389359]  [] warn_slowpath_null+0x15/0x20
[   42.389361]  [] rcu_eqs_enter+0x5c/0xc0
[   42.389364]  [] rcu_idle_enter+0x43/0xa0
[   42.389366]  [] cpu_idle+0x126/0x160
[   42.389369]  [] start_secondary+0x26e/0x276
[   42.389370] ---[ end trace 04c11301284d64ee ]---
[   42.389394] [ cut here ]
[   42.389396] WARNING: at kernel/rcutree.c:350 
rcu_eqs_enter_common+0x709/0x970()
[   42.389398] Pid: 0, comm: swapper/2 Tainted: GW
3.6.0-rc6-next-20120921-sasha-2-ge9c9495-dirty #378
[   42.389399] Call Trace:
[   42.389402]  [] ? rcu_eqs_enter_common+0x709/0x970
[   42.389405]  [] warn_slowpath_common+0x86/0xb0
[   42.389407]  [] warn_slowpath_null+0x15/0x20
[   42.389410]  [] rcu_eqs_enter_common+0x709/0x970
[   42.389412]  [] rcu_eqs_enter+0xaf/0xc0
[   42.389414]  [] rcu_idle_enter+0x43/0xa0
[   42.389417]  [] cpu_idle+0x126/0x160
[   42.389420]  [] start_secondary+0x26e/0x276
[   42.389421] ---[ end trace 04c11301284d64ef ]---
[   42.389424] [ cut here ]
[   42.389426] WARNING: at kernel/rcutree.c:527 rcu_eqs_exit+0x4f/0xb0()
[   42.389427] Pid: 0, comm: swapper/2 Tainted: GW
3.6.0-rc6-next-20120921-sasha-2-ge9c9495-dirty #378
[   42.389428] Call Trace:
[   42.389431]  [] ? rcu_eqs_exit+0x4f/0xb0
[   42.389433] 

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/22/2012 01:53 AM Francois Romieu wrote the following:

> 
> You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x 

I downloaded the stable 3.2.30 and compiled.
It worked. The r8169 driver of the latest (22 Sep 2012) stable 3.2.30
source tree for the NIC in subject works.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty ldisc: Close/Reopen race prevention should check the proper flag

[Sasha Levin]

On 09/19/2012 09:25 PM, Jiri Slaby wrote:
> On 07/10/2012 06:54 AM, Shachar Shemesh wrote:
>> > From: Shachar Shemesh 
>> > 
>> > Commit acfa747b introduced the TTY_HUPPING flag to distinguish
>> > closed TTY from currently closing ones. The test in tty_set_ldisc
>> > still remained pointing at the old flag. This causes pppd to
>> > sometimes lapse into uninterruptible sleep when killed and
>> > restarted.
>> > 
>> > Signed-off-by: Shachar Shemesh 
>> > ---
>> > Tested with 3.2.20 kernel.
>> > 
>> > diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
>> > index 24b95db..a662a24 100644
>> > --- a/drivers/tty/tty_ldisc.c
>> > +++ b/drivers/tty/tty_ldisc.c
>> > @@ -658,7 +658,7 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
>> >goto enable;
>> >}
>> >  
>> > -  if (test_bit(TTY_HUPPED, &tty->flags)) {
>> > +  if (test_bit(TTY_HUPPING, &tty->flags)) {
>> >/* We were raced by the hangup method. It will have stomped
>> >   the ldisc data and closed the ldisc down */
>> >clear_bit(TTY_LDISC_CHANGING, &tty->flags);
> Yes, that makes the issue go away, but does not seem to be right too.
> There are two issues I see:
> * TTY_HUPPED has no use now. That is incorrect. Here should be a test
> for both flags, I think.
> * The change forces the set_ldisc path to always re-open the ldisc even
> if it the terminal is HUPPED.

This patch also causes hangs on newer kernels. Can it be reverted please?

[  482.860279] INFO: task init:1 blocked for more than 120 seconds.
[  482.864244] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.

[  482.867175] initD 88000d618000  3424 1  0 0x0002
[  482.869321]  88000d5b9c28 0002 88000d5b9be8 
8114ff65
[  482.870387]  88000d5b9fd8 88000d5b9fd8 88000d5b9fd8 
88000d5b9fd8
[  482.871419]  88000d618000 88000d5b 88000d5b08f0 
7fff
[  482.872143] Call Trace:
[  482.872336]  [] ? sched_clock_local+0x25/0xa0
[  482.872796]  [] schedule+0x55/0x60
[  482.873433]  [] schedule_timeout+0x45/0x360
[  482.874134]  [] ? _raw_spin_unlock_irqrestore+0x5d/0xb0
[  482.874752]  [] ? trace_hardirqs_on+0xd/0x10
[  482.875835]  [] ? _raw_spin_unlock_irqrestore+0x84/0xb0
[  482.876744]  [] ? prepare_to_wait+0x77/0x90
[  482.877485]  [] tty_ldisc_wait_idle.isra.7+0x76/0xb0
[  482.878428]  [] ? abort_exclusive_wait+0xb0/0xb0
[  482.879239]  [] tty_ldisc_hangup+0x1cb/0x320
[  482.879988]  [] ? __tty_hangup+0x122/0x430
[  482.880491]  [] __tty_hangup+0x12a/0x430
[  482.880904]  [] ? _raw_spin_unlock_irqrestore+0x84/0xb0
[  482.881406]  [] disassociate_ctty+0x6c/0x230
[  482.882141]  [] do_exit+0x3d8/0xa90
[  482.882803]  [] ? trace_hardirqs_on+0xd/0x10
[  482.883564]  [] do_group_exit+0x84/0xd0
[  482.884261]  [] sys_exit_group+0x12/0x20
[  482.884975]  [] tracesys+0xe1/0xe6
[  482.885618] 1 lock held by init/1:
[  482.886059]  #0:  (&tty->ldisc_mutex){+.+.+.}, at: []
tty_ldisc_hangup+0x122/0x320
[  482.941519] rcu-torture: rtc: 8647dc30 ver: 746 tfle: 0 rta: 746
rtaf: 0 rtf: 745 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 5116 onoff:
0/0:0/0 -1,0:-1,0 0:0 (HZ=100) barrier: 0/0:0
[  482.941519] rcu-torture: Reader Pipe:  664658 22 0 0 0 0 0 0 0 0 0
[  482.941519] rcu-torture: Reader Batch:  664669 11 0 0 0 0 0 0 0 0 0
[  482.941519] rcu-torture: Free-Block Circulation:  745 745 745 745 745 745 745
745 745 745 0
[  542.942392] rcu-torture: rtc: 8647dc30 ver: 746 tfle: 0 rta: 746
rtaf: 0 rtf: 745 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 5116 onoff:
0/0:0/0 -1,0:-1,0 0:0 (HZ=100) barrier: 0/0:0
[  542.942392] rcu-torture: Reader Pipe:  664658 22 0 0 0 0 0 0 0 0 0
[  542.942392] rcu-torture: Reader Batch:  664669 11 0 0 0 0 0 0 0 0 0
[  542.942392] rcu-torture: Free-Block Circulation:  745 745 745 745 745 745 745
745 745 745 0
[  547.040453] kworker/u:3 (4274) used greatest stack depth: 3200 bytes left
[  602.880374] INFO: task init:1 blocked for more than 120 seconds.
[  602.883834] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[  602.886219] initD 88000d618000  3424 1  0 0x0002
[  602.887347]  88000d5b9c28 0002 88000d5b9be8 
8114ff65
[  602.888383]  88000d5b9fd8 88000d5b9fd8 88000d5b9fd8 
88000d5b9fd8
[  602.889554]  88000d618000 88000d5b 88000d5b08f0 
7fff
[  602.890851] Call Trace:
[  602.891240]  [] ? sched_clock_local+0x25/0xa0
[  602.892128]  [] schedule+0x55/0x60
[  602.892902]  [] schedule_timeout+0x45/0x360
[  602.893738]  [] ? _raw_spin_unlock_irqrestore+0x5d/0xb0
[  602.894713]  [] ? trace_hardirqs_on+0xd/0x10
[  602.895656]  [] ? _raw_spin_unlock_irqrestore+0x84/0xb0
[  602.896680]  [] ? prepare_to_wait+0x77/0x90
[  602.897557]  [] tty_ldisc_wait_idle.isra.7+0x76/0xb0
[  602.898509]  [] ? abort_exclusive_wait+0xb0/0xb0
[  602.899415]  [] tty_ldisc_hangup+0x1cb/0x320

Re: [ACPI/PCI] possible recursive locking detected

[Fengguang Wu]

On Sat, Sep 22, 2012 at 12:04:51AM -0700, Yinghai Lu wrote:
> On Fri, Sep 21, 2012 at 9:53 PM, Yinghai Lu  wrote:
> > On Fri, Sep 21, 2012 at 5:35 PM, Fengguang Wu  
> > wrote:
> >> Hi Taku,
> >>
> >> The below oops is pretty reproducible, and shows up first in:
> >>
> >> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
> >> pci/taku-acpi-pci-host-bridge-v3
> >> head:   e3faec8ea9c8aa683c56fa20ff2c58a4c5857960
> >> commit: d3c663236318a43fed5d86a643e6ea2534e9220e [5/7] PCI/ACPI: Protect 
> >> acpi_pci_roots list with mutex
> >>
> >> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> >> acpi_get_pci_rootbridge_handle+0x22/0x63
> >> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> >> acpi_get_pci_rootbridge_handle+0x22/0x63
> >> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> >> acpi_pci_register_driver+0x21/0x79
> >> [8.613239]   lock(acpi_pci_root_lock);
> >> [8.613239]   lock(acpi_pci_root_lock);
> >> [8.613239]  #0:  (acpi_pci_root_lock){+.+.+.}, at: 
> >> [] acpi_pci_register_driver+0x21/0x79
> >> [8.613239]  [] ? 
> >> acpi_get_pci_rootbridge_handle+0x22/0x63
> >> [8.613239]  [] ? 
> >> acpi_get_pci_rootbridge_handle+0x22/0x63
> >> [8.613239]  [] ? 
> >> acpi_get_pci_rootbridge_handle+0x22/0x63
> >> [8.613239]  [] 
> >> acpi_get_pci_rootbridge_handle+0x22/0x63
> >>
> >> [8.610859]
> >> [8.611385] =
> >> [8.612505] [ INFO: possible recursive locking detected ]
> >> [8.613239] 3.6.0-rc1-00022-gd3c6632 #7512 Not tainted
> >> [8.613239] -
> >> [8.613239] swapper/0/1 is trying to acquire lock:
> >> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> >> acpi_get_pci_rootbridge_handle+0x22/0x63
> >> [8.613239]
> >> [8.613239] but task is already holding lock:
> >> [8.613239]  (acpi_pci_root_lock){+.+.+.}, at: [] 
> >> acpi_pci_register_driver+0x21/0x79
> >> [8.613239]
> >> [8.613239] other info that might help us debug this:
> >> [8.613239]  Possible unsafe locking scenario:
> >> [8.613239]
> >> [8.613239]CPU0
> >> [8.613239]
> >> [8.613239]   lock(acpi_pci_root_lock);
> >> [8.613239]   lock(acpi_pci_root_lock);
> >> [8.613239]
> >> [8.613239]  *** DEADLOCK ***
> >> [8.613239]
> >> [8.613239]  May be due to missing lock nesting notation
> >> [8.613239]
> >> [8.613239] 1 lock held by swapper/0/1:
> >> [8.613239]  #0:  (acpi_pci_root_lock){+.+.+.}, at: 
> >> [] acpi_pci_register_driver+0x21/0x79
> >> [8.613239]

> > Please check attached patch that should fix the problem.
> 
> updated more aggressive version. two patches.

Yes they work nicely. Thank you very much!

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] USB: PHY: Re-organize Tegra USB PHY driver

[Venu Byravarasu]

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Friday, September 21, 2012 9:45 PM
> To: ABRAHAM, KISHON VIJAY
> Cc: Venu Byravarasu; ba...@ti.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v3] USB: PHY: Re-organize Tegra USB PHY driver
> 
> On 09/21/2012 07:09 AM, ABRAHAM, KISHON VIJAY wrote:
> > Hi,
> >
> > On Fri, Sep 21, 2012 at 5:50 PM, Venu Byravarasu
>  wrote:
> >> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> >> In order to support USB PHY drivers on these SoCs, existing
> >> PHY driver is split into SoC agnostic common USB PHY driver
> >> and Tegra20-specific USB phy driver. This will facilitate
> >> easy addition and deletion of phy drivers for Tegra SoCs.
> 
> >> @@ -618,6 +618,9 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> ...
> >> pdata = pdev->dev.platform_data;
> >> if (!pdata) {
> 
> Some missing lines of context are:
> 
> dev_err(&pdev->dev, "Platform data missing\n");
> return -EINVAL;
> }
> 
> ...
> >> +   params.mode = TEGRA_USB_PHY_MODE_HOST;
> >> +   params.config = pdata->phy_config;
> >
> > I fail to understand how pdata is not NULL in dt boot. I know i've
> > already given this comment and you replied that you dint see any
> > crash. But I'd like to know where and how pdata gets populated.
> 
> In practice, the platform uses AUXDATA to provide platform data to the
> driver even when it's instantiated using device tree; see
> arch/arm/mach-tegra/board-dt-tegra20.c variables tegra_ehci*_pdata and
> tegra20_auxdata_lookup[].
> 
> In the slightly (very very slightly, hopefully) longer term, I would
> like to completely remove the AUXDATA setup from board-dt-tegra20.c;
> tegra_ehci_probe() should do something like:
> 
> pdata = pdev->dev.platform_data
> if (!pdata)
> pdata = parse_pdata_from_dt();
> /* user didn't specify any in DT either */
> if (!pdata)
> pdata = default_pdata_for_port();
> 
> ... where perhaps the use of defaults could be folded into
> parse_pdata_from_dt().
 

Thanks Stephen for the detailed explanation.

Kishon / Felipe,
Do you have any more questions in this related, before patch can be applied?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty ldisc: Close/Reopen race prevention should check the proper flag

[Jiri Slaby]

On 09/22/2012 10:35 AM, Sasha Levin wrote:
> On 09/19/2012 09:25 PM, Jiri Slaby wrote:
>> On 07/10/2012 06:54 AM, Shachar Shemesh wrote:
 From: Shachar Shemesh 

 Commit acfa747b introduced the TTY_HUPPING flag to distinguish
 closed TTY from currently closing ones. The test in tty_set_ldisc
 still remained pointing at the old flag. This causes pppd to
 sometimes lapse into uninterruptible sleep when killed and
 restarted.

 Signed-off-by: Shachar Shemesh 
 ---
 Tested with 3.2.20 kernel.

 diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
 index 24b95db..a662a24 100644
 --- a/drivers/tty/tty_ldisc.c
 +++ b/drivers/tty/tty_ldisc.c
 @@ -658,7 +658,7 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
goto enable;
}
  
 -  if (test_bit(TTY_HUPPED, &tty->flags)) {
 +  if (test_bit(TTY_HUPPING, &tty->flags)) {
/* We were raced by the hangup method. It will have stomped
   the ldisc data and closed the ldisc down */
clear_bit(TTY_LDISC_CHANGING, &tty->flags);
>> Yes, that makes the issue go away, but does not seem to be right too.
>> There are two issues I see:
>> * TTY_HUPPED has no use now. That is incorrect. Here should be a test
>> for both flags, I think.
>> * The change forces the set_ldisc path to always re-open the ldisc even
>> if it the terminal is HUPPED.
> 
> This patch also causes hangs on newer kernels. Can it be reverted please?

Just for the record, how reproducible is this? IOW can you 100% say that
the hangs are gone if you revert the patch?

Could you identify the process sitting on the tty you are trying to hang up?

> [  482.860279] INFO: task init:1 blocked for more than 120 seconds.
> [  482.864244] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this
> message.
> 
> [  482.867175] initD 88000d618000  3424 1  0 
> 0x0002
> [  482.869321]  88000d5b9c28 0002 88000d5b9be8 
> 8114ff65
> [  482.870387]  88000d5b9fd8 88000d5b9fd8 88000d5b9fd8 
> 88000d5b9fd8
> [  482.871419]  88000d618000 88000d5b 88000d5b08f0 
> 7fff
> [  482.872143] Call Trace:
> [  482.872336]  [] ? sched_clock_local+0x25/0xa0
> [  482.872796]  [] schedule+0x55/0x60
> [  482.873433]  [] schedule_timeout+0x45/0x360
> [  482.874134]  [] ? _raw_spin_unlock_irqrestore+0x5d/0xb0
> [  482.874752]  [] ? trace_hardirqs_on+0xd/0x10
> [  482.875835]  [] ? _raw_spin_unlock_irqrestore+0x84/0xb0
> [  482.876744]  [] ? prepare_to_wait+0x77/0x90
> [  482.877485]  [] tty_ldisc_wait_idle.isra.7+0x76/0xb0
> [  482.878428]  [] ? abort_exclusive_wait+0xb0/0xb0
> [  482.879239]  [] tty_ldisc_hangup+0x1cb/0x320
> [  482.879988]  [] ? __tty_hangup+0x122/0x430
> [  482.880491]  [] __tty_hangup+0x12a/0x430

BTW that also means that my proposed patch will cause the same hangup
and we should proceed to step 2 suggested in the same patch. Given
nobody noticed in the past 3 years, which is another supporting
argument. But let's first investigate what is going on.

thanks,
-- 
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/22/2012 01:53 AM Francois Romieu wrote the following:

>>> Could you perform a test with ... 3.2-something kernel and its
>>> r8169 driver ?

As I said in my previous mail, I tried the r8169 of 3.2.30 and it works.

FWIW, while compiling the 3.2.30 kernel I saw this warning:

drivers/usb/storage/realtek_cr.c: In function ‘init_realtek_cr’:
drivers/usb/storage/realtek_cr.c:477:33: warning: ‘buf[15]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[15]’ was declared here
drivers/usb/storage/realtek_cr.c:476:33: warning: ‘buf[14]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[14]’ was declared here
drivers/usb/storage/realtek_cr.c:475:50: warning: ‘buf[13]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[13]’ was declared here
drivers/usb/storage/realtek_cr.c:473:30: warning: ‘buf[12]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[12]’ was declared here
drivers/usb/storage/realtek_cr.c:472:31: warning: ‘buf[11]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[11]’ was declared here
drivers/usb/storage/realtek_cr.c:471:31: warning: ‘buf[10]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[10]’ was declared here
drivers/usb/storage/realtek_cr.c:470:30: warning: ‘buf[9]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[9]’ was declared here
drivers/usb/storage/realtek_cr.c:469:27: warning: ‘buf[8]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[8]’ was declared here
drivers/usb/storage/realtek_cr.c:469:43: warning: ‘buf[7]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[7]’ was declared here
drivers/usb/storage/realtek_cr.c:468:30: warning: ‘buf[6]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[6]’ was declared here
drivers/usb/storage/realtek_cr.c:467:30: warning: ‘buf[5]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[5]’ was declared here
drivers/usb/storage/realtek_cr.c:466:28: warning: ‘buf[4]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[4]’ was declared here
drivers/usb/storage/realtek_cr.c:465:24: warning: ‘buf[3]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[3]’ was declared here
drivers/usb/storage/realtek_cr.c:465:40: warning: ‘buf[2]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[2]’ was declared here
drivers/usb/storage/realtek_cr.c:464:24: warning: ‘buf[1]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[1]’ was declared here
drivers/usb/storage/realtek_cr.c:464:40: warning: ‘buf[0]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[0]’ was declared here

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: change return values from -EACCES to -EPERM

[Zhao Hongjiang]

From: Zhao Hongjiang 

Change return value from -EACCES to -EPERM when the permission check fails.

Signed-off-by: Zhao Hongjiang 
---

This patch is based on linux-next tree 
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

---
 block/compat_ioctl.c |2 +-
 block/ioctl.c|   12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/block/compat_ioctl.c b/block/compat_ioctl.c
index 7c668c8..a21bf98 100644
--- a/block/compat_ioctl.c
+++ b/block/compat_ioctl.c
@@ -725,7 +725,7 @@ long compat_blkdev_ioctl(struct file *file, unsigned cmd, 
unsigned long arg)
case BLKRASET: /* compatible, but no compat_ptr (!) */
case BLKFRASET:
if (!capable(CAP_SYS_ADMIN))
-   return -EACCES;
+   return -EPERM;
bdi = blk_get_backing_dev_info(bdev);
if (bdi == NULL)
return -ENOTTY;
diff --git a/block/ioctl.c b/block/ioctl.c
index a31d91d..b7d6f07 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -21,7 +21,7 @@ static int blkpg_ioctl(struct block_device *bdev, struct 
blkpg_ioctl_arg __user
int partno;

if (!capable(CAP_SYS_ADMIN))
-   return -EACCES;
+   return -EPERM;
if (copy_from_user(&a, arg, sizeof(struct blkpg_ioctl_arg)))
return -EFAULT;
if (copy_from_user(&p, a.data, sizeof(struct blkpg_partition)))
@@ -158,7 +158,7 @@ static int blkdev_reread_part(struct block_device *bdev)
if (!disk_part_scan_enabled(disk) || bdev != bdev->bd_contains)
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
-   return -EACCES;
+   return -EPERM;
if (!mutex_trylock(&bdev->bd_mutex))
return -EBUSY;
res = rescan_partitions(disk, bdev);
@@ -282,7 +282,7 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode, 
unsigned cmd,
switch(cmd) {
case BLKFLSBUF:
if (!capable(CAP_SYS_ADMIN))
-   return -EACCES;
+   return -EPERM;

ret = __blkdev_driver_ioctl(bdev, mode, cmd, arg);
if (!is_unrecognized_ioctl(ret))
@@ -297,7 +297,7 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode, 
unsigned cmd,
if (!is_unrecognized_ioctl(ret))
return ret;
if (!capable(CAP_SYS_ADMIN))
-   return -EACCES;
+   return -EPERM;
if (get_user(n, (int __user *)(arg)))
return -EFAULT;
set_device_ro(bdev, n);
@@ -381,7 +381,7 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode, 
unsigned cmd,
case BLKRASET:
case BLKFRASET:
if(!capable(CAP_SYS_ADMIN))
-   return -EACCES;
+   return -EPERM;
bdi = blk_get_backing_dev_info(bdev);
if (bdi == NULL)
return -ENOTTY;
@@ -390,7 +390,7 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode, 
unsigned cmd,
case BLKBSZSET:
/* set the logical block size */
if (!capable(CAP_SYS_ADMIN))
-   return -EACCES;
+   return -EPERM;
if (!arg)
return -EINVAL;
if (get_user(n, (int __user *) arg))
-- 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 1/2] iio: inkern: put the IIO device when it fails to allocate memory

[Jonathan Cameron]

On 09/18/2012 05:55 AM, Kim, Milo wrote:
>  The reference count of the IIO device is increased if the IIO map has
>  matched consumer name.
>  After then, it tries to allocate the iio_channel which is used by the 
> consumer.
>  If it fails to allocate memory, the reference count should be decreased.
> 
>  This patch enables restoring the reference count of the IIO device.
> 
> Signed-off-by: Milo(Woogyom) Kim 
Thanks add to togreg branch of iio.git

> ---
>  drivers/iio/inkern.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> index 13748c0..aff034b 100644
> --- a/drivers/iio/inkern.c
> +++ b/drivers/iio/inkern.c
> @@ -132,7 +132,7 @@ struct iio_channel *iio_channel_get(const char *name, 
> const char *channel_name)
>  
>   channel = kzalloc(sizeof(*channel), GFP_KERNEL);
>   if (channel == NULL)
> - return ERR_PTR(-ENOMEM);
> + goto error_no_mem;
>  
>   channel->indio_dev = c->indio_dev;
>  
> @@ -151,6 +151,9 @@ error_no_chan:
>   iio_device_put(c->indio_dev);
>   kfree(channel);
>   return ERR_PTR(-EINVAL);
> +error_no_mem:
> + iio_device_put(c->indio_dev);
> + return ERR_PTR(-ENOMEM);
>  }
>  EXPORT_SYMBOL_GPL(iio_channel_get);
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] iio: inkern: clean up error return code

[Jonathan Cameron]

On 09/18/2012 05:56 AM, Kim, Milo wrote:
>  When the IIO consumer tries to get specific IIO channel,
>  few error cases can be happened.
>  (a) Memory allocation failure
>  (b) No matched ADC channel error
>  (c) Invalid input arguments
>  This patch enables cleaning up error handling in case of (a) and (b).
> 
>  In error handling code,
>  (a): the reference count of the IIO device should be decreased.
>  (b): the allocated memory should be freed with restoring the reference count.
>  Therefore iio_deivce_put() is called in both cases.
>  This can be handled in the last error statement.
> 
>  Additionally, integer variable is used for stating each error case 
> explicitly.
>  Then, the error returns as ERR_PTR() with this value.
> 
> Signed-off-by: Milo(Woogyom) Kim 
Thanks,
added to togreg branch of iio.git
> ---
>  drivers/iio/inkern.c |   13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> index aff034b..656d4d4 100644
> --- a/drivers/iio/inkern.c
> +++ b/drivers/iio/inkern.c
> @@ -111,6 +111,7 @@ struct iio_channel *iio_channel_get(const char *name, 
> const char *channel_name)
>  {
>   struct iio_map_internal *c_i = NULL, *c = NULL;
>   struct iio_channel *channel;
> + int err;
>  
>   if (name == NULL && channel_name == NULL)
>   return ERR_PTR(-ENODEV);
> @@ -131,8 +132,10 @@ struct iio_channel *iio_channel_get(const char *name, 
> const char *channel_name)
>   return ERR_PTR(-ENODEV);
>  
>   channel = kzalloc(sizeof(*channel), GFP_KERNEL);
> - if (channel == NULL)
> + if (channel == NULL) {
> + err = -ENOMEM;
>   goto error_no_mem;
> + }
>  
>   channel->indio_dev = c->indio_dev;
>  
> @@ -141,19 +144,19 @@ struct iio_channel *iio_channel_get(const char *name, 
> const char *channel_name)
>   iio_chan_spec_from_name(channel->indio_dev,
>   c->map->adc_channel_label);
>  
> - if (channel->channel == NULL)
> + if (channel->channel == NULL) {
> + err = -EINVAL;
>   goto error_no_chan;
> + }
>   }
>  
>   return channel;
>  
>  error_no_chan:
> - iio_device_put(c->indio_dev);
>   kfree(channel);
> - return ERR_PTR(-EINVAL);
>  error_no_mem:
>   iio_device_put(c->indio_dev);
> - return ERR_PTR(-ENOMEM);
> + return ERR_PTR(err);
>  }
>  EXPORT_SYMBOL_GPL(iio_channel_get);
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Fix bug in end absolute address in drivers/mtd/devices/slram.c

[Roel Kluin]

On Thu, Sep 20, 2012 at 5:55 PM, Jiri Kosina  wrote:
> On Thu, 20 Sep 2012, Jiri Engelthaler wrote:
>
>> Hello.
>>   I found a bug in parsing end absolute address in
>> drivers/mtd/devices/slram.c. There is checking for startaddress <
>> endaddress and endaddress subtracted by startaddress before check. The
>> bug is there from commit 3afd522de8d8ec446efe957b86e4f63e3dd8ce9d Mon,
>> 19 Jan 2009 01:24:21 +
>>
>> Here is the patch
>>
>> Signed-off-by: Jiri Engelthaler 
>>
>> --- linux-3.2.28/drivers/mtd/devices/slram.c  2012-08-19 19:15:38.0 
>> +0200
>> +++ linux-3.2.28.mod/drivers/mtd/devices/slram.c  2012-09-19
>> 18:29:28.012740703 +0200
>> @@ -266,7 +266,7 @@ static int parse_cmdline(char *devname,
>>
>>   if (*(szlength) != '+') {
>>   devlength = simple_strtoul(szlength, &buffer, 0);
>> - devlength = handle_unit(devlength, buffer) - devstart;
>> + devlength = handle_unit(devlength, buffer);
>>   if (devlength < devstart)
>>   goto err_out;
>
> ... adding the suspects to CC so that they are aware of this.

Yes, that's what it should have been. FWIW,

Acked-by: Roel Kluin 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Sound got mute in kernel 3.5.4 (Fast Track Pro USB Sound Card), found commit that causes it - how to proceed?

[Andrzej Giniewicz]

On 20.09.2012 18:33, Andrzej Giniewicz wrote:
> today I updated kernel to 3.5.4 and noticed, that all my sound from Fast
> Track Pro USB Sound Card got mute. I haven't noticed any error reports
> or messages, all seems to work, the card is just silent. I downgraded to
> 3.5.3 and applied patched from usb sound module one by one and found
> out, that 3.5.4 minus " ALSA: snd-usb: fix calls to next_packet_size "
> works fine:
> 
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=ca150f7ade5973c3bce19261bca6174d5c3cc342

On Arch Linux forums we got another report, that USB Sound Card got
mute, and works again after removing that change, so there are least two
affected devices now:

ID 04d2:5051 Altec Lansing Technologies
ID 0763:2012 Midiman M-Audio Fast Track Pro



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv4] remoteproc: Add STE modem driver for remoteproc

[Ohad Ben-Cohen]

On Thu, Sep 20, 2012 at 7:32 PM,   wrote:
> From: Sjur Brændeland 
>
> Add support for the STE modem shared memory driver.
> This driver hooks into the remoteproc framework
> in order to manage configuration and the virtio
> devices.
>
> This driver adds custom firmware handlers, because
> STE modem uses a custom firmware layout.
>
> Signed-off-by: Sjur Brændeland 
> cc: Linus Walleij 
> cc: Alan Cox 
> ---
> Changes from v3:
> Added function setup to struct ste_modem_dev_ops.

Thanks, it looks good.

It might be safer though to invoke ->setup() in probe/remove, instead
of in start/stop (just like you essentially did before).

This way we don't assume that stop is always called before remove (as
assumption that might be implicitly valid today, but may break in the
future).

If you want, I can just change that before applying.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6] iio: adc: add new lp8788 adc driver

[Jonathan Cameron]

On 09/18/2012 09:18 PM, Jonathan Cameron wrote:
> On 09/18/2012 09:19 AM, Lars-Peter Clausen wrote:
>> On 09/17/2012 11:35 AM, Kim, Milo wrote:
>>>  TI LP8788 PMU provides regulators, battery charger, ADC,
>>>  RTC, backlight driver and current sinks.
>>>
>>>  This patch enables the LP8788 ADC functions.
>>>
>>>  The LP8788 ADC has several ADC input selection and supports 12bit 
>>> resolution.
>>>  Internal operation of getting ADC is access to registers of LP8788.
>>>  The LP8788 ADC uses exported functions for accessing these registers.
>>>  (exported by LP8788 MFD device driver)
>>>
>>>  This driver supports IIO_CHAN_INFO_RAW and SCALE.
>>>  So the IIO consumer can calculate the value with raw and scale.
>>>  The unit of scale is micro.
>>>
>>>  (ADC Input Selection)
>>>
>>>  Voltage: battery voltage (MAX 5.0, 5.5 and 6.0V)
>>>   charger input voltage
>>>   four general ADC inputs
>>>   coin cell voltage
>>>  Current: battery charging current
>>>  Temperature: IC temperature
>>>
>>>  (The IIO map for the IIO consumer)
>>>
>>>  The ADC input is configurable in the platform side.
>>>  Even though this platform data is not defined,
>>>  the default IIO map is created for supporting the power supply driver.
>>>  The battery voltage and temperature are used inside this driver.
>>>
>>>  (History)
>>>
>>>  Patch v6.
>>>  (a) Fix scale value for each ADC input selection
>>>  Voltage and current type are mili unit and temperature is degree.
>>>  To calculate the IC temperature,
>>>  temp = raw * scaleint + (raw * scalepart)/ 100, scaleint is always 0.
>>>   = raw * 0.061050, raw: 0 ~ 4095
>>>  Then range of IC temperature(ADC result) is 0 ~ 250'C
>>>
>>>  (b) Reorganization of the IIO channel Spec
>>>  Remove address, scan_type and scan_index and rollback the datasheet name.
>>>  The reason why 'address' field is unnecessary is no relation with each 
>>> channel.
>>>  Moreover, to get the raw ADC value, the address info is not only one 
>>> register
>>>  but also several registers.
>>>  Therefore specific function(lp8788_get_adc_result) is called rather than
>>>  using one 'address' field.
>>>
>>>  (c) Fix coding style
>>>  Remove duplicated checking routine while unregistering the IIO map.
>>>  Fix code for space and parenthesis.
>>>
>>>  Patch v5.
>>>  Fix default consumer name as 'lp8788-charger'.
>>>  Add mutex for ADC read operation.
>>>  Reorganization on lp8788_adc_read_raw().
>>>
>>>  Patch v4.
>>>  Fix adc_raw function: support RAW and SCALE channel info.
>>>  Change LP8788 ADC platform data - iio map.
>>>  Enables the default IIO map.
>>>
>>>  Patch v3.
>>>  Fix wrong size of allocating iio private data.
>>>  Fix coding styles.
>>>
>>>  Patch v2.
>>>  Support RAW and SCALE interface for IIO consumer.
>>>  Clean up the iio channel spec macro.
>>>
>>> Signed-off-by: Milo(Woogyom) Kim 
>>
>> Looks good to me,
>>
>> Reviewed-by: Lars-Peter Clausen 
> I've added this to my local tree but not pushed out just
> yet on basis you might want to change the behaviour Lars
> has pointed out...
> 
> I don't here it'll go as is in a day or so.

Added to togreg branch of iio.git
> 
> Jonathan
>>
>> One comment though, not sure if it is critical or not.
>>
>>> +static int lp8788_get_adc_result(struct lp8788_adc *adc, enum 
>>> lp8788_adc_id id,
>>> +   int *val)
>>> +{
>>> +   unsigned int msb;
>>> +   unsigned int lsb;
>>> +   unsigned int result;
>>> +   u8 data;
>>> +   u8 rawdata[2];
>>> +   int size = ARRAY_SIZE(rawdata);
>>> +   int retry = 5;
>>> +   int ret;
>>> +
>>> +   data = (id << 1) | ADC_CONV_START;
>>> +   ret = lp8788_write_byte(adc->lp, LP8788_ADC_CONF, data);
>>> +   if (ret)
>>> +   goto err_io;
>>> +
>>> +   /* retry until adc conversion is done */
>>> +   data = 0;
>>> +   while (retry--) {
>>> +   usleep_range(100, 200);
>>> +
>>> +   ret = lp8788_read_byte(adc->lp, LP8788_ADC_DONE, &data);
>>> +   if (ret)
>>> +   goto err_io;
>>> +
>>> +   /* conversion done */
>>> +   if (data)
>>> +   break;
>>
>> Could as well go into the while header like this:
>> while (!data && retry--)
>>
>>> +   }
>>> +
>>
>> You still sample the data, even if there was a timeout and ADC_DONE is not 
>> set.
>>
>>> +   ret = lp8788_read_multi_bytes(adc->lp, LP8788_ADC_RAW, rawdata, size);
>>> +   if (ret)
>>> +   goto err_io;
>>> +
>>> +   msb = (rawdata[0] << 4) & 0x0ff0;
>>> +   lsb = (rawdata[1] >> 4) & 0x000f;
>>> +   result = msb | lsb;
>>> +   *val = result;
>>> +
>>> +   return 0;
>>> +
>>> +err_io:
>>> +   return ret;
>>> +}
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m

[GIT] HID

[Jiri Kosina]

Linus,

please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git upstream-fixes

to receive HID fixes that should still go into 3.6. Thanks.


The most important fix is Logitech Unifying receiver regression in device 
enumeration fix from Nestor Lopez Casado. In addition to that, there is a 
small memory leak fix for Thinkpad keyboard driver from Axel Lin.


Axel Lin (1):
  HID: lenovo-tpkbd: Fix memory leak in tpkbd_remove_tp()

Nestor Lopez Casado (1):
  HID: Fix logitech-dj: missing Unifying device issue

 drivers/hid/hid-lenovo-tpkbd.c |2 +
 drivers/hid/hid-logitech-dj.c  |   45 
 drivers/hid/hid-logitech-dj.h  |1 +
 3 files changed, 48 insertions(+), 0 deletions(-)

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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]power: battery: Generic battery driver using IIO

[Jonathan Cameron]

On 09/21/2012 11:52 PM, Anton Vorontsov wrote:
> On Fri, Sep 21, 2012 at 09:40:14PM +0530, anish kumar wrote:
>> From: anish kumar 
>>
>> In last version:
>> Addressed concerns raised by lars:
>> a. made the adc_bat per device.
>> b. get the IIO channel using hardcoded channel names.
>> c. Minor issues related to gpio_is_valid and some code
>>refactoring.
> 
> In the commit message itself it usually good idea to write a short
> description for the patch: the rationale behind the driver. Just a few
> sentences will work.
I've hacked in a very short description whilst merging this
(I'm a bit pushed for time in the coming week and don't want to delay
this long enough for Anish to get back to me and then miss the merge window.)

'Driver to allow use of the ADC drivers supported by the IIO
subsystem for battery status monitoring. Connecting this
driver to the relevant IIO device requires registration of
the appropriate iio_map structure array by the IIO device
driver (usually from platform data).  If specified the driver
will also make use of a gpio to provide interrupt driven
notification that the battery is fully charged.'

Hope no one minds that and that I haven't missed any important elements.

I've also taken to_generic_bat and gab_prop_to_chan static to avoid some
warnings from sparse (and the inevitable follow up patch when the autobuilders
hit this ;)

Anyhow the result of these trivial changes is now in the
togreg branch of

git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git

and will go to GregKH sometime later today / tomorrow.

Note this will merge through the staging tree.  This is no
reflection on the driver or indeed anything it actually depends on.
Greg is taking IIO patches through there purely because we have so
many other drivers still in staging and it would be very fiddly to
do it otherwise for the time being!

Thanks for your hard work on this Anish,

Jonathan

> 
> And changelog usually goes below the "---" separator, as we don't want it
> in the commit log ("git am" command ignores anything below "---").
> 
>> In V1:
>> Addressed concerns raised by Anton:
>> a. changed the struct name to gab(generic adc battery).
>> b. Added some functions to neaten the code.
>> c. Some minor coding guidelines changes.
>> d. Used the latest function introduce by lars:
>>iio_read_channel_processed to streamline the code.
>>
>> In V2:
>> Addressed concerns by lars:
>> a. No need of allocating memory for channels.Make it array.
>> b. Code restructring, coding style and following kernel guidelines changes
>>suggested by him.
>>
>> In V3:
>> Addressed conerns by Anton:
>> a. Added the copyright.
>> b. Coding guidelines changes suggested by him.
>> c. Added Makefile and Kconfig
>>
>> Signed-off-by: anish kumar 
>> ---
> 
> OK, I belive it is good enough, and as it depends on IIO changes,
> I believe now it's IIO maintainer's worry to pick it up. :-)
> 
> Acked-by: Anton Vorontsov 
> 
> Thanks a lot for your work!
> 
>>  drivers/power/Kconfig |7 +
>>  drivers/power/Makefile|1 +
>>  drivers/power/generic-adc-battery.c   |  422 
>> +
>>  include/linux/power/generic-adc-battery.h |   29 ++
>>  4 files changed, 459 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/power/generic-adc-battery.c
>>  create mode 100644 include/linux/power/generic-adc-battery.h
>>
>> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
>> index fcc1bb0..30a173a 100644
>> --- a/drivers/power/Kconfig
>> +++ b/drivers/power/Kconfig
>> @@ -29,6 +29,13 @@ config APM_POWER
>>Say Y here to enable support APM status emulation using
>>battery class devices.
>>  
>> +config GENERIC_ADC_BATTERY
>> +tristate "Generic battery support using IIO"
>> +depends on IIO
>> +help
>> +  Say Y here to enable support for the generic battery driver
>> +  which uses IIO framework to read adc.
>> +
>>  config MAX8925_POWER
>>  tristate "MAX8925 battery charger support"
>>  depends on MFD_MAX8925
>> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
>> index ee58afb..e0b4d42 100644
>> --- a/drivers/power/Makefile
>> +++ b/drivers/power/Makefile
>> @@ -5,6 +5,7 @@ power_supply-$(CONFIG_SYSFS) += power_supply_sysfs.o
>>  power_supply-$(CONFIG_LEDS_TRIGGERS)+= power_supply_leds.o
>>  
>>  obj-$(CONFIG_POWER_SUPPLY)  += power_supply.o
>> +obj-$(CONFIG_GENERIC_ADC_BATTERY)   += generic-adc-battery.o
>>  
>>  obj-$(CONFIG_PDA_POWER) += pda_power.o
>>  obj-$(CONFIG_APM_POWER) += apm_power.o
>> diff --git a/drivers/power/generic-adc-battery.c 
>> b/drivers/power/generic-adc-battery.c
>> new file mode 100644
>> index 000..a34d52a
>> --- /dev/null
>> +++ b/drivers/power/generic-adc-battery.c
>> @@ -0,0 +1,422 @@
>> +/*
>> + * Generic battery driver code using IIO
>> + * Copyright (C) 2012, Anish Kumar 
>> + * based on jz4740-battery.c
>> + * based on s3c_adc_batt

[PATCH] pppoe: drop PPPOX_ZOMBIEs in pppoe_release

[Xiaodong Xu]

From: Xiaodong Xu 

When PPPOE is running over a virtual ethernet interface (e.g., a
bonding interface) and the user tries to delete the interface in case
the PPPOE state is ZOMBIE, the kernel will loop forever while
unregistering net_device for the reference count is not decreased to
zero which should have been done with dev_put().

Signed-off-by: Xiaodong Xu 

---

--- drivers/net/ppp/pppoe.c.orig2012-09-19 11:49:27.921826868 +0800
+++ drivers/net/ppp/pppoe.c 2012-09-22 17:44:03.642730082 +0800
@@ -570,7 +570,7 @@ static int pppoe_release(struct socket *

po = pppox_sk(sk);

-   if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND)) {
+   if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND | PPPOX_ZOMBIE)) {
dev_put(po->pppoe_dev);
po->pppoe_dev = NULL;
}

-- 
Regards,
Xiaodong Xu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: OOPS/panic in iio_dummy (v3.6-rc6-176-gabef3bd)

[Jonathan Cameron]

On 09/22/2012 09:10 AM, Lars-Peter Clausen wrote:
> On 09/22/2012 04:13 AM, Peter Hüwe wrote:
>> Hi,
>>
>> loading iio_dummy results in kernel panic as the call to 
>> iio_buffer_register in iio_dummy_probe is performed with indio_dev->buffer 
>> == 
>> NULL and thus the access to indio_dev->buffer->attrs results in this 
>> oops/panic.
>>
>> Thanks,
>> Peter
>>
> 
> Hi,
> 
> I sent a patch or this a couple of days ago. See
> http://comments.gmane.org/gmane.linux.kernel.iio/5550
> 
> - Lars

Sorry, I'd completely forgotten that was queued up in my fixes branch.
As it's only in the dummy driver I've changed my mind and pulled it into
the togreg branch which will merge for 3.7. It's late in the cycle and
we are afterall talking about a fix for 'fake' hardware.

> 
> 
>> Steps to reproduce:
>>
>> #modprobe iio_dummy
>> iio_dummy: module is from the staging directory, the quality is unknown, you 
>> have been warned.
>>
>> Modules linked in: iio_dummy(C+) industrialio
>> Pid: 615, comm: modprobe Tainted: G C   
>> 3.6.0-rc6-00180-g68d0383-dirty
>> RIP: 0033:[]
>> RSP: 9f4ffd30  EFLAGS: 00010206
>> RAX: 0004 RBX: a08be6a0 RCX: 
>> RDX: 6036a320 RSI: 0008 RDI: 
>> RBP: 9f4ffda0 R08: 9f4ff900 R09: 60406da8
>> R10: 004a R11: 0246 R12: 602a58bc
>> R13: 0005 R14: 6005f170 R15: 9f6b0400
>> Call Trace: 
>> 603675d8:  [<6001d53d>] segv+0x1bd/0x340
>> 603675f8:  [<6008b8ab>] handle_irq_event_percpu+0xab/0x1b0
>> 60367620:  [<6008b9b0>] handle_irq_event+0x0/0x40
>> 60367630:  [<6002e09c>] os_waiting_for_events+0x0/0xc5
>> 60367658:  [<6008fccf>] rcu_irq_exit+0x5f/0xb0
>> 603676a8:  [<6001d713>] segv_handler+0x53/0xb0
>> 603676c8:  [<60019b5c>] sigio_handler+0xac/0xc0
>> 603676f8:  [<6002ff5a>] sig_handler_common+0xa4/0xb9
>> 60367708:  [<6005f170>] __mutex_init+0x0/0x20
>> 60367718:  [<602a58bc>] printk+0x0/0xa8
>> 60367780:  [] iio_buffer_register+0x46/0x610 [industrialio]
>> 60367818:  [<60016c34>] _einittext+0x2572/0x38f6
>> 60367828:  [<60016728>] _einittext+0x2066/0x38f6
>> 60367908:  [<60016c34>] _einittext+0x2572/0x38f6
>> 603679a8:  [<60019b70>] to_irq_stack+0x0/0xe0
>> 60367a28:  [<60019b70>] to_irq_stack+0x0/0xe0
>> 60367a38:  [<600300b5>] sig_handler+0x4a/0x5d
>> 60367a58:  [<6002fb81>] hard_handler+0x89/0xd8
>> 60367a90:  [<602a58bc>] printk+0x0/0xa8
>> 60367aa0:  [<6005f170>] __mutex_init+0x0/0x20
>> 60367b08:  [<602a58bc>] printk+0x0/0xa8
>> 60367b18:  [<6005f170>] __mutex_init+0x0/0x20
>> 60367b68:  [] iio_buffer_register+0x46/0x610 [industrialio]
>>
>> Kernel panic - not syncing: Kernel mode fault at addr 0x68, ip 0xa089d846
>> Call Trace: 
>> 603674b0:  [] iio_buffer_register+0x46/0x610 [industrialio]
>> 603674c8:  [<602a5751>] panic+0x146/0x2b1
>> 60367500:  [] iio_buffer_register+0x46/0x610 [industrialio]
>> 60367508:  [<602a560b>] panic+0x0/0x2b1
>> 60367520:  [<6007a4d4>] __module_text_address+0x14/0x70
>> 60367538:  [<6007ec20>] is_module_text_address+0x10/0x20
>> 60367548:  [<600582c7>] __kernel_text_address+0x87/0xc0
>> 60367568:  [<6001bc1f>] show_trace+0x7f/0xf0
>> 60367598:  [] iio_buffer_register+0x46/0x610 [industrialio]
>> 603675c0:  [] iio_buffer_register+0x46/0x610 [industrialio]
>> 603675d8:  [<6001d55b>] segv+0x1db/0x340
>> 603675f8:  [<6008b8ab>] handle_irq_event_percpu+0xab/0x1b0
>> 60367620:  [<6008b9b0>] handle_irq_event+0x0/0x40
>> 60367630:  [<6002e09c>] os_waiting_for_events+0x0/0xc5
>> 60367658:  [<6008fccf>] rcu_irq_exit+0x5f/0xb0
>> 603676a8:  [<6001d713>] segv_handler+0x53/0xb0
>> 603676c8:  [<60019b5c>] sigio_handler+0xac/0xc0
>> 603676f8:  [<6002ff5a>] sig_handler_common+0xa4/0xb9
>> 60367708:  [<6005f170>] __mutex_init+0x0/0x20
>> 60367718:  [<602a58bc>] printk+0x0/0xa8
>> 60367780:  [] iio_buffer_register+0x46/0x610 [industrialio]
>> 60367818:  [<60016c34>] _einittext+0x2572/0x38f6
>> 60367828:  [<60016728>] _einittext+0x2066/0x38f6
>> 60367908:  [<60016c34>] _einittext+0x2572/0x38f6
>> 603679a8:  [<60019b70>] to_irq_stack+0x0/0xe0
>> 60367a28:  [<60019b70>] to_irq_stack+0x0/0xe0
>> 60367a38:  [<600300b5>] sig_handler+0x4a/0x5d
>> 60367a58:  [<6002fb81>] hard_handler+0x89/0xd8
>> 60367a90:  [<602a58bc>] printk+0x0/0xa8
>> 60367aa0:  [<6005f170>] __mutex_init+0x0/0x20
>> 60367b08:  [<602a58bc>] printk+0x0/0xa8
>> 60367b18:  [<6005f170>] __mutex_init+0x0/0x20
>> 60367b68:  [] iio_buffer_register+0x46/0x610 [industrialio]
>>
>>
>> Modules linked in: iio_dummy(C+) industrialio
>> Pid: 615, comm: modprobe Tainted: G C   
>> 3.6.0-rc6-00180-g68d0383-dirty
>> RIP: 0033:[<402eff9a>]
>> RSP: 007fbfbf6798  EFLAGS: 0246
>> RAX: ffda RBX:  RCX: 
>> RDX: 0060e110 RSI: 000148c9 RDI: 40024000
>> RBP: 00611b70 R08: 0060e100 R09: 
>> R10:  R11: 0246 R12:

Re: [PATCH 0/3] Introduce devm_clk_register()

[Russell King - ARM Linux]

On Tue, Sep 18, 2012 at 11:05:27PM -0700, Stephen Boyd wrote:
> The first patch in this series fixes error checking in the wm831x clock
> driver and is here to prevent context conflicts in the third patch.
> I split it out in case it needed to merge sooner rather than later.
> 
> The goal of this series is to add devm_clk_register() so I can use it in
> some MSM clock code I'm sending out in the near future. The second 
> patch adds the API and the third patch moves over an existing user of
> clk_unregister() to the devm API.

Can we guarantee that the clocks are unused when the module is removed?
If we can't make that guarantee, then devm_* should not be used here,
and instead there should be refcounting done in the clocks (that's what
the __clk_get() and __clk_put() hooks are there for.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pppoe: drop PPPOX_ZOMBIEs in pppoe_release

[Xiaodong Xu]

From: Xiaodong Xu 

When PPPOE is running over a virtual ethernet interface (e.g., a
bonding interface) and the user tries to delete the interface in case
the PPPOE state is ZOMBIE, the kernel will loop forever while
unregistering net_device for the reference count is not decreased to
zero which should have been done with dev_put().

Signed-off-by: Xiaodong Xu 

---

--- linux/drivers/net/ppp/pppoe.c.orig  2012-09-19 11:49:27.921826868 +0800
+++ linux/drivers/net/ppp/pppoe.c   2012-09-22 17:44:03.642730082 +0800
@@ -570,7 +570,7 @@ static int pppoe_release(struct socket *

po = pppox_sk(sk);

-   if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND)) {
+   if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND | PPPOX_ZOMBIE)) {
dev_put(po->pppoe_dev);
po->pppoe_dev = NULL;
}

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

Re: [PATCH v2 2/5] unicore32: pwm: Use module_platform_driver()

[guanxuetao]

> On Sat, Sep 22, 2012 at 10:56:30AM +0800, guanxue...@mprc.pku.edu.cn
> wrote:
>> > Some of the boilerplate code can be eliminated by using this macro.
>> The
>> > driver was previously registered with an arch_initcall(), so
>> technically
>> > this is no longer the same, but when the driver is moved to the PWM
>> > framework, deferred probing will take care of any driver probe
>> ordering
>> > issues.
>> >
>> > Signed-off-by: Thierry Reding 
>>
>> Tested-by: Qin Rui 
>> Acked-by: Guan Xuetao 
>>
>> Thanks & Regards,
>> Guan Xuetao
>
> Great! If you don't mind I'll take this through the PWM tree with your
> Acked-by.
>
> Thierry
>

It's my pleasure.

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

Re: [PATCH v2 2/5] unicore32: pwm: Use module_platform_driver()

[guanxuetao]

> On Sat, Sep 22, 2012 at 10:56:30AM +0800, guanxue...@mprc.pku.edu.cn
> wrote:
>> > Some of the boilerplate code can be eliminated by using this macro.
>> The
>> > driver was previously registered with an arch_initcall(), so
>> technically
>> > this is no longer the same, but when the driver is moved to the PWM
>> > framework, deferred probing will take care of any driver probe
>> ordering
>> > issues.
>> >
>> > Signed-off-by: Thierry Reding 
>>
>> Tested-by: Qin Rui 
>> Acked-by: Guan Xuetao 
>>
>> Thanks & Regards,
>> Guan Xuetao
>
> Great! If you don't mind I'll take this through the PWM tree with your
> Acked-by.
>
> Thierry
>

It's my pleasure.

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

sys_kcmp (was: Re: [PATCH 1/2] ARM: add finit_module syscall to ARM)

[Geert Uytterhoeven]

On Fri, Sep 21, 2012 at 6:51 PM, Russell King  wrote:
> That brings up another question though - when was kcmp added to x86, and
> why aren't we getting notifications from checksyscalls.sh that ARM hasn't
> been updated?
>
> It seems to be that the script was broken, and no one has noticed.

It seems Heiko did notice: http://www.serverphorums.com/read.php?12,559093

Now, I'm a bit puzzled by what follows: Heiko proposes a patch to
ignore sys_kcmp,
as it's x86-specific, which is acked by Cyrill. Then it suddenly
switches to Heiko
enabling it on s390 anyway?

> commit 29dc54c673ea2531d589400badb4ada5f5f60dae
> Author: H. Peter Anvin 
> Date:   Fri Nov 11 15:57:53 2011 -0800
>
> checksyscalls: Use arch/x86/syscalls/syscall_32.tbl as source
>
> Use the new arch/x86/syscalls/syscall_32.tbl file as source instead of
> arch/x86/include/asm/unistd_32.h.
>
> Cc: Michal Marek 
> Cc: Geert Uytterhoeven 
> Cc: Sam Ravnborg 
> Signed-off-by: H. Peter Anvin 
>
> is the culpret, more specifically this fragment:
>
> +   echo < +#if !defined(__NR_${name}) && !defined(__IGNORE_${name})
> +#warning syscall ${name} not implemented
> +#endif
> +EOF
>
> "echo < above just generates a blank line for each entry in x86's syscalls_32.tbl,
> resulting in the compiler doing no checking for us.
>
> That "echo <
> :1220:2: warning: #warning syscall kcmp not implemented
>
> So, actually, I want to add this kcmp syscall _now_ into -rc which I'm
> afraid will break your patch, and bump your syscall number on ARM to 379.

With a CC to stable for v3.5? ;-)

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Staging: iio: gyro: Add STMicroelectronics L3GD20 gyroscope device driver

[Jonathan Cameron]

On 09/18/2012 08:19 PM, Swapnil TIWARI wrote:
> Add STMicroelectronics L3GD20 gyroscope device driver
>
>
>
> Signed-off-by: Swapnil Tiwari  >

Hi, couple of standard bits first.

1) Make sure your code passes checkpatch.pl with no warnings
(only exception to this is over 80 character lines if you have a good
reason for doing that).  Of course this might be all down to point 2 :)

2) Check your email client settings (ideally send patches via git send-email
as that won't mess things up). I can hammer this into basic shape via dos2unix 
and
some find and replaces, but I'm not going to bother doing that a second time.
This email seemed to contain bother html and plain text which wasn't a great 
start.

If you are having real problems with email clients, then attaching the patch is
better than nothing.

Anyhow the below should be a cleanish copy of the patch you sent.

Also, don't put comments below the patch, I'll miss them.
On the note you put about this being in staging because all the other
gyro drivers were, be brave and put it straight into drivers/iio/gyro.
The others haven't moved because of any particular problems but more because
no one has gotten round to it!



Anyhow, as for the driver.

Mostly good, but a few points to address.

i2c fallback if smbus isn't available.  I don't think there are any parts
that need this anymore given the i2c core supports emulated smbus over i2c
and will fall back to it if the hardware support isn't there.  Get rid
of that and you can squish your read / write functions directly into the call
sites creately reducing the amount of code.

Drop the embrionic buffer interfaces out of here. Bring them in only when 
needed.

Should have far fewer explicit attributes given most are supported via the 
info_mask
bit of the chan_spec and relevant chunks in read_raw.

My immediate observation on this driver was that it was rather long for a simple
device with not buffer support.  The above comments should address this somewhat
and I'll take a closer look at the details in the next revision!

Thanks,

Jonathan
---
 drivers/staging/iio/gyro/Kconfig   |9 +
 drivers/staging/iio/gyro/Makefile  |3 +
 drivers/staging/iio/gyro/l3gd20.h  |  155 +
 drivers/staging/iio/gyro/l3gd20_gyr_core.c | 1030 

If everything is in one file, drop the _core suffix.

4 files changed, 1197 insertions(+)
 create mode 100644 drivers/staging/iio/gyro/l3gd20.h
 create mode 100644 drivers/staging/iio/gyro/l3gd20_gyr_core.c

diff --git a/drivers/staging/iio/gyro/Kconfig b/drivers/staging/iio/gyro/Kconfig
index ea295b2..47698cb 100644
--- a/drivers/staging/iio/gyro/Kconfig
+++ b/drivers/staging/iio/gyro/Kconfig
@@ -46,4 +46,13 @@ config ADXRS450
  This driver can also be built as a module.  If so, the module
  will be called adxrs450.

+config L3GD20_GYR_IIO
+   tristate "STM L3GD20 3 Axis Digital Gyroscope Sensor I2C driver (iio)"
IIO
+   depends on I2C
+   help
+  Say yes here to build support for the STMicrolectronics L3GD20 3 Axis
+  Digital .
+  To compile this driver as a module, choose M here: the module
+  will be called l3gd20_gyr_iio.
+
 endmenu
diff --git a/drivers/staging/iio/gyro/Makefile 
b/drivers/staging/iio/gyro/Makefile
index 9ba5ec1..c5d2879 100644
--- a/drivers/staging/iio/gyro/Makefile
+++ b/drivers/staging/iio/gyro/Makefile
@@ -20,3 +20,6 @@ obj-$(CONFIG_ADIS16251) += adis16251.o

 adxrs450-y := adxrs450_core.o
 obj-$(CONFIG_ADXRS450) += adxrs450.o
+
+l3gd20_gyr-y:= l3gd20_gyr_core.o
+obj-$(CONFIG_L3GD20_GYR_IIO) += l3gd20_gyr.o
diff --git a/drivers/staging/iio/gyro/l3gd20.h 
b/drivers/staging/iio/gyro/l3gd20.h
new file mode 100644
index 000..0092e88
--- /dev/null
+++ b/drivers/staging/iio/gyro/l3gd20.h
@@ -0,0 +1,155 @@
+/ (C) COPYRIGHT 2011 STMicroelectronics 

+*
+* File Name: l3gd20_iio.h
+* Authors : MH - C&I BU - Application Team
+* : Matteo Dameno (matteo.dam...@st.com
+* : author is willing to be considered the contact
+* : and update points for the driver.
If you can edit this at all without the lawyers moaning then...
1) drop the version number, it won't mean anything to anyone looking at this in 
the
future.

If very brave, just just the standard copyright form you see if pretty much 
every
other driver.

+* Version : V.2.0.0
+* Date : 2011/Aug/16
+* Description  : L3GD20 3 Axis Digital Gyroscope Sensor device driver iio
+* :
+
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* THE PRESENT SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES
+* OR CONDITIONS OF ANY KIN

Re: [RFC] status of execve() work - per-architecture patches solicited

[Greg Ungerer]

On 09/22/2012 04:39 AM, Al Viro wrote:

On Fri, Sep 21, 2012 at 12:26:36PM -0400, Mark Salter wrote:

Here are a set of c6x patches to work with your experimental-kernel_thread
branch.

Mark Salter (3):
   c6x: add ret_from_kernel_thread(), simplify kernel_thread()
   c6x: switch to generic kernel_execve
   c6x: switch to generic sys_execve


Applied and pushed...

FWIW, the current status:

alpha - done, tested on hardware
arm - done, tested on qemu
c6x - done by maintainer
frv - done, untested
m68k - done, tested on aranym; there's a known issue in copy_thread() in
case of coldfire-MMU, presumably to be handled in m68k tree (I can do it
in this one instead, if m68k folks would prefer it that way)


I sent the patch to the m68k-linux list. Its been acked by Geert.

 http://marc.info/?l=linux-m68k&m=134742688015639&w=2

I was going to push it through the m68knommu git tree, but I don't mind
if you would rather take it with your changes.

Regards
Greg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/5] fat: modify nfs mount option

[OGAWA Hirofumi]

Namjae Jeon  writes:

> + case Opt_nfs_full:
> + opts->nfs = FAT_NFS_FULL;
> + break;
> + case Opt_nfs_limited:
> + opts->nfs = FAT_NFS_LIMITED;
> + sb->s_flags |= MS_RDONLY;
> + break;

Check opt->nfs at end of parse_option(). Otherwise, multiple nfs options
would confuse it.

E.g.

mount -o nfs=limited_stable,nfs=full_unstable

-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/5] fat: allocate persistent inode numbers

[OGAWA Hirofumi]

Namjae Jeon  writes:

> - inode->i_ino = iunique(sb, MSDOS_ROOT_INO);
> + if (MSDOS_SB(sb)->options.nfs == FAT_NFS_LIMITED)
> + inode->i_ino = i_pos;
> + else
> + inode->i_ino = iunique(sb, MSDOS_ROOT_INO);
>   inode->i_version = 1;
>   err = fat_fill_inode(inode, de);
>   if (err) {

I think we don't need this. Because FH and ino is not necessary to have
relation.

Can we re-introduce ->encode_fh() handler, and export i_pos again?  With
this, I think we can get i_pos correctly. Otherwise, ino may not contain
all bits of i_pos.
-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/11] x86: Supervisor Mode Access Prevention

[Ingo Molnar]

* H. Peter Anvin  wrote:

> On 09/21/2012 03:08 PM, Dave Jones wrote:
> > 
> > Perhaps add a printk somewhere to show that it's actually been enabled 
> > maybe ?
> > 
> > Also, would it be feasible to add something like we have for test_nx ?
> > If this feature regresses in some way in the future, I suspect we'd like
> > to know about it sooner rather than later.
> > 
> 
> Good idea... should add this both for SMEP and SMAP.

Very much agreed - these exploit preventation hardware features 
are really useful, and it's good to inform the user that they 
are active.

Thanks,

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

Re: [PATCHv4] remoteproc: Add STE modem driver for remoteproc

[Sjur Brændeland]

Hi Ohad,

> Thanks, it looks good.
>
> It might be safer though to invoke ->setup() in probe/remove, instead
> of in start/stop (just like you essentially did before).
>
> This way we don't assume that stop is always called before remove (as
> assumption that might be implicitly valid today, but may break in the
> future).
>
> If you want, I can just change that before applying.

Sounds good, please just go ahead and change this before applying.
Thank you.

Regards,
Sjur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/5] fat (exportfs): rebuild inode if ilookup() fails

[OGAWA Hirofumi]

Namjae Jeon  writes:

> + if (inode == NULL && MSDOS_SB(sb)->options.nfs == FAT_NFS_LIMITED) {
> + struct buffer_head *bh = NULL;
> + struct msdos_dir_entry *de ;
> + loff_t i_pos = (loff_t)ino;
> + int bits = MSDOS_SB(sb)->dir_per_block_bits;
> + loff_t blocknr = i_pos >> bits;
> + bh = sb_bread(sb, blocknr);
> + if (!bh) {
> + fat_msg(sb, KERN_ERR,
> +  "unable to read block(%llu) for building NFS 
> inode",
> + (llu)blocknr);
> + return inode;
> + }
> + de = (struct msdos_dir_entry *)bh->b_data;
> + /* If a file is deleted on server and client is not updated
> +  * yet, we must not build the inode upon a lookup call.
> +  */
> + if (de[i_pos&((1< +
> + inode = NULL;
> + else
> + inode = fat_build_inode(sb, &de[i_pos&((1< + i_pos);
> + brelse(bh);
> + }
>  
>   return inode;
>  }

1 << bits == sbi->dir_per_block

It would be better to add helper to decode i_pos to blocknr and offset.
And it should be shared on fat_write_inode and this.
-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

3.4.5 regression kernel oops in mount attempt without lockd present

[Jason Wessel]

Greg,

In 3.4.5, a regression was introduced from commit: ee92389156 "SUNRPC:
move per-net operations from svc_destroy()".

This regression was actually fixed in a later upstream patch in
v3.5-rc1, specifically 4db77695bf5 "LockD: pass service to per-net up
and down functions", which means there is no stock kernel.org kernel
that exhibits this particular crash.

Please add 4db77695bf5 to the 3.4.Y, it should cherry-pick cleanly.

Below is the stack trace you can get from lockd initiation crashing if
you try to mount a file system with locks when lockd is not running.

BUG: unable to handle kernel NULL pointer dereference at 011c
IP: [] lockd_down_net+0x41/0xb0
*pde = 
Oops:  [#1] PREEMPT SMP
Modules linked in:

Pid: 42, comm: mount Not tainted 3.4.10-WR5.0+snapshot-20120814_standard #26 
Bochs Bochs
EIP: 0060:[] EFLAGS: 00010282 CPU: 0
EIP is at lockd_down_net+0x41/0xb0
EAX:  EBX: 0003 ECX:  EDX: 
ESI: c1a23540 EDI: d7949708 EBP: d7033da0 ESP: d7033d88
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: 011c CR3: 1701a000 CR4: 06d0
DR0:  DR1:  DR2:  DR3: 
DR6: 0ff0 DR7: 0400
Process mount (pid: 42, ti=d7032000 task=d7a2e200 task.ti=d7032000)
Stack:
 c1208993 c181af78 ff91 ff91 d7af9980 c1a23540 d7033dcc c1208ba7
 d79d5500 d7033db8 c11dec06  d7033dd0 d7949708 d7033df8 0004
 0003 d7033df0 c120591c c11de15e 0001  d79d54e0 d700ac00
Call Trace:
 [] ? make_socks+0x93/0xa0
 [] lockd_up+0x207/0x280
 [] ? nfs_mark_client_ready+0x26/0x30
 [] nlmclnt_init+0x2c/0x80
 [] ? nfs_get_client+0x4ee/0x580
 [] nfs_start_lockd+0x9c/0xd0
 [] nfs_create_server+0x1bd/0x3e0
 [] nfs_fs_mount+0x91/0x3e0
 [] ? ida_get_new_above+0x1ad/0x230
 [] mount_fs+0x36/0x180
 [] ? __alloc_percpu+0xf/0x20
 [] vfs_kern_mount+0x51/0xc0
 [] do_kern_mount+0x3e/0xe0
 [] do_mount+0x169/0x710
 [] sys_mount+0x6b/0xa0
 [] syscall_call+0x7/0xb
Code: c0 8b a1 c1 89 c6 e8 6f 8f e8 ff 85 db 8b 86 80 03 00 00 74 5a 3b 18 77 
56 8b 7c 98 08 e8 48 a6 e8 ff 85 ff 74 66 a1 cc 8b a1 c1 <8b> 98 1c 01 00 00 8b 
07 85 c0 74 3a 83 e8 01 85 c0 89 07 74 12
EIP: [] lockd_down_net+0x41/0xb0 SS:ESP 0068:d7033d88
CR2: 011c
---[ end trace 4812fcaee13b225d ]---


Thanks,
Jason.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sys_kcmp (was: Re: [PATCH 1/2] ARM: add finit_module syscall to ARM)

[Cyrill Gorcunov]

On Sat, Sep 22, 2012 at 12:56:42PM +0200, Geert Uytterhoeven wrote:
> On Fri, Sep 21, 2012 at 6:51 PM, Russell King  wrote:
> > That brings up another question though - when was kcmp added to x86, and
> > why aren't we getting notifications from checksyscalls.sh that ARM hasn't
> > been updated?
> >
> > It seems to be that the script was broken, and no one has noticed.
> 
> It seems Heiko did notice: http://www.serverphorums.com/read.php?12,559093
> 
> Now, I'm a bit puzzled by what follows: Heiko proposes a patch to
> ignore sys_kcmp,
> as it's x86-specific, which is acked by Cyrill. Then it suddenly

hpa@ pointed that better approach is to implement kcmp on other archs
after i've acked the patch. so then Heiko provided a patch for s390.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] fat (exportfs): rebuild directory-inode if fat_dget() fails

[OGAWA Hirofumi]

Namjae Jeon  writes:

> From: Namjae Jeon 
>
> This patch enables rebuilding of directory inodes which are not present
> in the cache.This is done by traversing the disk clusters to find the
> directory entry of the parent directory and using its i_pos to build the
> inode.

Hmm... Is this functionality is necessary to work correctly? If we
didn't provide this, which case do server return ESTALE?

Well, this looks like duplication of lookup, we may need to consolidate.

> Signed-off-by: Namjae Jeon 
> Signed-off-by: Ravishankar N 
> Signed-off-by: Amit Sahrawat 
> ---
>  fs/fat/nfs.c |  132 
> --
>  1 file changed, 128 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c
> index 3cf5412..bb4262c 100644
> --- a/fs/fat/nfs.c
> +++ b/fs/fat/nfs.c
> @@ -104,6 +104,93 @@ struct dentry *fat_fh_to_parent(struct super_block *sb, 
> struct fid *fid,
>  }
>  
>  /*
> + * Read the directory entries of 'search_clus' and find the entry
> + * which contains 'match_ipos' for the starting cluster.If the entry
> + * is found, rebuild its inode.
> + */
> +static struct inode *fat_traverse_cluster(struct super_block *sb,
> + int search_clus, int match_ipos)
> +{
> + struct msdos_sb_info *sbi = MSDOS_SB(sb);
> + struct buffer_head *bh;
> + sector_t blknr;
> + int parent_ipos, search_ipos;
> + int i;
> + struct msdos_dir_entry *de;
> + struct inode *inode = NULL;
> + int iterations = sbi->cluster_size >> sb->s_blocksize_bits;
> + blknr = fat_clus_to_blknr(sbi, search_clus);
> +
> + do {
> + bh = sb_bread(sb, blknr);
> + if (!bh) {
> + fat_msg(sb, KERN_ERR,
> +  "NFS:unable to read block(%llu) while 
> traversing cluster(%d)",
> + (llu)blknr, search_clus);
> + inode = ERR_PTR(-EIO);
> + goto out;
> + }
> + de = (struct msdos_dir_entry *)bh->b_data;
> + for (i = 0; i < sbi->dir_per_block; i++) {
> + if (de[i].name[0] == FAT_ENT_FREE) {
> + /*Reached end of directory*/
> + brelse(bh);
> + inode = ERR_PTR(-ENODATA);
> + goto out;
> + }
> + if (de[i].name[0] == DELETED_FLAG)
> + continue;
> + if (de[i].attr == ATTR_EXT)
> + continue;
> + if (!(de[i].attr & ATTR_DIR))
> + continue;
> + else {
> + search_ipos = fat_get_start(sbi, &de[i]);
> + if (search_ipos == match_ipos) {
> + /*Success.Now build the inode*/
> + parent_ipos = (loff_t)i +
> +  (blknr << sbi->dir_per_block_bits);
> + inode = fat_build_inode(sb, &de[i],
> + parent_ipos);
> + brelse(bh);
> + goto out;
> + }
> + }
> + }
> + brelse(bh);
> + blknr += 1;
> + } while (--iterations > 0);
> +out:
> + return inode;
> +}
> +
> +/*
> + * Read the FAT to find the next cluster in the chain
> + * corresponding to 'search_clus'.
> + */
> +static int fat_read_next_clus(struct super_block *sb, int search_clus)
> +{
> + struct msdos_sb_info *sbi = MSDOS_SB(sb);
> + /*bits 31 to 7 give relative sector number*/
> + sector_t blknr = search_clus >> 7;
> + /*bits 6 to 0 give offset*/
> + unsigned int offset = search_clus & 0x7F;
> + __le32 *address;
> + unsigned int next_cluster;
> + struct buffer_head *bh = sb_bread(sb, blknr + sbi->fat_start);
> + if (!bh) {
> + fat_msg(sb, KERN_ERR,
> + "NFS:unable to read block(%llu) for finding the next 
> cluster in FAT chain",
> + (llu)blknr);
> + return -EIO;
> + }
> + address = (__le32 *) bh->b_data;
> + next_cluster = (le32_to_cpu(address[offset])) & 0x0FFF;
> + brelse(bh);
> + return next_cluster;
> +}
> +
> +/*
>   * Find the parent for a directory that is not currently connected to
>   * the filesystem root.
>   *
> @@ -112,15 +199,52 @@ struct dentry *fat_fh_to_parent(struct super_block *sb, 
> struct fid *fid,
>  struct dentry *fat_get_parent(struct dentry *child_dir)
>  {
>   struct super_block *sb = child_dir->d_sb;
> - struct buffer_head *bh = NULL;
> + struct buffer_head *dotdot_bh = NULL, *parent_bh = NULL;
>   struct msdos_dir_entry *de;
>   struct inode

Re: [PATCH] [V3]power: battery: Generic battery driver using IIO

[anish kumar]

On Sat, 2012-09-22 at 10:50 +0100, Jonathan Cameron wrote:
> On 09/21/2012 11:52 PM, Anton Vorontsov wrote:
> > On Fri, Sep 21, 2012 at 09:40:14PM +0530, anish kumar wrote:
> >> From: anish kumar 
> >>
> >> In last version:
> >> Addressed concerns raised by lars:
> >> a. made the adc_bat per device.
> >> b. get the IIO channel using hardcoded channel names.
> >> c. Minor issues related to gpio_is_valid and some code
> >>refactoring.
> > 
> > In the commit message itself it usually good idea to write a short
> > description for the patch: the rationale behind the driver. Just a few
> > sentences will work.
> I've hacked in a very short description whilst merging this
> (I'm a bit pushed for time in the coming week and don't want to delay
> this long enough for Anish to get back to me and then miss the merge window.)
> 
> 'Driver to allow use of the ADC drivers supported by the IIO
> subsystem for battery status monitoring. Connecting this
> driver to the relevant IIO device requires registration of
> the appropriate iio_map structure array by the IIO device
> driver (usually from platform data).  If specified the driver
> will also make use of a gpio to provide interrupt driven
> notification that the battery is fully charged.'
> 
> Hope no one minds that and that I haven't missed any important elements.
> 
> I've also taken to_generic_bat and gab_prop_to_chan static to avoid some
> warnings from sparse (and the inevitable follow up patch when the autobuilders
> hit this ;)
> 
> Anyhow the result of these trivial changes is now in the
> togreg branch of
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
> 
> and will go to GregKH sometime later today / tomorrow.
> 
> Note this will merge through the staging tree.  This is no
> reflection on the driver or indeed anything it actually depends on.
> Greg is taking IIO patches through there purely because we have so
> many other drivers still in staging and it would be very fiddly to
> do it otherwise for the time being!
> 
> Thanks for your hard work on this Anish,
Thanks to Lars for coming up with this idea, Anton for reviewing
and last but not the least yourself to comeup with IIO framework 
itself.
> 
> Jonathan
> 
> > 
> > And changelog usually goes below the "---" separator, as we don't want it
> > in the commit log ("git am" command ignores anything below "---").
> > 
> >> In V1:
> >> Addressed concerns raised by Anton:
> >> a. changed the struct name to gab(generic adc battery).
> >> b. Added some functions to neaten the code.
> >> c. Some minor coding guidelines changes.
> >> d. Used the latest function introduce by lars:
> >>iio_read_channel_processed to streamline the code.
> >>
> >> In V2:
> >> Addressed concerns by lars:
> >> a. No need of allocating memory for channels.Make it array.
> >> b. Code restructring, coding style and following kernel guidelines changes
> >>suggested by him.
> >>
> >> In V3:
> >> Addressed conerns by Anton:
> >> a. Added the copyright.
> >> b. Coding guidelines changes suggested by him.
> >> c. Added Makefile and Kconfig
> >>
> >> Signed-off-by: anish kumar 
> >> ---
> > 
> > OK, I belive it is good enough, and as it depends on IIO changes,
> > I believe now it's IIO maintainer's worry to pick it up. :-)
> > 
> > Acked-by: Anton Vorontsov 
> > 
> > Thanks a lot for your work!
> > 
> >>  drivers/power/Kconfig |7 +
> >>  drivers/power/Makefile|1 +
> >>  drivers/power/generic-adc-battery.c   |  422 
> >> +
> >>  include/linux/power/generic-adc-battery.h |   29 ++
> >>  4 files changed, 459 insertions(+), 0 deletions(-)
> >>  create mode 100644 drivers/power/generic-adc-battery.c
> >>  create mode 100644 include/linux/power/generic-adc-battery.h
> >>
> >> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> >> index fcc1bb0..30a173a 100644
> >> --- a/drivers/power/Kconfig
> >> +++ b/drivers/power/Kconfig
> >> @@ -29,6 +29,13 @@ config APM_POWER
> >>  Say Y here to enable support APM status emulation using
> >>  battery class devices.
> >>  
> >> +config GENERIC_ADC_BATTERY
> >> +  tristate "Generic battery support using IIO"
> >> +  depends on IIO
> >> +  help
> >> +Say Y here to enable support for the generic battery driver
> >> +which uses IIO framework to read adc.
> >> +
> >>  config MAX8925_POWER
> >>tristate "MAX8925 battery charger support"
> >>depends on MFD_MAX8925
> >> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> >> index ee58afb..e0b4d42 100644
> >> --- a/drivers/power/Makefile
> >> +++ b/drivers/power/Makefile
> >> @@ -5,6 +5,7 @@ power_supply-$(CONFIG_SYSFS)   += 
> >> power_supply_sysfs.o
> >>  power_supply-$(CONFIG_LEDS_TRIGGERS)  += power_supply_leds.o
> >>  
> >>  obj-$(CONFIG_POWER_SUPPLY)+= power_supply.o
> >> +obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
> >>  
> >>  obj-$(CONFIG_PDA_POWER)   += pda_power.o
>

Re: sys_kcmp (was: Re: [PATCH 1/2] ARM: add finit_module syscall to ARM)

[Russell King]

On Sat, Sep 22, 2012 at 03:45:49PM +0400, Cyrill Gorcunov wrote:
> On Sat, Sep 22, 2012 at 12:56:42PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Sep 21, 2012 at 6:51 PM, Russell King  wrote:
> > > That brings up another question though - when was kcmp added to x86, and
> > > why aren't we getting notifications from checksyscalls.sh that ARM hasn't
> > > been updated?
> > >
> > > It seems to be that the script was broken, and no one has noticed.
> > 
> > It seems Heiko did notice: http://www.serverphorums.com/read.php?12,559093
> > 
> > Now, I'm a bit puzzled by what follows: Heiko proposes a patch to
> > ignore sys_kcmp,
> > as it's x86-specific, which is acked by Cyrill. Then it suddenly
> 
> hpa@ pointed that better approach is to implement kcmp on other archs
> after i've acked the patch. so then Heiko provided a patch for s390.

I discussed with hpa yesterday, and it seems the situation is as follows:

1. There exists a patch to fix checksyscalls.sh, and it's allegedly sitting
   in akpm's tree, and no one knows why it's just sitting there and hasn't
   been merged upstream.

2. There allegedly exists a patch to remove x86isms from sys_kcmp -
   allegedly also in akpm's tree.  However, I've looked through the code in
   mainline, and nothing stands out.  Ralf Beachle also said yesterday that
   he has looked through from the MIPS PoV and also can't see any x86isms,
   so we're both thinking that it should merely have the x86 dependency
   removed.

3. Until the x86 dependency is gone (that depends on what akpm proposes to
   do with the patches he's allegedly sitting on), non-x86 arches can only
   reserve the syscall, and add an IGNORE for it.

Maybe akpm can provide some input to this thread, and let us know what the
intentions are for checksyscalls.sh and kernel/kcmp.c, and whether he does
indeed have outstanding patches for these.

It would be good to at least get checksyscalls.sh fixed so arch maintainers
get their warnings for new syscalls back.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH] Xen-SWIOTLB fixes (v4) for v3.7

[Konrad Rzeszutek Wilk]

>
> to allow it to use an io_tlb passed in. Note: I hadn't tested this
> on IA64 and that is something I need to do.

Done. I got my hands on a HP zx6000 and the patch series did not show
any regressions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4] remoteproc: Add STE modem driver for remoteproc

[Ohad Ben-Cohen]

Hi Sjur,

On Sat, Sep 22, 2012 at 2:38 PM, Sjur Brændeland  wrote:
>> It might be safer though to invoke ->setup() in probe/remove, instead
>> of in start/stop (just like you essentially did before).
>>
>> This way we don't assume that stop is always called before remove (as
>> assumption that might be implicitly valid today, but may break in the
>> future).
>>
>> If you want, I can just change that before applying.
>
> Sounds good, please just go ahead and change this before applying.
> Thank you.

I'm going to squash the below into the patch - please ack before I
apply and push - thanks!

diff --git a/drivers/remoteproc/ste_modem_rproc.c
b/drivers/remoteproc/ste_modem_rproc.c
index fcc8677..a7743c0 100644
--- a/drivers/remoteproc/ste_modem_rproc.c
+++ b/drivers/remoteproc/ste_modem_rproc.c
@@ -190,9 +190,6 @@ static int sproc_start(struct rproc *rproc)

sproc_dbg(sproc, "start ste-modem\n");

-   /* Provide callback functions to modem device */
-   sproc->mdev->ops.setup(sproc->mdev, &sproc_dev_cb);
-
/* Sanity test the max_notifyid */
if (rproc->max_notifyid > SPROC_MAX_NOTIFY_ID) {
sproc_err(sproc, "Notification IDs too high:%d\n",
@@ -220,9 +217,6 @@ static int sproc_stop(struct rproc *rproc)
struct sproc *sproc = rproc->priv;
sproc_dbg(sproc, "stop ste-modem\n");

-   /* Reset device callback functions */
-   sproc->mdev->ops.setup(sproc->mdev, NULL);
-
return sproc->mdev->ops.power(sproc->mdev, false);
 }

@@ -241,6 +235,9 @@ static int sproc_drv_remove(struct platform_device *pdev)

sproc_dbg(sproc, "remove ste-modem\n");

+   /* Reset device callback functions */
+   sproc->mdev->ops.setup(sproc->mdev, NULL);
+
/* Unregister as remoteproc device */
rproc_del(sproc->rproc);
rproc_put(sproc->rproc);
@@ -260,6 +257,13 @@ static int sproc_probe(struct platform_device *pdev)
int err;

dev_dbg(&mdev->pdev.dev, "probe ste-modem\n");
+
+   if (!mdev->ops.setup || !mdev->ops.kick || !mdev->ops.kick_subscribe ||
+   !mdev->ops.power) {
+   dev_err(&mdev->pdev.dev, "invalid mdev ops\n");
+   return -EINVAL;
+   }
+
rproc = rproc_alloc(&mdev->pdev.dev, mdev->pdev.name, &sproc_ops,
SPROC_MODEM_FIRMWARE, sizeof(*sproc));
if (!rproc)
@@ -270,6 +274,9 @@ static int sproc_probe(struct platform_device *pdev)
sproc->rproc = rproc;
mdev->drv_data = sproc;

+   /* Provide callback functions to modem device */
+   sproc->mdev->ops.setup(sproc->mdev, &sproc_dev_cb);
+
/* Set the STE-modem specific firmware handler */
rproc->fw_ops = &sproc_fw_ops;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: add support for zsmalloc and zcache

[Sasha Levin]

On 09/21/2012 09:14 PM, Dan Magenheimer wrote:
>>> +#define MAX_CLIENTS 16
>> > 
>> > Seems a bit arbitrary. Why 16?
> Sasha Levin posted a patch to fix this but it was tied in to
> the proposed KVM implementation, so was never merged.
> 

My patch changed the max pools per client, not the maximum amount of clients.
That patch has already found it's way in.

(MAX_CLIENTS does look like an arbitrary number though).


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4] remoteproc: Add STE modem driver for remoteproc

[Sjur Brændeland]

Hi Ohad,

>>> It might be safer though to invoke ->setup() in probe/remove, instead
>>> of in start/stop (just like you essentially did before).
>>>
>>> This way we don't assume that stop is always called before remove (as
>>> assumption that might be implicitly valid today, but may break in the
>>> future).
>>>
>>> If you want, I can just change that before applying.
>>
>> Sounds good, please just go ahead and change this before applying.
>> Thank you.
>
> I'm going to squash the below into the patch - please ack before I
> apply and push - thanks!

Looks good, thanks.

Acked-by: Sjur Brændeland 

>
> diff --git a/drivers/remoteproc/ste_modem_rproc.c
> b/drivers/remoteproc/ste_modem_rproc.c
> index fcc8677..a7743c0 100644
> --- a/drivers/remoteproc/ste_modem_rproc.c
> +++ b/drivers/remoteproc/ste_modem_rproc.c
> @@ -190,9 +190,6 @@ static int sproc_start(struct rproc *rproc)
>
> sproc_dbg(sproc, "start ste-modem\n");
>
> -   /* Provide callback functions to modem device */
> -   sproc->mdev->ops.setup(sproc->mdev, &sproc_dev_cb);
> -
> /* Sanity test the max_notifyid */
> if (rproc->max_notifyid > SPROC_MAX_NOTIFY_ID) {
> sproc_err(sproc, "Notification IDs too high:%d\n",
> @@ -220,9 +217,6 @@ static int sproc_stop(struct rproc *rproc)
> struct sproc *sproc = rproc->priv;
> sproc_dbg(sproc, "stop ste-modem\n");
>
> -   /* Reset device callback functions */
> -   sproc->mdev->ops.setup(sproc->mdev, NULL);
> -
> return sproc->mdev->ops.power(sproc->mdev, false);
>  }
>
> @@ -241,6 +235,9 @@ static int sproc_drv_remove(struct platform_device *pdev)
>
> sproc_dbg(sproc, "remove ste-modem\n");
>
> +   /* Reset device callback functions */
> +   sproc->mdev->ops.setup(sproc->mdev, NULL);
> +
> /* Unregister as remoteproc device */
> rproc_del(sproc->rproc);
> rproc_put(sproc->rproc);
> @@ -260,6 +257,13 @@ static int sproc_probe(struct platform_device *pdev)
> int err;
>
> dev_dbg(&mdev->pdev.dev, "probe ste-modem\n");
> +
> +   if (!mdev->ops.setup || !mdev->ops.kick || !mdev->ops.kick_subscribe 
> ||
> +   !mdev->ops.power) {
> +   dev_err(&mdev->pdev.dev, "invalid mdev ops\n");
> +   return -EINVAL;
> +   }
> +
> rproc = rproc_alloc(&mdev->pdev.dev, mdev->pdev.name, &sproc_ops,
> SPROC_MODEM_FIRMWARE, sizeof(*sproc));
> if (!rproc)
> @@ -270,6 +274,9 @@ static int sproc_probe(struct platform_device *pdev)
> sproc->rproc = rproc;
> mdev->drv_data = sproc;
>
> +   /* Provide callback functions to modem device */
> +   sproc->mdev->ops.setup(sproc->mdev, &sproc_dev_cb);
> +
> /* Set the STE-modem specific firmware handler */
> rproc->fw_ops = &sproc_fw_ops;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7][RFC] netfilter: add xt_qtaguid matching module

[Eric W. Biederman]

I just took a quick skim through the patch, and spotted a few things.

This patch is going to need to handle current_fsuid returning a kuid_t.

The permission checks are weird, and ancient looking.

There is no network namespace handling, to the point I don't think
the code will function properly if network namespace support is enabled
in the kernel.

The code probably wants to use struct pid *pid, instead of pid_t values.
Both to cope with the pid namespace and to avoid issues with pid wrap
around.

A few more comments below.

Eric



John Stultz  writes:

> From: JP Abgrall 
>
> This module allows tracking stats at the socket level for given UIDs.
> It replaces xt_owner.
> If the --uid-owner is not specified, it will just count stats based on
> who the skb belongs to. This will even happen on incoming skbs as it
> looks into the skb via xt_socket magic to see who owns it.
> If an skb is lost, it will be assigned to uid=0.
>
> To control what sockets of what UIDs are tagged by what, one uses:
>   echo t $sock_fd $accounting_tag $the_billed_uid \
>  > /proc/net/xt_qtaguid/ctrl
>  So whenever an skb belongs to a sock_fd, it will be accounted against
>$the_billed_uid
>   and matching stats will show up under the uid with the given
>$accounting_tag.
>
> Because the number of allocations for the stats structs is not that big:
>   ~500 apps * 32 per app
> we'll just do it atomic. This avoids walking lists many times, and
> the fancy worker thread handling. Slabs will grow when needed later.
>
> It use netdevice and inetaddr notifications instead of hooks in the core dev
> code to track when a device comes and goes. This removes the need for
> exposed iface_stat.h.
>
> Put procfs dirs in /proc/net/xt_qtaguid/
>   ctrl
>   stats
>   iface_stat//...
> The uid stats are obtainable in ./stats.
>
> Cc: net...@vger.kernel.org
> Cc: JP Abgrall 
> Cc: Ashish Sharma 
> Cc: Peter P Waskiewicz Jr 
> Signed-off-by: JP Abgrall 
> [Dropped paranoid network ifdefs and minor compile fixups -jstultz]
> Signed-off-by: John Stultz 
> ---


> +static struct qtaguid_event_counts qtu_events;
> +/*--*/
> +static bool can_manipulate_uids(void)
> +{

You probably want something like a test for capable(CAP_SETUID).
Certainly raw check for the uid == 0 fell out of common practice
for this sort of thing a decade or so ago.
> + /* root pwnd */
> + return unlikely(!current_fsuid()) || unlikely(!proc_ctrl_write_gid)
> + || in_egroup_p(proc_ctrl_write_gid);
> +}
> +
> +static bool can_impersonate_uid(uid_t uid)
> +{
> + return uid == current_fsuid() || can_manipulate_uids();
> +}
> +
> +static bool can_read_other_uid_stats(uid_t uid)
> +{
Perhaps may_ptrace?
> + /* root pwnd */
> + return unlikely(!current_fsuid()) || uid == current_fsuid()
> + || unlikely(!proc_stats_readall_gid)
> + || in_egroup_p(proc_stats_readall_gid);
> +}
> +


> +/*
> + * Track tag that this socket is transferring data for, and not necessarily
> + * the uid that owns the socket.
> + * This is the tag against which tag_stat.counters will be billed.
> + * These structs need to be looked up by sock and pid.
> + */
> +struct sock_tag {
> + struct rb_node sock_node;
> + struct sock *sk;  /* Only used as a number, never dereferenced */
> + /* The socket is needed for sockfd_put() */
> + struct socket *socket;
> + /* Used to associate with a given pid */
> + struct list_head list;   /* in proc_qtu_data.sock_tag_list */
> + pid_t pid;
You probably want this to be "struct pid *pid;"
> +
> + tag_t tag;
> +};


> + * The qtu uid data is used to track resources that are created directly or
> + * indirectly by processes (uid tracked).
> + * It is shared by the processes with the same uid.
> + * Some of the resource will be counted to prevent further rogue allocations,
> + * some will need freeing once the owner process (uid) exits.
> + */
> +struct uid_tag_data {
> + struct rb_node node;
> + uid_t uid;

You probably want to say kuid_t uid here.

> + /*
> +  * For the uid, how many accounting tags have been set.
> +  */
> + int num_active_tags;
> + /* Track the number of proc_qtu_data that reference it */
> + int num_pqd;
> + struct rb_root tag_ref_tree;
> + /* No tag_node_tree_lock; use uid_tag_data_tree_lock */
> +};


> +struct proc_qtu_data {
> + struct rb_node node;
> + pid_t pid;

I suspect you want to use "struct pid *pid" here.
> +
> + struct uid_tag_data *parent_tag_data;
> +
> + /* Tracks the sock_tags that need freeing upon this proc's death */
> + struct list_head sock_tag_list;
> + /* No spinlock_t sock_tag_list_lock; use the global one. */
> +};
> +

> diff --git a/net/netfilter/xt_qtaguid.c b/net/netfilter/xt_qtaguid.c
> new file mode 100644
> index 000..7c4ac46
> +/*--*/
> +static int __init qtaguid_proc_register(struc

Re: [RFC] mm: add support for zsmalloc and zcache

[Sasha Levin]

On 09/22/2012 03:31 PM, Sasha Levin wrote:
> On 09/21/2012 09:14 PM, Dan Magenheimer wrote:
 +#define MAX_CLIENTS 16

 Seems a bit arbitrary. Why 16?
>> Sasha Levin posted a patch to fix this but it was tied in to
>> the proposed KVM implementation, so was never merged.
>>
> 
> My patch changed the max pools per client, not the maximum amount of clients.
> That patch has already found it's way in.
> 
> (MAX_CLIENTS does look like an arbitrary number though).

btw, while we're on the subject of KVM, the implementation of tmem/kvm was
blocked due to insufficient performance caused by the lack of multi-page
ops/batching.

Are there any plans to make it better in the future?


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sys_kcmp (was: Re: [PATCH 1/2] ARM: add finit_module syscall to ARM)

[Ralf Baechle]

On Sat, Sep 22, 2012 at 02:20:46PM +0100, Russell King wrote:

> 2. There allegedly exists a patch to remove x86isms from sys_kcmp -
>allegedly also in akpm's tree.  However, I've looked through the code in
>mainline, and nothing stands out.  Ralf Beachle also said yesterday that
>he has looked through from the MIPS PoV and also can't see any x86isms,
>so we're both thinking that it should merely have the x86 dependency
>removed.
> 
> 3. Until the x86 dependency is gone (that depends on what akpm proposes to
>do with the patches he's allegedly sitting on), non-x86 arches can only
>reserve the syscall, and add an IGNORE for it.

There is a weak definition provided in kernel/sys_ni.c so it actually can
be properly wired up in preparation for the day when the dependency in
Kconfig gets fixed.

> It would be good to at least get checksyscalls.sh fixed so arch maintainers
> get their warnings for new syscalls back.

Indeed.  That script has become just too important.

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4] remoteproc: Add STE modem driver for remoteproc

[Ohad Ben-Cohen]

On Sat, Sep 22, 2012 at 4:33 PM, Sjur Brændeland  wrote:
 It might be safer though to invoke ->setup() in probe/remove, instead
 of in start/stop (just like you essentially did before).

 This way we don't assume that stop is always called before remove (as
 assumption that might be implicitly valid today, but may break in the
 future).

 If you want, I can just change that before applying.
>>>
>>> Sounds good, please just go ahead and change this before applying.
>>> Thank you.
>>
>> I'm going to squash the below into the patch - please ack before I
>> apply and push - thanks!
>
> Looks good, thanks.
>
> Acked-by: Sjur Brændeland 

Thanks, applied and pushed to remoteproc's for-next branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ACPI/PCI] possible recursive locking detected

[Yinghai Lu]

On Sat, Sep 22, 2012 at 1:10 AM, Fengguang Wu  wrote:
>
>> > Please check attached patch that should fix the problem.
>>
>> updated more aggressive version. two patches.
>
> Yes they work nicely. Thank you very much!

Thanks.

v2 breaks acpi_bind_one.

So we should use attached -v3.

Bjorn, please apply -v3 before Taku's patchset.

-Yinghai


pci_root_bus_to_handle_v3.patch
Description: Binary data

Re: RCU idle CPU detection is broken in linux-next

[Paul E. McKenney]

On Sat, Sep 22, 2012 at 10:26:09AM +0200, Sasha Levin wrote:
> On 09/21/2012 05:18 PM, Sasha Levin wrote:
> > On 09/21/2012 05:12 PM, Paul E. McKenney wrote:
> >> On Fri, Sep 21, 2012 at 03:26:27PM +0200, Sasha Levin wrote:
> >>> On 09/21/2012 02:13 PM, Paul E. McKenney wrote:
> > This might be unrelated, but I got the following dump as well when 
> > trinity
> >> decided it's time to reboot my guest:
>  OK, sounds like we should hold off until you reproduce, then.
> >>>
> >>> I'm not sure what you mean.
> >>>
> >>> There are basically two issues I'm seeing now, which reproduce pretty 
> >>> much every
> >>> time:
> >>>
> >>>  1. The "using when idle" warning.
> >>>  2. The rcu related hangs during shutdown.
> >>>
> >>> The first one appears early on when I start fuzzing, the other one 
> >>> happens when
> >>> shutting down - so both of them are reproducible in the same session.
> >>
> >> Ah, I misunderstood the "reboot my guest" -- I thought that you were
> >> doing something like repeated modprobe/rmmod cycles on rcutorture while
> >> running the guest for an extended time period.  That will teach me not
> >> to reply to email so soon after waking up.  ;-)
> >>
> >> That said, #2 is expected behavior given the RCU CPU stall warnings in
> >> your Sept. 20 dmesg.  This is because rcutorture does rcu_barrier() on
> >> the way out, which cannot complete if grace periods are not completing.
> >> And the later soft lockup is also likely a consequence of the stall,
> >> because CPU hotplug does a synchronize_sched() while holding the hotplug
> >> lock, which will then cause get_online_cpus() to hang.
> >>
> >> Looking further down, there are hung tasks that are waiting for a
> >> timeout, but this is also a consequence of the hang because they
> >> are waiting for MAX_SCHEDULE_TIMEOUT -- in other words, they are
> >> waiting to be killed at shutdown time.  I could suppress this by using
> >> schedule_timeout_interruptible() in a loop in order to reduce the noise
> >> in this case.
> >>
> >> The remaining traces in that email are also consequences of the stall.
> >>
> >> So why the stall?
> >>
> >> Using RCU from a CPU that RCU believes to be idle can cause arbitrary
> >> bad behavior (possibly including stalls), but with very low probability.
> >> The reason that things can go arbitrarily bad is that RCU is ignoring
> >> the CPU, and thus not waiting for any RCU read-side critical sections.
> >> This could of course result in abitrary corruption of memory.  The reason
> >> for the low probability is that grace periods tend to be long and RCU
> >> read-side critical sections tend to be short.
> >>
> >> It looks like you are running -next, which has RCU grace periods driven
> >> by a kthread.  Is it possible that this kthread is not getting a chance
> >> to run (in fact, the "Stall ended before state dump start" is consistent
> >> with that possibility), but in that case I would expect to see a soft
> >> lockup from it.  Furthermore, in that case, it would be expected to
> >> start running again as soon as things started going idle during shutdown.
> >>
> >> Or did the system somehow manage to stay busy despite being in shutdown?
> >> Or, for that matter, are you overcommitting the physical CPUs on your
> >> trinity test setup?
> > 
> > Nope, I originally had 4 vcpus in the guest with the host running 4 physical
> > cpus, but I've also tested it with just 2 vcpus and still see the warnings.
> 
> Some more info that might help, I'm also occasionally seeing:
> 
> [   42.389345] [ cut here ]
> [   42.389348] WARNING: at kernel/rcutree.c:375 rcu_eqs_enter+0x5c/0xc0()
> [   42.389350] Pid: 0, comm: swapper/2 Tainted: GW
> 3.6.0-rc6-next-20120921-sasha-2-ge9c9495-dirty #378

Hmmm...  So either RCU is losing count or some CPU that is already
marked as idle from RCU's perspective is trying to re-enter idle.

This is helpful, thank you!  It fits in nicely with the splat that
you got after applying Michael Wang's patch.  Could you please try the
diagnostic patch below?

Thanx, Paul

> [   42.389351] Call Trace:
> [   42.389354]  [] ? rcu_eqs_enter+0x5c/0xc0
> [   42.389356]  [] warn_slowpath_common+0x86/0xb0
> [   42.389359]  [] warn_slowpath_null+0x15/0x20
> [   42.389361]  [] rcu_eqs_enter+0x5c/0xc0
> [   42.389364]  [] rcu_idle_enter+0x43/0xa0
> [   42.389366]  [] cpu_idle+0x126/0x160
> [   42.389369]  [] start_secondary+0x26e/0x276
> [   42.389370] ---[ end trace 04c11301284d64ee ]---
> [   42.389394] [ cut here ]
> [   42.389396] WARNING: at kernel/rcutree.c:350 
> rcu_eqs_enter_common+0x709/0x970()
> [   42.389398] Pid: 0, comm: swapper/2 Tainted: GW
> 3.6.0-rc6-next-20120921-sasha-2-ge9c9495-dirty #378
> [   42.389399] Call Trace:
> [   42.389402]  [] ? rcu_eqs_enter_common+0x709/0x970
> [   42.389405]  [] warn_slowpath_common+0x86/0xb0
> [   42.389407]  [] warn_slowpath_nu

Re: [PATCH v3 03/15] dmaengine: Add flags parameter to dmaengine_prep_dma_cyclic()

[Mark Brown]

On Fri, Sep 14, 2012 at 03:05:46PM +0300, Peter Ujfalusi wrote:
> With this parameter added to dmaengine_prep_dma_cyclic() the API will be in
> sync with other dmaengine_prep_*() functions.
> The dmaengine_prep_dma_cyclic() function primarily used by audio for cyclic
> transfer required by ALSA, we use the from audio to ask dma drivers to
> suppress interrupts (if DMA_PREP_INTERRUPT is cleared) when it is supported
> on the platform.

Are you sure this was generated against for-3.7?  There's fuzz against
dmaengine.h and git can't find the blobs to do resolution.  Anyway, I
applied this and the rest of the series.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 01/17] ARM: add mechanism for late code patching

[Nicolas Pitre]

On Fri, 21 Sep 2012, Cyril Chemparathy wrote:

> The original phys_to_virt/virt_to_phys patching implementation relied on early
> patching prior to MMU initialization.  On PAE systems running out of >4G
> address space, this would have entailed an additional round of patching after
> switching over to the high address space.
> 
> The approach implemented here conceptually extends the original PHYS_OFFSET
> patching implementation with the introduction of "early" patch stubs.  Early
> patch code is required to be functional out of the box, even before the patch
> is applied.  This is implemented by inserting functional (but inefficient)
> load code into the .runtime.patch.code init section.  Having functional code
> out of the box then allows us to defer the init time patch application until
> later in the init sequence.
> 
> In addition to fitting better with our need for physical address-space
> switch-over, this implementation should be somewhat more extensible by virtue
> of its more readable (and hackable) C implementation.  This should prove
> useful for other similar init time specialization needs, especially in light
> of our multi-platform kernel initiative.
> 
> This code has been boot tested in both ARM and Thumb-2 modes on an ARMv7
> (Cortex-A8) device.
> 
> Note: the obtuse use of stringified symbols in patch_stub() and
> early_patch_stub() is intentional.  Theoretically this should have been
> accomplished with formal operands passed into the asm block, but this requires
> the use of the 'c' modifier for instantiating the long (e.g. .long %c0).
> However, the 'c' modifier has been found to ICE certain versions of GCC, and
> therefore we resort to stringified symbols here.
> 
> Signed-off-by: Cyril Chemparathy 
> Reviewed-by: Nicolas Pitre 

There is another problem with this.

[...]
> diff --git a/arch/arm/include/asm/runtime-patch.h 
> b/arch/arm/include/asm/runtime-patch.h
> new file mode 100644
> index 000..366444d
> --- /dev/null
> +++ b/arch/arm/include/asm/runtime-patch.h
> @@ -0,0 +1,208 @@
> +/*
> + * arch/arm/include/asm/runtime-patch.h
> + * Note: this file should not be included by non-asm/.h files
> + *
> + * Copyright 2012 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#ifndef __ASM_ARM_RUNTIME_PATCH_H
> +#define __ASM_ARM_RUNTIME_PATCH_H
> +
> +#include 
> +
> +#ifndef __ASSEMBLY__
> +
> +#ifdef CONFIG_ARM_RUNTIME_PATCH
> +
> +struct patch_info {
> + void*insn;
> + u16  type;
> + u8   insn_size;
> + u8   data_size;
> + u32  data[0];
> +};

This causes the following compilation error:

  CC  sound/core/pcm.o
In file included from sound/core/pcm.c:293:0:
include/linux/soundcard.h:223:8: error: redefinition of 'struct patch_info'
arch/arm/include/asm/runtime-patch.h:28:8: note: originally defined here
make[2]: *** [sound/core/pcm.o] Error 1

The problem is that asm/runtime-patch.h gets included by asm/memory.h 
and asm/memory.h is included by almost the entire kernel. Something like 
"struct patch_info" is a bit too generic a name to be exported to the 
world as the likelihood of a name collision with some private definition 
in a driver or the like is rather high.  

In that context it might be worth moving everything that is not required 
for the patch stub definitions out of asm/runtime-patch.h.  For example, 
the definition of struct patch_info, struct patch_info_imm8, 
patch_next() and patch_data() could be moved to runtime-patch.c directly 
instead.  And then patch_stub() should be renamed to 
runtime_patch_stub(), early_patch_stub() to early_runtime_patch_stub(), 
patch_imm8() to runtime_patch_imm8(), etc.  Even the __IMM8 symbol name 
is rather weak for kernel wide scope.


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

Re: [PATCH 2/2] ACPI: Override arbitrary ACPI tables via initrd for debugging

[Len Brown]

This isn't a NAK, but I'm at best, "like warm" on this.

I'm not convinced it is a good thing to have - enabled by default -
the ability for users to easily over-ride ACPI tables.

I am concerned this will result in users hacking their BIOS, and making 
themselves
unsupportable by both their HW and SW suppliers.

"But it is just a _debug_ capability", one counters, "we'd never have
to support somebody who actually uses it."

Even if you toss support (and security) out the window, there is a more 
insidious
problem.  When such a user latches onto a workaround that tickles their
itch, they are satisfied, and they have zero incentive to get
either their BIOS or Linux fixed for the benefit of other users.

Today we have 2 methods to override AML:
ACPI_CUSTOM_METHOD (default n) allows you to scribble on AML
on the current running system.
ACPI_CUSTOM_DSDT (default n) allows you to override the entire DSDT/SSDT,
but requires you to build that DSDT into the custom kernel itself.

Developers running on their own systems are not complaining about these.

But what if you want to debug something on a remote system
with a distro binary kernel, you say?  The user doesn't know how
to build a kernel, and the distro is too busy to do so.
Some distros ship the initrd hack to  address this problem,
even though it has been repeatedly rejected upstream.
But curiously, even larger distros do NOT ship that hack
and somehow they have survived the last decade of Linux/ACPI
deployment without it.  How is that possible?

Yes, convenience sounds like an improvement over inconvenience.
Yes, generality to override any table sounds like a good thing
over the limitation to override just AML tables.
But does that make it a good idea?

specific comments in-line below...


On 09/21/2012 09:28 AM, Thomas Renninger wrote:
> Details can be found in:
> Documentation/acpi/initrd_table_override.txt
> 
> Signed-off-by: Thomas Renninger 
> CC: eric.p...@tremplin-utc.net
> CC: voj...@tlen.pl
> CC: Lin Ming 
> CC: l...@kernel.org
> CC: robert.mo...@intel.com
> CC: h...@zytor.com
> CC: ying...@kernel.org
> ---
>  Documentation/acpi/initrd_table_override.txt |  122 +++
>  arch/x86/kernel/setup.c  |4 +
>  drivers/acpi/Kconfig |9 +
>  drivers/acpi/osl.c   |  203 
> --
>  include/linux/acpi.h |4 +
>  5 files changed, 331 insertions(+), 11 deletions(-)
>  create mode 100644 Documentation/acpi/initrd_table_override.txt
> 
> diff --git a/Documentation/acpi/initrd_table_override.txt 
> b/Documentation/acpi/initrd_table_override.txt
> new file mode 100644
> index 000..b550831
> --- /dev/null
> +++ b/Documentation/acpi/initrd_table_override.txt
> @@ -0,0 +1,122 @@
> +Overriding ACPI tables via initrd
> +=
> +
> +1) Introduction (What is this about)
> +2) What is this for
> +3) How does it work
> +4) References (Where to retrieve userspace tools)
> +
> +1) What is this about
> +-
> +
> +If ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to

If "the" ACPI_...

> +override nearly any ACPI table provided by the BIOS with an instrumented,
> +modified one.
> +
> +For a full list of ACPI tables that can be overridden, take a look at
> +the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in drivers/acpi/osl.c
> +All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should
> +be overridable, except:
> +   - ACPI_SIG_RSDP (has a signature of 6 bytes)
> +   - ACPI_SIG_FACS (does not have an ordinary ACPI table header)
> +Both could get implemented as well.
> +
> +
> +2) What is this for
> +---
> +
> +Please keep in mind that this is a debug option.
> +ACPI tables should not get overridden for productive use.
> +If BIOS ACPI tables are overridden the kernel will get tainted with the
> +TAINT_OVERRIDDEN_ACPI_TABLE flag.
> +Complain to your platform/BIOS vendor if you find a bug which is that sever

"bug, which is so severe"

> +that a workaround is not accepted in the Linus kernel.

"Linux kernel"

> +
> +Still, it can and should be enabled in any kernel, because:
> +  - There is no functional change with not instrumented initrds
> +  - It provides a powerful feature to easily debug and test ACPI BIOS table
> +compatibility with the Linux kernel.
> +
> +Until now it was only possible to override the DSDT by compiling it into
> +the kernel. This is a nightmare when trying to work on ACPI related bugs
> +and a lot bugs got stuck because of that.
> +
> +Even for people with enough kernel knowledge, building a kernel to try out
> +things is very time consuming. Also people may have to browse and modify the
> +ACPI interpreter code to find a possible BIOS bug. With this feature, people
> +can correct the ACPI tables and try out quickly whether this is the root 
> cause
> +that needs to get addressed in the kernel.
> +
> +This could ev

Re: [PATCH v4 00/14] MFD/ASoC/Input: twl4030-audio submodule DT support

[Mark Brown]

On Mon, Sep 10, 2012 at 01:46:18PM +0300, Peter Ujfalusi wrote:

> Hello,

Applied all, 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: RCU idle CPU detection is broken in linux-next

[Paul E. McKenney]

On Sat, Sep 22, 2012 at 08:09:13AM -0700, Paul E. McKenney wrote:
> On Sat, Sep 22, 2012 at 10:26:09AM +0200, Sasha Levin wrote:
> > On 09/21/2012 05:18 PM, Sasha Levin wrote:
> > > On 09/21/2012 05:12 PM, Paul E. McKenney wrote:
> > >> On Fri, Sep 21, 2012 at 03:26:27PM +0200, Sasha Levin wrote:
> > >>> On 09/21/2012 02:13 PM, Paul E. McKenney wrote:
> > > This might be unrelated, but I got the following dump as well when 
> > > trinity
> > >> decided it's time to reboot my guest:
> >  OK, sounds like we should hold off until you reproduce, then.
> > >>>
> > >>> I'm not sure what you mean.
> > >>>
> > >>> There are basically two issues I'm seeing now, which reproduce pretty 
> > >>> much every
> > >>> time:
> > >>>
> > >>>  1. The "using when idle" warning.
> > >>>  2. The rcu related hangs during shutdown.
> > >>>
> > >>> The first one appears early on when I start fuzzing, the other one 
> > >>> happens when
> > >>> shutting down - so both of them are reproducible in the same session.
> > >>
> > >> Ah, I misunderstood the "reboot my guest" -- I thought that you were
> > >> doing something like repeated modprobe/rmmod cycles on rcutorture while
> > >> running the guest for an extended time period.  That will teach me not
> > >> to reply to email so soon after waking up.  ;-)
> > >>
> > >> That said, #2 is expected behavior given the RCU CPU stall warnings in
> > >> your Sept. 20 dmesg.  This is because rcutorture does rcu_barrier() on
> > >> the way out, which cannot complete if grace periods are not completing.
> > >> And the later soft lockup is also likely a consequence of the stall,
> > >> because CPU hotplug does a synchronize_sched() while holding the hotplug
> > >> lock, which will then cause get_online_cpus() to hang.
> > >>
> > >> Looking further down, there are hung tasks that are waiting for a
> > >> timeout, but this is also a consequence of the hang because they
> > >> are waiting for MAX_SCHEDULE_TIMEOUT -- in other words, they are
> > >> waiting to be killed at shutdown time.  I could suppress this by using
> > >> schedule_timeout_interruptible() in a loop in order to reduce the noise
> > >> in this case.
> > >>
> > >> The remaining traces in that email are also consequences of the stall.
> > >>
> > >> So why the stall?
> > >>
> > >> Using RCU from a CPU that RCU believes to be idle can cause arbitrary
> > >> bad behavior (possibly including stalls), but with very low probability.
> > >> The reason that things can go arbitrarily bad is that RCU is ignoring
> > >> the CPU, and thus not waiting for any RCU read-side critical sections.
> > >> This could of course result in abitrary corruption of memory.  The reason
> > >> for the low probability is that grace periods tend to be long and RCU
> > >> read-side critical sections tend to be short.
> > >>
> > >> It looks like you are running -next, which has RCU grace periods driven
> > >> by a kthread.  Is it possible that this kthread is not getting a chance
> > >> to run (in fact, the "Stall ended before state dump start" is consistent
> > >> with that possibility), but in that case I would expect to see a soft
> > >> lockup from it.  Furthermore, in that case, it would be expected to
> > >> start running again as soon as things started going idle during shutdown.
> > >>
> > >> Or did the system somehow manage to stay busy despite being in shutdown?
> > >> Or, for that matter, are you overcommitting the physical CPUs on your
> > >> trinity test setup?
> > > 
> > > Nope, I originally had 4 vcpus in the guest with the host running 4 
> > > physical
> > > cpus, but I've also tested it with just 2 vcpus and still see the 
> > > warnings.
> > 
> > Some more info that might help, I'm also occasionally seeing:
> > 
> > [   42.389345] [ cut here ]
> > [   42.389348] WARNING: at kernel/rcutree.c:375 rcu_eqs_enter+0x5c/0xc0()
> > [   42.389350] Pid: 0, comm: swapper/2 Tainted: GW
> > 3.6.0-rc6-next-20120921-sasha-2-ge9c9495-dirty #378
> 
> Hmmm...  So either RCU is losing count or some CPU that is already
> marked as idle from RCU's perspective is trying to re-enter idle.
> 
> This is helpful, thank you!  It fits in nicely with the splat that
> you got after applying Michael Wang's patch.  Could you please try the
> diagnostic patch below?

Also, could you please send me your full .config?

Thanx, Paul

> > [   42.389351] Call Trace:
> > [   42.389354]  [] ? rcu_eqs_enter+0x5c/0xc0
> > [   42.389356]  [] warn_slowpath_common+0x86/0xb0
> > [   42.389359]  [] warn_slowpath_null+0x15/0x20
> > [   42.389361]  [] rcu_eqs_enter+0x5c/0xc0
> > [   42.389364]  [] rcu_idle_enter+0x43/0xa0
> > [   42.389366]  [] cpu_idle+0x126/0x160
> > [   42.389369]  [] start_secondary+0x26e/0x276
> > [   42.389370] ---[ end trace 04c11301284d64ee ]---
> > [   42.389394] [ cut here ]
> > [   42.389396] WARNING: at kernel/rcutree.c:350 
> > rcu_eqs_ent

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

On Fri, Sep 21, 2012 at 03:55:28PM -0700, Eric W. Biederman wrote:

> 1) I don't see anything disabling kdb or kgdb.  If ever there
>was a way to poke into the kernel and change things...

Is there any way to access them without having physical console access 
(either the system console or a serial console)? Physically-present 
attacks are kind of out of scope here.

> 2) You almost certainly want to disable module removal.  It is all to
>easy to have races where that are not properly handled in the module
>removal path.  I know I saw a bundle of those in debugfs the other
>day.

I'm pretty reluctant to work around bugs like this. Disabling features 
certainly reduces the attack surface, but the aim is to only disable 
features that *by design* permit the modification of the kernel. Where 
it's possible to do so by exploiting bugs, we should be fixing the bugs.

> 3) And half seriously you probably want to disable mounting of
>filesystems.  I believe I have heard it said the kernel has not been
>vetted against a hostile root user mounting deliberately corrupted
>filesystem images.

See (2). Not that you need to be root to trigger filesystem mounts, so 
this is also a user->kernel exploit. Those should be fixed.

-- 
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 05/17] ARM: LPAE: support 64-bit virt_to_phys patching

[Nicolas Pitre]

On Fri, 21 Sep 2012, Cyril Chemparathy wrote:

> This patch adds support for 64-bit physical addresses in virt_to_phys()
> patching.  This does not do real 64-bit add/sub, but instead patches in the
> upper 32-bits of the phys_offset directly into the output of virt_to_phys.
> 
> There is no corresponding change on the phys_to_virt() side, because
> computations on the upper 32-bits would be discarded anyway.
> 
> Signed-off-by: Cyril Chemparathy 

Reviewed-by: Nicolas Pitre 


> ---
>  arch/arm/include/asm/memory.h |   38 --
>  arch/arm/kernel/head.S|4 
>  arch/arm/kernel/setup.c   |2 +-
>  3 files changed, 41 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 88ca206..f3e8f88 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -154,13 +154,47 @@
>  #ifdef CONFIG_ARM_PATCH_PHYS_VIRT
>  
>  extern unsigned long __pv_offset;
> -extern unsigned long __pv_phys_offset;
> +extern phys_addr_t   __pv_phys_offset;
>  #define PHYS_OFFSET  __virt_to_phys(PAGE_OFFSET)
>  
>  static inline phys_addr_t __virt_to_phys(unsigned long x)
>  {
> - unsigned long t;
> + phys_addr_t t;
> +
> +#ifndef CONFIG_ARM_LPAE
>   early_patch_imm8("add", t, x, __pv_offset, 0);
> +#else
> + unsigned long __tmp;
> +
> +#ifndef __ARMEB__
> +#define PV_PHYS_HIGH "(__pv_phys_offset + 4)"
> +#else
> +#define PV_PHYS_HIGH "__pv_phys_offset"
> +#endif
> +
> + early_patch_stub(
> + /* type */  PATCH_IMM8,
> + /* code */
> + "ldr%[tmp], =__pv_offset\n"
> + "ldr%[tmp], [%[tmp]]\n"
> + "add%Q[to], %[from], %[tmp]\n"
> + "ldr%[tmp], =" PV_PHYS_HIGH "\n"
> + "ldr%[tmp], [%[tmp]]\n"
> + "mov%R[to], %[tmp]\n",
> + /* pad */   4,
> + /* patch_data */
> + ".long  __pv_offset\n"
> + "add%Q[to], %[from], %[imm]\n"
> + ".long  "   PV_PHYS_HIGH "\n"
> + "mov%R[to], %[imm]\n",
> + /* operands */
> + : [to]   "=r"   (t),
> +   [tmp]  "=&r"  (__tmp)
> + : [from] "r"(x),
> +   [imm]  "I"(__IMM8),
> +  "i"(&__pv_offset),
> +  "i"(&__pv_phys_offset));
> +#endif
>   return t;
>  }
>  
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 69a3c09..61fb8df 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -530,7 +530,11 @@ ENDPROC(__fixup_pv_offsets)
>  
>   .align
>  1:   .long   .
> +#if defined(CONFIG_ARM_LPAE) && defined(__ARMEB__)
> + .long   __pv_phys_offset + 4
> +#else
>   .long   __pv_phys_offset
> +#endif
>   .long   __pv_offset
>   .long   PAGE_OFFSET
>  #endif
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 59e0f57..edb4f42 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -159,7 +159,7 @@ DEFINE_PER_CPU(struct cpuinfo_arm, cpu_data);
>   * The initializers here prevent these from landing in the BSS section.
>   */
>  unsigned long __pv_offset = 0xdeadbeef;
> -unsigned long __pv_phys_offset = 0xdeadbeef;
> +phys_addr_t   __pv_phys_offset = 0xdeadbeef;
>  EXPORT_SYMBOL(__pv_phys_offset);
>  
>  #endif
> -- 
> 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: sys_kcmp (was: Re: [PATCH 1/2] ARM: add finit_module syscall to ARM)

[Cyrill Gorcunov]

On Sat, Sep 22, 2012 at 03:38:47PM +0200, Ralf Baechle wrote:
> On Sat, Sep 22, 2012 at 02:20:46PM +0100, Russell King wrote:
> 
> > 2. There allegedly exists a patch to remove x86isms from sys_kcmp -
> >allegedly also in akpm's tree.  However, I've looked through the code in
> >mainline, and nothing stands out.  Ralf Beachle also said yesterday that
> >he has looked through from the MIPS PoV and also can't see any x86isms,
> >so we're both thinking that it should merely have the x86 dependency
> >removed.
> > 
> > 3. Until the x86 dependency is gone (that depends on what akpm proposes to
> >do with the patches he's allegedly sitting on), non-x86 arches can only
> >reserve the syscall, and add an IGNORE for it.
> 
> There is a weak definition provided in kernel/sys_ni.c so it actually can
> be properly wired up in preparation for the day when the dependency in
> Kconfig gets fixed.
> 
> > It would be good to at least get checksyscalls.sh fixed so arch maintainers
> > get their warnings for new syscalls back.
> 
> Indeed.  That script has become just too important.

These are the patches from linux-next/akpm

commit 6dfc4cffd24b0c7dc04ca36471a4a6b2a9fc1377
Author: Heiko Carstens 
Date:   Fri Sep 21 11:01:56 2012 +1000

syscalls: make kcmp syscall available for all architectures

commit 7f36f199e958ce7009285cd887323cb222ed6b1e
Author: Heiko Carstens 
Date:   Fri Sep 21 10:57:07 2012 +1000

checksyscalls: fix "here document" handling

So I guess this tree in a good shape just checksyscalls.sh fix should
go upstream, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rcu self-detected stall messages on OMAP3, 4 boards

[Frederic Weisbecker]

2012/9/22 Paul E. McKenney :
> On Fri, Sep 21, 2012 at 01:31:49PM -0700, Tony Lindgren wrote:
>> * Paul E. McKenney  [120921 12:58]:
>> >
>> > Just to make sure I understand the combinations:
>> >
>> > o   All stalls have happened when running a minimal userspace.
>> > o   CONFIG_NO_HZ=n suppresses the stalls.
>> > o   CONFIG_RCU_FAST_NO_HZ (which depends on CONFIG_NO_HZ=y) has
>> > no observable effect on the stalls.
>>
>> The reason why you may need minimal userspace is to cut down
>> the number of timers waking up the system with NO_HZ.
>> Booting with init=/bin/sh might also do the trick for that.
>
> Good point!  This does make for a very quiet system, but does not
> reproduce the problem under kvm, even after waiting for four minutes.
> I will leave it for more time, but it looks like I really might need to
> ask Linaro for remote access to a Panda.

I have one. I'm currently installing Ubuntu on it and I'll try to
manage to build
a kernel and reproduce the issue.

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

Re: [PATCH] regulator: deprecate regulator-compatible DT property

[Mark Brown]

On Thu, Sep 20, 2012 at 04:04:57PM -0600, Stephen Warren wrote:

> Mark, if this gets into 3.7, I can fix up all the Tegra .dts files during 3.8.

I don't know which branch you generated this against but it doesn't
apply to any of the obvious branches in my regulator tree.  There's a
modify/delete conflict in

   Documentation/devicetree/bindings/regulator/max8907.txt

which I don't seem to have.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rcu self-detected stall messages on OMAP3, 4 boards

[Paul E. McKenney]

On Sat, Sep 22, 2012 at 05:45:12PM +0200, Frederic Weisbecker wrote:
> 2012/9/22 Paul E. McKenney :
> > On Fri, Sep 21, 2012 at 01:31:49PM -0700, Tony Lindgren wrote:
> >> * Paul E. McKenney  [120921 12:58]:
> >> >
> >> > Just to make sure I understand the combinations:
> >> >
> >> > o   All stalls have happened when running a minimal userspace.
> >> > o   CONFIG_NO_HZ=n suppresses the stalls.
> >> > o   CONFIG_RCU_FAST_NO_HZ (which depends on CONFIG_NO_HZ=y) has
> >> > no observable effect on the stalls.
> >>
> >> The reason why you may need minimal userspace is to cut down
> >> the number of timers waking up the system with NO_HZ.
> >> Booting with init=/bin/sh might also do the trick for that.
> >
> > Good point!  This does make for a very quiet system, but does not
> > reproduce the problem under kvm, even after waiting for four minutes.
> > I will leave it for more time, but it looks like I really might need to
> > ask Linaro for remote access to a Panda.
> 
> I have one. I'm currently installing Ubuntu on it and I'll try to
> manage to build
> a kernel and reproduce the issue.
> 
> I'll give more news soon.

Thank you!

My bet is that you have to have a userspace that is so small that it
registers only a few (but at least one!) RCU callback at boot time,
then never registers any callbacks ever again.  I have coded up a
crude test case, using Tony Lindgren's suggestion of "init=/bin/sh",
but I appear to have inadvertently fixed this bug in current -rcu
(git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git,
branch rcu/next).

But I have been wrong a few times already on this particular bug...

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [REPOST PATCH v2 1/2] spi: omap2-mcspi: add pinctrl support

[Mark Brown]

On Tue, Sep 18, 2012 at 08:01:25AM -0400, Matt Porter wrote:
> Adds pinctrl support to support OMAP platforms that boot from DT
> and rely on pinctrl support to set pinmuxes.

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

Re: [PATCH resend] spi core: Provide means to instantiate devices through sysfs

[Mark Brown]

On Mon, Sep 17, 2012 at 04:51:20PM -0700, Guenter Roeck wrote:
> The I2C core provides a means to instantiate devices from userspace
> using sysfs attributes. Provide the same mechanism for SPI devices.

So, unlike I2C this is only going to work for a subset of controllers -
anything that relies on GPIOs for chip select will need more data to add
the chip selects for example.  This means I'm having a hard time getting
enthused about the idea, it seems like it might be a support burden.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] spi/pl022: Devicetree support w/o platform data

[Mark Brown]

On Tue, Sep 18, 2012 at 03:53:53PM +0200, Roland Stigge wrote:
> Even with devicetree support, we needed platform data to provide some data,
> leading to mixed device tree and platform data. This patch makes it possible 
> to
> provide all that information via device tree. Now, the data must be provided
> via platform data _or_ device tree completely.

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

[PATCH v3] lxt PHY: Support for the buggy LXT973 rev A2

[Christophe Leroy]

This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
precautions linked to ERRATA Item 4:

Revision A2 of LXT973 chip randomly returns the contents of the previous even
register when you read a odd register regularly

Signed-off-by: Christophe Leroy 

diff -u linux-3.5-vanilla/drivers/net/phy/lxt.c linux-3.5/drivers/net/phy/lxt.c
--- linux-3.5-vanilla/drivers/net/phy/lxt.c 2012-07-21 22:58:29.0 
+0200
+++ linux-3.5/drivers/net/phy/lxt.c 2012-09-15 19:20:34.0 +0200
@@ -54,8 +54,12 @@
 #define MII_LXT971_ISR 19  /* Interrupt Status Register */
 
 /* register definitions for the 973 */
-#define MII_LXT973_PCR 16 /* Port Configuration Register */
+#define MII_LXT973_PCR 16 /* Port Configuration Register */
 #define PCR_FIBER_SELECT 1
+#define MII_LXT973_SFR 27  /* Special Function Register */
+
+#define PHYDEV_PRIV_FIBER  1
+#define PHYDEV_PRIV_REVA2  2
 
 MODULE_DESCRIPTION("Intel LXT PHY driver");
 MODULE_AUTHOR("Andy Fleming");
@@ -99,6 +103,9 @@
return err;
 }
 
+/* register definitions for the 973 */
+#define MII_LXT973_PCR 16 /* Port Configuration Register */
+#define PCR_FIBER_SELECT 1
 
 static int lxt971_ack_interrupt(struct phy_device *phydev)
 {
@@ -122,9 +129,138 @@
return err;
 }
 
+/*
+ * A2 version of LXT973 chip has an ERRATA: it randomly return the contents
+ * of the previous even register when you read a odd register regularly
+ */
+
+static int lxt973a2_update_link(struct phy_device *phydev)
+{
+   int status;
+   int control;
+   int retry = 8; /* we try 8 times */
+
+   /* Do a fake read */
+   status = phy_read(phydev, MII_BMSR);
+
+   if (status < 0)
+   return status;
+
+   control = phy_read(phydev, MII_BMCR);
+   if (control < 0)
+   return control;
+
+   do {
+   /* Read link and autonegotiation status */
+   status = phy_read(phydev, MII_BMSR);
+   } while (status >= 0 && retry-- && status == control);
+
+   if (status < 0)
+   return status;
+
+   if ((status & BMSR_LSTATUS) == 0)
+   phydev->link = 0;
+   else
+   phydev->link = 1;
+
+   return 0;
+}
+
+int lxt973a2_read_status(struct phy_device *phydev)
+{
+   int adv;
+   int err;
+   int lpa;
+   int lpagb = 0;
+
+   /* Update the link, but return if there was an error */
+   err = lxt973a2_update_link(phydev);
+   if (err)
+   return err;
+
+   if (AUTONEG_ENABLE == phydev->autoneg) {
+   int retry = 1;
+
+   adv = phy_read(phydev, MII_ADVERTISE);
+
+   if (adv < 0)
+   return adv;
+
+   do {
+   lpa = phy_read(phydev, MII_LPA);
+
+   if (lpa < 0)
+   return lpa;
+
+   /* If both registers are equal, it is suspect but not
+   * impossible, hence a new try
+   */
+   } while (lpa == adv && retry--);
+
+   lpa &= adv;
+
+   phydev->speed = SPEED_10;
+   phydev->duplex = DUPLEX_HALF;
+   phydev->pause = phydev->asym_pause = 0;
+
+   if (lpagb & (LPA_1000FULL | LPA_1000HALF)) {
+   phydev->speed = SPEED_1000;
+
+   if (lpagb & LPA_1000FULL)
+   phydev->duplex = DUPLEX_FULL;
+   } else if (lpa & (LPA_100FULL | LPA_100HALF)) {
+   phydev->speed = SPEED_100;
+
+   if (lpa & LPA_100FULL)
+   phydev->duplex = DUPLEX_FULL;
+   } else
+   if (lpa & LPA_10FULL)
+   phydev->duplex = DUPLEX_FULL;
+
+   if (phydev->duplex == DUPLEX_FULL) {
+   phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
+   phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
+   }
+   } else {
+   int bmcr = phy_read(phydev, MII_BMCR);
+
+   if (bmcr < 0)
+   return bmcr;
+
+   if (bmcr & BMCR_FULLDPLX)
+   phydev->duplex = DUPLEX_FULL;
+   else
+   phydev->duplex = DUPLEX_HALF;
+
+   if (bmcr & BMCR_SPEED1000)
+   phydev->speed = SPEED_1000;
+   else if (bmcr & BMCR_SPEED100)
+   phydev->speed = SPEED_100;
+   else
+   phydev->speed = SPEED_10;
+
+   phydev->pause = phydev->asym_pause = 0;
+   }
+
+   return 0;
+}
+
+static int lxt973_read_status(struct phy_device *phydev)
+{
+   return (int)phydev->priv&PHYDEV_PRIV_REVA2 ?
+   lxt973a2_read_status(phydev) :
+   genphy_read_status(phydev);
+}
+
 stat

Re: [PATCH v2] lxt PHY: Support for the buggy LXT973 rev A2

[leroy christophe]

Le 10/09/2012 20:17, Lutz Jaenicke a écrit :

On Mon, Sep 10, 2012 at 05:45:49PM +0200, Christophe Leroy wrote:

This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
precautions linked to ERRATA Item 4:

Item 4: MDIO Interface and Repeated Polling
Problem: Repeated polling of odd-numbered registers via the MDIO interface
randomly returns the contents of the previous even register.
Implication: Managed applications may not obtain the correct register contents
when a particular register is monitored for device status.
Workaround: None.
Status: This erratum has been previously fixed (in rev A3)

Hmm. Were did you get the hardware from? We have been using LXT973 in
our products and the A2 was replaced by A3 in 2003.

Best regards,
Lutz
They are custom boards that my company manufactures. Most boards 
manufactured before 2006 or 2007 have this buggy chip.


Regards
Christophe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: mxs: Use a better name for the USB PHY clock

[Fabio Estevam]

From: Fabio Estevam 

Use a better name for the USB PHY clock.

Signed-off-by: Fabio Estevam 
---
 .../devicetree/bindings/clock/imx23-clock.txt  |2 +-
 .../devicetree/bindings/clock/imx28-clock.txt  |4 ++--
 drivers/clk/mxs/clk-imx23.c|6 +++---
 drivers/clk/mxs/clk-imx28.c|   10 +-
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.txt 
b/Documentation/devicetree/bindings/clock/imx23-clock.txt
index a0b867e..baadbb1 100644
--- a/Documentation/devicetree/bindings/clock/imx23-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx23-clock.txt
@@ -52,7 +52,7 @@ clocks and IDs.
lcdif   38
etm 39
usb 40
-   usb_pwr 41
+   usb_phy 41
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.txt 
b/Documentation/devicetree/bindings/clock/imx28-clock.txt
index aa2af28..52a49a4 100644
--- a/Documentation/devicetree/bindings/clock/imx28-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx28-clock.txt
@@ -73,8 +73,8 @@ clocks and IDs.
can159
usb060
usb161
-   usb0_pwr62
-   usb1_pwr63
+   usb0_phy62
+   usb1_phy63
enet_out64
 
 Examples:
diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
index f00dffb..8dd476e 100644
--- a/drivers/clk/mxs/clk-imx23.c
+++ b/drivers/clk/mxs/clk-imx23.c
@@ -85,7 +85,7 @@ enum imx23_clk {
cpu_xtal, hbus, xbus, lcdif_div, ssp_div, gpmi_div, emi_pll,
emi_xtal, etm_div, saif_div, clk32k_div, rtc, adc, spdif_div,
clk32k, dri, pwm, filt, uart, ssp, gpmi, spdif, emi, saif,
-   lcdif, etm, usb, usb_pwr,
+   lcdif, etm, usb, usb_phy,
clk_max
 };
 
@@ -143,8 +143,8 @@ int __init mx23_clocks_init(void)
clks[saif] = mxs_clk_gate("saif", "saif_div", SAIF, 31);
clks[lcdif] = mxs_clk_gate("lcdif", "lcdif_div", PIX, 31);
clks[etm] = mxs_clk_gate("etm", "etm_div", ETM, 31);
-   clks[usb] = mxs_clk_gate("usb", "usb_pwr", DIGCTRL, 2);
-   clks[usb_pwr] = clk_register_gate(NULL, "usb_pwr", "pll", 0, PLLCTRL0, 
18, 0, &mxs_lock);
+   clks[usb] = mxs_clk_gate("usb", "usb_phy", DIGCTRL, 2);
+   clks[usb_phy] = clk_register_gate(NULL, "usb_phy", "pll", 0, PLLCTRL0, 
18, 0, &mxs_lock);
 
for (i = 0; i < ARRAY_SIZE(clks); i++)
if (IS_ERR(clks[i])) {
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index 42978f1b..db3af08 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -140,7 +140,7 @@ enum imx28_clk {
emi_xtal, lcdif_div, etm_div, ptp, saif0_div, saif1_div,
clk32k_div, rtc, lradc, spdif_div, clk32k, pwm, uart, ssp0,
ssp1, ssp2, ssp3, gpmi, spdif, emi, saif0, saif1, lcdif, etm,
-   fec, can0, can1, usb0, usb1, usb0_pwr, usb1_pwr, enet_out,
+   fec, can0, can1, usb0, usb1, usb0_phy, usb1_phy, enet_out,
clk_max
 };
 
@@ -218,10 +218,10 @@ int __init mx28_clocks_init(void)
clks[fec] = mxs_clk_gate("fec", "hbus", ENET, 30);
clks[can0] = mxs_clk_gate("can0", "ref_xtal", FLEXCAN, 30);
clks[can1] = mxs_clk_gate("can1", "ref_xtal", FLEXCAN, 28);
-   clks[usb0] = mxs_clk_gate("usb0", "usb0_pwr", DIGCTRL, 2);
-   clks[usb1] = mxs_clk_gate("usb1", "usb1_pwr", DIGCTRL, 16);
-   clks[usb0_pwr] = clk_register_gate(NULL, "usb0_pwr", "pll0", 0, 
PLL0CTRL0, 18, 0, &mxs_lock);
-   clks[usb1_pwr] = clk_register_gate(NULL, "usb1_pwr", "pll1", 0, 
PLL1CTRL0, 18, 0, &mxs_lock);
+   clks[usb0] = mxs_clk_gate("usb0", "usb0_phy", DIGCTRL, 2);
+   clks[usb1] = mxs_clk_gate("usb1", "usb1_phy", DIGCTRL, 16);
+   clks[usb0_phy] = clk_register_gate(NULL, "usb0_phy", "pll0", 0, 
PLL0CTRL0, 18, 0, &mxs_lock);
+   clks[usb1_phy] = clk_register_gate(NULL, "usb1_phy", "pll1", 0, 
PLL1CTRL0, 18, 0, &mxs_lock);
clks[enet_out] = clk_register_gate(NULL, "enet_out", "pll2", 0, ENET, 
18, 0, &mxs_lock);
 
for (i = 0; i < ARRAY_SIZE(clks); i++)
-- 
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/

pull request: wireless 2012-09-22

[John W. Linville]

commit 112df2417dc9a1db1b19930ea4d0a697a61e

Dave,

Please pull this last(?) batch of fixes intended for 3.6...

For the Bluetooth bits, Gustavo says this:

"Here goes probably my last update to 3.6. It includes the two patches
you were ok last week(from Andrzej Kaczmarek), those are critical
ones, and two other fixes one for a system crash and the other for
a missing lockdep annotation."

The referenced fixes from Andrzej prevent attempts to configure devices
that are powered-off.

Along with the Bluetooth fixes, there are a couple of 802.11 fixes.
Emmanuel Grumbach gives us an iwlwifi fix to prevent releasing an
interrupt twice.  Luis R. Rodriguez provides a fix for a possible
circular lock dependency in the cfg80211 regulatory enforcement code.

All of these have been in linux-next for a few days.  I hope they are
not too late to make the 3.6 release!

Thanks,

John

---

The following changes since commit abef3bd71029b80ec1bdd6c6244b5b0b99f56633:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-09-21 
14:32:55 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem

for you to fetch changes up to 112df2417dc9a1db1b19930ea4d0a697a61e:

  Merge branch 'master' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem 
(2012-09-22 12:19:22 -0400)



Andrei Emeltchenko (1):
  Bluetooth: Fix freeing uninitialized delayed works

Andrzej Kaczmarek (2):
  Bluetooth: mgmt: Fix enabling SSP while powered off
  Bluetooth: mgmt: Fix enabling LE while powered off

Emmanuel Grumbach (1):
  iwlwifi: don't double free the interrupt in failure path

John W. Linville (1):
  Merge branch 'master' of git://git.kernel.org/.../linville/wireless into 
for-davem

Luis R. Rodriguez (1):
  cfg80211: fix possible circular lock on reg_regdb_search()

Vinicius Costa Gomes (1):
  Bluetooth: Fix not removing power_off delayed work

 drivers/net/wireless/iwlwifi/pcie/trans.c |  1 +
 net/bluetooth/hci_core.c  |  2 ++
 net/bluetooth/l2cap_core.c|  2 +-
 net/bluetooth/mgmt.c  | 16 
 net/wireless/reg.c| 12 +---
 5 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/iwlwifi/pcie/trans.c
index 1e86ea2..dbeebef 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -1442,6 +1442,7 @@ static int iwl_trans_pcie_start_hw(struct iwl_trans 
*trans)
return err;
 
 err_free_irq:
+   trans_pcie->irq_requested = false;
free_irq(trans_pcie->irq, trans);
 error:
iwl_free_isr_ict(trans);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d4de5db..0b997c8 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -734,6 +734,8 @@ static int hci_dev_do_close(struct hci_dev *hdev)
 
cancel_work_sync(&hdev->le_scan);
 
+   cancel_delayed_work(&hdev->power_off);
+
hci_req_cancel(hdev, ENODEV);
hci_req_lock(hdev);
 
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4ea1710..38c00f1 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1008,7 +1008,7 @@ static void l2cap_send_disconn_req(struct l2cap_conn 
*conn, struct l2cap_chan *c
if (!conn)
return;
 
-   if (chan->mode == L2CAP_MODE_ERTM) {
+   if (chan->mode == L2CAP_MODE_ERTM && chan->state == BT_CONNECTED) {
__clear_retrans_timer(chan);
__clear_monitor_timer(chan);
__clear_ack_timer(chan);
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index ad6613d..eba022d 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2875,6 +2875,22 @@ int mgmt_powered(struct hci_dev *hdev, u8 powered)
if (scan)
hci_send_cmd(hdev, HCI_OP_WRITE_SCAN_ENABLE, 1, &scan);
 
+   if (test_bit(HCI_SSP_ENABLED, &hdev->dev_flags)) {
+   u8 ssp = 1;
+
+   hci_send_cmd(hdev, HCI_OP_WRITE_SSP_MODE, 1, &ssp);
+   }
+
+   if (test_bit(HCI_LE_ENABLED, &hdev->dev_flags)) {
+   struct hci_cp_write_le_host_supported cp;
+
+   cp.le = 1;
+   cp.simul = !!(hdev->features[6] & LMP_SIMUL_LE_BR);
+
+   hci_send_cmd(hdev, HCI_OP_WRITE_LE_HOST_SUPPORTED,
+sizeof(cp), &cp);
+   }
+
update_class(hdev);
update_name(hdev, hdev->dev_name);
update_eir(hdev);
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2ded3c7..72d170c 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -350,

Re: [PATCH v3] lxt PHY: Support for the buggy LXT973 rev A2

[Richard Cochran]

On Sat, Sep 22, 2012 at 06:16:49PM +0200, Christophe Leroy wrote:
> This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
> precautions linked to ERRATA Item 4:
> 
> Revision A2 of LXT973 chip randomly returns the contents of the previous even
> register when you read a odd register regularly

This patch does not apply to net-next.

Also, I have just a few stylistic comments, below.

> Signed-off-by: Christophe Leroy 
> 
> diff -u linux-3.5-vanilla/drivers/net/phy/lxt.c 
> linux-3.5/drivers/net/phy/lxt.c
> --- linux-3.5-vanilla/drivers/net/phy/lxt.c   2012-07-21 22:58:29.0 
> +0200
> +++ linux-3.5/drivers/net/phy/lxt.c   2012-09-15 19:20:34.0 +0200

...

> +int lxt973a2_read_status(struct phy_device *phydev)
> +{
> + int adv;
> + int err;
> + int lpa;
> + int lpagb = 0;
> +
> + /* Update the link, but return if there was an error */
> + err = lxt973a2_update_link(phydev);
> + if (err)
> + return err;
> +
> + if (AUTONEG_ENABLE == phydev->autoneg) {
> + int retry = 1;
> +
> + adv = phy_read(phydev, MII_ADVERTISE);
> +
> + if (adv < 0)
> + return adv;
> +
> + do {
> + lpa = phy_read(phydev, MII_LPA);
> +
> + if (lpa < 0)
> + return lpa;
> +
> + /* If both registers are equal, it is suspect but not
> + * impossible, hence a new try
> + */
> + } while (lpa == adv && retry--);
> +
> + lpa &= adv;
> +
> + phydev->speed = SPEED_10;
> + phydev->duplex = DUPLEX_HALF;
> + phydev->pause = phydev->asym_pause = 0;
> +
> + if (lpagb & (LPA_1000FULL | LPA_1000HALF)) {
> + phydev->speed = SPEED_1000;
> +
> + if (lpagb & LPA_1000FULL)
> + phydev->duplex = DUPLEX_FULL;
> + } else if (lpa & (LPA_100FULL | LPA_100HALF)) {
> + phydev->speed = SPEED_100;
> +
> + if (lpa & LPA_100FULL)
> + phydev->duplex = DUPLEX_FULL;
> + } else
> + if (lpa & LPA_10FULL)
> + phydev->duplex = DUPLEX_FULL;

This last 'else' could use braces.

> +
> + if (phydev->duplex == DUPLEX_FULL) {
> + phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
> + phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
> + }
> + } else {
> + int bmcr = phy_read(phydev, MII_BMCR);
> +
> + if (bmcr < 0)
> + return bmcr;
> +
> + if (bmcr & BMCR_FULLDPLX)
> + phydev->duplex = DUPLEX_FULL;
> + else
> + phydev->duplex = DUPLEX_HALF;
> +
> + if (bmcr & BMCR_SPEED1000)
> + phydev->speed = SPEED_1000;
> + else if (bmcr & BMCR_SPEED100)
> + phydev->speed = SPEED_100;
> + else
> + phydev->speed = SPEED_10;
> +
> + phydev->pause = phydev->asym_pause = 0;
> + }
> +
> + return 0;
> +}
> +
> +static int lxt973_read_status(struct phy_device *phydev)
> +{
> + return (int)phydev->priv&PHYDEV_PRIV_REVA2 ?
> + lxt973a2_read_status(phydev) :
> + genphy_read_status(phydev);

Needs spacing, like this:

return (int) phydev->priv & PHYDEV_PRIV_REVA2 ?
lxt973a2_read_status(phydev) : genphy_read_status(phydev);

> +}
> +
>  static int lxt973_probe(struct phy_device *phydev)
>  {
>   int val = phy_read(phydev, MII_LXT973_PCR);
> + int priv = 0;
> +
> + phydev->priv = NULL;
> +
> + if (val < 0)
> + return val;
>  
>   if (val & PCR_FIBER_SELECT) {
>   /*
> @@ -136,17 +272,26 @@
>   val &= ~BMCR_ANENABLE;
>   phy_write(phydev, MII_BMCR, val);
>   /* Remember that the port is in fiber mode. */
> - phydev->priv = lxt973_probe;
> - } else {
> - phydev->priv = NULL;
> + priv |= PHYDEV_PRIV_FIBER;
> + }
> + val = phy_read(phydev, MII_PHYSID2);
> +
> + if (val < 0)
> + return val;
> +
> + if ((val & 0xf) == 0) { /* rev A2 */
> + dev_info(&phydev->dev, " LXT973 revision A2 has bugs\n");
> + priv |= PHYDEV_PRIV_REVA2;
>   }
> + phydev->priv = (void *)priv;

One space after cast, please: (void *) priv;

>   return 0;
>  }
>  
>  static int lxt973_config_aneg(struct phy_device *phydev)
>  {
>   /* Do nothing if port is in fiber mode. */
> - return phydev->priv ? 0 : genphy_config_aneg(phydev);
> + return (int)phydev->priv&PHYDEV_PRIV_FIBER ?
> + 0 : genphy_config_aneg(phydev);

Same spacing issue agai

Re: RCU idle CPU detection is broken in linux-next

[Sasha Levin]

On 09/22/2012 05:56 PM, Paul E. McKenney wrote:
> And now the prime suspect is the new CONFIG_RCU_USER_QS=y.  Do these
> warnings ever show up with CONFIG_RCU_USER_QS=n?

It seems that disabling that does make the warnings go away.

I'll keep the tests running in case it just reduces the chances or something
like that.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] console: implement lockdep support for console_lock

[Daniel Vetter]

Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:

https://lkml.org/lkml/2012/8/21/36

Unfortunately the console_lock isn't a plain mutex and hence has no
lockdep support. Which resulted in a few days wasted of tracking down
this bug (complicated by the fact that printk doesn't show anything
when the console is locked) instead of noticing the bug much earlier
with the lockdep splat.

Hence I've figured I need to fix that for the next deadlock involving
console_lock - and with kms/drm growing ever more complex locking
that'll eventually happen.

Now the console_lock has rather funky semantics, so after a quick irc
discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
the original idead of switching to a real mutex (since it won't work)
and instead opted to annotate the console_lock with lockdep
information manually.

There are a few special cases:
- The console_lock state is protected by the console_sem, and usually
  grabbed/dropped at _lock/_unlock time. But the suspend/resume code
  drops the semaphore without dropping the console_lock (see
  suspend_console/resume_console). But since the same thread that did
  the suspend will do the resume, we don't need to fix up anything.

- In the printk code there's a special trylock, only used to kick off
  the logbuffer printk'ing in console_unlock. But all that happens
  while lockdep is disable (since printk does a few other evil
  tricks). So no issue there, either.

- The console_lock can also be acquired form irq context (but only
  with a trylock). lockdep already handles that.

This all leaves us with annotating the normal console_lock, _unlock
and _trylock functions.

And yes, it works - simply unloading a drm kms driver resulted in
lockdep complaining about the deadlock in fbcon_deinit:

==
[ INFO: possible circular locking dependency detected ]
3.6.0-rc2+ #552 Not tainted
---
kms-reload/3577 is trying to acquire lock:
 ((&info->queue)){+.+...}, at: [] wait_on_work+0x0/0xa7

but task is already holding lock:
 (console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (console_lock){+.+.+.}:
   [] lock_acquire+0x95/0x105
   [] console_lock+0x59/0x5b
   [] fb_flashcursor+0x2e/0x12c
   [] process_one_work+0x1d9/0x3b4
   [] worker_thread+0x1a7/0x24b
   [] kthread+0x7f/0x87
   [] kernel_thread_helper+0x4/0x10

-> #0 ((&info->queue)){+.+...}:
   [] __lock_acquire+0x999/0xcf6
   [] lock_acquire+0x95/0x105
   [] wait_on_work+0x3b/0xa7
   [] __cancel_work_timer+0xbf/0x102
   [] cancel_work_sync+0xb/0xd
   [] fbcon_deinit+0x11c/0x1dc
   [] bind_con_driver+0x145/0x263
   [] unbind_con_driver+0x14f/0x195
   [] store_bind+0x1ad/0x1c1
   [] dev_attr_store+0x13/0x1f
   [] sysfs_write_file+0xe9/0x121
   [] vfs_write+0x9b/0xfd
   [] sys_write+0x3e/0x6b
   [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(console_lock);
   lock((&info->queue));
   lock(console_lock);
  lock((&info->queue));

 *** DEADLOCK ***

v2: Mark the lockdep_map static, noticed by Jani Nikula.

Cc: Dave Airlie 
Cc: Thomas Gleixner 
Cc: Alan Cox 
Cc: Peter Zijlstra 
Signed-off-by: Daniel Vetter 
---
 kernel/printk.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/kernel/printk.c b/kernel/printk.c
index ed9af6a..e5c6dba 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -87,6 +87,12 @@ static DEFINE_SEMAPHORE(console_sem);
 struct console *console_drivers;
 EXPORT_SYMBOL_GPL(console_drivers);
 
+#ifdef CONFIG_LOCKDEP
+static struct lockdep_map console_lock_dep_map = {
+   .name = "console_lock"
+};
+#endif
+
 /*
  * This is used for debugging the mess that is the VT code by
  * keeping track if we have the console semaphore held. It's
@@ -1916,6 +1922,7 @@ void console_lock(void)
return;
console_locked = 1;
console_may_schedule = 1;
+   mutex_acquire(&console_lock_dep_map, 0, 0, _RET_IP_);
 }
 EXPORT_SYMBOL(console_lock);
 
@@ -1937,6 +1944,7 @@ int console_trylock(void)
}
console_locked = 1;
console_may_schedule = 0;
+   mutex_acquire(&console_lock_dep_map, 0, 1, _RET_IP_);
return 1;
 }
 EXPORT_SYMBOL(console_trylock);
@@ -2097,6 +2105,7 @@ skip:
local_irq_restore(flags);
}
console_locked = 0;
+   mutex_release(&console_lock_dep_map, 1, _RET_IP_);
 
/* Release the exclusive_console once it is used */
if (unlikely(exclus

Re: [RFC] tty: Add get- ioctls to fetch tty status

[Cyrill Gorcunov]

On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> On Thu, 13 Sep 2012 16:54:01 +0400
> Cyrill Gorcunov  wrote:
> 
> > On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > > +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> > > > +{
> > > > +   int locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> > > > +   if (put_user(locked, arg))
> > > > +   return -EFAULT;
> > > 
> > > Now explain exactly how this doesn't race with another thread chanigng
> > > the lock setting ?
> > 
> > It's the same as to set/clear this bit, isn't it? Please correct me
> > if I'm wrong.
> 
> So by the time you've finished the test bit and returned it to user space
> the answer may have changed ?
> 
> > > The other comment I have is that it might be better put these in now
> > > there are sysfs patches for the tty layer bouncing about to provide the
> > > needed infrastructure ?
> > 
> > Alan, could you please point me where these patches are living, so I would
> > take a look and check them out
> 
> linux-serial or check tty-next as I think Greg has now merged the test
> patch.

Guys, you mean something like below? Look, I must admit I'm not really
sure if I've done all locking right, and there is no need for additional
kref counting on tty_struct. Could you please check if it looks more-less
sane (I've tested it but still...)

---
From: Cyrill Gorcunov 
Subject: tty, pty: Add pty_state attribute to fetch tty flags

For checkpoint/restore we need to know if tty has
exclusive or packet mode set, as well as if pty
is currently locked (just to be able to restore
this characteristics).

To serve this the pty_state attribute is introduced
for pty devices. A typical output looks like

 | [root@neptune ~]# cat /sys/devices/virtual/tty/ptmp0/pty_state
 | locked: 0 exclusive: 0 packet: 0

Signed-off-by: Cyrill Gorcunov 
CC: Alan Cox 
CC: Greg Kroah-Hartman 
CC: "H. Peter Anvin" 
CC: Jiri Slaby 
CC: Pavel Emelyanov 
---
 drivers/tty/pty.c |   45 -
 1 file changed, 44 insertions(+), 1 deletion(-)

Index: tty.git/drivers/tty/pty.c
===
--- tty.git.orig/drivers/tty/pty.c
+++ tty.git/drivers/tty/pty.c
@@ -283,6 +283,46 @@ done:
return 0;
 }
 
+static ssize_t pty_show_state(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct tty_struct *tty = dev_get_drvdata(dev);
+   int locked, exclusive, packet;
+
+   tty_lock(tty);
+   locked = test_bit(TTY_PTY_LOCK, &tty->flags);
+   exclusive = test_bit(TTY_EXCLUSIVE, &tty->flags);
+   packet = tty->packet;
+   tty_unlock(tty);
+
+   return snprintf(buf, PAGE_SIZE, "locked: %d exclusive: %d packet: %d\n",
+   locked, exclusive, packet);
+}
+
+static DEVICE_ATTR(pty_state, S_IRUSR | S_IRGRP, pty_show_state, NULL);
+
+static struct attribute *pty_state_dev_attrs[] = {
+   &dev_attr_pty_state.attr,
+   NULL,
+};
+
+static const struct attribute_group pty_dev_attr_group = {
+   .attrs = pty_state_dev_attrs,
+};
+
+static const struct attribute_group *pty_dev_attr_groups[] = {
+   &pty_dev_attr_group,
+   NULL,
+};
+
+static int pty_register_attr(struct tty_driver *driver, struct tty_struct *tty)
+{
+   struct device *dev = tty_register_device_attr(driver, tty->index, 
tty->dev,
+ (void *)tty, 
pty_dev_attr_groups);
+   return PTR_RET(dev);
+}
+
 /**
  * pty_common_install  -   set up the pty pair
  * @driver: the pty driver
@@ -351,7 +391,9 @@ static int pty_common_install(struct tty
 
tty_driver_kref_get(driver);
tty->count++;
-   return 0;
+
+   return pty_register_attr(driver, tty);
+
 err_free_termios:
if (legacy)
tty_free_termios(tty);
@@ -368,6 +410,7 @@ err:
 
 static void pty_cleanup(struct tty_struct *tty)
 {
+   tty_unregister_device(tty->driver, tty->index);
kfree(tty->port);
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Drop support to compressed modules?

[Mike Frysinger]

On Friday 21 September 2012 17:41:44 Lucas De Marchi wrote:
> I'd like to ask people the following question: why are you using
> compressed modules? Is it only for the disk space or is there any
> performance related reason?

i've only seen it to save on disk space
-mike


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

Re: rcu self-detected stall messages on OMAP3, 4 boards

[Paul Walmsley]

Hi Paul

On Fri, 21 Sep 2012, Paul E. McKenney wrote:

> I am wondering if your system somehow figured out how to start a grace
> period that had no RCU callbacks waiting for it.  If that happened,
> then a CONFIG_NO_HZ=y system could in theory get into a state where all
> CPUs are in dyntick-idle mode, so that none of them is doing anything
> to force the grace period to complete.
>
> That should be easy to diagnose, anyway.  Please see below, which
> includes the earlier diagnostic patch.

Here you go.
 
- Paul

[  248.902618] INFO: rcu_sched self-detected stall on CPU
[  248.905456]  0: (1 ticks this GP) idle=933/1/0 
[  248.907897]   (t=26570 jiffies g=11 c=10 q=0)
[  248.910339] [] (unwind_backtrace+0x0/0xf0) from [] 
(rcu_check_callbacks+0x220/0x714)
[  248.915527] [] (rcu_check_callbacks+0x220/0x714) from [] 
(update_process_times+0x38/0x68)
[  248.920928] [] (update_process_times+0x38/0x68) from [] 
(tick_sched_timer+0x80/0xec)
[  248.926116] [] (tick_sched_timer+0x80/0xec) from [] 
(__run_hrtimer+0x7c/0x1e0)
[  248.930999] [] (__run_hrtimer+0x7c/0x1e0) from [] 
(hrtimer_interrupt+0x11c/0x2d0)
[  248.936035] [] (hrtimer_interrupt+0x11c/0x2d0) from [] 
(twd_handler+0x30/0x44)
[  248.940948] [] (twd_handler+0x30/0x44) from [] 
(handle_percpu_devid_irq+0x90/0x13c)
[  248.946075] [] (handle_percpu_devid_irq+0x90/0x13c) from 
[] (generic_handle_irq+0x30/0x48)
[  248.951538] [] (generic_handle_irq+0x30/0x48) from [] 
(handle_IRQ+0x4c/0xac)
[  248.956329] [] (handle_IRQ+0x4c/0xac) from [] 
(gic_handle_irq+0x28/0x5c)
[  248.960937] [] (gic_handle_irq+0x28/0x5c) from [] 
(__irq_svc+0x44/0x5c)
[  248.965484] Exception stack(0xc0729f58 to 0xc0729fa0)
[  248.968231] 9f40:   
0003b832 0001
[  248.972686] 9f60:  c074a8e8 c0728000 c07c42c8 c05065a0 c074bdc8 
 411fc092
[  248.977142] 9f80: c074bfe8  0001 c0729fa0 0003b833 c0015130 
2113 
[  248.981597] [] (__irq_svc+0x44/0x5c) from [] 
(default_idle+0x20/0x44)
[  248.986083] [] (default_idle+0x20/0x44) from [] 
(cpu_idle+0x9c/0x114)
[  248.990539] [] (cpu_idle+0x9c/0x114) from [] 
(start_kernel+0x2b4/0x304)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] USB: ohci-at91: fix PIO handling in relation with number of ports

[Joachim Eastwood]

On Wed, Aug 29, 2012 at 11:49 AM, Nicolas Ferre  wrote:
> If the number of ports present on the SoC/board is not the maximum
> and that the platform data is not filled with all data, there is
> an easy way to mess the PIO setup for this interface.
> This quick fix addresses mis-configuration in USB host platform data
> that is common in at91 boards since commit 0ee6d1e (USB: ohci-at91:
> change maximum number of ports) that did not modified the associatd
> board files.
>
> Reported-by: Klaus Falkner 
> Signed-off-by: Nicolas Ferre 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Cc: linux-...@vger.kernel.org
> Cc: Stable  [3.4+]
> ---
>  drivers/usb/host/ohci-at91.c |   10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index a665b3e..aaa8d2b 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -570,6 +570,16 @@ static int __devinit ohci_hcd_at91_drv_probe(struct 
> platform_device *pdev)
>
> if (pdata) {
> at91_for_each_port(i) {
> +   /*
> +* do not configure PIO if not in relation with
> +* real USB port on board
> +*/
> +   if (i >= pdata->ports) {
> +   pdata->vbus_pin[i] = -EINVAL;
> +   pdata->overcurrent_pin[i] = -EINVAL;
> +   break;
> +   }
> +
> if (!gpio_is_valid(pdata->vbus_pin[i]))
> continue;
> gpio = pdata->vbus_pin[i];
> --
> 1.7.10
>

Hi,

This commit causes a NULL point exception on my board with the
following message:
[7.74] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[7.81] Unable to handle kernel NULL pointer dereference at
virtual address 0028
[7.81] pgd = c3a38000
[7.81] [0028] *pgd=23a8c831, *pte=, *ppte=
[7.81] Internal error: Oops: 17 [#1] PREEMPT ARM
[7.81] Modules linked in: ohci_hcd(+) regmap_i2c snd_pcm
usbcore snd_page_alloc at91_cf snd_timer pcmcia_rsrc snd soundcore
gpio_keys regmap_spi pcmcia_core usb_common nls_base
[7.81] CPU: 0Not tainted  (3.6.0-rc6-mpa+ #264)
[7.81] PC is at __gpio_to_irq+0x18/0x40
[7.81] LR is at ohci_hcd_at91_overcurrent_irq+0x24/0xb4 [ohci_hcd]
[7.81] pc : []lr : []psr: 4093
[7.81] sp : c3a11c40  ip : c3a11c50  fp : c3a11c4c
[7.81] r10:   r9 : c02dcd6e  r8 : fefff400
[7.81] r7 :   r6 : c02cc928  r5 : 0030  r4 : c02dd168
[7.81] r3 : c02e7350  r2 : ffea  r1 : c02cc928  r0 : 
[7.81] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment user
[7.81] Control: c000717f  Table: 23a38000  DAC: 0015
[7.81] Process modprobe (pid: 285, stack limit = 0xc3a10270)
[7.81] Stack: (0xc3a11c40 to 0xc3a12000)
[7.81] 1c40: c3a11c6c c3a11c50 bf08f694 c01392cc c3a11c84
c2c38b00 c3806900 0030
[7.81] 1c60: c3a11ca4 c3a11c70 c0051264 bf08f680 c3a11cac
c3a11c80 c003e764 c3806900
[7.81] 1c80: c2c38b00 c02cb05c c02cb000 fefff400 c3806930
c3a11cf4 c3a11cbc c3a11ca8
[7.81] 1ca0: c005142c c005123c c3806900 c3805a00 c3a11cd4
c3a11cc0 c0053f24 c00513e4
[7.81] 1cc0: c3a11cf4 0030 c3a11cec c3a11cd8 c005120c
c0053e88  
[7.81] 1ce0: c3a11d1c c3a11cf0 c00124d0 c00511e0 0140
0001 0012 
[7.81] 1d00:  c3a11d94 0030  c3a11d34
c3a11d20 c005120c c0012438
[7.81] 1d20: c001dac4 0012 c3a11d4c c3a11d38 c0009b08
c00511e0 c00523fc 6013
[7.81] 1d40: c3a11d5c c3a11d50 c0008510 c0009ab4 c3a11ddc
c3a11d60 c0008eb4 c00084f0
[7.81] 1d60:  0030  0080 6013
bf08f670 c3806900 c2c38b00
[7.81] 1d80: 0030 c3806930  c3a11ddc c3a11d88
c3a11da8 c0054190 c00523fc
[7.81] 1da0: 6013  c3a11dec c3a11db8 
c2c38b00 bf08f670 c3806900
[7.81] 1dc0:  0080 c02cc928 0030 c3a11e0c
c3a11de0 c0052764 c00520d8
[7.81] 1de0: c3a11dfc   0002 bf090f61
0004 c02cc930 c02cc928
[7.81] 1e00: c3a11e4c c3a11e10 bf090978 c005269c bf090f61
c02cc928 bf093000 c02dd170
[7.81] 1e20: c3a11e3c c02cc930 c02cc930 bf0911d0 bf0911d0
bf093000 c3a1 
[7.81] 1e40: c3a11e5c c3a11e50 c0155b7c bf090808 c3a11e7c
c3a11e60 c0154690 c0155b6c
[7.81] 1e60: c02cc930 c02cc964 bf0911d0 c3a11ea0 c3a11e9c
c3a11e80 c015484c c01545e8
[7.81] 1e80:   c01547e4 bf0911d0 c3a11ec4
c3a11ea0 c0152e58 c01547f4
[7.81] 1ea0: c381b88c c384ab10 c2c10540 bf0911d0 
c02d7518 c3a11ed4 c3a11ec8
[7.81] 1ec0: c01544c0 c0152e0c c3a11efc c3a11ed8 c01536cc
c01544b0 bf0910

Re: sys_kcmp (was: Re: [PATCH 1/2] ARM: add finit_module syscall to ARM)

[Andrew Morton]

On Sat, 22 Sep 2012 14:20:46 +0100 Russell King  wrote:

> On Sat, Sep 22, 2012 at 03:45:49PM +0400, Cyrill Gorcunov wrote:
> > On Sat, Sep 22, 2012 at 12:56:42PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Sep 21, 2012 at 6:51 PM, Russell King  
> > > wrote:
> > > > That brings up another question though - when was kcmp added to x86, and
> > > > why aren't we getting notifications from checksyscalls.sh that ARM 
> > > > hasn't
> > > > been updated?
> > > >
> > > > It seems to be that the script was broken, and no one has noticed.
> > > 
> > > It seems Heiko did notice: http://www.serverphorums.com/read.php?12,559093
> > > 
> > > Now, I'm a bit puzzled by what follows: Heiko proposes a patch to
> > > ignore sys_kcmp,
> > > as it's x86-specific, which is acked by Cyrill. Then it suddenly
> > 
> > hpa@ pointed that better approach is to implement kcmp on other archs
> > after i've acked the patch. so then Heiko provided a patch for s390.
> 
> I discussed with hpa yesterday, and it seems the situation is as follows:
> 
> 1. There exists a patch to fix checksyscalls.sh, and it's allegedly sitting
>in akpm's tree, and no one knows why it's just sitting there and hasn't
>been merged upstream.

People sometimes just reply to my commit emails, ignoring the
reply-to:lkml and the "Before you just go and hit reply" request.  I could
start cc'ing the lists like tip-bot, but that seems a bit noisy.

> 2. There allegedly exists a patch to remove x86isms from sys_kcmp -
>allegedly also in akpm's tree.  However, I've looked through the code in
>mainline, and nothing stands out.  Ralf Beachle also said yesterday that
>he has looked through from the MIPS PoV and also can't see any x86isms,
>so we're both thinking that it should merely have the x86 dependency
>removed.

http://ozlabs.org/~akpm/mmotm/broken-out/syscalls-make-kcmp-syscall-available-for-all-architectures.patch

I have that queued for 3.7.  There is of course a little risk here.  We
do have a test in tools/testing/selftests/kcmp/ - I suggest that arch
people run it!  In fact all the tools/testing/selftests should execute
successfully on all architectures - if not, please let's fix things
up.

> 3. Until the x86 dependency is gone (that depends on what akpm proposes to
>do with the patches he's allegedly sitting on), non-x86 arches can only
>reserve the syscall, and add an IGNORE for it.
> 
> Maybe akpm can provide some input to this thread, and let us know what the
> intentions are for checksyscalls.sh and kernel/kcmp.c, and whether he does
> indeed have outstanding patches for these.
> 
> It would be good to at least get checksyscalls.sh fixed so arch maintainers
> get their warnings for new syscalls back.

http://ozlabs.org/~akpm/mmotm/broken-out/checksyscalls-fix-here-document-handling.patch

I had it queued for 3.7.  I now see that was a mistake and I'll get it
into 3.6.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rcu self-detected stall messages on OMAP3, 4 boards

[Paul Walmsley]

On Fri, 21 Sep 2012, Paul E. McKenney wrote:

> Could you please point me to a recipe for creating a minimal userspace?
> Just in case it is the userspac erather than the architecture/hardware
> that makes the difference.

Tony's suggestion is pretty good.  Note that there may also be differences 
in kernel timers -- either between x86 and ARM architectures, or loaded 
device drivers -- that may confound the problem.

> Just to make sure I understand the combinations:
> 
> o All stalls have happened when running a minimal userspace.
> o CONFIG_NO_HZ=n suppresses the stalls.
> o CONFIG_RCU_FAST_NO_HZ (which depends on CONFIG_NO_HZ=y) has
>   no observable effect on the stalls.
> 
> Did I get that right, or am I missing a combination?

That's correct.

> Indeed, rcu_idle_gp_timer_func() is a bit strange in that it is 
> cancelled upon exit from idle, and therefore should (almost) never 
> actually execute. Its sole purpose is to wake up the CPU.  ;-)

Right.  Just curious, what would wake up the kernel from idle to handle a 
grace period expiration when CONFIG_RCU_FAST_NO_HZ=n?  On a very idle 
system, the time between timer ticks could potentially be several tens of 
seconds.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 resend] spi core: Provide means to instantiate devices through sysfs

[Guenter Roeck]

On Sat, Sep 22, 2012 at 12:11:33PM -0400, Mark Brown wrote:
> On Mon, Sep 17, 2012 at 04:51:20PM -0700, Guenter Roeck wrote:
> > The I2C core provides a means to instantiate devices from userspace
> > using sysfs attributes. Provide the same mechanism for SPI devices.
> 
> So, unlike I2C this is only going to work for a subset of controllers -
> anything that relies on GPIOs for chip select will need more data to add
> the chip selects for example.  This means I'm having a hard time getting
> enthused about the idea, it seems like it might be a support burden.
> 
Yes, obviously that model can not be used if SPI chip select is handled outside
the SPI master driver.

Anyway, no problem. That the code is useful for me doesn't mean it has to be
useful for others. I'll make it available as branch on my linux tree on github.

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

Re: Linux 3.6-rc6

[Linus Torvalds]

On Fri, Sep 21, 2012 at 5:59 PM, Shaun Ruffell  wrote:
>
> I posted patches [1,2,3] that resolve the issue for me. Shaohui Xie
> also hit the issue and posted a slightly different patch [4]. The
> patches are currently waiting for Mauro, who I understand is
> catching up since returning from San Diego, to check them out.
>
> [1] http://marc.info/?l=linux-kernel&m=134764595921752&w=2
> [2] http://marc.info/?l=linux-kernel&m=134764594721747&w=2
> [3] http://marc.info/?l=linux-kernel&m=134764597921761&w=2
> [4] http://marc.info/?l=linux-kernel&m=134753579818528&w=2

That first patch needs a sign-off from you, since you are passing on
somebody elses patch.

Looking at that patch, the patch seems to be a memory leak (?) leaking
the "channels" allocation, along with fixing an odd and incorrect
kfree (and access) of mci->csrows[i]. If that is correct, please write
a proper changelog. The current changelog for that thing is totally
pointless, and doesn't actually explain what the patch *does*.

I'd also like some ack's from people, and I'd love to know which
commit introduced the problem(s). If this problem is new to 3.6, I
want to know what caused it, and if it is *not* new, then the thing
needs to be marked for stable. Please?

Finally, if I'm supposed to apply patches, I really *really* want to
see the patches sent to me explicitly, instead of having people post
pointers to them on the web. I don't apply random stuff on the web, I
want the "please take this patch" to be a case of people *explicitly*
sending it to me with the proper sign-offs in place etc.

IOW, the "hey, you should apply that random patch that wasn't even
sent to you" approach is not something I accept.

   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: [PATCH] rds: Error on offset mismatch if not loopback

[David Miller]

From: John Jolly 
Date: Fri, 21 Sep 2012 15:32:40 -0600

> Attempting an rds connection from the IP address of an IPoIB interface
> to itself causes a kernel panic due to a BUG_ON() being triggered.
> Making the test less strict allows rds-ping to work without crashing
> the machine.
> 
> A local unprivileged user could use this flaw to crash the system.
> 
> Signed-off-by: John Jolly 

Besides the questions being asked of you by Venkat Venkatsubra, this
patch has another issue.

It has been completely corrupted by your email client, it has
turned all TAB characters into spaces, making the patch useless.

Please learn how to send a patch unmolested in the body of your
email.  Test it by emailing the patch to yourself, and verifying
that you can in fact apply the patch you receive in that email.
Then, and only then, should you consider making a new submission
of this patch.

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

Re: [PATCH] net/phy/bcm87xx: Add MODULE_LICENSE("GPL") to GPL driver

[David Miller]

From: Peter Huewe 
Date: Sat, 22 Sep 2012 04:44:18 +0200

> Currently the driver has no MODULE_LICENSE attribute in its source which
> results in a kernel taint if I load this:
> 
> root@(none):~# modprobe bcm87xx
> bcm87xx: module license 'unspecified' taints kernel.
> 
> Since the first lines of the source code clearly state:
>  * This file is subject to the terms and conditions of the GNU General
>  * Public License.  See the file "COPYING" in the main directory of this
>  * archive for more details.
> I think it's safe to add the MODULE_LICENSE("GPL") macro and thus remove
> the kernel taint.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Peter Huewe 

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

Re: pull request: wireless 2012-09-22

[David Miller]

From: "John W. Linville" 
Date: Sat, 22 Sep 2012 13:13:42 -0400

> Please pull this last(?) batch of fixes intended for 3.6...
> 
> For the Bluetooth bits, Gustavo says this:
> 
> "Here goes probably my last update to 3.6. It includes the two patches
> you were ok last week(from Andrzej Kaczmarek), those are critical
> ones, and two other fixes one for a system crash and the other for
> a missing lockdep annotation."
> 
> The referenced fixes from Andrzej prevent attempts to configure devices
> that are powered-off.
> 
> Along with the Bluetooth fixes, there are a couple of 802.11 fixes.
> Emmanuel Grumbach gives us an iwlwifi fix to prevent releasing an
> interrupt twice.  Luis R. Rodriguez provides a fix for a possible
> circular lock dependency in the cfg80211 regulatory enforcement code.
> 
> All of these have been in linux-next for a few days.  I hope they are
> not too late to make the 3.6 release!

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

Re: [PATCH] pppoe: drop PPPOX_ZOMBIEs in pppoe_release

[David Miller]

From: Xiaodong Xu 
Date: Sat, 22 Sep 2012 18:09:32 +0800

> From: Xiaodong Xu 
> 
> When PPPOE is running over a virtual ethernet interface (e.g., a
> bonding interface) and the user tries to delete the interface in case
> the PPPOE state is ZOMBIE, the kernel will loop forever while
> unregistering net_device for the reference count is not decreased to
> zero which should have been done with dev_put().
> 
> Signed-off-by: Xiaodong Xu 

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

Re: [PATCH net-next v1] net: use a per task frag allocator

[David Miller]

From: Eric Dumazet 
Date: Fri, 21 Sep 2012 23:11:11 +0200

> On Fri, 2012-09-21 at 13:27 -0700, Vijay Subramanian wrote:
>> I get the following compile error with the newer version of the patch
>> 
>> net/sched/em_meta.c: In function ‘meta_int_sk_sendmsg_off’:
>> net/sched/em_meta.c:464: error: ‘struct sock’ has no member named
>> ‘sk_sndmsg_off’
>> make[1]: *** [net/sched/em_meta.o] Error 1
>> make: *** [net/sched/em_meta.o] Error 2
>> 
>> 
>> 
>> Vijay
> 
> Oh well, I wonder what's the expected use of this crap...
> 
> Thanks, I'll fix this on v3 !

So many aspects of the meta match are an extreme burdon on development
because the keys it allows unnecessarily exposes internals of our
implementation.

Who really uses it?  Maybe we can schedule it for removal.

Re: Tracking down suspend/resume ext3/mmc issues on imx233

[Pavel Machek]

Hi!

On Wed 2012-09-19 20:01:10, Theodore Ts'o wrote:
> On Thu, Sep 20, 2012 at 01:23:49AM +0200, Pavel Machek wrote:
> > 
> > I'm not sure I agree.
> > 
> > If you treat root fs as removable, you'll get "crash". You'll need to
> > replay the journal, but data is safe.
> > 
> > If you treat it as non-removable, and someone manages to remove it,
> > mount, and reinsert, you'll get silent data corruption.
> 
> We could detect this case; if the file system gets mounted, the last
> mount time will change.  So one of the things we could do is have the
> file system code freeze the file system at suspend time, so the file
> system is consistent (which will reduce the probability of data loss
> if the system never comes back up after the suspend), and save the
> last mount time and last write time in memory.  When the system comes
> back from resume, have the file system code check the last mount and
> last write time, and if they have changed, it can refuse the resume
> and abort the system to avoid data corruption.  It would require
> making ext3/ext4 suspend-aware, but it would be doable, if we really
> wanted to support this.

Yes please; I'd love to see this done.

We used to do sync() to get filesystem in consistent state, and I
believe that these days we are doing filesystem freeze; but code
validating the last mount time is certainly missing.

Looking forward,
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-next: build failure after merge of the final tree (net-next tree related)

[David Miller]

From: Benjamin Herrenschmidt 
Date: Sat, 22 Sep 2012 07:46:40 +1000

> Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all
> of memory is ZONE_DMA). It's always been like that afaik.
> 
> We could support ISA device limited addressability using the iommu but
> that would involve a map/unmap type API (which I remember we did support
> in the old days by passing NULL to pci_map_*, but we dropped that along
> the way).

I think I'm going to just end up restricting this driver to X86
as was originally suggested.

There seems to be no real consistent Kconfig protection for users
of isa_virt_to_bus() and friends.

We know that ISA_DMA_API doesn't do it, and ISA doesn't do it either
as powerpc also allows that to bet set for CHRP and friends.

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: [Intel-gfx] [PATCH] console: implement lockdep support for console_lock

[Greg KH]

On Sat, Sep 22, 2012 at 07:52:11PM +0200, Daniel Vetter wrote:
> Dave Airlie recently discovered a locking bug in the fbcon layer,
> where a timer_del_sync (for the blinking cursor) deadlocks with the
> timer itself, since both (want to) hold the console_lock:
> 
> https://lkml.org/lkml/2012/8/21/36
> 
> Unfortunately the console_lock isn't a plain mutex and hence has no
> lockdep support. Which resulted in a few days wasted of tracking down
> this bug (complicated by the fact that printk doesn't show anything
> when the console is locked) instead of noticing the bug much earlier
> with the lockdep splat.
> 
> Hence I've figured I need to fix that for the next deadlock involving
> console_lock - and with kms/drm growing ever more complex locking
> that'll eventually happen.
> 
> Now the console_lock has rather funky semantics, so after a quick irc
> discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
> the original idead of switching to a real mutex (since it won't work)
> and instead opted to annotate the console_lock with lockdep
> information manually.
> 
> There are a few special cases:
> - The console_lock state is protected by the console_sem, and usually
>   grabbed/dropped at _lock/_unlock time. But the suspend/resume code
>   drops the semaphore without dropping the console_lock (see
>   suspend_console/resume_console). But since the same thread that did
>   the suspend will do the resume, we don't need to fix up anything.
> 
> - In the printk code there's a special trylock, only used to kick off
>   the logbuffer printk'ing in console_unlock. But all that happens
>   while lockdep is disable (since printk does a few other evil
>   tricks). So no issue there, either.
> 
> - The console_lock can also be acquired form irq context (but only
>   with a trylock). lockdep already handles that.
> 
> This all leaves us with annotating the normal console_lock, _unlock
> and _trylock functions.
> 
> And yes, it works - simply unloading a drm kms driver resulted in
> lockdep complaining about the deadlock in fbcon_deinit:
> 
> ==
> [ INFO: possible circular locking dependency detected ]
> 3.6.0-rc2+ #552 Not tainted
> ---
> kms-reload/3577 is trying to acquire lock:
>  ((&info->queue)){+.+...}, at: [] wait_on_work+0x0/0xa7
> 
> but task is already holding lock:
>  (console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263
> 
> which lock already depends on the new lock.
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (console_lock){+.+.+.}:
>[] lock_acquire+0x95/0x105
>[] console_lock+0x59/0x5b
>[] fb_flashcursor+0x2e/0x12c
>[] process_one_work+0x1d9/0x3b4
>[] worker_thread+0x1a7/0x24b
>[] kthread+0x7f/0x87
>[] kernel_thread_helper+0x4/0x10
> 
> -> #0 ((&info->queue)){+.+...}:
>[] __lock_acquire+0x999/0xcf6
>[] lock_acquire+0x95/0x105
>[] wait_on_work+0x3b/0xa7
>[] __cancel_work_timer+0xbf/0x102
>[] cancel_work_sync+0xb/0xd
>[] fbcon_deinit+0x11c/0x1dc
>[] bind_con_driver+0x145/0x263
>[] unbind_con_driver+0x14f/0x195
>[] store_bind+0x1ad/0x1c1
>[] dev_attr_store+0x13/0x1f
>[] sysfs_write_file+0xe9/0x121
>[] vfs_write+0x9b/0xfd
>[] sys_write+0x3e/0x6b
>[] system_call_fastpath+0x16/0x1b
> 
> other info that might help us debug this:
> 
>  Possible unsafe locking scenario:
> 
>CPU0CPU1
>
>   lock(console_lock);
>lock((&info->queue));
>lock(console_lock);
>   lock((&info->queue));
> 
>  *** DEADLOCK ***
> 
> v2: Mark the lockdep_map static, noticed by Jani Nikula.
> 
> Cc: Dave Airlie 
> Cc: Thomas Gleixner 
> Cc: Alan Cox 
> Cc: Peter Zijlstra 
> Signed-off-by: Daniel Vetter 
> ---
>  kernel/printk.c |9 +
>  1 file changed, 9 insertions(+)

So I'm guessing I should take this through the tty tree, right?  Any
objections to that for 3.7?

thanks,

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

Re: [RFC] tty: Add get- ioctls to fetch tty status

[Greg Kroah-Hartman]

On Sat, Sep 22, 2012 at 10:06:39PM +0400, Cyrill Gorcunov wrote:
> On Thu, Sep 13, 2012 at 05:25:07PM +0100, Alan Cox wrote:
> > On Thu, 13 Sep 2012 16:54:01 +0400
> > Cyrill Gorcunov  wrote:
> > 
> > > On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > > > +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> > > > > +{
> > > > > + int locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> > > > > + if (put_user(locked, arg))
> > > > > + return -EFAULT;
> > > > 
> > > > Now explain exactly how this doesn't race with another thread chanigng
> > > > the lock setting ?
> > > 
> > > It's the same as to set/clear this bit, isn't it? Please correct me
> > > if I'm wrong.
> > 
> > So by the time you've finished the test bit and returned it to user space
> > the answer may have changed ?
> > 
> > > > The other comment I have is that it might be better put these in now
> > > > there are sysfs patches for the tty layer bouncing about to provide the
> > > > needed infrastructure ?
> > > 
> > > Alan, could you please point me where these patches are living, so I would
> > > take a look and check them out
> > 
> > linux-serial or check tty-next as I think Greg has now merged the test
> > patch.
> 
> Guys, you mean something like below? Look, I must admit I'm not really
> sure if I've done all locking right, and there is no need for additional
> kref counting on tty_struct. Could you please check if it looks more-less
> sane (I've tested it but still...)
> 
> ---
> From: Cyrill Gorcunov 
> Subject: tty, pty: Add pty_state attribute to fetch tty flags
> 
> For checkpoint/restore we need to know if tty has
> exclusive or packet mode set, as well as if pty
> is currently locked (just to be able to restore
> this characteristics).
> 
> To serve this the pty_state attribute is introduced
> for pty devices. A typical output looks like
> 
>  | [root@neptune ~]# cat /sys/devices/virtual/tty/ptmp0/pty_state
>  | locked: 0 exclusive: 0 packet: 0
> 
> Signed-off-by: Cyrill Gorcunov 
> CC: Alan Cox 
> CC: Greg Kroah-Hartman 
> CC: "H. Peter Anvin" 
> CC: Jiri Slaby 
> CC: Pavel Emelyanov 
> ---
>  drivers/tty/pty.c |   45 -
>  1 file changed, 44 insertions(+), 1 deletion(-)
> 
> Index: tty.git/drivers/tty/pty.c
> ===
> --- tty.git.orig/drivers/tty/pty.c
> +++ tty.git/drivers/tty/pty.c
> @@ -283,6 +283,46 @@ done:
>   return 0;
>  }
>  
> +static ssize_t pty_show_state(struct device *dev,
> +   struct device_attribute *attr,
> +   char *buf)
> +{
> + struct tty_struct *tty = dev_get_drvdata(dev);
> + int locked, exclusive, packet;
> +
> + tty_lock(tty);
> + locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> + exclusive = test_bit(TTY_EXCLUSIVE, &tty->flags);
> + packet = tty->packet;
> + tty_unlock(tty);
> +
> + return snprintf(buf, PAGE_SIZE, "locked: %d exclusive: %d packet: %d\n",
> + locked, exclusive, packet);
> +}

Sysfs is one value per file, you have three values here, please make 3
files.

And document them in Documentation/ABI/.

thanks,

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

Re: rcu self-detected stall messages on OMAP3, 4 boards

[Paul E. McKenney]

On Sat, Sep 22, 2012 at 06:42:08PM +, Paul Walmsley wrote:
> On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> 
> > Could you please point me to a recipe for creating a minimal userspace?
> > Just in case it is the userspac erather than the architecture/hardware
> > that makes the difference.
> 
> Tony's suggestion is pretty good.  Note that there may also be differences 
> in kernel timers -- either between x86 and ARM architectures, or loaded 
> device drivers -- that may confound the problem.

For example, there must be at least one RCU callback outstanding after
the boot sequence quiets down.  Of course, the last time I tried Tony's
approach, I was doing it on top of my -rcu stack, so am retrying on
v3.6-rc6.

> > Just to make sure I understand the combinations:
> > 
> > o   All stalls have happened when running a minimal userspace.
> > o   CONFIG_NO_HZ=n suppresses the stalls.
> > o   CONFIG_RCU_FAST_NO_HZ (which depends on CONFIG_NO_HZ=y) has
> > no observable effect on the stalls.
> > 
> > Did I get that right, or am I missing a combination?
> 
> That's correct.
> 
> > Indeed, rcu_idle_gp_timer_func() is a bit strange in that it is 
> > cancelled upon exit from idle, and therefore should (almost) never 
> > actually execute. Its sole purpose is to wake up the CPU.  ;-)
> 
> Right.  Just curious, what would wake up the kernel from idle to handle a 
> grace period expiration when CONFIG_RCU_FAST_NO_HZ=n?  On a very idle 
> system, the time between timer ticks could potentially be several tens of 
> seconds.

If CONFIG_RCU_FAST_NO_HZ=n, then CPUs with RCU callbacks are not permitted
to shut off the scheduling-clock tick, so any CPU with RCU callbacks will
be awakened every jiffy.  The problem is that there appears to be a way
to get an RCU grace period started without any CPU having any callbacks,
which, as you surmise, would result in all the CPUs going to sleep and
the grace period never ending.  So if a CPU is awakened for any reason
after this everlasting grace period has extended for more than a minute,
the first thing that CPU will do is print an RCU CPU stall warning.

I believe that I see how to prevent callback-free grace periods from
ever starting.  (Famous last words...)

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: Add get- ioctls to fetch tty status

[Cyrill Gorcunov]

On Sat, Sep 22, 2012 at 01:07:31PM -0700, Greg Kroah-Hartman wrote:
> >  drivers/tty/pty.c |   45 -
> >  1 file changed, 44 insertions(+), 1 deletion(-)
> > 
> > Index: tty.git/drivers/tty/pty.c
> > ===
> > --- tty.git.orig/drivers/tty/pty.c
> > +++ tty.git/drivers/tty/pty.c
> > @@ -283,6 +283,46 @@ done:
> > return 0;
> >  }
> >  
> > +static ssize_t pty_show_state(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > +   struct tty_struct *tty = dev_get_drvdata(dev);
> > +   int locked, exclusive, packet;
> > +
> > +   tty_lock(tty);
> > +   locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> > +   exclusive = test_bit(TTY_EXCLUSIVE, &tty->flags);
> > +   packet = tty->packet;
> > +   tty_unlock(tty);
> > +
> > +   return snprintf(buf, PAGE_SIZE, "locked: %d exclusive: %d packet: %d\n",
> > +   locked, exclusive, packet);
> > +}
> 
> Sysfs is one value per file, you have three values here, please make 3
> files.
> 
> And document them in Documentation/ABI/.

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

Re: [patch net] sky2: fix rx filter setup on link up

[Stephen Hemminger]

On Mon, 17 Sep 2012 17:10:17 +0200
Jiri Pirko  wrote:

> + sky2_write_rx_filter(sky2, filter);
> + memcpy(sky2->rx_filter, filter, sizeof(sky2->rx_filter));

This isn't safe since rx_filter might be referred to from interrupt
context (ie link up PHY interrupt). Maybe using atomic64 would be
best.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

blk: NULL ptr deref in blk_dequeue_request()

[Sasha Levin]

Hi all,

While fuzzing with trinity inside a KVM tools guest running the latest 
linux-next kernel, I've stumbled on the following BUG.

I've also hit a similar trace where the 'BUG_ON(ELV_ON_HASH(rq));' above that 
list_del_init() gets hit, so I guess it's a race
condition of some sorts.


[9.900299] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[9.909508] IP: [] __list_del_entry+0xb7/0xe0
[9.910191] PGD 0
[9.910191] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[9.910191] Dumping ftrace buffer:
[9.910191](ftrace buffer empty)
[9.910191] CPU 2
[9.910191] Pid: 3996, comm: kworker/u:2 Tainted: GW
3.6.0-rc6-next-20120921-sasha-1-geb77a39-dirty #3
[9.910191] RIP: 0010:[]  [] 
__list_del_entry+0xb7/0xe0
[9.910191] RSP: :880034e11c88  EFLAGS: 00010007
[9.910191] RAX:  RBX: 880034e3ec00 RCX: dead00200200
[9.910191] RDX:  RSI: 85366998 RDI: 880034e3ec00
[9.910191] RBP: 880034e11c88 R08:  R09: 88001af60928
[9.910191] R10:  R11: 0001 R12: 
[9.910191] R13: 85366360 R14:  R15: 85b4edd0
[9.910191] FS:  () GS:88002980() 
knlGS:
[9.910191] CS:  0010 DS:  ES:  CR0: 80050033
[9.910191] CR2:  CR3: 04c26000 CR4: 000406e0
[9.910191] DR0:  DR1:  DR2: 
[9.910191] DR3:  DR6: 0ff0 DR7: 0400
[9.910191] Process kworker/u:2 (pid: 3996, threadinfo 880034e1, 
task 88001af6)
[9.910191] Stack:
[9.910191]  880034e11ca8 819a1a45 880034e3ec00 

[9.910191]  880034e11cc8 819a1ae1  
880034e3ec00
[9.910191]  880034e11ce8 819a271e  

[9.910191] Call Trace:
[9.910191]  [] blk_dequeue_request+0x35/0xc0
[9.910191]  [] blk_start_request+0x11/0x40
[9.910191]  [] blk_fetch_request+0x1e/0x30
[9.910191]  [] redo_fd_request+0x9d/0x3f0
[9.910191]  [] process_one_work+0x3b9/0x770
[9.910191]  [] ? process_one_work+0x268/0x770
[9.910191]  [] ? get_lock_stats+0x22/0x70
[9.910191]  [] ? start_motor+0x120/0x120
[9.910191]  [] worker_thread+0x2ba/0x3f0
[9.910191]  [] ? rescuer_thread+0x2d0/0x2d0
[9.910191]  [] kthread+0xe3/0xf0
[9.910191]  [] ? put_lock_stats.isra.16+0xe/0x40
[9.910191]  [] ? insert_kthread_work+0x90/0x90
[9.910191]  [] kernel_thread_helper+0x5/0x10
[9.910191]  [] ? insert_kthread_work+0x90/0x90
[9.910191] Code: 6a 84 be 3e 00 00 00 48 c7 c7 7b d8 6a 84 31 c0 e8 8f c2 
71 ff eb 2c 0f 1f 44 00 00 48 b9 00 02 20 00 00 00
ad de 48 39 c8 74 8c <4c> 8b 00 4c 39 c7 75 a6 4c 8b 42 08 4c 39 c7 75 bc 48 89 
42 08
[9.910191] RIP  [] __list_del_entry+0xb7/0xe0
[9.910191]  RSP 
[9.910191] CR2: 


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rcu self-detected stall messages on OMAP3, 4 boards

[Paul E. McKenney]

On Sat, Sep 22, 2012 at 06:16:15PM +, Paul Walmsley wrote:
> Hi Paul
> 
> On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> 
> > I am wondering if your system somehow figured out how to start a grace
> > period that had no RCU callbacks waiting for it.  If that happened,
> > then a CONFIG_NO_HZ=y system could in theory get into a state where all
> > CPUs are in dyntick-idle mode, so that none of them is doing anything
> > to force the grace period to complete.
> >
> > That should be easy to diagnose, anyway.  Please see below, which
> > includes the earlier diagnostic patch.
> 
> Here you go.
> 
> - Paul
> 
> [  248.902618] INFO: rcu_sched self-detected stall on CPU
> [  248.905456]  0: (1 ticks this GP) idle=933/1/0 
> [  248.907897]   (t=26570 jiffies g=11 c=10 q=0)

Bingo!!!  (q=0, in case you were wondering.  And thank you for testing this!)

Strangely enough, I believe that I have inadvertently fixed this in
my -rcu tree:

git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next

Nevertheless, if you get a chance to try it, I would be interested to
hear if my guess is correct.  The trick is that a kthread drives the
grace period in -rcu, regardless of whether or not there are callbacks.

However, the backport would not be something that -stable would be happy
with, so I will be putting together a fix for mainline.  This thing
has been in the kernel since about 2004, not sure why you didn't hit
it earlier.

Thanx, Paul

> [  248.910339] [] (unwind_backtrace+0x0/0xf0) from [] 
> (rcu_check_callbacks+0x220/0x714)
> [  248.915527] [] (rcu_check_callbacks+0x220/0x714) from 
> [] (update_process_times+0x38/0x68)
> [  248.920928] [] (update_process_times+0x38/0x68) from 
> [] (tick_sched_timer+0x80/0xec)
> [  248.926116] [] (tick_sched_timer+0x80/0xec) from [] 
> (__run_hrtimer+0x7c/0x1e0)
> [  248.930999] [] (__run_hrtimer+0x7c/0x1e0) from [] 
> (hrtimer_interrupt+0x11c/0x2d0)
> [  248.936035] [] (hrtimer_interrupt+0x11c/0x2d0) from [] 
> (twd_handler+0x30/0x44)
> [  248.940948] [] (twd_handler+0x30/0x44) from [] 
> (handle_percpu_devid_irq+0x90/0x13c)
> [  248.946075] [] (handle_percpu_devid_irq+0x90/0x13c) from 
> [] (generic_handle_irq+0x30/0x48)
> [  248.951538] [] (generic_handle_irq+0x30/0x48) from [] 
> (handle_IRQ+0x4c/0xac)
> [  248.956329] [] (handle_IRQ+0x4c/0xac) from [] 
> (gic_handle_irq+0x28/0x5c)
> [  248.960937] [] (gic_handle_irq+0x28/0x5c) from [] 
> (__irq_svc+0x44/0x5c)
> [  248.965484] Exception stack(0xc0729f58 to 0xc0729fa0)
> [  248.968231] 9f40:   
> 0003b832 0001
> [  248.972686] 9f60:  c074a8e8 c0728000 c07c42c8 c05065a0 c074bdc8 
>  411fc092
> [  248.977142] 9f80: c074bfe8  0001 c0729fa0 0003b833 c0015130 
> 2113 
> [  248.981597] [] (__irq_svc+0x44/0x5c) from [] 
> (default_idle+0x20/0x44)
> [  248.986083] [] (default_idle+0x20/0x44) from [] 
> (cpu_idle+0x9c/0x114)
> [  248.990539] [] (cpu_idle+0x9c/0x114) from [] 
> (start_kernel+0x2b4/0x304)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] HID: Fix missing Unifying device issue

[Jiri Kosina]

On Sat, 22 Sep 2012, Jiri Kosina wrote:

> > This patch fixes an issue introduced after commit 4ea5454203d991ec
> > 
> > After that commit, hid-core silently discards any incoming packet
> > that arrives while any hid driver's probe function is being executed.
> > 
> > This broke the enumeration process of hid-logitech-dj, that must
> > receive control packets in-band with the mouse and keyboard
> > packets. Discarding mouse or keyboard data at the very begining is
> > usually fine, but it is not the case for control packets.
> > 
> > This patch forces a re-enumeration of the paired devices when a packet
> > arrives that comes from an unknown device.
> > 
> > Based on a patch originally written by Benjamin Tissoires.
> > 
> > Signed-off-by: Nestor Lopez Casado 
> 
> I am now applying it, will be pushing to Linus very soon

Now in Linus' tree and marked for stable.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: add support for zsmalloc and zcache

[Dan Magenheimer]

> From: Mel Gorman [mailto:mgor...@suse.de]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
> 
> On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote:
> > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> > > Subject: Re: [RFC] mm: add support for zsmalloc and zcache
> > The two proposals:
> > A) Recreate all the work done for zcache2 as a proper sequence of
> >independent patches and apply them to zcache1. (Seth/Konrad)
> > B) Add zsmalloc back in to zcache2 as an alternative allocator
> >for frontswap pages. (Dan)
> 
> Throwing it out there but 
> 
> C) Merge both, but freeze zcache1 except for critical fixes. Only allow
>future work on zcache2. Document limitations of zcache1 and
>workarounds until zcache2 is fully production ready.

Hi Mel (with request for Seth below) --

(C) may be the politically-expedient solution but, personally,
I think it is a bit insane and I suspect that any mm developer
who were to deeply review both codebases side-by-side would come to
the same conclusion.  The cost in developer/maintainer time,
and the confusion presented to the user/distro base if both
are promoted/merged would be way too high, and IMHO completely
unwarranted.  Let me try to explain...

I use the terms "zcache1" and "zcache2" only to clarify which
codebase, not because they are dramatically different. I estimate
that 85%-90% of the code in zcache1 and zcache2 is identical, not
counting the allocator or comments/whitespace/janitorial!

Zcache2 _is_ zcache1 with some good stuff added and with zsmalloc
dropped.  I think after careful study, there would be wide agreement
among mm developers that the stuff added is all moving in the direction
of making zcache "production-ready".  IMHO, zcache1 has _never_
been production-ready, and zcache2 is merely a big step in the right
direction.

(Quick logistical aside: zcache2 is in staging-next and linux-next,
currently housed under the drivers/staging/ramster directory...
with !CONFIG_RAMSTER, ramster _is_ zcache2.)

Seth (and IBM) seems to have a bee in his bonnet that the existing
zcache1 code _must_ be promoted _soon_ with as little change as possible.
Other than the fact that he didn't like my patching approach [1],
the only technical objection Seth has raised to zcache2 is that he
thinks zsmalloc is the best choice of allocator [2] for his limited
benchmarking [3].

I've offered to put zsmalloc back in to zcache2 as an optional
(even default) allocator, but that doesn't seem to be good enough
for Seth.  Any other technical objections to zcache2, or explanation
for his urgent desire to promote zcache1, Seth (and IBM) is keeping
close to his vest, which I find to be a bit disingenuous.

So, I'd like to challenge Seth with a simple question:

If zcache2 offers zsmalloc as an alternative (even default) allocator,
what remaining _technical_ objections do you (Seth) have to merging
zcache2 _instead_ of zcache1?

If Mel agrees that your objections are worth the costs of bifurcating
zcache and will still endorse merging both into core mm, I agree to move
forward with Mel's alternative (C) (and will then repost
https://lkml.org/lkml/2012/7/31/573).

Personally, I would _really_ like to get back to writing code to make
zcacheN more suitable for production so would really like to see this
resolved!

Dan

[1] Monolithic, because GregKH seemed to be unwilling to take further
patches to zcache before it was promoted, and because I thought
a number of things had to be fixed before I would feel comfortable
presenting zcache to be reviewed by mm developers
[2] Note, zsmalloc is used in zcache1 only for frontswap pages...
zbud is used in both zcache1 and zcache2 for cleancache pages.
[3] I've never seen any benchmark results posted for zcache other
than some variation of kernbench.  IMHO that's an issue all in itself.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the final tree (net-next tree related)

[Benjamin Herrenschmidt]

On Sat, 2012-09-22 at 16:00 -0400, David Miller wrote:
> 
> I think I'm going to just end up restricting this driver to X86
> as was originally suggested.

Probably the easiest fix indeed.

> There seems to be no real consistent Kconfig protection for users
> of isa_virt_to_bus() and friends.
> 
> We know that ISA_DMA_API doesn't do it, and ISA doesn't do it either
> as powerpc also allows that to bet set for CHRP and friends.

It's a old mess :-( And not an easy one to untangle...

Cheers,
Ben.


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