[PATCH] virtio: console: Fixes from linux-next
by Amit Shah
The virtio-console code in Rusty's tree has been updated with the following
changes:
- Initialize the 'data' entry for virtio's virtqueues
- Fix some memleaks on port hot-unplug
- Allow module unload
- Allocate more buffers for the host to send data
- Add myself to MAINTAINERS for virtio-console.
Please merge this patch with the rollup patch for the F13 and rawhide branches.
Signed-off-by: Amit Shah <amit.shah(a)redhat.com>
---
MAINTAINERS | 6 ++
drivers/char/virtio_console.c | 132 +++++++++++++++++++++++++++++++---------
drivers/virtio/virtio_ring.c | 5 +-
3 files changed, 112 insertions(+), 31 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 03f38c1..3118dfa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2394,6 +2394,12 @@ L: linuxppc-dev(a)ozlabs.org
S: Odd Fixes
F: drivers/char/hvc_*
+VIRTIO CONSOLE DRIVER
+M: Amit Shah <amit.shah(a)redhat.com>
+L: virtualization(a)lists.linux-foundation.org
+S: Maintained
+F: drivers/char/virtio_console.c
+
GSPCA FINEPIX SUBDRIVER
M: Frank Zago <frank(a)zago.net>
L: linux-media(a)vger.kernel.org
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index a3f1f73..213373b 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -330,6 +330,7 @@ static void discard_port_data(struct port *port)
struct port_buffer *buf;
struct virtqueue *vq;
unsigned int len;
+ int ret;
vq = port->in_vq;
if (port->inbuf)
@@ -337,16 +338,18 @@ static void discard_port_data(struct port *port)
else
buf = vq->vq_ops->get_buf(vq, &len);
- if (!buf)
- return;
-
- if (add_inbuf(vq, buf) < 0) {
- buf->len = buf->offset = 0;
- dev_warn(port->dev, "Error adding buffer back to vq\n");
- return;
+ ret = 0;
+ while (buf) {
+ if (add_inbuf(vq, buf) < 0) {
+ ret++;
+ free_buf(buf);
+ }
+ buf = vq->vq_ops->get_buf(vq, &len);
}
-
port->inbuf = NULL;
+ if (ret)
+ dev_warn(port->dev, "Errors adding %d buffers back to vq\n",
+ ret);
}
static bool port_has_data(struct port *port)
@@ -354,12 +357,19 @@ static bool port_has_data(struct port *port)
unsigned long flags;
bool ret;
- ret = false;
spin_lock_irqsave(&port->inbuf_lock, flags);
- if (port->inbuf)
+ if (port->inbuf) {
ret = true;
+ goto out;
+ }
+ port->inbuf = get_inbuf(port);
+ if (port->inbuf) {
+ ret = true;
+ goto out;
+ }
+ ret = false;
+out:
spin_unlock_irqrestore(&port->inbuf_lock, flags);
-
return ret;
}
@@ -838,6 +848,8 @@ static const struct file_operations port_debugfs_ops = {
/* Remove all port-specific data. */
static int remove_port(struct port *port)
{
+ struct port_buffer *buf;
+
spin_lock_irq(&port->portdev->ports_lock);
list_del(&port->list);
spin_unlock_irq(&port->portdev->ports_lock);
@@ -851,14 +863,17 @@ static int remove_port(struct port *port)
if (port->guest_connected)
send_control_msg(port, VIRTIO_CONSOLE_PORT_OPEN, 0);
- while (port->in_vq->vq_ops->detach_unused_buf(port->in_vq))
- ;
-
sysfs_remove_group(&port->dev->kobj, &port_attribute_group);
device_destroy(pdrvdata.class, port->dev->devt);
cdev_del(&port->cdev);
+ /* Remove unused data this port might have received. */
discard_port_data(port);
+
+ /* Remove buffers we queued up for the Host to send us data in. */
+ while ((buf = port->in_vq->vq_ops->detach_unused_buf(port->in_vq)))
+ free_buf(buf);
+
kfree(port->name);
debugfs_remove(port->debugfs_file);
@@ -1006,7 +1021,8 @@ static void in_intr(struct virtqueue *vq)
return;
spin_lock_irqsave(&port->inbuf_lock, flags);
- port->inbuf = get_inbuf(port);
+ if (!port->inbuf)
+ port->inbuf = get_inbuf(port);
/*
* Don't queue up data when port is closed. This condition
@@ -1052,32 +1068,37 @@ static void config_intr(struct virtio_device *vdev)
resize_console(find_port_by_id(portdev, 0));
}
-static void fill_queue(struct virtqueue *vq, spinlock_t *lock)
+static unsigned int fill_queue(struct virtqueue *vq, spinlock_t *lock)
{
struct port_buffer *buf;
- int ret;
+ unsigned int ret;
+ int err;
+ ret = 0;
do {
buf = alloc_buf(PAGE_SIZE);
if (!buf)
break;
spin_lock_irq(lock);
- ret = add_inbuf(vq, buf);
- if (ret < 0) {
+ err = add_inbuf(vq, buf);
+ if (err < 0) {
spin_unlock_irq(lock);
free_buf(buf);
break;
}
+ ret++;
spin_unlock_irq(lock);
- } while (ret > 0);
+ } while (err > 0);
+
+ return ret;
}
static int add_port(struct ports_device *portdev, u32 id)
{
char debugfs_name[16];
struct port *port;
- struct port_buffer *inbuf;
+ struct port_buffer *buf;
dev_t devt;
int err;
@@ -1122,22 +1143,21 @@ static int add_port(struct ports_device *portdev, u32 id)
spin_lock_init(&port->inbuf_lock);
init_waitqueue_head(&port->waitqueue);
- inbuf = alloc_buf(PAGE_SIZE);
- if (!inbuf) {
+ /* Fill the in_vq with buffers so the host can send us data. */
+ err = fill_queue(port->in_vq, &port->inbuf_lock);
+ if (!err) {
+ dev_err(port->dev, "Error allocating inbufs\n");
err = -ENOMEM;
goto free_device;
}
- /* Register the input buffer the first time. */
- add_inbuf(port->in_vq, inbuf);
-
/*
* If we're not using multiport support, this has to be a console port
*/
if (!use_multiport(port->portdev)) {
err = init_port_console(port);
if (err)
- goto free_inbuf;
+ goto free_inbufs;
}
spin_lock_irq(&portdev->ports_lock);
@@ -1165,8 +1185,9 @@ static int add_port(struct ports_device *portdev, u32 id)
}
return 0;
-free_inbuf:
- free_buf(inbuf);
+free_inbufs:
+ while ((buf = port->in_vq->vq_ops->detach_unused_buf(port->in_vq)))
+ free_buf(buf);
free_device:
device_destroy(pdrvdata.class, port->dev->devt);
free_cdev:
@@ -1425,7 +1446,13 @@ static int __devinit virtcons_probe(struct virtio_device *vdev)
INIT_WORK(&portdev->control_work, &control_work_handler);
INIT_WORK(&portdev->config_work, &config_work_handler);
- fill_queue(portdev->c_ivq, &portdev->cvq_lock);
+ err = fill_queue(portdev->c_ivq, &portdev->cvq_lock);
+ if (!err) {
+ dev_err(&vdev->dev,
+ "Error allocating buffers for control queue\n");
+ err = -ENOMEM;
+ goto free_vqs;
+ }
}
for (i = 0; i < portdev->config.nr_ports; i++)
@@ -1435,6 +1462,10 @@ static int __devinit virtcons_probe(struct virtio_device *vdev)
early_put_chars = NULL;
return 0;
+free_vqs:
+ vdev->config->del_vqs(vdev);
+ kfree(portdev->in_vqs);
+ kfree(portdev->out_vqs);
free_chrdev:
unregister_chrdev(portdev->chr_major, "virtio-portsdev");
free:
@@ -1443,6 +1474,36 @@ fail:
return err;
}
+static void virtcons_remove(struct virtio_device *vdev)
+{
+ struct ports_device *portdev;
+ struct port *port, *port2;
+ struct port_buffer *buf;
+ unsigned int len;
+
+ portdev = vdev->priv;
+
+ cancel_work_sync(&portdev->control_work);
+ cancel_work_sync(&portdev->config_work);
+
+ list_for_each_entry_safe(port, port2, &portdev->ports, list)
+ remove_port(port);
+
+ unregister_chrdev(portdev->chr_major, "virtio-portsdev");
+
+ while ((buf = portdev->c_ivq->vq_ops->get_buf(portdev->c_ivq, &len)))
+ free_buf(buf);
+
+ while ((buf = portdev->c_ivq->vq_ops->detach_unused_buf(portdev->c_ivq)))
+ free_buf(buf);
+
+ vdev->config->del_vqs(vdev);
+ kfree(portdev->in_vqs);
+ kfree(portdev->out_vqs);
+
+ kfree(portdev);
+}
+
static struct virtio_device_id id_table[] = {
{ VIRTIO_ID_CONSOLE, VIRTIO_DEV_ANY_ID },
{ 0 },
@@ -1460,6 +1521,7 @@ static struct virtio_driver virtio_console = {
.driver.owner = THIS_MODULE,
.id_table = id_table,
.probe = virtcons_probe,
+ .remove = virtcons_remove,
.config_changed = config_intr,
};
@@ -1483,7 +1545,17 @@ static int __init init(void)
return register_virtio_driver(&virtio_console);
}
+
+static void __exit fini(void)
+{
+ unregister_virtio_driver(&virtio_console);
+
+ class_destroy(pdrvdata.class);
+ if (pdrvdata.debugfs_dir)
+ debugfs_remove_recursive(pdrvdata.debugfs_dir);
+}
module_init(init);
+module_exit(fini);
MODULE_DEVICE_TABLE(virtio, id_table);
MODULE_DESCRIPTION("Virtio console driver");
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 71929ee..9bcfe95 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -431,8 +431,11 @@ struct virtqueue *vring_new_virtqueue(unsigned int num,
/* Put everything in free lists. */
vq->num_free = num;
vq->free_head = 0;
- for (i = 0; i < num-1; i++)
+ for (i = 0; i < num-1; i++) {
vq->vring.desc[i].next = i+1;
+ vq->data[i] = NULL;
+ }
+ vq->data[i] = NULL;
return &vq->vq;
}
--
1.6.2.5
13 years, 9 months
mvsas driver needs some love
by Orion Poplawski
This is a plea to see if any of the Fedora kernel folks might be able to
help give the mvsas driver some love. This driver supports some nice
inexpensive pcie SAS controllers that I would very much like to use for
my next generation disk servers.
Unfortunately the current driver is not very robust. Andy Yan of
Marvell has posted some patches that appear to help some, but were not
in good shape.
The patch posts start here:
http://marc.info/?l=linux-scsi&m=125773523811252&w=2
If there was any chance to get updated versions into the Fedora kernel
so that I could (much) more easily test, that would be a huge help to me.
Thank you for your consideration.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 9 months
[GIT][IMA] fix null pointer deref (fwd)
by James Morris
FYI,
This was introduced in 6c21a7fb492bf7e2c4985937082ce58ddeca84bd, i.e. in
2.6.32-rc5, it seems.
---------- Forwarded message ----------
Date: Sun, 7 Feb 2010 18:34:51 +1100 (EST)
From: James Morris <jmorris(a)namei.org>
To: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Xiaotian Feng <dfeng(a)redhat.com>, Eric Paris <eparis(a)redhat.com>,
linux-kernel(a)vger.kernel.org, linux-security-module(a)vger.kernel.org,
serue(a)linux.vnet.ibm.com, Al Viro <viro(a)zeniv.linux.org.uk>,
Eugene Teo <eugene(a)redhat.com>, Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Subject: [GIT][IMA] fix null pointer deref
Linus,
Please pull this bugfix. I've verified that it fixes the null pointer
deref.
The following changes since commit 29275254caedfedce960cfe6df24b90cb04fe431:
Linus Torvalds (1):
Linux 2.6.33-rc7
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing... for-linus
J. R. Okajima (1):
ima: fix null pointer deref
fs/pipe.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
13 years, 10 months
Backporting virtio-console patches for F13 VirtioSerial feature
by Amit Shah
Hello,
For the VirtioSerial F13 feature, a few patches need to be backported
from the linux-next tree. Rusty has put them up in his local queue and
they'll be pushed to Linus for 2.6.34.
The patches are
42de322 virtio: console: statically initialize virtio_cons
ddb20f0 hvc_console: make the ops pointer const.
14f5b2b virtio: console: We support only one device at a time
502d56a virtio: console: port encapsulation
bd035b3 virtio: console: encapsulate buffer information in a struct
db5f217 virtio: console: ensure add_inbuf can work for multiple ports as well
8bd5af9 virtio: console: introduce a get_inbuf helper to fetch bufs from in_vq
44ee715 virtio: console: use vdev->priv to avoid accessing global var.
982892b virtio: console: don't assume a single console port.
fadef8b virtio: console: remove global var
1d6770b virtio: console: struct ports for multiple ports per device.
468f638 virtio: console: ensure console size is updated on hvc open
9f6d918 virtio: console: Separate out console-specific data into a separate struct
07efa05 virtio: console: Separate out console init into a new function
6191b29 virtio: console: Separate out find_vqs operation into a different function
bfd9f44 virtio: console: Introduce function to hand off data from host to readers
e5b54b53 virtio: console: Introduce a send_buf function for a common path for sending data to host
8d5e5a7 virtio: console: Add a new MULTIPORT feature, support for generic ports
5966ef0 virtio: console: Prepare for writing to / reading from userspace buffers
2e62003 virtio: console: Associate each port with a char device
4954379 virtio: console: Add file operations to ports for open/read/write/poll
606ac80 virtio: console: Ensure only one process can have a port open at a time
c888962 virtio: console: Register with sysfs and create a 'name' attribute for ports
42eefd8 virtio: console: Remove cached data on port close
7c0ba1b virtio: console: Handle port hot-plug
9fe551d virtio: Add ability to detach unused buffers from vrings
d201dd5 virtio: console: Add ability to hot-unplug ports
0f015e0 virtio: console: Add debugfs files for each port to expose debug info
b431126 virtio: console: show error message if hvc_alloc fails for console ports
from today's linux-next tree.
The changes are confined to the drivers/virtio_console.c file (and a few
other drivers/char/hvc* files) which haven't seen changes since 2.6.32,
so these patches should apply as-is to the feodra tree.
A patch that was merged in the 2.6.33 cycle also is needed:
c0cefeb hvc_console: Export (GPL'ed) hvc_remove
I can send these patches out as a patch series if that's easier for
review.
Feature Page
https://fedoraproject.org/wiki/Features/VirtioSerial
More info
http://www.linux-kvm.org/page/VMchannel_Requirements
Amit
--
http://log.amitshah.net/
13 years, 10 months
JBD: Spotted dirty metadata buffer
by Norman Gaywood
I'm getting these messages logged in /var/log/messages. Should I be worried?
The system has had a number of unclean shutdowns due to:
https://bugzilla.redhat.com/show_bug.cgi?id=550724
kernel versions that I've seen this on:
kernel-2.6.31.12-174.2.3.fc12.x86_64
kernel-2.6.32.6-36.fc12.x86_64
These are ext4 filesystems.
Feb 5 15:04:57 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-5, blocknr = 2886175). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:04:57 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69752). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:04:57 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69752). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:05:09 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 1071367). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:05:09 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 1071367). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:05:21 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-5, blocknr = 2886176). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:05:21 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-5, blocknr = 2886176). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:05:22 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69753). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:05:22 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69753). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:15:04 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69754). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:15:04 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69754). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:37:01 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 1071369). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:37:01 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 1071369). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:37:04 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69755). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:37:04 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69755). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:48:04 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-5, blocknr = 2886178). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:48:04 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-5, blocknr = 2886178). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:59:06 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 1071370). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:59:06 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 1071370). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:59:11 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69756). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:59:11 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-2, blocknr = 69756). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:59:13 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-5, blocknr = 2886179). There's a risk of filesystem corruption in case of system crash.
Feb 5 15:59:13 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-5, blocknr = 2886179). There's a risk of filesystem corruption in case of system crash.
--
Norman Gaywood, Computer Systems Officer
University of New England, Armidale, NSW 2351, Australia
ngaywood(a)une.edu.au Phone: +61 (0)2 6773 3337
http://mcs.une.edu.au/~norm Fax: +61 (0)2 6773 3312
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
13 years, 10 months
[PATCH] remove kernel-firmware prereq
by Don Zickus
Now that kernel-firmware is no longer built, can we remove the pre-req so
we don't need to use --nodeps when installing a new kernel? Or am I
missing some other magic when installing?
Cheers,
Don
Index: kernel.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.1911
diff -u -r1.1911 kernel.spec
--- kernel.spec 3 Feb 2010 21:09:14 -0000 1.1911
+++ kernel.spec 5 Feb 2010 20:26:42 -0000
@@ -445,7 +445,7 @@
# Packages that need to be installed before the kernel is, because the %post
# scripts use them.
#
-%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, kernel-firmware >= %{rpmversion}-%{pkg_release}, grubby >= 7.0.4-1
+%define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, grubby >= 7.0.4-1
%if %{with_dracut}
%define initrd_prereq dracut >= 001-7
%else
13 years, 10 months
[Fwd: SECURITY: selinux, fix update_rlimit_cpu parameter] (fwd)
by James Morris
Please consider for 2.6.32.y and Fedora.
-------- Forwarded Message --------
From: Linux Kernel Mailing List <linux-kernel(a)vger.kernel.org>
To: git-commits-head(a)vger.kernel.org
Subject: SECURITY: selinux, fix update_rlimit_cpu parameter
Date: Mon, 4 Jan 2010 20:59:14 GMT
Gitweb: http://git.kernel.org/linus/17740d89785aeb4143770923d67c293849414710
Commit: 17740d89785aeb4143770923d67c293849414710
Parent: 45d28b097280a78893ce25a5d0db41e6a2717853
Author: Jiri Slaby <jirislaby(a)gmail.com>
AuthorDate: Fri Aug 28 10:47:16 2009 +0200
Committer: Jiri Slaby <jslaby(a)suse.cz>
CommitDate: Mon Jan 4 11:27:18 2010 +0100
SECURITY: selinux, fix update_rlimit_cpu parameter
Don't pass current RLIMIT_RTTIME to update_rlimit_cpu() in
selinux_bprm_committing_creds, since update_rlimit_cpu expects
RLIMIT_CPU limit.
Use proper rlim[RLIMIT_CPU].rlim_cur instead to fix that.
Signed-off-by: Jiri Slaby <jirislaby(a)gmail.com>
Acked-by: James Morris <jmorris(a)namei.org>
Cc: Stephen Smalley <sds(a)tycho.nsa.gov>
Cc: Eric Paris <eparis(a)parisplace.org>
Cc: David Howells <dhowells(a)redhat.com>
---
security/selinux/hooks.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 7a374c2..9a2ee84 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2365,7 +2365,7 @@ static void selinux_bprm_committing_creds(struct linux_binprm *bprm)
initrlim = init_task.signal->rlim + i;
rlim->rlim_cur = min(rlim->rlim_max, initrlim->rlim_cur);
}
- update_rlimit_cpu(rlim->rlim_cur);
+ update_rlimit_cpu(current->signal->rlim[RLIMIT_CPU].rlim_cur);
}
}
--
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Stephen Smalley
National Security Agency
13 years, 10 months
F12 panic in bio_integrity_free
by Chuck Anderson
I have a new Dell OptiPlex 960 with a fresh Fedora 12 install, fully
updated, that crashes while doing a dd from /dev/zero to an
aes-xts-plain LUKS mapping. memtest86+ shows no errors after a single
complete pass. From a serial console I was able to capture the
backtrace(s). Anyone have suggestions on how to debug this further?
Thanks.
BUG: unable to handle kernel paging request at 0000000081000024
IP: [<ffffffff811247f5>] bio_integrity_free+0x3d/0x7b
PGD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/kernel/mm/ksm/run
CPU 3
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat bridge stp llc
sunrpc xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter
ip6_tables ipv6 kvm_intel kvm uinput snd_hda_codec_analog
snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device tg3
snd_pcm snd_timer snd iTCO_wdt iTCO_vendor_support e1000e i2c_i801
ppdev soundcore snd_page_alloc shpchp serio_raw parport_pc wmi parport
dcdbas cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt raid1
usb_storage dm_multipath ttm drm_kms_helper drm i2c_algo_bit i2c_core
[last unloaded: speedstep_lib]
Pid: 0, comm: swapper Not tainted 2.6.31.12-174.2.3.fc12.x86_64 #1 OptiPlex 960
RIP: 0010:[<ffffffff811247f5>] [<ffffffff811247f5>]
bio_integrity_free+0x3d/0x7b
RSP: 0018:ffff88002808ea80 EFLAGS: 00010202
RAX: ffff880138fa7d30 RBX: 0000000081000000 RCX: 0000000000aa0049
RDX: 0000000000000001 RSI: ffff88022c80a0c0 RDI: ffff880138fa7cc0
RBP: ffff88002808eaa0 R08: 0000000000000000 R09: 0000000000000004
R10: 0000000000000000 R11: ffffea00050118b8 R12: ffff880138fa7cc0
R13: ffff88022c80a0c0 R14: ffff88022c963800 R15: ffff880138fb3aa0
FS: 0000000000000000(0000) GS:ffff88002808b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000081000024 CR3: 0000000001001000 CR4: 00000000000426e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffff88022f780000, task ffff88022f759780)
Stack:
ffff88002808eab0 ffff880138fa7cc0 ffff88022c80a0c0 ffff880138ef5900
<0> ffff88002808eac0 ffffffff81120023 0000000000000000 ffff880138fa7cc0
<0> ffff88002808ead0 ffffffff81345b85 ffff88002808eae0 ffffffff8111e801
Call Trace:
<IRQ>
[<ffffffff81120023>] bio_free+0x46/0x69
[<ffffffff81345b85>] dm_bio_destructor+0x12/0x14
[<ffffffff8111e801>] bio_put+0x2d/0x2f
[<ffffffff81345f5d>] clone_endio+0x9f/0xb5
[<ffffffff8111e6d6>] bio_endio+0x2b/0x2d
[<ffffffffa005f681>] crypt_dec_pending+0x52/0x79 [dm_crypt]
[<ffffffffa005f855>] crypt_endio+0x9c/0xa5 [dm_crypt]
[<ffffffff8111e6d6>] bio_endio+0x2b/0x2d
[<ffffffff81345da4>] dec_pending+0x13d/0x15c
[<ffffffff81345f67>] clone_endio+0xa9/0xb5
[<ffffffff8111e6d6>] bio_endio+0x2b/0x2d
[<ffffffffa005904f>] raid_end_bio_io+0x37/0x88 [raid1]
[<ffffffffa005a279>] raid1_end_write_request+0x1f3/0x20f [raid1]
[<ffffffff8102d079>] ? hpet_msi_next_event+0x14/0x16
[<ffffffff8111e6d6>] bio_endio+0x2b/0x2d
[<ffffffff811e9177>] req_bio_endio+0x9f/0xbe
[<ffffffff811e9322>] blk_update_request+0x18c/0x32a
[<ffffffff812d9ee0>] ? ata_scsi_qc_complete+0x349/0x358
[<ffffffff811e94e0>] blk_update_bidi_request+0x20/0x59
[<ffffffff811eae51>] blk_end_bidi_request+0x1f/0x5d
[<ffffffff811eaecb>] blk_end_request+0x10/0x12
[<ffffffff812c07ca>] scsi_io_completion+0x1a5/0x416
[<ffffffff812b9c10>] scsi_finish_command+0xf5/0xfe
[<ffffffff812c0b61>] scsi_softirq_done+0x111/0x11a
[<ffffffff811f14a3>] blk_done_softirq+0x7b/0x8b
[<ffffffff81057630>] __do_softirq+0xdd/0x1ad
[<ffffffff81026966>] ? apic_write+0x16/0x18
[<ffffffff81012eac>] call_softirq+0x1c/0x30
[<ffffffff810143fb>] do_softirq+0x47/0x8d
[<ffffffff81057342>] irq_exit+0x44/0x86
[<ffffffff814215d5>] do_IRQ+0xa5/0xbc
[<ffffffff810126d3>] ret_from_intr+0x0/0x11
<EOI>
[<ffffffff8101907f>] ? mwait_idle+0x91/0xae
[<ffffffff8101907f>] ? mwait_idle+0x91/0xae
[<ffffffff81019021>] ? mwait_idle+0x33/0xae
[<ffffffff8141fc39>] ? atomic_notifier_call_chain+0x13/0x15
[<ffffffff81010bb8>] ? enter_idle+0x25/0x27
[<ffffffff81010c60>] ? cpu_idle+0xa6/0xe9
[<ffffffff8141717e>] ? start_secondary+0x1f3/0x234
Code: 48 8b 5f 60 49 89 fc 49 89 f5 48 85 db 75 04 0f 0b eb fe 48 f7
47 18 10 04 00 00 75 0e 48 8b 7b 10 48 85 ff 74 05 e8 6b ef fc ff <8b>
43 24 66 83 f8 06 75 1d 49 8b 75 18 48 89 df e8 09 eb f9 ff
RIP [<ffffffff811247f5>] bio_integrity_free+0x3d/0x7b
RSP <ffff88002808ea80>
CR2: 0000000081000024
---[ end trace ecd6d65d595c0086 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 0, comm: swapper Tainted: G D 2.6.31.12-174.2.3.fc12.x86_64 #1
Call Trace:
<IRQ> [<ffffffff8141b41c>] panic+0x7a/0x12c
[<ffffffff8141e66d>] oops_end+0xb2/0xc2
[<ffffffff8103456d>] no_context+0x1f6/0x205
[<ffffffff810c4a1b>] ? list_add+0x11/0x13
[<ffffffff8103471f>] __bad_area_nosemaphore+0x1a3/0x1c9
[<ffffffff8120a737>] ? __percpu_counter_add+0x47/0x64
[<ffffffff81200132>] ? percpu_counter_add.clone.0+0x14/0x16
[<ffffffff81034758>] bad_area_nosemaphore+0x13/0x15
[<ffffffff8141fa6a>] do_page_fault+0x14a/0x299
[<ffffffff8141db35>] page_fault+0x25/0x30
[<ffffffff811247f5>] ? bio_integrity_free+0x3d/0x7b
[<ffffffff81120023>] bio_free+0x46/0x69
[<ffffffff81345b85>] dm_bio_destructor+0x12/0x14
[<ffffffff8111e801>] bio_put+0x2d/0x2f
[<ffffffff81345f5d>] clone_endio+0x9f/0xb5
[<ffffffff8111e6d6>] bio_endio+0x2b/0x2d
[<ffffffffa005f681>] crypt_dec_pending+0x52/0x79 [dm_crypt]
[<ffffffffa005f855>] crypt_endio+0x9c/0xa5 [dm_crypt]
[<ffffffff8111e6d6>] bio_endio+0x2b/0x2d
[<ffffffff81345da4>] dec_pending+0x13d/0x15c
[<ffffffff81345f67>] clone_endio+0xa9/0xb5
[<ffffffff8111e6d6>] bio_endio+0x2b/0x2d
[<ffffffffa005904f>] raid_end_bio_io+0x37/0x88 [raid1]
[<ffffffffa005a279>] raid1_end_write_request+0x1f3/0x20f [raid1]
[<ffffffff8102d079>] ? hpet_msi_next_event+0x14/0x16
[<ffffffff8111e6d6>] bio_endio+0x2b/0x2d
[<ffffffff811e9177>] req_bio_endio+0x9f/0xbe
[<ffffffff811e9322>] blk_update_request+0x18c/0x32a
[<ffffffff812d9ee0>] ? ata_scsi_qc_complete+0x349/0x358
[<ffffffff811e94e0>] blk_update_bidi_request+0x20/0x59
[<ffffffff811eae51>] blk_end_bidi_request+0x1f/0x5d
[<ffffffff811eaecb>] blk_end_request+0x10/0x12
[<ffffffff812c07ca>] scsi_io_completion+0x1a5/0x416
[<ffffffff812b9c10>] scsi_finish_command+0xf5/0xfe
[<ffffffff812c0b61>] scsi_softirq_done+0x111/0x11a
[<ffffffff811f14a3>] blk_done_softirq+0x7b/0x8b
[<ffffffff81057630>] __do_softirq+0xdd/0x1ad
[<ffffffff81026966>] ? apic_write+0x16/0x18
[<ffffffff81012eac>] call_softirq+0x1c/0x30
[<ffffffff810143fb>] do_softirq+0x47/0x8d
[<ffffffff81057342>] irq_exit+0x44/0x86
[<ffffffff814215d5>] do_IRQ+0xa5/0xbc
[<ffffffff810126d3>] ret_from_intr+0x0/0x11
<EOI> [<ffffffff8101907f>] ? mwait_idle+0x91/0xae
[<ffffffff8101907f>] ? mwait_idle+0x91/0xae
[<ffffffff81019021>] ? mwait_idle+0x33/0xae
[<ffffffff8141fc39>] ? atomic_notifier_call_chain+0x13/0x15
[<ffffffff81010bb8>] ? enter_idle+0x25/0x27
[<ffffffff81010c60>] ? cpu_idle+0xa6/0xe9
[<ffffffff8141717e>] ? start_secondary+0x1f3/0x234
13 years, 10 months
