November 2018 - Linux-stable-mirror

[PATCH] MAINTAINERS: Add Sasha as a stable branch maintainer

by Greg Kroah-Hartman

Sasha has somehow been convinced into helping me with the stable kernel maintenance. Codify this slip in good judgement before he realizes what he really signed up for :) Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Acked-by: Sasha Levin <sashal(a)kernel.org> diff --git a/MAINTAINERS b/MAINTAINERS index 0abecc528dac..a46c1aa82398 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14078,6 +14078,7 @@ F: Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt STABLE BRANCH M: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> +M: Sasha Levin <sashal(a)kernel.org> L: stable(a)vger.kernel.org S: Supported F: Documentation/process/stable-kernel-rules.rst

6 years, 1 month

1
0
0 0

+ mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: cleancache: fix corruption on missed inode invalidation has been added to the -mm tree. Its filename is mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-cleancache-fix-corruption-on-mi… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-cleancache-fix-corruption-on-mi… 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/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Subject: mm: cleancache: fix corruption on missed inode invalidation If all pages are deleted from the mapping by memory reclaim and also moved to the cleancache: __delete_from_page_cache (no shadow case) unaccount_page_cache_page cleancache_put_page page_cache_delete mapping->nrpages -= nr (nrpages becomes 0) We don't clean the cleancache for an inode after final file truncation (removal). truncate_inode_pages_final check (nrpages || nrexceptional) is false no truncate_inode_pages no cleancache_invalidate_inode(mapping) These way when reading the new file created with same inode we may get these trash leftover pages from cleancache and see wrong data instead of the contents of the new file. Fix it by always doing truncate_inode_pages which is already ready for nrpages == 0 && nrexceptional == 0 case and just invalidates inode. Link: http://lkml.kernel.org/r/20181112095734.17979-1-ptikhomirov@virtuozzo.com Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache") Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Reviewed-by: Vasily Averin <vvs(a)virtuozzo.com> Reviewed-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/truncate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/truncate.c~mm-cleancache-fix-corruption-on-missed-inode-invalidation +++ a/mm/truncate.c @@ -517,9 +517,9 @@ void truncate_inode_pages_final(struct a */ xa_lock_irq(&mapping->i_pages); xa_unlock_irq(&mapping->i_pages); - - truncate_inode_pages(mapping, 0); } + + truncate_inode_pages(mapping, 0); } EXPORT_SYMBOL(truncate_inode_pages_final); _ Patches currently in -mm which might be from ptikhomirov(a)virtuozzo.com are mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch

6 years, 1 month

1
0
0 0

Re: [PATCH] clk: meson: axg: mark fdiv2 and fdiv3 as critical

by Neil Armstrong

Hi Stable team, Le 08/11/2018 10:31, Jerome Brunet a écrit : > Similar to gxbb and gxl platforms, axg SCPI Cortex-M co-processor > uses the fdiv2 and fdiv3 to, among other things, provide the cpu > clock. > > Until clock hand-off mechanism makes its way to CCF and the generic > SCPI claims platform specific clocks, these clocks must be marked as > critical to make sure they are never disabled when needed by the > co-processor. > > Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates") > Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Could this fix go into the next 4.18 and 4.19 stable releases since it hit linus master with commit id d6ee1e7e9004d3d246cdfa14196989e0a9466c16 ? Thanks, Neil > --- > > Hi Stephen, > > If you can put this one in clk-fixes as well, it would be awesome. > It is basically the same thing as the change you took this Tuesday. > > Since then, we had reports the same problem with SCPI was happening > on the axg, calling for the same fixup. > > Cheers > Jerome > > drivers/clk/meson/axg.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c > index c981159b02c0..792735d7e46e 100644 > --- a/drivers/clk/meson/axg.c > +++ b/drivers/clk/meson/axg.c > @@ -325,6 +325,7 @@ static struct clk_regmap axg_fclk_div2 = { > .ops = &clk_regmap_gate_ops, > .parent_names = (const char *[]){ "fclk_div2_div" }, > .num_parents = 1, > + .flags = CLK_IS_CRITICAL, > }, > }; > > @@ -349,6 +350,18 @@ static struct clk_regmap axg_fclk_div3 = { > .ops = &clk_regmap_gate_ops, > .parent_names = (const char *[]){ "fclk_div3_div" }, > .num_parents = 1, > + /* > + * FIXME: > + * This clock, as fdiv2, is used by the SCPI FW and is required > + * by the platform to operate correctly. > + * Until the following condition are met, we need this clock to > + * be marked as critical: > + * a) The SCPI generic driver claims and enable all the clocks > + * it needs > + * b) CCF has a clock hand-off mechanism to make the sure the > + * clock stays on until the proper driver comes along > + */ > + .flags = CLK_IS_CRITICAL, > }, > }; > >

6 years, 1 month

2
1
0 0

[PATCH 4.9] mm: do not bug_on on incorrect length in __mm_populate()

by Ben Hutchings

From: Michal Hocko <mhocko(a)suse.com> commit bb177a732c4369bb58a1fe1df8f552b6f0f7db5f upstream. syzbot has noticed that a specially crafted library can easily hit VM_BUG_ON in __mm_populate kernel BUG at mm/gup.c:1242! invalid opcode: 0000 [#1] SMP CPU: 2 PID: 9667 Comm: a.out Not tainted 4.18.0-rc3 #644 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 RIP: 0010:__mm_populate+0x1e2/0x1f0 Code: 55 d0 65 48 33 14 25 28 00 00 00 89 d8 75 21 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 75 18 f1 ff 0f 0b e8 6e 18 f1 ff <0f> 0b 31 db eb c9 e8 93 06 e0 ff 0f 1f 00 55 48 89 e5 53 48 89 fb Call Trace: vm_brk_flags+0xc3/0x100 vm_brk+0x1f/0x30 load_elf_library+0x281/0x2e0 __ia32_sys_uselib+0x170/0x1e0 do_fast_syscall_32+0xca/0x420 entry_SYSENTER_compat+0x70/0x7f The reason is that the length of the new brk is not page aligned when we try to populate the it. There is no reason to bug on that though. do_brk_flags already aligns the length properly so the mapping is expanded as it should. All we need is to tell mm_populate about it. Besides that there is absolutely no reason to to bug_on in the first place. The worst thing that could happen is that the last page wouldn't get populated and that is far from putting system into an inconsistent state. Fix the issue by moving the length sanitization code from do_brk_flags up to vm_brk_flags. The only other caller of do_brk_flags is brk syscall entry and it makes sure to provide the proper length so t here is no need for sanitation and so we can use do_brk_flags without it. Also remove the bogus BUG_ONs. [osalvador(a)techadventures.net: fix up vm_brk_flags s@request@len@] Link: http://lkml.kernel.org/r/20180706090217.GI32658@dhcp22.suse.cz Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: syzbot <syzbot+5dcb560fe12aa5091c06(a)syzkaller.appspotmail.com> Tested-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: Zi Yan <zi.yan(a)cs.rutgers.edu> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.vnet.ibm.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: "Huang, Ying" <ying.huang(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> [bwh: Backported to 4.9: - There is no do_brk_flags() function; update do_brk() - Adjust context] Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> --- mm/gup.c | 2 -- mm/mmap.c | 19 ++++++++++--------- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/mm/gup.c b/mm/gup.c index be4ccddac26f..d71da7216c6e 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -1122,8 +1122,6 @@ int __mm_populate(unsigned long start, unsigned long len, int ignore_errors) int locked = 0; long ret = 0; - VM_BUG_ON(start & ~PAGE_MASK); - VM_BUG_ON(len != PAGE_ALIGN(len)); end = start + len; for (nstart = start; nstart < end; nstart = nend) { diff --git a/mm/mmap.c b/mm/mmap.c index aa97074a4a99..283755645d17 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2876,21 +2876,15 @@ static inline void verify_mm_writelocked(struct mm_struct *mm) * anonymous maps. eventually we may be able to do some * brk-specific accounting here. */ -static int do_brk(unsigned long addr, unsigned long request) +static int do_brk(unsigned long addr, unsigned long len) { struct mm_struct *mm = current->mm; struct vm_area_struct *vma, *prev; - unsigned long flags, len; + unsigned long flags; struct rb_node **rb_link, *rb_parent; pgoff_t pgoff = addr >> PAGE_SHIFT; int error; - len = PAGE_ALIGN(request); - if (len < request) - return -ENOMEM; - if (!len) - return 0; - flags = VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags; error = get_unmapped_area(NULL, addr, len, 0, MAP_FIXED); @@ -2959,12 +2953,19 @@ static int do_brk(unsigned long addr, unsigned long request) return 0; } -int vm_brk(unsigned long addr, unsigned long len) +int vm_brk(unsigned long addr, unsigned long request) { struct mm_struct *mm = current->mm; + unsigned long len; int ret; bool populate; + len = PAGE_ALIGN(request); + if (len < request) + return -ENOMEM; + if (!len) + return 0; + if (down_write_killable(&mm->mmap_sem)) return -EINTR; -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom

6 years, 1 month

2
1
0 0

Re: [PATCH v2] clk: meson-gxbb: set fclk_div3 as CLK_IS_CRITICAL

by Neil Armstrong

Hi Stable team, Le 06/11/2018 00:08, Jerome Brunet a écrit : > From: Christian Hewitt <christianshewitt(a)gmail.com> > > On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems > with reboot; e.g. a ~60 second delay between issuing reboot and the > board power cycling (and in some OS configurations reboot will fail > and require manual power cycling). > > Similar to 'commit c987ac6f1f088663b6dad39281071aeb31d450a8 ("clk: > meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL")' the SCPI Cortex-M4 > Co-Processor seems to depend on FCLK_DIV3 being operational. > > Until commit 05f814402d6174369b3b29832cbb5eb5ed287059 ("clk: > meson: add fdiv clock gates"), this clock was modeled and left on by > the bootloader. > > We don't have precise documentation about the SCPI Co-Processor and > its clock requirement so we are learning things the hard way. > > Marking this clock as critical solves the problem but it should not > be viewed as final solution. Ideally, the SCPI driver should claim > these clocks. We also depends on some clock hand-off mechanism > making its way to CCF, to make sure the clock stays on between its > registration and the SCPI driver probe. > > Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates") > Signed-off-by: Christian Hewitt <christianshewitt(a)gmail.com> > Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> Could this patch go into the next 4.18 stable release since it hit linus master with commit id e2576c8bdfd462c34b8a46c0084e7c30b0851bf4 ? Thanks, Neil > --- > drivers/clk/meson/gxbb.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c > index 9309cfaaa464..4ada9668fd49 100644 > --- a/drivers/clk/meson/gxbb.c > +++ b/drivers/clk/meson/gxbb.c > @@ -506,6 +506,18 @@ static struct clk_regmap gxbb_fclk_div3 = { > .ops = &clk_regmap_gate_ops, > .parent_names = (const char *[]){ "fclk_div3_div" }, > .num_parents = 1, > + /* > + * FIXME: > + * This clock, as fdiv2, is used by the SCPI FW and is required > + * by the platform to operate correctly. > + * Until the following condition are met, we need this clock to > + * be marked as critical: > + * a) The SCPI generic driver claims and enable all the clocks > + * it needs > + * b) CCF has a clock hand-off mechanism to make the sure the > + * clock stays on until the proper driver comes along > + */ > + .flags = CLK_IS_CRITICAL, > }, > }; > >

6 years, 1 month

2
2
0 0

[4.4] brk alignment fixes

by Ben Hutchings

Please apply the attached fixes to the 4.4-stable branch. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom

6 years, 1 month

2
1
0 0

[PATCH 1/2] arm64: dts: stratix10: Support Ethernet Jumbo frame

by Dinh Nguyen

From: Thor Thayer <thor.thayer(a)linux.intel.com> commit a27460c9768ee19949c5b91f3d959ccd88c2a64a upstream Properly specify the RX and TX FIFO size which is important for Jumbo frames. Update the max-frame-size to support Jumbo frames. Signed-off-by: Thor Thayer <thor.thayer(a)linux.intel.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> --- arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 6 ++++++ arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi index d033da401c26..8a2641c742ae 100644 --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi @@ -137,6 +137,8 @@ reset-names = "stmmaceth", "stmmaceth-ocp"; clocks = <&clkmgr STRATIX10_EMAC0_CLK>; clock-names = "stmmaceth"; + tx-fifo-depth = <16384>; + rx-fifo-depth = <16384>; status = "disabled"; }; @@ -150,6 +152,8 @@ reset-names = "stmmaceth", "stmmaceth-ocp"; clocks = <&clkmgr STRATIX10_EMAC1_CLK>; clock-names = "stmmaceth"; + tx-fifo-depth = <16384>; + rx-fifo-depth = <16384>; status = "disabled"; }; @@ -163,6 +167,8 @@ reset-names = "stmmaceth", "stmmaceth-ocp"; clocks = <&clkmgr STRATIX10_EMAC2_CLK>; clock-names = "stmmaceth"; + tx-fifo-depth = <16384>; + rx-fifo-depth = <16384>; status = "disabled"; }; diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts index 6edc4fa9fd42..7c661753bfaf 100644 --- a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts @@ -76,7 +76,7 @@ phy-mode = "rgmii"; phy-handle = <&phy0>; - max-frame-size = <3800>; + max-frame-size = <9000>; mdio0 { #address-cells = <1>; -- 2.17.1

6 years, 1 month

3
4
0 0

[PATCH v2] ubifs: Handle re-linking of inodes correctly while recovery

by Richard Weinberger

UBIFS's recovery code strictly assumes that a deleted inode will never come back, therefore it removes all data which belongs to that inode as soon it faces an inode with link count 0 in the replay list. Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE it can lead to data loss upon a power-cut. Consider a journal with entries like: 0: inode X (nlink = 0) /* O_TMPFILE was created */ 1: data for inode X /* Someone writes to the temp file */ 2: inode X (nlink = 0) /* inode was changed, xattr, chmod, … */ 3: inode X (nlink = 1) /* inode was re-linked via linkat() */ Upon replay of entry #2 UBIFS will drop all data that belongs to inode X, this will lead to an empty file after mounting. As solution for this problem, scan the replay list for a re-link entry before dropping data. Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE") Cc: stable(a)vger.kernel.org Cc: Russell Senior <russell(a)personaltelco.net> Cc: Rafał Miłecki <zajec5(a)gmail.com> Reported-by: Russell Senior <russell(a)personaltelco.net> Reported-by: Rafał Miłecki <zajec5(a)gmail.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> --- fs/ubifs/replay.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c index 75f961c4c044..cb1f23459553 100644 --- a/fs/ubifs/replay.c +++ b/fs/ubifs/replay.c @@ -212,6 +212,38 @@ static int trun_remove_range(struct ubifs_info *c, struct replay_entry *r) return ubifs_tnc_remove_range(c, &min_key, &max_key); } +/** + * inode_still_linked - check whether inode in question will be re-linked. + * @c: UBIFS file-system description object + * @rino: replay entry to test + * + * O_TMPFILE files can be re-linked, this means link count goes from 0 to 1. + * This case needs special care, otherwise all references to the inode will + * be removed upon the first replay entry of an inode with link count 0 + * is found. + */ +static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino) +{ + struct replay_entry *r; + + ubifs_assert(c, rino->deletion); + ubifs_assert(c, key_type(c, &rino->key) == UBIFS_INO_KEY); + + /* + * Find the most recent entry for the inode behind @rino and check + * whether it is a deletion. + */ + list_for_each_entry_reverse(r, &c->replay_list, list) { + ubifs_assert(c, r->sqnum >= rino->sqnum); + if (key_inum(c, &r->key) == key_inum(c, &rino->key)) + return r->deletion == 0; + + } + + ubifs_assert(c, 0); + return false; +} + /** * apply_replay_entry - apply a replay entry to the TNC. * @c: UBIFS file-system description object @@ -239,6 +271,11 @@ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r) { ino_t inum = key_inum(c, &r->key); + if (inode_still_linked(c, r)) { + err = 0; + break; + } + err = ubifs_tnc_remove_ino(c, inum); break; } -- 2.19.1

6 years, 1 month

2
1
0 0

[PATCH v3] drm/msm: Move fence put to where failure occurs

by Robert Foss

If dma_fence_wait fails to wait for a supplied in-fence in msm_ioctl_gem_submit, make sure we release that in-fence. Also remove this dma_fence_put() from the 'out' label. Signed-off-by: Robert Foss <robert.foss(a)collabora.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: stable(a)vger.kernel.org --- Changes since v2: - Chris Wilson: Added r-b and stable kernel tag Changes since v1: - Chris Wilson: Make sure that dma_fence_put() is always executed drivers/gpu/drm/msm/msm_gem_submit.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index a90aedd6883a..d5e6665a4c8f 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, struct msm_file_private *ctx = file->driver_priv; struct msm_gem_submit *submit; struct msm_gpu *gpu = priv->gpu; - struct dma_fence *in_fence = NULL; struct sync_file *sync_file = NULL; struct msm_gpu_submitqueue *queue; struct msm_ringbuffer *ring; @@ -444,6 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, ring = gpu->rb[queue->prio]; if (args->flags & MSM_SUBMIT_FENCE_FD_IN) { + struct dma_fence *in_fence; + in_fence = sync_file_get_fence(args->fence_fd); if (!in_fence) @@ -453,11 +454,13 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, * Wait if the fence is from a foreign context, or if the fence * array contains any fence from a foreign context. */ - if (!dma_fence_match_context(in_fence, ring->fctx->context)) { + ret = 0; + if (!dma_fence_match_context(in_fence, ring->fctx->context)) ret = dma_fence_wait(in_fence, true); - if (ret) - return ret; - } + + dma_fence_put(in_fence); + if (ret) + return ret; } ret = mutex_lock_interruptible(&dev->struct_mutex); @@ -583,8 +586,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, } out: - if (in_fence) - dma_fence_put(in_fence); submit_cleanup(submit); if (ret) msm_gem_submit_free(submit); -- 2.17.1

6 years, 1 month

1
1
0 0

[PATCH v3 2/2] drm/vc4: Set ->legacy_cursor_update to false when doing non-async updates

by Boris Brezillon

drm_atomic_helper_setup_commit() auto-completes commit->flip_done when state->legacy_cursor_update is true, but we know for sure that we want a sync update when we call drm_atomic_helper_setup_commit() from vc4_atomic_commit(). Explicitly set state->legacy_cursor_update to false to prevent this auto-completion. Fixes: 184d3cf4f738 ("drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Reviewed-by: Eric Anholt <eric(a)anholt.net> --- Changes in v3: - Add missing Fixes and Cc-stable tags - Fix a typo in the commit message Changes in v2: - Add Eric's R-b --- drivers/gpu/drm/vc4/vc4_kms.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index 127468785f74..1f94b9affe4b 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -214,6 +214,12 @@ static int vc4_atomic_commit(struct drm_device *dev, return 0; } + /* We know for sure we don't want an async update here. Set + * state->legacy_cursor_update to false to prevent + * drm_atomic_helper_setup_commit() from auto-completing + * commit->flip_done. + */ + state->legacy_cursor_update = false; ret = drm_atomic_helper_setup_commit(state, nonblock); if (ret) return ret; -- 2.17.1

6 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2018