December 2019 - Linux-stable-mirror

FAILED: patch "[PATCH] PM / devfreq: Lock devfreq in trans_stat_show" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2abb0d5268ae7b5ddf82099b1f8d5aa8414637d4 Mon Sep 17 00:00:00 2001 From: Leonard Crestez <leonard.crestez(a)nxp.com> Date: Tue, 24 Sep 2019 10:52:23 +0300 Subject: [PATCH] PM / devfreq: Lock devfreq in trans_stat_show There is no locking in this sysfs show function so stats printing can race with a devfreq_update_status called as part of freq switching or with initialization. Also add an assert in devfreq_update_status to make it clear that lock must be held by caller. Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats") Cc: stable(a)vger.kernel.org Signed-off-by: Leonard Crestez <leonard.crestez(a)nxp.com> Reviewed-by: Matthias Kaehlcke <mka(a)chromium.org> Reviewed-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 60859a2400bc..d6c3dce9e9d5 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -160,6 +160,7 @@ int devfreq_update_status(struct devfreq *devfreq, unsigned long freq) int lev, prev_lev, ret = 0; unsigned long cur_time; + lockdep_assert_held(&devfreq->lock); cur_time = jiffies; /* Immediately exit if previous_freq is not initialized yet. */ @@ -1397,12 +1398,17 @@ static ssize_t trans_stat_show(struct device *dev, int i, j; unsigned int max_state = devfreq->profile->max_state; - if (!devfreq->stop_polling && - devfreq_update_status(devfreq, devfreq->previous_freq)) - return 0; if (max_state == 0) return sprintf(buf, "Not Supported.\n"); + mutex_lock(&devfreq->lock); + if (!devfreq->stop_polling && + devfreq_update_status(devfreq, devfreq->previous_freq)) { + mutex_unlock(&devfreq->lock); + return 0; + } + mutex_unlock(&devfreq->lock); + len = sprintf(buf, " From : To\n"); len += sprintf(buf + len, " :"); for (i = 0; i < max_state; i++)

4 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] perf scripts python: exported-sql-viewer.py: Fix use of TRUE" failed to apply to 5.3-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.3-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From af833988c088d3fed3e7188e7c3dd9ca17178dc3 Mon Sep 17 00:00:00 2001 From: Adrian Hunter <adrian.hunter(a)intel.com> Date: Wed, 13 Nov 2019 14:02:06 +0200 Subject: [PATCH] perf scripts python: exported-sql-viewer.py: Fix use of TRUE with SQLite Prior to version 3.23 SQLite does not support TRUE or FALSE, so always use 1 and 0 for SQLite. Fixes: 26c11206f433 ("perf scripts python: exported-sql-viewer.py: Use new 'has_calls' column") Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: stable(a)vger.kernel.org # v5.3+ Link: http://lore.kernel.org/lkml/20191113120206.26957-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> diff --git a/tools/perf/scripts/python/exported-sql-viewer.py b/tools/perf/scripts/python/exported-sql-viewer.py index ebc6a2e5eae9..26d7be785288 100755 --- a/tools/perf/scripts/python/exported-sql-viewer.py +++ b/tools/perf/scripts/python/exported-sql-viewer.py @@ -637,7 +637,7 @@ class CallGraphRootItem(CallGraphLevelItemBase): self.query_done = True if_has_calls = "" if IsSelectable(glb.db, "comms", columns = "has_calls"): - if_has_calls = " WHERE has_calls = TRUE" + if_has_calls = " WHERE has_calls = " + glb.dbref.TRUE query = QSqlQuery(glb.db) QueryExec(query, "SELECT id, comm FROM comms" + if_has_calls) while query.next(): @@ -918,7 +918,7 @@ class CallTreeRootItem(CallGraphLevelItemBase): self.query_done = True if_has_calls = "" if IsSelectable(glb.db, "comms", columns = "has_calls"): - if_has_calls = " WHERE has_calls = TRUE" + if_has_calls = " WHERE has_calls = " + glb.dbref.TRUE query = QSqlQuery(glb.db) QueryExec(query, "SELECT id, comm FROM comms" + if_has_calls) while query.next(): @@ -1290,7 +1290,7 @@ class SwitchGraphData(GraphData): QueryExec(query, "SELECT id, c_time" " FROM comms" " WHERE c_thread_id = " + str(thread_id) + - " AND exec_flag = TRUE" + " AND exec_flag = " + self.collection.glb.dbref.TRUE + " AND c_time >= " + str(start_time) + " AND c_time <= " + str(end_time) + " ORDER BY c_time, id") @@ -5016,6 +5016,12 @@ class DBRef(): def __init__(self, is_sqlite3, dbname): self.is_sqlite3 = is_sqlite3 self.dbname = dbname + self.TRUE = "TRUE" + self.FALSE = "FALSE" + # SQLite prior to version 3.23 does not support TRUE and FALSE + if self.is_sqlite3: + self.TRUE = "1" + self.FALSE = "0" def Open(self, connection_name): dbname = self.dbname

4 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] perf scripts python: exported-sql-viewer.py: Fix use of TRUE" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From af833988c088d3fed3e7188e7c3dd9ca17178dc3 Mon Sep 17 00:00:00 2001 From: Adrian Hunter <adrian.hunter(a)intel.com> Date: Wed, 13 Nov 2019 14:02:06 +0200 Subject: [PATCH] perf scripts python: exported-sql-viewer.py: Fix use of TRUE with SQLite Prior to version 3.23 SQLite does not support TRUE or FALSE, so always use 1 and 0 for SQLite. Fixes: 26c11206f433 ("perf scripts python: exported-sql-viewer.py: Use new 'has_calls' column") Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: stable(a)vger.kernel.org # v5.3+ Link: http://lore.kernel.org/lkml/20191113120206.26957-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> diff --git a/tools/perf/scripts/python/exported-sql-viewer.py b/tools/perf/scripts/python/exported-sql-viewer.py index ebc6a2e5eae9..26d7be785288 100755 --- a/tools/perf/scripts/python/exported-sql-viewer.py +++ b/tools/perf/scripts/python/exported-sql-viewer.py @@ -637,7 +637,7 @@ class CallGraphRootItem(CallGraphLevelItemBase): self.query_done = True if_has_calls = "" if IsSelectable(glb.db, "comms", columns = "has_calls"): - if_has_calls = " WHERE has_calls = TRUE" + if_has_calls = " WHERE has_calls = " + glb.dbref.TRUE query = QSqlQuery(glb.db) QueryExec(query, "SELECT id, comm FROM comms" + if_has_calls) while query.next(): @@ -918,7 +918,7 @@ class CallTreeRootItem(CallGraphLevelItemBase): self.query_done = True if_has_calls = "" if IsSelectable(glb.db, "comms", columns = "has_calls"): - if_has_calls = " WHERE has_calls = TRUE" + if_has_calls = " WHERE has_calls = " + glb.dbref.TRUE query = QSqlQuery(glb.db) QueryExec(query, "SELECT id, comm FROM comms" + if_has_calls) while query.next(): @@ -1290,7 +1290,7 @@ class SwitchGraphData(GraphData): QueryExec(query, "SELECT id, c_time" " FROM comms" " WHERE c_thread_id = " + str(thread_id) + - " AND exec_flag = TRUE" + " AND exec_flag = " + self.collection.glb.dbref.TRUE + " AND c_time >= " + str(start_time) + " AND c_time <= " + str(end_time) + " ORDER BY c_time, id") @@ -5016,6 +5016,12 @@ class DBRef(): def __init__(self, is_sqlite3, dbname): self.is_sqlite3 = is_sqlite3 self.dbname = dbname + self.TRUE = "TRUE" + self.FALSE = "FALSE" + # SQLite prior to version 3.23 does not support TRUE and FALSE + if self.is_sqlite3: + self.TRUE = "1" + self.FALSE = "0" def Open(self, connection_name): dbname = self.dbname

4 years, 10 months

1
0
0 0

Re: [PATCH] ARM: dts: omap3-tao3530: Fix incorrect MMC card detection GPIO polarity

by Jarkko Nikula

On 11/25/19 1:11 PM, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: 3a637e008e54 ("ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards"). > > The bot has tested the following trees: v5.3.12, v4.19.85, v4.14.155, v4.9.202, v4.4.202. > > v5.3.12: Build OK! > v4.19.85: Build OK! > v4.14.155: Build OK! > v4.9.202: Failed to apply! Possible dependencies: > 1a177cf72b3a ("ARM: dts: dra72-evm-tps65917: Add voltage supplies to usb_phy, mmc, dss") > 45ea75eb92a4 ("ARM: dts: omap*: Replace deprecated "vmmc_aux" with "vqmmc"") > 5d080aa30681 ("ARM: dts: dra72: Add separate dtsi for tps65917") > 6eebfeb9cf0d ("ARM: dts: Add support for dra718-evm") > e9a05fbd21de ("ARM: dts: dra72-evm: Fix modelling of regulators") > > v4.4.202: Failed to apply! Possible dependencies: > 12ca468306a2 ("ARM: dts: am57xx: cl-som-am57x: add dual EMAC support") > 1a472e14ba08 ("ARM: dts: am57xx: cl-som-am57x: dts: add RTC support") > 27ddd846cb25 ("ARM: dts: am57xx: cl-som-am57x: add USB support") > 2c7cf1f48f36 ("ARM: dts: am57xx: cl-som-am57x: add EEPROM support") > 2d47fc3b9801 ("ARM: dts: am57xx: cl-som-am57x: add touchscreen support") > 317d15679a5e ("ARM: dts: dra72-evm: Mark uart1 rxd as wakeup capable") > 387450fc882e ("ARM: dts: am57xx: cl-som-am57x: add basic module support") > 3a1de8082405 ("ARM: dts: dra7xx: Fix compatible string for PCF8575 chip") > 4424cd009648 ("ARM: dts: am57xx: cl-som-am57x: add analog audio support") > 45ea75eb92a4 ("ARM: dts: omap*: Replace deprecated "vmmc_aux" with "vqmmc"") > 488f270d90e1 ("ARM: dts: dra7: Fix NAND device nodes") > 4e8603eff519 ("ARM: dts: omap: remove unneeded unit name for sound nodes") > 6686f744df70 ("ARM: dts: DRA72-EVM: Add regulator-allow-bypass property for ldo1 and ldo2") > 6cfec12f2545 ("ARM: dts: dra72-evm: Enable AFIFO use for McASP3") > 6eebfeb9cf0d ("ARM: dts: Add support for dra718-evm") > 8deb60f535fa ("ARM: dts: am57xx: cl-som-am57x: add eMMC support") > 9255ea8472d2 ("ARM: dts: dra72-evm: Use DRA7XX_CORE_IOPAD pinmux macro") > a23fc1558487 ("ARM: dts: dra7x-evm: Provide NAND ready pin") > a4240d3af677 ("ARM: dts: Add support for dra72-evm rev C (SR2.0)") > a7cac713f90a ("ARM: dts: AM572x-IDK Initial Support") > cc2d681420d0 ("ARM: dts: am57xx: cl-som-am57x: add spi-flash support") > e1fdd060f08d ("ARM: dts: am57xx: sbc-am57x: add basic board support") > e9a05fbd21de ("ARM: dts: dra72-evm: Fix modelling of regulators") > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? > Ah, it doesn't apply to v4.4 and v4.9 due the commit 45ea75eb92a4 ("ARM: dts: omap*: Replace deprecated "vmmc_aux" with "vqmmc"") but that commit doesn't apply either stable and probably even should not even if it would. I believe best is me to submit a separate version for v4.4/v4.9. -- Jarkko

4 years, 10 months

1
1
0 0

FAILED: patch "[PATCH] Btrfs: send, skip backreference walking for extents with many" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From fd0ddbe2509568b00df364156f47561e9f469f15 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Wed, 30 Oct 2019 12:23:01 +0000 Subject: [PATCH] Btrfs: send, skip backreference walking for extents with many references Backreference walking, which is used by send to figure if it can issue clone operations instead of write operations, can be very slow and use too much memory when extents have many references. This change simply skips backreference walking when an extent has more than 64 references, in which case we fallback to a write operation instead of a clone operation. This limit is conservative and in practice I observed no signicant slowdown with up to 100 references and still low memory usage up to that limit. This is a temporary workaround until there are speedups in the backref walking code, and as such it does not attempt to add extra interfaces or knobs to tweak the threshold. Reported-by: Atemu <atemu.main(a)gmail.com> Link: https://lore.kernel.org/linux-btrfs/CAE4GHgkvqVADtS4AzcQJxo0Q1jKQgKaW3JGp3S… CC: stable(a)vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index cbf4909f5cd9..ae2db5eb1549 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -24,6 +24,14 @@ #include "transaction.h" #include "compression.h" +/* + * Maximum number of references an extent can have in order for us to attempt to + * issue clone operations instead of write operations. This currently exists to + * avoid hitting limitations of the backreference walking code (taking a lot of + * time and using too much memory for extents with large number of references). + */ +#define SEND_MAX_EXTENT_REFS 64 + /* * A fs_path is a helper to dynamically build path names with unknown size. * It reallocates the internal buffer on demand. @@ -1310,6 +1318,7 @@ static int find_extent_clone(struct send_ctx *sctx, struct clone_root *cur_clone_root; struct btrfs_key found_key; struct btrfs_path *tmp_path; + struct btrfs_extent_item *ei; int compressed; u32 i; @@ -1357,7 +1366,6 @@ static int find_extent_clone(struct send_ctx *sctx, ret = extent_from_logical(fs_info, disk_byte, tmp_path, &found_key, &flags); up_read(&fs_info->commit_root_sem); - btrfs_release_path(tmp_path); if (ret < 0) goto out; @@ -1366,6 +1374,21 @@ static int find_extent_clone(struct send_ctx *sctx, goto out; } + ei = btrfs_item_ptr(tmp_path->nodes[0], tmp_path->slots[0], + struct btrfs_extent_item); + /* + * Backreference walking (iterate_extent_inodes() below) is currently + * too expensive when an extent has a large number of references, both + * in time spent and used memory. So for now just fallback to write + * operations instead of clone operations when an extent has more than + * a certain amount of references. + */ + if (btrfs_extent_refs(tmp_path->nodes[0], ei) > SEND_MAX_EXTENT_REFS) { + ret = -ENOENT; + goto out; + } + btrfs_release_path(tmp_path); + /* * Setup the clone roots. */

4 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] Btrfs: fix negative subv_writers counter and data space leak" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a0e248bb502d5165b3314ac3819e888fdcdf7d9f Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Fri, 11 Oct 2019 16:41:20 +0100 Subject: [PATCH] Btrfs: fix negative subv_writers counter and data space leak after buffered write When doing a buffered write it's possible to leave the subv_writers counter of the root, used for synchronization between buffered nocow writers and snapshotting. This happens in an exceptional case like the following: 1) We fail to allocate data space for the write, since there's not enough available data space nor enough unallocated space for allocating a new data block group; 2) Because of that failure, we try to go to NOCOW mode, which succeeds and therefore we set the local variable 'only_release_metadata' to true and set the root's sub_writers counter to 1 through the call to btrfs_start_write_no_snapshotting() made by check_can_nocow(); 3) The call to btrfs_copy_from_user() returns zero, which is very unlikely to happen but not impossible; 4) No pages are copied because btrfs_copy_from_user() returned zero; 5) We call btrfs_end_write_no_snapshotting() which decrements the root's subv_writers counter to 0; 6) We don't set 'only_release_metadata' back to 'false' because we do it only if 'copied', the value returned by btrfs_copy_from_user(), is greater than zero; 7) On the next iteration of the while loop, which processes the same page range, we are now able to allocate data space for the write (we got enough data space released in the meanwhile); 8) After this if we fail at btrfs_delalloc_reserve_metadata(), because now there isn't enough free metadata space, or in some other place further below (prepare_pages(), lock_and_cleanup_extent_if_need(), btrfs_dirty_pages()), we break out of the while loop with 'only_release_metadata' having a value of 'true'; 9) Because 'only_release_metadata' is 'true' we end up decrementing the root's subv_writers counter to -1 (through a call to btrfs_end_write_no_snapshotting()), and we also end up not releasing the data space previously reserved through btrfs_check_data_free_space(). As a consequence the mechanism for synchronizing NOCOW buffered writes with snapshotting gets broken. Fix this by always setting 'only_release_metadata' to false at the start of each iteration. Fixes: 8257b2dc3c1a ("Btrfs: introduce btrfs_{start, end}_nocow_write() for each subvolume") Fixes: 7ee9e4405f26 ("Btrfs: check if we can nocow if we don't have data space") CC: stable(a)vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index f9434fa3e387..91c98a6d1408 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1636,6 +1636,7 @@ static noinline ssize_t btrfs_buffered_write(struct kiocb *iocb, break; } + only_release_metadata = false; sector_offset = pos & (fs_info->sectorsize - 1); reserve_bytes = round_up(write_bytes + sector_offset, fs_info->sectorsize); @@ -1791,7 +1792,6 @@ static noinline ssize_t btrfs_buffered_write(struct kiocb *iocb, set_extent_bit(&BTRFS_I(inode)->io_tree, lockstart, lockend, EXTENT_NORESERVE, NULL, NULL, GFP_NOFS); - only_release_metadata = false; } btrfs_drop_pages(pages, num_pages);

4 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a60adce85f4bb5c1ef8ffcebadd702cafa2f3696 Mon Sep 17 00:00:00 2001 From: Josef Bacik <josef(a)toxicpanda.com> Date: Tue, 24 Sep 2019 16:50:44 -0400 Subject: [PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group When free'ing extents in a block group we check to see if the block group is not cached, and then cache it if we need to. However we'll just carry on as long as we're loading the cache. This is problematic because we are dirtying the block group here. If we are fast enough we could do a transaction commit and clear the free space cache while we're still loading the space cache in another thread. This truncates the free space inode, which will keep it from loading the space cache. Fix this by using the btrfs_block_group_cache_done helper so that we try to load the space cache unconditionally here, which will result in the caller waiting for the fast caching to complete and keep us from truncating the free space inode. CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> Reviewed-by: Nikolay Borisov <nborisov(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 384659dc7818..540a7a63601e 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -2661,7 +2661,7 @@ int btrfs_update_block_group(struct btrfs_trans_handle *trans, * is because we need the unpinning stage to actually add the * space back to the block group, otherwise we will leak space. */ - if (!alloc && cache->cached == BTRFS_CACHE_NO) + if (!alloc && !btrfs_block_group_cache_done(cache)) btrfs_cache_block_group(cache, 1); byte_in_group = bytenr - cache->key.objectid;

4 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a60adce85f4bb5c1ef8ffcebadd702cafa2f3696 Mon Sep 17 00:00:00 2001 From: Josef Bacik <josef(a)toxicpanda.com> Date: Tue, 24 Sep 2019 16:50:44 -0400 Subject: [PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group When free'ing extents in a block group we check to see if the block group is not cached, and then cache it if we need to. However we'll just carry on as long as we're loading the cache. This is problematic because we are dirtying the block group here. If we are fast enough we could do a transaction commit and clear the free space cache while we're still loading the space cache in another thread. This truncates the free space inode, which will keep it from loading the space cache. Fix this by using the btrfs_block_group_cache_done helper so that we try to load the space cache unconditionally here, which will result in the caller waiting for the fast caching to complete and keep us from truncating the free space inode. CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> Reviewed-by: Nikolay Borisov <nborisov(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 384659dc7818..540a7a63601e 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -2661,7 +2661,7 @@ int btrfs_update_block_group(struct btrfs_trans_handle *trans, * is because we need the unpinning stage to actually add the * space back to the block group, otherwise we will leak space. */ - if (!alloc && cache->cached == BTRFS_CACHE_NO) + if (!alloc && !btrfs_block_group_cache_done(cache)) btrfs_cache_block_group(cache, 1); byte_in_group = bytenr - cache->key.objectid;

4 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a60adce85f4bb5c1ef8ffcebadd702cafa2f3696 Mon Sep 17 00:00:00 2001 From: Josef Bacik <josef(a)toxicpanda.com> Date: Tue, 24 Sep 2019 16:50:44 -0400 Subject: [PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group When free'ing extents in a block group we check to see if the block group is not cached, and then cache it if we need to. However we'll just carry on as long as we're loading the cache. This is problematic because we are dirtying the block group here. If we are fast enough we could do a transaction commit and clear the free space cache while we're still loading the space cache in another thread. This truncates the free space inode, which will keep it from loading the space cache. Fix this by using the btrfs_block_group_cache_done helper so that we try to load the space cache unconditionally here, which will result in the caller waiting for the fast caching to complete and keep us from truncating the free space inode. CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> Reviewed-by: Nikolay Borisov <nborisov(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 384659dc7818..540a7a63601e 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -2661,7 +2661,7 @@ int btrfs_update_block_group(struct btrfs_trans_handle *trans, * is because we need the unpinning stage to actually add the * space back to the block group, otherwise we will leak space. */ - if (!alloc && cache->cached == BTRFS_CACHE_NO) + if (!alloc && !btrfs_block_group_cache_done(cache)) btrfs_cache_block_group(cache, 1); byte_in_group = bytenr - cache->key.objectid;

4 years, 10 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a60adce85f4bb5c1ef8ffcebadd702cafa2f3696 Mon Sep 17 00:00:00 2001 From: Josef Bacik <josef(a)toxicpanda.com> Date: Tue, 24 Sep 2019 16:50:44 -0400 Subject: [PATCH] btrfs: use btrfs_block_group_cache_done in update_block_group When free'ing extents in a block group we check to see if the block group is not cached, and then cache it if we need to. However we'll just carry on as long as we're loading the cache. This is problematic because we are dirtying the block group here. If we are fast enough we could do a transaction commit and clear the free space cache while we're still loading the space cache in another thread. This truncates the free space inode, which will keep it from loading the space cache. Fix this by using the btrfs_block_group_cache_done helper so that we try to load the space cache unconditionally here, which will result in the caller waiting for the fast caching to complete and keep us from truncating the free space inode. CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> Reviewed-by: Nikolay Borisov <nborisov(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 384659dc7818..540a7a63601e 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -2661,7 +2661,7 @@ int btrfs_update_block_group(struct btrfs_trans_handle *trans, * is because we need the unpinning stage to actually add the * space back to the block group, otherwise we will leak space. */ - if (!alloc && cache->cached == BTRFS_CACHE_NO) + if (!alloc && !btrfs_block_group_cache_done(cache)) btrfs_cache_block_group(cache, 1); byte_in_group = bytenr - cache->key.objectid;

4 years, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2019