/* Some toolchains use a `_' prefix for all user symbols. */
-commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511
-Author: stephen hemminger <shemminger@vyatta.com>
-Date: Fri Feb 12 06:58:00 2010 +0000
-
- sky2: dont enable PME legacy mode
-
- This bit is not changed by vendor driver, and should be left alone.
- The documentation implies this a debug bit.
- 0 = WAKE# only asserted when VMAIN not available
- 1 = WAKE# is depend on wake events and independent of VMAIN.
-
- Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
- Signed-off-by: David S. Miller <davem@davemloft.net>
-
-diff --git b/drivers/net/ethernet/marvell/sky2.c a/drivers/net/ethernet/marvell/sky2.c
-index 2494842..edf37aa 100644
---- 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;
- u16 ctrl;
-+ u32 reg1;
-
- /* Bring hardware out of reset */
- sky2_write16(hw, B0_CTST, CS_RST_CLR);
-@@ -786,6 +787,11 @@ static void sky2_wol_init(struct sky2_port *sky2)
- /* Disable PiG firmware */
- sky2_write16(hw, B0_CTST, Y2_HW_WOL_OFF);
-
-+ /* Turn on legacy PCI-Express PME mode */
-+ reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
-+ reg1 |= PCI_Y2_PME_LEGACY;
-+ sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
-+
- /* 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 @@
exit
fi
done
-
-
-
-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
-
-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.
-
-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:
-
---
-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/
-
-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>
+From e820d55cb99dd93ac2dc949cf486bb187e5cd70d Mon Sep 17 00:00:00 2001
+From: Guoqing Jiang <gqjiang@suse.com>
+Date: Wed, 19 Dec 2018 14:19:25 +0800
+Subject: md: fix raid10 hang issue caused by barrier
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When both regular IO and resync IO happen at the same time,
+and if we also need to split regular. Then we can see tasks
+hang due to barrier.
+
+1. resync thread
+[ 1463.757205] INFO: task md1_resync:5215 blocked for more than 480 seconds.
+[ 1463.757207] Not tainted 4.19.5-1-default #1
+[ 1463.757209] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+[ 1463.757212] md1_resync D 0 5215 2 0x80000000
+[ 1463.757216] Call Trace:
+[ 1463.757223] ? __schedule+0x29a/0x880
+[ 1463.757231] ? raise_barrier+0x8d/0x140 [raid10]
+[ 1463.757236] schedule+0x78/0x110
+[ 1463.757243] raise_barrier+0x8d/0x140 [raid10]
+[ 1463.757248] ? wait_woken+0x80/0x80
+[ 1463.757257] raid10_sync_request+0x1f6/0x1e30 [raid10]
+[ 1463.757265] ? _raw_spin_unlock_irq+0x22/0x40
+[ 1463.757284] ? is_mddev_idle+0x125/0x137 [md_mod]
+[ 1463.757302] md_do_sync.cold.78+0x404/0x969 [md_mod]
+[ 1463.757311] ? wait_woken+0x80/0x80
+[ 1463.757336] ? md_rdev_init+0xb0/0xb0 [md_mod]
+[ 1463.757351] md_thread+0xe9/0x140 [md_mod]
+[ 1463.757358] ? _raw_spin_unlock_irqrestore+0x2e/0x60
+[ 1463.757364] ? __kthread_parkme+0x4c/0x70
+[ 1463.757369] kthread+0x112/0x130
+[ 1463.757374] ? kthread_create_worker_on_cpu+0x40/0x40
+[ 1463.757380] ret_from_fork+0x3a/0x50
+
+2. regular IO
+[ 1463.760679] INFO: task kworker/0:8:5367 blocked for more than 480 seconds.
+[ 1463.760683] Not tainted 4.19.5-1-default #1
+[ 1463.760684] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+[ 1463.760687] kworker/0:8 D 0 5367 2 0x80000000
+[ 1463.760718] Workqueue: md submit_flushes [md_mod]
+[ 1463.760721] Call Trace:
+[ 1463.760731] ? __schedule+0x29a/0x880
+[ 1463.760741] ? wait_barrier+0xdd/0x170 [raid10]
+[ 1463.760746] schedule+0x78/0x110
+[ 1463.760753] wait_barrier+0xdd/0x170 [raid10]
+[ 1463.760761] ? wait_woken+0x80/0x80
+[ 1463.760768] raid10_write_request+0xf2/0x900 [raid10]
+[ 1463.760774] ? wait_woken+0x80/0x80
+[ 1463.760778] ? mempool_alloc+0x55/0x160
+[ 1463.760795] ? md_write_start+0xa9/0x270 [md_mod]
+[ 1463.760801] ? try_to_wake_up+0x44/0x470
+[ 1463.760810] raid10_make_request+0xc1/0x120 [raid10]
+[ 1463.760816] ? wait_woken+0x80/0x80
+[ 1463.760831] md_handle_request+0x121/0x190 [md_mod]
+[ 1463.760851] md_make_request+0x78/0x190 [md_mod]
+[ 1463.760860] generic_make_request+0x1c6/0x470
+[ 1463.760870] raid10_write_request+0x77a/0x900 [raid10]
+[ 1463.760875] ? wait_woken+0x80/0x80
+[ 1463.760879] ? mempool_alloc+0x55/0x160
+[ 1463.760895] ? md_write_start+0xa9/0x270 [md_mod]
+[ 1463.760904] raid10_make_request+0xc1/0x120 [raid10]
+[ 1463.760910] ? wait_woken+0x80/0x80
+[ 1463.760926] md_handle_request+0x121/0x190 [md_mod]
+[ 1463.760931] ? _raw_spin_unlock_irq+0x22/0x40
+[ 1463.760936] ? finish_task_switch+0x74/0x260
+[ 1463.760954] submit_flushes+0x21/0x40 [md_mod]
+
+So resync io is waiting for regular write io to complete to
+decrease nr_pending (conf->barrier++ is called before waiting).
+The regular write io splits another bio after call wait_barrier
+which call nr_pending++, then the splitted bio would continue
+with raid10_write_request -> wait_barrier, so the splitted bio
+has to wait for barrier to be zero, then deadlock happens as
+follows.
+
+ resync io regular io
+
+ raise_barrier
+ wait_barrier
+ generic_make_request
+ wait_barrier
+
+To resolve the issue, we need to call allow_barrier to decrease
+nr_pending before generic_make_request since regular IO is not
+issued to underlying devices, and wait_barrier is called again
+to ensure no internal IO happening.
+
+Fixes: fc9977dd069e ("md/raid10: simplify the splitting of requests.")
+Reported-and-tested-by: SiniĊĦa Bandin <sinisa@4net.rs>
+Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.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
-
---
-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/
-
-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>
----
- 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;
+ drivers/md/raid10.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
+index 76c92e31afc0..abb5d382f64d 100644
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -1209,7 +1209,9 @@ static void raid10_read_request(struct mddev *mddev, struct bio *bio,
+ struct bio *split = bio_split(bio, max_sectors,
+ gfp, &conf->bio_split);
+ bio_chain(split, bio);
++ allow_barrier(conf);
+ generic_make_request(bio);
++ wait_barrier(conf);
+ bio = split;
+ r10_bio->master_bio = bio;
+ r10_bio->sectors = max_sectors;
+@@ -1492,7 +1494,9 @@ retry_write:
+ struct bio *split = bio_split(bio, r10_bio->sectors,
+ GFP_NOIO, &conf->bio_split);
+ bio_chain(split, bio);
++ allow_barrier(conf);
+ generic_make_request(bio);
++ wait_barrier(conf);
+ bio = split;
+ r10_bio->master_bio = bio;
}
-
--
-1.7.7.5
-
---
-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/
-
+cgit 1.2-0.3.lf.el7
+
+--- linux-4.14/security/selinux/include/classmap.h 2017-11-12 19:46:13.000000000 +0100
++++ linux-4.20/security/selinux/include/classmap.h 2018-12-24 00:55:59.000000000 +0100
+@@ -238,9 +238,11 @@
+ { "access", NULL } },
+ { "infiniband_endport",
+ { "manage_subnet", NULL } },
++ { "xdp_socket",
++ { COMMON_SOCK_PERMS, NULL } },
+ { NULL }
+ };
+
+-#if PF_MAX > 44
++#if PF_MAX > 45
+ #error New address family defined, please update secclass_map.
+ #endif
projects / packages / kernel.git / blobdiff