- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

by Patrick McLean

As of 4.13.11 (and also with 4.14-rc) we have an issue where when serving nfs4 sometimes we get the following BUG. When this bug happens, it usually also causes the motherboard to no longer POST until we externally re-flash the BIOS (using the BMC web interface). If a motherboard does not have an external way to flash the BIOS, this would brick the hardware. The issue was introduced somewhere between 4.13.8 and 4.13.11 in the stable series 4.13 kernels. It seems to be much easier to trigger on 4.14 kernels than 4.13 kernels. We are working on bisecting it, but it is slow going since it often takes several reboots to trigger the issue. The taint is caused by the "gkuart" an out-of-kernel driver which is a fork of the cp210x driver with GPIO lines added to it, we can provide the source for this if needed. When the BIOS is gets broke, we see these messages in the shutdown logs: > [ 2206.698884] kvm: exiting hardware virtualization > [ 2206.700160] e1000e: EEE TX LPI TIMER: 00t > [ 2206.743126] ACPI MEMORY or I/O RESET_REG. Here is the BUG we are getting: > [ 58.962528] BUG: unable to handle kernel NULL pointer dereference at 0000000000000230 > [ 58.963918] IP: vfs_statfs+0x73/0xb0 > [ 58.964597] PGD 0 P4D 0 > [ 58.965208] Oops: 0000 [#1] SMP > [ 58.965847] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_multiport xt_addrtype iptable_mangle iptable_raw iptable_nat nf_nat_ipv4 nf_nat gkuart(O) usbserial x86_pkg_temp_thermal ipmi_ssif tpm_tis tpm_tis_core ie31200_edac ext4 mbcache jbd2 e1000e crc32c_intel > [ 58.969163] CPU: 0 PID: 3970 Comm: nfsd Tainted: G O 4.14.0-rc8-git-kratos-1-00012-gd6a2cf07f0c9 #1 > [ 58.970693] Hardware name: TYAN S5510/S5510, BIOS V2.02 03/12/2013 > [ 58.971685] task: ffff88040b286200 task.stack: ffffc90002c94000 > [ 58.972576] RIP: 0010:vfs_statfs+0x73/0xb0 > [ 58.973329] RSP: 0018:ffffc90002c97b30 EFLAGS: 00010202 > [ 58.974188] RAX: 0000000000000000 RBX: ffffc90002c97bf8 RCX: 0000000000001c00 > [ 58.975253] RDX: 0000000000000c00 RSI: 0000000000000020 RDI: 0000000000000000 > [ 58.976213] RBP: ffffc90002c97bc8 R08: 0000000000000000 R09: 00000000000000ff > [ 58.977161] R10: 000000000038be3a R11: ffff88040ec440c8 R12: ffff88040c5ba000 > [ 58.978107] R13: ffff88040a86e000 R14: ffff88040c5c1000 R15: ffffc90002c97bf8 > [ 58.979051] FS: 0000000000000000(0000) GS:ffff88041fc00000(0000) knlGS:0000000000000000 > [ 58.980448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 58.981419] CR2: 0000000000000230 CR3: 0000000001e0a002 CR4: 00000000001606f0 > [ 58.982483] Call Trace: > [ 58.983108] nfsd4_encode_fattr+0x1f3/0x2070 > [ 58.983873] ? find_inode_fast+0x52/0x90 > [ 58.984587] ? get_acl+0x17/0xf0 > [ 58.985258] ? generic_permission+0x122/0x1a0 > [ 58.986019] nfsd4_encode_getattr+0x25/0x30 > [ 58.986746] nfsd4_encode_operation+0x98/0x1a0 > [ 58.987485] nfsd4_proc_compound+0x3eb/0x5c0 > [ 58.988206] nfsd_dispatch+0xa8/0x230 > [ 58.988891] svc_process_common+0x347/0x640 > [ 58.989619] svc_process+0x100/0x1b0 > [ 58.990334] nfsd+0xe3/0x150 > [ 58.990988] kthread+0xfc/0x130 > [ 58.991651] ? nfsd_destroy+0x60/0x60 > [ 58.992364] ? kthread_create_on_node+0x40/0x40 > [ 58.993153] ret_from_fork+0x25/0x30 > [ 58.993858] Code: d1 83 c9 08 40 f6 c6 04 0f 45 d1 89 d1 80 cd 04 40 f6 c6 08 0f 45 d1 89 d1 80 cd 08 40 f6 c6 10 0f 45 d1 89 d1 80 cd 10 83 e6 20 <48> 8b b7 30 02 00 00 0f 45 d1 83 ca 20 89 f1 83 e1 10 89 cf 83 > [ 58.996592] RIP: vfs_statfs+0x73/0xb0 RSP: ffffc90002c97b30 > [ 58.997474] CR2: 0000000000000230 > [ 58.998147] ---[ end trace c3a6e976d53aaa00 ]--- > [ 107.669217] random: crng init done > [ 210.170059] BUG: unable to handle kernel NULL pointer dereference at 0000000000000230 > [ 210.176363] IP: vfs_statfs+0x73/0xb0 > [ 210.177032] PGD 0 P4D 0 > [ 210.177633] Oops: 0000 [#2] SMP > [ 210.178286] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_multiport xt_addrtype iptable_mangle iptable_raw iptable_nat nf_nat_ipv4 nf_nat gkuart(O) usbserial x86_pkg_temp_thermal ipmi_ssif tpm_tis tpm_tis_core ie31200_edac ext4 mbcache jbd2 e1000e crc32c_intel > [ 210.192120] CPU: 0 PID: 3969 Comm: nfsd Tainted: G D O 4.14.0-rc8-git-kratos-1-00012-gd6a2cf07f0c9 #1 > [ 210.203168] Hardware name: TYAN S5510/S5510, BIOS V2.02 03/12/2013 > [ 210.204140] task: ffff880409a7aa00 task.stack: ffffc90002c8c000 > [ 210.205168] RIP: 0010:vfs_statfs+0x73/0xb0 > [ 210.205893] RSP: 0018:ffffc90002c8fb30 EFLAGS: 00010202 > [ 210.206708] RAX: 0000000000000000 RBX: ffffc90002c8fbf8 RCX: 0000000000001c00 > [ 210.218314] RDX: 0000000000000c00 RSI: 0000000000000020 RDI: 0000000000000000 > [ 210.219364] RBP: ffffc90002c8fbc8 R08: 0000000000000000 R09: 00000000000000ff > [ 210.220426] R10: 000000000038be3a R11: ffff88040ec440c8 R12: ffff88040c5b8000 > [ 210.221455] R13: ffff88040a86e000 R14: ffff88040c5c4000 R15: ffffc90002c8fbf8 > [ 210.222484] FS: 0000000000000000(0000) GS:ffff88041fc00000(0000) knlGS:0000000000000000 > [ 210.223894] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 210.224938] CR2: 0000000000000230 CR3: 0000000001e0a003 CR4: 00000000001606f0 > [ 210.226020] Call Trace: > [ 210.226615] nfsd4_encode_fattr+0x1f3/0x2070 > [ 210.227348] ? find_inode_fast+0x52/0x90 > [ 210.238225] ? get_acl+0x17/0xf0 > [ 210.238890] ? generic_permission+0x122/0x1a0 > [ 210.239637] nfsd4_encode_getattr+0x25/0x30 > [ 210.240365] nfsd4_encode_operation+0x98/0x1a0 > [ 210.241127] nfsd4_proc_compound+0x3eb/0x5c0 > [ 210.241868] nfsd_dispatch+0xa8/0x230 > [ 210.242564] svc_process_common+0x347/0x640 > [ 210.243294] svc_process+0x100/0x1b0 > [ 210.243969] nfsd+0xe3/0x150 > [ 210.244582] kthread+0xfc/0x130 > [ 210.255467] ? nfsd_destroy+0x60/0x60 > [ 210.256153] ? kthread_create_on_node+0x40/0x40 > [ 210.256892] ret_from_fork+0x25/0x30 > [ 210.257570] Code: d1 83 c9 08 40 f6 c6 04 0f 45 d1 89 d1 80 cd 04 40 f6 c6 08 0f 45 d1 89 d1 80 cd 08 40 f6 c6 10 0f 45 d1 89 d1 80 cd 10 83 e6 20 <48> 8b b7 30 02 00 00 0f 45 d1 83 ca 20 89 f1 83 e1 10 89 cf 83 > [ 210.260340] RIP: vfs_statfs+0x73/0xb0 RSP: ffffc90002c8fb30 > [ 210.261157] CR2: 0000000000000230 > [ 210.261810] ---[ end trace c3a6e976d53aaa01 ]---

6 years, 6 months

9
36
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

by alexander.levin＠verizon.com

From: Bob Moore <robert.moore(a)intel.com> [ Upstream commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3 ] ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1 ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e The declared buffer length must be the same as the length of the byte initializer list, otherwise not a valid resource descriptor. Link: https://github.com/acpica/acpica/commit/9f76de2d Link: https://github.com/acpica/acpica/commit/b2e89d72 Link: https://github.com/acpica/acpica/commit/23b5bbe6 Signed-off-by: Bob Moore <robert.moore(a)intel.com> Signed-off-by: Lv Zheng <lv.zheng(a)intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- drivers/acpi/acpica/utresrc.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/acpica/utresrc.c b/drivers/acpi/acpica/utresrc.c index 1de3376da66a..2ad99ea3d496 100644 --- a/drivers/acpi/acpica/utresrc.c +++ b/drivers/acpi/acpica/utresrc.c @@ -421,8 +421,10 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state, ACPI_FUNCTION_TRACE(ut_walk_aml_resources); - /* The absolute minimum resource template is one end_tag descriptor */ - + /* + * The absolute minimum resource template is one end_tag descriptor. + * However, we will treat a lone end_tag as just a simple buffer. + */ if (aml_length < sizeof(struct aml_resource_end_tag)) { return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG); } @@ -454,9 +456,8 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state, /* Invoke the user function */ if (user_function) { - status = - user_function(aml, length, offset, resource_index, - context); + status = user_function(aml, length, offset, + resource_index, context); if (ACPI_FAILURE(status)) { return_ACPI_STATUS(status); } @@ -480,6 +481,12 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state, *context = aml; } + /* Check if buffer is defined to be longer than the resource length */ + + if (aml_length > (offset + length)) { + return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG); + } + /* Normal exit */ return_ACPI_STATUS(AE_OK); -- 2.11.0

6 years, 6 months

5
67
0 0

Re: [Linux-stable-mirror] [PATCH 4.13 00/44] 4.13.14-stable review

by Greg Kroah-Hartman

On Thu, Nov 16, 2017 at 04:02:28PM -0800, kernelci.org bot wrote: > stable-rc/linux-4.13.y boot: 241 boots: 10 failed, 225 passed with 5 offline, 1 conflict (v4.13.13-45-gff52a5099e0b) > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.13.y/kernel/v4.1… > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.13.y/kernel/v4.13.13-45… > > Tree: stable-rc > Branch: linux-4.13.y > Git Describe: v4.13.13-45-gff52a5099e0b > Git Commit: ff52a5099e0b6063a807ff017528b0b3fa78ad58 > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Tested: 88 unique boards, 24 SoC families, 21 builds out of 188 > > Boot Regressions Detected: > > arm: > > at91_dt_defconfig: > at91sam9261ek: > lab-free-electrons: new failure (last pass: v4.13.13) Hm, is this something to worry about? > exynos_defconfig: > exynos4412-odroidx2_rootfs:nfs: > lab-collabora: failing since 7 days (last pass: v4.13.11-37-g2295c8345797 - first fail: v4.13.12) > exynos5250-snow_rootfs:nfs: > lab-collabora: failing since 7 days (last pass: v4.13.11-37-g2295c8345797 - first fail: v4.13.12) > exynos5422-odroidxu3_rootfs:nfs: > lab-collabora: failing since 7 days (last pass: v4.13.5 - first fail: v4.13.12) > > omap2plus_defconfig: > am335x-boneblack_rootfs:nfs: > lab-collabora: failing since 7 days (last pass: v4.13.11-37-g2295c8345797 - first fail: v4.13.12) > > tegra_defconfig: > tegra124-jetson-tk1_rootfs:nfs: > lab-collabora: failing since 7 days (last pass: v4.13.11-37-g2295c8345797 - first fail: v4.13.12) For these I'm just guessing the collabora lab fell off the map :) thanks, greg k-h

6 years, 6 months

2
1
0 0

[Linux-stable-mirror] [patch 57/94] nilfs2: fix race condition that causes file system corruption

by akpm＠linux-foundation.org

From: Andreas Rohner <andreas.rohner(a)gmx.net> Subject: nilfs2: fix race condition that causes file system corruption There is a race condition between nilfs_dirty_inode() and nilfs_set_file_dirty(). When a file is opened, nilfs_dirty_inode() is called to update the access timestamp in the inode. It calls __nilfs_mark_inode_dirty() in a separate transaction. __nilfs_mark_inode_dirty() caches the ifile buffer_head in the i_bh field of the inode info structure and marks it as dirty. After some data was written to the file in another transaction, the function nilfs_set_file_dirty() is called, which adds the inode to the ns_dirty_files list. Then the segment construction calls nilfs_segctor_collect_dirty_files(), which goes through the ns_dirty_files list and checks the i_bh field. If there is a cached buffer_head in i_bh it is not marked as dirty again. Since nilfs_dirty_inode() and nilfs_set_file_dirty() use separate transactions, it is possible that a segment construction that writes out the ifile occurs in-between the two. If this happens the inode is not on the ns_dirty_files list, but its ifile block is still marked as dirty and written out. In the next segment construction, the data for the file is written out and nilfs_bmap_propagate() updates the b-tree. Eventually the bmap root is written into the i_bh block, which is not dirty, because it was written out in another segment construction. As a result the bmap update can be lost, which leads to file system corruption. Either the virtual block address points to an unallocated DAT block, or the DAT entry will be reused for something different. The error can remain undetected for a long time. A typical error message would be one of the "bad btree" errors or a warning that a DAT entry could not be found. This bug can be reproduced reliably by a simple benchmark that creates and overwrites millions of 4k files. Link: http://lkml.kernel.org/r/1509367935-3086-2-git-send-email-konishi.ryusuke@l… Signed-off-by: Andreas Rohner <andreas.rohner(a)gmx.net> Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)lab.ntt.co.jp> Tested-by: Andreas Rohner <andreas.rohner(a)gmx.net> Tested-by: Ryusuke Konishi <konishi.ryusuke(a)lab.ntt.co.jp> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/segment.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff -puN fs/nilfs2/segment.c~nilfs2-fix-race-condition-that-causes-file-system-corruption fs/nilfs2/segment.c --- a/fs/nilfs2/segment.c~nilfs2-fix-race-condition-that-causes-file-system-corruption +++ a/fs/nilfs2/segment.c @@ -1954,8 +1954,6 @@ static int nilfs_segctor_collect_dirty_f err, ii->vfs_inode.i_ino); return err; } - mark_buffer_dirty(ibh); - nilfs_mdt_mark_dirty(ifile); spin_lock(&nilfs->ns_inode_lock); if (likely(!ii->i_bh)) ii->i_bh = ibh; @@ -1964,6 +1962,10 @@ static int nilfs_segctor_collect_dirty_f goto retry; } + // Always redirty the buffer to avoid race condition + mark_buffer_dirty(ii->i_bh); + nilfs_mdt_mark_dirty(ifile); + clear_bit(NILFS_I_QUEUED, &ii->i_state); set_bit(NILFS_I_BUSY, &ii->i_state); list_move_tail(&ii->i_dirty, &sci->sc_dirty_files); _

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] [patch 51/94] autofs: don't fail mount for transient error

by akpm＠linux-foundation.org

From: NeilBrown <neilb(a)suse.com> Subject: autofs: don't fail mount for transient error Currently if the autofs kernel module gets an error when writing to the pipe which links to the daemon, then it marks the whole moutpoint as catatonic, and it will stop working. It is possible that the error is transient. This can happen if the daemon is slow and more than 16 requests queue up. If a subsequent process tries to queue a request, and is then signalled, the write to the pipe will return -ERESTARTSYS and autofs will take that as total failure. So change the code to assess -ERESTARTSYS and -ENOMEM as transient failures which only abort the current request, not the whole mountpoint. It isn't a crash or a data corruption, but having autofs mountpoints suddenly stop working is rather inconvenient. Ian said: : And given the problems with a half dozen (or so) user space applications : consuming large amounts of CPU under heavy mount and umount activity this : could happen more easily than we expect. Link: http://lkml.kernel.org/r/87y3norvgp.fsf@notabene.neil.brown.name Signed-off-by: NeilBrown <neilb(a)suse.com> Acked-by: Ian Kent <raven(a)themaw.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/autofs4/waitq.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff -puN fs/autofs4/waitq.c~autofs-dont-fail-mount-for-transient-error fs/autofs4/waitq.c --- a/fs/autofs4/waitq.c~autofs-dont-fail-mount-for-transient-error +++ a/fs/autofs4/waitq.c @@ -81,7 +81,8 @@ static int autofs4_write(struct autofs_s spin_unlock_irqrestore(&current->sighand->siglock, flags); } - return (bytes > 0); + /* if 'wr' returned 0 (impossible) we assume -EIO (safe) */ + return bytes == 0 ? 0 : wr < 0 ? wr : -EIO; } static void autofs4_notify_daemon(struct autofs_sb_info *sbi, @@ -95,6 +96,7 @@ static void autofs4_notify_daemon(struct } pkt; struct file *pipe = NULL; size_t pktsz; + int ret; pr_debug("wait id = 0x%08lx, name = %.*s, type=%d\n", (unsigned long) wq->wait_queue_token, @@ -169,7 +171,18 @@ static void autofs4_notify_daemon(struct mutex_unlock(&sbi->wq_mutex); if (autofs4_write(sbi, pipe, &pkt, pktsz)) + switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) { + case 0: + break; + case -ENOMEM: + case -ERESTARTSYS: + /* Just fail this one */ + autofs4_wait_release(sbi, wq->wait_queue_token, ret); + break; + default: autofs4_catatonic_mode(sbi); + break; + } fput(pipe); } _

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] [patch 02/94] mm/z3fold.c: use kref to prevent page free/compact race

by akpm＠linux-foundation.org

From: Vitaly Wool <vitalywool(a)gmail.com> Subject: mm/z3fold.c: use kref to prevent page free/compact race There is a race in the current z3fold implementation between do_compact() called in a work queue context and the page release procedure when page's kref goes to 0. do_compact() may be waiting for page lock, which is released by release_z3fold_page_locked right before putting the page onto the "stale" list, and then the page may be freed as do_compact() modifies its contents. The mechanism currently implemented to handle that (checking the PAGE_STALE flag) is not reliable enough. Instead, we'll use page's kref counter to guarantee that the page is not released if its compaction is scheduled. It then becomes compaction function's responsibility to decrease the counter and quit immediately if the page was actually freed. Link: http://lkml.kernel.org/r/20171117092032.00ea56f42affbed19f4fcc6c@gmail.com Signed-off-by: Vitaly Wool <vitaly.wool(a)sonymobile.com> Cc: <Oleksiy.Avramchenko(a)sony.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/z3fold.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff -puN mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race mm/z3fold.c --- a/mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race +++ a/mm/z3fold.c @@ -404,8 +404,7 @@ static void do_compact_page(struct z3fol WARN_ON(z3fold_page_trylock(zhdr)); else z3fold_page_lock(zhdr); - if (test_bit(PAGE_STALE, &page->private) || - !test_and_clear_bit(NEEDS_COMPACTING, &page->private)) { + if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) { z3fold_page_unlock(zhdr); return; } @@ -413,6 +412,11 @@ static void do_compact_page(struct z3fol list_del_init(&zhdr->buddy); spin_unlock(&pool->lock); + if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) { + atomic64_dec(&pool->pages_nr); + return; + } + z3fold_compact_page(zhdr); unbuddied = get_cpu_ptr(pool->unbuddied); fchunks = num_free_chunks(zhdr); @@ -753,9 +757,11 @@ static void z3fold_free(struct z3fold_po list_del_init(&zhdr->buddy); spin_unlock(&pool->lock); zhdr->cpu = -1; + kref_get(&zhdr->refcount); do_compact_page(zhdr, true); return; } + kref_get(&zhdr->refcount); queue_work_on(zhdr->cpu, pool->compact_wq, &zhdr->work); z3fold_page_unlock(zhdr); } _

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] + z3fold-use-kref-to-prevent-page-free-compact-race.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/z3fold.c: use kref to prevent page free/compact race has been added to the -mm tree. Its filename is z3fold-use-kref-to-prevent-page-free-compact-race.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/z3fold-use-kref-to-prevent-page-fr… and later at http://ozlabs.org/~akpm/mmotm/broken-out/z3fold-use-kref-to-prevent-page-fr… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Vitaly Wool <vitalywool(a)gmail.com> Subject: mm/z3fold.c: use kref to prevent page free/compact race There is a race in the current z3fold implementation between do_compact() called in a work queue context and the page release procedure when page's kref goes to 0. do_compact() may be waiting for page lock, which is released by release_z3fold_page_locked right before putting the page onto the "stale" list, and then the page may be freed as do_compact() modifies its contents. The mechanism currently implemented to handle that (checking the PAGE_STALE flag) is not reliable enough. Instead, we'll use page's kref counter to guarantee that the page is not released if its compaction is scheduled. It then becomes compaction function's responsibility to decrease the counter and quit immediately if the page was actually freed. Link: http://lkml.kernel.org/r/20171117092032.00ea56f42affbed19f4fcc6c@gmail.com Signed-off-by: Vitaly Wool <vitaly.wool(a)sonymobile.com> Cc: <Oleksiy.Avramchenko(a)sony.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/z3fold.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff -puN mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race mm/z3fold.c --- a/mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race +++ a/mm/z3fold.c @@ -404,8 +404,7 @@ static void do_compact_page(struct z3fol WARN_ON(z3fold_page_trylock(zhdr)); else z3fold_page_lock(zhdr); - if (test_bit(PAGE_STALE, &page->private) || - !test_and_clear_bit(NEEDS_COMPACTING, &page->private)) { + if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) { z3fold_page_unlock(zhdr); return; } @@ -413,6 +412,11 @@ static void do_compact_page(struct z3fol list_del_init(&zhdr->buddy); spin_unlock(&pool->lock); + if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) { + atomic64_dec(&pool->pages_nr); + return; + } + z3fold_compact_page(zhdr); unbuddied = get_cpu_ptr(pool->unbuddied); fchunks = num_free_chunks(zhdr); @@ -753,9 +757,11 @@ static void z3fold_free(struct z3fold_po list_del_init(&zhdr->buddy); spin_unlock(&pool->lock); zhdr->cpu = -1; + kref_get(&zhdr->refcount); do_compact_page(zhdr, true); return; } + kref_get(&zhdr->refcount); queue_work_on(zhdr->cpu, pool->compact_wq, &zhdr->work); z3fold_page_unlock(zhdr); } _ Patches currently in -mm which might be from vitalywool(a)gmail.com are z3fold-use-kref-to-prevent-page-free-compact-race.patch

6 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH] bio: ensure __bio_clone_fast copies bi_partno

by Michael Lyle

A new field was introduced in 74d46992e0d9dee7f1f376de0d56d31614c8a17a, bi_partno, instead of using bdev->bd_contains and encoding the partition information in the bi_bdev field. __bio_clone_fast was changed to copy the disk information, but not the partition information. At minimum, this regressed bcache and caused data corruption. Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Fixes: 74d46992e0d9dee7f1f376de0d56d31614c8a17a Reported-by: Pavel Goran <via-bcache(a)pvgoran.name> Reported-by: Campbell Steven <casteven(a)gmail.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: <stable(a)vger.kernel.org> --- block/bio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/bio.c b/block/bio.c index 101c2a9b5481..33fa6b4af312 100644 --- a/block/bio.c +++ b/block/bio.c @@ -597,6 +597,7 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src) * so we don't set nor calculate new physical/hw segment counts here */ bio->bi_disk = bio_src->bi_disk; + bio->bi_partno = bio_src->bi_partno; bio_set_flag(bio, BIO_CLONED); bio->bi_opf = bio_src->bi_opf; bio->bi_write_hint = bio_src->bi_write_hint; -- 2.14.1

6 years, 6 months

8
8
0 0

[Linux-stable-mirror] [PATCH 0/7] [RESEND] [net] intel: Use smp_rmb rather than read_barrier_depends

by Brian King

Resending as the first attempt is not showing up in the list archive. This patch converts several network drivers to use smp_rmb rather than read_barrier_depends. The initial issue was discovered with ixgbe on a Power machine which resulted in skb list corruption due to fetching a stale skb pointer. More details can be found in the ixgbe patch description. Brian King (7): ixgbe: Fix skb list corruption on Power systems i40e: Use smp_rmb rather than read_barrier_depends ixgbevf: Use smp_rmb rather than read_barrier_depends igbvf: Use smp_rmb rather than read_barrier_depends igb: Use smp_rmb rather than read_barrier_depends fm10k: Use smp_rmb rather than read_barrier_depends i40evf: Use smp_rmb rather than read_barrier_depends drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +- drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- drivers/net/ethernet/intel/igbvf/netdev.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +- 8 files changed, 9 insertions(+), 8 deletions(-) -- 1.8.3.1

6 years, 6 months

4
14
0 0

[Linux-stable-mirror] [PATCH] omapdrm: hdmi4: Correct the SoC revision matching

by Peter Ujfalusi

I believe the intention of the commit 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver") was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions, like omap4460. By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a same way as it would treat omap4430 ES1.x This breaks HDMI audio on OMAP4460 devices (PandaES for example). Correct the match rule so we are not going to get false positive match. Fixes: 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver") CC: stable(a)vger.kernel.org # 4.14 Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c index 62e451162d96..07945a40c33a 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c @@ -902,9 +902,20 @@ static const struct hdmi4_features hdmi4_es3_features = { }; static const struct soc_device_attribute hdmi4_soc_devices[] = { - { .family = "OMAP4", .revision = "ES1.?", .data = &hdmi4_es1_features }, - { .family = "OMAP4", .revision = "ES2.?", .data = &hdmi4_es2_features }, - { .family = "OMAP4", .data = &hdmi4_es3_features }, + { + .machine = "OMAP4430", + .revision = "ES1.?", + .data = &hdmi4_es1_features, + }, + { + .machine = "OMAP4430", + .revision = "ES2.?", + .data = &hdmi4_es2_features, + }, + { + .family = "OMAP4", + .data = &hdmi4_es3_features, + }, { /* sentinel */ } }; -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

6 years, 6 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror