---- linux-2.6.32/drivers/infiniband/Kconfig~ 2009-12-05 00:26:03.663774916 +0100
-+++ linux-2.6.32/drivers/infiniband/Kconfig 2009-12-05 00:26:05.914179759 +0100
-@@ -37,7 +37,6 @@
- config INFINIBAND_ADDR_TRANS
- bool
- depends on INET
-- depends on !(INFINIBAND = y && IPV6 = m)
- default y
-
- source "drivers/infiniband/hw/mthca/Kconfig"
--- linux-2.6.33/scripts/mod/modpost.c~ 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/scripts/mod/modpost.c 2010-03-07 14:26:47.242168558 +0100
@@ -15,7 +15,8 @@
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-diff --git b/drivers/net/sky2.c a/drivers/net/sky2.c
+diff --git b/drivers/net/ethernet/marvell/sky2.c a/drivers/net/ethernet/marvell/sky2.c
index 2494842..edf37aa 100644
---- b/drivers/net/sky2.c
-+++ a/drivers/net/sky2.c
+--- b/drivers/net/ethernet/marvell/sky2.c
++++ a/drivers/net/ethernet/marvell/sky2.c
@@ -733,6 +733,7 @@ static void sky2_wol_init(struct sky2_port *sky2)
unsigned port = sky2->port;
enum flow_control save_mode;
/* block receiver */
sky2_write8(hw, SK_REG(port, RX_GMF_CTRL_T), GMF_RST_SET);
}
-On Sat, 2 Jul 2011, Andi Kleen wrote:
-
-> > The problem is that blk_peek_request() calls scsi_prep_fn(), which
-> > does this:
-> >
-> > struct scsi_device *sdev = q->queuedata;
-> > int ret = BLKPREP_KILL;
-> >
-> > if (req->cmd_type == REQ_TYPE_BLOCK_PC)
-> > ret = scsi_setup_blk_pc_cmnd(sdev, req);
-> > return scsi_prep_return(q, req, ret);
-> >
-> > It doesn't check to see if sdev is NULL, nor does
-> > scsi_setup_blk_pc_cmnd(). That accounts for this error:
->
-> I actually added a NULL check in scsi_setup_blk_pc_cmnd early on,
-> but that just caused RCU CPU stalls afterwards and then eventually
-> a hung system.
-
-The RCU problem is likely to be a separate issue. It might even be a
-result of the use-after-free problem with the elevator.
-
-At any rate, it's clear that the crash in the refcounting log you
-posted occurred because scsi_setup_blk_pc_cmnd() called
-scsi_prep_state_check(), which tried to dereference the NULL pointer.
-
-Would you like to try this patch to see if it fixes the problem? As I
-said before, I'm not certain it's the best thing to do, but it worked
-on my system.
-
-Alan Stern
-
-
-
-
-Index: usb-3.0/drivers/scsi/scsi_lib.c
-===================================================================
---- usb-3.0.orig/drivers/scsi/scsi_lib.c
-+++ usb-3.0/drivers/scsi/scsi_lib.c
-@@ -1247,6 +1247,8 @@ int scsi_prep_fn(struct request_queue *q
- struct scsi_device *sdev = q->queuedata;
- int ret = BLKPREP_KILL;
-
-+ if (!sdev)
-+ return ret;
- if (req->cmd_type == REQ_TYPE_BLOCK_PC)
- ret = scsi_setup_blk_pc_cmnd(sdev, req);
- return scsi_prep_return(q, req, ret);
-Index: usb-3.0/drivers/scsi/scsi_sysfs.c
-===================================================================
---- usb-3.0.orig/drivers/scsi/scsi_sysfs.c
-+++ usb-3.0/drivers/scsi/scsi_sysfs.c
-@@ -322,6 +322,8 @@ static void scsi_device_dev_release_user
- kfree(evt);
- }
-
-+ /* Freeing the queue signals to block that we're done */
-+ scsi_free_queue(sdev->request_queue);
- blk_put_queue(sdev->request_queue);
- /* NULL queue means the device can't be used */
- sdev->request_queue = NULL;
-@@ -936,8 +938,6 @@ void __scsi_remove_device(struct scsi_de
- /* cause the request function to reject all I/O requests */
- sdev->request_queue->queuedata = NULL;
-
-- /* Freeing the queue signals to block that we're done */
-- scsi_free_queue(sdev->request_queue);
- put_device(dev);
- }
-
-
-
---
-To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at http://vger.kernel.org/majordomo-info.html
-Please read the FAQ at http://www.tux.org/lkml/
--- linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh~ 2011-07-22 04:17:23.000000000 +0200
+++ linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh 2011-08-25 21:26:04.799150642 +0200
@@ -9,6 +9,12 @@
done
-Fixes a possible memory corruption when the link is larger than
-MAXPATHLEN and XFS_DEBUG is not enabled. This also remove the
-S_ISLNK assert, since the inode mode is checked previously in
-xfs_readlink_by_handle() and via VFS.
-Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
----
- fs/xfs/xfs_vnodeops.c | 11 ++++++++---
- 1 files changed, 8 insertions(+), 3 deletions(-)
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
+Subject: [PATCH] small fixes to 3.3 (and 3.2) CPU hotplug code. (v1)
+Date: Wed, 1 Feb 2012 16:16:38 -0500
-diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c
-index 51fc429..c3288be 100644
---- a/fs/xfs/xfs_vnodeops.c
-+++ b/fs/xfs/xfs_vnodeops.c
-@@ -123,13 +123,18 @@ xfs_readlink(
-
- xfs_ilock(ip, XFS_ILOCK_SHARED);
-
-- ASSERT(S_ISLNK(ip->i_d.di_mode));
-- ASSERT(ip->i_d.di_size <= MAXPATHLEN);
--
- pathlen = ip->i_d.di_size;
- if (!pathlen)
- goto out;
-
-+ if (pathlen > MAXPATHLEN) {
-+ xfs_alert(mp, "%s: inode (%llu) symlink length (%d) too long",
-+ __func__, (unsigned long long)ip->i_ino, pathlen);
-+ ASSERT(0);
-+ return XFS_ERROR(EFSCORRUPTED);
-+ }
-+
-+
- if (ip->i_df.if_flags & XFS_IFINLINE) {
- memcpy(link, ip->i_df.if_u1.if_data, pathlen);
- link[pathlen] = '\0';
---
-1.7.6.2
-
-_______________________________________________
-xfs mailing list
-xfs@oss.sgi.com
-http://oss.sgi.com/mailman/listinfo/xfs
-
-An integer overflow will happen on 64bit archs if task's sum of rss, swapents
-and nr_ptes exceeds (2^31)/1000 value. This was introduced by commit
-
-f755a04 oom: use pte pages in OOM score
-
-where the oom score computation was divided into several steps and it's no
-longer computed as one expression in unsigned long(rss, swapents, nr_pte are
-unsigned long), where the result value assigned to points(int) is in
-range(1..1000). So there could be an int overflow while computing
-
-176 points *= 1000;
-
-and points may have negative value. Meaning the oom score for a mem hog task
-will be one.
-
-196 if (points <= 0)
-197 return 1;
+While I was playing with 'xm vcpu-set X N' I realized that the VCPU hotplug
+code in 3.2 spews tons of messages. Found out that we were missing an preempt_*
+call. While at it, I fixed also an annoying message ("XENBUS: Unable to ..")
+that shows up during bootup.
-For example:
-[ 3366] 0 3366 35390480 24303939 5 0 0 oom01
-Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child
+Anyhow, these are going for 3.3 and CC-ing stable on the:
+ [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG:
-Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical
-memory, but it's oom score is one.
+--
+To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at http://vger.kernel.org/majordomo-info.html
+Please read the FAQ at http://www.tux.org/lkml/
-In this situation the mem hog task is skipped and oom killer kills another and
-most probably innocent task with oom score greater than one.
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
+Subject: [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
+Date: Wed, 1 Feb 2012 16:16:39 -0500
+
+When a user offlines a VCPU and then onlines it, we get:
+
+NMI watchdog disabled (cpu2): hardware events not enabled
+BUG: scheduling while atomic: swapper/2/0/0x00000002
+Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod libcrc32c crc32c radeon fbco
+ ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs [last unloaded:
+
+Pid: 0, comm: swapper/2 Tainted: G O 3.2.0phase15.1-00003-gd6f7f5b-dirty #4
+Call Trace:
+ [<ffffffff81070571>] __schedule_bug+0x61/0x70
+ [<ffffffff8158eb78>] __schedule+0x798/0x850
+ [<ffffffff8158ed6a>] schedule+0x3a/0x50
+ [<ffffffff810349be>] cpu_idle+0xbe/0xe0
+ [<ffffffff81583599>] cpu_bringup_and_idle+0xe/0x10
+
+The reason for this should be obvious from this call-chain:
+cpu_bringup_and_idle:
+ \- cpu_bringup
+ | \-[preempt_disable]
+ |
+ |- cpu_idle
+ \- play_dead [assuming the user offlined the VCPU]
+ | \
+ | +- (xen_play_dead)
+ | \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
+ | | onlines it starts from here]
+ | \- cpu_bringup [preempt_disable]
+ |
+ +- preempt_enable_no_reschedule()
+ +- schedule()
+ \- preempt_enable()
+
+So we have two preempt_disble() and one preempt_enable(). Calling
+preempt_enable() after the cpu_bringup() in the xen_play_dead
+fixes the imbalance.
+
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+---
+ arch/x86/xen/smp.c | 7 +++++++
+ 1 files changed, 7 insertions(+), 0 deletions(-)
+
+diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
+index 041d4fe..501d4e0 100644
+--- a/arch/x86/xen/smp.c
++++ b/arch/x86/xen/smp.c
+@@ -409,6 +409,13 @@ static void __cpuinit xen_play_dead(void) /* used only with HOTPLUG_CPU */
+ play_dead_common();
+ HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
+ cpu_bringup();
++ /*
++ * Balance out the preempt calls - as we are running in cpu_idle
++ * loop which has been called at bootup from cpu_bringup_and_idle.
++ * The cpucpu_bringup_and_idle called cpu_bringup which made a
++ * preempt_disable() So this preempt_enable will balance it out.
++ */
++ preempt_enable();
+ }
+
+ #else /* !CONFIG_HOTPLUG_CPU */
+--
+1.7.7.5
-The points variable should be of type long instead of int to prevent the int
-overflow.
+--
+To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at http://vger.kernel.org/majordomo-info.html
+Please read the FAQ at http://www.tux.org/lkml/
-Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
+Subject: [PATCH 2/2] xen/bootup: During bootup suppress XENBUS: Unable to read cpu state
+Date: Wed, 1 Feb 2012 16:16:40 -0500
+
+When the initial domain starts, it prints (depending on the
+amount of CPUs) a slew of
+XENBUS: Unable to read cpu state
+XENBUS: Unable to read cpu state
+XENBUS: Unable to read cpu state
+XENBUS: Unable to read cpu state
+
+which provide no useful information - as the error is a valid
+issue - but not on the initial domain. The reason is that the
+XenStore is not accessible at that time (it is after all the
+first guest) so the CPU hotplug watch cannot parse "availability/cpu"
+attribute.
+
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
- mm/oom_kill.c | 2 +-
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-diff --git a/mm/oom_kill.c b/mm/oom_kill.c
-index 626303b..e9a1785 100644
---- a/mm/oom_kill.c
-+++ b/mm/oom_kill.c
-@@ -162,7 +162,7 @@ static bool oom_unkillable_task(struct task_struct *p,
- unsigned int oom_badness(struct task_struct *p, struct mem_cgroup *mem,
- const nodemask_t *nodemask, unsigned long totalpages)
- {
-- int points;
-+ long points;
+ drivers/xen/cpu_hotplug.c | 3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
+index 14e2d99..4dcfced 100644
+--- a/drivers/xen/cpu_hotplug.c
++++ b/drivers/xen/cpu_hotplug.c
+@@ -30,7 +30,8 @@ static int vcpu_online(unsigned int cpu)
+ sprintf(dir, "cpu/%u", cpu);
+ err = xenbus_scanf(XBT_NIL, dir, "availability", "%s", state);
+ if (err != 1) {
+- printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
++ if (!xen_initial_domain())
++ printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
+ return err;
+ }
- if (oom_unkillable_task(p, mem, nodemask))
- return 0;
--
-1.7.6.4
+1.7.7.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
+diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
+index 7a0c800..ec5ebbb 100644
+--- a/drivers/net/ethernet/realtek/r8169.c
++++ b/drivers/net/ethernet/realtek/r8169.c
+@@ -4103,6 +4103,14 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
+ /* Get MAC address */
+ for (i = 0; i < ETH_ALEN; i++)
+ dev->dev_addr[i] = RTL_R8(MAC0 + i);
++
++ if (!is_valid_ether_addr(dev->dev_addr)) {
++ /* Report it and use a random ethernet address instead */
++ netdev_err(dev, "Invalid MAC address: %pM\n", dev->dev_addr);
++ random_ether_addr(dev->dev_addr);
++ netdev_info(dev, "Using random MAC address: %pM\n",
++ dev->dev_addr);
++ }
+ memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
+
+ SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops);
+--
+1.7.7.3
+
+
projects / packages / kernel.git / blobdiff