Re: e1000_netpoll(): disable_irq() triggers might_sleep() on linux-next

Hello, sorry for the delay. 2014-10-29, 20:36:03 +0100, Peter Zijlstra wrote: > On Wed, Oct 29, 2014 at 07:33:00PM +0100, Thomas Gleixner wrote: > > Yuck. No. You are just papering over the problem. > > > > What happens if you add 'threadirqs' to the kernel command line? Or if > > the interrupt

Re: e1000_netpoll(): disable_irq() triggers might_sleep() on linux-next

Hello, sorry for the delay. 2014-10-29, 20:36:03 +0100, Peter Zijlstra wrote: On Wed, Oct 29, 2014 at 07:33:00PM +0100, Thomas Gleixner wrote: Yuck. No. You are just papering over the problem. What happens if you add 'threadirqs' to the kernel command line? Or if the interrupt line is

Re: linux-next: manual merge of the block tree with the ext4 tree

Hello, [adding Jeremiah Mahler to CC] 2014-11-27, 14:53:47 +1100, Stephen Rothwell wrote: > Hi Jens, > > Today's linux-next merge of the block tree got a conflict in > fs/fs-writeback.c between commit ef7fdf5e8c87 ("vfs: add support for a > lazytime mount option") from the ext4 tree and commit

Re: linux-next: manual merge of the block tree with the ext4 tree

Hello, [adding Jeremiah Mahler to CC] 2014-11-27, 14:53:47 +1100, Stephen Rothwell wrote: Hi Jens, Today's linux-next merge of the block tree got a conflict in fs/fs-writeback.c between commit ef7fdf5e8c87 (vfs: add support for a lazytime mount option) from the ext4 tree and commit

e1000_netpoll(): disable_irq() triggers might_sleep() on linux-next

commit e22b886a8a43b ("sched/wait: Add might_sleep() checks") included in today's linux-next added a check that fires on e1000 with netpoll: BUG: sleeping function called from invalid context at kernel/irq/manage.c:104 in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd no locks held by

e1000_netpoll(): disable_irq() triggers might_sleep() on linux-next

commit e22b886a8a43b (sched/wait: Add might_sleep() checks) included in today's linux-next added a check that fires on e1000 with netpoll: BUG: sleeping function called from invalid context at kernel/irq/manage.c:104 in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd no locks held by

kmemleak: Cannot insert [...] into the object search tree (overlaps existing) (mm: use memblock_alloc_range())

Hello, 2014-08-24, 23:56:03 +0900, Akinobu Mita wrote: > Replace memblock_find_in_range() and memblock_reserve() with > memblock_alloc_range(). > > Signed-off-by: Akinobu Mita > Cc: linux...@kvack.org This patch is included in linux-next, and when I boot next-20140901, on a 32-bit build, I get

[PATCH net v2] ipv6: fix rtnl locking in setsockopt for anycast and multicast

(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before calling ipv6_dev_mc_inc/dec. This patch moves ASSERT_RTNL() up a level in the call stack. Signed-off-by: Cong Wang Signed-off-by: Sabrina Dubroca Reported-by: Tommi Rantala --- As was said earlier, this should go in stable. v2: - based on net - keep

[PATCH net v2] ipv6: fix rtnl locking in setsockopt for anycast and multicast

(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before calling ipv6_dev_mc_inc/dec. This patch moves ASSERT_RTNL() up a level in the call stack. Signed-off-by: Cong Wang xiyou.wangc...@gmail.com Signed-off-by: Sabrina Dubroca s...@queasysnail.net Reported-by: Tommi Rantala tt.rant...@gmail.com --- As was said

kmemleak: Cannot insert [...] into the object search tree (overlaps existing) (mm: use memblock_alloc_range())

Hello, 2014-08-24, 23:56:03 +0900, Akinobu Mita wrote: Replace memblock_find_in_range() and memblock_reserve() with memblock_alloc_range(). Signed-off-by: Akinobu Mita akinobu.m...@gmail.com Cc: linux...@kvack.org This patch is included in linux-next, and when I boot next-20140901, on a

[PATCH] ipv6: fix rtnl locking in setsockopt for anycast and multicast

(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before calling ipv6_dev_mc_inc/dec. This patch moves ASSERT_RTNL() up a level in the call stack. Signed-off-by: Cong Wang Signed-off-by: Sabrina Dubroca Reported-by: Tommi Rantala --- I included Cong's Signed-off-by for the first part of the patch, I hope

[PATCH] ipv6: fix rtnl locking in setsockopt for anycast and multicast

(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before calling ipv6_dev_mc_inc/dec. This patch moves ASSERT_RTNL() up a level in the call stack. Signed-off-by: Cong Wang xiyou.wangc...@gmail.com Signed-off-by: Sabrina Dubroca s...@queasysnail.net Reported-by: Tommi Rantala tt.rant...@gmail.com --- I included

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

2014-08-30, 12:58:21 +0200, Sabrina Dubroca wrote: >- pndisc_constructor, called from pneigh_lookup -- pneigh_lookup > has ASSERT_RTNL(), but pneigh_lookup is called from ip6_forward and > ndisc_recv_na Ah, these have creat = 0, so it's fine. I missed that earlie

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

Hello, 2014-08-30, 03:51:29 +0200, Hannes Frederic Sowa wrote: > Hi Sabrina, > > [...] > > Sorry, just had time to look at this. > > The reason is not to have list corruption but that the calls down to > ndo_set_rx_mode expect rtnl to be locked by the drivers. Filter lists > are locked by

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

2014-08-29, 15:54:48 -0700, Cong Wang wrote: > [...] > > You are absolutely right here. > > Can I have your Signed-off-by and Tested-by before sending the patch > formally? > > Thanks! Sure: Signed-off-by: Sabrina Dubroca Tested-by: Sabrina Dubroca Thanks, -- S

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

2014-08-29, 15:54:48 -0700, Cong Wang wrote: [...] You are absolutely right here. Can I have your Signed-off-by and Tested-by before sending the patch formally? Thanks! Sure: Signed-off-by: Sabrina Dubroca s...@queasysnail.net Tested-by: Sabrina Dubroca s...@queasysnail.net Thanks

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

Hello, 2014-08-30, 03:51:29 +0200, Hannes Frederic Sowa wrote: Hi Sabrina, [...] Sorry, just had time to look at this. The reason is not to have list corruption but that the calls down to ndo_set_rx_mode expect rtnl to be locked by the drivers. Filter lists are locked by

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

2014-08-30, 12:58:21 +0200, Sabrina Dubroca wrote: - pndisc_constructor, called from pneigh_lookup -- pneigh_lookup has ASSERT_RTNL(), but pneigh_lookup is called from ip6_forward and ndisc_recv_na Ah, these have creat = 0, so it's fine. I missed that earlier. Sorry for the noise

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

2014-08-29, 11:14:48 -0700, Cong Wang wrote: > On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala wrote: > > [ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699) > > [ 77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+ > > #30 > > [ 77.299039] Hardware name:

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

2014-08-29, 11:14:48 -0700, Cong Wang wrote: On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala tt.rant...@gmail.com wrote: [ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699) [ 77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+ #30 [ 77.299039]

BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1177

Hello, While fuzzing with trinity on next-20140827, I ran into this: [ 2059.161014] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1177 [ 2059.162968] in_atomic(): 0, irqs_disabled(): 1, pid: 3225, name: trinity-c0 [ 2059.163142] INFO: lockdep is turned off. [

BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1177

Hello, While fuzzing with trinity on next-20140827, I ran into this: [ 2059.161014] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1177 [ 2059.162968] in_atomic(): 0, irqs_disabled(): 1, pid: 3225, name: trinity-c0 [ 2059.163142] INFO: lockdep is turned off. [

Re: [PATCH][input-led] Defer input led work to workqueue

2014-08-26, 22:02:08 +0200, Sabrina Dubroca wrote: > [...] > > Tested-by: Sabrina Dubroca Forgot to mention, this applies to both versions of the patch. -- Sabrina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord

Re: [PATCH][input-led] Defer input led work to workqueue

but the same > tree with this patch on top of it boots without warning. Soo... > > Tested-By: Valdis Kletnieks Same for me. Tested-by: Sabrina Dubroca Thanks, -- Sabrina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to maj

[PATCH] block: fix error handling in sg_io

ad address APM_level = 128 Signed-off-by: Sabrina Dubroca Fixes: 2cada584b200 ("block: cleanup error handling in sg_io") --- block/scsi_ioctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c index 5dd477bfb4bc..9b8eaeca6a79 100644 --- a/bloc

linux-next: hdparm -B broken

Hello, Since next-20140823: # hdparm -B 200 /dev/sda /dev/sda: setting Advanced Power Management level to 0xc8 (200) HDIO_DRIVE_CMD failed: Bad address APM_level = 128 It looks like before commit 2cada584b200 ("block: cleanup error handling in sg_io"), we had ret = 0 before entering

linux-next: hdparm -B value broken

Hello, Since next-20140823: # hdparm -B 200 /dev/sda /dev/sda: setting Advanced Power Management level to 0xc8 (200) HDIO_DRIVE_CMD failed: Bad address APM_level = 128 It looks like before commit 2cada584b200 (block: cleanup error handling in sg_io), we had ret = 0 before entering

[PATCH] block: fix error handling in sg_io

APM_level = 128 Signed-off-by: Sabrina Dubroca s...@queasysnail.net Fixes: 2cada584b200 (block: cleanup error handling in sg_io) --- block/scsi_ioctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c index 5dd477bfb4bc..9b8eaeca6a79 100644 --- a/block

Re: [PATCH][input-led] Defer input led work to workqueue

Kletnieks valdis.kletni...@vt.edu Same for me. Tested-by: Sabrina Dubroca s...@queasysnail.net Thanks, -- Sabrina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: [PATCH][input-led] Defer input led work to workqueue

2014-08-26, 22:02:08 +0200, Sabrina Dubroca wrote: [...] Tested-by: Sabrina Dubroca s...@queasysnail.net Forgot to mention, this applies to both versions of the patch. -- Sabrina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: 3.17-rc1: leds blink workqueue causes sleeping BUGs

2014-08-19, 13:06:07 -0400, valdis.kletni...@vt.edu wrote: > On Sat, 16 Aug 2014 20:27:01 -0700, Hugh Dickins said: > > Can we safely revert your 8b37e1bef5a6 ("leds: convert blink timer to > > workqueue"), or have there been other changes which now depend upon it? > > I suspect there's something

Re: [PATCH v3 5/7] KVM: trace kvm_ple_window grow/shrink

Hello, 2014-08-21, 18:08:09 +0200, Radim Krčmář wrote: > Tracepoint for dynamic PLE window, fired on every potential change. > > Signed-off-by: Radim Krčmář > --- > arch/x86/kvm/trace.h | 30 ++ > arch/x86/kvm/vmx.c | 10 -- > arch/x86/kvm/x86.c | 1 + >

Re: [PATCH v3 5/7] KVM: trace kvm_ple_window grow/shrink

Hello, 2014-08-21, 18:08:09 +0200, Radim Krčmář wrote: Tracepoint for dynamic PLE window, fired on every potential change. Signed-off-by: Radim Krčmář rkrc...@redhat.com --- arch/x86/kvm/trace.h | 30 ++ arch/x86/kvm/vmx.c | 10 -- arch/x86/kvm/x86.c

Re: 3.17-rc1: leds blink workqueue causes sleeping BUGs

2014-08-19, 13:06:07 -0400, valdis.kletni...@vt.edu wrote: On Sat, 16 Aug 2014 20:27:01 -0700, Hugh Dickins said: Can we safely revert your 8b37e1bef5a6 (leds: convert blink timer to workqueue), or have there been other changes which now depend upon it? I suspect there's something else

Re: [PATCH] gpio / ACPI: Don't crash on NULL chip->dev

gt; [] bus_for_each_dev+0x47/0x80 > [] driver_attach+0x1e/0x20 > [] ? __device_attach+0x40/0x40 > [] bus_add_driver+0x157/0x230 > [] driver_register+0x59/0xe0 > ... > > Fix this by checking chip->dev pointer against NULL first. Also we can now > remove redundant c

Re: [PATCH] gpio / ACPI: Don't crash on NULL chip-dev

(). Reported-by: Sabrina Dubroca s...@queasysnail.net Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com --- Sabrina, Can you please re-test this and provide your tested-by? I changed the patch a bit to remove redundant checks. Just to be sure that I don't accidentally break something

Re: [bisected] NULL pointer dereference in acpi_gpiochip_add (on modprobe ssb)

2014-03-25, 09:25:30 +0200, Mika Westerberg wrote: > On Mon, Mar 24, 2014 at 07:31:11PM +0100, Sabrina Dubroca wrote: > > > Actually gpiolib seems to handle ->dev as optional. Can you try this patch > > > instead? Thanks. > > > > > > diff --git a/drivers/

Re: [bisected] NULL pointer dereference in acpi_gpiochip_add (on modprobe ssb)

2014-03-25, 09:25:30 +0200, Mika Westerberg wrote: On Mon, Mar 24, 2014 at 07:31:11PM +0100, Sabrina Dubroca wrote: Actually gpiolib seems to handle -dev as optional. Can you try this patch instead? Thanks. diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c

Re: [bisected] NULL pointer dereference in acpi_gpiochip_add (on modprobe ssb)

2014-03-24, 20:11:12 +0200, Mika Westerberg wrote: > On Mon, Mar 24, 2014 at 08:00:33PM +0200, Mika Westerberg wrote: > > On Mon, Mar 24, 2014 at 04:49:44PM +0100, Sabrina Dubroca wrote: > > > Hi, > > > > > > With next-20140324, I get the BUG below w

Re: [bisected] NULL pointer dereference in acpi_gpiochip_add (on modprobe ssb)

2014-03-24, 20:11:12 +0200, Mika Westerberg wrote: On Mon, Mar 24, 2014 at 08:00:33PM +0200, Mika Westerberg wrote: On Mon, Mar 24, 2014 at 04:49:44PM +0100, Sabrina Dubroca wrote: Hi, With next-20140324, I get the BUG below when I modprobe ssb. I bisected it to aa92b6f689ac

Re: [RFC PATCH 1/2] ACPICA: Dispatcher: Ignore SyncLevel for auto-serialization mechanism.

Hi, 2014-03-18, 00:50:04 +, Zheng, Lv wrote: > Hi, Sabrina and Valdis > > Could you give this patch a try to see if this patch is working? > > Thanks and best regards > -Lv I applied the two patches. The laptop boots and there is no ACPI error in the logs, both with auto-serialization

Re: [RFC PATCH 1/2] ACPICA: Dispatcher: Ignore SyncLevel for auto-serialization mechanism.

Hi, 2014-03-18, 00:50:04 +, Zheng, Lv wrote: Hi, Sabrina and Valdis Could you give this patch a try to see if this patch is working? Thanks and best regards -Lv I applied the two patches. The laptop boots and there is no ACPI error in the logs, both with auto-serialization enabled

Re: ACPICA 20140214 auto-serialize weirds my machine...

Hi, 2014-03-14, 12:05:01 -0400, Valdis Kletnieks wrote: > Surprisingly enough, this hasn't seemed to have bitten many Linux people yet, > Google only finds a BSD thread (where the same ACPICA code is in use): > > http://comments.gmane.org/gmane.os.dragonfly-bsd.user/1817 I was about to report

Re: ACPICA 20140214 auto-serialize weirds my machine...

Hi, 2014-03-14, 12:05:01 -0400, Valdis Kletnieks wrote: Surprisingly enough, this hasn't seemed to have bitten many Linux people yet, Google only finds a BSD thread (where the same ACPICA code is in use): http://comments.gmane.org/gmane.os.dragonfly-bsd.user/1817 I was about to report the

Re: [3.14-rc1] cirrus driver problem (qemu)

2014-02-05, 14:50:18 +1000, Dave Airlie wrote: > On Wed, Feb 5, 2014 at 8:53 AM, Sabrina Dubroca wrote: > > 2014-02-04, 13:20:54 +1000, Dave Airlie wrote: > >> On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca > >> wrote: > >> > When I boot 3.14-rc1 in q

Re: [3.14-rc1] cirrus driver problem (qemu)

2014-02-05, 14:50:18 +1000, Dave Airlie wrote: On Wed, Feb 5, 2014 at 8:53 AM, Sabrina Dubroca s...@queasysnail.net wrote: 2014-02-04, 13:20:54 +1000, Dave Airlie wrote: On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca s...@queasysnail.net wrote: When I boot 3.14-rc1 in qemu, I get

Re: [3.14-rc1] cirrus driver problem (qemu)

2014-02-04, 13:20:54 +1000, Dave Airlie wrote: > On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca wrote: > > When I boot 3.14-rc1 in qemu, I get the trace below. The console stops > > updating and I don't get a login prompt. I can login, but I can't see > > what I'm doing. I c

Re: [3.14-rc1] cirrus driver problem (qemu)

2014-02-04, 13:20:54 +1000, Dave Airlie wrote: On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca s...@queasysnail.net wrote: When I boot 3.14-rc1 in qemu, I get the trace below. The console stops updating and I don't get a login prompt. I can login, but I can't see what I'm doing. I can login

[3.14-rc1] cirrus driver problem (qemu)

] [] x86_64_start_reservations+0x2a/0x2c [1.749470] [] x86_64_start_kernel+0x169/0x178 [1.749471] ---[ end trace d478ba7c30908d4d ]--- -- Sabrina Dubroca -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kerne

[3.14-rc1] cirrus driver problem (qemu)

] [81ae296f] ? repair_env_string+0x5c/0x5c [1.749469] [81ae25f6] x86_64_start_reservations+0x2a/0x2c [1.749470] [81ae2761] x86_64_start_kernel+0x169/0x178 [1.749471] ---[ end trace d478ba7c30908d4d ]--- -- Sabrina Dubroca -- To unsubscribe from this list: send

Re: linux-next: build failure after merge of the tip tree

2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote: > On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote: > > > > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on > > Q6600 box. See below for an alternative. > > Urgh, I see, we call the idle arch_cpu_idle()

Re: linux-next: build failure after merge of the tip tree

2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote: On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote: I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on Q6600 box. See below for an alternative. Urgh, I see, we call the idle arch_cpu_idle() callback with

<    1   2