+dkrahn

That's interesting.  Darren, you may want to take a quick look at the log, there is a large amount of TPM commands and I am not sure why they would be needed.

Activating. Please assign to the right owner and the appropriate priority.

Curt, this one might suit as a starter bug

I tried again with R60, different stack, but lock up nonetheless.
Note xfstests code is still not submitted.

Deleted: screen-exchange 50.4 KB

screen-exchange 50.4 KB View Download

Gwendal do you think this is a suitable starter bug? If so, are you happy to act as mentor/reviewer?

I'm working on fixing these anyway as part of  crbug.com/766786  -- so I can do this too.

I put up a series to fix this and generic/405 here:

https://chromium-review.googlesource.com/#/c/chromiumos/third_party/kernel/+/696554

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e1bfdbbc72b5d42cd60fdf734f62c3dc847c11e2

commit e1bfdbbc72b5d42cd60fdf734f62c3dc847c11e2
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:06 2017

UPSTREAM: dm thin: allow metadata commit if pool is in PM_OUT_OF_DATA_SPACE mode

commit 8d07e8a5f5bc7b90f755d9b427ea930024f4c986 upstream.

Commit 3e1a0699 ("dm thin: fix out of data space handling") introduced
a regression in the metadata commit() method by returning an error if
the pool is in PM_OUT_OF_DATA_SPACE mode.  This oversight caused a thin
device to return errors even if the default queue_if_no_space ENOSPC
handling mode is used.

Fix commit() to only fail if pool is in PM_READ_ONLY or PM_FAIL mode.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: Ie87f731cd841262abff45c6789268bed1be4a942
Reported-by: qindehua@163.com
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 36f7757dadcd from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699862
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/e1bfdbbc72b5d42cd60fdf734f62c3dc847c11e2/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7f14fc33dbf3f1e4681af4832b2ceed24abf4f3d

commit 7f14fc33dbf3f1e4681af4832b2ceed24abf4f3d
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:07 2017

UPSTREAM: dm thin: add timeout to stop out-of-data-space mode holding IO forever

commit 85ad643b7e7e52d37620fb272a9fd577a8095647 upstream.

If the pool runs out of data space, dm-thin can be configured to
either error IOs that would trigger provisioning, or hold those IOs
until the pool is resized.  Unfortunately, holding IOs until the pool is
resized can result in a cascade of tasks hitting the hung_task_timeout,
which may render the system unavailable.

Add a fixed timeout so IOs can only be held for a maximum of 60 seconds.
If LVM is going to resize a thin-pool that is out of data space it needs
to be prompt about it.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: I8906631dbc28eaad50e1e37782b9165cb018b8c3
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 6a1170d67327 from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699863
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/7f14fc33dbf3f1e4681af4832b2ceed24abf4f3d/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fe3f0ebd2c82bd883e77b224a72b10dbb8691d6f

commit fe3f0ebd2c82bd883e77b224a72b10dbb8691d6f
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Oct 17 23:44:09 2017

UPSTREAM: dm thin: add 'no_space_timeout' dm-thin-pool module param

commit 80c578930ce77ba8bcfb226a184b482020bdda7b upstream.

Commit 85ad643b ("dm thin: add timeout to stop out-of-data-space mode
holding IO forever") introduced a fixed 60 second timeout.  Users may
want to either disable or modify this timeout.

Allow the out-of-data-space timeout to be configured using the
'no_space_timeout' dm-thin-pool module param.  Setting it to 0 will
disable the timeout, resulting in IO being queued until more data space
is added to the thin-pool.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: I44a65131cffc18b8ece590f2eb701d1e499398ec
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 2936b8269a85 in 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699864
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/fe3f0ebd2c82bd883e77b224a72b10dbb8691d6f/drivers/md/dm-thin.c
[modify] https://crrev.com/fe3f0ebd2c82bd883e77b224a72b10dbb8691d6f/Documentation/device-mapper/thin-provisioning.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/752d3a02a3739f76898fb0a6e8842ca0ff9df942

commit 752d3a02a3739f76898fb0a6e8842ca0ff9df942
Author: Lukas Czerner <lczerner@redhat.com>
Date: Tue Oct 17 23:44:10 2017

UPSTREAM: dm thin: update discard_granularity to reflect the thin-pool blocksize

commit 09869de57ed2728ae3c619803932a86cb0e2c4f8 upstream.

DM thinp already checks whether the discard_granularity of the data
device is a factor of the thin-pool block size.  But when using the
dm-thin-pool's discard passdown support, DM thinp was not selecting the
max of the underlying data device's discard_granularity and the
thin-pool's block size.

Update set_discard_limits() to set discard_granularity to the max of
these values.  This enables blkdev_issue_discard() to properly align the
discards that are sent to the DM thin device on a full block boundary.
As such each discard will now cover an entire DM thin-pool block and the
block will be reclaimed.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: Ia1b0f709dd010632c33146c52be498ddfca2a982
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from dd7ba80f4a39 from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699865
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/752d3a02a3739f76898fb0a6e8842ca0ff9df942/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/abd9b4fd82c3ca7f1cc5a643683b9a7eabb2d72e

commit abd9b4fd82c3ca7f1cc5a643683b9a7eabb2d72e
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Oct 17 23:44:11 2017

UPSTREAM: dm thin metadata: do not allow the data block size to change

commit 9aec8629ec829fc9403788cd959e05dd87988bd1 upstream.

The block size for the thin-pool's data device must remained fixed for
the life of the thin-pool.  Disallow any attempt to change the
thin-pool's data block size.

It should be noted that attempting to change the data block size via
thin-pool table reload will be ignored as a side-effect of the thin-pool
handover that the thin-pool target does during thin-pool table reload.

Here is an example outcome of attempting to load a thin-pool table that
reduced the thin-pool's data block size from 1024K to 512K.

Before:
kernel: device-mapper: thin: 253:4: growing the data device from 204800 to 409600 blocks

After:
kernel: device-mapper: thin metadata: changing the data block size (from 2048 to 1024) is not supported
kernel: device-mapper: table: 253:4: thin-pool: Error creating metadata object
kernel: device-mapper: ioctl: error adding target to table

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: Ief7ee791a9763eaad9399e5f1f0a172515ce81bb
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 60d97c8d656f from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699866
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/abd9b4fd82c3ca7f1cc5a643683b9a7eabb2d72e/drivers/md/dm-thin-metadata.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3943ee70d7e3d855c6e2d5382e0b92e47b3d5bc5

commit 3943ee70d7e3d855c6e2d5382e0b92e47b3d5bc5
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:12 2017

UPSTREAM: dm thin: grab a virtual cell before looking up the mapping

commit c822ed967cba38505713d59ed40a114386ef6c01 upstream.

Avoids normal IO racing with discard.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: Id6c568267371846c730825e279dbf96bde9198a6
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 5f64b0f2cbb9 from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699867
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/3943ee70d7e3d855c6e2d5382e0b92e47b3d5bc5/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cc10af6b2767ed27665bbf7636f04c0c96d4c95f

commit cc10af6b2767ed27665bbf7636f04c0c96d4c95f
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:13 2017

UPSTREAM: dm thin: fix inability to discard blocks when in out-of-data-space mode

commit 45ec9bd0fd7abf8705e7cf12205ff69fe9d51181 upstream.

When the pool was in PM_OUT_OF_SPACE mode its process_prepared_discard
function pointer was incorrectly being set to
process_prepared_discard_passdown rather than process_prepared_discard.

This incorrect function pointer meant the discard was being passed down,
but not effecting the mapping.  As such any discard that was issued, in
an attempt to reclaim blocks, would not successfully free data space.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: I1297f4e8c32a57c83cb273234ad17bf871db3dd7
Reported-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 3b2caa87bacb from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699868
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/cc10af6b2767ed27665bbf7636f04c0c96d4c95f/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4aa04c619bd680cce561436af408ea37d70c1647

commit 4aa04c619bd680cce561436af408ea37d70c1647
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:15 2017

UPSTREAM: dm thin: fix missing out-of-data-space to write mode transition if blocks are released

commit 2c43fd26e46734430122b8d2ad3024bb532df3ef upstream.

Discard bios and thin device deletion have the potential to release data
blocks.  If the thin-pool is in out-of-data-space mode, and blocks were
released, transition the thin-pool back to full write mode.

The correct time to do this is just after the thin-pool metadata commit.
It cannot be done before the commit because the space maps will not
allow immediate reuse of the data blocks in case there's a rollback
following power failure.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: I1f46167ceebe673b2a1a3f7bfa74d5f552c1c962
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 1b210c873eba from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699869
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/4aa04c619bd680cce561436af408ea37d70c1647/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/408d814828111e72a58b224b4389de2d81ec38e6

commit 408d814828111e72a58b224b4389de2d81ec38e6
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:16 2017

UPSTREAM: dm thin: don't allow messages to be sent to a pool target in READ_ONLY or FAIL mode

commit 2a7eaea02b99b6e267b1e89c79acc6e9a51cee3b upstream.

You can't modify the metadata in these modes.  It's better to fail these
messages immediately than let the block-manager deny write locks on
metadata blocks.  Otherwise these failed metadata changes will trigger
'needs_check' to get set in the metadata superblock -- requiring repair
using the thin_check utility.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: I9c9f112bac671a5faf7cc5a54ccccf9eb93a12ee
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from e6f2661f9e1b from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699870
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/408d814828111e72a58b224b4389de2d81ec38e6/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/efe9f9bafb5f149891047328c6713c553dbb2886

commit efe9f9bafb5f149891047328c6713c553dbb2886
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:17 2017

UPSTREAM: dm thin metadata: delete btrees when releasing metadata snapshot

commit 7f518ad0a212e2a6fd68630e176af1de395070a7 upstream.

The device details and mapping trees were just being decremented
before.  Now btree_del() is called to do a deep delete.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: I4390ffd085f59f4a3f4a81ca3377380ef97b4aac
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from e7a778e90f8b from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699871
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/efe9f9bafb5f149891047328c6713c553dbb2886/drivers/md/dm-thin-metadata.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ae5aced368606af005fb8a633655cb69798884ec

commit ae5aced368606af005fb8a633655cb69798884ec
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Oct 17 23:44:18 2017

UPSTREAM: dm thin: fix missing pool reference count decrement in pool_ctr error path

commit ba30670f4d5292c4e7f7980bbd5071f7c4794cdd upstream.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: Id7549ed5d2a2f2b5e8479b8b35aecc91983fd0de
Fixes: ac8c3f3df ("dm thin: generate event when metadata threshold passed")
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 9e7042c2fffc in 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699872
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/ae5aced368606af005fb8a633655cb69798884ec/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f2bf143d30cbe1d346f6ffde98c89b56142cc088

commit f2bf143d30cbe1d346f6ffde98c89b56142cc088
Author: Mike Snitzer <snitzer@redhat.com>
Date: Tue Oct 17 23:44:19 2017

UPSTREAM: dm thin: restore requested 'error_if_no_space' setting on OODS to WRITE transition

commit 172c238612ebf81cabccc86b788c9209af591f61 upstream.

A thin-pool that is in out-of-data-space (OODS) mode may transition back
to write mode -- without the admin adding more space to the thin-pool --
if/when blocks are released (either by deleting thin devices or
discarding provisioned blocks).

But as part of the thin-pool's earlier transition to out-of-data-space
mode the thin-pool may have set the 'error_if_no_space' flag to true if
the no_space_timeout expires without more space having been made
available.  That implementation detail, of changing the pool's
error_if_no_space setting, needs to be reset back to the default that
the user specified when the thin-pool's table was loaded.

Otherwise we'll drop the user requested behaviour on the floor when this
out-of-data-space to write mode transition occurs.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: I428f2f14738698f7671c548460db0d306114da6b
Reported-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Fixes: 2c43fd26e4 ("dm thin: fix missing out-of-data-space to write mode transition if blocks are released")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 613c515dc046 from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699873
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/f2bf143d30cbe1d346f6ffde98c89b56142cc088/drivers/md/dm-thin.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2fd123c46bf02fcbb008715450a575d2b9bff979

commit 2fd123c46bf02fcbb008715450a575d2b9bff979
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Oct 17 23:44:21 2017

UPSTREAM: dm thin metadata: fix bug when taking a metadata snapshot

commit 49e99fc717f624aa75ca755d6e7bc029efd3f0e9 upstream.

When you take a metadata snapshot the btree roots for the mapping and
details tree need to have their reference counts incremented so they
persist for the lifetime of the metadata snap.

The roots being incremented were those currently written in the
superblock, which could possibly be out of date if concurrent IO is
triggering new mappings, breaking of sharing, etc.

Fix this by performing a commit with the metadata lock held while taking
a metadata snapshot.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: I1ff6f5145bfb19b4ccf36d2f3c38faa51916647d
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from eb44c5a6ff5b from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/700314
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/2fd123c46bf02fcbb008715450a575d2b9bff979/drivers/md/dm-thin-metadata.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/185809b7de8123b3411cc19e6ca83818f625f9d5

commit 185809b7de8123b3411cc19e6ca83818f625f9d5
Author: Nikolay Borisov <kernel@kyup.com>
Date: Tue Oct 17 23:44:22 2017

UPSTREAM: dm thin: fix race condition when destroying thin pool workqueue

commit 18d03e8c25f173f4107a40d0b8c24defb6ed69f3 upstream.

When a thin pool is being destroyed delayed work items are
cancelled using cancel_delayed_work(), which doesn't guarantee that on
return the delayed item isn't running.  This can cause the work item to
requeue itself on an already destroyed workqueue.  Fix this by using
cancel_delayed_work_sync() which guarantees that on return the work item
is not running anymore.

BUG= chromium:616822 
TEST=build/boot on samus, xfstest generic/347 passes

Change-Id: Iec84136ef8dfe0ebdc39c84d22db11510f16d6df
Fixes: 905e51b39a555 ("dm thin: commit outstanding data every second")
Fixes: 85ad643b7e7e5 ("dm thin: add timeout to stop out-of-data-space mode holding IO forever")
Signed-off-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from 5e297a6a053e from 3.14-stable)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/700315
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/185809b7de8123b3411cc19e6ca83818f625f9d5/drivers/md/dm-thin.c