* Re: [PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32
From: Borislav Petkov @ 2016-11-09 11:04 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel
In-Reply-To: <20161108183956.4521-5-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:53AM -0800, Kyle Huey wrote:
> Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat
> mode on x86-64. This allows us to have arch_prctls that are not specific to
function_name()
> 64 bits.
>
> On UML, simply stub out this syscall.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: [PATCH] USB: serial: fix invalid user-pointer checks
From: Oliver Neukum @ 2016-11-09 10:58 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-kernel, linux-usb
In-Reply-To: <20161108154117.GN2664@localhost>
On Tue, 2016-11-08 at 16:41 +0100, Johan Hovold wrote:
> On Tue, Nov 08, 2016 at 03:13:13PM +0100, Oliver Neukum wrote:
> > On Tue, 2016-11-08 at 13:26 +0100, Johan Hovold wrote:
> > > Drop invalid user-pointer checks from ioctl handlers.
> > >
> > > A NULL-pointer can be valid in user space and copy_to_user() takes
> > > care
> > > of sanity checking.
> >
> > Shouldn't we bail out early in these cases?
>
> I don't think it's worth it, and this is also the general pattern for
> such ioctls. The added overhead for an error case like this is really
> negligible.
OK, as you say.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32
From: Borislav Petkov @ 2016-11-09 11:04 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel, user-mode-linux-devel,
user-mode-linux-user, linux-fsdevel, linux-kselftest, kvm
In-Reply-To: <20161108183956.4521-5-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:53AM -0800, Kyle Huey wrote:
> Hook up arch_prctl to call do_arch_prctl on x86-32, and in 32 bit compat
> mode on x86-64. This allows us to have arch_prctls that are not specific to
function_name()
> 64 bits.
>
> On UML, simply stub out this syscall.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* [PATCH 4.4 39/69] virtio: console: Unlock vqs while freeing buffers
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matt Redfearn, Michael S. Tsirkin
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Redfearn <matt.redfearn@imgtec.com>
commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 upstream.
Commit c6017e793b93 ("virtio: console: add locks around buffer removal
in port unplug path") added locking around the freeing of buffers in the
vq. However, when free_buf() is called with can_sleep = true and rproc
is enabled, it calls dma_free_coherent() directly, requiring interrupts
to be enabled. Currently a WARNING is triggered due to the spin locking
around free_buf, with a call stack like this:
WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
free_buf+0x1a8/0x288
Call Trace:
[<8040c538>] show_stack+0x74/0xc0
[<80757240>] dump_stack+0xd0/0x110
[<80430d98>] __warn+0xfc/0x130
[<80430ee0>] warn_slowpath_null+0x2c/0x3c
[<807e7c6c>] free_buf+0x1a8/0x288
[<807ea590>] remove_port_data+0x50/0xac
[<807ea6a0>] unplug_port+0xb4/0x1bc
[<807ea858>] virtcons_remove+0xb0/0xfc
[<807b6734>] virtio_dev_remove+0x58/0xc0
[<807f918c>] __device_release_driver+0xac/0x134
[<807f924c>] device_release_driver+0x38/0x50
[<807f7edc>] bus_remove_device+0xfc/0x130
[<807f4b74>] device_del+0x17c/0x21c
[<807f4c38>] device_unregister+0x24/0x38
[<807b6b50>] unregister_virtio_device+0x28/0x44
Fix this by restructuring the loops to allow the locks to only be taken
where it is necessary to protect the vqs, and release it while the
buffer is being freed.
Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path")
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/virtio_console.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1533,19 +1533,29 @@ static void remove_port_data(struct port
spin_lock_irq(&port->inbuf_lock);
/* Remove unused data this port might have received. */
discard_port_data(port);
+ spin_unlock_irq(&port->inbuf_lock);
/* Remove buffers we queued up for the Host to send us data in. */
- while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
- free_buf(buf, true);
- spin_unlock_irq(&port->inbuf_lock);
+ do {
+ spin_lock_irq(&port->inbuf_lock);
+ buf = virtqueue_detach_unused_buf(port->in_vq);
+ spin_unlock_irq(&port->inbuf_lock);
+ if (buf)
+ free_buf(buf, true);
+ } while (buf);
spin_lock_irq(&port->outvq_lock);
reclaim_consumed_buffers(port);
+ spin_unlock_irq(&port->outvq_lock);
/* Free pending buffers from the out-queue. */
- while ((buf = virtqueue_detach_unused_buf(port->out_vq)))
- free_buf(buf, true);
- spin_unlock_irq(&port->outvq_lock);
+ do {
+ spin_lock_irq(&port->outvq_lock);
+ buf = virtqueue_detach_unused_buf(port->out_vq);
+ spin_unlock_irq(&port->outvq_lock);
+ if (buf)
+ free_buf(buf, true);
+ } while (buf);
}
/*
^ permalink raw reply
* Re: [PATCH net-next 1/2] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path
From: Daniel Borkmann @ 2016-11-09 11:04 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Zhiyi Sun, bblanco, Tariq Toukan, Yishai Hadas,
netdev, linux-rdma, linux-kernel, alexei.starovoitov
In-Reply-To: <201611091853.HAp072gP%fengguang.wu@intel.com>
On 11/09/2016 11:58 AM, kbuild test robot wrote:
[...]
> All errors (new ones prefixed by >>):
>
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function 'mlx4_xdp_set':
>>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2752:4: error: implicit declaration of function 'bpf_prog_add_undo' [-Werror=implicit-function-declaration]
> bpf_prog_add_undo(prog, priv->rx_ring_num - 1);
> ^~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
Ahh right, needs an empty variant for !CONFIG_BPF_SYSCALL. I'll fix that up
before sending an official patch.
Thanks,
Daniel
^ permalink raw reply
* [PATCH 4.4 65/69] usb: dwc3: Fix size used in dma_free_coherent()
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Christophe JAILLET, Felipe Balbi
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
commit 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 upstream.
In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the
size of the memory allocated with 'dma_alloc_coherent()' has been modified
but the corresponding calls to 'dma_free_coherent()' have not been updated
accordingly.
This has been spotted with coccinelle, using the following script:
////////////////////
@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@
* ret = dma_alloc_coherent(x0, y0, z0, t0);
...
* dma_free_coherent(x1, y1, ret, t1);
@script:python@
y0 << r.y0;
y1 << r.y1;
@@
if y1.find(y0) == -1:
print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1)
////////////////////
Fixes: 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2845,7 +2845,7 @@ err3:
kfree(dwc->setup_buf);
err2:
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
err1:
@@ -2869,7 +2869,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
kfree(dwc->setup_buf);
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
dma_free_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
^ permalink raw reply
* [PATCH 4.4 64/69] pwm: Unexport children before chip removal
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, David Hsu, Thierry Reding
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hsu <davidhsu@google.com>
commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.
Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.
Signed-off-by: David Hsu <davidhsu@google.com>
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pwm/core.c | 2 ++
drivers/pwm/sysfs.c | 18 ++++++++++++++++++
include/linux/pwm.h | 5 +++++
3 files changed, 25 insertions(+)
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -321,6 +321,8 @@ int pwmchip_remove(struct pwm_chip *chip
unsigned int i;
int ret = 0;
+ pwmchip_sysfs_unexport_children(chip);
+
mutex_lock(&pwm_lock);
for (i = 0; i < chip->npwm; i++) {
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -350,6 +350,24 @@ void pwmchip_sysfs_unexport(struct pwm_c
}
}
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+ struct device *parent;
+ unsigned int i;
+
+ parent = class_find_device(&pwm_class, NULL, chip,
+ pwmchip_sysfs_match);
+ if (!parent)
+ return;
+
+ for (i = 0; i < chip->npwm; i++) {
+ struct pwm_device *pwm = &chip->pwms[i];
+
+ if (test_bit(PWMF_EXPORTED, &pwm->flags))
+ pwm_unexport_child(parent, pwm);
+ }
+}
+
static int __init pwm_sysfs_init(void)
{
return class_register(&pwm_class);
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -331,6 +331,7 @@ static inline void pwm_remove_table(stru
#ifdef CONFIG_PWM_SYSFS
void pwmchip_sysfs_export(struct pwm_chip *chip);
void pwmchip_sysfs_unexport(struct pwm_chip *chip);
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip);
#else
static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
{
@@ -339,6 +340,10 @@ static inline void pwmchip_sysfs_export(
static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
{
}
+
+static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+}
#endif /* CONFIG_PWM_SYSFS */
#endif /* __LINUX_PWM_H */
^ permalink raw reply
* [PATCH 4.4 59/69] drm/exynos: fix error handling in exynos_drm_subdrv_open
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Inki Dae
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit 55c4b906aa2aec3fa66310ec03c6842e34a04b2a upstream.
gcc-6 warns about a pointless loop in exynos_drm_subdrv_open:
drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open':
drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always evaluates to false [-Werror=tautological-compare]
list_for_each_entry_reverse(subdrv, &subdrv->list, list) {
Here, the list_for_each_entry_reverse immediately terminates because
the subdrv pointer is compared to itself as the loop end condition.
If we were to take the current subdrv pointer as the start of the
list (as we would do if list_for_each_entry_reverse() was not a macro),
we would iterate backwards over the &exynos_drm_subdrv_list anchor,
which would be even worse.
Instead, we need to use list_for_each_entry_continue_reverse()
to go back over each subdrv that was successfully opened until
the first entry.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -101,7 +101,7 @@ int exynos_drm_subdrv_open(struct drm_de
return 0;
err:
- list_for_each_entry_reverse(subdrv, &subdrv->list, list) {
+ list_for_each_entry_continue_reverse(subdrv, &exynos_drm_subdrv_list, list) {
if (subdrv->close)
subdrv->close(dev, subdrv->dev, file);
}
^ permalink raw reply
* [PATCH 4.4 60/69] cgroup: avoid false positive gcc-6 warning
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Tejun Heo
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit cfe02a8a973e7e5f66926b8ae38dfce404b19e29 upstream.
When all subsystems are disabled, gcc notices that cgroup_subsys_enabled_key
is a zero-length array and that any access to it must be out of bounds:
In file included from ../include/linux/cgroup.h:19:0,
from ../kernel/cgroup.c:31:
../kernel/cgroup.c: In function 'cgroup_add_cftypes':
../kernel/cgroup.c:261:53: error: array subscript is above array bounds [-Werror=array-bounds]
return static_key_enabled(cgroup_subsys_enabled_key[ssid]);
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
../include/linux/jump_label.h:271:40: note: in definition of macro 'static_key_enabled'
static_key_count((struct static_key *)x) > 0; \
^
We should never call the function in this particular case, so this is
not a bug. In order to silence the warning, this adds an explicit check
for the CGROUP_SUBSYS_COUNT==0 case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup.c | 3 +++
1 file changed, 3 insertions(+)
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -236,6 +236,9 @@ static int cgroup_addrm_files(struct cgr
*/
static bool cgroup_ssid_enabled(int ssid)
{
+ if (CGROUP_SUBSYS_COUNT == 0)
+ return false;
+
return static_key_enabled(cgroup_subsys_enabled_key[ssid]);
}
^ permalink raw reply
* [PATCH 4.4 57/69] ARM: 8584/1: floppy: avoid gcc-6 warning
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Russell King
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit dd665be0e243873343a28e18f9f345927b658daf upstream.
gcc-6.0 warns about comparisons between two identical expressions,
which is what we get in the floppy driver when writing to the FD_DOR
register:
drivers/block/floppy.c: In function 'set_dor':
drivers/block/floppy.c:810:44: error: self-comparison always evaluates to true [-Werror=tautological-compare]
fd_outb(newdor, FD_DOR);
It would be nice to use a static inline function instead of the
macro, to avoid the warning, but we cannot do that because the
FD_DOR definition is incomplete at this point.
Adding a cast to (u32) is a harmless way to shut up the warning,
just not very nice.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/floppy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/include/asm/floppy.h
+++ b/arch/arm/include/asm/floppy.h
@@ -17,7 +17,7 @@
#define fd_outb(val,port) \
do { \
- if ((port) == FD_DOR) \
+ if ((port) == (u32)FD_DOR) \
fd_setdor((val)); \
else \
outb((val),(port)); \
^ permalink raw reply
* [Buildroot] [PATCH] grub2: enable grub-mkfont host tool
From: Jérôme Pouiller @ 2016-11-09 11:03 UTC (permalink / raw)
To: buildroot
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
boot/grub2/grub2.mk | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/boot/grub2/grub2.mk b/boot/grub2/grub2.mk
index dc4e51e..a3352c2 100644
--- a/boot/grub2/grub2.mk
+++ b/boot/grub2/grub2.mk
@@ -9,7 +9,7 @@ GRUB2_SITE = $(BR2_GNU_MIRROR)/grub
GRUB2_SOURCE = grub-$(GRUB2_VERSION).tar.xz
GRUB2_LICENSE = GPLv3+
GRUB2_LICENSE_FILES = COPYING
-GRUB2_DEPENDENCIES = host-bison host-flex
+GRUB2_DEPENDENCIES = host-bison host-flex host-freetype
GRUB2_BUILTIN_MODULES = $(call qstrip,$(BR2_TARGET_GRUB2_BUILTIN_MODULES))
GRUB2_BUILTIN_CONFIG = $(call qstrip,$(BR2_TARGET_GRUB2_BUILTIN_CONFIG))
@@ -63,7 +63,6 @@ GRUB2_CONF_ENV = \
GRUB2_CONF_OPTS = \
--target=$(GRUB2_TARGET) \
--with-platform=$(GRUB2_PLATFORM) \
- --disable-grub-mkfont \
--enable-efiemu=no \
ac_cv_lib_lzma_lzma_code=no \
--enable-device-mapper=no \
--
2.9.3
^ permalink raw reply related
* [PATCH 4.4 38/69] virtio_ring: Make interrupt suppression spec compliant
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael S. Tsirkin, Ladi Prosek
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ladi Prosek <lprosek@redhat.com>
commit 0ea1e4a6d9b62cf29e210d2b4ba9fd43917522e3 upstream.
According to the spec, if the VIRTIO_RING_F_EVENT_IDX feature bit is
negotiated the driver MUST set flags to 0. Not dirtying the available
ring in virtqueue_disable_cb also has a minor positive performance
impact, improving L1 dcache load missed by ~0.5% in vring_bench.
Writes to the used event field (vring_used_event) are still unconditional.
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Ladi Prosek <lprosek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/virtio/virtio_ring.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -548,7 +548,8 @@ void virtqueue_disable_cb(struct virtque
if (!(vq->avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT)) {
vq->avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT;
- vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
+ if (!vq->event)
+ vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
}
}
@@ -580,7 +581,8 @@ unsigned virtqueue_enable_cb_prepare(str
* entry. Always do both to keep code simple. */
if (vq->avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT) {
vq->avail_flags_shadow &= ~VRING_AVAIL_F_NO_INTERRUPT;
- vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
+ if (!vq->event)
+ vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
}
vring_used_event(&vq->vring) = cpu_to_virtio16(_vq->vdev, last_used_idx = vq->last_used_idx);
END_USE(vq);
@@ -648,10 +650,11 @@ bool virtqueue_enable_cb_delayed(struct
* more to do. */
/* Depending on the VIRTIO_RING_F_USED_EVENT_IDX feature, we need to
* either clear the flags bit or point the event index at the next
- * entry. Always do both to keep code simple. */
+ * entry. Always update the event index to keep code simple. */
if (vq->avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT) {
vq->avail_flags_shadow &= ~VRING_AVAIL_F_NO_INTERRUPT;
- vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
+ if (!vq->event)
+ vq->vring.avail->flags = cpu_to_virtio16(_vq->vdev, vq->avail_flags_shadow);
}
/* TODO: tune this threshold */
bufs = (u16)(vq->avail_idx_shadow - vq->last_used_idx) * 3 / 4;
@@ -770,7 +773,8 @@ struct virtqueue *vring_new_virtqueue(un
/* No callback? Tell other side not to bother us. */
if (!callback) {
vq->avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT;
- vq->vring.avail->flags = cpu_to_virtio16(vdev, vq->avail_flags_shadow);
+ if (!vq->event)
+ vq->vring.avail->flags = cpu_to_virtio16(vdev, vq->avail_flags_shadow);
}
/* Put everything in free lists. */
^ permalink raw reply
* [PATCH 4.4 54/69] perf build: Fix traceevent plugins build race
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Olsa, David Ahern, Namhyung Kim,
Peter Zijlstra, Arnaldo Carvalho de Melo, Thomas Backlund
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Olsa <jolsa@kernel.org>
commit 67befc652845c8ffbefc8d173a6e6ced14d472f1 upstream.
Ingo reported following build failure:
$ make clean install
...
CC plugin_kmem.o
fixdep: error opening depfile: ./.plugin_hrtimer.o.d: No such file or directory
/home/mingo/tip/tools/build/Makefile.build:77: recipe for target
'plugin_hrtimer.o' failed
make[3]: *** [plugin_hrtimer.o] Error 2
Makefile:189: recipe for target 'plugin_hrtimer-in.o' failed
make[2]: *** [plugin_hrtimer-in.o] Error 2
Makefile.perf:414: recipe for target 'libtraceevent_plugins' failed
make[1]: *** [libtraceevent_plugins] Error 2
make[1]: *** Waiting for unfinished jobs....
Currently we have the install-traceevent-plugins target being dependent
on $(LIBTRACEEVENT), which will actualy not build any plugin. So the
install-traceevent-plugins target itself will try to build plugins,
but..
Plugins built is also triggered by perf build itself via
libtraceevent_plugins target.
This might cause a race having one make thread removing temp files from
another and result in above error. Fixing this by having proper plugins
build dependency before installing plugins.
Reported-and-Tested-by:: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1448546044-28973-3-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/Makefile.perf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -420,7 +420,7 @@ $(LIBTRACEEVENT)-clean:
$(call QUIET_CLEAN, libtraceevent)
$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) O=$(OUTPUT) clean >/dev/null
-install-traceevent-plugins: $(LIBTRACEEVENT)
+install-traceevent-plugins: libtraceevent_plugins
$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) install_plugins
$(LIBAPI): fixdep FORCE
^ permalink raw reply
* [PATCH 4.4 51/69] drm/radeon/si_dpm: workaround for SI kickers
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e upstream.
Consolidate existing quirks. Fixes stability issues
on some kickers.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/si_dpm.c | 59 +++++++++++++++++++++++++++++-----------
1 file changed, 43 insertions(+), 16 deletions(-)
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2999,6 +2999,49 @@ static void si_apply_state_adjust_rules(
int i;
struct si_dpm_quirk *p = si_dpm_quirk_list;
+ /* limit all SI kickers */
+ if (rdev->family == CHIP_PITCAIRN) {
+ if ((rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->device == 0x6810) ||
+ (rdev->pdev->device == 0x6811) ||
+ (rdev->pdev->device == 0x6816) ||
+ (rdev->pdev->device == 0x6817) ||
+ (rdev->pdev->device == 0x6806))
+ max_mclk = 120000;
+ } else if (rdev->family == CHIP_VERDE) {
+ if ((rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->revision == 0x83) ||
+ (rdev->pdev->revision == 0x87) ||
+ (rdev->pdev->device == 0x6820) ||
+ (rdev->pdev->device == 0x6821) ||
+ (rdev->pdev->device == 0x6822) ||
+ (rdev->pdev->device == 0x6823) ||
+ (rdev->pdev->device == 0x682A) ||
+ (rdev->pdev->device == 0x682B)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ } else if (rdev->family == CHIP_OLAND) {
+ if ((rdev->pdev->revision == 0xC7) ||
+ (rdev->pdev->revision == 0x80) ||
+ (rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->revision == 0x83) ||
+ (rdev->pdev->device == 0x6604) ||
+ (rdev->pdev->device == 0x6605)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ } else if (rdev->family == CHIP_HAINAN) {
+ if ((rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->revision == 0x83) ||
+ (rdev->pdev->revision == 0xC3) ||
+ (rdev->pdev->device == 0x6664) ||
+ (rdev->pdev->device == 0x6665) ||
+ (rdev->pdev->device == 0x6667)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ }
/* Apply dpm quirks */
while (p && p->chip_device != 0) {
if (rdev->pdev->vendor == p->chip_vendor &&
@@ -3011,22 +3054,6 @@ static void si_apply_state_adjust_rules(
}
++p;
}
- /* limit mclk on all R7 370 parts for stability */
- if (rdev->pdev->device == 0x6811 &&
- rdev->pdev->revision == 0x81)
- max_mclk = 120000;
- /* limit sclk/mclk on Jet parts for stability */
- if (rdev->pdev->device == 0x6665 &&
- rdev->pdev->revision == 0xc3) {
- max_sclk = 75000;
- max_mclk = 80000;
- }
- /* limit clocks on HD8600 series */
- if (rdev->pdev->device == 0x6660 &&
- rdev->pdev->revision == 0x83) {
- max_sclk = 75000;
- max_mclk = 80000;
- }
if (rps->vce_active) {
rps->evclk = rdev->pm.dpm.vce_states[rdev->pm.dpm.vce_level].evclk;
^ permalink raw reply
* [PATCH 4.4 46/69] scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ewan D. Milne, Laurence Oberman,
Martin K. Petersen
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ewan D. Milne <emilne@redhat.com>
commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d upstream.
map_storep was not being vfree()'d in the module_exit call.
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/scsi_debug.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -4981,6 +4981,7 @@ static void __exit scsi_debug_exit(void)
bus_unregister(&pseudo_lld_bus);
root_device_unregister(pseudo_primary);
+ vfree(map_storep);
vfree(dif_storep);
vfree(fake_storep);
}
^ permalink raw reply
* [PATCH 4.4 47/69] scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ching Huang, Tomas Henzl,
Martin K. Petersen
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ching Huang <ching2048@areca.com.tw>
commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream.
The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller
firmware. Depending on how drive caches are handled internally by
controller firmware this could potentially lead to data integrity
problems.
Ensure that cache flushes are passed to the controller.
[mkp: applied by hand and removed unused vars]
Signed-off-by: Ching Huang <ching2048@areca.com.tw>
Reported-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/arcmsr/arcmsr_hba.c | 9 ---------
1 file changed, 9 deletions(-)
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2545,18 +2545,9 @@ static int arcmsr_queue_command_lck(stru
struct AdapterControlBlock *acb = (struct AdapterControlBlock *) host->hostdata;
struct CommandControlBlock *ccb;
int target = cmd->device->id;
- int lun = cmd->device->lun;
- uint8_t scsicmd = cmd->cmnd[0];
cmd->scsi_done = done;
cmd->host_scribble = NULL;
cmd->result = 0;
- if ((scsicmd == SYNCHRONIZE_CACHE) ||(scsicmd == SEND_DIAGNOSTIC)){
- if(acb->devstate[target][lun] == ARECA_RAID_GONE) {
- cmd->result = (DID_NO_CONNECT << 16);
- }
- cmd->scsi_done(cmd);
- return 0;
- }
if (target == 16) {
/* virtual device for iop message transfer */
arcmsr_handle_virtual_command(acb, cmd);
^ permalink raw reply
* Re: [meta-freescale-layer][PATCH] gstreamer1.0-plugins-bad: append patches for imx targets to remove cross-impaction for qoriq
From: Otavio Salvador @ 2016-11-09 11:03 UTC (permalink / raw)
To: Zhenhua Luo; +Cc: meta-freescale@yoctoproject.org
In-Reply-To: <1478600991-31419-1-git-send-email-zhenhua.luo@nxp.com>
On Tue, Nov 8, 2016 at 8:29 AM, Zhenhua Luo <zhenhua.luo@nxp.com> wrote:
> Those patches cross-impacts QorIQ targets build and the following build error
> appears when gstreamer1.0-plugins-bad is built for QorIQ PPC targets. Apply the
> patches for imx targets only.
>
> Error log:
> | In file included from ../../../../gst-plugins-bad-1.8.3/gst-libs/gst/gl/gstglbufferpool.c:33:0:
> | ../../../../gst-plugins-bad-1.8.3/gst-libs/gst/gl/gstglphymemory.h:27:47: fatal error: gst/allocators/gstallocatorphymem.h: No such file or directory
> | #include <gst/allocators/gstallocatorphymem.h>
> | ^
> | compilation terminated.
> | Makefile:1134: recipe for target 'libgstgl_1.0_la-gstglbufferpool.lo' failed
>
> Signed-off-by: Zhenhua Luo <zhenhua.luo@nxp.com>
I think your branch is old; this has been fixes few days ago.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* [PATCH 4.4 37/69] parisc: Ensure consistent state when switching to kernel stack at syscall entry
From: Greg Kroah-Hartman @ 2016-11-09 10:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John David Anglin, Helge Deller
In-Reply-To: <20161109102901.127641653@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John David Anglin <dave.anglin@bell.net>
commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 upstream.
We have one critical section in the syscall entry path in which we switch from
the userspace stack to kernel stack. In the event of an external interrupt, the
interrupt code distinguishes between those two states by analyzing the value of
sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that
the value of sr7 is in sync with the currently enabled stack.
This patch now disables interrupts while executing the critical section. This
prevents the interrupt handler to possibly see an inconsistent state which in
the worst case can lead to crashes.
Interestingly, in the syscall exit path interrupts were already disabled in the
critical section which switches back to the userspace stack.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/syscall.S | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/arch/parisc/kernel/syscall.S
+++ b/arch/parisc/kernel/syscall.S
@@ -106,8 +106,6 @@ linux_gateway_entry:
mtsp %r0,%sr4 /* get kernel space into sr4 */
mtsp %r0,%sr5 /* get kernel space into sr5 */
mtsp %r0,%sr6 /* get kernel space into sr6 */
- mfsp %sr7,%r1 /* save user sr7 */
- mtsp %r1,%sr3 /* and store it in sr3 */
#ifdef CONFIG_64BIT
/* for now we can *always* set the W bit on entry to the syscall
@@ -133,6 +131,14 @@ linux_gateway_entry:
depdi 0, 31, 32, %r21
1:
#endif
+
+ /* We use a rsm/ssm pair to prevent sr3 from being clobbered
+ * by external interrupts.
+ */
+ mfsp %sr7,%r1 /* save user sr7 */
+ rsm PSW_SM_I, %r0 /* disable interrupts */
+ mtsp %r1,%sr3 /* and store it in sr3 */
+
mfctl %cr30,%r1
xor %r1,%r30,%r30 /* ye olde xor trick */
xor %r1,%r30,%r1
@@ -147,6 +153,7 @@ linux_gateway_entry:
*/
mtsp %r0,%sr7 /* get kernel space into sr7 */
+ ssm PSW_SM_I, %r0 /* enable interrupts */
STREGM %r1,FRAME_SIZE(%r30) /* save r1 (usp) here for now */
mfctl %cr30,%r1 /* get task ptr in %r1 */
LDREG TI_TASK(%r1),%r1
^ permalink raw reply
* [Qemu-devel] [PATCH] test-uuid: fix leak
From: Marc-André Lureau @ 2016-11-09 11:02 UTC (permalink / raw)
To: qemu-devel; +Cc: famz, Marc-André Lureau
ASAN spotted:
SUMMARY: AddressSanitizer: 74 byte(s) leaked in 2 allocation(s).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
tests/test-uuid.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/test-uuid.c b/tests/test-uuid.c
index 77dcdc4..d3a2791 100644
--- a/tests/test-uuid.c
+++ b/tests/test-uuid.c
@@ -161,6 +161,7 @@ static void test_uuid_unparse_strdup(void)
}
out = qemu_uuid_unparse_strdup(&uuid_test_data[i].uuid);
g_assert_cmpstr(uuid_test_data[i].uuidstr, ==, out);
+ g_free(out);
}
}
--
2.10.0
^ permalink raw reply related
* [PATCH] clk: gate: fix coding style
From: Uwe Kleine-König @ 2016-11-09 11:00 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd; +Cc: linux-clk, trivial, kernel
The : of the ?: operator should have a leading space.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
I always wonder if I should send such patches or if they hurt more than
they are worth. *shrug* ignore at will.
Best regards
Uwe
drivers/clk/clk-gate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 4e691e35483a..59e302538d23 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -145,7 +145,7 @@ struct clk_hw *clk_hw_register_gate(struct device *dev, const char *name,
init.name = name;
init.ops = &clk_gate_ops;
init.flags = flags | CLK_IS_BASIC;
- init.parent_names = (parent_name ? &parent_name: NULL);
+ init.parent_names = (parent_name ? &parent_name : NULL);
init.num_parents = (parent_name ? 1 : 0);
/* struct clk_gate assignments */
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v4 0/3] spi-nor: Add support for Intel SPI serial flash controller
From: Mika Westerberg @ 2016-11-09 11:00 UTC (permalink / raw)
To: linux-mtd
Cc: Brian Norris, David Woodhouse, Lee Jones, Peter Tyser,
key.seong.lim, mkraemer, linux-kernel, Cyrille Pitchen,
Marek Vasut, Boris Brezillon, Richard Weinberger
In-Reply-To: <20161017145858.143771-1-mika.westerberg@linux.intel.com>
On Mon, Oct 17, 2016 at 05:58:55PM +0300, Mika Westerberg wrote:
> This is fourth version of the series. Previous versions can be found:
>
> v3: https://lwn.net/Articles/697231/
> v2: http://lists.infradead.org/pipermail/linux-mtd/2016-June/068277.html
> v1: https://lkml.org/lkml/2016/6/14/269
>
> This patch series adds support for the Intel SPI serial flash controller
> found on many recent Intel CPUs including Baytrail and Braswell. This
> driver makes it possible to access the BIOS and other platform data which
> is stored on the SPI serial flash. It is also possible to upgrade the BIOS
> using this driver if it has not been protected by special hardware bits.
>
> The patch [1/3] includes documentation how to upgrade BIOS on MinnowBoard
> MAX.
>
> Since poking the SPI serial flash can brick the machine, this driver can
> only be enabled when CONFIG_EXPERT=y and even then it will remain read-only
> unless instructed othwerwise by module parameter.
>
> This missed v4.8 and v4.9 so it would be really nice to get it finally
> included in v4.10.
Adding the new MTD and SPI-NOR maintainers. Any change getting this
merged for v4.10?
^ permalink raw reply
* [PATCH] megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression caused by commit 1e793f6fc0db920400574211c48f9157a37e3945
From: Sumit Saxena @ 2016-11-09 10:59 UTC (permalink / raw)
To: linux-scsi
Cc: martin.petersen, thenzl, jejb, kashyap.desai,
shivasharan.srikanteshwara, axboe, stable, Sumit Saxena
This patch will fix regression caused by below commit-
1e793f6 scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices
The problem was MEGASAS_IS_LOGICAL macro does not have braces and because of above commit
using this macro was exposing lot of non-existing SCSI devices(all SCSI commands to channels-1,2,3 was
returned as SUCCESS-DID_OK by driver).
Fixes: 1e793f6fc0db920400574211c48f9157a37e3945
Reported-by: Jens Axboe <axboe@kernel.dk>
CC: stable@vger.kernel.org
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Tested-by: Sumit Saxena <sumit.saxena@broadcom.com>
---
drivers/scsi/megaraid/megaraid_sas.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h
index ca86c88..3aaea71 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2233,7 +2233,7 @@ struct megasas_instance_template {
};
#define MEGASAS_IS_LOGICAL(scp) \
- (scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1
+ ((scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1)
#define MEGASAS_DEV_INDEX(scp) \
(((scp->device->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL) + \
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next 1/2] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path
From: kbuild test robot @ 2016-11-09 10:58 UTC (permalink / raw)
To: Daniel Borkmann
Cc: kbuild-all, Zhiyi Sun, bblanco, Tariq Toukan, Yishai Hadas,
netdev, linux-rdma, linux-kernel, alexei.starovoitov
In-Reply-To: <5822F30C.1050900@iogearbox.net>
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
Hi Daniel,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Daniel-Borkmann/bpf-mlx4-fix-prog-refcount-in-mlx4_en_try_alloc_resources-error-path/20161109-182712
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function 'mlx4_xdp_set':
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2752:4: error: implicit declaration of function 'bpf_prog_add_undo' [-Werror=implicit-function-declaration]
bpf_prog_add_undo(prog, priv->rx_ring_num - 1);
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/bpf_prog_add_undo +2752 drivers/net/ethernet/mellanox/mlx4/en_netdev.c
2746 en_warn(priv, "Reducing the number of TX rings, to not exceed the max total rings number.\n");
2747 }
2748
2749 err = mlx4_en_try_alloc_resources(priv, tmp, &new_prof);
2750 if (err) {
2751 if (prog)
> 2752 bpf_prog_add_undo(prog, priv->rx_ring_num - 1);
2753 goto unlock_out;
2754 }
2755
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28646 bytes --]
^ permalink raw reply
* Re: [PATCH] drm/i915/audio: fix hdmi audio noise issue
From: Jani Nikula @ 2016-11-09 10:59 UTC (permalink / raw)
To: libin.yang, intel-gfx, ville.syrjala, daniel.vetter, tiwai
In-Reply-To: <1478680049-50757-1-git-send-email-libin.yang@intel.com>
On Wed, 09 Nov 2016, libin.yang@intel.com wrote:
> From: Libin Yang <libin.yang@intel.com>
>
> This issue is caused by:
> 6014ac12: drm/i915/audio: set proper N/M in modeset
>
> Some special monitors will have noise or even no sound after
> applying the patch 6014ac12.
>
> In patch 6014ac12, it will reset the cts value to 0 for HDMI.
> However, we need disable Enable CTS or M Prog bit. This is
> the initial setting after HW reset.
>
Fixes: 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset")
> Signed-off-by: Libin Yang <libin.yang@intel.com>
> ---
> drivers/gpu/drm/i915/intel_audio.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
> index 813fd74..a472d35 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -332,6 +332,13 @@ hsw_hdmi_audio_config_update(struct intel_crtc *intel_crtc, enum port port,
> int n;
> u32 tmp;
>
> + /* reset CTS value to 0 */
> + tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
> + tmp &= ~AUD_CONFIG_M_MASK;
> + tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
> + tmp |= AUD_M_CTS_M_PROG_ENABLE;
> + I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
> +
> tmp = I915_READ(HSW_AUD_CFG(pipe));
> tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
> @@ -351,10 +358,12 @@ hsw_hdmi_audio_config_update(struct intel_crtc *intel_crtc, enum port port,
>
> I915_WRITE(HSW_AUD_CFG(pipe), tmp);
>
> + /*
> + * Let's disable "Enable CTS or M Prog bit"
> + * and let HW calculate the value
> + */
> tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
> - tmp &= ~AUD_CONFIG_M_MASK;
> - tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
> - tmp |= AUD_M_CTS_M_PROG_ENABLE;
> + tmp &= ~AUD_M_CTS_M_PROG_ENABLE;
> I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
Is it necessary to do the HSW_AUD_M_CTS_ENABLE updates in two places?
Why do you both enable and disable AUD_M_CTS_M_PROG_ENABLE bit here?
BR,
Jani.
> }
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Torsten Bögershausen @ 2016-11-09 10:51 UTC (permalink / raw)
To: Lars Schneider; +Cc: Jeff King, git, gitster
In-Reply-To: <0966CBE3-2F08-4B89-9716-4EEE3CE2526E@gmail.com>
On 09.11.16 10:29, Lars Schneider wrote:
>
>> On 09 Nov 2016, at 09:18, Torsten Bögershausen <tboegi@web.de> wrote:
>>
>> On 07.11.16 18:26, Jeff King wrote:
>>> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote:
>>>
>>>> Good point. I think I found an even easier way to achieve the same.
>>>> What do you think about the patch below?
>>>>
>>>> [...]
>>>>
>>>> diff --git a/Makefile b/Makefile
>>>> index 9d6c245..f53fcc9 100644
>>>> --- a/Makefile
>>>> +++ b/Makefile
>>>> @@ -1047,6 +1047,7 @@ ifeq ($(uname_S),Darwin)
>>>> endif
>>>> endif
>>>> ifndef NO_APPLE_COMMON_CRYPTO
>>>> + NO_OPENSSL = YesPlease
>>>> APPLE_COMMON_CRYPTO = YesPlease
>>>> COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
>>>> endif
>>>
>>> That is much simpler.
>> []
>> I don't know if that is a correct solution.
>>
>> If I have Mac OS 10.12 and Mac Ports installed, I may want to use
>> OPENSSL from Mac Ports.
>
> Can't you define `NO_APPLE_COMMON_CRYPTO` in that case?
> I think if you use OpenSSL then you don't need the Apple crypto lib, right?
After re-reading the Makefile: that makes sense :-)
Do you want to send a new patch ?
Feel free to omit
"Original-patch-by: Torsten Bögershausen <tboegi@web.de>"
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.