July 2020 - Linux-stable-mirror

[PATCH 25/25] bcache: fix bio_{start,end}_io_acct with proper device

by Coly Li

Commit 85750aeb748f ("bcache: use bio_{start,end}_io_acct") moves the io account code to the location after bio_set_dev(bio, dc->bdev) in cached_dev_make_request(). Then the account is performed incorrectly on backing device, indeed the I/O should be counted to bcache device like /dev/bcache0. With the mistaken I/O account, iostat does not display I/O counts for bcache device and all the numbers go to backing device. In writeback mode, the hard drive may have 340K+ IOPS which is impossible and wrong for spinning disk. This patch introduces bch_bio_start_io_acct() and bch_bio_end_io_acct(), which switches bio->bi_disk to bcache device before calling bio_start_io_acct() or bio_end_io_acct(). Now the I/Os are counted to bcache device, and bcache device, cache device and backing device have their correct I/O count information back. Fixes: 85750aeb748f ("bcache: use bio_{start,end}_io_acct") Signed-off-by: Coly Li <colyli(a)suse.de> Cc: Christoph Hellwig <hch(a)lst.de> Cc: stable(a)vger.kernel.org --- drivers/md/bcache/request.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c index 7acf024e99f3..8ea0f079c1d0 100644 --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -617,6 +617,28 @@ static void cache_lookup(struct closure *cl) /* Common code for the make_request functions */ +static inline void bch_bio_start_io_acct(struct gendisk *acct_bi_disk, + struct bio *bio, + unsigned long *start_time) +{ + struct gendisk *saved_bi_disk = bio->bi_disk; + + bio->bi_disk = acct_bi_disk; + *start_time = bio_start_io_acct(bio); + bio->bi_disk = saved_bi_disk; +} + +static inline void bch_bio_end_io_acct(struct gendisk *acct_bi_disk, + struct bio *bio, + unsigned long start_time) +{ + struct gendisk *saved_bi_disk = bio->bi_disk; + + bio->bi_disk = acct_bi_disk; + bio_end_io_acct(bio, start_time); + bio->bi_disk = saved_bi_disk; +} + static void request_endio(struct bio *bio) { struct closure *cl = bio->bi_private; @@ -668,7 +690,7 @@ static void backing_request_endio(struct bio *bio) static void bio_complete(struct search *s) { if (s->orig_bio) { - bio_end_io_acct(s->orig_bio, s->start_time); + bch_bio_end_io_acct(s->d->disk, s->orig_bio, s->start_time); trace_bcache_request_end(s->d, s->orig_bio); s->orig_bio->bi_status = s->iop.status; bio_endio(s->orig_bio); @@ -728,7 +750,7 @@ static inline struct search *search_alloc(struct bio *bio, s->recoverable = 1; s->write = op_is_write(bio_op(bio)); s->read_dirty_data = 0; - s->start_time = bio_start_io_acct(bio); + bch_bio_start_io_acct(d->disk, bio, &s->start_time); s->iop.c = d->c; s->iop.bio = NULL; @@ -1080,7 +1102,7 @@ static void detached_dev_end_io(struct bio *bio) bio->bi_end_io = ddip->bi_end_io; bio->bi_private = ddip->bi_private; - bio_end_io_acct(bio, ddip->start_time); + bch_bio_end_io_acct(ddip->d->disk, bio, ddip->start_time); if (bio->bi_status) { struct cached_dev *dc = container_of(ddip->d, @@ -1105,7 +1127,8 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio) */ ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); ddip->d = d; - ddip->start_time = bio_start_io_acct(bio); + bch_bio_start_io_acct(d->disk, bio, &ddip->start_time); + ddip->bi_end_io = bio->bi_end_io; ddip->bi_private = bio->bi_private; bio->bi_end_io = detached_dev_end_io; -- 2.26.2

4 years, 5 months

2
1
0 0

Re: FW: Re: [PATCH 5.7.y 0/4] exfat stable patches for 5.7.y

by Namjae Jeon

> > > On Fri, Jul 24, 2020 at 09:15:40AM +0900, Namjae Jeon wrote: > > > >Hi, > > > > > > > >Could you please pick up exfat stable patches ? > > > > > Hi Sasha, > > > I see that the upstream commits already have stable tags and don't need modifications for backporting, > > > so there is no need to explicitly send them here - they will be picked up automatically. > > Okay, I see:) > Hi Greg, Sorry for late reply. I checked this mail late. > As Sasha said, these will normally get picked up automatically. We wait > until a patch is in a release from Linus (i.e. a -rc) before taking > them, but we can take them earilier if you ask for them. Okay, I like that you apply them after 5.8-rc7 is released if these patches can be applied in 5.7. I was just worried that 5.7 stable kernel release is closed without these patches being applied :) > > You did include one patch in this series that was not marked for stable, > so I've taken that, and the other 3 now to make it easy. Ah, okay, I will check stable mark in patches next time. Thanks for your mail! > > thanks, > > greg k-h > > > > >

4 years, 5 months

1
0
0 0

Re: Patch "btrfs: qgroup: fix data leak caused by race between writeback and truncate" has been added to the 4.14-stable tree

by Qu Wenruo

On 2020/7/26 下午8:41, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > btrfs: qgroup: fix data leak caused by race between writeback and truncate > > to the 4.14-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > btrfs-qgroup-fix-data-leak-caused-by-race-between-writeback-and-truncate.patch > and it can be found in the queue-4.14 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Please don't merge this patch for any of the stable branches. This patch needs one unmerged patch ("btrfs: change timing for qgroup reserved space for ordered extents to fix reserved space leak", already in maintainer's tree) as prerequisite. The behavior without that patch could be problematic. I should have noticed this earlier. Thanks, Qu > > > From fa91e4aa1716004ea8096d5185ec0451e206aea0 Mon Sep 17 00:00:00 2001 > From: Qu Wenruo <wqu(a)suse.com> > Date: Fri, 17 Jul 2020 15:12:05 +0800 > Subject: btrfs: qgroup: fix data leak caused by race between writeback and truncate > > From: Qu Wenruo <wqu(a)suse.com> > > commit fa91e4aa1716004ea8096d5185ec0451e206aea0 upstream. > > [BUG] > When running tests like generic/013 on test device with btrfs quota > enabled, it can normally lead to data leak, detected at unmount time: > > BTRFS warning (device dm-3): qgroup 0/5 has unreleased space, type 0 rsv 4096 > ------------[ cut here ]------------ > WARNING: CPU: 11 PID: 16386 at fs/btrfs/disk-io.c:4142 close_ctree+0x1dc/0x323 [btrfs] > RIP: 0010:close_ctree+0x1dc/0x323 [btrfs] > Call Trace: > btrfs_put_super+0x15/0x17 [btrfs] > generic_shutdown_super+0x72/0x110 > kill_anon_super+0x18/0x30 > btrfs_kill_super+0x17/0x30 [btrfs] > deactivate_locked_super+0x3b/0xa0 > deactivate_super+0x40/0x50 > cleanup_mnt+0x135/0x190 > __cleanup_mnt+0x12/0x20 > task_work_run+0x64/0xb0 > __prepare_exit_to_usermode+0x1bc/0x1c0 > __syscall_return_slowpath+0x47/0x230 > do_syscall_64+0x64/0xb0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > ---[ end trace caf08beafeca2392 ]--- > BTRFS error (device dm-3): qgroup reserved space leaked > > [CAUSE] > In the offending case, the offending operations are: > 2/6: writev f2X[269 1 0 0 0 0] [1006997,67,288] 0 > 2/7: truncate f2X[269 1 0 0 48 1026293] 18388 0 > > The following sequence of events could happen after the writev(): > CPU1 (writeback) | CPU2 (truncate) > ----------------------------------------------------------------- > btrfs_writepages() | > |- extent_write_cache_pages() | > |- Got page for 1003520 | > | 1003520 is Dirty, no writeback | > | So (!clear_page_dirty_for_io()) | > | gets called for it | > |- Now page 1003520 is Clean. | > | | btrfs_setattr() > | | |- btrfs_setsize() > | | |- truncate_setsize() > | | New i_size is 18388 > |- __extent_writepage() | > | |- page_offset() > i_size | > |- btrfs_invalidatepage() | > |- Page is clean, so no qgroup | > callback executed > > This means, the qgroup reserved data space is not properly released in > btrfs_invalidatepage() as the page is Clean. > > [FIX] > Instead of checking the dirty bit of a page, call > btrfs_qgroup_free_data() unconditionally in btrfs_invalidatepage(). > > As qgroup rsv are completely bound to the QGROUP_RESERVED bit of > io_tree, not bound to page status, thus we won't cause double freeing > anyway. > > Fixes: 0b34c261e235 ("btrfs: qgroup: Prevent qgroup->reserved from going subzero") > CC: stable(a)vger.kernel.org # 4.14+ > Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> > Signed-off-by: Qu Wenruo <wqu(a)suse.com> > Signed-off-by: David Sterba <dsterba(a)suse.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > > --- > fs/btrfs/inode.c | 23 ++++++++++------------- > 1 file changed, 10 insertions(+), 13 deletions(-) > > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -9197,20 +9197,17 @@ again: > /* > * Qgroup reserved space handler > * Page here will be either > - * 1) Already written to disk > - * In this case, its reserved space is released from data rsv map > - * and will be freed by delayed_ref handler finally. > - * So even we call qgroup_free_data(), it won't decrease reserved > - * space. > - * 2) Not written to disk > - * This means the reserved space should be freed here. However, > - * if a truncate invalidates the page (by clearing PageDirty) > - * and the page is accounted for while allocating extent > - * in btrfs_check_data_free_space() we let delayed_ref to > - * free the entire extent. > + * 1) Already written to disk or ordered extent already submitted > + * Then its QGROUP_RESERVED bit in io_tree is already cleaned. > + * Qgroup will be handled by its qgroup_record then. > + * btrfs_qgroup_free_data() call will do nothing here. > + * > + * 2) Not written to disk yet > + * Then btrfs_qgroup_free_data() call will clear the QGROUP_RESERVED > + * bit of its io_tree, and free the qgroup reserved data space. > + * Since the IO will never happen for this page. > */ > - if (PageDirty(page)) > - btrfs_qgroup_free_data(inode, NULL, page_start, PAGE_SIZE); > + btrfs_qgroup_free_data(inode, NULL, page_start, PAGE_SIZE); > if (!inode_evicting) { > clear_extent_bit(tree, page_start, page_end, > EXTENT_LOCKED | EXTENT_DIRTY | > > > Patches currently in stable-queue which might be from wqu(a)suse.com are > > queue-4.14/btrfs-qgroup-fix-data-leak-caused-by-race-between-writeback-and-truncate.patch >

4 years, 5 months

2
2
0 0

FAILED: patch "[PATCH] btrfs: fix mount failure caused by race with umount" 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 48cfa61b58a1fee0bc49eef04f8ccf31493b7cdd Mon Sep 17 00:00:00 2001 From: Boris Burkov <boris(a)bur.io> Date: Thu, 16 Jul 2020 13:29:46 -0700 Subject: [PATCH] btrfs: fix mount failure caused by race with umount It is possible to cause a btrfs mount to fail by racing it with a slow umount. The crux of the sequence is generic_shutdown_super not yet calling sop->put_super before btrfs_mount_root calls btrfs_open_devices. If that occurs, btrfs_open_devices will decide the opened counter is non-zero, increment it, and skip resetting fs_devices->total_rw_bytes to 0. From here, mount will call sget which will result in grab_super trying to take the super block umount semaphore. That semaphore will be held by the slow umount, so mount will block. Before up-ing the semaphore, umount will delete the super block, resulting in mount's sget reliably allocating a new one, which causes the mount path to dutifully fill it out, and increment total_rw_bytes a second time, which causes the mount to fail, as we see double the expected bytes. Here is the sequence laid out in greater detail: CPU0 CPU1 down_write sb->s_umount btrfs_kill_super kill_anon_super(sb) generic_shutdown_super(sb); shrink_dcache_for_umount(sb); sync_filesystem(sb); evict_inodes(sb); // SLOW btrfs_mount_root btrfs_scan_one_device fs_devices = device->fs_devices fs_info->fs_devices = fs_devices // fs_devices-opened makes this a no-op btrfs_open_devices(fs_devices, mode, fs_type) s = sget(fs_type, test, set, flags, fs_info); find sb in s_instances grab_super(sb); down_write(&s->s_umount); // blocks sop->put_super(sb) // sb->fs_devices->opened == 2; no-op spin_lock(&sb_lock); hlist_del_init(&sb->s_instances); spin_unlock(&sb_lock); up_write(&sb->s_umount); return 0; retry lookup don't find sb in s_instances (deleted by CPU0) s = alloc_super return s; btrfs_fill_super(s, fs_devices, data) open_ctree // fs_devices total_rw_bytes improperly set! btrfs_read_chunk_tree read_one_dev // increment total_rw_bytes again!! super_total_bytes < fs_devices->total_rw_bytes // ERROR!!! To fix this, we clear total_rw_bytes from within btrfs_read_chunk_tree before the calls to read_one_dev, while holding the sb umount semaphore and the uuid mutex. To reproduce, it is sufficient to dirty a decent number of inodes, then quickly umount and mount. for i in $(seq 0 500) do dd if=/dev/zero of="/mnt/foo/$i" bs=1M count=1 done umount /mnt/foo& mount /mnt/foo does the trick for me. CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Boris Burkov <boris(a)bur.io> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 0d6e785bcb98..f403fb1e6d37 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -7051,6 +7051,14 @@ int btrfs_read_chunk_tree(struct btrfs_fs_info *fs_info) mutex_lock(&uuid_mutex); mutex_lock(&fs_info->chunk_mutex); + /* + * It is possible for mount and umount to race in such a way that + * we execute this code path, but open_fs_devices failed to clear + * total_rw_bytes. We certainly want it cleared before reading the + * device items, so clear it here. + */ + fs_info->fs_devices->total_rw_bytes = 0; + /* * Read all device items, and then all the chunk items. All * device items are found before any chunk item (their object id

4 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix mount failure caused by race with umount" 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 48cfa61b58a1fee0bc49eef04f8ccf31493b7cdd Mon Sep 17 00:00:00 2001 From: Boris Burkov <boris(a)bur.io> Date: Thu, 16 Jul 2020 13:29:46 -0700 Subject: [PATCH] btrfs: fix mount failure caused by race with umount It is possible to cause a btrfs mount to fail by racing it with a slow umount. The crux of the sequence is generic_shutdown_super not yet calling sop->put_super before btrfs_mount_root calls btrfs_open_devices. If that occurs, btrfs_open_devices will decide the opened counter is non-zero, increment it, and skip resetting fs_devices->total_rw_bytes to 0. From here, mount will call sget which will result in grab_super trying to take the super block umount semaphore. That semaphore will be held by the slow umount, so mount will block. Before up-ing the semaphore, umount will delete the super block, resulting in mount's sget reliably allocating a new one, which causes the mount path to dutifully fill it out, and increment total_rw_bytes a second time, which causes the mount to fail, as we see double the expected bytes. Here is the sequence laid out in greater detail: CPU0 CPU1 down_write sb->s_umount btrfs_kill_super kill_anon_super(sb) generic_shutdown_super(sb); shrink_dcache_for_umount(sb); sync_filesystem(sb); evict_inodes(sb); // SLOW btrfs_mount_root btrfs_scan_one_device fs_devices = device->fs_devices fs_info->fs_devices = fs_devices // fs_devices-opened makes this a no-op btrfs_open_devices(fs_devices, mode, fs_type) s = sget(fs_type, test, set, flags, fs_info); find sb in s_instances grab_super(sb); down_write(&s->s_umount); // blocks sop->put_super(sb) // sb->fs_devices->opened == 2; no-op spin_lock(&sb_lock); hlist_del_init(&sb->s_instances); spin_unlock(&sb_lock); up_write(&sb->s_umount); return 0; retry lookup don't find sb in s_instances (deleted by CPU0) s = alloc_super return s; btrfs_fill_super(s, fs_devices, data) open_ctree // fs_devices total_rw_bytes improperly set! btrfs_read_chunk_tree read_one_dev // increment total_rw_bytes again!! super_total_bytes < fs_devices->total_rw_bytes // ERROR!!! To fix this, we clear total_rw_bytes from within btrfs_read_chunk_tree before the calls to read_one_dev, while holding the sb umount semaphore and the uuid mutex. To reproduce, it is sufficient to dirty a decent number of inodes, then quickly umount and mount. for i in $(seq 0 500) do dd if=/dev/zero of="/mnt/foo/$i" bs=1M count=1 done umount /mnt/foo& mount /mnt/foo does the trick for me. CC: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Boris Burkov <boris(a)bur.io> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 0d6e785bcb98..f403fb1e6d37 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -7051,6 +7051,14 @@ int btrfs_read_chunk_tree(struct btrfs_fs_info *fs_info) mutex_lock(&uuid_mutex); mutex_lock(&fs_info->chunk_mutex); + /* + * It is possible for mount and umount to race in such a way that + * we execute this code path, but open_fs_devices failed to clear + * total_rw_bytes. We certainly want it cleared before reading the + * device items, so clear it here. + */ + fs_info->fs_devices->total_rw_bytes = 0; + /* * Read all device items, and then all the chunk items. All * device items are found before any chunk item (their object id

4 years, 5 months

1
0
0 0

[PATCH V2] MIPS: CPU#0 is not hotpluggable

by Huacai Chen

Now CPU#0 is not hotpluggable on MIPS, so prevent to create /sys/devices /system/cpu/cpu0/online which confuses some user-space tools. Cc: stable(a)vger.kernel.org Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/mips/kernel/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/topology.c b/arch/mips/kernel/topology.c index cd3e1f8..08ad637 100644 --- a/arch/mips/kernel/topology.c +++ b/arch/mips/kernel/topology.c @@ -20,7 +20,7 @@ static int __init topology_init(void) for_each_present_cpu(i) { struct cpu *c = &per_cpu(cpu_devices, i); - c->hotpluggable = 1; + c->hotpluggable = !!i; ret = register_cpu(c, i); if (ret) printk(KERN_WARNING "topology_init: register_cpu %d " -- 2.7.0

4 years, 5 months

5
10
0 0

stable-rc/linux-4.4.y baseline: 116 runs, 1 regressions (v4.4.231)

by kernelci.org bot

stable-rc/linux-4.4.y baseline: 116 runs, 1 regressions (v4.4.231) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | results ------------+--------+--------------+----------+------------------+-------- qemu_x86_64 | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 0/1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.231/… Test: baseline Tree: stable-rc Branch: linux-4.4.y Describe: v4.4.231 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 554bbfc0d87fcbc842a18997c2a11a772dc3f003 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | results ------------+--------+--------------+----------+------------------+-------- qemu_x86_64 | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f1ab0ba5480baaaf885bb18 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.231/x86_64/x86_64_… HTML log: https://storage.kernelci.org//stable-rc/linux-4.4.y/v4.4.231/x86_64/x86_64_… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/x86/baselin… * baseline.login: https://kernelci.org/test/case/id/5f1ab0ba5480baaaf885bb19 new failure (last pass: v4.4.230-59-gecea46f88646)

4 years, 5 months

1
0
0 0

stable-rc/linux-5.7.y baseline: 178 runs, 4 regressions (v5.7.10)

by kernelci.org bot

stable-rc/linux-5.7.y baseline: 178 runs, 4 regressions (v5.7.10) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | results -------------------------+-------+--------------+----------+--------------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 imx6q-var-dt6customboard | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 3/5 meson-gxl-s905d-p230 | arm64 | lab-baylibre | gcc-8 | defconfig | 0/1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-5.7.y/kernel/v5.7.10/p… Test: baseline Tree: stable-rc Branch: linux-5.7.y Describe: v5.7.10 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 780e72b005455d117e2f733707ceca14792a67f1 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | results -------------------------+-------+--------------+----------+--------------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f1abcff027d8f1b1f85bb31 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: sama5_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.10/arm/sama5_defco… HTML log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.10/arm/sama5_defco… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/basel… * baseline.login: https://kernelci.org/test/case/id/5f1abcff027d8f1b1f85bb32 failing since 7 days (last pass: v5.7.8-167-gc2fb28a4b6e4, first fail: v5.7.9) platform | arch | lab | compiler | defconfig | results -------------------------+-------+--------------+----------+--------------------+-------- imx6q-var-dt6customboard | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 3/5 Details: https://kernelci.org/test/plan/id/5f1abd9b699794f7b385bb2e Results: 3 PASS, 2 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.10/arm/multi_v7_de… HTML log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.10/arm/multi_v7_de… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/basel… * baseline.dmesg.alert: https://kernelci.org/test/case/id/5f1abd9b699794f7b385bb32 new failure (last pass: v5.7.9-244-g7d2e5723ce4a) 4 lines* baseline.dmesg.emerg: https://kernelci.org/test/case/id/5f1abd9b699794f7b385bb33 new failure (last pass: v5.7.9-244-g7d2e5723ce4a) 35 lines platform | arch | lab | compiler | defconfig | results -------------------------+-------+--------------+----------+--------------------+-------- meson-gxl-s905d-p230 | arm64 | lab-baylibre | gcc-8 | defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f1c0feb310f01ad9285bb31 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.10/arm64/defconfig… HTML log: https://storage.kernelci.org//stable-rc/linux-5.7.y/v5.7.10/arm64/defconfig… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/arm64/basel… * baseline.login: https://kernelci.org/test/case/id/5f1c0feb310f01ad9285bb32 new failure (last pass: v5.7.9-244-g7d2e5723ce4a)

4 years, 5 months

1
0
0 0

[PATCH v3 03/19] firmware_loader: EFI firmware loader must handle pre-allocated buffer

by Kees Cook

The EFI platform firmware fallback would clobber any pre-allocated buffers. Instead, correctly refuse to reallocate when too small (as already done in the sysfs fallback), or perform allocation normally when needed. Fixes: e4c2c0ff00ec ("firmware: Add new platform fallback mechanism and firm ware_request_platform()") Cc: stable(a)vger.kernel.org Acked-by: Scott Branden <scott.branden(a)broadcom.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> --- To aid in backporting, this change is made before moving kernel_read_file() to separate header/source files. --- drivers/base/firmware_loader/fallback_platform.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/base/firmware_loader/fallback_platform.c b/drivers/base/firmware_loader/fallback_platform.c index cdd2c9a9f38a..685edb7dd05a 100644 --- a/drivers/base/firmware_loader/fallback_platform.c +++ b/drivers/base/firmware_loader/fallback_platform.c @@ -25,7 +25,10 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 opt_flags) if (rc) return rc; /* rc == -ENOENT when the fw was not found */ - fw_priv->data = vmalloc(size); + if (fw_priv->data && size > fw_priv->allocated_size) + return -ENOMEM; + if (!fw_priv->data) + fw_priv->data = vmalloc(size); if (!fw_priv->data) return -ENOMEM; -- 2.25.1

4 years, 5 months

2
3
0 0

stable-rc/linux-4.14.y baseline: 154 runs, 2 regressions (v4.14.189)

by kernelci.org bot

stable-rc/linux-4.14.y baseline: 154 runs, 2 regressions (v4.14.189) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | results ----------------------+-------+--------------+----------+-----------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 meson-gxbb-p200 | arm64 | lab-baylibre | gcc-8 | defconfig | 0/1 Details: https://kernelci.org/test/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.18… Test: baseline Tree: stable-rc Branch: linux-4.14.y Describe: v4.14.189 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 69b94dd6dcd14d9bfcba35a492f5e27c15cf4d0a Test Regressions ---------------- platform | arch | lab | compiler | defconfig | results ----------------------+-------+--------------+----------+-----------------+-------- at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f1ac77ac5f6635c5385bb18 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: sama5_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.14.y/v4.14.189/arm/sama5_de… HTML log: https://storage.kernelci.org//stable-rc/linux-4.14.y/v4.14.189/arm/sama5_de… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/armel/basel… * baseline.login: https://kernelci.org/test/case/id/5f1ac77ac5f6635c5385bb19 new failure (last pass: v4.14.188-126-g5b1e982af0f8) platform | arch | lab | compiler | defconfig | results ----------------------+-------+--------------+----------+-----------------+-------- meson-gxbb-p200 | arm64 | lab-baylibre | gcc-8 | defconfig | 0/1 Details: https://kernelci.org/test/plan/id/5f1ac27de51bf0a15585bb36 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/linux-4.14.y/v4.14.189/arm64/defcon… HTML log: https://storage.kernelci.org//stable-rc/linux-4.14.y/v4.14.189/arm64/defcon… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05/arm64/basel… * baseline.login: https://kernelci.org/test/case/id/5f1ac27de51bf0a15585bb37 failing since 114 days (last pass: v4.14.172-114-g734382e2d26e, first fail: v4.14.174-131-g234ce78cac23)

4 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2020