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

Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

by Thomas Deutschmann

Hi, please add > From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001 > From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> > Date: Thu, 25 Jan 2018 19:03:03 +0100 > Subject: net: don't call update_pmtu unconditionally > > Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to: > "BUG: unable to handle kernel NULL pointer dereference at (null)" > > Let's add a helper to check if update_pmtu is available before calling it. > > Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path") > Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") > CC: Roman Kapl <code(a)rkapl.cz> > CC: Xin Long <lucien.xin(a)gmail.com> > Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> > Signed-off-by: David S. Miller <davem(a)davemloft.net> to 4.14.x. This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path"), which was backported to 4.14.24. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

7 years, 7 months

4
11
0 0

FAILED: patch "[PATCH] tpm: self test failure should not cause suspend to fail" 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 0803d7befa15cab5717d667a97a66214d2a4c083 Mon Sep 17 00:00:00 2001 From: Chris Chiu <chiu(a)endlessm.com> Date: Tue, 20 Mar 2018 15:36:40 +0800 Subject: [PATCH] tpm: self test failure should not cause suspend to fail The Acer Acer Veriton X4110G has a TPM device detected as: tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71) After the first S3 suspend, the following error appears during resume: tpm tpm0: A TPM error(38) occurred continue selftest Any following S3 suspend attempts will now fail with this error: tpm tpm0: Error (38) sending savestate before suspend PM: Device 00:0b failed to suspend: error 38 Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is not in the correct state. This indicates that the platform BIOS is not sending the usual TPM_Startup command during S3 resume. >From this point onwards, all TPM commands will fail. The same issue was previously reported on Foxconn 6150BK8MC and Sony Vaio TX3. The platform behaviour seems broken here, but we should not break suspend/resume because of this. When the unexpected TPM state is encountered, set a flag to skip the affected TPM_SaveState command on later suspends. Cc: stable(a)vger.kernel.org Signed-off-by: Chris Chiu <chiu(a)endlessm.com> Signed-off-by: Daniel Drake <drake(a)endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23Ui… Link: https://lkml.org/lkml/2011/3/28/192 Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031 Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 47aacecdc85c..22288ff70a0b 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -1002,6 +1002,10 @@ int tpm_do_selftest(struct tpm_chip *chip) loops = jiffies_to_msecs(duration) / delay_msec; rc = tpm_continue_selftest(chip); + if (rc == TPM_ERR_INVALID_POSTINIT) { + chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED; + dev_info(&chip->dev, "TPM not ready (%d)\n", rc); + } /* This may fail if there was no TPM driver during a suspend/resume * cycle; some may return 10 (BAD_ORDINAL), others 28 (FAILEDSELFTEST) */

7 years, 7 months

3
4
0 0

[PATCH 0/3] v4.16 tpmdd backports

by Jarkko Sakkinen

"tpm: add retry logic" caused merge conflicts so I picked couple of other fixes in order to get it apply cleanly. James Bottomley (1): tpm: add retry logic Tomas Winkler (1): tpm: cmd_ready command can be issued only after granting locality Winkler, Tomas (1): tpm: tpm-interface: fix tpm_transmit/_cmd kdoc drivers/char/tpm/tpm-interface.c | 131 ++++++++++++++++++++++++------- drivers/char/tpm/tpm.h | 1 + drivers/char/tpm/tpm_crb.c | 108 +++++++++++++++++-------- drivers/char/tpm/tpm_tis_core.c | 4 +- include/linux/tpm.h | 2 +- 5 files changed, 183 insertions(+), 63 deletions(-) -- 2.17.0

7 years, 7 months

3
7
0 0

+ mm-sections-are-not-offlined-during-memory-hotremove.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: sections are not offlined during memory hotremove has been added to the -mm tree. Its filename is mm-sections-are-not-offlined-during-memory-hotremove.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-sections-are-not-offlined-durin… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-sections-are-not-offlined-durin… 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 Tatashin <pasha.tatashin(a)oracle.com> Subject: mm: sections are not offlined during memory hotremove Memory hotplug and hotremove operate with per-block granularity. If the machine has a large amount of memory (more than 64G), the size of a memory block can span multiple sections. By mistake, during hotremove we set only the first section to offline state. The bug was discovered because kernel selftest started to fail: https://lkml.kernel.org/r/20180423011247.GK5563@yexl-desktop After commit, "mm/memory_hotplug: optimize probe routine". But, the bug is older than this commit. In this optimization we also added a check for sections to be in a proper state during hotplug operation. Link: http://lkml.kernel.org/r/20180427145257.15222-1-pasha.tatashin@oracle.com Fixes: 2d070eab2e82 ("mm: consider zone which is not fully populated to have holes") Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Steven Sistare <steven.sistare(a)oracle.com> Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/sparse.c~mm-sections-are-not-offlined-during-memory-hotremove mm/sparse.c --- a/mm/sparse.c~mm-sections-are-not-offlined-during-memory-hotremove +++ a/mm/sparse.c @@ -629,7 +629,7 @@ void offline_mem_sections(unsigned long unsigned long pfn; for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) { - unsigned long section_nr = pfn_to_section_nr(start_pfn); + unsigned long section_nr = pfn_to_section_nr(pfn); struct mem_section *ms; /* _ Patches currently in -mm which might be from pasha.tatashin(a)oracle.com are mm-sections-are-not-offlined-during-memory-hotremove.patch sparc64-ng4-memset-32-bits-overflow.patch

7 years, 7 months

1
0
0 0

+ z3fold-fix-reclaim-lock-ups.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: z3fold: fix reclaim lock-ups has been added to the -mm tree. Its filename is z3fold-fix-reclaim-lock-ups.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/z3fold-fix-reclaim-lock-ups.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/z3fold-fix-reclaim-lock-ups.patch 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: Vitaly Wool <vitalywool(a)gmail.com> Subject: z3fold: fix reclaim lock-ups Do not try to optimize in-page object layout while the page is under reclaim. This fixes lock-ups on reclaim and improves reclaim performance at the same time. Link: http://lkml.kernel.org/r/20180430125800.444cae9706489f412ad12621@gmail.com Signed-off-by: Vitaly Wool <vitaly.vul(a)sony.com> Reported-by: Guenter Roeck <linux(a)roeck-us.net> Tested-by: Guenter Roeck <linux(a)roeck-us.net> Cc: <Oleksiy.Avramchenko(a)sony.com> Cc: Matthew Wilcox <mawilcox(a)microsoft.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/z3fold.c | 42 ++++++++++++++++++++++++++++++------------ 1 file changed, 30 insertions(+), 12 deletions(-) diff -puN mm/z3fold.c~z3fold-fix-reclaim-lock-ups mm/z3fold.c --- a/mm/z3fold.c~z3fold-fix-reclaim-lock-ups +++ a/mm/z3fold.c @@ -144,7 +144,8 @@ enum z3fold_page_flags { PAGE_HEADLESS = 0, MIDDLE_CHUNK_MAPPED, NEEDS_COMPACTING, - PAGE_STALE + PAGE_STALE, + UNDER_RECLAIM }; /***************** @@ -173,6 +174,7 @@ static struct z3fold_header *init_z3fold clear_bit(MIDDLE_CHUNK_MAPPED, &page->private); clear_bit(NEEDS_COMPACTING, &page->private); clear_bit(PAGE_STALE, &page->private); + clear_bit(UNDER_RECLAIM, &page->private); spin_lock_init(&zhdr->page_lock); kref_init(&zhdr->refcount); @@ -756,6 +758,10 @@ static void z3fold_free(struct z3fold_po atomic64_dec(&pool->pages_nr); return; } + if (test_bit(UNDER_RECLAIM, &page->private)) { + z3fold_page_unlock(zhdr); + return; + } if (test_and_set_bit(NEEDS_COMPACTING, &page->private)) { z3fold_page_unlock(zhdr); return; @@ -840,6 +846,8 @@ static int z3fold_reclaim_page(struct z3 kref_get(&zhdr->refcount); list_del_init(&zhdr->buddy); zhdr->cpu = -1; + set_bit(UNDER_RECLAIM, &page->private); + break; } list_del_init(&page->lru); @@ -887,25 +895,35 @@ static int z3fold_reclaim_page(struct z3 goto next; } next: - spin_lock(&pool->lock); if (test_bit(PAGE_HEADLESS, &page->private)) { if (ret == 0) { - spin_unlock(&pool->lock); free_z3fold_page(page); return 0; } - } else if (kref_put(&zhdr->refcount, release_z3fold_page)) { - atomic64_dec(&pool->pages_nr); + spin_lock(&pool->lock); + list_add(&page->lru, &pool->lru); + spin_unlock(&pool->lock); + } else { + z3fold_page_lock(zhdr); + clear_bit(UNDER_RECLAIM, &page->private); + if (kref_put(&zhdr->refcount, + release_z3fold_page_locked)) { + atomic64_dec(&pool->pages_nr); + return 0; + } + /* + * if we are here, the page is still not completely + * free. Take the global pool lock then to be able + * to add it back to the lru list + */ + spin_lock(&pool->lock); + list_add(&page->lru, &pool->lru); spin_unlock(&pool->lock); - return 0; + z3fold_page_unlock(zhdr); } - /* - * Add to the beginning of LRU. - * Pool lock has to be kept here to ensure the page has - * not already been released - */ - list_add(&page->lru, &pool->lru); + /* We started off locked to we need to lock the pool back */ + spin_lock(&pool->lock); } spin_unlock(&pool->lock); return -EAGAIN; _ Patches currently in -mm which might be from vitalywool(a)gmail.com are z3fold-fix-reclaim-lock-ups.patch

7 years, 7 months

1
0
0 0

[PATCH] drm/vc4: Make sure vc4_bo_{inc, dec}_usecnt() calls are balanced

by Boris Brezillon

Commit b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl") introduced a mechanism to mark some BOs as purgeable to allow the driver to drop them under memory pressure. In order to implement this feature we had to add a mechanism to mark BOs as currently used by a piece of hardware which materialized through the ->usecnt counter. Plane code is supposed to increment usecnt when it attaches a BO to a plane and decrement it when it's done with this BO, which was done in the ->prepare_fb() and ->cleanup_fb() hooks. The problem is, async page flip logic does not go through the regular atomic update path, and ->prepare_fb() and ->cleanup_fb() are not called in this case. Fix that by manually calling vc4_bo_{inc,dec}_usecnt() in the async-page-flip path. Note that all this should go away as soon as we get generic async page flip support in the core, in the meantime, this fix should do the trick. Fixes: b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl") Reported-by: Peter Robinson <pbrobinson(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> --- drivers/gpu/drm/vc4/vc4_crtc.c | 46 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c index 83d3b7912fc2..c8650bbcbcb3 100644 --- a/drivers/gpu/drm/vc4/vc4_crtc.c +++ b/drivers/gpu/drm/vc4/vc4_crtc.c @@ -741,6 +741,7 @@ static irqreturn_t vc4_crtc_irq_handler(int irq, void *data) struct vc4_async_flip_state { struct drm_crtc *crtc; struct drm_framebuffer *fb; + struct drm_framebuffer *old_fb; struct drm_pending_vblank_event *event; struct vc4_seqno_cb cb; @@ -770,6 +771,23 @@ vc4_async_page_flip_complete(struct vc4_seqno_cb *cb) drm_crtc_vblank_put(crtc); drm_framebuffer_put(flip_state->fb); + + /* Decrement the BO usecnt in order to keep the inc/dec calls balanced + * when the planes are updated through the async update path. + * FIXME: we should move to generic async-page-flip when it's + * available, so that we can get rid of this hand-made cleanup_fb() + * logic. + */ + if (flip_state->old_fb) { + struct drm_gem_cma_object *cma_bo; + struct vc4_bo *bo; + + cma_bo = drm_fb_cma_get_gem_obj(flip_state->old_fb, 0); + bo = to_vc4_bo(&cma_bo->base); + vc4_bo_dec_usecnt(bo); + drm_framebuffer_put(flip_state->old_fb); + } + kfree(flip_state); up(&vc4->async_modeset); @@ -794,9 +812,22 @@ static int vc4_async_page_flip(struct drm_crtc *crtc, struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 0); struct vc4_bo *bo = to_vc4_bo(&cma_bo->base); + /* Increment the BO usecnt here, so that we never end up with an + * unbalanced number of vc4_bo_{dec,inc}_usecnt() calls when the + * plane is later updated through the non-async path. + * FIXME: we should move to generic async-page-flip when it's + * available, so that we can get rid of this hand-made prepare_fb() + * logic. + */ + ret = vc4_bo_inc_usecnt(bo); + if (ret) + return ret; + flip_state = kzalloc(sizeof(*flip_state), GFP_KERNEL); - if (!flip_state) + if (!flip_state) { + vc4_bo_dec_usecnt(bo); return -ENOMEM; + } drm_framebuffer_get(fb); flip_state->fb = fb; @@ -807,10 +838,23 @@ static int vc4_async_page_flip(struct drm_crtc *crtc, ret = down_interruptible(&vc4->async_modeset); if (ret) { drm_framebuffer_put(fb); + vc4_bo_dec_usecnt(bo); kfree(flip_state); return ret; } + /* Save the current FB before it's replaced by the new one in + * drm_atomic_set_fb_for_plane(). We'll need the old FB in + * vc4_async_page_flip_complete() to decrement the BO usecnt and keep + * it consistent. + * FIXME: we should move to generic async-page-flip when it's + * available, so that we can get rid of this hand-made cleanup_fb() + * logic. + */ + flip_state->old_fb = plane->state->fb; + if (flip_state->old_fb) + drm_framebuffer_get(flip_state->old_fb); + WARN_ON(drm_crtc_vblank_get(crtc) != 0); /* Immediately update the plane's legacy fb pointer, so that later -- 2.14.1

7 years, 7 months

2
1
0 0

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

by Dmitry Torokhov

On Thu, Apr 26, 2018 at 06:45:32AM -0700, Guenter Roeck wrote: > On Wed, Apr 25, 2018 at 10:37 PM, Vittorio Gambaletta (VittGam) < > linuxbugs(a)vittgam.net> wrote: > > > Hello, > > > > On 26/04/2018 00:57:34 CEST, Dmitry Torokhov wrote: > > > On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry Torokhov wrote: > > >> On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam) > > wrote: > > >> > This patch adds the correct platform data information for the Caroline > > >> > Chromebook, so that the mouse button does not get stuck in pressed > > state > > >> > after the first click. > > >> > > > >> > The Samus button keymap and platform data definition are the correct > > >> > ones for Caroline, so they have been reused here. > > >> > > > >> > v2: updated patch offset after 20180409 changes. > > >> > > > >> > Cc: stable(a)vger.kernel.org > > >> > Signed-off-by: Vittorio Gambaletta <linuxbugs(a)vittgam.net> > > >> > Signed-off-by: Salvatore Bellizzi <lkml(a)seppia.net> > > >> > > > >> > > >> Applied, thank you. > > >> > > >> > --- > > >> > > > >> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c > > >> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c > > >> > @@ -3035,6 +3035,15 @@ > > >> > .driver_data = samus_platform_data, > > >> > }, > > >> > { > > >> > + /* Samsung Chromebook Pro */ > > >> > + .ident = "Samsung Chromebook Pro", > > >> > + .matches = { > > >> > + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"), > > > > > > I've been alerted that shipping BIOS has vendor not capitalized; where > > > did you get the firmware that has vendor all capitals? > > > > Upstream coreboot and mrchromebox's coreboot, which do support loading > > Linux > > natively or with UEFI, both use capitalized GOOGLE as DMI System Vendor > > as far as I know. > > > > By the way, the shipping BIOS (coreboot customized by Google) does not > > support > > mainline Linux natively (eg. without seabios and nasty tricks), but only > > Chromium OS, which for Caroline is an old 3.something fork of Linux, so > > this > > patch does not really apply to Chromium OS or to Linux running on shipping > > BIOS. > > > > Can you provide details or a pointer to it ? The mainline kernel boots > fine for me (with a ChromeOS distribution), with the exception of the > Google/GOOGLE problem. > > > > Anyway if I recall correctly, the DMI System Vendor should be GOOGLE in > > Google's coreboot for Caroline too, but I'm not 100% sure and cannot check > > right now. > > > > > FWIW, the DMI system vendor is "Google" in my Caroline. I'll dig up > configuration files later today - maybe it was changed to "GOOGLE" at some > point and I have an old Bios in my system. I believe all shipping BIOSes use "Google" as vendor, as it is what is specified in src/mainboard/google/Kconfig::MAINBOARD_VENDOR and our configs/build scripts do not override it. I do not know why we have this difference. > > Thanks, > Guenter > > By the way please note that this is the DMI System Vendor and not the DMI > > BIOS version string, which indeed starts with "Google_" in the shipping > > BIOS > > (but not in coreboot, see f56db262e46d3368ee4e5c9e19797853cab382cd). Hmm, I just tried checking out tree from https://review.coreboot.org/coreboot.git and do not see this commit: dtor@dtor-ws:~/coreboot $ git show f56db262e46d3368ee4e5c9e19797853cab382cd fatal: bad object f56db262e46d3368ee4e5c9e19797853cab382cd dtor@dtor-ws:~/coreboot $ git log --oneline -1 HEAD 82d0f91420 (HEAD -> master, origin/master, origin/HEAD) soc/intel/apollolake: enable exception handling in every stage for glk Anyway, if you are overriding the shipping BIOS, then please adjust coreboot to use device-tree compatible bindings (via PRP0001 HID and _DSD properties - you can check out bindings for PENH device in Caroline to see how they can be used). This way we would not need to breed DMI quirks. Thanks. -- Dmitry

7 years, 7 months

2
3
0 0

[PATCH 0/2] musb fixes for v4.17-rc4

by Bin Liu

Hi Greg, Here are musb fixes for v4.17-rc4 to fix two NULL pointer dereference cases. Please let me know if any change is needed. Regards, -Bin. ---- Bin Liu (2): usb: musb: host: fix potential NULL pointer dereference usb: musb: trace: fix NULL pointer dereference in musb_g_tx() drivers/usb/musb/musb_gadget.c | 3 ++- drivers/usb/musb/musb_host.c | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) -- 1.9.1

7 years, 7 months

2
6
0 0

[PATCH] perf session: Fix undeclared 'oe'

by Murilo Opsfelder Araujo

Using linux-3.18.y branch, perf build fails with the following: $ make -s -j16 -C tools/perf V=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_LIBNUMA=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=/usr DESTDIR=/tmp/builddir/build all [...] util/session.c: In function ‘__perf_session__process_pipe_events’: util/session.c:1093:36: error: ‘oe’ undeclared (first use in this function) ordered_events__set_copy_on_queue(oe, true); ^ util/session.c:1093:36: note: each undeclared identifier is reported only once for each function it appears in This patch fixes it for linux-3.18.y branch. Fixes: 95b33b99cdd6 ("perf inject: Copy events when reordering events in pipe mode") Cc: <stable(a)vger.kernel.org> # 3.18.x Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: David Carrillo-Cisneros <davidcc(a)google.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: He Kuang <hekuang(a)huawei.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Paul Mackerras <paulus(a)samba.org> Cc: Paul Turner <pjt(a)google.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Sasha Levin <alexander.levin(a)microsoft.com> Cc: Simon Que <sque(a)chromium.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Wang Nan <wangnan0(a)huawei.com> Signed-off-by: Murilo Opsfelder Araujo <muriloo(a)linux.ibm.com> --- tools/perf/util/session.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c index dc3d3b1b813e..c2d4a7ec40df 100644 --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -1073,6 +1073,7 @@ volatile int session_done; static int __perf_session__process_pipe_events(struct perf_session *session, struct perf_tool *tool) { + struct ordered_events *oe = &session->ordered_events; int fd = perf_data_file__fd(session->file); union perf_event *event; uint32_t size, cur_size = 0; -- 2.14.3

7 years, 7 months

3
6
0 0

Re: [PATCH 4.4 12/50] KVM: s390: wire up bpb feature

by Christian Borntraeger

On 04/27/2018 03:58 PM, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Martin Schwidefsky <schwidefsky(a)de.ibm.com> > > > From: Christian Borntraeger <borntraeger(a)de.ibm.com> > > [ Upstream commit 35b3fde6203b932b2b1a5b53b3d8808abc9c4f60 ] > > The new firmware interfaces for branch prediction behaviour changes > are transparently available for the guest. Nevertheless, there is > new state attached that should be migrated and properly resetted. > Provide a mechanism for handling reset, migration and VSIE. > > Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> > Reviewed-by: David Hildenbrand <david(a)redhat.com> > Reviewed-by: Cornelia Huck <cohuck(a)redhat.com> > [Changed capability number to 152. - Radim] > Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> > Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Something went wrong during the backport of this to 4.4 [...] > --- > arch/s390/include/asm/kvm_host.h | 3 ++- > arch/s390/include/uapi/asm/kvm.h | 3 +++ > arch/s390/kvm/kvm-s390.c | 13 ++++++++++++- > include/uapi/linux/kvm.h | 1 + > 4 files changed, 18 insertions(+), 2 deletions(-) > > --- a/arch/s390/include/asm/kvm_host.h > +++ b/arch/s390/include/asm/kvm_host.h > @@ -1286,7 +1291,6 @@ void kvm_arch_vcpu_load(struct kvm_vcpu > if (test_fp_ctl(current->thread.fpu.fpc)) > /* User space provided an invalid FPC, let's clear it */ > current->thread.fpu.fpc = 0; > - unrelated whitespace change > save_access_regs(vcpu->arch.host_acrs); > restore_access_regs(vcpu->run->s.regs.acrs); > gmap_enable(vcpu->arch.gmap); > @@ -1327,6 +1331,7 @@ static void kvm_s390_vcpu_initial_reset( > current->thread.fpu.fpc = 0; > vcpu->arch.sie_block->gbea = 1; > vcpu->arch.sie_block->pp = 0; > + vcpu->arch.sie_block->fpf &= ~FPF_BPBC; > vcpu->arch.pfault_token = KVM_S390_PFAULT_TOKEN_INVALID; > kvm_clear_async_pf_completion_queue(vcpu); > if (!kvm_s390_user_cpu_state_ctrl(vcpu->kvm)) > @@ -2162,6 +2167,7 @@ static void store_regs(struct kvm_vcpu * > kvm_run->s.regs.pft = vcpu->arch.pfault_token; > kvm_run->s.regs.pfs = vcpu->arch.pfault_select; > kvm_run->s.regs.pfc = vcpu->arch.pfault_compare; > + kvm_run->s.regs.bpbc = (vcpu->arch.sie_block->fpf & FPF_BPBC) == FPF_BPBC; > } > > int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) > @@ -2194,6 +2200,11 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v > kvm_run->exit_reason = KVM_EXIT_INTR; > rc = -EINTR; > } > + if ((kvm_run->kvm_dirty_regs & KVM_SYNC_BPBC) && > + test_kvm_facility(vcpu->kvm, 82)) { > + vcpu->arch.sie_block->fpf &= ~FPF_BPBC; > + vcpu->arch.sie_block->fpf |= kvm_run->s.regs.bpbc ? FPF_BPBC : 0; > + } > This looks misplaced and should go into the sync_regs function.

7 years, 7 months

3
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror