---- 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 @@
- #include <stdio.h>
- #include <ctype.h>
- #include "modpost.h"
--#include "../../include/generated/autoconf.h"
-+// PLD architectures don't use CONFIG_SYMBOL_PREFIX
-+//#include "../../include/generated/autoconf.h"
- #include "../../include/linux/license.h"
-
- /* Some toolchains use a `_' prefix for all user symbols. */
+From: Shaohua Li <shli@fb.com>
---- 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 @@
- $cc -print-file-name=lib${lib}.${ext} | grep -q /
- if [ $? -eq 0 ]; then
- echo "-l${lib}"
-+ for libt in tinfow tinfo ; do
-+ $cc -print-file-name=lib${libt}.${ext} | grep -q /
-+ if [ $? -eq 0 ]; then
-+ echo "-l${libt}"
-+ fi
-+ done
- exit
- fi
- done
+Basically this is a copy of commit 001e4a8775f6(ext4: implement cgroup
+writeback support). Tested with a fio test, verified writeback is
+throttled against cgroup io.max write bandwidth, also verified moving
+the fio test to another cgroup and the writeback is throttled against
+new cgroup setting.
-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
-@@ -6927,6 +6927,14 @@ rtl_init_one(struct pci_dev *pdev, const
- 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);
-+ }
-+
- SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops);
- dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
-
-commit 110dc24ad2ae4e9b94b08632fe1eb2fcdff83045
-Author: Dave Chinner <dchinner@redhat.com>
-Date: Tue May 20 08:18:09 2014 +1000
+Cc: Tejun Heo <tj@kernel.org>
+Signed-off-by: Shaohua Li <shli@fb.com>
+---
+ fs/xfs/xfs_aops.c | 2 ++
+ fs/xfs/xfs_super.c | 1 +
+ 2 files changed, 3 insertions(+)
- xfs: log vector rounding leaks log space
-
- The addition of direct formatting of log items into the CIL
- linear buffer added alignment restrictions that the start of each
- vector needed to be 64 bit aligned. Hence padding was added in
- xlog_finish_iovec() to round up the vector length to ensure the next
- vector started with the correct alignment.
-
- This adds a small number of bytes to the size of
- the linear buffer that is otherwise unused. The issue is that we
- then use the linear buffer size to determine the log space used by
- the log item, and this includes the unused space. Hence when we
- account for space used by the log item, it's more than is actually
- written into the iclogs, and hence we slowly leak this space.
-
- This results on log hangs when reserving space, with threads getting
- stuck with these stack traces:
-
- Call Trace:
- [<ffffffff81d15989>] schedule+0x29/0x70
- [<ffffffff8150d3a2>] xlog_grant_head_wait+0xa2/0x1a0
- [<ffffffff8150d55d>] xlog_grant_head_check+0xbd/0x140
- [<ffffffff8150ee33>] xfs_log_reserve+0x103/0x220
- [<ffffffff814b7f05>] xfs_trans_reserve+0x2f5/0x310
- .....
-
- The 4 bytes is significant. Brain Foster did all the hard work in
- tracking down a reproducable leak to inode chunk allocation (it went
- away with the ikeep mount option). His rough numbers were that
- creating 50,000 inodes leaked 11 log blocks. This turns out to be
- roughly 800 inode chunks or 1600 inode cluster buffers. That
- works out at roughly 4 bytes per cluster buffer logged, and at that
- I started looking for a 4 byte leak in the buffer logging code.
-
- What I found was that a struct xfs_buf_log_format structure for an
- inode cluster buffer is 28 bytes in length. This gets rounded up to
- 32 bytes, but the vector length remains 28 bytes. Hence the CIL
- ticket reservation is decremented by 32 bytes (via lv->lv_buf_len)
- for that vector rather than 28 bytes which are written into the log.
-
- The fix for this problem is to separately track the bytes used by
- the log vectors in the item and use that instead of the buffer
- length when accounting for the log space that will be used by the
- formatted log item.
-
- Again, thanks to Brian Foster for doing all the hard work and long
- hours to isolate this leak and make finding the bug relatively
- simple.
-
- Signed-off-by: Dave Chinner <dchinner@redhat.com>
- Reviewed-by: Christoph Hellwig <hch@lst.de>
- Reviewed-by: Brian Foster <bfoster@redhat.com>
- Signed-off-by: Dave Chinner <david@fromorbit.com>
-
-diff --git a/fs/xfs/xfs_log.h b/fs/xfs/xfs_log.h
-index 2c40044..84e0deb 100644
---- a/fs/xfs/xfs_log.h
-+++ b/fs/xfs/xfs_log.h
-@@ -24,7 +24,8 @@ struct xfs_log_vec {
- struct xfs_log_iovec *lv_iovecp; /* iovec array */
- struct xfs_log_item *lv_item; /* owner */
- char *lv_buf; /* formatted buffer */
-- int lv_buf_len; /* size of formatted buffer */
-+ int lv_bytes; /* accounted space in buffer */
-+ int lv_buf_len; /* aligned size of buffer */
- int lv_size; /* size of allocated lv */
- };
-
-@@ -52,15 +53,21 @@ xlog_prepare_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec **vecp,
- return vec->i_addr;
- }
-
-+/*
-+ * We need to make sure the next buffer is naturally aligned for the biggest
-+ * basic data type we put into it. We already accounted for this padding when
-+ * sizing the buffer.
-+ *
-+ * However, this padding does not get written into the log, and hence we have to
-+ * track the space used by the log vectors separately to prevent log space hangs
-+ * due to inaccurate accounting (i.e. a leak) of the used log space through the
-+ * CIL context ticket.
-+ */
- static inline void
- xlog_finish_iovec(struct xfs_log_vec *lv, struct xfs_log_iovec *vec, int len)
- {
-- /*
-- * We need to make sure the next buffer is naturally aligned for the
-- * biggest basic data type we put into it. We already accounted for
-- * this when sizing the buffer.
-- */
- lv->lv_buf_len += round_up(len, sizeof(uint64_t));
-+ lv->lv_bytes += len;
- vec->i_len = len;
- }
-
-diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c
-index 7e54553..de835da 100644
---- a/fs/xfs/xfs_log_cil.c
-+++ b/fs/xfs/xfs_log_cil.c
-@@ -97,7 +97,7 @@ xfs_cil_prepare_item(
- {
- /* Account for the new LV being passed in */
- if (lv->lv_buf_len != XFS_LOG_VEC_ORDERED) {
-- *diff_len += lv->lv_buf_len;
-+ *diff_len += lv->lv_bytes;
- *diff_iovecs += lv->lv_niovecs;
+--- linux-4.19/fs/xfs/xfs_aops.c.org 2018-11-21 10:31:12.348955352 +0100
++++ linux-4.19/fs/xfs/xfs_aops.c 2018-11-21 10:34:35.241764742 +0100
+@@ -613,8 +613,10 @@ xfs_add_to_ioend(
+ list_add(&wpc->ioend->io_list, iolist);
+ wpc->ioend = xfs_alloc_ioend(inode, wpc->io_type, offset,
+ bdev, sector);
++ wbc_init_bio(wbc, wpc->ioend->io_bio);
}
-@@ -111,7 +111,7 @@ xfs_cil_prepare_item(
- else if (old_lv != lv) {
- ASSERT(lv->lv_buf_len != XFS_LOG_VEC_ORDERED);
++ wbc_account_io(wbc, page, len);
+ if (!__bio_try_merge_page(wpc->ioend->io_bio, page, len, poff)) {
+ if (iop)
+ atomic_inc(&iop->write_count);
+diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
+index 584cf2d..aea3bc2 100644
+--- a/fs/xfs/xfs_super.c
++++ b/fs/xfs/xfs_super.c
+@@ -1634,6 +1634,7 @@ xfs_fs_fill_super(
+ sb->s_max_links = XFS_MAXLINK;
+ sb->s_time_gran = 1;
+ set_posix_acl_flag(sb);
++ sb->s_iflags |= SB_I_CGROUPWB;
-- *diff_len -= old_lv->lv_buf_len;
-+ *diff_len -= old_lv->lv_bytes;
- *diff_iovecs -= old_lv->lv_niovecs;
- kmem_free(old_lv);
+ /* version 5 superblocks support inode version counters. */
+ if (XFS_SB_VERSION_NUM(&mp->m_sb) == XFS_SB_VERSION_5)
+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>
+---
+ 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;
}
-@@ -239,7 +239,7 @@ xlog_cil_insert_format_items(
- * that the space reservation accounting is correct.
- */
- *diff_iovecs -= lv->lv_niovecs;
-- *diff_len -= lv->lv_buf_len;
-+ *diff_len -= lv->lv_bytes;
- } else {
- /* allocate new data chunk */
- lv = kmem_zalloc(buf_size, KM_SLEEP|KM_NOFS);
-@@ -259,6 +259,7 @@ xlog_cil_insert_format_items(
-
- /* The allocated data region lies beyond the iovec region */
- lv->lv_buf_len = 0;
-+ lv->lv_bytes = 0;
- lv->lv_buf = (char *)lv + buf_size - nbytes;
- ASSERT(IS_ALIGNED((unsigned long)lv->lv_buf, sizeof(uint64_t)));
-
+--
+cgit 1.2-0.3.lf.el7
+
+
projects / packages / kernel.git / blobdiff