From: Jens Axboe <jens.axboe@oracle.com>
To: Jens Rosenboom <jens@mcbone.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Oops when writing to /sys/block/ram0/queue/max_sectors_kb
Date: Tue, 28 Jul 2009 09:07:11 +0200 [thread overview]
Message-ID: <20090728070711.GN4148@kernel.dk> (raw)
In-Reply-To: <1248363032.7237.48.camel@fnki-nb00130>
On Thu, Jul 23 2009, Jens Rosenboom wrote:
> Even when writing the current value again, I get this Oops and further
> reads from that file stall.
>
> # cat /sys/block/ram0/queue/max_sectors_kb
> 512
> # echo 512 >/sys/block/ram0/queue/max_sectors_kb
> [Produces an Oops and connection closes]
> [After logging in again:]
> # cat /sys/block/ram0/queue/max_sectors_kb
> [hangs]
>
> Corresponding output from dmesg:
>
> [ 1254.984435] BUG: unable to handle kernel NULL pointer dereference at
> (null)
> [ 1254.988005] IP: [<c12a1550>] _spin_lock_irq+0x10/0x30
> [ 1254.988005] *pde = 00000000
> [ 1254.988005] Oops: 0002 [#1] SMP
> [ 1254.988005] last sysfs
> file: /sys/devices/virtual/block/ram0/queue/max_sectors_kb
> [ 1254.988005] Modules linked in: ipv6 af_packet usbhid hid uhci_hcd
> ohci_hcd ehci_hcd usbcore 8021q garp stp serio_raw psmouse evdev
> i2c_piix4 button container pcspkr processor i2c_core ext3 jbd mbcache
> dm_mirror dm_region_hash dm_log dm_snapshot dm_mod raid10 raid456
> raid6_pq async_xor async_memcpy async_tx xor raid1 raid0 multipath
> linear md_mod sg sr_mod cdrom ata_generic pata_acpi pata_serverworks
> megaraid libata floppy e100 mii scsi_mod cpqarray thermal fan
> [ 1254.988005]
> [ 1254.988005] Pid: 3822, comm: bash Not tainted (2.6.31-rc4 #3)
> ProLiant DL360
> [ 1254.988005] EIP: 0060:[<c12a1550>] EFLAGS: 00010012 CPU: 0
> [ 1254.988005] EIP is at _spin_lock_irq+0x10/0x30
> [ 1254.988005] EAX: 00000100 EBX: 00000004 ECX: c379e003 EDX: 00000000
> [ 1254.988005] ESI: 00000200 EDI: f6bb0000 EBP: c3605f00 ESP: c3605f00
> [ 1254.988005] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [ 1254.988005] Process bash (pid: 3822, ti=c3604000 task=f6bde800
> task.ti=c3604000)
> [ 1254.988005] Stack:
> [ 1254.988005] c3605f1c c115d93b 00000004 c379e003 f6bb0000 f6bb0470
> c13ca238 c3605f34
> [ 1254.988005] <0> c115d9a7 c379e000 f707c7e0 c13ca1ac f69bf5c0 c3605f64
> c111408d 00000004
> [ 1254.988005] <0> 00000004 08e99408 f6976480 f69bf5d4 c13ca1ac f6bb0148
> f6976480 08e99408
> [ 1254.988005] Call Trace:
> [ 1254.988005] [<c115d93b>] ? queue_max_sectors_store+0x5b/0x80
> [ 1254.988005] [<c115d9a7>] ? queue_attr_store+0x47/0x70
> [ 1254.988005] [<c111408d>] ? sysfs_write_file+0x9d/0xf0
> [ 1254.988005] [<c10c889c>] ? vfs_write+0x9c/0x180
> [ 1254.988005] [<c1113ff0>] ? sysfs_write_file+0x0/0xf0
> [ 1254.988005] [<c10c8a3d>] ? sys_write+0x3d/0x70
> [ 1254.988005] [<c1003049>] ? syscall_call+0x7/0xb
> [ 1254.988005] Code: 01 00 00 f0 66 0f c1 02 38 e0 74 06 f3 90 8a 02 eb
> f6 89 c8 5d c3 90 8d 74 26 00 55 89 c2 89 e5 fa 90 8d 74 26 00 b8 00 01
> 00 00 <f0> 66 0f c1 02 38 e0 74 06 f3 90 8a 02 eb f6 5d c3 eb 0d 90 90
> [ 1254.988005] EIP: [<c12a1550>] _spin_lock_irq+0x10/0x30 SS:ESP
> 0068:c3605f00
> [ 1254.988005] CR2: 0000000000000000
> [ 1254.988005] ---[ end trace ee0e56d1adcbecab ]---
Looks like this will hit nonrot/merge/etc store functions after we
exposed these sysfs knobs for non-request_fn drivers too. Can you try
the below? Should fix all of them up.
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b45435..a0c340d 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -575,13 +575,6 @@ blk_init_queue_node(request_fn_proc *rfn, spinlock_t *lock, int node_id)
return NULL;
}
- /*
- * if caller didn't supply a lock, they get per-queue locking with
- * our embedded lock
- */
- if (!lock)
- lock = &q->__queue_lock;
-
q->request_fn = rfn;
q->prep_rq_fn = NULL;
q->unplug_fn = generic_unplug_device;
diff --git a/block/blk-settings.c b/block/blk-settings.c
index bd582a7..8a3ea3b 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -165,6 +165,13 @@ void blk_queue_make_request(struct request_queue *q, make_request_fn *mfn)
blk_set_default_limits(&q->limits);
/*
+ * If the caller didn't supply a lock, fall back to our embedded
+ * per-queue locks
+ */
+ if (!q->queue_lock)
+ q->queue_lock = &q->__queue_lock;
+
+ /*
* by default assume old behaviour and bounce for any highmem page
*/
blk_queue_bounce_limit(q, BLK_BOUNCE_HIGH);
--
Jens Axboe
next prev parent reply other threads:[~2009-07-28 7:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-23 15:30 Oops when writing to /sys/block/ram0/queue/max_sectors_kb Jens Rosenboom
2009-07-28 7:07 ` Jens Axboe [this message]
2009-07-28 9:30 ` Jens Rosenboom
2009-07-28 10:04 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090728070711.GN4148@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=jens@mcbone.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.