* IMPORTANT MAIL TO YOU
From: verifelaw @ 2016-04-18 11:09 UTC (permalink / raw)
I am Capt. Lawrence Tyman, an officer in US Army,and also a West Point
Graduate, serving in the Military with the 82nd Air Borne Division
Peace keeping force deployed from Afganistan to Syria.
We were moved to Syria from Iraq as the last batch just left,and i
really need your help in assisting me with the safe keeping of 1 military
trunk box contain funds amount of $10.2M which i secured on a raiding we carried out in
January in one of the chief Syrian IsIs base which i headed the squard as the
Captain. With every possible arrangement to lift this box out, is intended to arrive
Belgium from there a diplomat will deliver it to your designated location
I hope you can be trusted? You will be rewarded handsomely if you could help
me secure the funds until I conclude my service here in 3 month to meet you while we can
plan head to head on a good and profitable business or company i can invest my funds in your country.
If you can be trusted and willing to support me in securing this safely kindly indicate
by Letting me know this (1) Your name (2) Your address (3) Age (4) Occupation and
i will explain further when i get a response from you
kindly contact me in this my private email address below: lawrencetyman@gmx.com
Regards,
Capt. Lawrence Tyman
^ permalink raw reply
* Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
From: Mike Snitzer @ 2016-04-18 13:36 UTC (permalink / raw)
To: Baolin Wang
Cc: Herbert Xu, David Miller, Alasdair G Kergon, Jens Axboe, dm-devel,
Andrew Morton, david.s.gordon, Tom Lendacky, Robert Jarzmik,
Masahiro Yamada, smueller, tadeusz.struk, Masanari Iida, shli,
Mark Brown, Linus Walleij, Arnd Bergmann, LKML, linux-crypto,
linux-raid, Milan Broz
In-Reply-To: <CAMz4ku+hXbgx1+YcdJWbCBW7KoeFisk5qcquAAg0fD5Qw5XDFQ@mail.gmail.com>
On Mon, Apr 18 2016 at 1:31am -0400,
Baolin Wang <baolin.wang@linaro.org> wrote:
> Hi Herbert,
>
> On 15 April 2016 at 21:48, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > On Tue, Mar 15, 2016 at 03:47:58PM +0800, Baolin Wang wrote:
> >> Now some cipher hardware engines prefer to handle bulk block by merging requests
> >> to increase the block size and thus increase the hardware engine processing speed.
> >>
> >> This patchset introduces request bulk mode to help the crypto hardware drivers
> >> improve in efficiency.
> >
> > Could you please explain why this merging can't be done in dm-crypt
> > instead?
>
> We've tried to do this in dm-crypt, but it failed.
> The dm-crypt maintainer explained to me that I should optimize the
> driver, not add strange hw-dependent crypto modes to dm-crypt, this is
> not the first crypto accelerator that is just not suited for this kind
> of use.
As a DM mainatiner my only contribution to this line of discussion was
relative to your proposal to train the dm-crypt target (which is
bio-based) to also provide request-based support, see:
https://www.redhat.com/archives/dm-devel/2015-November/msg00112.html
But follow-up discussion occured, primarily with Milan Broz, which led
to this bulk mode support in the crypto layer. Pretty strange Milan
wasn't cc'd on your patchset posting (I've now cc'd him).
Mike
^ permalink raw reply
* Re: [PATCH 16/42] nilfs: set bi_op to REQ_OP
From: Ryusuke Konishi @ 2016-04-18 16:04 UTC (permalink / raw)
To: Mike Christie
Cc: linux-f2fs-devel, linux-ext4, konrad.wilk, drbd-dev,
philipp.reisner, lars.ellenberg, linux-raid, dm-devel,
linux-fsdevel, linux-bcache, linux-block, linux-kernel,
linux-scsi, linux-mtd, target-devel, linux-btrfs, osd-dev, xfs,
ocfs2-devel
In-Reply-To: <1460747777-8479-17-git-send-email-mchristi@redhat.com>
On Fri, 15 Apr 2016 14:15:51 -0500, mchristi@redhat.com wrote:
> From: Mike Christie <mchristi@redhat.com>
>
> This patch has nilfs use bio->bi_op for REQ_OPs and rq_flag_bits
> to bio->bi_rw.
>
> Signed-off-by: Mike Christie <mchristi@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Hannes Reinecke <hare@suse.com>
> ---
> fs/nilfs2/segbuf.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
Looks good to me.
Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Thanks,
Ryuske Konishi
>
> diff --git a/fs/nilfs2/segbuf.c b/fs/nilfs2/segbuf.c
> index 7666f1d..7b13e14 100644
> --- a/fs/nilfs2/segbuf.c
> +++ b/fs/nilfs2/segbuf.c
> @@ -350,7 +350,8 @@ static void nilfs_end_bio_write(struct bio *bio)
> }
>
> static int nilfs_segbuf_submit_bio(struct nilfs_segment_buffer *segbuf,
> - struct nilfs_write_info *wi, int mode)
> + struct nilfs_write_info *wi, int mode,
> + int mode_flags)
> {
> struct bio *bio = wi->bio;
> int err;
> @@ -368,7 +369,8 @@ static int nilfs_segbuf_submit_bio(struct nilfs_segment_buffer *segbuf,
>
> bio->bi_end_io = nilfs_end_bio_write;
> bio->bi_private = segbuf;
> - bio->bi_rw = mode;
> + bio->bi_op = mode;
> + bio->bi_rw = mode_flags;
> submit_bio(bio);
> segbuf->sb_nbio++;
>
> @@ -442,7 +444,7 @@ static int nilfs_segbuf_submit_bh(struct nilfs_segment_buffer *segbuf,
> return 0;
> }
> /* bio is FULL */
> - err = nilfs_segbuf_submit_bio(segbuf, wi, mode);
> + err = nilfs_segbuf_submit_bio(segbuf, wi, mode, 0);
> /* never submit current bh */
> if (likely(!err))
> goto repeat;
> @@ -466,19 +468,19 @@ static int nilfs_segbuf_write(struct nilfs_segment_buffer *segbuf,
> {
> struct nilfs_write_info wi;
> struct buffer_head *bh;
> - int res = 0, rw = WRITE;
> + int res = 0;
>
> wi.nilfs = nilfs;
> nilfs_segbuf_prepare_write(segbuf, &wi);
>
> list_for_each_entry(bh, &segbuf->sb_segsum_buffers, b_assoc_buffers) {
> - res = nilfs_segbuf_submit_bh(segbuf, &wi, bh, rw);
> + res = nilfs_segbuf_submit_bh(segbuf, &wi, bh, REQ_OP_WRITE);
> if (unlikely(res))
> goto failed_bio;
> }
>
> list_for_each_entry(bh, &segbuf->sb_payload_buffers, b_assoc_buffers) {
> - res = nilfs_segbuf_submit_bh(segbuf, &wi, bh, rw);
> + res = nilfs_segbuf_submit_bh(segbuf, &wi, bh, REQ_OP_WRITE);
> if (unlikely(res))
> goto failed_bio;
> }
> @@ -488,8 +490,8 @@ static int nilfs_segbuf_write(struct nilfs_segment_buffer *segbuf,
> * Last BIO is always sent through the following
> * submission.
> */
> - rw |= REQ_SYNC;
> - res = nilfs_segbuf_submit_bio(segbuf, &wi, rw);
> + res = nilfs_segbuf_submit_bio(segbuf, &wi, REQ_OP_WRITE,
> + REQ_SYNC);
> }
>
> failed_bio:
> --
> 2.7.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [dm-devel] [PATCH 04/42] fs: have submit_bh users pass in op and flags separately
From: Ryusuke Konishi @ 2016-04-18 16:30 UTC (permalink / raw)
To: Mike Christie
Cc: linux-f2fs-devel, linux-ext4, konrad.wilk, drbd-dev,
philipp.reisner, lars.ellenberg, linux-raid, dm-devel,
linux-fsdevel, linux-bcache, linux-block, linux-kernel,
linux-scsi, linux-mtd, target-devel, linux-btrfs, osd-dev, xfs,
ocfs2-devel
In-Reply-To: <1460716802-2294-5-git-send-email-mchristi@redhat.com>
On Fri, 15 Apr 2016 05:39:24 -0500, mchristi@redhat.com wrote:
> From: Mike Christie <mchristi@redhat.com>
>
> This has submit_bh users pass in the operation and flags separately,
> so submit_bh_wbc can setup bio->bi_op and bio-bi_rw on the bio that
> is submitted.
>
> Signed-off-by: Mike Christie <mchristi@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Hannes Reinecke <hare@suse.com>
> ---
Looks good with regard to nilfs2.
Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
> drivers/md/bitmap.c | 4 ++--
> fs/btrfs/check-integrity.c | 24 ++++++++++----------
> fs/btrfs/check-integrity.h | 2 +-
> fs/btrfs/disk-io.c | 4 ++--
> fs/buffer.c | 54 +++++++++++++++++++++++----------------------
> fs/ext4/balloc.c | 2 +-
> fs/ext4/ialloc.c | 2 +-
> fs/ext4/inode.c | 2 +-
> fs/ext4/mmp.c | 4 ++--
> fs/fat/misc.c | 2 +-
> fs/gfs2/bmap.c | 2 +-
> fs/gfs2/dir.c | 2 +-
> fs/gfs2/meta_io.c | 6 ++---
> fs/jbd2/commit.c | 6 ++---
> fs/jbd2/journal.c | 8 +++----
> fs/nilfs2/btnode.c | 6 ++---
> fs/nilfs2/btnode.h | 2 +-
> fs/nilfs2/btree.c | 6 +++--
> fs/nilfs2/gcinode.c | 5 +++--
> fs/nilfs2/mdt.c | 11 ++++-----
> fs/ntfs/aops.c | 6 ++---
> fs/ntfs/compress.c | 2 +-
> fs/ntfs/file.c | 2 +-
> fs/ntfs/logfile.c | 2 +-
> fs/ntfs/mft.c | 4 ++--
> fs/ocfs2/buffer_head_io.c | 8 +++----
> fs/reiserfs/inode.c | 4 ++--
> fs/reiserfs/journal.c | 6 ++---
> fs/ufs/util.c | 2 +-
> include/linux/buffer_head.h | 9 ++++----
> 30 files changed, 103 insertions(+), 96 deletions(-)
>
> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
> index 3fe86b5..8b2e16f 100644
> --- a/drivers/md/bitmap.c
> +++ b/drivers/md/bitmap.c
> @@ -294,7 +294,7 @@ static void write_page(struct bitmap *bitmap, struct page *page, int wait)
> atomic_inc(&bitmap->pending_writes);
> set_buffer_locked(bh);
> set_buffer_mapped(bh);
> - submit_bh(WRITE | REQ_SYNC, bh);
> + submit_bh(REQ_OP_WRITE, REQ_SYNC, bh);
> bh = bh->b_this_page;
> }
>
> @@ -389,7 +389,7 @@ static int read_page(struct file *file, unsigned long index,
> atomic_inc(&bitmap->pending_writes);
> set_buffer_locked(bh);
> set_buffer_mapped(bh);
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
> }
> block++;
> bh = bh->b_this_page;
> diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
> index 9400acd..f82190f 100644
> --- a/fs/btrfs/check-integrity.c
> +++ b/fs/btrfs/check-integrity.c
> @@ -2856,12 +2856,12 @@ static struct btrfsic_dev_state *btrfsic_dev_state_lookup(
> return ds;
> }
>
> -int btrfsic_submit_bh(int rw, struct buffer_head *bh)
> +int btrfsic_submit_bh(int op, int op_flags, struct buffer_head *bh)
> {
> struct btrfsic_dev_state *dev_state;
>
> if (!btrfsic_is_initialized)
> - return submit_bh(rw, bh);
> + return submit_bh(op, op_flags, bh);
>
> mutex_lock(&btrfsic_mutex);
> /* since btrfsic_submit_bh() might also be called before
> @@ -2870,26 +2870,26 @@ int btrfsic_submit_bh(int rw, struct buffer_head *bh)
>
> /* Only called to write the superblock (incl. FLUSH/FUA) */
> if (NULL != dev_state &&
> - (rw & WRITE) && bh->b_size > 0) {
> + (op == REQ_OP_WRITE) && bh->b_size > 0) {
> u64 dev_bytenr;
>
> dev_bytenr = 4096 * bh->b_blocknr;
> if (dev_state->state->print_mask &
> BTRFSIC_PRINT_MASK_SUBMIT_BIO_BH)
> printk(KERN_INFO
> - "submit_bh(rw=0x%x, blocknr=%llu (bytenr %llu),"
> - " size=%zu, data=%p, bdev=%p)\n",
> - rw, (unsigned long long)bh->b_blocknr,
> + "submit_bh(op=0x%x,0x%x, blocknr=%llu "
> + "(bytenr %llu), size=%zu, data=%p, bdev=%p)\n",
> + op, op_flags, (unsigned long long)bh->b_blocknr,
> dev_bytenr, bh->b_size, bh->b_data, bh->b_bdev);
> btrfsic_process_written_block(dev_state, dev_bytenr,
> &bh->b_data, 1, NULL,
> - NULL, bh, rw);
> - } else if (NULL != dev_state && (rw & REQ_FLUSH)) {
> + NULL, bh, op_flags);
> + } else if (NULL != dev_state && (op_flags & REQ_FLUSH)) {
> if (dev_state->state->print_mask &
> BTRFSIC_PRINT_MASK_SUBMIT_BIO_BH)
> printk(KERN_INFO
> - "submit_bh(rw=0x%x FLUSH, bdev=%p)\n",
> - rw, bh->b_bdev);
> + "submit_bh(op=0x%x,0x%x FLUSH, bdev=%p)\n",
> + op, op_flags, bh->b_bdev);
> if (!dev_state->dummy_block_for_bio_bh_flush.is_iodone) {
> if ((dev_state->state->print_mask &
> (BTRFSIC_PRINT_MASK_SUBMIT_BIO_BH |
> @@ -2907,7 +2907,7 @@ int btrfsic_submit_bh(int rw, struct buffer_head *bh)
> block->never_written = 0;
> block->iodone_w_error = 0;
> block->flush_gen = dev_state->last_flush_gen + 1;
> - block->submit_bio_bh_rw = rw;
> + block->submit_bio_bh_rw = op_flags;
> block->orig_bio_bh_private = bh->b_private;
> block->orig_bio_bh_end_io.bh = bh->b_end_io;
> block->next_in_same_bio = NULL;
> @@ -2916,7 +2916,7 @@ int btrfsic_submit_bh(int rw, struct buffer_head *bh)
> }
> }
> mutex_unlock(&btrfsic_mutex);
> - return submit_bh(rw, bh);
> + return submit_bh(op, op_flags, bh);
> }
>
> static void __btrfsic_submit_bio(struct bio *bio)
> diff --git a/fs/btrfs/check-integrity.h b/fs/btrfs/check-integrity.h
> index c04e249..f78dff1 100644
> --- a/fs/btrfs/check-integrity.h
> +++ b/fs/btrfs/check-integrity.h
> @@ -20,7 +20,7 @@
> #define __BTRFS_CHECK_INTEGRITY__
>
> #ifdef CONFIG_BTRFS_FS_CHECK_INTEGRITY
> -int btrfsic_submit_bh(int rw, struct buffer_head *bh);
> +int btrfsic_submit_bh(int op, int op_flags, struct buffer_head *bh);
> void btrfsic_submit_bio(struct bio *bio);
> int btrfsic_submit_bio_wait(struct bio *bio);
> #else
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index 0bd25e4..9a13c85 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -3410,9 +3410,9 @@ static int write_dev_supers(struct btrfs_device *device,
> * to go down lazy.
> */
> if (i == 0)
> - ret = btrfsic_submit_bh(WRITE_FUA, bh);
> + ret = btrfsic_submit_bh(REQ_OP_WRITE, WRITE_FUA, bh);
> else
> - ret = btrfsic_submit_bh(WRITE_SYNC, bh);
> + ret = btrfsic_submit_bh(REQ_OP_WRITE, WRITE_SYNC, bh);
> if (ret)
> errors++;
> }
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 7ed7869..1e1a474 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -45,7 +45,7 @@
> #include <trace/events/block.h>
>
> static int fsync_buffers_list(spinlock_t *lock, struct list_head *list);
> -static int submit_bh_wbc(int rw, struct buffer_head *bh,
> +static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
> unsigned long bio_flags,
> struct writeback_control *wbc);
>
> @@ -1225,7 +1225,7 @@ static struct buffer_head *__bread_slow(struct buffer_head *bh)
> } else {
> get_bh(bh);
> bh->b_end_io = end_buffer_read_sync;
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
> wait_on_buffer(bh);
> if (buffer_uptodate(bh))
> return bh;
> @@ -1697,7 +1697,7 @@ static int __block_write_full_page(struct inode *inode, struct page *page,
> struct buffer_head *bh, *head;
> unsigned int blocksize, bbits;
> int nr_underway = 0;
> - int write_op = (wbc->sync_mode == WB_SYNC_ALL ? WRITE_SYNC : WRITE);
> + int write_flags = (wbc->sync_mode == WB_SYNC_ALL ? WRITE_SYNC : 0);
>
> head = create_page_buffers(page, inode,
> (1 << BH_Dirty)|(1 << BH_Uptodate));
> @@ -1786,7 +1786,7 @@ static int __block_write_full_page(struct inode *inode, struct page *page,
> do {
> struct buffer_head *next = bh->b_this_page;
> if (buffer_async_write(bh)) {
> - submit_bh_wbc(write_op, bh, 0, wbc);
> + submit_bh_wbc(REQ_OP_WRITE, write_flags, bh, 0, wbc);
> nr_underway++;
> }
> bh = next;
> @@ -1840,7 +1840,7 @@ recover:
> struct buffer_head *next = bh->b_this_page;
> if (buffer_async_write(bh)) {
> clear_buffer_dirty(bh);
> - submit_bh_wbc(write_op, bh, 0, wbc);
> + submit_bh_wbc(REQ_OP_WRITE, write_flags, bh, 0, wbc);
> nr_underway++;
> }
> bh = next;
> @@ -2248,7 +2248,7 @@ int block_read_full_page(struct page *page, get_block_t *get_block)
> if (buffer_uptodate(bh))
> end_buffer_async_read(bh, 1);
> else
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
> }
> return 0;
> }
> @@ -2582,7 +2582,7 @@ int nobh_write_begin(struct address_space *mapping,
> if (block_start < from || block_end > to) {
> lock_buffer(bh);
> bh->b_end_io = end_buffer_read_nobh;
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
> nr_reads++;
> }
> }
> @@ -2949,7 +2949,7 @@ static void end_bio_bh_io_sync(struct bio *bio)
> * errors, this only handles the "we need to be able to
> * do IO at the final sector" case.
> */
> -void guard_bio_eod(int rw, struct bio *bio)
> +void guard_bio_eod(int op, struct bio *bio)
> {
> sector_t maxsector;
> struct bio_vec *bvec = &bio->bi_io_vec[bio->bi_vcnt - 1];
> @@ -2979,13 +2979,13 @@ void guard_bio_eod(int rw, struct bio *bio)
> bvec->bv_len -= truncated_bytes;
>
> /* ..and clear the end of the buffer for reads */
> - if ((rw & RW_MASK) == READ) {
> + if (op == REQ_OP_READ) {
> zero_user(bvec->bv_page, bvec->bv_offset + bvec->bv_len,
> truncated_bytes);
> }
> }
>
> -static int submit_bh_wbc(int rw, struct buffer_head *bh,
> +static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
> unsigned long bio_flags, struct writeback_control *wbc)
> {
> struct bio *bio;
> @@ -2999,7 +2999,7 @@ static int submit_bh_wbc(int rw, struct buffer_head *bh,
> /*
> * Only clear out a write error when rewriting
> */
> - if (test_set_buffer_req(bh) && (rw & WRITE))
> + if (test_set_buffer_req(bh) && (op == REQ_OP_WRITE))
> clear_buffer_write_io_error(bh);
>
> /*
> @@ -3022,29 +3022,31 @@ static int submit_bh_wbc(int rw, struct buffer_head *bh,
> bio->bi_end_io = end_bio_bh_io_sync;
> bio->bi_private = bh;
> bio->bi_flags |= bio_flags;
> + bio->bi_op = op;
>
> /* Take care of bh's that straddle the end of the device */
> - guard_bio_eod(rw, bio);
> + guard_bio_eod(op, bio);
>
> if (buffer_meta(bh))
> - rw |= REQ_META;
> + op_flags |= REQ_META;
> if (buffer_prio(bh))
> - rw |= REQ_PRIO;
> - bio->bi_rw = rw;
> + op_flags |= REQ_PRIO;
> + bio->bi_rw = op_flags;
>
> submit_bio(bio);
> return 0;
> }
>
> -int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags)
> +int _submit_bh(int op, int op_flags, struct buffer_head *bh,
> + unsigned long bio_flags)
> {
> - return submit_bh_wbc(rw, bh, bio_flags, NULL);
> + return submit_bh_wbc(op, op_flags, bh, bio_flags, NULL);
> }
> EXPORT_SYMBOL_GPL(_submit_bh);
>
> -int submit_bh(int rw, struct buffer_head *bh)
> +int submit_bh(int op, int op_flags, struct buffer_head *bh)
> {
> - return submit_bh_wbc(rw, bh, 0, NULL);
> + return submit_bh_wbc(op, op_flags, bh, 0, NULL);
> }
> EXPORT_SYMBOL(submit_bh);
>
> @@ -3086,14 +3088,14 @@ void ll_rw_block(int rw, int nr, struct buffer_head *bhs[])
> if (test_clear_buffer_dirty(bh)) {
> bh->b_end_io = end_buffer_write_sync;
> get_bh(bh);
> - submit_bh(WRITE, bh);
> + submit_bh(rw, 0, bh);
> continue;
> }
> } else {
> if (!buffer_uptodate(bh)) {
> bh->b_end_io = end_buffer_read_sync;
> get_bh(bh);
> - submit_bh(rw, bh);
> + submit_bh(rw, 0, bh);
> continue;
> }
> }
> @@ -3102,7 +3104,7 @@ void ll_rw_block(int rw, int nr, struct buffer_head *bhs[])
> }
> EXPORT_SYMBOL(ll_rw_block);
>
> -void write_dirty_buffer(struct buffer_head *bh, int rw)
> +void write_dirty_buffer(struct buffer_head *bh, int op_flags)
> {
> lock_buffer(bh);
> if (!test_clear_buffer_dirty(bh)) {
> @@ -3111,7 +3113,7 @@ void write_dirty_buffer(struct buffer_head *bh, int rw)
> }
> bh->b_end_io = end_buffer_write_sync;
> get_bh(bh);
> - submit_bh(rw, bh);
> + submit_bh(REQ_OP_WRITE, op_flags, bh);
> }
> EXPORT_SYMBOL(write_dirty_buffer);
>
> @@ -3120,7 +3122,7 @@ EXPORT_SYMBOL(write_dirty_buffer);
> * and then start new I/O and then wait upon it. The caller must have a ref on
> * the buffer_head.
> */
> -int __sync_dirty_buffer(struct buffer_head *bh, int rw)
> +int __sync_dirty_buffer(struct buffer_head *bh, int op_flags)
> {
> int ret = 0;
>
> @@ -3129,7 +3131,7 @@ int __sync_dirty_buffer(struct buffer_head *bh, int rw)
> if (test_clear_buffer_dirty(bh)) {
> get_bh(bh);
> bh->b_end_io = end_buffer_write_sync;
> - ret = submit_bh(rw, bh);
> + ret = submit_bh(REQ_OP_WRITE, op_flags, bh);
> wait_on_buffer(bh);
> if (!ret && !buffer_uptodate(bh))
> ret = -EIO;
> @@ -3392,7 +3394,7 @@ int bh_submit_read(struct buffer_head *bh)
>
> get_bh(bh);
> bh->b_end_io = end_buffer_read_sync;
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
> wait_on_buffer(bh);
> if (buffer_uptodate(bh))
> return 0;
> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index fe1f50f..d06823b 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -470,7 +470,7 @@ ext4_read_block_bitmap_nowait(struct super_block *sb, ext4_group_t block_group)
> trace_ext4_read_block_bitmap_load(sb, block_group);
> bh->b_end_io = ext4_end_bitmap_read;
> get_bh(bh);
> - submit_bh(READ | REQ_META | REQ_PRIO, bh);
> + submit_bh(REQ_OP_READ, REQ_META | REQ_PRIO, bh);
> return bh;
> verify:
> err = ext4_validate_block_bitmap(sb, desc, block_group, bh);
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index 237b877..0b08abc 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -214,7 +214,7 @@ ext4_read_inode_bitmap(struct super_block *sb, ext4_group_t block_group)
> trace_ext4_load_inode_bitmap(sb, block_group);
> bh->b_end_io = ext4_end_bitmap_read;
> get_bh(bh);
> - submit_bh(READ | REQ_META | REQ_PRIO, bh);
> + submit_bh(REQ_OP_READ, REQ_META | REQ_PRIO, bh);
> wait_on_buffer(bh);
> if (!buffer_uptodate(bh)) {
> put_bh(bh);
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 981a1fc..f19220b 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4186,7 +4186,7 @@ make_io:
> trace_ext4_load_inode(inode);
> get_bh(bh);
> bh->b_end_io = end_buffer_read_sync;
> - submit_bh(READ | REQ_META | REQ_PRIO, bh);
> + submit_bh(REQ_OP_READ, REQ_META | REQ_PRIO, bh);
> wait_on_buffer(bh);
> if (!buffer_uptodate(bh)) {
> EXT4_ERROR_INODE_BLOCK(inode, block,
> diff --git a/fs/ext4/mmp.c b/fs/ext4/mmp.c
> index 2444527..cef1db4 100644
> --- a/fs/ext4/mmp.c
> +++ b/fs/ext4/mmp.c
> @@ -52,7 +52,7 @@ static int write_mmp_block(struct super_block *sb, struct buffer_head *bh)
> lock_buffer(bh);
> bh->b_end_io = end_buffer_write_sync;
> get_bh(bh);
> - submit_bh(WRITE_SYNC | REQ_META | REQ_PRIO, bh);
> + submit_bh(REQ_OP_WRITE, WRITE_SYNC | REQ_META | REQ_PRIO, bh);
> wait_on_buffer(bh);
> sb_end_write(sb);
> if (unlikely(!buffer_uptodate(bh)))
> @@ -88,7 +88,7 @@ static int read_mmp_block(struct super_block *sb, struct buffer_head **bh,
> get_bh(*bh);
> lock_buffer(*bh);
> (*bh)->b_end_io = end_buffer_read_sync;
> - submit_bh(READ_SYNC | REQ_META | REQ_PRIO, *bh);
> + submit_bh(REQ_OP_READ, READ_SYNC | REQ_META | REQ_PRIO, *bh);
> wait_on_buffer(*bh);
> if (!buffer_uptodate(*bh)) {
> ret = -EIO;
> diff --git a/fs/fat/misc.c b/fs/fat/misc.c
> index c4589e9..8a86981 100644
> --- a/fs/fat/misc.c
> +++ b/fs/fat/misc.c
> @@ -267,7 +267,7 @@ int fat_sync_bhs(struct buffer_head **bhs, int nr_bhs)
> int i, err = 0;
>
> for (i = 0; i < nr_bhs; i++)
> - write_dirty_buffer(bhs[i], WRITE);
> + write_dirty_buffer(bhs[i], 0);
>
> for (i = 0; i < nr_bhs; i++) {
> wait_on_buffer(bhs[i]);
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index 24ce1cd..06d79aa 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -285,7 +285,7 @@ static void gfs2_metapath_ra(struct gfs2_glock *gl,
> if (trylock_buffer(rabh)) {
> if (!buffer_uptodate(rabh)) {
> rabh->b_end_io = end_buffer_read_sync;
> - submit_bh(READA | REQ_META, rabh);
> + submit_bh(REQ_OP_READ, READA | REQ_META, rabh);
> continue;
> }
> unlock_buffer(rabh);
> diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
> index 4a01f30..97a7d47 100644
> --- a/fs/gfs2/dir.c
> +++ b/fs/gfs2/dir.c
> @@ -1510,7 +1510,7 @@ static void gfs2_dir_readahead(struct inode *inode, unsigned hsize, u32 index,
> continue;
> }
> bh->b_end_io = end_buffer_read_sync;
> - submit_bh(READA | REQ_META, bh);
> + submit_bh(REQ_OP_READ, READA | REQ_META, bh);
> continue;
> }
> brelse(bh);
> diff --git a/fs/gfs2/meta_io.c b/fs/gfs2/meta_io.c
> index f8d33e8..3c63087 100644
> --- a/fs/gfs2/meta_io.c
> +++ b/fs/gfs2/meta_io.c
> @@ -37,8 +37,8 @@ static int gfs2_aspace_writepage(struct page *page, struct writeback_control *wb
> {
> struct buffer_head *bh, *head;
> int nr_underway = 0;
> - int write_op = REQ_META | REQ_PRIO |
> - (wbc->sync_mode == WB_SYNC_ALL ? WRITE_SYNC : WRITE);
> + int write_flags = REQ_META | REQ_PRIO |
> + (wbc->sync_mode == WB_SYNC_ALL ? WRITE_SYNC : 0);
>
> BUG_ON(!PageLocked(page));
> BUG_ON(!page_has_buffers(page));
> @@ -79,7 +79,7 @@ static int gfs2_aspace_writepage(struct page *page, struct writeback_control *wb
> do {
> struct buffer_head *next = bh->b_this_page;
> if (buffer_async_write(bh)) {
> - submit_bh(write_op, bh);
> + submit_bh(REQ_OP_WRITE, write_flags, bh);
> nr_underway++;
> }
> bh = next;
> diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> index 2ad98d6..956bcf0 100644
> --- a/fs/jbd2/commit.c
> +++ b/fs/jbd2/commit.c
> @@ -155,9 +155,9 @@ static int journal_submit_commit_record(journal_t *journal,
>
> if (journal->j_flags & JBD2_BARRIER &&
> !jbd2_has_feature_async_commit(journal))
> - ret = submit_bh(WRITE_SYNC | WRITE_FLUSH_FUA, bh);
> + ret = submit_bh(REQ_OP_WRITE, WRITE_SYNC | WRITE_FLUSH_FUA, bh);
> else
> - ret = submit_bh(WRITE_SYNC, bh);
> + ret = submit_bh(REQ_OP_WRITE, WRITE_SYNC, bh);
>
> *cbh = bh;
> return ret;
> @@ -714,7 +714,7 @@ start_journal_io:
> clear_buffer_dirty(bh);
> set_buffer_uptodate(bh);
> bh->b_end_io = journal_end_buffer_io_sync;
> - submit_bh(WRITE_SYNC, bh);
> + submit_bh(REQ_OP_WRITE, WRITE_SYNC, bh);
> }
> cond_resched();
> stats.run.rs_blocks_logged += bufs;
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 435f0b2..6d7e33a 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -1345,15 +1345,15 @@ static int journal_reset(journal_t *journal)
> return jbd2_journal_start_thread(journal);
> }
>
> -static int jbd2_write_superblock(journal_t *journal, int write_op)
> +static int jbd2_write_superblock(journal_t *journal, int write_flags)
> {
> struct buffer_head *bh = journal->j_sb_buffer;
> journal_superblock_t *sb = journal->j_superblock;
> int ret;
>
> - trace_jbd2_write_superblock(journal, write_op);
> + trace_jbd2_write_superblock(journal, write_flags);
> if (!(journal->j_flags & JBD2_BARRIER))
> - write_op &= ~(REQ_FUA | REQ_FLUSH);
> + write_flags &= ~(REQ_FUA | REQ_FLUSH);
> lock_buffer(bh);
> if (buffer_write_io_error(bh)) {
> /*
> @@ -1373,7 +1373,7 @@ static int jbd2_write_superblock(journal_t *journal, int write_op)
> jbd2_superblock_csum_set(journal, sb);
> get_bh(bh);
> bh->b_end_io = end_buffer_write_sync;
> - ret = submit_bh(write_op, bh);
> + ret = submit_bh(REQ_OP_WRITE, write_flags, bh);
> wait_on_buffer(bh);
> if (buffer_write_io_error(bh)) {
> clear_buffer_write_io_error(bh);
> diff --git a/fs/nilfs2/btnode.c b/fs/nilfs2/btnode.c
> index e0c9daf..87baf87 100644
> --- a/fs/nilfs2/btnode.c
> +++ b/fs/nilfs2/btnode.c
> @@ -67,7 +67,7 @@ nilfs_btnode_create_block(struct address_space *btnc, __u64 blocknr)
> }
>
> int nilfs_btnode_submit_block(struct address_space *btnc, __u64 blocknr,
> - sector_t pblocknr, int mode,
> + sector_t pblocknr, int mode, int mode_flags,
> struct buffer_head **pbh, sector_t *submit_ptr)
> {
> struct buffer_head *bh;
> @@ -100,7 +100,7 @@ int nilfs_btnode_submit_block(struct address_space *btnc, __u64 blocknr,
> }
> }
>
> - if (mode == READA) {
> + if (mode_flags & REQ_RAHEAD) {
> if (pblocknr != *submit_ptr + 1 || !trylock_buffer(bh)) {
> err = -EBUSY; /* internal code */
> brelse(bh);
> @@ -119,7 +119,7 @@ int nilfs_btnode_submit_block(struct address_space *btnc, __u64 blocknr,
> bh->b_blocknr = pblocknr; /* set block address for read */
> bh->b_end_io = end_buffer_read_sync;
> get_bh(bh);
> - submit_bh(mode, bh);
> + submit_bh(mode, mode_flags, bh);
> bh->b_blocknr = blocknr; /* set back to the given block address */
> *submit_ptr = pblocknr;
> err = 0;
> diff --git a/fs/nilfs2/btnode.h b/fs/nilfs2/btnode.h
> index d876b56..3f93197 100644
> --- a/fs/nilfs2/btnode.h
> +++ b/fs/nilfs2/btnode.h
> @@ -47,7 +47,7 @@ void nilfs_btnode_cache_clear(struct address_space *);
> struct buffer_head *nilfs_btnode_create_block(struct address_space *btnc,
> __u64 blocknr);
> int nilfs_btnode_submit_block(struct address_space *, __u64, sector_t, int,
> - struct buffer_head **, sector_t *);
> + int, struct buffer_head **, sector_t *);
> void nilfs_btnode_delete(struct buffer_head *);
> int nilfs_btnode_prepare_change_key(struct address_space *,
> struct nilfs_btnode_chkey_ctxt *);
> diff --git a/fs/nilfs2/btree.c b/fs/nilfs2/btree.c
> index 3a3821b..5d6a2c6 100644
> --- a/fs/nilfs2/btree.c
> +++ b/fs/nilfs2/btree.c
> @@ -480,7 +480,8 @@ static int __nilfs_btree_get_block(const struct nilfs_bmap *btree, __u64 ptr,
> sector_t submit_ptr = 0;
> int ret;
>
> - ret = nilfs_btnode_submit_block(btnc, ptr, 0, READ, &bh, &submit_ptr);
> + ret = nilfs_btnode_submit_block(btnc, ptr, 0, REQ_OP_READ, 0, &bh,
> + &submit_ptr);
> if (ret) {
> if (ret != -EEXIST)
> return ret;
> @@ -496,7 +497,8 @@ static int __nilfs_btree_get_block(const struct nilfs_bmap *btree, __u64 ptr,
> n > 0 && i < ra->ncmax; n--, i++) {
> ptr2 = nilfs_btree_node_get_ptr(ra->node, i, ra->ncmax);
>
> - ret = nilfs_btnode_submit_block(btnc, ptr2, 0, READA,
> + ret = nilfs_btnode_submit_block(btnc, ptr2, 0,
> + REQ_OP_READ, REQ_RAHEAD,
> &ra_bh, &submit_ptr);
> if (likely(!ret || ret == -EEXIST))
> brelse(ra_bh);
> diff --git a/fs/nilfs2/gcinode.c b/fs/nilfs2/gcinode.c
> index 0224b78..90be270 100644
> --- a/fs/nilfs2/gcinode.c
> +++ b/fs/nilfs2/gcinode.c
> @@ -106,7 +106,7 @@ int nilfs_gccache_submit_read_data(struct inode *inode, sector_t blkoff,
> bh->b_blocknr = pbn;
> bh->b_end_io = end_buffer_read_sync;
> get_bh(bh);
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
> if (vbn)
> bh->b_blocknr = vbn;
> out:
> @@ -143,7 +143,8 @@ int nilfs_gccache_submit_read_node(struct inode *inode, sector_t pbn,
> int ret;
>
> ret = nilfs_btnode_submit_block(&NILFS_I(inode)->i_btnode_cache,
> - vbn ? : pbn, pbn, READ, out_bh, &pbn);
> + vbn ? : pbn, pbn, REQ_OP_READ, 0,
> + out_bh, &pbn);
> if (ret == -EEXIST) /* internal code (cache hit) */
> ret = 0;
> return ret;
> diff --git a/fs/nilfs2/mdt.c b/fs/nilfs2/mdt.c
> index f6982b9..27aee74 100644
> --- a/fs/nilfs2/mdt.c
> +++ b/fs/nilfs2/mdt.c
> @@ -124,7 +124,7 @@ static int nilfs_mdt_create_block(struct inode *inode, unsigned long block,
>
> static int
> nilfs_mdt_submit_block(struct inode *inode, unsigned long blkoff,
> - int mode, struct buffer_head **out_bh)
> + int mode, int mode_flags, struct buffer_head **out_bh)
> {
> struct buffer_head *bh;
> __u64 blknum = 0;
> @@ -138,7 +138,7 @@ nilfs_mdt_submit_block(struct inode *inode, unsigned long blkoff,
> if (buffer_uptodate(bh))
> goto out;
>
> - if (mode == READA) {
> + if (mode_flags & REQ_RAHEAD) {
> if (!trylock_buffer(bh)) {
> ret = -EBUSY;
> goto failed_bh;
> @@ -160,7 +160,7 @@ nilfs_mdt_submit_block(struct inode *inode, unsigned long blkoff,
>
> bh->b_end_io = end_buffer_read_sync;
> get_bh(bh);
> - submit_bh(mode, bh);
> + submit_bh(mode, mode_flags, bh);
> ret = 0;
>
> trace_nilfs2_mdt_submit_block(inode, inode->i_ino, blkoff, mode);
> @@ -184,7 +184,7 @@ static int nilfs_mdt_read_block(struct inode *inode, unsigned long block,
> int i, nr_ra_blocks = NILFS_MDT_MAX_RA_BLOCKS;
> int err;
>
> - err = nilfs_mdt_submit_block(inode, block, READ, &first_bh);
> + err = nilfs_mdt_submit_block(inode, block, REQ_OP_READ, 0, &first_bh);
> if (err == -EEXIST) /* internal code */
> goto out;
>
> @@ -194,7 +194,8 @@ static int nilfs_mdt_read_block(struct inode *inode, unsigned long block,
> if (readahead) {
> blkoff = block + 1;
> for (i = 0; i < nr_ra_blocks; i++, blkoff++) {
> - err = nilfs_mdt_submit_block(inode, blkoff, READA, &bh);
> + err = nilfs_mdt_submit_block(inode, blkoff, REQ_OP_READ,
> + REQ_RAHEAD, &bh);
> if (likely(!err || err == -EEXIST))
> brelse(bh);
> else if (err != -EBUSY)
> diff --git a/fs/ntfs/aops.c b/fs/ntfs/aops.c
> index 97768a1..fe251f1 100644
> --- a/fs/ntfs/aops.c
> +++ b/fs/ntfs/aops.c
> @@ -362,7 +362,7 @@ handle_zblock:
> for (i = 0; i < nr; i++) {
> tbh = arr[i];
> if (likely(!buffer_uptodate(tbh)))
> - submit_bh(READ, tbh);
> + submit_bh(REQ_OP_READ, 0, tbh);
> else
> ntfs_end_buffer_async_read(tbh, 1);
> }
> @@ -877,7 +877,7 @@ lock_retry_remap:
> do {
> struct buffer_head *next = bh->b_this_page;
> if (buffer_async_write(bh)) {
> - submit_bh(WRITE, bh);
> + submit_bh(REQ_OP_WRITE, 0, bh);
> need_end_writeback = false;
> }
> bh = next;
> @@ -1202,7 +1202,7 @@ lock_retry_remap:
> BUG_ON(!buffer_mapped(tbh));
> get_bh(tbh);
> tbh->b_end_io = end_buffer_write_sync;
> - submit_bh(WRITE, tbh);
> + submit_bh(REQ_OP_WRITE, 0, tbh);
> }
> /* Synchronize the mft mirror now if not @sync. */
> if (is_mft && !sync)
> diff --git a/fs/ntfs/compress.c b/fs/ntfs/compress.c
> index f2b5e74..f8eb043 100644
> --- a/fs/ntfs/compress.c
> +++ b/fs/ntfs/compress.c
> @@ -670,7 +670,7 @@ lock_retry_remap:
> }
> get_bh(tbh);
> tbh->b_end_io = end_buffer_read_sync;
> - submit_bh(READ, tbh);
> + submit_bh(REQ_OP_READ, 0, tbh);
> }
>
> /* Wait for io completion on all buffer heads. */
> diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
> index 91117ad..d96f0c1 100644
> --- a/fs/ntfs/file.c
> +++ b/fs/ntfs/file.c
> @@ -553,7 +553,7 @@ static inline int ntfs_submit_bh_for_read(struct buffer_head *bh)
> lock_buffer(bh);
> get_bh(bh);
> bh->b_end_io = end_buffer_read_sync;
> - return submit_bh(READ, bh);
> + return submit_bh(REQ_OP_READ, 0, bh);
> }
>
> /**
> diff --git a/fs/ntfs/logfile.c b/fs/ntfs/logfile.c
> index 9d71213..761f12f 100644
> --- a/fs/ntfs/logfile.c
> +++ b/fs/ntfs/logfile.c
> @@ -821,7 +821,7 @@ map_vcn:
> * completed ignore errors afterwards as we can assume
> * that if one buffer worked all of them will work.
> */
> - submit_bh(WRITE, bh);
> + submit_bh(REQ_OP_WRITE, 0, bh);
> if (should_wait) {
> should_wait = false;
> wait_on_buffer(bh);
> diff --git a/fs/ntfs/mft.c b/fs/ntfs/mft.c
> index 37b2501..d15d492 100644
> --- a/fs/ntfs/mft.c
> +++ b/fs/ntfs/mft.c
> @@ -592,7 +592,7 @@ int ntfs_sync_mft_mirror(ntfs_volume *vol, const unsigned long mft_no,
> clear_buffer_dirty(tbh);
> get_bh(tbh);
> tbh->b_end_io = end_buffer_write_sync;
> - submit_bh(WRITE, tbh);
> + submit_bh(REQ_OP_WRITE, 0, tbh);
> }
> /* Wait on i/o completion of buffers. */
> for (i_bhs = 0; i_bhs < nr_bhs; i_bhs++) {
> @@ -785,7 +785,7 @@ int write_mft_record_nolock(ntfs_inode *ni, MFT_RECORD *m, int sync)
> clear_buffer_dirty(tbh);
> get_bh(tbh);
> tbh->b_end_io = end_buffer_write_sync;
> - submit_bh(WRITE, tbh);
> + submit_bh(REQ_OP_WRITE, 0, tbh);
> }
> /* Synchronize the mft mirror now if not @sync. */
> if (!sync && ni->mft_no < vol->mftmirr_size)
> diff --git a/fs/ocfs2/buffer_head_io.c b/fs/ocfs2/buffer_head_io.c
> index fe50ded..fb775c9 100644
> --- a/fs/ocfs2/buffer_head_io.c
> +++ b/fs/ocfs2/buffer_head_io.c
> @@ -79,7 +79,7 @@ int ocfs2_write_block(struct ocfs2_super *osb, struct buffer_head *bh,
>
> get_bh(bh); /* for end_buffer_write_sync() */
> bh->b_end_io = end_buffer_write_sync;
> - submit_bh(WRITE, bh);
> + submit_bh(REQ_OP_WRITE, 0, bh);
>
> wait_on_buffer(bh);
>
> @@ -149,7 +149,7 @@ int ocfs2_read_blocks_sync(struct ocfs2_super *osb, u64 block,
> clear_buffer_uptodate(bh);
> get_bh(bh); /* for end_buffer_read_sync() */
> bh->b_end_io = end_buffer_read_sync;
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
> }
>
> for (i = nr; i > 0; i--) {
> @@ -305,7 +305,7 @@ int ocfs2_read_blocks(struct ocfs2_caching_info *ci, u64 block, int nr,
> if (validate)
> set_buffer_needs_validate(bh);
> bh->b_end_io = end_buffer_read_sync;
> - submit_bh(READ, bh);
> + submit_bh(REQ_OP_READ, 0, bh);
> continue;
> }
> }
> @@ -419,7 +419,7 @@ int ocfs2_write_super_or_backup(struct ocfs2_super *osb,
> get_bh(bh); /* for end_buffer_write_sync() */
> bh->b_end_io = end_buffer_write_sync;
> ocfs2_compute_meta_ecc(osb->sb, bh->b_data, &di->i_check);
> - submit_bh(WRITE, bh);
> + submit_bh(REQ_OP_WRITE, 0, bh);
>
> wait_on_buffer(bh);
>
> diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
> index d5c2e9c..b72c23a 100644
> --- a/fs/reiserfs/inode.c
> +++ b/fs/reiserfs/inode.c
> @@ -2668,7 +2668,7 @@ static int reiserfs_write_full_page(struct page *page,
> do {
> struct buffer_head *next = bh->b_this_page;
> if (buffer_async_write(bh)) {
> - submit_bh(WRITE, bh);
> + submit_bh(REQ_OP_WRITE, 0, bh);
> nr++;
> }
> put_bh(bh);
> @@ -2728,7 +2728,7 @@ fail:
> struct buffer_head *next = bh->b_this_page;
> if (buffer_async_write(bh)) {
> clear_buffer_dirty(bh);
> - submit_bh(WRITE, bh);
> + submit_bh(REQ_OP_WRITE, 0, bh);
> nr++;
> }
> put_bh(bh);
> diff --git a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
> index 2ace90e..6945e71 100644
> --- a/fs/reiserfs/journal.c
> +++ b/fs/reiserfs/journal.c
> @@ -652,7 +652,7 @@ static void submit_logged_buffer(struct buffer_head *bh)
> BUG();
> if (!buffer_uptodate(bh))
> BUG();
> - submit_bh(WRITE, bh);
> + submit_bh(REQ_OP_WRITE, 0, bh);
> }
>
> static void submit_ordered_buffer(struct buffer_head *bh)
> @@ -662,7 +662,7 @@ static void submit_ordered_buffer(struct buffer_head *bh)
> clear_buffer_dirty(bh);
> if (!buffer_uptodate(bh))
> BUG();
> - submit_bh(WRITE, bh);
> + submit_bh(REQ_OP_WRITE, 0, bh);
> }
>
> #define CHUNK_SIZE 32
> @@ -2269,7 +2269,7 @@ abort_replay:
> /* flush out the real blocks */
> for (i = 0; i < get_desc_trans_len(desc); i++) {
> set_buffer_dirty(real_blocks[i]);
> - write_dirty_buffer(real_blocks[i], WRITE);
> + write_dirty_buffer(real_blocks[i], 0);
> }
> for (i = 0; i < get_desc_trans_len(desc); i++) {
> wait_on_buffer(real_blocks[i]);
> diff --git a/fs/ufs/util.c b/fs/ufs/util.c
> index a409e3e7..f41ad0a 100644
> --- a/fs/ufs/util.c
> +++ b/fs/ufs/util.c
> @@ -118,7 +118,7 @@ void ubh_sync_block(struct ufs_buffer_head *ubh)
> unsigned i;
>
> for (i = 0; i < ubh->count; i++)
> - write_dirty_buffer(ubh->bh[i], WRITE);
> + write_dirty_buffer(ubh->bh[i], 0);
>
> for (i = 0; i < ubh->count; i++)
> wait_on_buffer(ubh->bh[i]);
> diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
> index d48daa3..bc9a45d 100644
> --- a/include/linux/buffer_head.h
> +++ b/include/linux/buffer_head.h
> @@ -189,10 +189,11 @@ void unlock_buffer(struct buffer_head *bh);
> void __lock_buffer(struct buffer_head *bh);
> void ll_rw_block(int, int, struct buffer_head * bh[]);
> int sync_dirty_buffer(struct buffer_head *bh);
> -int __sync_dirty_buffer(struct buffer_head *bh, int rw);
> -void write_dirty_buffer(struct buffer_head *bh, int rw);
> -int _submit_bh(int rw, struct buffer_head *bh, unsigned long bio_flags);
> -int submit_bh(int, struct buffer_head *);
> +int __sync_dirty_buffer(struct buffer_head *bh, int op_flags);
> +void write_dirty_buffer(struct buffer_head *bh, int op_flags);
> +int _submit_bh(int op, int op_flags, struct buffer_head *bh,
> + unsigned long bio_flags);
> +int submit_bh(int, int, struct buffer_head *);
> void write_boundary_block(struct block_device *bdev,
> sector_t bblock, unsigned blocksize);
> int bh_uptodate_or_lock(struct buffer_head *bh);
> --
> 2.7.2
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply
* Greetings!!!
From: andreas11 @ 2016-04-18 17:43 UTC (permalink / raw)
To: Mr. Eric
Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London. It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with you as you're a foreigner, it will be mutually beneficial to both. If you’re interested, urgently, get back to me for more explanation about the deal.
Regards
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Greetings!!!
From: andreas122 @ 2016-04-18 20:12 UTC (permalink / raw)
To: Mr. Eric
Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London. It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with you as you're a foreigner, it will be mutually beneficial to both. If you’re interested, urgently, get back to me for more explanation about the deal.
Regards
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
From: Milan Broz @ 2016-04-18 21:22 UTC (permalink / raw)
To: Mike Snitzer, Baolin Wang
Cc: Herbert Xu, David Miller, Alasdair G Kergon, Jens Axboe, dm-devel,
Andrew Morton, david.s.gordon, Tom Lendacky, Robert Jarzmik,
Masahiro Yamada, smueller, tadeusz.struk, Masanari Iida, shli,
Mark Brown, Linus Walleij, Arnd Bergmann, LKML, linux-crypto,
linux-raid
In-Reply-To: <20160418133612.GA16853@redhat.com>
On 04/18/2016 03:36 PM, Mike Snitzer wrote:
> On Mon, Apr 18 2016 at 1:31am -0400,
> Baolin Wang <baolin.wang@linaro.org> wrote:
>
>> Hi Herbert,
>>
>> On 15 April 2016 at 21:48, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>>> On Tue, Mar 15, 2016 at 03:47:58PM +0800, Baolin Wang wrote:
>>>> Now some cipher hardware engines prefer to handle bulk block by merging requests
>>>> to increase the block size and thus increase the hardware engine processing speed.
>>>>
>>>> This patchset introduces request bulk mode to help the crypto hardware drivers
>>>> improve in efficiency.
>>>
>>> Could you please explain why this merging can't be done in dm-crypt
>>> instead?
>>
>> We've tried to do this in dm-crypt, but it failed.
>> The dm-crypt maintainer explained to me that I should optimize the
>> driver, not add strange hw-dependent crypto modes to dm-crypt, this is
>> not the first crypto accelerator that is just not suited for this kind
>> of use.
>
> As a DM mainatiner my only contribution to this line of discussion was
> relative to your proposal to train the dm-crypt target (which is
> bio-based) to also provide request-based support, see:
> https://www.redhat.com/archives/dm-devel/2015-November/msg00112.html
>
> But follow-up discussion occured, primarily with Milan Broz, which led
> to this bulk mode support in the crypto layer. Pretty strange Milan
> wasn't cc'd on your patchset posting (I've now cc'd him).
My complaint was mainly that the proposed dmcrypt based version just did
not work properly.
https://lkml.org/lkml/2016/1/2/109
(I did not test the new version we are replying here. I wonder how the problem
I mentioned is fixed though.
Also see Mikulas' comments https://www.redhat.com/archives/dm-devel/2016-January/msg00145.html)
Anyway, all this seems to optimize case for specific crypto hw, that
is not able to perform optimally with pattern dmcrypt produces.
I do not think dmcrypt should do optimizations for specific hw.
But if we decide that it is needed there, it should not cause any performance
or compatibility problems elsewhere...
Milan
^ permalink raw reply
* Re: Poor written performance with RAID5 on ARM64
From: Shaohua Li @ 2016-04-19 13:59 UTC (permalink / raw)
To: 刘正元; +Cc: linux-raid
In-Reply-To: <tencent_7B55CA2751E70C532CB35C8E@qq.com>
On Mon, Apr 18, 2016 at 01:43:04PM +0800, 刘正元 wrote:
> Hi,everyone. I upgrade kernel form 3.14.x to 4.4.x recently on my ARM64
> server. I create a RAID5 device with 8 disks on the server and have a dd
> test which like this "dd if=/dev/zero of=/dev/md5 bs=64K count=400000".
> Before upgrade it can reach 700M/s written and only 500M/s after upgrade.
> Then I disable the bitmap which means "mdadm create --bitmap=none", the speed
> can reach 800M/s with 4.4 kernel. I have a fast view on driver/md/bitmap.c
> and got no answer. I doubt X86 platform has the same question. So, what is
> the most difference between 3.14.x and 4.4.x about md driver. Where could I
> found the ChangeLog or commit about the driver. Any answer would be thankful.
did you observe any changes in iostat? Could you post blktrace from one of the
raid disk?
Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] include sys/sysmacros.h for major/minor/makedev prototypes
From: Mike Frysinger @ 2016-04-19 22:12 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
These funcs are defined in sys/sysmacros.h, so include it for them.
It works today due to an implicit include by sys/types.h, but the
various Linux C libraries are moving away from that.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
mdadm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/mdadm.h b/mdadm.h
index d209488..b8767a7 100755
--- a/mdadm.h
+++ b/mdadm.h
@@ -33,6 +33,7 @@ extern __off64_t lseek64 __P ((int __fd, __off64_t __offset, int __whence));
# endif
#endif
+#include <sys/sysmacros.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdint.h>
--
2.7.4
^ permalink raw reply related
* Re: Poor written performance with RAID5 on ARM64
From: 刘正元 @ 2016-04-20 4:16 UTC (permalink / raw)
To: linux-raid
Thanks for reply.
I have traced the iostat changes under the both kernel version as below show. As you can see, disk IO is not the bottleneck because bandwidth not reach 100%, and cpu for single core hold about 40% during testing.
----------------------------------------------for kernel 3.14.64----------------------------------------------------------------------
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 3.65 6.25 0.00 90.10
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 1549.01 0.00 220.30 0.00 112033.91 1017.12 14.23 63.48 0.00 63.48 4.11 90.59
sdc 0.00 1549.01 0.00 222.77 0.00 113301.24 1017.19 10.95 48.76 0.00 48.76 4.02 89.60
sdd 0.00 1549.01 0.00 222.28 0.00 113047.77 1017.18 16.18 72.32 0.00 72.32 4.16 92.57
sdf 0.00 1549.01 0.00 216.34 0.00 110006.19 1016.99 14.61 65.01 0.00 65.01 4.28 92.57
sde 0.00 1549.01 0.00 222.28 0.00 113047.77 1017.18 12.37 55.21 0.00 55.21 3.99 88.61
--------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------for kernel 4.4.3--------------------------------------------------------------
avg-cpu: %user %nice %system %iowait %steal %idle
0.03 0.00 2.37 5.43 0.00 92.18
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 30.00 1209.50 1.50 70.00 1056.00 85441.50 2419.51 19.62 331.41 114.67 336.06 9.68 69.20
sdc 30.00 1209.50 1.50 69.00 1056.00 84161.50 2417.52 18.02 303.06 120.00 307.04 9.28 65.40
sdd 30.50 1211.00 1.50 70.00 1088.00 85505.50 2422.20 20.88 351.13 142.67 355.60 10.13 72.40
sde 30.50 1210.50 1.50 69.50 1088.00 84866.25 2421.25 18.53 311.77 117.33 315.97 9.55 67.80
sdf 0.00 1224.50 0.00 72.00 0.00 86850.25 2412.51 21.38 353.64 0.00 353.64 10.75 77.40
--------------------------------------------------------------------------------------------------------------------------------------
While disable bitmap the field %util could reach 100% and written speed of single disk could reach 120M/s under kernel 4.4.3. So, I doubt bitmap may be the mather.
Best wishs (祝生活愉快)!
------------------ Original ------------------
From: "Shaohua Li";
Date: 2016年4月19日(星期二) 晚上9:59
To: "刘正元";
Cc: "linux-raid";
Subject: Re: Poor written performance with RAID5 on ARM64
On Mon, Apr 18, 2016 at 01:43:04PM +0800, 刘正元 wrote:
> Hi,everyone. I upgrade kernel form 3.14.x to 4.4.x recently on my ARM64
> server. I create a RAID5 device with 8 disks on the server and have a dd
> test which like this "dd if=/dev/zero of=/dev/md5 bs=64K count=400000".
> Before upgrade it can reach 700M/s written and only 500M/s after upgrade.
> Then I disable the bitmap which means "mdadm create --bitmap=none", the speed
> can reach 800M/s with 4.4 kernel. I have a fast view on driver/md/bitmap.c
> and got no answer. I doubt X86 platform has the same question. So, what is
> the most difference between 3.14.x and 4.4.x about md driver. Where could I
> found the ChangeLog or commit about the driver. Any answer would be thankful.
did you observe any changes in iostat? Could you post blktrace from one of the
raid disk?
Thanks,
Shaohua
^ permalink raw reply
* Re: Hard CPU Lockup when accessing MD RAID5
From: Daniel Walker @ 2016-04-20 6:52 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <20160413170008.GA6186@kernel.org>
Hi,
I upgraded the kernel to the latest stable with debugging enabled
(4.5.1) without any luck, this is what is outputted in dmesg:
[262448.558983] INFO: task php:13376 blocked for more than 120 seconds.
[262448.559057] Tainted: G W 4.5.1 #1
[262448.559092] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[262448.559246] php D
ffff88001c297a18
0 13376 12277 0x00000000
[262448.559519] ffff88001c297a18
ffff881ff248c100
ffff880013e9b400
ffff881fea472000
[262448.559603] ffff88001c297ae8
ffff88001c298000
ffff881c5cac1b30
ffff880013e9b400
[262448.560046] 0000000000020001
0000000545ea7820
ffff88001c297a30
ffffffff814d5690
[262448.560485] Call Trace:
[262448.560541] [<ffffffff814d5690>] schedule+0x30/0x80
[262448.560761] [<ffffffff814d823e>] schedule_timeout+0x21e/0x2a0
[262448.560828] [<ffffffff81217c3d>] ?
xfs_bmap_search_extents+0x7d/0x100
[262448.561000] [<ffffffff810902d9>] ? down_trylock+0x29/0x40
[262448.561135] [<ffffffff814d726f>] __down+0x5f/0xa0
[262448.561268] [<ffffffff8124bdd6>] ? _xfs_buf_find+0x156/0x350
[262448.561347] [<ffffffff8109032c>] down+0x3c/0x50
[262448.561390] [<ffffffff8124bbc7>] xfs_buf_lock+0x37/0xf0
[262448.561435] [<ffffffff8124bdd6>] _xfs_buf_find+0x156/0x350
[262448.561557] [<ffffffff8124bff5>] xfs_buf_get_map+0x25/0x280
[262448.561603] [<ffffffff81268f4b>] ? kmem_zone_alloc+0x7b/0x120
[262448.561666] [<ffffffff8124cbe8>] xfs_buf_read_map+0x28/0x180
[262448.561768] [<ffffffff8127830b>] xfs_trans_read_buf_map+0xeb/0x300
[262448.561809] [<ffffffff8123f7da>] xfs_imap_to_bp+0x5a/0xc0
[262448.561881] [<ffffffff8125b7a5>] xfs_iunlink_remove+0x275/0x3a0
[262448.561943] [<ffffffff81268f4b>] ? kmem_zone_alloc+0x7b/0x120
[262448.561988] [<ffffffff8125ec33>] xfs_ifree+0x33/0xd0
[262448.562033] [<ffffffff8125ed85>] xfs_inactive_ifree+0xb5/0x200
[262448.562109] [<ffffffff8125ef58>] xfs_inactive+0x88/0x110
[262448.562296] [<ffffffff81263f31>] xfs_fs_evict_inode+0xc1/0x110
[262448.562344] [<ffffffff811a42fb>] evict+0xbb/0x180
[262448.562405] [<ffffffff811a4bb3>] iput+0x193/0x200
[262448.562483] [<ffffffff811a08d2>] d_delete+0x122/0x160
[262448.562520] [<ffffffff81195b99>] vfs_rmdir+0xf9/0x120
[262448.562559] [<ffffffff81199d17>] do_rmdir+0x1b7/0x1d0
[262448.562607] [<ffffffff81001210>] ? exit_to_usermode_loop+0x90/0xb0
[262448.562665] [<ffffffff8119a921>] SyS_rmdir+0x11/0x20
[262448.562891] [<ffffffff814d8f1b>]
entry_SYSCALL_64_fastpath+0x16/0x6e
[262489.707201] NMI watchdog: Watchdog detected hard LOCKUP on cpu 15
[262489.707227] Modules linked in:
ipt_MASQUERADE
nf_nat_masquerade_ipv4
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
ipt_REJECT
nf_reject_ipv4
iptable_mangle
netconsole
configfs
tun
xt_multiport
ip6table_filter
ip6_tables
iptable_filter
ip_tables
x_tables
bridge
stp
llc
bonding
ext4
crc16
mbcache
jbd2
raid1
raid0
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
xor
async_tx
raid6_pq
md_mod
sg
sd_mod
hid_generic
usbhid
hid
x86_pkg_temp_thermal
coretemp
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
jitterentropy_rng
sha256_ssse3
iTCO_wdt
sha256_generic
iTCO_vendor_support
hmac
drbg
xhci_pci
ahci
sb_edac
ehci_pci
ansi_cprng
xhci_hcd
ehci_hcd
libahci
i2c_i801
edac_core
lpc_ich
mei_me
mfd_core
libata
usbcore
igb
mei
megaraid_sas
i2c_algo_bit
usb_common
ptp
aesni_intel
pps_core
aes_x86_64
ioatdma
lrw
gf128mul
glue_helper
ablk_helper
i2c_core
scsi_mod
dca
cryptd
ipmi_si
ipmi_msghandler
acpi_power_meter
tpm_tis
tpm
processor
button
[262489.708066] CPU: 15 PID: 17535 Comm: kworker/u32:6 Tainted:
G W 4.5.1 #1
[262489.708124] Hardware name: Supermicro Super Server/X10DRi-LN4+,
BIOS 2.0 12/17/2015
[262489.708187] Workqueue: writeback wb_workfn
(flush-9:7)
[262489.708228] 0000000000000000
ffff88207fde5bd0
ffffffff812e00b8
0000000000000000
[262489.708298] 0000000000000000
ffff88207fde5be8
ffffffff810dff1d
ffff881ff2270000
[262489.708368] ffff88207fde5c20
ffffffff8110f8f8
0000000000000001
ffff88207fdeaf00
[262489.708438] Call Trace:
[262489.708467] <NMI>
[<ffffffff812e00b8>] dump_stack+0x4d/0x65
[262489.708512] [<ffffffff810dff1d>]
watchdog_overflow_callback+0xdd/0xf0
[262489.708552] [<ffffffff8110f8f8>] __perf_event_overflow+0x88/0x1d0
[262489.708589] [<ffffffff811103e4>] perf_event_overflow+0x14/0x20
[262489.708627] [<ffffffff8101e320>] intel_pmu_handle_irq+0x1d0/0x4a0
[262489.708666] [<ffffffff81155481>] ? vunmap_page_range+0x1a1/0x310
[262489.708703] [<ffffffff811555fc>] ?
unmap_kernel_range_noflush+0xc/0x10
[262489.708748] [<ffffffff8135a543>] ?
ghes_copy_tofrom_phys+0x113/0x1e0
[262489.708788] [<ffffffff810359da>] ?
native_apic_wait_icr_idle+0x1a/0x30
[262489.708827] [<ffffffff810096e0>] ? arch_irq_work_raise+0x30/0x40
[262489.708865] [<ffffffff810162d8>] perf_event_nmi_handler+0x28/0x50
[262489.708902] [<ffffffff81008121>] nmi_handle+0x61/0x110
[262489.708939] [<ffffffff810082e7>] do_nmi+0x117/0x3e0
[262489.708975] [<ffffffff814dae97>] end_repeat_nmi+0x1a/0x1e
[262489.709013] [<ffffffffa01d05f0>] ? raid5_unplug+0x70/0x130
[raid456]
[262489.709051] [<ffffffffa01d05f0>] ? raid5_unplug+0x70/0x130
[raid456]
[262489.709089] [<ffffffffa01d05f0>] ? raid5_unplug+0x70/0x130
[raid456]
[262489.709125] <<EOE>>
[<ffffffff812b9b98>] blk_flush_plug_list+0xa8/0x210
[262489.709169] [<ffffffff814d5de0>] ? bit_wait_timeout+0x70/0x70
[262489.709206] [<ffffffff814d4c04>] io_schedule_timeout+0x54/0x130
[262489.709242] [<ffffffff814d5df6>] bit_wait_io+0x16/0x60
[262489.709277] [<ffffffff814d5b59>] __wait_on_bit_lock+0x49/0xa0
[262489.709314] [<ffffffff81117fd0>] __lock_page+0xb0/0xc0
[262489.709352] [<ffffffff8108bdc0>] ?
autoremove_wake_function+0x30/0x30
[262489.709391] [<ffffffff811250f0>] write_cache_pages+0x2f0/0x4d0
[262489.709427] [<ffffffff81122df0>] ? wb_position_ratio+0x1f0/0x1f0
[262489.709465] [<ffffffff8112530e>] generic_writepages+0x3e/0x60
[262489.709502] [<ffffffff81244c18>] xfs_vm_writepages+0x38/0x40
[262489.709539] [<ffffffff81125e29>] do_writepages+0x19/0x30
[262489.709574] [<ffffffff811b5c50>]
__writeback_single_inode+0x40/0x310
[262489.709612] [<ffffffff811b6402>] writeback_sb_inodes+0x242/0x520
[262489.709649] [<ffffffff811b676a>] __writeback_inodes_wb+0x8a/0xc0
[262489.709686] [<ffffffff811b6a77>] wb_writeback+0x247/0x2d0
[262489.709721] [<ffffffff811b716f>] wb_workfn+0x20f/0x3c0
[262489.709758] [<ffffffff81067513>] process_one_work+0x143/0x400
[262489.709795] [<ffffffff81067cc1>] worker_thread+0x61/0x490
[262489.709831] [<ffffffff81067c60>] ? max_active_store+0x60/0x60
[262489.709867] [<ffffffff8106c926>] kthread+0xd6/0xf0
[262489.709901] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
[262489.709937] [<ffffffff814d92af>] ret_from_fork+0x3f/0x70
[262489.709972] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
[262491.022971] NMI watchdog: Watchdog detected hard LOCKUP on cpu 0
[262491.023470] Modules linked in:
ipt_MASQUERADE
nf_nat_masquerade_ipv4
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
ipt_REJECT
nf_reject_ipv4
iptable_mangle
netconsole
configfs
tun
xt_multiport
ip6table_filter
ip6_tables
iptable_filter
ip_tables
x_tables
bridge
stp
llc
bonding
ext4
crc16
mbcache
jbd2
raid1
raid0
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
xor
async_tx
raid6_pq
md_mod
sg
sd_mod
hid_generic
usbhid
hid
x86_pkg_temp_thermal
coretemp
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
jitterentropy_rng
sha256_ssse3
iTCO_wdt
sha256_generic
iTCO_vendor_support
hmac
drbg
xhci_pci
ahci
sb_edac
ehci_pci
ansi_cprng
xhci_hcd
ehci_hcd
libahci
i2c_i801
edac_core
lpc_ich
mei_me
mfd_core
libata
usbcore
igb
mei
megaraid_sas
i2c_algo_bit
usb_common
ptp
aesni_intel
pps_core
aes_x86_64
ioatdma
lrw
gf128mul
glue_helper
ablk_helper
i2c_core
scsi_mod
dca
cryptd
ipmi_si
ipmi_msghandler
acpi_power_meter
tpm_tis
tpm
processor
button
[262491.029705] CPU: 0 PID: 1178 Comm: md7_raid5 Tainted: G
W 4.5.1 #1
[262491.029776] Hardware name: Supermicro Super Server/X10DRi-LN4+,
BIOS 2.0 12/17/2015
[262491.029849] 0000000000000000
ffff88207fc05bd0
ffffffff812e00b8
0000000000000000
[262491.029988] 0000000000000000
ffff88207fc05be8
ffffffff810dff1d
ffff881fff032000
[262491.030124] ffff88207fc05c20
ffffffff8110f8f8
0000000000000001
ffff88207fc0af00
[262491.030260] Call Trace:
[262491.030302] <NMI>
[<ffffffff812e00b8>] dump_stack+0x4d/0x65
[262491.030377] [<ffffffff810dff1d>]
watchdog_overflow_callback+0xdd/0xf0
[262491.030432] [<ffffffff8110f8f8>] __perf_event_overflow+0x88/0x1d0
[262491.030484] [<ffffffff811103e4>] perf_event_overflow+0x14/0x20
[262491.030536] [<ffffffff8101e320>] intel_pmu_handle_irq+0x1d0/0x4a0
[262491.030589] [<ffffffff81155481>] ? vunmap_page_range+0x1a1/0x310
[262491.030640] [<ffffffff811555fc>] ?
unmap_kernel_range_noflush+0xc/0x10
[262491.030693] [<ffffffff8135a543>] ?
ghes_copy_tofrom_phys+0x113/0x1e0
[262491.030745] [<ffffffff8135a681>] ? ghes_read_estatus+0x71/0x140
[262491.030797] [<ffffffff810162d8>] perf_event_nmi_handler+0x28/0x50
[262491.030849] [<ffffffff81008121>] nmi_handle+0x61/0x110
[262491.030898] [<ffffffff810083d1>] do_nmi+0x201/0x3e0
[262491.030949] [<ffffffff814dae97>] end_repeat_nmi+0x1a/0x1e
[262491.030998] [<ffffffff81090d23>] ?
queued_spin_lock_slowpath+0x153/0x170
[262491.031050] [<ffffffff81090d23>] ?
queued_spin_lock_slowpath+0x153/0x170
[262491.031102] [<ffffffff81090d23>] ?
queued_spin_lock_slowpath+0x153/0x170
[262491.031153] <<EOE>>
[<ffffffff814d8c6c>] _raw_spin_lock_irq+0x1c/0x20
[262491.031225] [<ffffffffa01db6b1>] raid5d+0x91/0x720 [raid456]
[262491.031276] [<ffffffff810a4a8a>] ? try_to_del_timer_sync+0x4a/0x60
[262491.031328] [<ffffffff810a4ae3>] ? del_timer_sync+0x43/0x50
[262491.031377] [<ffffffff814d816e>] ? schedule_timeout+0x14e/0x2a0
[262491.031428] [<ffffffff810a4830>] ?
trace_event_raw_event_tick_stop+0x100/0x100
[262491.031502] [<ffffffffa017874b>] md_thread+0x12b/0x130 [md_mod]
[262491.031555] [<ffffffff8108bd90>] ? wait_woken+0x80/0x80
[262491.031605] [<ffffffffa0178620>] ? find_pers+0x70/0x70 [md_mod]
[262491.031656] [<ffffffff8106c926>] kthread+0xd6/0xf0
[262491.031704] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
[262491.031753] [<ffffffff814d92af>] ret_from_fork+0x3f/0x70
[262491.031802] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
[262491.031753] [<ffffffff814d92af>] ret_from_fork+0x3f/0x70
[262491.031802] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
The server is hosting plain VPS's, there's a few that use it for
rtorrent which is quite disk extenssive, but from what I can see that
iowait is quite low.
There's absolutely nothing logged at all before the lockups, everythings
running fine and then suddenly it just crashes, im beginning to think we
might have a hardware problem, but im having a hard time finding the
actual issue.
Any ideas?
Best regards
Den 13-04-2016 kl. 19:00 skrev Shaohua Li:
> Looks there is a deadlock trying to hold the device_lock or hash_lock. anything
> abormal print out before the NMI watchdog? What is running in the machine?
> Looks this is old kernel, is it possible you can try a latest kernel and report
> back?
>
> Thanks,
> Shaohua
>
> On Tue, Apr 12, 2016 at 09:54:08PM +0000, Daniel Walker wrote:
>> Im having some issues on a brand new Supermicro server that we have running
>> in production along side a few other machines which are identical to this
>> server..
>>
>> The output from the netconsole attached to the server is here:
>>
>> Apr 12 21:34:45 [75704.964946] NMI watchdog: Watchdog detected hard LOCKUP
>> on cpu 6
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75704.964973] Modules linked in:
>> Apr 12 21:34:45 ipt_REJECT
>> Apr 12 21:34:45 nf_reject_ipv4
>> Apr 12 21:34:45 iptable_mangle
>> Apr 12 21:34:45 tun
>> Apr 12 21:34:45 netconsole
>> Apr 12 21:34:45 configfs
>> Apr 12 21:34:45 xt_multiport
>> Apr 12 21:34:45 ip6table_filter
>> Apr 12 21:34:45 ip6_tables
>> Apr 12 21:34:45 iptable_filter
>> Apr 12 21:34:45 ip_tables
>> Apr 12 21:34:45 x_tables
>> Apr 12 21:34:45 bridge
>> Apr 12 21:34:45 stp
>> Apr 12 21:34:45 llc
>> Apr 12 21:34:45 bonding
>> Apr 12 21:34:45 ext4
>> Apr 12 21:34:45 crc16
>> Apr 12 21:34:45 mbcache
>> Apr 12 21:34:45 jbd2
>> Apr 12 21:34:45 raid1
>> Apr 12 21:34:45 raid0
>> Apr 12 21:34:45 raid456
>> Apr 12 21:34:45 async_raid6_recov
>> Apr 12 21:34:45 async_memcpy
>> Apr 12 21:34:45 async_pq
>> Apr 12 21:34:45 async_xor
>> Apr 12 21:34:45 xor
>> Apr 12 21:34:45 async_tx
>> Apr 12 21:34:45 raid6_pq
>> Apr 12 21:34:45 md_mod
>> Apr 12 21:34:45 sr_mod
>> Apr 12 21:34:45 cdrom
>> Apr 12 21:34:45 usb_storage
>> Apr 12 21:34:45 hid_generic
>> Apr 12 21:34:45 usbhid
>> Apr 12 21:34:45 hid
>> Apr 12 21:34:45 sg
>> Apr 12 21:34:45 sd_mod
>> Apr 12 21:34:45 x86_pkg_temp_thermal
>> Apr 12 21:34:45 coretemp
>> Apr 12 21:34:45 crct10dif_pclmul
>> Apr 12 21:34:45 crc32_pclmul
>> Apr 12 21:34:45 crc32c_intel
>> Apr 12 21:34:45 jitterentropy_rng
>> Apr 12 21:34:45 sha256_ssse3
>> Apr 12 21:34:45 sha256_generic
>> Apr 12 21:34:45 hmac
>> Apr 12 21:34:45 iTCO_wdt
>> Apr 12 21:34:45 iTCO_vendor_support
>> Apr 12 21:34:45 drbg
>> Apr 12 21:34:45 ansi_cprng
>> Apr 12 21:34:45 aesni_intel
>> Apr 12 21:34:45 aes_x86_64
>> Apr 12 21:34:45 lrw
>> Apr 12 21:34:45 gf128mul
>> Apr 12 21:34:45 glue_helper
>> Apr 12 21:34:45 ablk_helper
>> Apr 12 21:34:45 cryptd
>> Apr 12 21:34:45 ahci
>> Apr 12 21:34:45 libahci
>> Apr 12 21:34:45 sb_edac
>> Apr 12 21:34:45 libata
>> Apr 12 21:34:45 igb
>> Apr 12 21:34:45 megaraid_sas
>> Apr 12 21:34:45 xhci_pci
>> Apr 12 21:34:45 ehci_pci
>> Apr 12 21:34:45 i2c_algo_bit
>> Apr 12 21:34:45 xhci_hcd
>> Apr 12 21:34:45 ehci_hcd
>> Apr 12 21:34:45 edac_core
>> Apr 12 21:34:45 ptp
>> Apr 12 21:34:45 mei_me
>> Apr 12 21:34:45 lpc_ich
>> Apr 12 21:34:45 i2c_i801
>> Apr 12 21:34:45 usbcore
>> Apr 12 21:34:45 pps_core
>> Apr 12 21:34:45 mfd_core
>> Apr 12 21:34:45 mei
>> Apr 12 21:34:45 usb_common
>> Apr 12 21:34:45 i2c_core
>> Apr 12 21:34:45 ioatdma
>> Apr 12 21:34:45 scsi_mod
>> Apr 12 21:34:45 dca
>> Apr 12 21:34:45 ipmi_si
>> Apr 12 21:34:45 ipmi_msghandler
>> Apr 12 21:34:45 acpi_power_meter
>> Apr 12 21:34:45 tpm_tis
>> Apr 12 21:34:45 tpm
>> Apr 12 21:34:45 processor
>> Apr 12 21:34:45 button
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75704.965874] CPU: 6 PID: 25339 Comm: main Not tainted
>> 4.4.1 #2
>> Apr 12 21:34:45 [75704.965916] Hardware name: Supermicro Super
>> Server/X10DRi-LN4+, BIOS 2.0 12/17/2015
>> Apr 12 21:34:45 [75704.965979] 0000000000000000
>> Apr 12 21:34:45 ffffffff812abdf3
>> Apr 12 21:34:45 0000000000000000
>> Apr 12 21:34:45 ffffffff810cf5f5
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75704.966054] ffff881ff2870000
>> Apr 12 21:34:45 ffffffff810fcea2
>> Apr 12 21:34:45 0000000000000001
>> Apr 12 21:34:45 ffff881fffcc5e58
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75704.966134] ffff881fffccaf00
>> Apr 12 21:34:45 ffff881fffccb100
>> Apr 12 21:34:45 ffff881ff2870000
>> Apr 12 21:34:45 ffffffff8101bc63
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75704.966211] Call Trace:
>> Apr 12 21:34:45 [75704.966246] <NMI>
>> Apr 12 21:34:45 [<ffffffff812abdf3>] ? dump_stack+0x40/0x5d
>> Apr 12 21:34:45 [75704.966297] [<ffffffff810cf5f5>] ?
>> watchdog_overflow_callback+0xb5/0xd0
>> Apr 12 21:34:45 [75704.966339] [<ffffffff810fcea2>] ?
>> __perf_event_overflow+0x82/0x1c0
>> Apr 12 21:34:45 [75704.966384] [<ffffffff8101bc63>] ?
>> intel_pmu_handle_irq+0x1c3/0x3e0
>> Apr 12 21:34:45 [75704.966431] [<ffffffff8113b5cb>] ?
>> vunmap_page_range+0x1bb/0x320
>> Apr 12 21:34:45 [75704.966474] [<ffffffff813213e0>] ?
>> ghes_copy_tofrom_phys+0x110/0x1d0
>> Apr 12 21:34:45 [75704.966519] [<ffffffff81014f53>] ?
>> perf_event_nmi_handler+0x23/0x40
>> Apr 12 21:34:45 [75704.966560] [<ffffffff81007b85>] ?
>> nmi_handle+0x65/0x100
>> Apr 12 21:34:45 [75704.966597] [<ffffffff81007dfe>] ? do_nmi+0x1de/0x360
>> Apr 12 21:34:45 [75704.970603] [<ffffffff8148f957>] ?
>> end_repeat_nmi+0x1a/0x1e
>> Apr 12 21:34:45 [75704.970644] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:45 [75704.970685] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:45 [75704.970728] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:45 [75704.970768] <<EOE>>
>> Apr 12 21:34:45 [<ffffffffa01b413b>] ? make_request+0x60b/0xbd0 [raid456]
>> Apr 12 21:34:45 [75704.970838] [<ffffffff810815c0>] ? wait_woken+0x80/0x80
>> Apr 12 21:34:45 [75704.970878] [<ffffffff81151ec4>] ?
>> kmem_cache_alloc+0xf4/0x120
>> Apr 12 21:34:45 [75704.970922] [<ffffffffa017632d>] ?
>> md_make_request+0xdd/0x220 [md_mod]
>> Apr 12 21:34:45 [75704.970969] [<ffffffff81219fde>] ?
>> xfs_map_buffer.isra.12+0x2e/0x60
>> Apr 12 21:34:45 [75704.971012] [<ffffffff8128691d>] ?
>> generic_make_request+0xed/0x1d0
>> Apr 12 21:34:45 [75704.971052] [<ffffffff81286a5a>] ?
>> submit_bio+0x5a/0x140
>> Apr 12 21:34:45 [75704.971098] [<ffffffff81113379>] ?
>> release_pages+0xc9/0x270
>> Apr 12 21:34:45 [75704.971145] [<ffffffff811a2c01>] ?
>> do_mpage_readpage+0x2d1/0x640
>> Apr 12 21:34:45 [75704.971187] [<ffffffff811a304d>] ?
>> mpage_readpages+0xdd/0x130
>> Apr 12 21:34:45 [75704.971226] [<ffffffff8121b510>] ?
>> __xfs_get_blocks+0x750/0x750
>> Apr 12 21:34:45 [75704.971267] [<ffffffff8121b510>] ?
>> __xfs_get_blocks+0x750/0x750
>> Apr 12 21:34:45 [75704.971313] [<ffffffff8114ad45>] ?
>> alloc_pages_current+0x85/0x110
>> Apr 12 21:34:45 [75704.971354] [<ffffffff81111d25>] ?
>> __do_page_cache_readahead+0x165/0x1f0
>> Apr 12 21:34:45 [75704.971399] [<ffffffff81105902>] ?
>> pagecache_get_page+0x22/0x1a0
>> Apr 12 21:34:45 [75704.971441] [<ffffffff8110768c>] ?
>> filemap_fault+0x37c/0x400
>> Apr 12 21:34:45 [75704.971481] [<ffffffff8122474b>] ?
>> xfs_filemap_fault+0x3b/0x80
>> Apr 12 21:34:45 [75704.971526] [<ffffffff8112d2da>] ? __do_fault+0x3a/0xc0
>> Apr 12 21:34:45 [75704.971564] [<ffffffff81130883>] ?
>> handle_mm_fault+0x1063/0x1650
>> Apr 12 21:34:45 [75704.971614] [<ffffffff8103bdae>] ?
>> __do_page_fault+0x11e/0x370
>> Apr 12 21:34:45 [75704.971653] [<ffffffff811aa4ff>] ?
>> SyS_epoll_wait+0x8f/0xd0
>> Apr 12 21:34:45 [75704.971694] [<ffffffff8148f64f>] ? page_fault+0x1f/0x30
>> Apr 12 21:34:45 [75705.493640] NMI watchdog: Watchdog detected hard LOCKUP
>> on cpu 12
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75705.493668] Modules linked in:
>> Apr 12 21:34:45 ipt_REJECT
>> Apr 12 21:34:45 nf_reject_ipv4
>> Apr 12 21:34:45 iptable_mangle
>> Apr 12 21:34:45 tun
>> Apr 12 21:34:45 netconsole
>> Apr 12 21:34:45 configfs
>> Apr 12 21:34:45 xt_multiport
>> Apr 12 21:34:45 ip6table_filter
>> Apr 12 21:34:45 ip6_tables
>> Apr 12 21:34:45 iptable_filter
>> Apr 12 21:34:45 ip_tables
>> Apr 12 21:34:45 x_tables
>> Apr 12 21:34:45 bridge
>> Apr 12 21:34:45 stp
>> Apr 12 21:34:45 llc
>> Apr 12 21:34:45 bonding
>> Apr 12 21:34:45 ext4
>> Apr 12 21:34:45 crc16
>> Apr 12 21:34:45 mbcache
>> Apr 12 21:34:45 jbd2
>> Apr 12 21:34:45 raid1
>> Apr 12 21:34:45 raid0
>> Apr 12 21:34:45 raid456
>> Apr 12 21:34:45 async_raid6_recov
>> Apr 12 21:34:45 async_memcpy
>> Apr 12 21:34:45 async_pq
>> Apr 12 21:34:45 async_xor
>> Apr 12 21:34:45 xor
>> Apr 12 21:34:45 async_tx
>> Apr 12 21:34:45 raid6_pq
>> Apr 12 21:34:45 md_mod
>> Apr 12 21:34:45 sr_mod
>> Apr 12 21:34:45 cdrom
>> Apr 12 21:34:45 usb_storage
>> Apr 12 21:34:45 hid_generic
>> Apr 12 21:34:45 usbhid
>> Apr 12 21:34:45 hid
>> Apr 12 21:34:45 sg
>> Apr 12 21:34:45 sd_mod
>> Apr 12 21:34:45 x86_pkg_temp_thermal
>> Apr 12 21:34:45 coretemp
>> Apr 12 21:34:45 crct10dif_pclmul
>> Apr 12 21:34:45 crc32_pclmul
>> Apr 12 21:34:45 crc32c_intel
>> Apr 12 21:34:45 jitterentropy_rng
>> Apr 12 21:34:45 sha256_ssse3
>> Apr 12 21:34:45 sha256_generic
>> Apr 12 21:34:45 hmac
>> Apr 12 21:34:45 iTCO_wdt
>> Apr 12 21:34:45 iTCO_vendor_support
>> Apr 12 21:34:45 drbg
>> Apr 12 21:34:45 ansi_cprng
>> Apr 12 21:34:45 aesni_intel
>> Apr 12 21:34:45 aes_x86_64
>> Apr 12 21:34:45 lrw
>> Apr 12 21:34:45 gf128mul
>> Apr 12 21:34:45 glue_helper
>> Apr 12 21:34:45 ablk_helper
>> Apr 12 21:34:45 cryptd
>> Apr 12 21:34:45 ahci
>> Apr 12 21:34:45 libahci
>> Apr 12 21:34:45 sb_edac
>> Apr 12 21:34:45 libata
>> Apr 12 21:34:45 igb
>> Apr 12 21:34:45 megaraid_sas
>> Apr 12 21:34:45 xhci_pci
>> Apr 12 21:34:45 ehci_pci
>> Apr 12 21:34:45 i2c_algo_bit
>> Apr 12 21:34:45 xhci_hcd
>> Apr 12 21:34:45 ehci_hcd
>> Apr 12 21:34:45 edac_core
>> Apr 12 21:34:45 ptp
>> Apr 12 21:34:45 mei_me
>> Apr 12 21:34:45 lpc_ich
>> Apr 12 21:34:45 i2c_i801
>> Apr 12 21:34:45 usbcore
>> Apr 12 21:34:45 pps_core
>> Apr 12 21:34:45 mfd_core
>> Apr 12 21:34:45 mei
>> Apr 12 21:34:45 usb_common
>> Apr 12 21:34:45 i2c_core
>> Apr 12 21:34:45 ioatdma
>> Apr 12 21:34:45 scsi_mod
>> Apr 12 21:34:45 dca
>> Apr 12 21:34:45 ipmi_si
>> Apr 12 21:34:45 ipmi_msghandler
>> Apr 12 21:34:45 acpi_power_meter
>> Apr 12 21:34:45 tpm_tis
>> Apr 12 21:34:45 tpm
>> Apr 12 21:34:45 processor
>> Apr 12 21:34:45 button
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75705.494688] CPU: 12 PID: 32350 Comm: main Not tainted
>> 4.4.1 #2
>> Apr 12 21:34:45 [75705.494728] Hardware name: Supermicro Super
>> Server/X10DRi-LN4+, BIOS 2.0 12/17/2015
>> Apr 12 21:34:45 [75705.494790] 0000000000000000
>> Apr 12 21:34:45 ffffffff812abdf3
>> Apr 12 21:34:45 0000000000000000
>> Apr 12 21:34:45 ffffffff810cf5f5
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75705.494886] ffff883ff29a0000
>> Apr 12 21:34:45 ffffffff810fcea2
>> Apr 12 21:34:45 0000000000000001
>> Apr 12 21:34:45 ffff88407fc85e58
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75705.494976] ffff88407fc8af00
>> Apr 12 21:34:45 ffff88407fc8b100
>> Apr 12 21:34:45 ffff883ff29a0000
>> Apr 12 21:34:45 ffffffff8101bc63
>> Apr 12 21:34:45
>> Apr 12 21:34:45 [75705.495064] Call Trace:
>> Apr 12 21:34:45 [75705.495094] <NMI>
>> Apr 12 21:34:45 [<ffffffff812abdf3>] ? dump_stack+0x40/0x5d
>> Apr 12 21:34:45 [75705.495150] [<ffffffff810cf5f5>] ?
>> watchdog_overflow_callback+0xb5/0xd0
>> Apr 12 21:34:45 [75705.495193] [<ffffffff810fcea2>] ?
>> __perf_event_overflow+0x82/0x1c0
>> Apr 12 21:34:45 [75705.495237] [<ffffffff8101bc63>] ?
>> intel_pmu_handle_irq+0x1c3/0x3e0
>> Apr 12 21:34:45 [75705.495284] [<ffffffff8113b5cb>] ?
>> vunmap_page_range+0x1bb/0x320
>> Apr 12 21:34:45 [75705.495330] [<ffffffff813213e0>] ?
>> ghes_copy_tofrom_phys+0x110/0x1d0
>> Apr 12 21:34:45 [75705.495373] [<ffffffff81014f53>] ?
>> perf_event_nmi_handler+0x23/0x40
>> Apr 12 21:34:45 [75705.495418] [<ffffffff81007b85>] ?
>> nmi_handle+0x65/0x100
>> Apr 12 21:34:45 [75705.495458] [<ffffffff81007d2e>] ? do_nmi+0x10e/0x360
>> Apr 12 21:34:45 [75705.495497] [<ffffffff8148f957>] ?
>> end_repeat_nmi+0x1a/0x1e
>> Apr 12 21:34:45 [75705.495540] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:45 [75705.495581] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:45 [75705.495621] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:45 [75705.495661] <<EOE>>
>> Apr 12 21:34:45 [<ffffffffa01b413b>] ? make_request+0x60b/0xbd0 [raid456]
>> Apr 12 21:34:45 [75705.495733] [<ffffffff81282d87>] ?
>> blk_rq_init+0x87/0xa0
>> Apr 12 21:34:45 [75705.495771] [<ffffffff81283e3c>] ?
>> get_request+0x29c/0x6e0
>> Apr 12 21:34:45 [75705.495812] [<ffffffff810815c0>] ? wait_woken+0x80/0x80
>> Apr 12 21:34:45 [75705.495853] [<ffffffffa017632d>] ?
>> md_make_request+0xdd/0x220 [md_mod]
>> Apr 12 21:34:45 [75705.495898] [<ffffffff8128829e>] ?
>> blk_queue_bio+0x15e/0x350
>> Apr 12 21:34:45 [75705.495937] [<ffffffff8128691d>] ?
>> generic_make_request+0xed/0x1d0
>> Apr 12 21:34:45 [75705.495978] [<ffffffff81286a5a>] ?
>> submit_bio+0x5a/0x140
>> Apr 12 21:34:45 [75705.496018] [<ffffffff811a215e>] ?
>> mpage_bio_submit+0x1e/0x30
>> Apr 12 21:34:45 [75705.496057] [<ffffffff811a3076>] ?
>> mpage_readpages+0x106/0x130
>> Apr 12 21:34:45 [75705.496102] [<ffffffff8121b510>] ?
>> __xfs_get_blocks+0x750/0x750
>> Apr 12 21:34:45 [75705.496144] [<ffffffff8121b510>] ?
>> __xfs_get_blocks+0x750/0x750
>> Apr 12 21:34:45 [75705.496185] [<ffffffff8114ad45>] ?
>> alloc_pages_current+0x85/0x110
>> Apr 12 21:34:45 [75705.496227] [<ffffffff81111d25>] ?
>> __do_page_cache_readahead+0x165/0x1f0
>> Apr 12 21:34:45 [75705.496268] [<ffffffff811344f5>] ? vma_link+0x75/0xb0
>> Apr 12 21:34:45 [75705.496307] [<ffffffff811120eb>] ?
>> force_page_cache_readahead+0x9b/0xe0
>> Apr 12 21:34:45 [75705.496352] [<ffffffff8113f876>] ?
>> madvise_willneed+0x76/0x140
>> Apr 12 21:34:45 [75705.496395] [<ffffffff811301ce>] ?
>> handle_mm_fault+0x9ae/0x1650
>> Apr 12 21:34:45 [75705.496437] [<ffffffff81133dcb>] ? find_vma+0x5b/0x70
>> Apr 12 21:34:45 [75705.496476] [<ffffffff8113fc52>] ?
>> SyS_madvise+0x312/0x6f0
>> Apr 12 21:34:45 [75705.496515] [<ffffffff8148d9db>] ?
>> entry_SYSCALL_64_fastpath+0x16/0x6e
>> Apr 12 21:34:47 [75707.118049] NMI watchdog: Watchdog detected hard LOCKUP
>> on cpu 15
>> Apr 12 21:34:47
>> Apr 12 21:34:47 [75707.118078] Modules linked in:
>> Apr 12 21:34:47 ipt_REJECT
>> Apr 12 21:34:47 nf_reject_ipv4
>> Apr 12 21:34:47 iptable_mangle
>> Apr 12 21:34:47 tun
>> Apr 12 21:34:47 netconsole
>> Apr 12 21:34:47 configfs
>> Apr 12 21:34:47 xt_multiport
>> Apr 12 21:34:47 ip6table_filter
>> Apr 12 21:34:47 ip6_tables
>> Apr 12 21:34:47 iptable_filter
>> Apr 12 21:34:47 ip_tables
>> Apr 12 21:34:47 x_tables
>> Apr 12 21:34:47 bridge
>> Apr 12 21:34:47 stp
>> Apr 12 21:34:47 llc
>> Apr 12 21:34:47 bonding
>> Apr 12 21:34:47 ext4
>> Apr 12 21:34:47 crc16
>> Apr 12 21:34:47 mbcache
>> Apr 12 21:34:47 jbd2
>> Apr 12 21:34:47 raid1
>> Apr 12 21:34:47 raid0
>> Apr 12 21:34:47 raid456
>> Apr 12 21:34:47 async_raid6_recov
>> Apr 12 21:34:47 async_memcpy
>> Apr 12 21:34:47 async_pq
>> Apr 12 21:34:47 async_xor
>> Apr 12 21:34:47 xor
>> Apr 12 21:34:47 async_tx
>> Apr 12 21:34:47 raid6_pq
>> Apr 12 21:34:47 md_mod
>> Apr 12 21:34:47 sr_mod
>> Apr 12 21:34:47 cdrom
>> Apr 12 21:34:47 usb_storage
>> Apr 12 21:34:47 hid_generic
>> Apr 12 21:34:47 usbhid
>> Apr 12 21:34:47 hid
>> Apr 12 21:34:47 sg
>> Apr 12 21:34:47 sd_mod
>> Apr 12 21:34:47 x86_pkg_temp_thermal
>> Apr 12 21:34:47 coretemp
>> Apr 12 21:34:47 crct10dif_pclmul
>> Apr 12 21:34:47 crc32_pclmul
>> Apr 12 21:34:47 crc32c_intel
>> Apr 12 21:34:47 jitterentropy_rng
>> Apr 12 21:34:47 sha256_ssse3
>> Apr 12 21:34:47 sha256_generic
>> Apr 12 21:34:47 hmac
>> Apr 12 21:34:47 iTCO_wdt
>> Apr 12 21:34:47 iTCO_vendor_support
>> Apr 12 21:34:47 drbg
>> Apr 12 21:34:47 ansi_cprng
>> Apr 12 21:34:47 aesni_intel
>> Apr 12 21:34:47 aes_x86_64
>> Apr 12 21:34:47 lrw
>> Apr 12 21:34:47 gf128mul
>> Apr 12 21:34:47 glue_helper
>> Apr 12 21:34:47 ablk_helper
>> Apr 12 21:34:47 cryptd
>> Apr 12 21:34:47 ahci
>> Apr 12 21:34:47 libahci
>> Apr 12 21:34:47 sb_edac
>> Apr 12 21:34:47 libata
>> Apr 12 21:34:47 igb
>> Apr 12 21:34:47 megaraid_sas
>> Apr 12 21:34:47 xhci_pci
>> Apr 12 21:34:47 ehci_pci
>> Apr 12 21:34:47 i2c_algo_bit
>> Apr 12 21:34:47 xhci_hcd
>> Apr 12 21:34:47 ehci_hcd
>> Apr 12 21:34:47 edac_core
>> Apr 12 21:34:47 ptp
>> Apr 12 21:34:47 mei_me
>> Apr 12 21:34:47 lpc_ich
>> Apr 12 21:34:47 i2c_i801
>> Apr 12 21:34:47 usbcore
>> Apr 12 21:34:47 pps_core
>> Apr 12 21:34:47 mfd_core
>> Apr 12 21:34:47 mei
>> Apr 12 21:34:47 usb_common
>> Apr 12 21:34:47 i2c_core
>> Apr 12 21:34:47 ioatdma
>> Apr 12 21:34:47 scsi_mod
>> Apr 12 21:34:47 dca
>> Apr 12 21:34:47 ipmi_si
>> Apr 12 21:34:47 ipmi_msghandler
>> Apr 12 21:34:47 acpi_power_meter
>> Apr 12 21:34:47 tpm_tis
>> Apr 12 21:34:47 tpm
>> Apr 12 21:34:47 processor
>> Apr 12 21:34:47 button
>> Apr 12 21:34:47
>> Apr 12 21:34:47 [75707.119088] CPU: 15 PID: 31940 Comm: main Not tainted
>> 4.4.1 #2
>> Apr 12 21:34:47 [75707.119134] Hardware name: Supermicro Super
>> Server/X10DRi-LN4+, BIOS 2.0 12/17/2015
>> Apr 12 21:34:47 [75707.119196] 0000000000000000
>> Apr 12 21:34:47 ffffffff812abdf3
>> Apr 12 21:34:47 0000000000000000
>> Apr 12 21:34:47 ffffffff810cf5f5
>> Apr 12 21:34:47
>> Apr 12 21:34:47 [75707.119277] ffff883ff2a20000
>> Apr 12 21:34:47 ffffffff810fcea2
>> Apr 12 21:34:47 0000000000000001
>> Apr 12 21:34:47 ffff88407fce5e58
>> Apr 12 21:34:47
>> Apr 12 21:34:47 [75707.119360] ffff88407fceaf00
>> Apr 12 21:34:47 ffff88407fceb100
>> Apr 12 21:34:47 ffff883ff2a20000
>> Apr 12 21:34:47 ffffffff8101bc63
>> Apr 12 21:34:47
>> Apr 12 21:34:47 [75707.119439] Call Trace:
>> Apr 12 21:34:47 [75707.119471] <NMI>
>> Apr 12 21:34:47 [<ffffffff812abdf3>] ? dump_stack+0x40/0x5d
>> Apr 12 21:34:47 [75707.119527] [<ffffffff810cf5f5>] ?
>> watchdog_overflow_callback+0xb5/0xd0
>> Apr 12 21:34:47 [75707.119571] [<ffffffff810fcea2>] ?
>> __perf_event_overflow+0x82/0x1c0
>> Apr 12 21:34:47 [75707.119614] [<ffffffff8101bc63>] ?
>> intel_pmu_handle_irq+0x1c3/0x3e0
>> Apr 12 21:34:47 [75707.119657] [<ffffffff8113b5cb>] ?
>> vunmap_page_range+0x1bb/0x320
>> Apr 12 21:34:47 [75707.119703] [<ffffffff813213e0>] ?
>> ghes_copy_tofrom_phys+0x110/0x1d0
>> Apr 12 21:34:47 [75707.119758] [<ffffffff81014f53>] ?
>> perf_event_nmi_handler+0x23/0x40
>> Apr 12 21:34:47 [75707.119800] [<ffffffff81007b85>] ?
>> nmi_handle+0x65/0x100
>> Apr 12 21:34:47 [75707.119838] [<ffffffff81007d2e>] ? do_nmi+0x10e/0x360
>> Apr 12 21:34:47 [75707.119878] [<ffffffff8148f957>] ?
>> end_repeat_nmi+0x1a/0x1e
>> Apr 12 21:34:47 [75707.119920] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:47 [75707.119962] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:47 [75707.120002] [<ffffffff810862ca>] ?
>> queued_spin_lock_slowpath+0xea/0x150
>> Apr 12 21:34:47 [75707.120042] <<EOE>>
>> Apr 12 21:34:47 [<ffffffffa01b413b>] ? make_request+0x60b/0xbd0 [raid456]
>> Apr 12 21:34:47 [75707.120113] [<ffffffff810815c0>] ? wait_woken+0x80/0x80
>> Apr 12 21:34:47 [75707.120152] [<ffffffffa017632d>] ?
>> md_make_request+0xdd/0x220 [md_mod]
>> Apr 12 21:34:47 [75707.120195] [<ffffffff8128691d>] ?
>> generic_make_request+0xed/0x1d0
>> Apr 12 21:34:47 [75707.120236] [<ffffffff81286a5a>] ?
>> submit_bio+0x5a/0x140
>> Apr 12 21:34:47 [75707.120277] [<ffffffff8112afaf>] ?
>> workingset_refault+0x4f/0xa0
>> Apr 12 21:34:47 [75707.120320] [<ffffffff811a215e>] ?
>> mpage_bio_submit+0x1e/0x30
>> Apr 12 21:34:47 [75707.120359] [<ffffffff811a3076>] ?
>> mpage_readpages+0x106/0x130
>> Apr 12 21:34:47 [75707.120401] [<ffffffff8121b510>] ?
>> __xfs_get_blocks+0x750/0x750
>> Apr 12 21:34:47 [75707.120439] [<ffffffff8121b510>] ?
>> __xfs_get_blocks+0x750/0x750
>> Apr 12 21:34:47 [75707.120481] [<ffffffff8114ad45>] ?
>> alloc_pages_current+0x85/0x110
>> Apr 12 21:34:47 [75707.120523] [<ffffffff81111d25>] ?
>> __do_page_cache_readahead+0x165/0x1f0
>> Apr 12 21:34:47 [75707.120564] [<ffffffff811344f5>] ? vma_link+0x75/0xb0
>> Apr 12 21:34:47 [75707.120602] [<ffffffff811120c7>] ?
>> force_page_cache_readahead+0x77/0xe0
>> Apr 12 21:34:47 [75707.120644] [<ffffffff8113f876>] ?
>> madvise_willneed+0x76/0x140
>> Apr 12 21:34:47 [75707.120683] [<ffffffff811301ce>] ?
>> handle_mm_fault+0x9ae/0x1650
>> Apr 12 21:34:47 [75707.120722] [<ffffffff81133dcb>] ? find_vma+0x5b/0x70
>> Apr 12 21:34:47 [75707.120760] [<ffffffff8113fc52>] ?
>> SyS_madvise+0x312/0x6f0
>> Apr 12 21:34:47 [75707.120799] [<ffffffff8148d9db>] ?
>> entry_SYSCALL_64_fastpath+0x16/0x6e
>>
>> Once this starts, a couple of minutes goes by and the machine locks up
>> completely.
>>
>> I have been unable to locate the problem here, anyone that can point me in
>> the right direction?
>>
>> Best regards
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/4] scatterlist: Introduce some helper functions
From: Baolin Wang @ 2016-04-20 7:34 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Herbert Xu, David Miller, Alasdair G Kergon, Mike Snitzer,
Jens Axboe, dm-devel, Andrew Morton, david.s.gordon, Tom Lendacky,
Masahiro Yamada, smueller, tadeusz.struk, Masanari Iida, shli,
Mark Brown, Linus Walleij, Arnd Bergmann, LKML, linux-crypto,
linux-raid
In-Reply-To: <CAMz4kuKcJKHKoX8JTs5zSrre5y+cVo+hcHS6BZi1M=WOAHyu-g@mail.gmail.com>
Hi Robert,
On 5 April 2016 at 15:10, Baolin Wang <baolin.wang@linaro.org> wrote:
> Hi Robert,
>
> Sorry for the late reply.
>
> On 2 April 2016 at 23:00, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> Baolin Wang <baolin.wang@linaro.org> writes:
>>
>>> +/**
>>> + * sg_is_contiguous - Check if the scatterlists are contiguous
>>> + * @sga: SG entry
>>> + * @sgb: SG entry
>>> + *
>>> + * Description:
>>> + * If the sga scatterlist is contiguous with the sgb scatterlist,
>>> + * that means they can be merged together.
>>> + *
>>> + **/
>>> +static inline bool sg_is_contiguous(struct scatterlist *sga,
>>> + struct scatterlist *sgb)
>>> +{
>>> + return *(unsigned long *)sg_virt(sga) + sga->length ==
>>> + *(unsigned long *)sg_virt(sgb);
>> As I already said, I don't like casts.
>
> OK. Could you give me a good example. Thanks.
>
>>
>> But let's take some height : you're needing this function to decide to merge
>> scatterlists. That means that you think the probability of having 2 scatterlist
>> mergeable is not meaningless, ie. 50% or more.
>>
>> I suppose your scatterlists are allocated through kmalloc(). I'd like to know,
>> through your testing, what is the success rate of sg_is_contiguous(), ie. I'd
>> like to know how many times sg_is_contiguous() was called, and amongst these
>> calls how many times it returned true.
>>
>> That will tell me how "worth" is this optimization.
>
> I think this is just one useful API for users, If the rate is only 1%,
> we also need to check if they are contiguous to decide if they can be
> coalesced.
>
>>
>>> + * sg_add_sg_to_table - Add one scatterlist into sg table
>>> + * @sgt: The sg table header to use
>>> + * @src: The sg need to be added into sg table
>>> + *
>>> + * Description:
>>> + * The 'nents' member indicates how many mapped scatterlists has been added
>>> + * in the dynamic sg table. The 'orig_nents' member indicates the size of the
>>> + * dynamic sg table.
>>> + *
>>> + * Copy one mapped @src@ scatterlist into the dynamic sg table and increase
>>> + * 'nents' member.
>>> + *
>>> + **/
>> Okay, I still believe this one is wrong, because we don't understand each other.
>> So let's take an example :
>> sg_table = {
>> .sgl = {
>> {
>> .page_link = PAGE_48,
>> .offset = 0,
>> .length = 2048,
>> .dma_address = 0x30000,
>> .dma_length = 4096,
>> },
>> {
>> .page_link = PAGE_48 | 0x02,
>> .offset = 2048,
>> .length = 2048,
>> .dma_address = 0,
>> .dma_length = 0,
>> },
>> },
>> .nents = 1,
>> .orig_nents = 2,
>> };
>>
>> In this example, by sheer luck the 2 scatterlist entries were physically
>> contiguous, and the mapping function coallesced the 2 entries into only one
>> (dma_address, dma_length) entry. That could also happen with an IOMMU by the
>> way. Therefore, sg_table.nents = 1.
>>
>> If I understand your function correctly, it will erase sg_table.sgl[1], and that
>> looks incorrect to me. This is why I can't understand how your code can be
>> correct, and why I say you add a new "meaning" to sg_table->nents, which is not
>> consistent with the meaning I understand.
>
> I think you misunderstood my point. The 'sg_add_sg_to_table()'
> function is used to add one mapped scatterlist into the dynamic sg
> table. For example:
> 1. How to add one mapped sg into dynamic sg table
> (1) If we allocate one dynamic sg table with 3 (small size can be
> showed easily) empty scatterlists.:
> sg_table = {
> .sgl = {
> {
> .page_link = 0,
> .offset = 0,
> .length = 0,
> },
> {
> .page_link = 0,
> .offset = 0,
> .length = 0,
> },
> {
> .page_link = 0 | 0x02,
> .offset = 0,
> .length = 0,
> },
> },
> .nents = 0,
> .orig_nents = 3,
> };
>
> (2) If some module (like dm-crypt module) always sends one mapped
> scatterlist (size is always 512bytes) to another module (crypto
> driver) to handle the mapped scatterlist at one time. But we want to
> collect the mapped scatterlist into one dynamic sg table to manage
> them together, means we can send multiple mapped scatterlists (from
> sg_table->sgl) to the crypto driver to handle them together to improve
> its efficiency. So we add one mapped scatterlists into the dynamic sg
> table.
> mapped sg = {
> .page_link = PAGE_20,
> .offset = 0,
> .length = 512,
> },
>
> Add into synamic sg table ------->
> sg_table = {
> .sgl = {
> {
> .page_link = PAGE_20 | 0x02,
> .offset = 0,
> .length = 512,
> },
> {
> .page_link = 0,
> .offset = 0,
> .length = 0,
> },
> {
> .page_link = 0,
> .offset = 0,
> .length = 0,
> },
> },
> .nents = 1,
> .orig_nents = 3,
> };
>
> Another two mapped scatterlists are added into synamic sg table ------->
> sg_table = {
> .sgl = {
> {
> .page_link = PAGE_20,
> .offset = 0,
> .length = 512,
> },
> {
> .page_link = PAGE_25,
> .offset = 0,
> .length = 512,
> },
> {
> .page_link = PAGE_28 | 0x20,
> .offset = 0,
> .length = 512,
> },
> },
> .nents = 3,
> .orig_nents = 3,
> };
>
> Then we can send the dynamic sg table to the crypto engine driver to
> handle them together at one time. (If the dynamic sg table size is
> 512, then the crypto engine driver can handle 512 scatterlists at one
> time, which can improve much efficiency). That's the reason why we
> want to introduce the dynamic sg table.
>
> 2. How to coalesce
> (1) If one mapped scatterlsit already has been added into dynamic sg table:
> sg_table = {
> .sgl = {
> {
> .page_link = PAGE_20 | 0x02,
> .offset = 0,
> .length = 512,
> },
> {
> .page_link = 0,
> .offset = 0,
> .length = 0,
> },
> {
> .page_link = 0,
> .offset = 0,
> .length = 0,
> },
> },
> .nents = 1,
> .orig_nents = 3,
> };
>
> (2) Another mapped scatterlist comes.
> mapped sg = {
> .page_link = PAGE_20,
> .offset = 512,
> .length = 512,
> },
>
> So we check the new mapped scatterlist can be coalesced into previous
> one in dynamic sg table like this:
> sg_table = {
> .sgl = {
> {
> .page_link = PAGE_20 | 0x02,
> .offset = 0,
> .length = 1024,
> },
> {
> .page_link = 0,
> .offset = 0,
> .length = 0,
> },
> {
> .page_link = 0,
> .offset = 0,
> .length = 0,
> },
> },
> .nents = 1,
> .orig_nents = 3,
> };
>
> It's done. We coalesced one scatterlist into antoher one to expand the
> scatterlist's length.
> Thanks for your comments.
>
It seems there are no more comments about this patchset? We really
want to these APIs to coalesce scatterlists to improve the crypto
engine efficiency. Thanks.
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: [PATCH v2 1/4] scatterlist: Introduce some helper functions
From: Herbert Xu @ 2016-04-20 8:38 UTC (permalink / raw)
To: Baolin Wang
Cc: Robert Jarzmik, David Miller, Alasdair G Kergon, Mike Snitzer,
Jens Axboe, dm-devel, Andrew Morton, david.s.gordon, Tom Lendacky,
Masahiro Yamada, smueller, tadeusz.struk, Masanari Iida, shli,
Mark Brown, Linus Walleij, Arnd Bergmann, LKML, linux-crypto,
linux-raid
In-Reply-To: <CAMz4kuK41221jQGtDb0d4MfOXwr=7S5_1f0ThC3c+8TKHs6VgA@mail.gmail.com>
On Wed, Apr 20, 2016 at 03:34:47PM +0800, Baolin Wang wrote:
> It seems there are no more comments about this patchset? We really
> want to these APIs to coalesce scatterlists to improve the crypto
> engine efficiency. Thanks.
Your patch-set makes no sense. If the data can be coalesced then
it shouldn't have been split up in the first place. I'm nacking
the whole series.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Hard CPU Lockup when accessing MD RAID5
From: John Stoffel @ 2016-04-20 15:29 UTC (permalink / raw)
To: Daniel Walker; +Cc: linux-raid
In-Reply-To: <57172735.9030202@ftwinc.net>
Daniel,
This is one of those hard problems to diagnose. Can you take the
system out of production and run some stress tests on it to see how it
does?
Have you updated all the firmware on the board? Have you disabled
hyperthreading as well? Is there any overclocking or stuff like that
happening? If so, go back to the BIOS "safe" defaults.
Do you have another system with the same hardware that's working fine
in the same type of setup? Then that does point to hardware.
Is your power supply maxed out or near the limits? Maybe you're
getting a slight under-voltage? Not likely... but you never know.
And why is the kernel tainted? Are you adding in third party modules?
If so, remove them completely from the system. SuperMicros don't
generally require anything like that in my experience.
Is it some of the extra monitoring modules you have installed?
Good luck!
John
>>>>> "Daniel" == Daniel Walker <admin@ftwinc.net> writes:
Daniel> Hi,
Daniel> I upgraded the kernel to the latest stable with debugging enabled
Daniel> (4.5.1) without any luck, this is what is outputted in dmesg:
Daniel> [262448.558983] INFO: task php:13376 blocked for more than 120 seconds.
Daniel> [262448.559057] Tainted: G W 4.5.1 #1
Daniel> [262448.559092] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
Daniel> disables this message.
Daniel> [262448.559246] php D
Daniel> ffff88001c297a18
Daniel> 0 13376 12277 0x00000000
Daniel> [262448.559519] ffff88001c297a18
Daniel> ffff881ff248c100
Daniel> ffff880013e9b400
Daniel> ffff881fea472000
Daniel> [262448.559603] ffff88001c297ae8
Daniel> ffff88001c298000
Daniel> ffff881c5cac1b30
Daniel> ffff880013e9b400
Daniel> [262448.560046] 0000000000020001
Daniel> 0000000545ea7820
Daniel> ffff88001c297a30
Daniel> ffffffff814d5690
Daniel> [262448.560485] Call Trace:
Daniel> [262448.560541] [<ffffffff814d5690>] schedule+0x30/0x80
Daniel> [262448.560761] [<ffffffff814d823e>] schedule_timeout+0x21e/0x2a0
Daniel> [262448.560828] [<ffffffff81217c3d>] ?
Daniel> xfs_bmap_search_extents+0x7d/0x100
Daniel> [262448.561000] [<ffffffff810902d9>] ? down_trylock+0x29/0x40
Daniel> [262448.561135] [<ffffffff814d726f>] __down+0x5f/0xa0
Daniel> [262448.561268] [<ffffffff8124bdd6>] ? _xfs_buf_find+0x156/0x350
Daniel> [262448.561347] [<ffffffff8109032c>] down+0x3c/0x50
Daniel> [262448.561390] [<ffffffff8124bbc7>] xfs_buf_lock+0x37/0xf0
Daniel> [262448.561435] [<ffffffff8124bdd6>] _xfs_buf_find+0x156/0x350
Daniel> [262448.561557] [<ffffffff8124bff5>] xfs_buf_get_map+0x25/0x280
Daniel> [262448.561603] [<ffffffff81268f4b>] ? kmem_zone_alloc+0x7b/0x120
Daniel> [262448.561666] [<ffffffff8124cbe8>] xfs_buf_read_map+0x28/0x180
Daniel> [262448.561768] [<ffffffff8127830b>] xfs_trans_read_buf_map+0xeb/0x300
Daniel> [262448.561809] [<ffffffff8123f7da>] xfs_imap_to_bp+0x5a/0xc0
Daniel> [262448.561881] [<ffffffff8125b7a5>] xfs_iunlink_remove+0x275/0x3a0
Daniel> [262448.561943] [<ffffffff81268f4b>] ? kmem_zone_alloc+0x7b/0x120
Daniel> [262448.561988] [<ffffffff8125ec33>] xfs_ifree+0x33/0xd0
Daniel> [262448.562033] [<ffffffff8125ed85>] xfs_inactive_ifree+0xb5/0x200
Daniel> [262448.562109] [<ffffffff8125ef58>] xfs_inactive+0x88/0x110
Daniel> [262448.562296] [<ffffffff81263f31>] xfs_fs_evict_inode+0xc1/0x110
Daniel> [262448.562344] [<ffffffff811a42fb>] evict+0xbb/0x180
Daniel> [262448.562405] [<ffffffff811a4bb3>] iput+0x193/0x200
Daniel> [262448.562483] [<ffffffff811a08d2>] d_delete+0x122/0x160
Daniel> [262448.562520] [<ffffffff81195b99>] vfs_rmdir+0xf9/0x120
Daniel> [262448.562559] [<ffffffff81199d17>] do_rmdir+0x1b7/0x1d0
Daniel> [262448.562607] [<ffffffff81001210>] ? exit_to_usermode_loop+0x90/0xb0
Daniel> [262448.562665] [<ffffffff8119a921>] SyS_rmdir+0x11/0x20
Daniel> [262448.562891] [<ffffffff814d8f1b>]
Daniel> entry_SYSCALL_64_fastpath+0x16/0x6e
Daniel> [262489.707201] NMI watchdog: Watchdog detected hard LOCKUP on cpu 15
Daniel> [262489.707227] Modules linked in:
Daniel> ipt_MASQUERADE
Daniel> nf_nat_masquerade_ipv4
Daniel> iptable_nat
Daniel> nf_conntrack_ipv4
Daniel> nf_defrag_ipv4
Daniel> nf_nat_ipv4
Daniel> nf_nat
Daniel> nf_conntrack
Daniel> ipt_REJECT
Daniel> nf_reject_ipv4
Daniel> iptable_mangle
Daniel> netconsole
Daniel> configfs
Daniel> tun
Daniel> xt_multiport
Daniel> ip6table_filter
Daniel> ip6_tables
Daniel> iptable_filter
Daniel> ip_tables
Daniel> x_tables
Daniel> bridge
Daniel> stp
Daniel> llc
Daniel> bonding
Daniel> ext4
Daniel> crc16
Daniel> mbcache
Daniel> jbd2
Daniel> raid1
Daniel> raid0
Daniel> raid456
Daniel> async_raid6_recov
Daniel> async_memcpy
Daniel> async_pq
Daniel> async_xor
Daniel> xor
Daniel> async_tx
Daniel> raid6_pq
Daniel> md_mod
Daniel> sg
Daniel> sd_mod
Daniel> hid_generic
Daniel> usbhid
Daniel> hid
Daniel> x86_pkg_temp_thermal
Daniel> coretemp
Daniel> crct10dif_pclmul
Daniel> crc32_pclmul
Daniel> crc32c_intel
Daniel> ghash_clmulni_intel
Daniel> jitterentropy_rng
Daniel> sha256_ssse3
Daniel> iTCO_wdt
Daniel> sha256_generic
Daniel> iTCO_vendor_support
Daniel> hmac
Daniel> drbg
Daniel> xhci_pci
Daniel> ahci
Daniel> sb_edac
Daniel> ehci_pci
Daniel> ansi_cprng
Daniel> xhci_hcd
Daniel> ehci_hcd
Daniel> libahci
Daniel> i2c_i801
Daniel> edac_core
Daniel> lpc_ich
Daniel> mei_me
Daniel> mfd_core
Daniel> libata
Daniel> usbcore
Daniel> igb
Daniel> mei
Daniel> megaraid_sas
Daniel> i2c_algo_bit
Daniel> usb_common
Daniel> ptp
Daniel> aesni_intel
Daniel> pps_core
Daniel> aes_x86_64
Daniel> ioatdma
Daniel> lrw
Daniel> gf128mul
Daniel> glue_helper
Daniel> ablk_helper
Daniel> i2c_core
Daniel> scsi_mod
Daniel> dca
Daniel> cryptd
Daniel> ipmi_si
Daniel> ipmi_msghandler
Daniel> acpi_power_meter
Daniel> tpm_tis
Daniel> tpm
Daniel> processor
Daniel> button
Daniel> [262489.708066] CPU: 15 PID: 17535 Comm: kworker/u32:6 Tainted:
Daniel> G W 4.5.1 #1
Daniel> [262489.708124] Hardware name: Supermicro Super Server/X10DRi-LN4+,
Daniel> BIOS 2.0 12/17/2015
Daniel> [262489.708187] Workqueue: writeback wb_workfn
Daniel> (flush-9:7)
Daniel> [262489.708228] 0000000000000000
Daniel> ffff88207fde5bd0
Daniel> ffffffff812e00b8
Daniel> 0000000000000000
Daniel> [262489.708298] 0000000000000000
Daniel> ffff88207fde5be8
Daniel> ffffffff810dff1d
Daniel> ffff881ff2270000
Daniel> [262489.708368] ffff88207fde5c20
Daniel> ffffffff8110f8f8
Daniel> 0000000000000001
Daniel> ffff88207fdeaf00
Daniel> [262489.708438] Call Trace:
Daniel> [262489.708467] <NMI>
Daniel> [<ffffffff812e00b8>] dump_stack+0x4d/0x65
Daniel> [262489.708512] [<ffffffff810dff1d>]
Daniel> watchdog_overflow_callback+0xdd/0xf0
Daniel> [262489.708552] [<ffffffff8110f8f8>] __perf_event_overflow+0x88/0x1d0
Daniel> [262489.708589] [<ffffffff811103e4>] perf_event_overflow+0x14/0x20
Daniel> [262489.708627] [<ffffffff8101e320>] intel_pmu_handle_irq+0x1d0/0x4a0
Daniel> [262489.708666] [<ffffffff81155481>] ? vunmap_page_range+0x1a1/0x310
Daniel> [262489.708703] [<ffffffff811555fc>] ?
Daniel> unmap_kernel_range_noflush+0xc/0x10
Daniel> [262489.708748] [<ffffffff8135a543>] ?
Daniel> ghes_copy_tofrom_phys+0x113/0x1e0
Daniel> [262489.708788] [<ffffffff810359da>] ?
Daniel> native_apic_wait_icr_idle+0x1a/0x30
Daniel> [262489.708827] [<ffffffff810096e0>] ? arch_irq_work_raise+0x30/0x40
Daniel> [262489.708865] [<ffffffff810162d8>] perf_event_nmi_handler+0x28/0x50
Daniel> [262489.708902] [<ffffffff81008121>] nmi_handle+0x61/0x110
Daniel> [262489.708939] [<ffffffff810082e7>] do_nmi+0x117/0x3e0
Daniel> [262489.708975] [<ffffffff814dae97>] end_repeat_nmi+0x1a/0x1e
Daniel> [262489.709013] [<ffffffffa01d05f0>] ? raid5_unplug+0x70/0x130
Daniel> [raid456]
Daniel> [262489.709051] [<ffffffffa01d05f0>] ? raid5_unplug+0x70/0x130
Daniel> [raid456]
Daniel> [262489.709089] [<ffffffffa01d05f0>] ? raid5_unplug+0x70/0x130
Daniel> [raid456]
Daniel> [262489.709125] <<EOE>>
Daniel> [<ffffffff812b9b98>] blk_flush_plug_list+0xa8/0x210
Daniel> [262489.709169] [<ffffffff814d5de0>] ? bit_wait_timeout+0x70/0x70
Daniel> [262489.709206] [<ffffffff814d4c04>] io_schedule_timeout+0x54/0x130
Daniel> [262489.709242] [<ffffffff814d5df6>] bit_wait_io+0x16/0x60
Daniel> [262489.709277] [<ffffffff814d5b59>] __wait_on_bit_lock+0x49/0xa0
Daniel> [262489.709314] [<ffffffff81117fd0>] __lock_page+0xb0/0xc0
Daniel> [262489.709352] [<ffffffff8108bdc0>] ?
Daniel> autoremove_wake_function+0x30/0x30
Daniel> [262489.709391] [<ffffffff811250f0>] write_cache_pages+0x2f0/0x4d0
Daniel> [262489.709427] [<ffffffff81122df0>] ? wb_position_ratio+0x1f0/0x1f0
Daniel> [262489.709465] [<ffffffff8112530e>] generic_writepages+0x3e/0x60
Daniel> [262489.709502] [<ffffffff81244c18>] xfs_vm_writepages+0x38/0x40
Daniel> [262489.709539] [<ffffffff81125e29>] do_writepages+0x19/0x30
Daniel> [262489.709574] [<ffffffff811b5c50>]
Daniel> __writeback_single_inode+0x40/0x310
Daniel> [262489.709612] [<ffffffff811b6402>] writeback_sb_inodes+0x242/0x520
Daniel> [262489.709649] [<ffffffff811b676a>] __writeback_inodes_wb+0x8a/0xc0
Daniel> [262489.709686] [<ffffffff811b6a77>] wb_writeback+0x247/0x2d0
Daniel> [262489.709721] [<ffffffff811b716f>] wb_workfn+0x20f/0x3c0
Daniel> [262489.709758] [<ffffffff81067513>] process_one_work+0x143/0x400
Daniel> [262489.709795] [<ffffffff81067cc1>] worker_thread+0x61/0x490
Daniel> [262489.709831] [<ffffffff81067c60>] ? max_active_store+0x60/0x60
Daniel> [262489.709867] [<ffffffff8106c926>] kthread+0xd6/0xf0
Daniel> [262489.709901] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
Daniel> [262489.709937] [<ffffffff814d92af>] ret_from_fork+0x3f/0x70
Daniel> [262489.709972] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
Daniel> [262491.022971] NMI watchdog: Watchdog detected hard LOCKUP on cpu 0
Daniel> [262491.023470] Modules linked in:
Daniel> ipt_MASQUERADE
Daniel> nf_nat_masquerade_ipv4
Daniel> iptable_nat
Daniel> nf_conntrack_ipv4
Daniel> nf_defrag_ipv4
Daniel> nf_nat_ipv4
Daniel> nf_nat
Daniel> nf_conntrack
Daniel> ipt_REJECT
Daniel> nf_reject_ipv4
Daniel> iptable_mangle
Daniel> netconsole
Daniel> configfs
Daniel> tun
Daniel> xt_multiport
Daniel> ip6table_filter
Daniel> ip6_tables
Daniel> iptable_filter
Daniel> ip_tables
Daniel> x_tables
Daniel> bridge
Daniel> stp
Daniel> llc
Daniel> bonding
Daniel> ext4
Daniel> crc16
Daniel> mbcache
Daniel> jbd2
Daniel> raid1
Daniel> raid0
Daniel> raid456
Daniel> async_raid6_recov
Daniel> async_memcpy
Daniel> async_pq
Daniel> async_xor
Daniel> xor
Daniel> async_tx
Daniel> raid6_pq
Daniel> md_mod
Daniel> sg
Daniel> sd_mod
Daniel> hid_generic
Daniel> usbhid
Daniel> hid
Daniel> x86_pkg_temp_thermal
Daniel> coretemp
Daniel> crct10dif_pclmul
Daniel> crc32_pclmul
Daniel> crc32c_intel
Daniel> ghash_clmulni_intel
Daniel> jitterentropy_rng
Daniel> sha256_ssse3
Daniel> iTCO_wdt
Daniel> sha256_generic
Daniel> iTCO_vendor_support
Daniel> hmac
Daniel> drbg
Daniel> xhci_pci
Daniel> ahci
Daniel> sb_edac
Daniel> ehci_pci
Daniel> ansi_cprng
Daniel> xhci_hcd
Daniel> ehci_hcd
Daniel> libahci
Daniel> i2c_i801
Daniel> edac_core
Daniel> lpc_ich
Daniel> mei_me
Daniel> mfd_core
Daniel> libata
Daniel> usbcore
Daniel> igb
Daniel> mei
Daniel> megaraid_sas
Daniel> i2c_algo_bit
Daniel> usb_common
Daniel> ptp
Daniel> aesni_intel
Daniel> pps_core
Daniel> aes_x86_64
Daniel> ioatdma
Daniel> lrw
Daniel> gf128mul
Daniel> glue_helper
Daniel> ablk_helper
Daniel> i2c_core
Daniel> scsi_mod
Daniel> dca
Daniel> cryptd
Daniel> ipmi_si
Daniel> ipmi_msghandler
Daniel> acpi_power_meter
Daniel> tpm_tis
Daniel> tpm
Daniel> processor
Daniel> button
Daniel> [262491.029705] CPU: 0 PID: 1178 Comm: md7_raid5 Tainted: G
Daniel> W 4.5.1 #1
Daniel> [262491.029776] Hardware name: Supermicro Super Server/X10DRi-LN4+,
Daniel> BIOS 2.0 12/17/2015
Daniel> [262491.029849] 0000000000000000
Daniel> ffff88207fc05bd0
Daniel> ffffffff812e00b8
Daniel> 0000000000000000
Daniel> [262491.029988] 0000000000000000
Daniel> ffff88207fc05be8
Daniel> ffffffff810dff1d
Daniel> ffff881fff032000
Daniel> [262491.030124] ffff88207fc05c20
Daniel> ffffffff8110f8f8
Daniel> 0000000000000001
Daniel> ffff88207fc0af00
Daniel> [262491.030260] Call Trace:
Daniel> [262491.030302] <NMI>
Daniel> [<ffffffff812e00b8>] dump_stack+0x4d/0x65
Daniel> [262491.030377] [<ffffffff810dff1d>]
Daniel> watchdog_overflow_callback+0xdd/0xf0
Daniel> [262491.030432] [<ffffffff8110f8f8>] __perf_event_overflow+0x88/0x1d0
Daniel> [262491.030484] [<ffffffff811103e4>] perf_event_overflow+0x14/0x20
Daniel> [262491.030536] [<ffffffff8101e320>] intel_pmu_handle_irq+0x1d0/0x4a0
Daniel> [262491.030589] [<ffffffff81155481>] ? vunmap_page_range+0x1a1/0x310
Daniel> [262491.030640] [<ffffffff811555fc>] ?
Daniel> unmap_kernel_range_noflush+0xc/0x10
Daniel> [262491.030693] [<ffffffff8135a543>] ?
Daniel> ghes_copy_tofrom_phys+0x113/0x1e0
Daniel> [262491.030745] [<ffffffff8135a681>] ? ghes_read_estatus+0x71/0x140
Daniel> [262491.030797] [<ffffffff810162d8>] perf_event_nmi_handler+0x28/0x50
Daniel> [262491.030849] [<ffffffff81008121>] nmi_handle+0x61/0x110
Daniel> [262491.030898] [<ffffffff810083d1>] do_nmi+0x201/0x3e0
Daniel> [262491.030949] [<ffffffff814dae97>] end_repeat_nmi+0x1a/0x1e
Daniel> [262491.030998] [<ffffffff81090d23>] ?
Daniel> queued_spin_lock_slowpath+0x153/0x170
Daniel> [262491.031050] [<ffffffff81090d23>] ?
Daniel> queued_spin_lock_slowpath+0x153/0x170
Daniel> [262491.031102] [<ffffffff81090d23>] ?
Daniel> queued_spin_lock_slowpath+0x153/0x170
Daniel> [262491.031153] <<EOE>>
Daniel> [<ffffffff814d8c6c>] _raw_spin_lock_irq+0x1c/0x20
Daniel> [262491.031225] [<ffffffffa01db6b1>] raid5d+0x91/0x720 [raid456]
Daniel> [262491.031276] [<ffffffff810a4a8a>] ? try_to_del_timer_sync+0x4a/0x60
Daniel> [262491.031328] [<ffffffff810a4ae3>] ? del_timer_sync+0x43/0x50
Daniel> [262491.031377] [<ffffffff814d816e>] ? schedule_timeout+0x14e/0x2a0
Daniel> [262491.031428] [<ffffffff810a4830>] ?
Daniel> trace_event_raw_event_tick_stop+0x100/0x100
Daniel> [262491.031502] [<ffffffffa017874b>] md_thread+0x12b/0x130 [md_mod]
Daniel> [262491.031555] [<ffffffff8108bd90>] ? wait_woken+0x80/0x80
Daniel> [262491.031605] [<ffffffffa0178620>] ? find_pers+0x70/0x70 [md_mod]
Daniel> [262491.031656] [<ffffffff8106c926>] kthread+0xd6/0xf0
Daniel> [262491.031704] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
Daniel> [262491.031753] [<ffffffff814d92af>] ret_from_fork+0x3f/0x70
Daniel> [262491.031802] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
Daniel> [262491.031753] [<ffffffff814d92af>] ret_from_fork+0x3f/0x70
Daniel> [262491.031802] [<ffffffff8106c850>] ? kthread_park+0x50/0x50
Daniel> The server is hosting plain VPS's, there's a few that use it for
Daniel> rtorrent which is quite disk extenssive, but from what I can see that
Daniel> iowait is quite low.
Daniel> There's absolutely nothing logged at all before the lockups, everythings
Daniel> running fine and then suddenly it just crashes, im beginning to think we
Daniel> might have a hardware problem, but im having a hard time finding the
Daniel> actual issue.
Daniel> Any ideas?
Daniel> Best regards
Daniel> Den 13-04-2016 kl. 19:00 skrev Shaohua Li:
>> Looks there is a deadlock trying to hold the device_lock or hash_lock. anything
>> abormal print out before the NMI watchdog? What is running in the machine?
>> Looks this is old kernel, is it possible you can try a latest kernel and report
>> back?
>>
>> Thanks,
>> Shaohua
>>
>> On Tue, Apr 12, 2016 at 09:54:08PM +0000, Daniel Walker wrote:
>>> Im having some issues on a brand new Supermicro server that we have running
>>> in production along side a few other machines which are identical to this
>>> server..
>>>
>>> The output from the netconsole attached to the server is here:
>>>
>>> Apr 12 21:34:45 [75704.964946] NMI watchdog: Watchdog detected hard LOCKUP
>>> on cpu 6
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75704.964973] Modules linked in:
>>> Apr 12 21:34:45 ipt_REJECT
>>> Apr 12 21:34:45 nf_reject_ipv4
>>> Apr 12 21:34:45 iptable_mangle
>>> Apr 12 21:34:45 tun
>>> Apr 12 21:34:45 netconsole
>>> Apr 12 21:34:45 configfs
>>> Apr 12 21:34:45 xt_multiport
>>> Apr 12 21:34:45 ip6table_filter
>>> Apr 12 21:34:45 ip6_tables
>>> Apr 12 21:34:45 iptable_filter
>>> Apr 12 21:34:45 ip_tables
>>> Apr 12 21:34:45 x_tables
>>> Apr 12 21:34:45 bridge
>>> Apr 12 21:34:45 stp
>>> Apr 12 21:34:45 llc
>>> Apr 12 21:34:45 bonding
>>> Apr 12 21:34:45 ext4
>>> Apr 12 21:34:45 crc16
>>> Apr 12 21:34:45 mbcache
>>> Apr 12 21:34:45 jbd2
>>> Apr 12 21:34:45 raid1
>>> Apr 12 21:34:45 raid0
>>> Apr 12 21:34:45 raid456
>>> Apr 12 21:34:45 async_raid6_recov
>>> Apr 12 21:34:45 async_memcpy
>>> Apr 12 21:34:45 async_pq
>>> Apr 12 21:34:45 async_xor
>>> Apr 12 21:34:45 xor
>>> Apr 12 21:34:45 async_tx
>>> Apr 12 21:34:45 raid6_pq
>>> Apr 12 21:34:45 md_mod
>>> Apr 12 21:34:45 sr_mod
>>> Apr 12 21:34:45 cdrom
>>> Apr 12 21:34:45 usb_storage
>>> Apr 12 21:34:45 hid_generic
>>> Apr 12 21:34:45 usbhid
>>> Apr 12 21:34:45 hid
>>> Apr 12 21:34:45 sg
>>> Apr 12 21:34:45 sd_mod
>>> Apr 12 21:34:45 x86_pkg_temp_thermal
>>> Apr 12 21:34:45 coretemp
>>> Apr 12 21:34:45 crct10dif_pclmul
>>> Apr 12 21:34:45 crc32_pclmul
>>> Apr 12 21:34:45 crc32c_intel
>>> Apr 12 21:34:45 jitterentropy_rng
>>> Apr 12 21:34:45 sha256_ssse3
>>> Apr 12 21:34:45 sha256_generic
>>> Apr 12 21:34:45 hmac
>>> Apr 12 21:34:45 iTCO_wdt
>>> Apr 12 21:34:45 iTCO_vendor_support
>>> Apr 12 21:34:45 drbg
>>> Apr 12 21:34:45 ansi_cprng
>>> Apr 12 21:34:45 aesni_intel
>>> Apr 12 21:34:45 aes_x86_64
>>> Apr 12 21:34:45 lrw
>>> Apr 12 21:34:45 gf128mul
>>> Apr 12 21:34:45 glue_helper
>>> Apr 12 21:34:45 ablk_helper
>>> Apr 12 21:34:45 cryptd
>>> Apr 12 21:34:45 ahci
>>> Apr 12 21:34:45 libahci
>>> Apr 12 21:34:45 sb_edac
>>> Apr 12 21:34:45 libata
>>> Apr 12 21:34:45 igb
>>> Apr 12 21:34:45 megaraid_sas
>>> Apr 12 21:34:45 xhci_pci
>>> Apr 12 21:34:45 ehci_pci
>>> Apr 12 21:34:45 i2c_algo_bit
>>> Apr 12 21:34:45 xhci_hcd
>>> Apr 12 21:34:45 ehci_hcd
>>> Apr 12 21:34:45 edac_core
>>> Apr 12 21:34:45 ptp
>>> Apr 12 21:34:45 mei_me
>>> Apr 12 21:34:45 lpc_ich
>>> Apr 12 21:34:45 i2c_i801
>>> Apr 12 21:34:45 usbcore
>>> Apr 12 21:34:45 pps_core
>>> Apr 12 21:34:45 mfd_core
>>> Apr 12 21:34:45 mei
>>> Apr 12 21:34:45 usb_common
>>> Apr 12 21:34:45 i2c_core
>>> Apr 12 21:34:45 ioatdma
>>> Apr 12 21:34:45 scsi_mod
>>> Apr 12 21:34:45 dca
>>> Apr 12 21:34:45 ipmi_si
>>> Apr 12 21:34:45 ipmi_msghandler
>>> Apr 12 21:34:45 acpi_power_meter
>>> Apr 12 21:34:45 tpm_tis
>>> Apr 12 21:34:45 tpm
>>> Apr 12 21:34:45 processor
>>> Apr 12 21:34:45 button
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75704.965874] CPU: 6 PID: 25339 Comm: main Not tainted
>>> 4.4.1 #2
>>> Apr 12 21:34:45 [75704.965916] Hardware name: Supermicro Super
>>> Server/X10DRi-LN4+, BIOS 2.0 12/17/2015
>>> Apr 12 21:34:45 [75704.965979] 0000000000000000
>>> Apr 12 21:34:45 ffffffff812abdf3
>>> Apr 12 21:34:45 0000000000000000
>>> Apr 12 21:34:45 ffffffff810cf5f5
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75704.966054] ffff881ff2870000
>>> Apr 12 21:34:45 ffffffff810fcea2
>>> Apr 12 21:34:45 0000000000000001
>>> Apr 12 21:34:45 ffff881fffcc5e58
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75704.966134] ffff881fffccaf00
>>> Apr 12 21:34:45 ffff881fffccb100
>>> Apr 12 21:34:45 ffff881ff2870000
>>> Apr 12 21:34:45 ffffffff8101bc63
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75704.966211] Call Trace:
>>> Apr 12 21:34:45 [75704.966246] <NMI>
>>> Apr 12 21:34:45 [<ffffffff812abdf3>] ? dump_stack+0x40/0x5d
>>> Apr 12 21:34:45 [75704.966297] [<ffffffff810cf5f5>] ?
>>> watchdog_overflow_callback+0xb5/0xd0
>>> Apr 12 21:34:45 [75704.966339] [<ffffffff810fcea2>] ?
>>> __perf_event_overflow+0x82/0x1c0
>>> Apr 12 21:34:45 [75704.966384] [<ffffffff8101bc63>] ?
>>> intel_pmu_handle_irq+0x1c3/0x3e0
>>> Apr 12 21:34:45 [75704.966431] [<ffffffff8113b5cb>] ?
>>> vunmap_page_range+0x1bb/0x320
>>> Apr 12 21:34:45 [75704.966474] [<ffffffff813213e0>] ?
>>> ghes_copy_tofrom_phys+0x110/0x1d0
>>> Apr 12 21:34:45 [75704.966519] [<ffffffff81014f53>] ?
>>> perf_event_nmi_handler+0x23/0x40
>>> Apr 12 21:34:45 [75704.966560] [<ffffffff81007b85>] ?
>>> nmi_handle+0x65/0x100
>>> Apr 12 21:34:45 [75704.966597] [<ffffffff81007dfe>] ? do_nmi+0x1de/0x360
>>> Apr 12 21:34:45 [75704.970603] [<ffffffff8148f957>] ?
>>> end_repeat_nmi+0x1a/0x1e
>>> Apr 12 21:34:45 [75704.970644] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:45 [75704.970685] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:45 [75704.970728] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:45 [75704.970768] <<EOE>>
>>> Apr 12 21:34:45 [<ffffffffa01b413b>] ? make_request+0x60b/0xbd0 [raid456]
>>> Apr 12 21:34:45 [75704.970838] [<ffffffff810815c0>] ? wait_woken+0x80/0x80
>>> Apr 12 21:34:45 [75704.970878] [<ffffffff81151ec4>] ?
>>> kmem_cache_alloc+0xf4/0x120
>>> Apr 12 21:34:45 [75704.970922] [<ffffffffa017632d>] ?
>>> md_make_request+0xdd/0x220 [md_mod]
>>> Apr 12 21:34:45 [75704.970969] [<ffffffff81219fde>] ?
>>> xfs_map_buffer.isra.12+0x2e/0x60
>>> Apr 12 21:34:45 [75704.971012] [<ffffffff8128691d>] ?
>>> generic_make_request+0xed/0x1d0
>>> Apr 12 21:34:45 [75704.971052] [<ffffffff81286a5a>] ?
>>> submit_bio+0x5a/0x140
>>> Apr 12 21:34:45 [75704.971098] [<ffffffff81113379>] ?
>>> release_pages+0xc9/0x270
>>> Apr 12 21:34:45 [75704.971145] [<ffffffff811a2c01>] ?
>>> do_mpage_readpage+0x2d1/0x640
>>> Apr 12 21:34:45 [75704.971187] [<ffffffff811a304d>] ?
>>> mpage_readpages+0xdd/0x130
>>> Apr 12 21:34:45 [75704.971226] [<ffffffff8121b510>] ?
>>> __xfs_get_blocks+0x750/0x750
>>> Apr 12 21:34:45 [75704.971267] [<ffffffff8121b510>] ?
>>> __xfs_get_blocks+0x750/0x750
>>> Apr 12 21:34:45 [75704.971313] [<ffffffff8114ad45>] ?
>>> alloc_pages_current+0x85/0x110
>>> Apr 12 21:34:45 [75704.971354] [<ffffffff81111d25>] ?
>>> __do_page_cache_readahead+0x165/0x1f0
>>> Apr 12 21:34:45 [75704.971399] [<ffffffff81105902>] ?
>>> pagecache_get_page+0x22/0x1a0
>>> Apr 12 21:34:45 [75704.971441] [<ffffffff8110768c>] ?
>>> filemap_fault+0x37c/0x400
>>> Apr 12 21:34:45 [75704.971481] [<ffffffff8122474b>] ?
>>> xfs_filemap_fault+0x3b/0x80
>>> Apr 12 21:34:45 [75704.971526] [<ffffffff8112d2da>] ? __do_fault+0x3a/0xc0
>>> Apr 12 21:34:45 [75704.971564] [<ffffffff81130883>] ?
>>> handle_mm_fault+0x1063/0x1650
>>> Apr 12 21:34:45 [75704.971614] [<ffffffff8103bdae>] ?
>>> __do_page_fault+0x11e/0x370
>>> Apr 12 21:34:45 [75704.971653] [<ffffffff811aa4ff>] ?
>>> SyS_epoll_wait+0x8f/0xd0
>>> Apr 12 21:34:45 [75704.971694] [<ffffffff8148f64f>] ? page_fault+0x1f/0x30
>>> Apr 12 21:34:45 [75705.493640] NMI watchdog: Watchdog detected hard LOCKUP
>>> on cpu 12
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75705.493668] Modules linked in:
>>> Apr 12 21:34:45 ipt_REJECT
>>> Apr 12 21:34:45 nf_reject_ipv4
>>> Apr 12 21:34:45 iptable_mangle
>>> Apr 12 21:34:45 tun
>>> Apr 12 21:34:45 netconsole
>>> Apr 12 21:34:45 configfs
>>> Apr 12 21:34:45 xt_multiport
>>> Apr 12 21:34:45 ip6table_filter
>>> Apr 12 21:34:45 ip6_tables
>>> Apr 12 21:34:45 iptable_filter
>>> Apr 12 21:34:45 ip_tables
>>> Apr 12 21:34:45 x_tables
>>> Apr 12 21:34:45 bridge
>>> Apr 12 21:34:45 stp
>>> Apr 12 21:34:45 llc
>>> Apr 12 21:34:45 bonding
>>> Apr 12 21:34:45 ext4
>>> Apr 12 21:34:45 crc16
>>> Apr 12 21:34:45 mbcache
>>> Apr 12 21:34:45 jbd2
>>> Apr 12 21:34:45 raid1
>>> Apr 12 21:34:45 raid0
>>> Apr 12 21:34:45 raid456
>>> Apr 12 21:34:45 async_raid6_recov
>>> Apr 12 21:34:45 async_memcpy
>>> Apr 12 21:34:45 async_pq
>>> Apr 12 21:34:45 async_xor
>>> Apr 12 21:34:45 xor
>>> Apr 12 21:34:45 async_tx
>>> Apr 12 21:34:45 raid6_pq
>>> Apr 12 21:34:45 md_mod
>>> Apr 12 21:34:45 sr_mod
>>> Apr 12 21:34:45 cdrom
>>> Apr 12 21:34:45 usb_storage
>>> Apr 12 21:34:45 hid_generic
>>> Apr 12 21:34:45 usbhid
>>> Apr 12 21:34:45 hid
>>> Apr 12 21:34:45 sg
>>> Apr 12 21:34:45 sd_mod
>>> Apr 12 21:34:45 x86_pkg_temp_thermal
>>> Apr 12 21:34:45 coretemp
>>> Apr 12 21:34:45 crct10dif_pclmul
>>> Apr 12 21:34:45 crc32_pclmul
>>> Apr 12 21:34:45 crc32c_intel
>>> Apr 12 21:34:45 jitterentropy_rng
>>> Apr 12 21:34:45 sha256_ssse3
>>> Apr 12 21:34:45 sha256_generic
>>> Apr 12 21:34:45 hmac
>>> Apr 12 21:34:45 iTCO_wdt
>>> Apr 12 21:34:45 iTCO_vendor_support
>>> Apr 12 21:34:45 drbg
>>> Apr 12 21:34:45 ansi_cprng
>>> Apr 12 21:34:45 aesni_intel
>>> Apr 12 21:34:45 aes_x86_64
>>> Apr 12 21:34:45 lrw
>>> Apr 12 21:34:45 gf128mul
>>> Apr 12 21:34:45 glue_helper
>>> Apr 12 21:34:45 ablk_helper
>>> Apr 12 21:34:45 cryptd
>>> Apr 12 21:34:45 ahci
>>> Apr 12 21:34:45 libahci
>>> Apr 12 21:34:45 sb_edac
>>> Apr 12 21:34:45 libata
>>> Apr 12 21:34:45 igb
>>> Apr 12 21:34:45 megaraid_sas
>>> Apr 12 21:34:45 xhci_pci
>>> Apr 12 21:34:45 ehci_pci
>>> Apr 12 21:34:45 i2c_algo_bit
>>> Apr 12 21:34:45 xhci_hcd
>>> Apr 12 21:34:45 ehci_hcd
>>> Apr 12 21:34:45 edac_core
>>> Apr 12 21:34:45 ptp
>>> Apr 12 21:34:45 mei_me
>>> Apr 12 21:34:45 lpc_ich
>>> Apr 12 21:34:45 i2c_i801
>>> Apr 12 21:34:45 usbcore
>>> Apr 12 21:34:45 pps_core
>>> Apr 12 21:34:45 mfd_core
>>> Apr 12 21:34:45 mei
>>> Apr 12 21:34:45 usb_common
>>> Apr 12 21:34:45 i2c_core
>>> Apr 12 21:34:45 ioatdma
>>> Apr 12 21:34:45 scsi_mod
>>> Apr 12 21:34:45 dca
>>> Apr 12 21:34:45 ipmi_si
>>> Apr 12 21:34:45 ipmi_msghandler
>>> Apr 12 21:34:45 acpi_power_meter
>>> Apr 12 21:34:45 tpm_tis
>>> Apr 12 21:34:45 tpm
>>> Apr 12 21:34:45 processor
>>> Apr 12 21:34:45 button
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75705.494688] CPU: 12 PID: 32350 Comm: main Not tainted
>>> 4.4.1 #2
>>> Apr 12 21:34:45 [75705.494728] Hardware name: Supermicro Super
>>> Server/X10DRi-LN4+, BIOS 2.0 12/17/2015
>>> Apr 12 21:34:45 [75705.494790] 0000000000000000
>>> Apr 12 21:34:45 ffffffff812abdf3
>>> Apr 12 21:34:45 0000000000000000
>>> Apr 12 21:34:45 ffffffff810cf5f5
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75705.494886] ffff883ff29a0000
>>> Apr 12 21:34:45 ffffffff810fcea2
>>> Apr 12 21:34:45 0000000000000001
>>> Apr 12 21:34:45 ffff88407fc85e58
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75705.494976] ffff88407fc8af00
>>> Apr 12 21:34:45 ffff88407fc8b100
>>> Apr 12 21:34:45 ffff883ff29a0000
>>> Apr 12 21:34:45 ffffffff8101bc63
>>> Apr 12 21:34:45
>>> Apr 12 21:34:45 [75705.495064] Call Trace:
>>> Apr 12 21:34:45 [75705.495094] <NMI>
>>> Apr 12 21:34:45 [<ffffffff812abdf3>] ? dump_stack+0x40/0x5d
>>> Apr 12 21:34:45 [75705.495150] [<ffffffff810cf5f5>] ?
>>> watchdog_overflow_callback+0xb5/0xd0
>>> Apr 12 21:34:45 [75705.495193] [<ffffffff810fcea2>] ?
>>> __perf_event_overflow+0x82/0x1c0
>>> Apr 12 21:34:45 [75705.495237] [<ffffffff8101bc63>] ?
>>> intel_pmu_handle_irq+0x1c3/0x3e0
>>> Apr 12 21:34:45 [75705.495284] [<ffffffff8113b5cb>] ?
>>> vunmap_page_range+0x1bb/0x320
>>> Apr 12 21:34:45 [75705.495330] [<ffffffff813213e0>] ?
>>> ghes_copy_tofrom_phys+0x110/0x1d0
>>> Apr 12 21:34:45 [75705.495373] [<ffffffff81014f53>] ?
>>> perf_event_nmi_handler+0x23/0x40
>>> Apr 12 21:34:45 [75705.495418] [<ffffffff81007b85>] ?
>>> nmi_handle+0x65/0x100
>>> Apr 12 21:34:45 [75705.495458] [<ffffffff81007d2e>] ? do_nmi+0x10e/0x360
>>> Apr 12 21:34:45 [75705.495497] [<ffffffff8148f957>] ?
>>> end_repeat_nmi+0x1a/0x1e
>>> Apr 12 21:34:45 [75705.495540] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:45 [75705.495581] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:45 [75705.495621] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:45 [75705.495661] <<EOE>>
>>> Apr 12 21:34:45 [<ffffffffa01b413b>] ? make_request+0x60b/0xbd0 [raid456]
>>> Apr 12 21:34:45 [75705.495733] [<ffffffff81282d87>] ?
>>> blk_rq_init+0x87/0xa0
>>> Apr 12 21:34:45 [75705.495771] [<ffffffff81283e3c>] ?
>>> get_request+0x29c/0x6e0
>>> Apr 12 21:34:45 [75705.495812] [<ffffffff810815c0>] ? wait_woken+0x80/0x80
>>> Apr 12 21:34:45 [75705.495853] [<ffffffffa017632d>] ?
>>> md_make_request+0xdd/0x220 [md_mod]
>>> Apr 12 21:34:45 [75705.495898] [<ffffffff8128829e>] ?
>>> blk_queue_bio+0x15e/0x350
>>> Apr 12 21:34:45 [75705.495937] [<ffffffff8128691d>] ?
>>> generic_make_request+0xed/0x1d0
>>> Apr 12 21:34:45 [75705.495978] [<ffffffff81286a5a>] ?
>>> submit_bio+0x5a/0x140
>>> Apr 12 21:34:45 [75705.496018] [<ffffffff811a215e>] ?
>>> mpage_bio_submit+0x1e/0x30
>>> Apr 12 21:34:45 [75705.496057] [<ffffffff811a3076>] ?
>>> mpage_readpages+0x106/0x130
>>> Apr 12 21:34:45 [75705.496102] [<ffffffff8121b510>] ?
>>> __xfs_get_blocks+0x750/0x750
>>> Apr 12 21:34:45 [75705.496144] [<ffffffff8121b510>] ?
>>> __xfs_get_blocks+0x750/0x750
>>> Apr 12 21:34:45 [75705.496185] [<ffffffff8114ad45>] ?
>>> alloc_pages_current+0x85/0x110
>>> Apr 12 21:34:45 [75705.496227] [<ffffffff81111d25>] ?
>>> __do_page_cache_readahead+0x165/0x1f0
>>> Apr 12 21:34:45 [75705.496268] [<ffffffff811344f5>] ? vma_link+0x75/0xb0
>>> Apr 12 21:34:45 [75705.496307] [<ffffffff811120eb>] ?
>>> force_page_cache_readahead+0x9b/0xe0
>>> Apr 12 21:34:45 [75705.496352] [<ffffffff8113f876>] ?
>>> madvise_willneed+0x76/0x140
>>> Apr 12 21:34:45 [75705.496395] [<ffffffff811301ce>] ?
>>> handle_mm_fault+0x9ae/0x1650
>>> Apr 12 21:34:45 [75705.496437] [<ffffffff81133dcb>] ? find_vma+0x5b/0x70
>>> Apr 12 21:34:45 [75705.496476] [<ffffffff8113fc52>] ?
>>> SyS_madvise+0x312/0x6f0
>>> Apr 12 21:34:45 [75705.496515] [<ffffffff8148d9db>] ?
>>> entry_SYSCALL_64_fastpath+0x16/0x6e
>>> Apr 12 21:34:47 [75707.118049] NMI watchdog: Watchdog detected hard LOCKUP
>>> on cpu 15
>>> Apr 12 21:34:47
>>> Apr 12 21:34:47 [75707.118078] Modules linked in:
>>> Apr 12 21:34:47 ipt_REJECT
>>> Apr 12 21:34:47 nf_reject_ipv4
>>> Apr 12 21:34:47 iptable_mangle
>>> Apr 12 21:34:47 tun
>>> Apr 12 21:34:47 netconsole
>>> Apr 12 21:34:47 configfs
>>> Apr 12 21:34:47 xt_multiport
>>> Apr 12 21:34:47 ip6table_filter
>>> Apr 12 21:34:47 ip6_tables
>>> Apr 12 21:34:47 iptable_filter
>>> Apr 12 21:34:47 ip_tables
>>> Apr 12 21:34:47 x_tables
>>> Apr 12 21:34:47 bridge
>>> Apr 12 21:34:47 stp
>>> Apr 12 21:34:47 llc
>>> Apr 12 21:34:47 bonding
>>> Apr 12 21:34:47 ext4
>>> Apr 12 21:34:47 crc16
>>> Apr 12 21:34:47 mbcache
>>> Apr 12 21:34:47 jbd2
>>> Apr 12 21:34:47 raid1
>>> Apr 12 21:34:47 raid0
>>> Apr 12 21:34:47 raid456
>>> Apr 12 21:34:47 async_raid6_recov
>>> Apr 12 21:34:47 async_memcpy
>>> Apr 12 21:34:47 async_pq
>>> Apr 12 21:34:47 async_xor
>>> Apr 12 21:34:47 xor
>>> Apr 12 21:34:47 async_tx
>>> Apr 12 21:34:47 raid6_pq
>>> Apr 12 21:34:47 md_mod
>>> Apr 12 21:34:47 sr_mod
>>> Apr 12 21:34:47 cdrom
>>> Apr 12 21:34:47 usb_storage
>>> Apr 12 21:34:47 hid_generic
>>> Apr 12 21:34:47 usbhid
>>> Apr 12 21:34:47 hid
>>> Apr 12 21:34:47 sg
>>> Apr 12 21:34:47 sd_mod
>>> Apr 12 21:34:47 x86_pkg_temp_thermal
>>> Apr 12 21:34:47 coretemp
>>> Apr 12 21:34:47 crct10dif_pclmul
>>> Apr 12 21:34:47 crc32_pclmul
>>> Apr 12 21:34:47 crc32c_intel
>>> Apr 12 21:34:47 jitterentropy_rng
>>> Apr 12 21:34:47 sha256_ssse3
>>> Apr 12 21:34:47 sha256_generic
>>> Apr 12 21:34:47 hmac
>>> Apr 12 21:34:47 iTCO_wdt
>>> Apr 12 21:34:47 iTCO_vendor_support
>>> Apr 12 21:34:47 drbg
>>> Apr 12 21:34:47 ansi_cprng
>>> Apr 12 21:34:47 aesni_intel
>>> Apr 12 21:34:47 aes_x86_64
>>> Apr 12 21:34:47 lrw
>>> Apr 12 21:34:47 gf128mul
>>> Apr 12 21:34:47 glue_helper
>>> Apr 12 21:34:47 ablk_helper
>>> Apr 12 21:34:47 cryptd
>>> Apr 12 21:34:47 ahci
>>> Apr 12 21:34:47 libahci
>>> Apr 12 21:34:47 sb_edac
>>> Apr 12 21:34:47 libata
>>> Apr 12 21:34:47 igb
>>> Apr 12 21:34:47 megaraid_sas
>>> Apr 12 21:34:47 xhci_pci
>>> Apr 12 21:34:47 ehci_pci
>>> Apr 12 21:34:47 i2c_algo_bit
>>> Apr 12 21:34:47 xhci_hcd
>>> Apr 12 21:34:47 ehci_hcd
>>> Apr 12 21:34:47 edac_core
>>> Apr 12 21:34:47 ptp
>>> Apr 12 21:34:47 mei_me
>>> Apr 12 21:34:47 lpc_ich
>>> Apr 12 21:34:47 i2c_i801
>>> Apr 12 21:34:47 usbcore
>>> Apr 12 21:34:47 pps_core
>>> Apr 12 21:34:47 mfd_core
>>> Apr 12 21:34:47 mei
>>> Apr 12 21:34:47 usb_common
>>> Apr 12 21:34:47 i2c_core
>>> Apr 12 21:34:47 ioatdma
>>> Apr 12 21:34:47 scsi_mod
>>> Apr 12 21:34:47 dca
>>> Apr 12 21:34:47 ipmi_si
>>> Apr 12 21:34:47 ipmi_msghandler
>>> Apr 12 21:34:47 acpi_power_meter
>>> Apr 12 21:34:47 tpm_tis
>>> Apr 12 21:34:47 tpm
>>> Apr 12 21:34:47 processor
>>> Apr 12 21:34:47 button
>>> Apr 12 21:34:47
>>> Apr 12 21:34:47 [75707.119088] CPU: 15 PID: 31940 Comm: main Not tainted
>>> 4.4.1 #2
>>> Apr 12 21:34:47 [75707.119134] Hardware name: Supermicro Super
>>> Server/X10DRi-LN4+, BIOS 2.0 12/17/2015
>>> Apr 12 21:34:47 [75707.119196] 0000000000000000
>>> Apr 12 21:34:47 ffffffff812abdf3
>>> Apr 12 21:34:47 0000000000000000
>>> Apr 12 21:34:47 ffffffff810cf5f5
>>> Apr 12 21:34:47
>>> Apr 12 21:34:47 [75707.119277] ffff883ff2a20000
>>> Apr 12 21:34:47 ffffffff810fcea2
>>> Apr 12 21:34:47 0000000000000001
>>> Apr 12 21:34:47 ffff88407fce5e58
>>> Apr 12 21:34:47
>>> Apr 12 21:34:47 [75707.119360] ffff88407fceaf00
>>> Apr 12 21:34:47 ffff88407fceb100
>>> Apr 12 21:34:47 ffff883ff2a20000
>>> Apr 12 21:34:47 ffffffff8101bc63
>>> Apr 12 21:34:47
>>> Apr 12 21:34:47 [75707.119439] Call Trace:
>>> Apr 12 21:34:47 [75707.119471] <NMI>
>>> Apr 12 21:34:47 [<ffffffff812abdf3>] ? dump_stack+0x40/0x5d
>>> Apr 12 21:34:47 [75707.119527] [<ffffffff810cf5f5>] ?
>>> watchdog_overflow_callback+0xb5/0xd0
>>> Apr 12 21:34:47 [75707.119571] [<ffffffff810fcea2>] ?
>>> __perf_event_overflow+0x82/0x1c0
>>> Apr 12 21:34:47 [75707.119614] [<ffffffff8101bc63>] ?
>>> intel_pmu_handle_irq+0x1c3/0x3e0
>>> Apr 12 21:34:47 [75707.119657] [<ffffffff8113b5cb>] ?
>>> vunmap_page_range+0x1bb/0x320
>>> Apr 12 21:34:47 [75707.119703] [<ffffffff813213e0>] ?
>>> ghes_copy_tofrom_phys+0x110/0x1d0
>>> Apr 12 21:34:47 [75707.119758] [<ffffffff81014f53>] ?
>>> perf_event_nmi_handler+0x23/0x40
>>> Apr 12 21:34:47 [75707.119800] [<ffffffff81007b85>] ?
>>> nmi_handle+0x65/0x100
>>> Apr 12 21:34:47 [75707.119838] [<ffffffff81007d2e>] ? do_nmi+0x10e/0x360
>>> Apr 12 21:34:47 [75707.119878] [<ffffffff8148f957>] ?
>>> end_repeat_nmi+0x1a/0x1e
>>> Apr 12 21:34:47 [75707.119920] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:47 [75707.119962] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:47 [75707.120002] [<ffffffff810862ca>] ?
>>> queued_spin_lock_slowpath+0xea/0x150
>>> Apr 12 21:34:47 [75707.120042] <<EOE>>
>>> Apr 12 21:34:47 [<ffffffffa01b413b>] ? make_request+0x60b/0xbd0 [raid456]
>>> Apr 12 21:34:47 [75707.120113] [<ffffffff810815c0>] ? wait_woken+0x80/0x80
>>> Apr 12 21:34:47 [75707.120152] [<ffffffffa017632d>] ?
>>> md_make_request+0xdd/0x220 [md_mod]
>>> Apr 12 21:34:47 [75707.120195] [<ffffffff8128691d>] ?
>>> generic_make_request+0xed/0x1d0
>>> Apr 12 21:34:47 [75707.120236] [<ffffffff81286a5a>] ?
>>> submit_bio+0x5a/0x140
>>> Apr 12 21:34:47 [75707.120277] [<ffffffff8112afaf>] ?
>>> workingset_refault+0x4f/0xa0
>>> Apr 12 21:34:47 [75707.120320] [<ffffffff811a215e>] ?
>>> mpage_bio_submit+0x1e/0x30
>>> Apr 12 21:34:47 [75707.120359] [<ffffffff811a3076>] ?
>>> mpage_readpages+0x106/0x130
>>> Apr 12 21:34:47 [75707.120401] [<ffffffff8121b510>] ?
>>> __xfs_get_blocks+0x750/0x750
>>> Apr 12 21:34:47 [75707.120439] [<ffffffff8121b510>] ?
>>> __xfs_get_blocks+0x750/0x750
>>> Apr 12 21:34:47 [75707.120481] [<ffffffff8114ad45>] ?
>>> alloc_pages_current+0x85/0x110
>>> Apr 12 21:34:47 [75707.120523] [<ffffffff81111d25>] ?
>>> __do_page_cache_readahead+0x165/0x1f0
>>> Apr 12 21:34:47 [75707.120564] [<ffffffff811344f5>] ? vma_link+0x75/0xb0
>>> Apr 12 21:34:47 [75707.120602] [<ffffffff811120c7>] ?
>>> force_page_cache_readahead+0x77/0xe0
>>> Apr 12 21:34:47 [75707.120644] [<ffffffff8113f876>] ?
>>> madvise_willneed+0x76/0x140
>>> Apr 12 21:34:47 [75707.120683] [<ffffffff811301ce>] ?
>>> handle_mm_fault+0x9ae/0x1650
>>> Apr 12 21:34:47 [75707.120722] [<ffffffff81133dcb>] ? find_vma+0x5b/0x70
>>> Apr 12 21:34:47 [75707.120760] [<ffffffff8113fc52>] ?
>>> SyS_madvise+0x312/0x6f0
>>> Apr 12 21:34:47 [75707.120799] [<ffffffff8148d9db>] ?
>>> entry_SYSCALL_64_fastpath+0x16/0x6e
>>>
>>> Once this starts, a couple of minutes goes by and the machine locks up
>>> completely.
>>>
>>> I have been unable to locate the problem here, anyone that can point me in
>>> the right direction?
>>>
>>> Best regards
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Daniel> --
Daniel> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
Daniel> the body of a message to majordomo@vger.kernel.org
Daniel> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] raid6check: Fix if-else indentation
From: Khem Raj @ 2016-04-20 16:41 UTC (permalink / raw)
To: linux-raid; +Cc: Khem Raj
gcc 6 warns about ambiguity due to this indentation
| raid6check.c: In function 'manual_repair':
| raid6check.c:267:4: error: this 'else' clause does not guard... [-Werror=misleading-indentation]
| else
| ^~~~
| raid6check.c:269:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'else'
| printf("Repairing D(%d) and P\n", failed_data);
| ^~~~~~
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
raid6check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/raid6check.c b/raid6check.c
index ad7ffe7..409b1b6 100644
--- a/raid6check.c
+++ b/raid6check.c
@@ -266,7 +266,7 @@ int manual_repair(int chunk_size, int syndrome_disks,
failed_data = failed_slot2;
else
failed_data = failed_slot1;
- printf("Repairing D(%d) and P\n", failed_data);
+ printf("Repairing D(%d) and P\n", failed_data);
raid6_datap_recov(syndrome_disks+2, chunk_size,
failed_data, (uint8_t**)blocks, 1);
} else {
--
1.9.1
^ permalink raw reply related
* [PATCH 00/13] The latest patches for md-cluster
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
For cluster raid1, we found some issues and some codes need to be
improved during the past months, and all the patches are based on
for-next branch of md tree.
The patchset also available in github as follows:
https://github.com/GuoqingJiang/linux/tree/md-for-next
Thanks,
Guoqing
Guoqing Jiang (13):
md-cluster: change resync lock from asynchronous to synchronous
md-cluser: make resync_finish only called after pers->sync_request
md-cluster: wake up thread to continue recovery
md-cluster: unregister thread if err happened
md-cluster: fix locking when node joins cluster during message
broadcast
md-cluster: change array_sectors and update size are not supported
md-cluster: wakeup thread if activated a spare disk
md: set MD_CHANGE_PENDING in a spinlocked region
md-cluster: always setup in-memory bitmap
md-cluster: sync bitmap when node received RESYNCING msg
md-cluster/bitmap: fix wrong calcuation of offset
md-cluster/bitmap: fix wrong page num in bitmap_file_clear_bit and
bitmap_file_set_bit
md-cluster/bitmap: unplug bitmap to sync dirty pages to disk
Documentation/md-cluster.txt | 6 +++
drivers/md/bitmap.c | 108 ++++++++++++++++++++++++++++++++++---------
drivers/md/bitmap.h | 3 ++
drivers/md/md-cluster.c | 53 +++++++++++++++++----
drivers/md/md.c | 80 ++++++++++++++++++++++----------
drivers/md/raid1.c | 2 +
drivers/md/raid10.c | 6 ++-
drivers/md/raid5-cache.c | 2 +
drivers/md/raid5.c | 2 +
9 files changed, 207 insertions(+), 55 deletions(-)
--
2.6.6
^ permalink raw reply
* [PATCH 01/13] md-cluster: change resync lock from asynchronous to synchronous
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
If multiple nodes choose to attempt do resync at the same time
they need to be serialized so they don't duplicate effort. This
serialization is done by locking the 'resync' DLM lock.
Currently if a node cannot get the lock immediately it doesn't
request notification when the lock becomes available (i.e.
DLM_LKF_NOQUEUE is set), so it may not reliably find out when it
is safe to try again.
Rather than trying to arrange an async wake-up when the lock
becomes available, switch to using synchronous locking - this is
a lot easier to think about. As it is not permitted to block in
the 'raid1d' thread, move the locking to the resync thread. So
the rsync thread is forked immediately, but it blocks until the
resync lock is available. Once the lock is locked it checks again
if any resync action is needed.
A particular symptom of the current problem is that a node can
get stuck with "resync=pending" indefinitely.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/md-cluster.c | 2 --
drivers/md/md.c | 22 ++++++++++++++--------
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index dd97d42..12fbfec 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -937,7 +937,6 @@ static void metadata_update_cancel(struct mddev *mddev)
static int resync_start(struct mddev *mddev)
{
struct md_cluster_info *cinfo = mddev->cluster_info;
- cinfo->resync_lockres->flags |= DLM_LKF_NOQUEUE;
return dlm_lock_sync(cinfo->resync_lockres, DLM_LOCK_EX);
}
@@ -967,7 +966,6 @@ static int resync_info_update(struct mddev *mddev, sector_t lo, sector_t hi)
static int resync_finish(struct mddev *mddev)
{
struct md_cluster_info *cinfo = mddev->cluster_info;
- cinfo->resync_lockres->flags &= ~DLM_LKF_NOQUEUE;
dlm_unlock_sync(cinfo->resync_lockres);
return resync_info_update(mddev, 0, 0);
}
diff --git a/drivers/md/md.c b/drivers/md/md.c
index c068f17..113e71c 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -7781,6 +7781,7 @@ void md_do_sync(struct md_thread *thread)
char *desc, *action = NULL;
struct blk_plug plug;
bool cluster_resync_finished = false;
+ int ret;
/* just incase thread restarts... */
if (test_bit(MD_RECOVERY_DONE, &mddev->recovery))
@@ -7790,6 +7791,19 @@ void md_do_sync(struct md_thread *thread)
return;
}
+ if (mddev_is_clustered(mddev)) {
+ ret = md_cluster_ops->resync_start(mddev);
+ if (ret)
+ goto skip;
+
+ if (!(test_bit(MD_RECOVERY_SYNC, &mddev->recovery) ||
+ test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery) ||
+ test_bit(MD_RECOVERY_RECOVER, &mddev->recovery))
+ && ((unsigned long long)mddev->curr_resync_completed
+ < (unsigned long long)mddev->resync_max_sectors))
+ goto skip;
+ }
+
if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) {
if (test_bit(MD_RECOVERY_CHECK, &mddev->recovery)) {
desc = "data-check";
@@ -8221,14 +8235,6 @@ static void md_start_sync(struct work_struct *ws)
struct mddev *mddev = container_of(ws, struct mddev, del_work);
int ret = 0;
- if (mddev_is_clustered(mddev)) {
- ret = md_cluster_ops->resync_start(mddev);
- if (ret) {
- mddev->sync_thread = NULL;
- goto out;
- }
- }
-
mddev->sync_thread = md_register_thread(md_do_sync,
mddev,
"resync");
--
2.6.6
^ permalink raw reply related
* [PATCH 02/13] md-cluser: make resync_finish only called after pers->sync_request
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
It is not reasonable that cluster raid to release resync
lock before the last pers->sync_request has finished.
As the metadata will be changed when node performs resync,
we need to inform other nodes to update metadata, so the
MD_CHANGE_PENDING flag is set before finish resync.
Then metadata_update_finish is move ahead to ensure that
METADATA_UPDATED msg is sent before finish resync, and
metadata_update_start need to be run after "repeat:" label
accordingly.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/md.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 113e71c..0639c01 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2286,6 +2286,7 @@ void md_update_sb(struct mddev *mddev, int force_change)
return;
}
+repeat:
if (mddev_is_clustered(mddev)) {
if (test_and_clear_bit(MD_CHANGE_DEVS, &mddev->flags))
force_change = 1;
@@ -2298,7 +2299,7 @@ void md_update_sb(struct mddev *mddev, int force_change)
return;
}
}
-repeat:
+
/* First make sure individual recovery_offsets are correct */
rdev_for_each(rdev, mddev) {
if (rdev->raid_disk >= 0 &&
@@ -2425,6 +2426,9 @@ repeat:
md_super_wait(mddev);
/* if there was a failure, MD_CHANGE_DEVS was set, and we re-write super */
+ if (mddev_is_clustered(mddev) && ret == 0)
+ md_cluster_ops->metadata_update_finish(mddev);
+
spin_lock(&mddev->lock);
if (mddev->in_sync != sync_req ||
test_bit(MD_CHANGE_DEVS, &mddev->flags)) {
@@ -2447,9 +2451,6 @@ repeat:
clear_bit(BlockedBadBlocks, &rdev->flags);
wake_up(&rdev->blocked_wait);
}
-
- if (mddev_is_clustered(mddev) && ret == 0)
- md_cluster_ops->metadata_update_finish(mddev);
}
EXPORT_SYMBOL(md_update_sb);
@@ -7780,7 +7781,6 @@ void md_do_sync(struct md_thread *thread)
struct md_rdev *rdev;
char *desc, *action = NULL;
struct blk_plug plug;
- bool cluster_resync_finished = false;
int ret;
/* just incase thread restarts... */
@@ -8098,11 +8098,6 @@ void md_do_sync(struct md_thread *thread)
mddev->curr_resync_completed = mddev->curr_resync;
sysfs_notify(&mddev->kobj, NULL, "sync_completed");
}
- /* tell personality and other nodes that we are finished */
- if (mddev_is_clustered(mddev)) {
- md_cluster_ops->resync_finish(mddev);
- cluster_resync_finished = true;
- }
mddev->pers->sync_request(mddev, max_sectors, &skipped);
if (!test_bit(MD_RECOVERY_CHECK, &mddev->recovery) &&
@@ -8142,9 +8137,15 @@ void md_do_sync(struct md_thread *thread)
set_bit(MD_CHANGE_DEVS, &mddev->flags);
if (mddev_is_clustered(mddev) &&
- test_bit(MD_RECOVERY_INTR, &mddev->recovery) &&
- !cluster_resync_finished)
+ ret == 0) {
+ /* set CHANGE_PENDING here since maybe another
+ * update is needed, so other nodes are informed */
+ set_bit(MD_CHANGE_PENDING, &mddev->flags);
+ md_wakeup_thread(mddev->thread);
+ wait_event(mddev->sb_wait,
+ !test_bit(MD_CHANGE_PENDING, &mddev->flags));
md_cluster_ops->resync_finish(mddev);
+ }
spin_lock(&mddev->lock);
if (!test_bit(MD_RECOVERY_INTR, &mddev->recovery)) {
--
2.6.6
^ permalink raw reply related
* [PATCH 03/13] md-cluster: wake up thread to continue recovery
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
In recovery case, we need to set MD_RECOVERY_NEEDED
and wake up thread only if recover is not finished.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/md-cluster.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index 12fbfec..0d4ddf8 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -284,11 +284,14 @@ static void recover_bitmaps(struct md_thread *thread)
goto dlm_unlock;
}
if (hi > 0) {
- /* TODO:Wait for current resync to get over */
- set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
if (lo < mddev->recovery_cp)
mddev->recovery_cp = lo;
- md_check_recovery(mddev);
+ /* wake up thread to continue resync in case resync
+ * is not finished */
+ if (mddev->recovery_cp != MaxSector) {
+ set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
+ md_wakeup_thread(mddev->thread);
+ }
}
dlm_unlock:
dlm_unlock_sync(bm_lockres);
--
2.6.6
^ permalink raw reply related
* [PATCH 04/13] md-cluster: unregister thread if err happened
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
The two threads need to be unregistered if a node
can't join cluster successfully.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/md-cluster.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index 0d4ddf8..76f88f7 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -818,6 +818,8 @@ static int join(struct mddev *mddev, int nodes)
return 0;
err:
+ md_unregister_thread(&cinfo->recovery_thread);
+ md_unregister_thread(&cinfo->recv_thread);
lockres_free(cinfo->message_lockres);
lockres_free(cinfo->token_lockres);
lockres_free(cinfo->ack_lockres);
--
2.6.6
^ permalink raw reply related
* [PATCH 05/13] md-cluster: fix locking when node joins cluster during message broadcast
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
If a node joins the cluster while a message broadcast
is under way, a lock issue could happen as follows.
For a cluster which included two nodes, if node A is
calling __sendmsg before up-convert CR to EX on ack,
and node B released CR on ack. But if a new node C
joins the cluster and it doesn't receive the message
which A sent before, so it could hold CR on ack before
A up-convert CR to EX on ack.
So a node joining the cluster should get an EX lock on
the "token" first to ensure no broadcast is ongoing,
then release it after held CR on ack.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/md-cluster.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index 76f88f7..30f1160 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -781,17 +781,24 @@ static int join(struct mddev *mddev, int nodes)
cinfo->token_lockres = lockres_init(mddev, "token", NULL, 0);
if (!cinfo->token_lockres)
goto err;
- cinfo->ack_lockres = lockres_init(mddev, "ack", ack_bast, 0);
- if (!cinfo->ack_lockres)
- goto err;
cinfo->no_new_dev_lockres = lockres_init(mddev, "no-new-dev", NULL, 0);
if (!cinfo->no_new_dev_lockres)
goto err;
+ ret = dlm_lock_sync(cinfo->token_lockres, DLM_LOCK_EX);
+ if (ret) {
+ ret = -EAGAIN;
+ pr_err("md-cluster: can't join cluster to avoid lock issue\n");
+ goto err;
+ }
+ cinfo->ack_lockres = lockres_init(mddev, "ack", ack_bast, 0);
+ if (!cinfo->ack_lockres)
+ goto err;
/* get sync CR lock on ACK. */
if (dlm_lock_sync(cinfo->ack_lockres, DLM_LOCK_CR))
pr_err("md-cluster: failed to get a sync CR lock on ACK!(%d)\n",
ret);
+ dlm_unlock_sync(cinfo->token_lockres);
/* get sync CR lock on no-new-dev. */
if (dlm_lock_sync(cinfo->no_new_dev_lockres, DLM_LOCK_CR))
pr_err("md-cluster: failed to get a sync CR lock on no-new-dev!(%d)\n", ret);
--
2.6.6
^ permalink raw reply related
* [PATCH 06/13] md-cluster: change array_sectors and update size are not supported
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
Currently, some features are not supported yet,
such as change array_sectors and update size, so
return EINVAL for them and listed it in document.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
Documentation/md-cluster.txt | 6 ++++++
drivers/md/md.c | 8 ++++++++
2 files changed, 14 insertions(+)
diff --git a/Documentation/md-cluster.txt b/Documentation/md-cluster.txt
index c100c71..3888327 100644
--- a/Documentation/md-cluster.txt
+++ b/Documentation/md-cluster.txt
@@ -316,3 +316,9 @@ The algorithm is:
nodes are using the raid which is achieved by lock all bitmap
locks within the cluster, and also those locks are unlocked
accordingly.
+
+7. Unsupported features
+
+There are somethings which are not supported by cluster MD yet.
+
+- update size and change array_sectors.
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 0639c01..1b26397 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4812,6 +4812,10 @@ array_size_store(struct mddev *mddev, const char *buf, size_t len)
if (err)
return err;
+ /* cluster raid doesn't support change array_sectors */
+ if (mddev_is_clustered(mddev))
+ return -EINVAL;
+
if (strncmp(buf, "default", 7) == 0) {
if (mddev->pers)
sectors = mddev->pers->size(mddev, 0, 0);
@@ -6433,6 +6437,10 @@ static int update_size(struct mddev *mddev, sector_t num_sectors)
int rv;
int fit = (num_sectors == 0);
+ /* cluster raid doesn't support update size */
+ if (mddev_is_clustered(mddev))
+ return -EINVAL;
+
if (mddev->pers->resize == NULL)
return -EINVAL;
/* The "num_sectors" is the number of sectors of each device that
--
2.6.6
^ permalink raw reply related
* [PATCH 07/13] md-cluster: wakeup thread if activated a spare disk
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
When a device is re-added, it will ultimately need
to be activated and that happens in md_check_recovery,
so we need to set MD_RECOVERY_NEEDED right after
remove_and_add_spares.
A specifical issue without the change is that when
one node perform fail/remove/readd on a disk, but
slave nodes could not add the disk back to array as
expected (added as missed instead of in sync). So
give slave nodes a chance to do resync.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/md.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 1b26397..dbc7c83 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8690,6 +8690,11 @@ static void check_sb_changes(struct mddev *mddev, struct md_rdev *rdev)
ret = remove_and_add_spares(mddev, rdev2);
pr_info("Activated spare: %s\n",
bdevname(rdev2->bdev,b));
+ /* wakeup mddev->thread here, so array could
+ * perform resync with the new activated disk */
+ set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
+ md_wakeup_thread(mddev->thread);
+
}
/* device faulty
* We just want to do the minimum to mark the disk
--
2.6.6
^ permalink raw reply related
* [PATCH 08/13] md: set MD_CHANGE_PENDING in a spinlocked region
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
Some code waits for a metadata update by:
1. flagging that it is needed (MD_CHANGE_DEVS or MD_CHANGE_CLEAN)
2. setting MD_CHANGE_PENDING and waking the management thread
3. waiting for MD_CHANGE_PENDING to be cleared
If the first two are done without locking, the code in md_update_sb()
which checks if it needs to repeat might test if an update is needed
before step 1, then clear MD_CHANGE_PENDING after step 2, resulting
in the wait returning early.
So make sure all places that set MD_CHANGE_PENDING are protected by
mddev->lock.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/md.c | 22 +++++++++++++++++-----
drivers/md/raid1.c | 2 ++
drivers/md/raid10.c | 6 +++++-
drivers/md/raid5-cache.c | 2 ++
drivers/md/raid5.c | 2 ++
5 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index dbc7c83..80f0e8a 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2290,12 +2290,18 @@ repeat:
if (mddev_is_clustered(mddev)) {
if (test_and_clear_bit(MD_CHANGE_DEVS, &mddev->flags))
force_change = 1;
+ if (test_and_clear_bit(MD_CHANGE_CLEAN, &mddev->flags))
+ nospares = 1;
ret = md_cluster_ops->metadata_update_start(mddev);
/* Has someone else has updated the sb */
if (!does_sb_need_changing(mddev)) {
if (ret == 0)
md_cluster_ops->metadata_update_cancel(mddev);
- clear_bit(MD_CHANGE_PENDING, &mddev->flags);
+ spin_lock(&mddev->write_lock);
+ if (!test_bit(MD_CHANGE_DEVS, &mddev->flags) &&
+ !test_bit(MD_CHANGE_CLEAN, &mddev->flags))
+ clear_bit(MD_CHANGE_PENDING, &mddev->flags);
+ spin_unlock(&mddev->lock);
return;
}
}
@@ -2431,7 +2437,8 @@ repeat:
spin_lock(&mddev->lock);
if (mddev->in_sync != sync_req ||
- test_bit(MD_CHANGE_DEVS, &mddev->flags)) {
+ test_bit(MD_CHANGE_DEVS, &mddev->flags) ||
+ test_bit(MD_CHANGE_CLEAN, &mddev->flags)) {
/* have to write it out again */
spin_unlock(&mddev->lock);
goto repeat;
@@ -8142,18 +8149,20 @@ void md_do_sync(struct md_thread *thread)
}
}
skip:
- set_bit(MD_CHANGE_DEVS, &mddev->flags);
-
if (mddev_is_clustered(mddev) &&
ret == 0) {
/* set CHANGE_PENDING here since maybe another
* update is needed, so other nodes are informed */
+ spin_lock(&mddev->lock);
+ set_bit(MD_CHANGE_DEVS, &mddev->flags);
set_bit(MD_CHANGE_PENDING, &mddev->flags);
+ spin_unlock(&mddev->lock);
md_wakeup_thread(mddev->thread);
wait_event(mddev->sb_wait,
!test_bit(MD_CHANGE_PENDING, &mddev->flags));
md_cluster_ops->resync_finish(mddev);
- }
+ } else
+ set_bit(MD_CHANGE_DEVS, &mddev->flags);
spin_lock(&mddev->lock);
if (!test_bit(MD_RECOVERY_INTR, &mddev->recovery)) {
@@ -8546,6 +8555,7 @@ EXPORT_SYMBOL(md_finish_reshape);
int rdev_set_badblocks(struct md_rdev *rdev, sector_t s, int sectors,
int is_new)
{
+ struct mddev *mddev = rdev->mddev;
int rv;
if (is_new)
s += rdev->new_data_offset;
@@ -8555,8 +8565,10 @@ int rdev_set_badblocks(struct md_rdev *rdev, sector_t s, int sectors,
if (rv == 0) {
/* Make sure they get written out promptly */
sysfs_notify_dirent_safe(rdev->sysfs_state);
+ spin_lock(&mddev->lock);
set_bit(MD_CHANGE_CLEAN, &rdev->mddev->flags);
set_bit(MD_CHANGE_PENDING, &rdev->mddev->flags);
+ spin_unlock(&mddev->lock);
md_wakeup_thread(rdev->mddev->thread);
return 1;
} else
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 39fb21e..cd9e4cc 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1474,8 +1474,10 @@ static void raid1_error(struct mddev *mddev, struct md_rdev *rdev)
* if recovery is running, make sure it aborts.
*/
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
+ spin_lock(&mddev->lock);
set_bit(MD_CHANGE_DEVS, &mddev->flags);
set_bit(MD_CHANGE_PENDING, &mddev->flags);
+ spin_unlock(&mddev->lock);
printk(KERN_ALERT
"md/raid1:%s: Disk failure on %s, disabling device.\n"
"md/raid1:%s: Operation continuing on %d devices.\n",
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e3fd725..98a4cf1 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1102,8 +1102,10 @@ static void __make_request(struct mddev *mddev, struct bio *bio)
bio->bi_iter.bi_sector < conf->reshape_progress))) {
/* Need to update reshape_position in metadata */
mddev->reshape_position = conf->reshape_progress;
+ spin_lock(&mddev->lock);
set_bit(MD_CHANGE_DEVS, &mddev->flags);
set_bit(MD_CHANGE_PENDING, &mddev->flags);
+ spin_unlock(&mddev->lock);
md_wakeup_thread(mddev->thread);
wait_event(mddev->sb_wait,
!test_bit(MD_CHANGE_PENDING, &mddev->flags));
@@ -1585,15 +1587,17 @@ static void raid10_error(struct mddev *mddev, struct md_rdev *rdev)
}
if (test_and_clear_bit(In_sync, &rdev->flags))
mddev->degraded++;
+ spin_unlock_irqrestore(&conf->device_lock, flags);
/*
* If recovery is running, make sure it aborts.
*/
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
set_bit(Blocked, &rdev->flags);
set_bit(Faulty, &rdev->flags);
+ spin_lock(&mddev->lock);
set_bit(MD_CHANGE_DEVS, &mddev->flags);
set_bit(MD_CHANGE_PENDING, &mddev->flags);
- spin_unlock_irqrestore(&conf->device_lock, flags);
+ spin_unlock(&mddev->lock);
printk(KERN_ALERT
"md/raid10:%s: Disk failure on %s, disabling device.\n"
"md/raid10:%s: Operation continuing on %d devices.\n",
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 9531f5f..2ba9366 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -712,8 +712,10 @@ static void r5l_write_super_and_discard_space(struct r5l_log *log,
* in_teardown check workaround this issue.
*/
if (!log->in_teardown) {
+ spin_lock(&mddev->lock);
set_bit(MD_CHANGE_DEVS, &mddev->flags);
set_bit(MD_CHANGE_PENDING, &mddev->flags);
+ spin_unlock(&mddev->lock);
md_wakeup_thread(mddev->thread);
wait_event(mddev->sb_wait,
!test_bit(MD_CHANGE_PENDING, &mddev->flags) ||
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 31ac0f0..a36af8b 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2514,8 +2514,10 @@ static void raid5_error(struct mddev *mddev, struct md_rdev *rdev)
set_bit(Blocked, &rdev->flags);
set_bit(Faulty, &rdev->flags);
+ spin_lock(&mddev->lock);
set_bit(MD_CHANGE_DEVS, &mddev->flags);
set_bit(MD_CHANGE_PENDING, &mddev->flags);
+ spin_unlock(&mddev->lock);
printk(KERN_ALERT
"md/raid:%s: Disk failure on %s, disabling device.\n"
"md/raid:%s: Operation continuing on %d devices.\n",
--
2.6.6
^ permalink raw reply related
* [PATCH 09/13] md-cluster: always setup in-memory bitmap
From: Guoqing Jiang @ 2016-04-21 5:58 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1461218294-4960-1-git-send-email-gqjiang@suse.com>
The in-memory bitmap for raid is allocated on demand,
then for cluster scenario, it is possible that slave
node which received RESYNCING message doesn't have the
in-memory bitmap when master node is perform resyncing,
so we can't make bitmap is match up well among each
nodes.
So for cluster scenario, we need always preserve the
bitmap, and ensure the page will not be freed. And a
no_hijack flag is introduced to both bitmap_checkpage
and bitmap_get_counter, which makes cluster raid returns
fail once allocate failed.
And the next patch is relied on this change since it
keeps sync bitmap among each nodes during resyncing
stage.
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/bitmap.c | 59 +++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 46 insertions(+), 13 deletions(-)
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index 7df6b4f..00cf1c1 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -46,7 +46,7 @@ static inline char *bmname(struct bitmap *bitmap)
* allocated while we're using it
*/
static int bitmap_checkpage(struct bitmap_counts *bitmap,
- unsigned long page, int create)
+ unsigned long page, int create, int no_hijack)
__releases(bitmap->lock)
__acquires(bitmap->lock)
{
@@ -90,6 +90,9 @@ __acquires(bitmap->lock)
if (mappage == NULL) {
pr_debug("md/bitmap: map page allocation failed, hijacking\n");
+ /* We don't support hijack for cluster raid */
+ if (no_hijack)
+ return -ENOMEM;
/* failed - set the hijacked flag so that we can use the
* pointer as a counter */
if (!bitmap->bp[page].map)
@@ -1177,7 +1180,7 @@ static void bitmap_set_pending(struct bitmap_counts *bitmap, sector_t offset)
static bitmap_counter_t *bitmap_get_counter(struct bitmap_counts *bitmap,
sector_t offset, sector_t *blocks,
- int create);
+ int create, int no_hijack);
/*
* bitmap daemon -- periodically wakes up to clean bits and flush pages
@@ -1257,7 +1260,7 @@ void bitmap_daemon_work(struct mddev *mddev)
}
bmc = bitmap_get_counter(counts,
block,
- &blocks, 0);
+ &blocks, 0, 0);
if (!bmc) {
j |= PAGE_COUNTER_MASK;
@@ -1307,7 +1310,7 @@ void bitmap_daemon_work(struct mddev *mddev)
static bitmap_counter_t *bitmap_get_counter(struct bitmap_counts *bitmap,
sector_t offset, sector_t *blocks,
- int create)
+ int create, int no_hijack)
__releases(bitmap->lock)
__acquires(bitmap->lock)
{
@@ -1321,7 +1324,7 @@ __acquires(bitmap->lock)
sector_t csize;
int err;
- err = bitmap_checkpage(bitmap, page, create);
+ err = bitmap_checkpage(bitmap, page, create, 0);
if (bitmap->bp[page].hijacked ||
bitmap->bp[page].map == NULL)
@@ -1368,7 +1371,7 @@ int bitmap_startwrite(struct bitmap *bitmap, sector_t offset, unsigned long sect
bitmap_counter_t *bmc;
spin_lock_irq(&bitmap->counts.lock);
- bmc = bitmap_get_counter(&bitmap->counts, offset, &blocks, 1);
+ bmc = bitmap_get_counter(&bitmap->counts, offset, &blocks, 1, 0);
if (!bmc) {
spin_unlock_irq(&bitmap->counts.lock);
return 0;
@@ -1430,7 +1433,7 @@ void bitmap_endwrite(struct bitmap *bitmap, sector_t offset, unsigned long secto
bitmap_counter_t *bmc;
spin_lock_irqsave(&bitmap->counts.lock, flags);
- bmc = bitmap_get_counter(&bitmap->counts, offset, &blocks, 0);
+ bmc = bitmap_get_counter(&bitmap->counts, offset, &blocks, 0, 0);
if (!bmc) {
spin_unlock_irqrestore(&bitmap->counts.lock, flags);
return;
@@ -1474,7 +1477,7 @@ static int __bitmap_start_sync(struct bitmap *bitmap, sector_t offset, sector_t
return 1; /* always resync if no bitmap */
}
spin_lock_irq(&bitmap->counts.lock);
- bmc = bitmap_get_counter(&bitmap->counts, offset, blocks, 0);
+ bmc = bitmap_get_counter(&bitmap->counts, offset, blocks, 0, 0);
rv = 0;
if (bmc) {
/* locked */
@@ -1526,7 +1529,7 @@ void bitmap_end_sync(struct bitmap *bitmap, sector_t offset, sector_t *blocks, i
return;
}
spin_lock_irqsave(&bitmap->counts.lock, flags);
- bmc = bitmap_get_counter(&bitmap->counts, offset, blocks, 0);
+ bmc = bitmap_get_counter(&bitmap->counts, offset, blocks, 0, 0);
if (bmc == NULL)
goto unlock;
/* locked */
@@ -1604,7 +1607,7 @@ static void bitmap_set_memory_bits(struct bitmap *bitmap, sector_t offset, int n
sector_t secs;
bitmap_counter_t *bmc;
spin_lock_irq(&bitmap->counts.lock);
- bmc = bitmap_get_counter(&bitmap->counts, offset, &secs, 1);
+ bmc = bitmap_get_counter(&bitmap->counts, offset, &secs, 1, 0);
if (!bmc) {
spin_unlock_irq(&bitmap->counts.lock);
return;
@@ -2029,17 +2032,47 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks,
chunks << chunkshift);
spin_lock_irq(&bitmap->counts.lock);
+ /* For cluster raid, need to pre-allocate bitmap */
+ if (mddev_is_clustered(bitmap->mddev)) {
+ unsigned long page;
+ for (page = 0; page < pages; page++) {
+ ret = bitmap_checkpage(&bitmap->counts, page, 1, 1);
+ if (ret) {
+ unsigned long k;
+
+ /* deallocate the page memory */
+ for (k = 0; k < page; k++) {
+ if (new_bp[k].map)
+ kfree(new_bp[k].map);
+ }
+
+ /* restore some fields from old_counts */
+ bitmap->counts.bp = old_counts.bp;
+ bitmap->counts.pages = old_counts.pages;
+ bitmap->counts.missing_pages = old_counts.pages;
+ bitmap->counts.chunkshift = old_counts.chunkshift;
+ bitmap->counts.chunks = old_counts.chunks;
+ bitmap->mddev->bitmap_info.chunksize = 1 << (old_counts.chunkshift +
+ BITMAP_BLOCK_SHIFT);
+ blocks = old_counts.chunks << old_counts.chunkshift;
+ pr_err("Could not pre-allocate in-memory bitmap for cluster raid\n");
+ break;
+ } else
+ bitmap->counts.bp[page].count += 1;
+ }
+ }
+
for (block = 0; block < blocks; ) {
bitmap_counter_t *bmc_old, *bmc_new;
int set;
bmc_old = bitmap_get_counter(&old_counts, block,
- &old_blocks, 0);
+ &old_blocks, 0, 0);
set = bmc_old && NEEDED(*bmc_old);
if (set) {
bmc_new = bitmap_get_counter(&bitmap->counts, block,
- &new_blocks, 1);
+ &new_blocks, 1, 0);
if (*bmc_new == 0) {
/* need to set on-disk bits too. */
sector_t end = block + new_blocks;
@@ -2067,7 +2100,7 @@ int bitmap_resize(struct bitmap *bitmap, sector_t blocks,
while (block < (chunks << chunkshift)) {
bitmap_counter_t *bmc;
bmc = bitmap_get_counter(&bitmap->counts, block,
- &new_blocks, 1);
+ &new_blocks, 1, 0);
if (bmc) {
/* new space. It needs to be resynced, so
* we set NEEDED_MASK.
--
2.6.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox