Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Mon, Feb 19, 2007 at 03:08:03PM +0100, Michal Piotrowski wrote: > Michal Piotrowski napisał(a): > > Hi Frederik, > > > > On 20/02/07, Frederik Deweerdt <[EMAIL PROTECTED]> wrote: > >> Hi Michal, > >> > >> This seems to be a locking problem in __make_request, check_plug_merge() > >> should be called with the q->queue_lock held. > >> Could you try the following patch? It silenced the oops for me. > > > > For me too, but Jens dislikes this patch. > > Now I know why... > > Code: Bad EIP value. > EIP: [<6b6b6b6b>] 0x6b6b6b6b SS:ESP 0068:f45f9bf8 :) It may not be related though. I think that my patch avoids the BUG_ON(!rq_mergeable(req)); in ll_rw_blk.c:2782. This looks like another beast to me. Regards, Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Mon, Feb 19, 2007 at 02:34:53PM +0100, Jens Axboe wrote: > On Tue, Feb 20 2007, Frederik Deweerdt wrote: > > On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote: > > > On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > >On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> > > > >wrote: > > > > > > > >> On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > > >> > Le 18.02.2007 06:51, Andrew Morton a ?crit : > > > >> > >Temporarily at > > > >> > > > > > >> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > >> > > > > > >> > >Will appear later at > > > >> > > > > > >> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > >> > > > > >> > Hello, I've got a fully reproducible Oops. I just have to boot to > > > >> > runlevel 2 and wait less than one minute. > > > >> > > > >> Maybe this oops is related too? > > > > > > > >Looks that way. > > > > > > Hi Michal, > > > > This seems to be a locking problem in __make_request, check_plug_merge() > > should be called with the q->queue_lock held. > > Could you try the following patch? It silenced the oops for me. > > Just back from travel... That is not correct, why do you think the queue > lock needs to be held there? The unprotected: check_plug_merge -> bio_attempt_back_merge -> ll_back_merge_fn -> q->last_merge = NULL made me think that. I don't know the code enough though. Regards, Frederik > > -- > Jens Axboe > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
Michal Piotrowski napisał(a): > Hi Frederik, > > On 20/02/07, Frederik Deweerdt <[EMAIL PROTECTED]> wrote: >> Hi Michal, >> >> This seems to be a locking problem in __make_request, check_plug_merge() >> should be called with the q->queue_lock held. >> Could you try the following patch? It silenced the oops for me. > > For me too, but Jens dislikes this patch. Now I know why... Code: Bad EIP value. EIP: [<6b6b6b6b>] 0x6b6b6b6b SS:ESP 0068:f45f9bf8 note: ksmserver[20993] exited with preempt_count 2 BUG: sleeping function called from invalid context at /mnt/md0/devel/linux-mm/kernel/rwsem.c:20 in_atomic():1, irqs_disabled():1 no locks held by ksmserver/20993. irq event stamp: 0 hardirqs last enabled at (0): [<>] 0x0 hardirqs last disabled at (0): [] copy_process+0x539/0x137d softirqs last enabled at (0): [] copy_process+0x557/0x137d BUG: unable to handle kernel NULL pointer dereference at virtual address 0118 printing eip: c01f3f12 *pde = Oops: [#1] PREEMPT SMP last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss evdev snd_pcm skge intel_agp snd_timer agpgart snd 8139too soundcore sk98lin i2c_i801 mii snd_page_alloc ide_cd cdrom rtc unix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00210297 (2.6.20-mm2 #19) EIP is at blk_unplug_current+0x60/0x156 eax: f3f97298 ebx: 0001 ecx: c043db74 edx: esi: f3f97284 edi: ebp: dda39d94 esp: dda39d58 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process swriter.bin (pid: 20846, ti=dda38000 task=dda79510 task.ti=dda38000) Stack: dda79510 c03369fd dda79510 c03369fd dda39d90 f3f97298 c011e710 c7403fac 00200046 dda39d90 0001 c04abda0 06f75d80 dda39da8 c03339bb dda79f38 dda79f30 c7403f98 dda39db0 c0333a2f dda39db8 c015e380 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9d/0xac [] show_registers+0x1ed/0x34c [] die+0x11d/0x234 [] do_page_fault+0x47c/0x55b [] error_code+0x7c/0x84 [] io_schedule+0x3d/0x9a [] io_wait_schedule+0x17/0x1d [] sleep_on_page+0xa/0xc [] __wait_on_bit_lock+0x34/0x66 [] lock_page_blocking+0x2c/0x30 [] do_generic_mapping_read+0x29f/0x51a [] generic_file_aio_read+0x19a/0x1c8 [] do_sync_read+0xd7/0x114 [] vfs_read+0xcf/0x158 [] sys_read+0x3d/0x72 [] syscall_call+0x7/0xb === Code: 0b eb fe 8b 46 0c 48 89 46 0c 85 c0 0f 85 07 01 00 00 8b 7e 1c c7 46 1c 00 00 00 00 8d 46 14 89 45 e0 39 46 14 0f 84 d4 00 00 00 <8b> 87 18 01 00 00 e8 c0 26 14 00 c7 45 e4 00 00 00 00 8b 5e 14 EIP: [] blk_unplug_current+0x60/0x156 SS:ESP 0068:dda39d58 BUG: unable to handle kernel paging request at virtual address 6b6b6b6b printing eip: 6b6b6b6b *pde = Oops: [#2] PREEMPT SMP last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss evdev snd_pcm skge intel_agp snd_timer agpgart snd 8139too soundcore sk98lin i2c_i801 mii snd_page_alloc ide_cd cdrom rtc unix CPU:0 EIP:0060:[<6b6b6b6b>]Not tainted VLI EFLAGS: 00210012 (2.6.20-mm2 #19) EIP is at 0x6b6b6b6b eax: dda79f38 ebx: dda79f38 ecx: edx: 0003 esi: 6b6b6b6b edi: 0001 ebp: f45f9c18 esp: f45f9bf8 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process ksmserver (pid: 20993, ti=f45f8000 task=f335b510 task.ti=f45f8000) Stack: c011b5e0 f45f9c44 0003 c7403f98 6b6b6b6b c7403f98 0001 00200292 f45f9c38 c011c3fb f45f9c44 0003 c7403f98 f7d71f4c f7d71f4c f45f9c50 c01353c3 f45f9c44 f7d71f4c 0002 0002 f45f9c60 c01353e0 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9d/0xac [] show_registers+0x1ed/0x34c [] die+0x11d/0x234 [] do_page_fault+0x47c/0x55b [] error_code+0x7c/0x84 [] __wake_up+0x31/0x42 [] __wake_up_bit+0x2e/0x34 [] wake_up_bit+0x17/0x1b [] unlock_buffer+0x12/0x14 [] do_get_write_access+0x185/0x657 [] journal_get_write_access+0x1b/0x2a [] __ext3_journal_get_write_access+0x19/0x3f [] ext3_reserve_inode_write+0x34/0x68 [] ext3_mark_inode_dirty+0x2a/0x41 [] ext3_dirty_inode+0x6a/0x7d [] __mark_inode_dirty+0x2a/0x16d [] touch_atime+0xc1/0xcb []
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
Hi Frederik, On 20/02/07, Frederik Deweerdt <[EMAIL PROTECTED]> wrote: Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q->queue_lock held. Could you try the following patch? It silenced the oops for me. For me too, but Jens dislikes this patch. Regards, Frederik Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Tue, Feb 20 2007, Frederik Deweerdt wrote: > On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote: > > On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > >On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> > > >wrote: > > > > > >> On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > >> > Le 18.02.2007 06:51, Andrew Morton a ?crit : > > >> > >Temporarily at > > >> > > > > >> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > >> > > > > >> > >Will appear later at > > >> > > > > >> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > >> > > > >> > Hello, I've got a fully reproducible Oops. I just have to boot to > > >> > runlevel 2 and wait less than one minute. > > >> > > >> Maybe this oops is related too? > > > > > >Looks that way. > > > > Hi Michal, > > This seems to be a locking problem in __make_request, check_plug_merge() > should be called with the q->queue_lock held. > Could you try the following patch? It silenced the oops for me. Just back from travel... That is not correct, why do you think the queue lock needs to be held there? I'll look into this tomorrow. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote:
> On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote:
> >
> >> On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote:
> >> > Le 18.02.2007 06:51, Andrew Morton a �crit :
> >> > >Temporarily at
> >> > >
> >> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> >> > >
> >> > >Will appear later at
> >> > >
> >> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> >> >
> >> > Hello, I've got a fully reproducible Oops. I just have to boot to
> >> > runlevel 2 and wait less than one minute.
> >>
> >> Maybe this oops is related too?
> >
> >Looks that way.
> >
Hi Michal,
This seems to be a locking problem in __make_request, check_plug_merge()
should be called with the q->queue_lock held.
Could you try the following patch? It silenced the oops for me.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 577f448..666f34e 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -2919,14 +2919,14 @@ static int __make_request(request_queue_
*/
blk_queue_bounce(q, );
+ spin_lock_irq(q->queue_lock);
/*
* Check if we can merge with the plugged list before grabbing
* any locks.
*/
if (!check_plug_merge(q, ioc, bio))
- goto out;
+ goto out_unlock;
- spin_lock_irq(q->queue_lock);
el_ret = elv_merge(q, , bio);
if (el_ret == ELEVATOR_BACK_MERGE) {
if (bio_attempt_back_merge(q, req, bio)) {
@@ -2984,7 +2984,6 @@ out_unlock:
list_add_tail(>queuelist, >plugged_list);
}
-out:
return 0;
end_io_eopnotsupp:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote:
On 18/02/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote:
On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote:
Le 18.02.2007 06:51, Andrew Morton a �crit :
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-mm2/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
Hello, I've got a fully reproducible Oops. I just have to boot to
runlevel 2 and wait less than one minute.
Maybe this oops is related too?
Looks that way.
Hi Michal,
This seems to be a locking problem in __make_request, check_plug_merge()
should be called with the q-queue_lock held.
Could you try the following patch? It silenced the oops for me.
Regards,
Frederik
Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 577f448..666f34e 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -2919,14 +2919,14 @@ static int __make_request(request_queue_
*/
blk_queue_bounce(q, bio);
+ spin_lock_irq(q-queue_lock);
/*
* Check if we can merge with the plugged list before grabbing
* any locks.
*/
if (!check_plug_merge(q, ioc, bio))
- goto out;
+ goto out_unlock;
- spin_lock_irq(q-queue_lock);
el_ret = elv_merge(q, req, bio);
if (el_ret == ELEVATOR_BACK_MERGE) {
if (bio_attempt_back_merge(q, req, bio)) {
@@ -2984,7 +2984,6 @@ out_unlock:
list_add_tail(req-queuelist, ioc-plugged_list);
}
-out:
return 0;
end_io_eopnotsupp:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Tue, Feb 20 2007, Frederik Deweerdt wrote: On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote: On 18/02/07, Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a ?crit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Looks that way. Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. Just back from travel... That is not correct, why do you think the queue lock needs to be held there? I'll look into this tomorrow. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
Hi Frederik, On 20/02/07, Frederik Deweerdt [EMAIL PROTECTED] wrote: Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. For me too, but Jens dislikes this patch. Regards, Frederik Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
Michal Piotrowski napisał(a): Hi Frederik, On 20/02/07, Frederik Deweerdt [EMAIL PROTECTED] wrote: Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. For me too, but Jens dislikes this patch. Now I know why... Code: Bad EIP value. EIP: [6b6b6b6b] 0x6b6b6b6b SS:ESP 0068:f45f9bf8 note: ksmserver[20993] exited with preempt_count 2 BUG: sleeping function called from invalid context at /mnt/md0/devel/linux-mm/kernel/rwsem.c:20 in_atomic():1, irqs_disabled():1 no locks held by ksmserver/20993. irq event stamp: 0 hardirqs last enabled at (0): [] 0x0 hardirqs last disabled at (0): [c0121bc6] copy_process+0x539/0x137d softirqs last enabled at (0): [c0121be4] copy_process+0x557/0x137d BUG: unable to handle kernel NULL pointer dereference at virtual address 0118 printing eip: c01f3f12 *pde = Oops: [#1] PREEMPT SMP last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss evdev snd_pcm skge intel_agp snd_timer agpgart snd 8139too soundcore sk98lin i2c_i801 mii snd_page_alloc ide_cd cdrom rtc unix CPU:0 EIP:0060:[c01f3f12]Not tainted VLI EFLAGS: 00210297 (2.6.20-mm2 #19) EIP is at blk_unplug_current+0x60/0x156 eax: f3f97298 ebx: 0001 ecx: c043db74 edx: esi: f3f97284 edi: ebp: dda39d94 esp: dda39d58 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process swriter.bin (pid: 20846, ti=dda38000 task=dda79510 task.ti=dda38000) Stack: dda79510 c03369fd dda79510 c03369fd dda39d90 f3f97298 c011e710 c7403fac 00200046 dda39d90 0001 c04abda0 06f75d80 dda39da8 c03339bb dda79f38 dda79f30 c7403f98 dda39db0 c0333a2f dda39db8 c015e380 Call Trace: [c0105312] show_trace_log_lvl+0x1a/0x2f [c01053c4] show_stack_log_lvl+0x9d/0xac [c01055c0] show_registers+0x1ed/0x34c [c010583c] die+0x11d/0x234 [c011a8e1] do_page_fault+0x47c/0x55b [c0336d54] error_code+0x7c/0x84 [c03339bb] io_schedule+0x3d/0x9a [c0333a2f] io_wait_schedule+0x17/0x1d [c015e380] sleep_on_page+0xa/0xc [c0334217] __wait_on_bit_lock+0x34/0x66 [c015e372] lock_page_blocking+0x2c/0x30 [c015ebe2] do_generic_mapping_read+0x29f/0x51a [c0160daa] generic_file_aio_read+0x19a/0x1c8 [c017f300] do_sync_read+0xd7/0x114 [c017fc2a] vfs_read+0xcf/0x158 [c0180090] sys_read+0x3d/0x72 [c010432c] syscall_call+0x7/0xb === Code: 0b eb fe 8b 46 0c 48 89 46 0c 85 c0 0f 85 07 01 00 00 8b 7e 1c c7 46 1c 00 00 00 00 8d 46 14 89 45 e0 39 46 14 0f 84 d4 00 00 00 8b 87 18 01 00 00 e8 c0 26 14 00 c7 45 e4 00 00 00 00 8b 5e 14 EIP: [c01f3f12] blk_unplug_current+0x60/0x156 SS:ESP 0068:dda39d58 BUG: unable to handle kernel paging request at virtual address 6b6b6b6b printing eip: 6b6b6b6b *pde = Oops: [#2] PREEMPT SMP last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss evdev snd_pcm skge intel_agp snd_timer agpgart snd 8139too soundcore sk98lin i2c_i801 mii snd_page_alloc ide_cd cdrom rtc unix CPU:0 EIP:0060:[6b6b6b6b]Not tainted VLI EFLAGS: 00210012 (2.6.20-mm2 #19) EIP is at 0x6b6b6b6b eax: dda79f38 ebx: dda79f38 ecx: edx: 0003 esi: 6b6b6b6b edi: 0001 ebp: f45f9c18 esp: f45f9bf8 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process ksmserver (pid: 20993, ti=f45f8000 task=f335b510 task.ti=f45f8000) Stack: c011b5e0 f45f9c44 0003 c7403f98 6b6b6b6b c7403f98 0001 00200292 f45f9c38 c011c3fb f45f9c44 0003 c7403f98 f7d71f4c f7d71f4c f45f9c50 c01353c3 f45f9c44 f7d71f4c 0002 0002 f45f9c60 c01353e0 Call Trace: [c0105312] show_trace_log_lvl+0x1a/0x2f [c01053c4] show_stack_log_lvl+0x9d/0xac [c01055c0] show_registers+0x1ed/0x34c [c010583c] die+0x11d/0x234 [c011a8e1] do_page_fault+0x47c/0x55b [c0336d54] error_code+0x7c/0x84 [c011c3fb] __wake_up+0x31/0x42 [c01353c3] __wake_up_bit+0x2e/0x34 [c01353e0] wake_up_bit+0x17/0x1b [c019ecbf] unlock_buffer+0x12/0x14 [c01ccad4] do_get_write_access+0x185/0x657 [c01ccfc1]
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Mon, Feb 19, 2007 at 02:34:53PM +0100, Jens Axboe wrote: On Tue, Feb 20 2007, Frederik Deweerdt wrote: On Sun, Feb 18, 2007 at 09:05:33PM +0100, Michal Piotrowski wrote: On 18/02/07, Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a ?crit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Looks that way. Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. Just back from travel... That is not correct, why do you think the queue lock needs to be held there? The unprotected: check_plug_merge - bio_attempt_back_merge - ll_back_merge_fn - q-last_merge = NULL made me think that. I don't know the code enough though. Regards, Frederik -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request)
On Mon, Feb 19, 2007 at 03:08:03PM +0100, Michal Piotrowski wrote: Michal Piotrowski napisał(a): Hi Frederik, On 20/02/07, Frederik Deweerdt [EMAIL PROTECTED] wrote: Hi Michal, This seems to be a locking problem in __make_request, check_plug_merge() should be called with the q-queue_lock held. Could you try the following patch? It silenced the oops for me. For me too, but Jens dislikes this patch. Now I know why... Code: Bad EIP value. EIP: [6b6b6b6b] 0x6b6b6b6b SS:ESP 0068:f45f9bf8 :) It may not be related though. I think that my patch avoids the BUG_ON(!rq_mergeable(req)); in ll_rw_blk.c:2782. This looks like another beast to me. Regards, Frederik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
