August 2019 - Linux-stable-mirror

FAILED: patch "[PATCH] eeprom: at24: make spd world-readable again" 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 25e5ef302c24a6fead369c0cfe88c073d7b97ca8 Mon Sep 17 00:00:00 2001 From: Jean Delvare <jdelvare(a)suse.de> Date: Sun, 28 Jul 2019 18:41:38 +0200 Subject: [PATCH] eeprom: at24: make spd world-readable again The integration of the at24 driver into the nvmem framework broke the world-readability of spd EEPROMs. Fix it. Signed-off-by: Jean Delvare <jdelvare(a)suse.de> Cc: stable(a)vger.kernel.org Fixes: 57d155506dd5 ("eeprom: at24: extend driver to plug into the NVMEM framework") Cc: Andrew Lunn <andrew(a)lunn.ch> Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Bartosz Golaszewski <brgl(a)bgdev.pl> Cc: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c index 35bf2477693d..518945b2f737 100644 --- a/drivers/misc/eeprom/at24.c +++ b/drivers/misc/eeprom/at24.c @@ -685,7 +685,7 @@ static int at24_probe(struct i2c_client *client) nvmem_config.name = dev_name(dev); nvmem_config.dev = dev; nvmem_config.read_only = !writable; - nvmem_config.root_only = true; + nvmem_config.root_only = !(flags & AT24_FLAG_IRUGO); nvmem_config.owner = THIS_MODULE; nvmem_config.compat = true; nvmem_config.base_dev = dev;

5 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] eeprom: at24: make spd world-readable again" 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 25e5ef302c24a6fead369c0cfe88c073d7b97ca8 Mon Sep 17 00:00:00 2001 From: Jean Delvare <jdelvare(a)suse.de> Date: Sun, 28 Jul 2019 18:41:38 +0200 Subject: [PATCH] eeprom: at24: make spd world-readable again The integration of the at24 driver into the nvmem framework broke the world-readability of spd EEPROMs. Fix it. Signed-off-by: Jean Delvare <jdelvare(a)suse.de> Cc: stable(a)vger.kernel.org Fixes: 57d155506dd5 ("eeprom: at24: extend driver to plug into the NVMEM framework") Cc: Andrew Lunn <andrew(a)lunn.ch> Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Bartosz Golaszewski <brgl(a)bgdev.pl> Cc: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c index 35bf2477693d..518945b2f737 100644 --- a/drivers/misc/eeprom/at24.c +++ b/drivers/misc/eeprom/at24.c @@ -685,7 +685,7 @@ static int at24_probe(struct i2c_client *client) nvmem_config.name = dev_name(dev); nvmem_config.dev = dev; nvmem_config.read_only = !writable; - nvmem_config.root_only = true; + nvmem_config.root_only = !(flags & AT24_FLAG_IRUGO); nvmem_config.owner = THIS_MODULE; nvmem_config.compat = true; nvmem_config.base_dev = dev;

5 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] gpiolib: Preserve desc->flags when setting state" 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 d95da993383c78f7efd25957ba3af23af4b1c613 Mon Sep 17 00:00:00 2001 From: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Date: Mon, 8 Jul 2019 08:35:58 +1200 Subject: [PATCH] gpiolib: Preserve desc->flags when setting state desc->flags may already have values set by of_gpiochip_add() so make sure that this isn't undone when setting the initial direction. Cc: stable(a)vger.kernel.org Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning") Signed-off-by: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20190707203558.10993-1-chris.packham@alliedtelesi… Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index bf05c29b53be..f497003f119c 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1394,12 +1394,17 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data, for (i = 0; i < chip->ngpio; i++) { struct gpio_desc *desc = &gdev->descs[i]; - if (chip->get_direction && gpiochip_line_is_valid(chip, i)) - desc->flags = !chip->get_direction(chip, i) ? - (1 << FLAG_IS_OUT) : 0; - else - desc->flags = !chip->direction_input ? - (1 << FLAG_IS_OUT) : 0; + if (chip->get_direction && gpiochip_line_is_valid(chip, i)) { + if (!chip->get_direction(chip, i)) + set_bit(FLAG_IS_OUT, &desc->flags); + else + clear_bit(FLAG_IS_OUT, &desc->flags); + } else { + if (!chip->direction_input) + set_bit(FLAG_IS_OUT, &desc->flags); + else + clear_bit(FLAG_IS_OUT, &desc->flags); + } } acpi_gpiochip_add(chip);

5 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] gpiolib: Preserve desc->flags when setting state" 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 d95da993383c78f7efd25957ba3af23af4b1c613 Mon Sep 17 00:00:00 2001 From: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Date: Mon, 8 Jul 2019 08:35:58 +1200 Subject: [PATCH] gpiolib: Preserve desc->flags when setting state desc->flags may already have values set by of_gpiochip_add() so make sure that this isn't undone when setting the initial direction. Cc: stable(a)vger.kernel.org Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning") Signed-off-by: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20190707203558.10993-1-chris.packham@alliedtelesi… Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index bf05c29b53be..f497003f119c 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1394,12 +1394,17 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data, for (i = 0; i < chip->ngpio; i++) { struct gpio_desc *desc = &gdev->descs[i]; - if (chip->get_direction && gpiochip_line_is_valid(chip, i)) - desc->flags = !chip->get_direction(chip, i) ? - (1 << FLAG_IS_OUT) : 0; - else - desc->flags = !chip->direction_input ? - (1 << FLAG_IS_OUT) : 0; + if (chip->get_direction && gpiochip_line_is_valid(chip, i)) { + if (!chip->get_direction(chip, i)) + set_bit(FLAG_IS_OUT, &desc->flags); + else + clear_bit(FLAG_IS_OUT, &desc->flags); + } else { + if (!chip->direction_input) + set_bit(FLAG_IS_OUT, &desc->flags); + else + clear_bit(FLAG_IS_OUT, &desc->flags); + } } acpi_gpiochip_add(chip);

5 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] Btrfs: fix race leading to fs corruption after transaction" 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 cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 25 Jul 2019 11:27:04 +0100 Subject: [PATCH] Btrfs: fix race leading to fs corruption after transaction abort When one transaction is finishing its commit, it is possible for another transaction to start and enter its initial commit phase as well. If the first ends up getting aborted, we have a small time window where the second transaction commit does not notice that the previous transaction aborted and ends up committing, writing a superblock that points to btrees that reference extent buffers (nodes and leafs) that were not persisted to disk. The consequence is that after mounting the filesystem again, we will be unable to load some btree nodes/leafs, either because the content on disk is either garbage (or just zeroes) or corresponds to the old content of a previouly COWed or deleted node/leaf, resulting in the well known error messages "parent transid verify failed on ...". The following sequence diagram illustrates how this can happen. CPU 1 CPU 2 <at transaction N> btrfs_commit_transaction() (...) --> sets transaction state to TRANS_STATE_UNBLOCKED --> sets fs_info->running_transaction to NULL (...) btrfs_start_transaction() start_transaction() wait_current_trans() --> returns immediately because fs_info->running_transaction is NULL join_transaction() --> creates transaction N + 1 --> sets fs_info->running_transaction to transaction N + 1 --> adds transaction N + 1 to the fs_info->trans_list list --> returns transaction handle pointing to the new transaction N + 1 (...) btrfs_sync_file() btrfs_start_transaction() --> returns handle to transaction N + 1 (...) btrfs_write_and_wait_transaction() --> writeback of some extent buffer fails, returns an error btrfs_handle_fs_error() --> sets BTRFS_FS_STATE_ERROR in fs_info->fs_state --> jumps to label "scrub_continue" cleanup_transaction() btrfs_abort_transaction(N) --> sets BTRFS_FS_STATE_TRANS_ABORTED flag in fs_info->fs_state --> sets aborted field in the transaction and transaction handle structures, for transaction N only --> removes transaction from the list fs_info->trans_list btrfs_commit_transaction(N + 1) --> transaction N + 1 was not aborted, so it proceeds (...) --> sets the transaction's state to TRANS_STATE_COMMIT_START --> does not find the previous transaction (N) in the fs_info->trans_list, so it doesn't know that transaction was aborted, and the commit of transaction N + 1 proceeds (...) --> sets transaction N + 1 state to TRANS_STATE_UNBLOCKED btrfs_write_and_wait_transaction() --> succeeds writing all extent buffers created in the transaction N + 1 write_all_supers() --> succeeds --> we now have a superblock on disk that points to trees that refer to at least one extent buffer that was never persisted So fix this by updating the transaction commit path to check if the flag BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting the transaction to the TRANS_STATE_COMMIT_START we do not find any previous transaction in the fs_info->trans_list. If the flag is set, just fail the transaction commit with -EROFS, as we do in other places. The exact error code for the previous transaction abort was already logged and reported. Fixes: 49b25e0540904b ("btrfs: enhance transaction abort infrastructure") 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/transaction.c b/fs/btrfs/transaction.c index 3b8ae1a8f02d..39b7bcde3c6f 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2037,6 +2037,16 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) } } else { spin_unlock(&fs_info->trans_lock); + /* + * The previous transaction was aborted and was already removed + * from the list of transactions at fs_info->trans_list. So we + * abort to prevent writing a new superblock that reflects a + * corrupt state (pointing to trees with unwritten nodes/leafs). + */ + if (test_bit(BTRFS_FS_STATE_TRANS_ABORTED, &fs_info->fs_state)) { + ret = -EROFS; + goto cleanup_transaction; + } } extwriter_counter_dec(cur_trans, trans->type);

5 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] Btrfs: fix race leading to fs corruption after transaction" 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 cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 25 Jul 2019 11:27:04 +0100 Subject: [PATCH] Btrfs: fix race leading to fs corruption after transaction abort When one transaction is finishing its commit, it is possible for another transaction to start and enter its initial commit phase as well. If the first ends up getting aborted, we have a small time window where the second transaction commit does not notice that the previous transaction aborted and ends up committing, writing a superblock that points to btrees that reference extent buffers (nodes and leafs) that were not persisted to disk. The consequence is that after mounting the filesystem again, we will be unable to load some btree nodes/leafs, either because the content on disk is either garbage (or just zeroes) or corresponds to the old content of a previouly COWed or deleted node/leaf, resulting in the well known error messages "parent transid verify failed on ...". The following sequence diagram illustrates how this can happen. CPU 1 CPU 2 <at transaction N> btrfs_commit_transaction() (...) --> sets transaction state to TRANS_STATE_UNBLOCKED --> sets fs_info->running_transaction to NULL (...) btrfs_start_transaction() start_transaction() wait_current_trans() --> returns immediately because fs_info->running_transaction is NULL join_transaction() --> creates transaction N + 1 --> sets fs_info->running_transaction to transaction N + 1 --> adds transaction N + 1 to the fs_info->trans_list list --> returns transaction handle pointing to the new transaction N + 1 (...) btrfs_sync_file() btrfs_start_transaction() --> returns handle to transaction N + 1 (...) btrfs_write_and_wait_transaction() --> writeback of some extent buffer fails, returns an error btrfs_handle_fs_error() --> sets BTRFS_FS_STATE_ERROR in fs_info->fs_state --> jumps to label "scrub_continue" cleanup_transaction() btrfs_abort_transaction(N) --> sets BTRFS_FS_STATE_TRANS_ABORTED flag in fs_info->fs_state --> sets aborted field in the transaction and transaction handle structures, for transaction N only --> removes transaction from the list fs_info->trans_list btrfs_commit_transaction(N + 1) --> transaction N + 1 was not aborted, so it proceeds (...) --> sets the transaction's state to TRANS_STATE_COMMIT_START --> does not find the previous transaction (N) in the fs_info->trans_list, so it doesn't know that transaction was aborted, and the commit of transaction N + 1 proceeds (...) --> sets transaction N + 1 state to TRANS_STATE_UNBLOCKED btrfs_write_and_wait_transaction() --> succeeds writing all extent buffers created in the transaction N + 1 write_all_supers() --> succeeds --> we now have a superblock on disk that points to trees that refer to at least one extent buffer that was never persisted So fix this by updating the transaction commit path to check if the flag BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting the transaction to the TRANS_STATE_COMMIT_START we do not find any previous transaction in the fs_info->trans_list. If the flag is set, just fail the transaction commit with -EROFS, as we do in other places. The exact error code for the previous transaction abort was already logged and reported. Fixes: 49b25e0540904b ("btrfs: enhance transaction abort infrastructure") 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/transaction.c b/fs/btrfs/transaction.c index 3b8ae1a8f02d..39b7bcde3c6f 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2037,6 +2037,16 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) } } else { spin_unlock(&fs_info->trans_lock); + /* + * The previous transaction was aborted and was already removed + * from the list of transactions at fs_info->trans_list. So we + * abort to prevent writing a new superblock that reflects a + * corrupt state (pointing to trees with unwritten nodes/leafs). + */ + if (test_bit(BTRFS_FS_STATE_TRANS_ABORTED, &fs_info->fs_state)) { + ret = -EROFS; + goto cleanup_transaction; + } } extwriter_counter_dec(cur_trans, trans->type);

5 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] Btrfs: fix incremental send failure after deduplication" 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 b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Wed, 17 Jul 2019 13:23:39 +0100 Subject: [PATCH] Btrfs: fix incremental send failure after deduplication When doing an incremental send operation we can fail if we previously did deduplication operations against a file that exists in both snapshots. In that case we will fail the send operation with -EIO and print a message to dmesg/syslog like the following: BTRFS error (device sdc): Send: inconsistent snapshot, found updated \ extent for inode 257 without updated inode item, send root is 258, \ parent root is 257 This requires that we deduplicate to the same file in both snapshots for the same amount of times on each snapshot. The issue happens because a deduplication only updates the iversion of an inode and does not update any other field of the inode, therefore if we deduplicate the file on each snapshot for the same amount of time, the inode will have the same iversion value (stored as the "sequence" field on the inode item) on both snapshots, therefore it will be seen as unchanged between in the send snapshot while there are new/updated/deleted extent items when comparing to the parent snapshot. This makes the send operation return -EIO and print an error message. Example reproducer: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt # Create our first file. The first half of the file has several 64Kb # extents while the second half as a single 512Kb extent. $ xfs_io -f -s -c "pwrite -S 0xb8 -b 64K 0 512K" /mnt/foo $ xfs_io -c "pwrite -S 0xb8 512K 512K" /mnt/foo # Create the base snapshot and the parent send stream from it. $ btrfs subvolume snapshot -r /mnt /mnt/mysnap1 $ btrfs send -f /tmp/1.snap /mnt/mysnap1 # Create our second file, that has exactly the same data as the first # file. $ xfs_io -f -c "pwrite -S 0xb8 0 1M" /mnt/bar # Create the second snapshot, used for the incremental send, before # doing the file deduplication. $ btrfs subvolume snapshot -r /mnt /mnt/mysnap2 # Now before creating the incremental send stream: # # 1) Deduplicate into a subrange of file foo in snapshot mysnap1. This # will drop several extent items and add a new one, also updating # the inode's iversion (sequence field in inode item) by 1, but not # any other field of the inode; # # 2) Deduplicate into a different subrange of file foo in snapshot # mysnap2. This will replace an extent item with a new one, also # updating the inode's iversion by 1 but not any other field of the # inode. # # After these two deduplication operations, the inode items, for file # foo, are identical in both snapshots, but we have different extent # items for this inode in both snapshots. We want to check this doesn't # cause send to fail with an error or produce an incorrect stream. $ xfs_io -r -c "dedupe /mnt/bar 0 0 512K" /mnt/mysnap1/foo $ xfs_io -r -c "dedupe /mnt/bar 512K 512K 512K" /mnt/mysnap2/foo # Create the incremental send stream. $ btrfs send -p /mnt/mysnap1 -f /tmp/2.snap /mnt/mysnap2 ERROR: send ioctl failed with -5: Input/output error This issue started happening back in 2015 when deduplication was updated to not update the inode's ctime and mtime and update only the iversion. Back then we would hit a BUG_ON() in send, but later in 2016 send was updated to return -EIO and print the error message instead of doing the BUG_ON(). A test case for fstests follows soon. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203933 Fixes: 1c919a5e13702c ("btrfs: don't update mtime/ctime on deduped inodes") CC: stable(a)vger.kernel.org # 4.4+ 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 69b59bf75882..c3c0c064c25d 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -6322,68 +6322,21 @@ static int changed_extent(struct send_ctx *sctx, { int ret = 0; - if (sctx->cur_ino != sctx->cmp_key->objectid) { - - if (result == BTRFS_COMPARE_TREE_CHANGED) { - struct extent_buffer *leaf_l; - struct extent_buffer *leaf_r; - struct btrfs_file_extent_item *ei_l; - struct btrfs_file_extent_item *ei_r; - - leaf_l = sctx->left_path->nodes[0]; - leaf_r = sctx->right_path->nodes[0]; - ei_l = btrfs_item_ptr(leaf_l, - sctx->left_path->slots[0], - struct btrfs_file_extent_item); - ei_r = btrfs_item_ptr(leaf_r, - sctx->right_path->slots[0], - struct btrfs_file_extent_item); - - /* - * We may have found an extent item that has changed - * only its disk_bytenr field and the corresponding - * inode item was not updated. This case happens due to - * very specific timings during relocation when a leaf - * that contains file extent items is COWed while - * relocation is ongoing and its in the stage where it - * updates data pointers. So when this happens we can - * safely ignore it since we know it's the same extent, - * but just at different logical and physical locations - * (when an extent is fully replaced with a new one, we - * know the generation number must have changed too, - * since snapshot creation implies committing the current - * transaction, and the inode item must have been updated - * as well). - * This replacement of the disk_bytenr happens at - * relocation.c:replace_file_extents() through - * relocation.c:btrfs_reloc_cow_block(). - */ - if (btrfs_file_extent_generation(leaf_l, ei_l) == - btrfs_file_extent_generation(leaf_r, ei_r) && - btrfs_file_extent_ram_bytes(leaf_l, ei_l) == - btrfs_file_extent_ram_bytes(leaf_r, ei_r) && - btrfs_file_extent_compression(leaf_l, ei_l) == - btrfs_file_extent_compression(leaf_r, ei_r) && - btrfs_file_extent_encryption(leaf_l, ei_l) == - btrfs_file_extent_encryption(leaf_r, ei_r) && - btrfs_file_extent_other_encoding(leaf_l, ei_l) == - btrfs_file_extent_other_encoding(leaf_r, ei_r) && - btrfs_file_extent_type(leaf_l, ei_l) == - btrfs_file_extent_type(leaf_r, ei_r) && - btrfs_file_extent_disk_bytenr(leaf_l, ei_l) != - btrfs_file_extent_disk_bytenr(leaf_r, ei_r) && - btrfs_file_extent_disk_num_bytes(leaf_l, ei_l) == - btrfs_file_extent_disk_num_bytes(leaf_r, ei_r) && - btrfs_file_extent_offset(leaf_l, ei_l) == - btrfs_file_extent_offset(leaf_r, ei_r) && - btrfs_file_extent_num_bytes(leaf_l, ei_l) == - btrfs_file_extent_num_bytes(leaf_r, ei_r)) - return 0; - } - - inconsistent_snapshot_error(sctx, result, "extent"); - return -EIO; - } + /* + * We have found an extent item that changed without the inode item + * having changed. This can happen either after relocation (where the + * disk_bytenr of an extent item is replaced at + * relocation.c:replace_file_extents()) or after deduplication into a + * file in both the parent and send snapshots (where an extent item can + * get modified or replaced with a new one). Note that deduplication + * updates the inode item, but it only changes the iversion (sequence + * field in the inode item) of the inode, so if a file is deduplicated + * the same amount of times in both the parent and send snapshots, its + * iversion becames the same in both snapshots, whence the inode item is + * the same on both snapshots. + */ + if (sctx->cur_ino != sctx->cmp_key->objectid) + return 0; if (!sctx->cur_inode_new_gen && !sctx->cur_inode_deleted) { if (result != BTRFS_COMPARE_TREE_DELETED)

5 years, 4 months

1
0
0 0

[PATCH 4.19.x] kconfig: Clear "written" flag to avoid data loss

by Masahiro Yamada

From: "M. Vefa Bicakci" <m.v.b(a)runbox.com> commit 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce upstream. Prior to this commit, starting nconfig, xconfig or gconfig, and saving the .config file more than once caused data loss, where a .config file that contained only comments would be written to disk starting from the second save operation. This bug manifests itself because the SYMBOL_WRITTEN flag is never cleared after the first call to conf_write, and subsequent calls to conf_write then skip all of the configuration symbols due to the SYMBOL_WRITTEN flag being set. This commit resolves this issue by clearing the SYMBOL_WRITTEN flag from all symbols before conf_write returns. Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf") Cc: linux-stable <stable(a)vger.kernel.org> # 4.19+ Signed-off-by: M. Vefa Bicakci <m.v.b(a)runbox.com> Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- scripts/kconfig/confdata.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index fd99ae90a618..0dde19cf7486 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -784,6 +784,7 @@ int conf_write(const char *name) const char *str; char dirname[PATH_MAX+1], tmpname[PATH_MAX+22], newname[PATH_MAX+8]; char *env; + int i; dirname[0] = 0; if (name && name[0]) { @@ -860,6 +861,9 @@ int conf_write(const char *name) } fclose(out); + for_all_symbols(i, sym) + sym->flags &= ~SYMBOL_WRITTEN; + if (*tmpname) { strcat(dirname, basename); strcat(dirname, ".old"); -- 2.17.1

5 years, 4 months

2
1
0 0

[PATCH 4.19 00/32] 4.19.64-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.64 release. There are 32 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.64-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.19.64-rc1 Bart Van Assche <bvanassche(a)acm.org> scsi: core: Avoid that a kernel warning appears during system resume Bart Van Assche <bvanassche(a)acm.org> block, scsi: Change the preempt-only flag into a counter Yan, Zheng <zyan(a)redhat.com> ceph: hold i_ceph_lock when removing caps for freeing inode Yoshinori Sato <ysato(a)users.sourceforge.jp> Fix allyesconfig output. Miroslav Lichvar <mlichvar(a)redhat.com> drivers/pps/pps.c: clear offset flags in PPS_SETPARAMS ioctl Linus Torvalds <torvalds(a)linux-foundation.org> /proc/<pid>/cmdline: add back the setproctitle() special case Linus Torvalds <torvalds(a)linux-foundation.org> /proc/<pid>/cmdline: remove all the special cases Jann Horn <jannh(a)google.com> sched/fair: Use RCU accessors consistently for ->numa_group Jann Horn <jannh(a)google.com> sched/fair: Don't free p->numa_faults with concurrent readers Jason Wang <jasowang(a)redhat.com> vhost: scsi: add weight support Jason Wang <jasowang(a)redhat.com> vhost: vsock: add weight support Jason Wang <jasowang(a)redhat.com> vhost_net: fix possible infinite loop Jason Wang <jasowang(a)redhat.com> vhost: introduce vhost_exceeds_weight() Vladis Dronov <vdronov(a)redhat.com> Bluetooth: hci_uart: check for missing tty operations Joerg Roedel <jroedel(a)suse.de> iommu/iova: Fix compilation error with !CONFIG_IOMMU_IOVA Dmitry Safonov <dima(a)arista.com> iommu/vt-d: Don't queue_iova() if there is no flush queue Luke Nowakowski-Krijger <lnowakow(a)eng.ucsd.edu> media: radio-raremono: change devm_k*alloc to k*alloc Benjamin Coddington <bcodding(a)redhat.com> NFS: Cleanup if nfs_match_client is interrupted Andrey Konovalov <andreyknvl(a)google.com> media: pvrusb2: use a different format for warnings Oliver Neukum <oneukum(a)suse.com> media: cpia2_usb: first wake up, then free in disconnect Fabio Estevam <festevam(a)gmail.com> ath10k: Change the warning message string Sean Young <sean(a)mess.org> media: au0828: fix null dereference in error path Phong Tran <tranmanphong(a)gmail.com> ISDN: hfcsusb: checking idx of ep configuration Todd Kjos <tkjos(a)android.com> binder: fix possible UAF when freeing buffer Will Deacon <will.deacon(a)arm.com> arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ Minas Harutyunyan <minas.harutyunyan(a)synopsys.com> usb: dwc2: Fix disable all EP's on disconnect Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com> usb: dwc2: Disable all EP's on disconnect Trond Myklebust <trond.myklebust(a)hammerspace.com> NFSv4: Fix lookup revalidate of regular files Trond Myklebust <trond.myklebust(a)hammerspace.com> NFS: Refactor nfs_lookup_revalidate() Trond Myklebust <trond.myklebust(a)hammerspace.com> NFS: Fix dentry revalidation on NFSv4 lookup Sunil Muthuswamy <sunilmut(a)microsoft.com> vsock: correct removal of socket from the list Sunil Muthuswamy <sunilmut(a)microsoft.com> hv_sock: Add support for delayed close ------------- Diffstat: Makefile | 4 +- arch/arm64/include/asm/compat.h | 1 + arch/sh/boards/Kconfig | 14 +- block/blk-core.c | 35 ++-- block/blk-mq-debugfs.c | 10 +- drivers/android/binder.c | 16 +- drivers/bluetooth/hci_ath.c | 3 + drivers/bluetooth/hci_bcm.c | 3 + drivers/bluetooth/hci_intel.c | 3 + drivers/bluetooth/hci_ldisc.c | 13 ++ drivers/bluetooth/hci_mrvl.c | 3 + drivers/bluetooth/hci_qca.c | 3 + drivers/bluetooth/hci_uart.h | 1 + drivers/iommu/intel-iommu.c | 2 +- drivers/iommu/iova.c | 18 +- drivers/isdn/hardware/mISDN/hfcsusb.c | 3 + drivers/media/radio/radio-raremono.c | 30 ++- drivers/media/usb/au0828/au0828-core.c | 12 +- drivers/media/usb/cpia2/cpia2_usb.c | 3 +- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 4 +- drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c | 6 +- drivers/media/usb/pvrusb2/pvrusb2-std.c | 2 +- drivers/net/wireless/ath/ath10k/usb.c | 2 +- drivers/pps/pps.c | 8 + drivers/scsi/scsi_lib.c | 15 +- drivers/usb/dwc2/gadget.c | 41 +++- drivers/vhost/net.c | 41 ++-- drivers/vhost/scsi.c | 15 +- drivers/vhost/vhost.c | 20 +- drivers/vhost/vhost.h | 5 +- drivers/vhost/vsock.c | 28 ++- fs/ceph/caps.c | 7 +- fs/exec.c | 2 +- fs/nfs/client.c | 4 +- fs/nfs/dir.c | 295 +++++++++++++++------------ fs/nfs/nfs4proc.c | 15 +- fs/proc/base.c | 132 ++++++------ include/linux/blkdev.h | 14 +- include/linux/iova.h | 6 + include/linux/sched.h | 10 +- include/linux/sched/numa_balancing.h | 4 +- kernel/fork.c | 2 +- kernel/sched/fair.c | 144 +++++++++---- net/vmw_vsock/af_vsock.c | 38 +--- net/vmw_vsock/hyperv_transport.c | 108 +++++++--- 45 files changed, 719 insertions(+), 426 deletions(-)

5 years, 4 months

7
40
0 0

[PATCH V4 0/2] block/scsi/dm-rq: fix leak of request private data in dm-mpath

by Ming Lei

Hi, When one request is dispatched to LLD via dm-rq, if the result is BLK_STS_*RESOURCE, dm-rq will free the request. However, LLD may allocate private data for this request, so this way will cause memory leak. Add .cleanup_rq() callback and implement it in SCSI for fixing the issue, since SCSI is the only driver which allocates private requst data in .queue_rq() path. Another use case of this callback is to free the request and re-submit bios during cpu hotplug when the hctx is dead, see the following link: https://lore.kernel.org/linux-block/f122e8f2-5ede-2d83-9ca0-bc713ce66d01@hu… V4: - add more commit log on the new .cleanup_rq callback, as suggested by Mike V3: - run .cleanup_rq() from dm-rq because this issue is dm-rq specific, and even in future it should be still very unusual to free request in this way. If we call .cleanup_rq() in generic rq free code(fast path), cost will be introduced unnecessarily, also we have to consider related race. V2: - run .cleanup_rq() in blk_mq_free_request(), as suggested by Mike Ming Lei (2): blk-mq: add callback of .cleanup_rq scsi: implement .cleanup_rq callback drivers/md/dm-rq.c | 1 + drivers/scsi/scsi_lib.c | 13 +++++++++++++ include/linux/blk-mq.h | 13 +++++++++++++ 3 files changed, 27 insertions(+) Cc: Ewan D. Milne <emilne(a)redhat.com> Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Mike Snitzer <snitzer(a)redhat.com> Cc: dm-devel(a)redhat.com Cc: <stable(a)vger.kernel.org> Fixes: 396eaf21ee17 ("blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback") -- 2.20.1

5 years, 4 months

2
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2019