November 2018 - Linux-stable-mirror

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.133 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Oct 13 15:25:09 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.133-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.9.133-rc1 Andy Lutomirski <luto(a)kernel.org> x86/fpu: Finish excising 'eagerfpu' Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "perf: sync up x86/.../cpufeatures.h" Rik van Riel <riel(a)redhat.com> x86/fpu: Remove struct fpu::counter Andy Lutomirski <luto(a)kernel.org> x86/fpu: Remove use_eager_fpu() Gao Feng <gfree.wind(a)vip.163.com> ebtables: arpreply: Add the standard target sanity check Zhi Chen <zhichen(a)codeaurora.org> ath10k: fix scan crash due to incorrect length calculation Frederic Weisbecker <fweisbec(a)gmail.com> sched/cputime: Fix ksoftirqd cputime accounting regression Frederic Weisbecker <fweisbec(a)gmail.com> sched/cputime: Increment kcpustat directly on irqtime account Frederic Weisbecker <fweisbec(a)gmail.com> sched/cputime: Convert kcpustat to nsecs Richard Weinberger <richard(a)nod.at> ubifs: Check for name being NULL while mounting Cong Wang <xiyou.wangcong(a)gmail.com> ucma: fix a use-after-free in ucma_resolve_ip() Chao Yu <yuchao0(a)huawei.com> f2fs: fix invalid memory access Feng Tang <feng.tang(a)intel.com> x86/mm: Expand static page table for fixmap space Vineet Gupta <vgupta(a)synopsys.com> ARC: clone syscall to setp r25 as thread pointer Michal Suchanek <msuchanek(a)suse.de> powerpc/fadump: Return error when fadump registration fails Yu Wang <yyuwang(a)codeaurora.org> ath10k: fix kernel panic issue during pci probe Carl Huang <cjhuang(a)codeaurora.org> ath10k: fix use-after-free in ath10k_wmi_cmd_send_nowait Prateek Sood <prsood(a)codeaurora.org> cgroup: Fix deadlock in cpu hotplug path Theodore Ts'o <tytso(a)mit.edu> ext4: always verify the magic number in xattr blocks Theodore Ts'o <tytso(a)mit.edu> ext4: add corruption check in ext4_xattr_set_entry() Guenter Roeck <linux(a)roeck-us.net> of: unittest: Disable interrupt node tests for old world MAC systems Dmitry Safonov <dima(a)arista.com> tty: Drop tty->count on tty_reopen() failure Johan Hovold <johan(a)kernel.org> USB: serial: simple: add Motorola Tetra MTP6550 id Chunfeng Yun <chunfeng.yun(a)mediatek.com> usb: xhci-mtk: resume USB3 roothub first Mathias Nyman <mathias.nyman(a)linux.intel.com> xhci: Add missing CAS workaround for Intel Sunrise Point xHCI Mike Snitzer <snitzer(a)redhat.com> dm cache: fix resize crash if user doesn't reload cache table Joe Thornber <ejt(a)redhat.com> dm cache metadata: ignore hints array being too small during resize Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> PM / core: Clear the direct_complete flag on errors Felix Fietkau <nbd(a)nbd.name> mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys Daniel Drake <drake(a)endlessm.com> PCI: Reprogram bridge prefetch registers on resume Andy Lutomirski <luto(a)kernel.org> x86/vdso: Fix vDSO syscall fallback asm constraint regression Andy Lutomirski <luto(a)kernel.org> x86/vdso: Fix asm constraints on vDSO syscall fallbacks Jan Beulich <JBeulich(a)suse.com> xen-netback: fix input validation in xenvif_set_hash_mapping() Tomi Valkeinen <tomi.valkeinen(a)ti.com> fbdev/omapfb: fix omapfb_memory_read infoleak Jann Horn <jannh(a)google.com> mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly ------------- Diffstat: Documentation/kernel-parameters.txt | 6 -- Makefile | 4 +- arch/arc/kernel/process.c | 20 +++++++ arch/powerpc/kernel/fadump.c | 23 +++++--- arch/s390/appldata/appldata_os.c | 16 +++--- arch/x86/crypto/crc32c-intel_glue.c | 17 ++---- arch/x86/entry/vdso/vclock_gettime.c | 26 +++++---- arch/x86/include/asm/cpufeatures.h | 1 - arch/x86/include/asm/fixmap.h | 10 ++++ arch/x86/include/asm/fpu/internal.h | 37 +----------- arch/x86/include/asm/fpu/types.h | 34 ----------- arch/x86/include/asm/pgtable_64.h | 3 +- arch/x86/include/asm/trace/fpu.h | 5 +- arch/x86/kernel/fpu/core.c | 39 ++----------- arch/x86/kernel/fpu/signal.c | 8 +-- arch/x86/kernel/fpu/xstate.c | 9 --- arch/x86/kernel/head_64.S | 16 ++++-- arch/x86/kvm/cpuid.c | 4 +- arch/x86/kvm/x86.c | 10 ---- arch/x86/mm/pgtable.c | 9 +++ arch/x86/mm/pkeys.c | 3 +- arch/x86/xen/mmu.c | 8 ++- drivers/base/power/main.c | 5 +- drivers/cpufreq/cpufreq.c | 6 +- drivers/cpufreq/cpufreq_governor.c | 2 +- drivers/cpufreq/cpufreq_stats.c | 1 - drivers/infiniband/core/ucma.c | 2 + drivers/macintosh/rack-meter.c | 2 +- drivers/md/dm-cache-metadata.c | 4 +- drivers/md/dm-cache-target.c | 9 ++- drivers/net/wireless/ath/ath10k/debug.c | 12 +++- drivers/net/wireless/ath/ath10k/trace.h | 12 ++-- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 8 +-- drivers/net/wireless/ath/ath10k/wmi.c | 2 +- drivers/net/xen-netback/hash.c | 12 ++-- drivers/of/unittest.c | 28 ++++++--- drivers/pci/pci.c | 27 ++++++--- drivers/tty/tty_io.c | 11 +++- drivers/usb/host/xhci-mtk.c | 4 +- drivers/usb/host/xhci-pci.c | 2 + drivers/usb/serial/usb-serial-simple.c | 3 +- drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c | 5 +- fs/ext4/xattr.c | 28 +++++---- fs/f2fs/checkpoint.c | 9 +-- fs/proc/stat.c | 68 +++++++++++----------- fs/proc/uptime.c | 7 +-- fs/ubifs/super.c | 3 + include/linux/netfilter_bridge/ebtables.h | 5 ++ kernel/cgroup.c | 6 +- kernel/sched/cpuacct.c | 2 +- kernel/sched/cputime.c | 75 +++++++++++-------------- kernel/sched/sched.h | 12 +++- mm/vmstat.c | 3 + net/bridge/netfilter/ebt_arpreply.c | 3 + net/mac80211/cfg.c | 2 +- tools/arch/x86/include/asm/cpufeatures.h | 1 - 56 files changed, 335 insertions(+), 354 deletions(-)

5 years, 6 months

8
45
0 0

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

by Robert Foss

+stable On 2018-11-02 13:13, Robert Foss wrote: > 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> > --- > 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); >

5 years, 6 months

2
1
0 0

[PATCH v2 1/2] ARM: cpuidle: Don't register the driver when back-end init returns -ENXIO

by Ulf Hansson

There's no point to register the cpuidle driver for the current CPU, when the initialization of the arch specific back-end data fails by returning -ENXIO. Instead, let's re-order the sequence to its original flow, by first trying to initialize the back-end part and then act accordingly on the returned error code. Additionally, let's print the error message, no matter of what error code that was returned. Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Fixes: a0d46a3dfdc3 ("ARM: cpuidle: Register per cpuidle device") Cc: <stable(a)vger.kernel.org> # v4.19+ --- Changes in v2: - Added a fixes and a stable tag. --- drivers/cpuidle/cpuidle-arm.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c index 073557f433eb..df564d783216 100644 --- a/drivers/cpuidle/cpuidle-arm.c +++ b/drivers/cpuidle/cpuidle-arm.c @@ -103,13 +103,6 @@ static int __init arm_idle_init_cpu(int cpu) goto out_kfree_drv; } - ret = cpuidle_register_driver(drv); - if (ret) { - if (ret != -EBUSY) - pr_err("Failed to register cpuidle driver\n"); - goto out_kfree_drv; - } - /* * Call arch CPU operations in order to initialize * idle states suspend back-end specific data @@ -117,15 +110,20 @@ static int __init arm_idle_init_cpu(int cpu) ret = arm_cpuidle_init(cpu); /* - * Skip the cpuidle device initialization if the reported + * Allow the initialization to continue for other CPUs, if the reported * failure is a HW misconfiguration/breakage (-ENXIO). */ - if (ret == -ENXIO) - return 0; - if (ret) { pr_err("CPU %d failed to init idle CPU ops\n", cpu); - goto out_unregister_drv; + ret = ret == -ENXIO ? 0 : ret; + goto out_kfree_drv; + } + + ret = cpuidle_register_driver(drv); + if (ret) { + if (ret != -EBUSY) + pr_err("Failed to register cpuidle driver\n"); + goto out_kfree_drv; } dev = kzalloc(sizeof(*dev), GFP_KERNEL); -- 2.17.1

5 years, 6 months

2
1
0 0

Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

by Stephen Boyd

Quoting Dean Wallace (2018-10-25 16:25:17) > I have found a regression in 4.18.15 that means I lose sound on my old > Toshiba Chromebook 2 (Swanky). My system details are:- > > Toshiba Chromebook (Swanky) > MrChromebox UEFI coreboot > Arch Linux running latest alsa/pulseaudio > > Upgraded kernel from 4.18.14 to 4.18.15 and lost all sound output. By > output I mean, the card is still detected, the module loaded, all apps > showing sound is being playing, but no actual audible sound comes > through. Upgraded to 4.18.16 same issue. > > Dug around and found Upstream commit 648e921888ad96ea3dc922739e96716ad3225d7f > clk: x86: Stop marking clocks as CLK_IS_CRITICAL > "This commit removes the CLK_IS_CRITICAL marking, fixing Cherry Trail > devices not being able to reach S0i3 greatly decreasing their battery > drain when suspended." > > I reverted it and compiled 4.18.16 and have sound back again. Could > this be looked into, with possibility of fix. > Thanks for the bug report. I'm adding some people involved in the commit you mention is causing audio regressions. The best plan is to probably revert the commit from the 4.18 linux stable tree. Or there may be another patch missing that would be useful to make this backported patch work. Hopefully Hans or Andy knows.

5 years, 6 months

5
35
0 0

[PATCH 14/15] iwlwifi: add new cards for 9560, 9462, 9461 and killer series

by Luca Coelho

From: Ihab Zhaika <ihab.zhaika(a)intel.com> add few PCI ID'S for 9560, 9462, 9461 and killer series. Cc: stable(a)vger.kernel.org Signed-off-by: Ihab Zhaika <ihab.zhaika(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 50 +++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c index 9e015212c2c0..8d4711590dfc 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -513,6 +513,56 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x24FD, 0x9074, iwl8265_2ac_cfg)}, /* 9000 Series */ + {IWL_PCI_DEVICE(0x02F0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0060, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x1551, iwl9560_killer_s_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x1552, iwl9560_killer_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x2034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x02F0, 0x42A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0060, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x1551, iwl9560_killer_s_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x1552, iwl9560_killer_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x2030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x2034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x4234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x06F0, 0x42A4, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x0010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0014, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0018, iwl9260_2ac_cfg)}, -- 2.19.1

5 years, 6 months

1
0
0 0

[git:media_tree/fixes] media: v4l: event: Prevent freeing event subscriptions while accessed

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: v4l: event: Prevent freeing event subscriptions while accessed Author: Sakari Ailus <sakari.ailus(a)linux.intel.com> Date: Tue Sep 11 05:32:37 2018 -0400 The event subscriptions are added to the subscribed event list while holding a spinlock, but that lock is subsequently released while still accessing the subscription object. This makes it possible to unsubscribe the event --- and freeing the subscription object's memory --- while the subscription object is simultaneously accessed. Prevent this by adding a mutex to serialise the event subscription and unsubscription. This also gives a guarantee to the callback ops that the add op has returned before the del op is called. This change also results in making the elems field less special: subscriptions are only added to the event list once they are fully initialised. Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Reviewed-by: Hans Verkuil <hans.verkuil(a)cisco.com> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: stable(a)vger.kernel.org # for 4.14 and up Fixes: c3b5b0241f62 ("V4L/DVB: V4L: Events: Add backend") Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/v4l2-core/v4l2-event.c | 38 +++++++++++++++++++----------------- drivers/media/v4l2-core/v4l2-fh.c | 2 ++ include/media/v4l2-fh.h | 4 ++++ 3 files changed, 26 insertions(+), 18 deletions(-) --- diff --git a/drivers/media/v4l2-core/v4l2-event.c b/drivers/media/v4l2-core/v4l2-event.c index 127fe6eb91d9..a3ef1f50a4b3 100644 --- a/drivers/media/v4l2-core/v4l2-event.c +++ b/drivers/media/v4l2-core/v4l2-event.c @@ -115,14 +115,6 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh, const struct v4l2_event *e if (sev == NULL) return; - /* - * If the event has been added to the fh->subscribed list, but its - * add op has not completed yet elems will be 0, treat this as - * not being subscribed. - */ - if (!sev->elems) - return; - /* Increase event sequence number on fh. */ fh->sequence++; @@ -208,6 +200,7 @@ int v4l2_event_subscribe(struct v4l2_fh *fh, struct v4l2_subscribed_event *sev, *found_ev; unsigned long flags; unsigned i; + int ret = 0; if (sub->type == V4L2_EVENT_ALL) return -EINVAL; @@ -225,31 +218,36 @@ int v4l2_event_subscribe(struct v4l2_fh *fh, sev->flags = sub->flags; sev->fh = fh; sev->ops = ops; + sev->elems = elems; + + mutex_lock(&fh->subscribe_lock); spin_lock_irqsave(&fh->vdev->fh_lock, flags); found_ev = v4l2_event_subscribed(fh, sub->type, sub->id); - if (!found_ev) - list_add(&sev->list, &fh->subscribed); spin_unlock_irqrestore(&fh->vdev->fh_lock, flags); if (found_ev) { + /* Already listening */ kvfree(sev); - return 0; /* Already listening */ + goto out_unlock; } if (sev->ops && sev->ops->add) { - int ret = sev->ops->add(sev, elems); + ret = sev->ops->add(sev, elems); if (ret) { - sev->ops = NULL; - v4l2_event_unsubscribe(fh, sub); - return ret; + kvfree(sev); + goto out_unlock; } } - /* Mark as ready for use */ - sev->elems = elems; + spin_lock_irqsave(&fh->vdev->fh_lock, flags); + list_add(&sev->list, &fh->subscribed); + spin_unlock_irqrestore(&fh->vdev->fh_lock, flags); - return 0; +out_unlock: + mutex_unlock(&fh->subscribe_lock); + + return ret; } EXPORT_SYMBOL_GPL(v4l2_event_subscribe); @@ -288,6 +286,8 @@ int v4l2_event_unsubscribe(struct v4l2_fh *fh, return 0; } + mutex_lock(&fh->subscribe_lock); + spin_lock_irqsave(&fh->vdev->fh_lock, flags); sev = v4l2_event_subscribed(fh, sub->type, sub->id); @@ -305,6 +305,8 @@ int v4l2_event_unsubscribe(struct v4l2_fh *fh, if (sev && sev->ops && sev->ops->del) sev->ops->del(sev); + mutex_unlock(&fh->subscribe_lock); + kvfree(sev); return 0; diff --git a/drivers/media/v4l2-core/v4l2-fh.c b/drivers/media/v4l2-core/v4l2-fh.c index 3895999bf880..c91a7bd3ecfc 100644 --- a/drivers/media/v4l2-core/v4l2-fh.c +++ b/drivers/media/v4l2-core/v4l2-fh.c @@ -45,6 +45,7 @@ void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev) INIT_LIST_HEAD(&fh->available); INIT_LIST_HEAD(&fh->subscribed); fh->sequence = -1; + mutex_init(&fh->subscribe_lock); } EXPORT_SYMBOL_GPL(v4l2_fh_init); @@ -90,6 +91,7 @@ void v4l2_fh_exit(struct v4l2_fh *fh) return; v4l_disable_media_source(fh->vdev); v4l2_event_unsubscribe_all(fh); + mutex_destroy(&fh->subscribe_lock); fh->vdev = NULL; } EXPORT_SYMBOL_GPL(v4l2_fh_exit); diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h index ea73fef8bdc0..8586cfb49828 100644 --- a/include/media/v4l2-fh.h +++ b/include/media/v4l2-fh.h @@ -38,10 +38,13 @@ struct v4l2_ctrl_handler; * @prio: priority of the file handler, as defined by &enum v4l2_priority * * @wait: event' s wait queue + * @subscribe_lock: serialise changes to the subscribed list; guarantee that + * the add and del event callbacks are orderly called * @subscribed: list of subscribed events * @available: list of events waiting to be dequeued * @navailable: number of available events at @available list * @sequence: event sequence number + * * @m2m_ctx: pointer to &struct v4l2_m2m_ctx */ struct v4l2_fh { @@ -52,6 +55,7 @@ struct v4l2_fh { /* Events */ wait_queue_head_t wait; + struct mutex subscribe_lock; struct list_head subscribed; struct list_head available; unsigned int navailable;

5 years, 6 months

1
0
0 0

Re: [Xen-devel] [PATCH] xen: remove size limit of privcmd-buf mapping interface

by Juergen Gross

On 02/11/2018 08:26, Jan Beulich wrote: >>>> On 01.11.18 at 17:27, <jgross(a)suse.com> wrote: >> On 01/11/2018 16:50, Jan Beulich wrote: >>>>>> Juergen Gross <jgross(a)suse.com> 11/01/18 3:23 PM >>> >>>> On 01/11/2018 15:18, Jan Beulich wrote: >>>>>>>> Juergen Gross <jgross(a)suse.com> 11/01/18 1:34 PM >>> >>>>>> Currently the size of hypercall buffers allocated via >>>>>> /dev/xen/hypercall is limited to a default of 64 memory pages. For live >>>>>> migration of guests this might be too small as the page dirty bitmask >>>>>> needs to be sized according to the size of the guest. This means >>>>>> migrating a 8GB sized guest is already exhausting the default buffer >>>>>> size for the dirty bitmap. >>>>>> >>>>>> There is no sensible way to set a sane limit, so just remove it >>>>>> completely. The device node's usage is limited to root anyway, so there >>>>>> is no additional DOS scenario added by allowing unlimited buffers. >>>>> >>>>> But is this setting of permissions what we want long term? What about a >>>>> de-privileged qemu, which still needs to be able to issue at least dm-op >>>>> hypercalls? >>>> >>>> Wouldn't that qemu have opened the node while still being privileged? >>> >>> Possibly, but how does this help? As soon as it's unprivileged it must not >>> be able to hog resources anymore. >>> >>> Anyway, with Andrew's reply my point may be irrelevant, but I have to >>> admit I'm not entirely sure. >> >> I guess we want Xen tools to close /dev/xen/hypercall (or more precise: >> don't dup2() it) when qemu is de-privileging itself. This will make it >> very clear that it can't hog memory via mmap(). >> >> When you are fine with that I'll send a Xen patch for this. > > If that doesn't prevent the process from making the hypercalls it > is permitted to do (I have to admit I don't recall if there are any > still needed besides the dmop ones), sure. Turns out that is already done: the restrict_all callback of libxencall will associate /dev/null with the file descriptor of /dev/xen/hypercall. Juergen

5 years, 6 months

1
0
0 0

[PATCH AUTOSEL 4.4 01/25] xfrm: Validate address prefix lengths in the xfrm selector.

by Sasha Levin

From: Steffen Klassert <steffen.klassert(a)secunet.com> [ Upstream commit 07bf7908950a8b14e81aa1807e3c667eab39287a ] We don't validate the address prefix lengths in the xfrm selector we got from userspace. This can lead to undefined behaviour in the address matching functions if the prefix is too big for the given address family. Fix this by checking the prefixes and refuse SA/policy insertation when a prefix is invalid. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Air Icy <icytxw(a)gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/xfrm/xfrm_user.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index a9b4491a3cc4..c2e98dcba9fe 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -151,10 +151,16 @@ static int verify_newsa_info(struct xfrm_usersa_info *p, err = -EINVAL; switch (p->family) { case AF_INET: + if (p->sel.prefixlen_d > 32 || p->sel.prefixlen_s > 32) + goto out; + break; case AF_INET6: #if IS_ENABLED(CONFIG_IPV6) + if (p->sel.prefixlen_d > 128 || p->sel.prefixlen_s > 128) + goto out; + break; #else err = -EAFNOSUPPORT; @@ -1312,10 +1318,16 @@ static int verify_newpolicy_info(struct xfrm_userpolicy_info *p) switch (p->sel.family) { case AF_INET: + if (p->sel.prefixlen_d > 32 || p->sel.prefixlen_s > 32) + return -EINVAL; + break; case AF_INET6: #if IS_ENABLED(CONFIG_IPV6) + if (p->sel.prefixlen_d > 128 || p->sel.prefixlen_s > 128) + return -EINVAL; + break; #else return -EAFNOSUPPORT; -- 2.17.1

5 years, 6 months

2
25
0 0

Re: Patch "bridge: do not add port to router list when receives query with source 0.0.0.0" has been added to the 4.18-stable tree

by Hangbin Liu

On Fri, Nov 02, 2018 at 06:13:17AM +0100, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > bridge: do not add port to router list when receives query with source 0.0.0.0 > > to the 4.18-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: > bridge-do-not-add-port-to-router-list-when-receives-query-with-source-0.0.0.0.patch > and it can be found in the queue-4.18 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. Hi, Please also include patch commit 0fe5119e267f3e3d8ac206895f5922195ec55a8a Author: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com> Date: Sat Oct 27 12:07:47 2018 +0300 net: bridge: remove ipv6 zero address check in mcast queries which fixed the patch. Thanks Hangbin > > > From foo@baz Fri Nov 2 06:12:44 CET 2018 > From: Hangbin Liu <liuhangbin(a)gmail.com> > Date: Fri, 26 Oct 2018 10:28:43 +0800 > Subject: bridge: do not add port to router list when receives query with source 0.0.0.0 > > From: Hangbin Liu <liuhangbin(a)gmail.com> > > [ Upstream commit 5a2de63fd1a59c30c02526d427bc014b98adf508 ] > > Based on RFC 4541, 2.1.1. IGMP Forwarding Rules > > The switch supporting IGMP snooping must maintain a list of > multicast routers and the ports on which they are attached. This > list can be constructed in any combination of the following ways: > > a) This list should be built by the snooping switch sending > Multicast Router Solicitation messages as described in IGMP > Multicast Router Discovery [MRDISC]. It may also snoop > Multicast Router Advertisement messages sent by and to other > nodes. > > b) The arrival port for IGMP Queries (sent by multicast routers) > where the source address is not 0.0.0.0. > > We should not add the port to router list when receives query with source > 0.0.0.0. > > Reported-by: Ying Xu <yinxu(a)redhat.com> > Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> > Acked-by: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com> > Acked-by: Roopa Prabhu <roopa(a)cumulusnetworks.com> > Signed-off-by: David S. Miller <davem(a)davemloft.net> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > net/bridge/br_multicast.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > --- a/net/bridge/br_multicast.c > +++ b/net/bridge/br_multicast.c > @@ -1420,7 +1420,15 @@ static void br_multicast_query_received( > return; > > br_multicast_update_query_timer(br, query, max_delay); > - br_multicast_mark_router(br, port); > + > + /* Based on RFC4541, section 2.1.1 IGMP Forwarding Rules, > + * the arrival port for IGMP Queries where the source address > + * is 0.0.0.0 should not be added to router port list. > + */ > + if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) || > + (saddr->proto == htons(ETH_P_IPV6) && > + !ipv6_addr_any(&saddr->u.ip6))) > + br_multicast_mark_router(br, port); > } > > static int br_ip4_multicast_query(struct net_bridge *br, > > > Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are > > queue-4.18/bridge-do-not-add-port-to-router-list-when-receives-query-with-source-0.0.0.0.patch

5 years, 6 months

3
2
0 0

Re: [Xen-devel] [PATCH] xen: remove size limit of privcmd-buf mapping interface

by Juergen Gross

On 01/11/2018 16:50, Jan Beulich wrote: >>>> Juergen Gross <jgross(a)suse.com> 11/01/18 3:23 PM >>> >> On 01/11/2018 15:18, Jan Beulich wrote: >>>>>> Juergen Gross <jgross(a)suse.com> 11/01/18 1:34 PM >>> >>>> Currently the size of hypercall buffers allocated via >>>> /dev/xen/hypercall is limited to a default of 64 memory pages. For live >>>> migration of guests this might be too small as the page dirty bitmask >>>> needs to be sized according to the size of the guest. This means >>>> migrating a 8GB sized guest is already exhausting the default buffer >>>> size for the dirty bitmap. >>>> >>>> There is no sensible way to set a sane limit, so just remove it >>>> completely. The device node's usage is limited to root anyway, so there >>>> is no additional DOS scenario added by allowing unlimited buffers. >>> >>> But is this setting of permissions what we want long term? What about a >>> de-privileged qemu, which still needs to be able to issue at least dm-op >>> hypercalls? >> >> Wouldn't that qemu have opened the node while still being privileged? > > Possibly, but how does this help? As soon as it's unprivileged it must not > be able to hog resources anymore. > > Anyway, with Andrew's reply my point may be irrelevant, but I have to > admit I'm not entirely sure. I guess we want Xen tools to close /dev/xen/hypercall (or more precise: don't dup2() it) when qemu is de-privileging itself. This will make it very clear that it can't hog memory via mmap(). When you are fine with that I'll send a Xen patch for this. Juergen

5 years, 6 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2018