Re: [PATCH 1/3] perf pt: Mark PT return events as "return"

On 24/05/2016 5:57 p.m., Arnaldo Carvalho de Melo wrote: Em Mon, May 23, 2016 at 05:52:23PM -0700, Andi Kleen escreveu: From: Andi Kleen With perf script --itrace=cr we can synthesize calls and returns out of a PT log. However both calls and returns are marked with the

Re: [PATCH 1/3] perf pt: Mark PT return events as "return"

On 24/05/2016 5:57 p.m., Arnaldo Carvalho de Melo wrote: Em Mon, May 23, 2016 at 05:52:23PM -0700, Andi Kleen escreveu: From: Andi Kleen With perf script --itrace=cr we can synthesize calls and returns out of a PT log. However both calls and returns are marked with the same event, called

Applied "ASoC: rockchip: i2s: rename I2S_CKR_TRCM_TX/RXSHARE to I2S_CKR_TRCM_TX/RXONLY" to the asoc tree

The patch ASoC: rockchip: i2s: rename I2S_CKR_TRCM_TX/RXSHARE to I2S_CKR_TRCM_TX/RXONLY has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Applied "ASoC: rockchip: i2s: rename I2S_CKR_TRCM_TX/RXSHARE to I2S_CKR_TRCM_TX/RXONLY" to the asoc tree

The patch ASoC: rockchip: i2s: rename I2S_CKR_TRCM_TX/RXSHARE to I2S_CKR_TRCM_TX/RXONLY has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Re: [RFC][PATCH 2/3] locking: Annotate spin_unlock_wait() users

Hello, On Tue, May 24, 2016 at 09:17:13AM -0700, Linus Torvalds wrote: > So don't talk about "acquire". And most certainly don't talk about > "control dependencies". Not if we end up having things like *drivers* > using this like in this example libata. A delta but that particular libata usage

Re: [RFC][PATCH 2/3] locking: Annotate spin_unlock_wait() users

Hello, On Tue, May 24, 2016 at 09:17:13AM -0700, Linus Torvalds wrote: > So don't talk about "acquire". And most certainly don't talk about > "control dependencies". Not if we end up having things like *drivers* > using this like in this example libata. A delta but that particular libata usage

Re: [RFC][PATCH 2/3] locking: Annotate spin_unlock_wait() users

On Tue, May 24, 2016 at 7:27 AM, Peter Zijlstra wrote: > spin_unlock_wait() has an unintuitive 'feature' in that it doesn't > fully serialize against the spin_unlock() we've waited on. NAK. We don't start adding more of this "after_ctrl_dep" crap. It's completely

Re: [RFC][PATCH 2/3] locking: Annotate spin_unlock_wait() users

On Tue, May 24, 2016 at 7:27 AM, Peter Zijlstra wrote: > spin_unlock_wait() has an unintuitive 'feature' in that it doesn't > fully serialize against the spin_unlock() we've waited on. NAK. We don't start adding more of this "after_ctrl_dep" crap. It's completely impossible to understand, and

[PATCH] mailbox: mailbox-test: set tdev->signal to NULL after freeing

tdev->signal is not set NULL after it's freed. This will cause random exceptions when the stale pointer is accessed after tdev->signal is freed. Also, since tdev->signal allocation is skipped the next time it's written, this leads to continuous fault finally leading to the total death of the

[PATCH] mailbox: mailbox-test: set tdev->signal to NULL after freeing

tdev->signal is not set NULL after it's freed. This will cause random exceptions when the stale pointer is accessed after tdev->signal is freed. Also, since tdev->signal allocation is skipped the next time it's written, this leads to continuous fault finally leading to the total death of the

Re: can't boot with reiserfs on linux-4.6.0+

On Tue, May 24, 2016 at 8:59 AM, Al Viro wrote: > > Umm... Any chance of getting the function names to go with the addresses? > I'll try to reproduce it here, but the things would be easier with that > information... Yeah, we shouldn't even allow non-KALLSYMS builds. In

Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c

On 05/23/2016 07:18 PM, Al Viro wrote: On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote: The mainline kernels past 4.6.0 fail hang when logging in. There are no error messages, and the machine seems to be waiting for some event that never happens. The problem has been bisected to

Re: can't boot with reiserfs on linux-4.6.0+

On Tue, May 24, 2016 at 8:59 AM, Al Viro wrote: > > Umm... Any chance of getting the function names to go with the addresses? > I'll try to reproduce it here, but the things would be easier with that > information... Yeah, we shouldn't even allow non-KALLSYMS builds. In fact, unless you pick

Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c

On 05/23/2016 07:18 PM, Al Viro wrote: On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote: The mainline kernels past 4.6.0 fail hang when logging in. There are no error messages, and the machine seems to be waiting for some event that never happens. The problem has been bisected to

Re: [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend

+mjg59, who may be seeing this issue on a skylake laptop Chen-yu, Great debugging, but I think there is a more general fix possible than this DMI quirk. I agree that in this example, a grantley server, it seems the BIOS is erroneously returning a bogus value of MSR_IA32_THERM_CONTROL on resume

Re: [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend

+mjg59, who may be seeing this issue on a skylake laptop Chen-yu, Great debugging, but I think there is a more general fix possible than this DMI quirk. I agree that in this example, a grantley server, it seems the BIOS is erroneously returning a bogus value of MSR_IA32_THERM_CONTROL on resume

Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type

Hello Krzysztof, Krzysztof Kozlowski wrote: > On 05/24/2016 03:49 PM, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> are you sure that these are the only differences. Because AFAIK there >> are quite a few more: >> - DMA submission of commands >> - blend mode / rounding >> - solid fill >> -

Re: [PATCH 1/2] drm/exynos: g2d: Add support for old S5Pv210 type

Hello Krzysztof, Krzysztof Kozlowski wrote: > On 05/24/2016 03:49 PM, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> are you sure that these are the only differences. Because AFAIK there >> are quite a few more: >> - DMA submission of commands >> - blend mode / rounding >> - solid fill >> -

[PATCH net 0/2] Fix spinlock usage in HWBM

Hi, these two patches fix spinlock related issues introduced in v4.6. They have been reported by Russell King and Jean-Jacques Hiblot. Thanks to them, Gregory Gregory CLEMENT (2): net: mvneta: Fix lacking spinlock initialization net: hwbm: Fix unbalanced spinlock in error case

[PATCH net 0/2] Fix spinlock usage in HWBM

Hi, these two patches fix spinlock related issues introduced in v4.6. They have been reported by Russell King and Jean-Jacques Hiblot. Thanks to them, Gregory Gregory CLEMENT (2): net: mvneta: Fix lacking spinlock initialization net: hwbm: Fix unbalanced spinlock in error case

[PATCH net 1/2] net: mvneta: Fix lacking spinlock initialization

The spinlock used by the hwbm functions must be initialized by the network driver. This commit fixes this lack and the following erros when lockdep is enabled: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. []

[PATCH net 1/2] net: mvneta: Fix lacking spinlock initialization

The spinlock used by the hwbm functions must be initialized by the network driver. This commit fixes this lack and the following erros when lockdep is enabled: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. []

[PATCH net 2/2] net: hwbm: Fix unbalanced spinlock in error case

When hwbm_pool_add exited in error the spinlock was not released. This patch fixes this issue. Fixes: 8cb2d8bf57e6 ("net: add a hardware buffer management helper API") Reported-by: Jean-Jacques Hiblot Cc: Signed-off-by: Gregory CLEMENT

[PATCH net 2/2] net: hwbm: Fix unbalanced spinlock in error case

When hwbm_pool_add exited in error the spinlock was not released. This patch fixes this issue. Fixes: 8cb2d8bf57e6 ("net: add a hardware buffer management helper API") Reported-by: Jean-Jacques Hiblot Cc: Signed-off-by: Gregory CLEMENT --- net/core/hwbm.c | 3 +++ 1 file changed, 3

Re: can't boot with reiserfs on linux-4.6.0+

On Tue, May 24, 2016 at 10:10:18PM +0800, Jeff Chua wrote: > Seems to break after index 348619f..d55dc5a 100644 > > Boot up with ext4 works, but try anything to access anything on the > reiser partition such as "/mnt/bin/passwd" resulted in the following > ... > > [ 93.380353] BUG: unable to

Re: can't boot with reiserfs on linux-4.6.0+

On Tue, May 24, 2016 at 10:10:18PM +0800, Jeff Chua wrote: > Seems to break after index 348619f..d55dc5a 100644 > > Boot up with ext4 works, but try anything to access anything on the > reiser partition such as "/mnt/bin/passwd" resulted in the following > ... > > [ 93.380353] BUG: unable to

Re: [PATCH v3] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On 2016/5/23 23:20, Alex Williamson wrote: On Mon, 23 May 2016 11:45:34 +0800 Yongji Xie wrote: On 2016/5/20 6:33, Alex Williamson wrote: On Thu, 12 May 2016 18:20:51 +0800 Yongji Xie wrote: Current vfio-pci implementation

Re: [PATCH v3] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

On 2016/5/23 23:20, Alex Williamson wrote: On Mon, 23 May 2016 11:45:34 +0800 Yongji Xie wrote: On 2016/5/20 6:33, Alex Williamson wrote: On Thu, 12 May 2016 18:20:51 +0800 Yongji Xie wrote: Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs because

Re: [PATCH v4 10/21] fs: Check for invalid i_uid in may_follow_link()

On Tue, Apr 26, 2016 at 02:36:23PM -0500, Seth Forshee wrote: > Filesystem uids which don't map into a user namespace may result > in inode->i_uid being INVALID_UID. A symlink and its parent > could have different owners in the filesystem can both get > mapped to INVALID_UID, which may result in

Re: [PATCH v4 10/21] fs: Check for invalid i_uid in may_follow_link()

On Tue, Apr 26, 2016 at 02:36:23PM -0500, Seth Forshee wrote: > Filesystem uids which don't map into a user namespace may result > in inode->i_uid being INVALID_UID. A symlink and its parent > could have different owners in the filesystem can both get > mapped to INVALID_UID, which may result in

Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations

On 24 May 2016 at 17:02, Morten Rasmussen wrote: > On Tue, May 24, 2016 at 03:52:00PM +0200, Vincent Guittot wrote: >> On 24 May 2016 at 15:36, Morten Rasmussen wrote: >> > On Tue, May 24, 2016 at 03:27:05PM +0200, Vincent Guittot wrote: >> >>

Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations

On 24 May 2016 at 17:02, Morten Rasmussen wrote: > On Tue, May 24, 2016 at 03:52:00PM +0200, Vincent Guittot wrote: >> On 24 May 2016 at 15:36, Morten Rasmussen wrote: >> > On Tue, May 24, 2016 at 03:27:05PM +0200, Vincent Guittot wrote: >> >> On 24 May 2016 at 15:16, Morten Rasmussen >> >>

Re: [PATCH v2 4/5] iommu/mediatek: add support for mtk iommu generation one HW

On 24/05/16 10:57, Honghui Zhang wrote: [...] @@ -48,6 +48,9 @@ struct mtk_iommu_domain { struct io_pgtable_ops *iop; struct iommu_domain domain; + void*pgt_va; + dma_addr_t pgt_pa; + void

Re: [PATCH v2 4/5] iommu/mediatek: add support for mtk iommu generation one HW

On 24/05/16 10:57, Honghui Zhang wrote: [...] @@ -48,6 +48,9 @@ struct mtk_iommu_domain { struct io_pgtable_ops *iop; struct iommu_domain domain; + void*pgt_va; + dma_addr_t pgt_pa; + void

Re: [RFC PATCH] usb: gadget: Introduce Cadence USB2 UDC Driver

Hi Neil, On Tuesday 24 May 2016 16:16:16 Neil Armstrong wrote: > Hi Felipe, Laurent, > > I submitted this driver for a Cadence IP library from a now abandoned > project. > > The driver was working on a SoC platform ported on a FPGA, but I do not have > access to this HW anymore. > > But I have

Re: [RFC PATCH] usb: gadget: Introduce Cadence USB2 UDC Driver

Hi Neil, On Tuesday 24 May 2016 16:16:16 Neil Armstrong wrote: > Hi Felipe, Laurent, > > I submitted this driver for a Cadence IP library from a now abandoned > project. > > The driver was working on a SoC platform ported on a FPGA, but I do not have > access to this HW anymore. > > But I have

Re: [PATCH] power_suply: isp1704_charger: Fix isp1704_write() definition

On Thursday 19 May 2016 11:13:04 Pali Rohár wrote: > On Saturday 09 January 2016 23:42:30 Pali Rohár wrote: > > On Friday 01 January 2016 12:26:21 Pali Rohár wrote: > > > On Friday 01 January 2016 12:03:29 Ivaylo Dimitrov wrote: > > > > All calls to isp1704_write() are using parameter sequence of

Re: [PATCH] power_suply: isp1704_charger: Fix isp1704_write() definition

On Thursday 19 May 2016 11:13:04 Pali Rohár wrote: > On Saturday 09 January 2016 23:42:30 Pali Rohár wrote: > > On Friday 01 January 2016 12:26:21 Pali Rohár wrote: > > > On Friday 01 January 2016 12:03:29 Ivaylo Dimitrov wrote: > > > > All calls to isp1704_write() are using parameter sequence of

Re: bpf: use-after-free in array_map_alloc

Hello, On Tue, May 24, 2016 at 10:40:54AM +0200, Vlastimil Babka wrote: > [+CC Marco who reported the CVE, forgot that earlier] > > On 05/23/2016 11:35 PM, Tejun Heo wrote: > > Hello, > > > > Can you please test whether this patch resolves the issue? While > > adding support for atomic

Re: bpf: use-after-free in array_map_alloc

Hello, On Tue, May 24, 2016 at 10:40:54AM +0200, Vlastimil Babka wrote: > [+CC Marco who reported the CVE, forgot that earlier] > > On 05/23/2016 11:35 PM, Tejun Heo wrote: > > Hello, > > > > Can you please test whether this patch resolves the issue? While > > adding support for atomic

BUG: slab-out-of-bounds in bio_alloc_bioset

Hi all, I've got the following report (slab-out-of-bounds in bio_alloc_bioset) while running syzkaller.The kernel version is 4.6.0-rc7+. (I can reproduce it with syzkaller).Thanks. BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr 8800187a9030 Read of size 4096 by task

BUG: slab-out-of-bounds in bio_alloc_bioset

Hi all, I've got the following report (slab-out-of-bounds in bio_alloc_bioset) while running syzkaller.The kernel version is 4.6.0-rc7+. (I can reproduce it with syzkaller).Thanks. BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr 8800187a9030 Read of size 4096 by task

Re: [PATCH 16/54] MAINTAINERS: Add file patterns for drm device tree bindings

On 23 May 2016 at 13:35, Rob Herring wrote: > On Mon, May 23, 2016 at 4:33 AM, Emil Velikov > wrote: >> On 22 May 2016 at 10:05, Geert Uytterhoeven wrote: >>> Submitters of device tree binding documentation may forget to CC >>>

Re: [PATCH 16/54] MAINTAINERS: Add file patterns for drm device tree bindings

On 23 May 2016 at 13:35, Rob Herring wrote: > On Mon, May 23, 2016 at 4:33 AM, Emil Velikov > wrote: >> On 22 May 2016 at 10:05, Geert Uytterhoeven wrote: >>> Submitters of device tree binding documentation may forget to CC >>> the subsystem maintainer if this is missing. >>> >>>

Re: [Nbd] [PATCH] NBD: replace kill_bdev() with __invalidate_device()

On Thu, May 19, 2016 at 08:35:03AM +0200, Markus Pargmann wrote: > Hi Wouter, > > On Sun, May 15, 2016 at 02:55:39PM +0200, Wouter Verhelst wrote: > > Hi Markus, > > > > On Thu, May 12, 2016 at 11:53:01AM +0200, Markus Pargmann wrote: > > > On Thursday 28 April 2016 18:27:34 Wouter Verhelst

Re: [Nbd] [PATCH] NBD: replace kill_bdev() with __invalidate_device()

On Thu, May 19, 2016 at 08:35:03AM +0200, Markus Pargmann wrote: > Hi Wouter, > > On Sun, May 15, 2016 at 02:55:39PM +0200, Wouter Verhelst wrote: > > Hi Markus, > > > > On Thu, May 12, 2016 at 11:53:01AM +0200, Markus Pargmann wrote: > > > On Thursday 28 April 2016 18:27:34 Wouter Verhelst

Re: [PATCH 1/1] arm64: fix flush_cache_range

On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > > > On 2016/5/24 19:37, Mark Rutland wrote: > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > >> When we ran mprotect04(a test case in LTP) infinitely, it would always > >> failed after a few seconds. The case

Re: [PATCH 1/1] arm64: fix flush_cache_range

On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: > > > On 2016/5/24 19:37, Mark Rutland wrote: > > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: > >> When we ran mprotect04(a test case in LTP) infinitely, it would always > >> failed after a few seconds. The case

Re: [PATCH RFC kernel] balloon: speed up inflating/deflating process

On Tue, May 24, 2016 at 02:36:08PM +, Li, Liang Z wrote: > > > > > > This can be pre-initialized, correct? > > > > > > > > > > pre-initialized? I am not quite understand your mean. > > > > > > > > I think you can maintain sg as part of device state and init sg with the > > bitmap. > > > > > >

Re: [PATCH RFC kernel] balloon: speed up inflating/deflating process

On Tue, May 24, 2016 at 02:36:08PM +, Li, Liang Z wrote: > > > > > > This can be pre-initialized, correct? > > > > > > > > > > pre-initialized? I am not quite understand your mean. > > > > > > > > I think you can maintain sg as part of device state and init sg with the > > bitmap. > > > > > >

RE: livepatch: change to a per-task consistency model

From: Jiri Kosina > Sent: 23 May 2016 19:45 > > Related, please can we have a flag for the sleep and/or process so that > > an uninterruptible sleep doesn't trigger the 'hung task' detector > > TASK_KILLABLE Not sure that does what I want. It appears to allow some 'kill' actions to wake the

RE: livepatch: change to a per-task consistency model

From: Jiri Kosina > Sent: 23 May 2016 19:45 > > Related, please can we have a flag for the sleep and/or process so that > > an uninterruptible sleep doesn't trigger the 'hung task' detector > > TASK_KILLABLE Not sure that does what I want. It appears to allow some 'kill' actions to wake the

Re: [PATCH 1/4] bcache: bch_writeback_thread() is not freezable

On 05/24/2016 08:38 AM, Jiri Kosina wrote: From: Jiri Kosina bch_writeback_thread() is calling try_to_freeze(), but that's just an expensive no-op given the fact that the thread is not marked freezable. I/O helper kthreads, exactly such as the bcache writeback thread,

Re: [PATCH 1/4] bcache: bch_writeback_thread() is not freezable

On 05/24/2016 08:38 AM, Jiri Kosina wrote: From: Jiri Kosina bch_writeback_thread() is calling try_to_freeze(), but that's just an expensive no-op given the fact that the thread is not marked freezable. I/O helper kthreads, exactly such as the bcache writeback thread, actually shouldn't be

[RFC PATCH v2] tools: iio: Rename generic_buffer to iio_generic_buffer

This makes it clear that generic_buffer is an IIO tool and also complies with filename conventions in tools/iio. Signed-off-by: Daniel Baluta --- Changes since v1: * use -M to detect renames and make the patch easier to review tools/iio/Makefile

[RFC PATCH v2] tools: iio: Rename generic_buffer to iio_generic_buffer

This makes it clear that generic_buffer is an IIO tool and also complies with filename conventions in tools/iio. Signed-off-by: Daniel Baluta --- Changes since v1: * use -M to detect renames and make the patch easier to review tools/iio/Makefile | 6

[PATCH v1 1/3] videodev2.h: add V4L2_PIX_FMT_VP9 format.

This adds VP9 video coding format, a successor to VP8. Signed-off-by: Wu-Cheng Li --- include/uapi/linux/videodev2.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 8f95191..a95f940 100644 ---

[PATCH v1 1/3] videodev2.h: add V4L2_PIX_FMT_VP9 format.

This adds VP9 video coding format, a successor to VP8. Signed-off-by: Wu-Cheng Li --- include/uapi/linux/videodev2.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 8f95191..a95f940 100644 ---

[PATCH v1 3/3] V4L: add VP9 format documentation

Add documentation for V4L2_PIX_FMT_VP9. Signed-off-by: Wu-Cheng Li --- Documentation/DocBook/media/v4l/pixfmt.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index

[PATCH v1 0/3] Add V4L2_PIX_FMT_VP9

This patch series add V4L2_PIX_FMT_VP9 and the documentation. Wu-Cheng Li (3): videodev2.h: add V4L2_PIX_FMT_VP9 format. v4l2-ioctl: add VP9 format description. V4L: add VP9 format documentation Documentation/DocBook/media/v4l/pixfmt.xml | 5 + drivers/media/v4l2-core/v4l2-ioctl.c

[PATCH v1 2/3] v4l2-ioctl: add VP9 format description.

VP9 is a video coding format and a successor to VP8. Signed-off-by: Wu-Cheng Li --- drivers/media/v4l2-core/v4l2-ioctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index

[PATCH v1 3/3] V4L: add VP9 format documentation

Add documentation for V4L2_PIX_FMT_VP9. Signed-off-by: Wu-Cheng Li --- Documentation/DocBook/media/v4l/pixfmt.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 5a08aee..ab915c3 100644 ---

[PATCH v1 0/3] Add V4L2_PIX_FMT_VP9

This patch series add V4L2_PIX_FMT_VP9 and the documentation. Wu-Cheng Li (3): videodev2.h: add V4L2_PIX_FMT_VP9 format. v4l2-ioctl: add VP9 format description. V4L: add VP9 format documentation Documentation/DocBook/media/v4l/pixfmt.xml | 5 + drivers/media/v4l2-core/v4l2-ioctl.c

[PATCH v1 2/3] v4l2-ioctl: add VP9 format description.

VP9 is a video coding format and a successor to VP8. Signed-off-by: Wu-Cheng Li --- drivers/media/v4l2-core/v4l2-ioctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 28e5be2..8f3e631 100644 ---

Re: [PATCH] mm: oom_kill_process: do not abort if the victim is exiting

Michal Hocko wrote: > On Tue 24-05-16 15:24:02, Vladimir Davydov wrote: > > After selecting an oom victim, we first check if it's already exiting > > and if it is, we don't bother killing tasks sharing its mm. We do try to > > reap its mm though, but we abort if any of the processes sharing it is

Re: [PATCH] mm: oom_kill_process: do not abort if the victim is exiting

Michal Hocko wrote: > On Tue 24-05-16 15:24:02, Vladimir Davydov wrote: > > After selecting an oom victim, we first check if it's already exiting > > and if it is, we don't bother killing tasks sharing its mm. We do try to > > reap its mm though, but we abort if any of the processes sharing it is

Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations

On Tue, May 24, 2016 at 03:52:00PM +0200, Vincent Guittot wrote: > On 24 May 2016 at 15:36, Morten Rasmussen wrote: > > On Tue, May 24, 2016 at 03:27:05PM +0200, Vincent Guittot wrote: > >> On 24 May 2016 at 15:16, Morten Rasmussen wrote: > >>

Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations

On Tue, May 24, 2016 at 03:52:00PM +0200, Vincent Guittot wrote: > On 24 May 2016 at 15:36, Morten Rasmussen wrote: > > On Tue, May 24, 2016 at 03:27:05PM +0200, Vincent Guittot wrote: > >> On 24 May 2016 at 15:16, Morten Rasmussen wrote: > >> > On Tue, May 24, 2016 at 02:12:38PM +0200, Vincent

[RFC PATCH] tools:iio: Rename generic_buffer

The new name is in agreement with convention for tools/iio programs. Signed-off-by: Daniel Baluta --- tools/iio/Makefile | 6 +- tools/iio/generic_buffer.c | 581 - tools/iio/iio_generic_buffer.c | 581

[RFC PATCH] tools:iio: Rename generic_buffer

The new name is in agreement with convention for tools/iio programs. Signed-off-by: Daniel Baluta --- tools/iio/Makefile | 6 +- tools/iio/generic_buffer.c | 581 - tools/iio/iio_generic_buffer.c | 581

Re: [PATCH 1/3] perf pt: Mark PT return events as "return"

Em Mon, May 23, 2016 at 05:52:23PM -0700, Andi Kleen escreveu: > From: Andi Kleen > > With perf script --itrace=cr we can synthesize calls and returns out of > a PT log. However both calls and returns are marked with the same event, > called branches. This makes it

Re: [PATCH 1/3] perf pt: Mark PT return events as "return"

Em Mon, May 23, 2016 at 05:52:23PM -0700, Andi Kleen escreveu: > From: Andi Kleen > > With perf script --itrace=cr we can synthesize calls and returns out of > a PT log. However both calls and returns are marked with the same event, > called branches. This makes it difficult to read and post

Re: [PATCH 2/3] perf util: Move get_main_thread to thread.c

Em Mon, May 23, 2016 at 05:52:24PM -0700, Andi Kleen escreveu: > From: Andi Kleen > > Move the get_main_thread function from db-export.c to thread.c > so that it can be used elsewhere. After removing the db-export.h leftover junk, applied. - Arnaldo > Signed-off-by:

Re: [PATCH 2/3] perf util: Move get_main_thread to thread.c

Em Mon, May 23, 2016 at 05:52:24PM -0700, Andi Kleen escreveu: > From: Andi Kleen > > Move the get_main_thread function from db-export.c to thread.c > so that it can be used elsewhere. After removing the db-export.h leftover junk, applied. - Arnaldo > Signed-off-by: Andi Kleen > --- >

[GIT PULL] xen: bug fixes for 4.7-rc0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.7-rc0-tag xen: bug fixes for 4.7-rc0 Thanks. David arch/x86/pci/xen.c | 7 +++-- arch/x86/xen/setup.c

[GIT PULL] xen: bug fixes for 4.7-rc0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.7-rc0-tag xen: bug fixes for 4.7-rc0 Thanks. David arch/x86/pci/xen.c | 7 +++-- arch/x86/xen/setup.c

[PATCH] perf/x86/intel/rapl: fix pmus free during cleanup

On rapl cleanup path, kfree() is given by mistake the address of the pointer of the structure to free (rapl_pmus->pmus + i). Pass the pointer instead (rapl_pmus->pmus[i]). This was introduced by commit 9de8d686955b0e8e27847ed4edbbcd280f3fd8 ("perf/x86/intel/rapl: Convert it to a per package

[PATCH] perf/x86/intel/rapl: fix pmus free during cleanup

On rapl cleanup path, kfree() is given by mistake the address of the pointer of the structure to free (rapl_pmus->pmus + i). Pass the pointer instead (rapl_pmus->pmus[i]). This was introduced by commit 9de8d686955b0e8e27847ed4edbbcd280f3fd8 ("perf/x86/intel/rapl: Convert it to a per package

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On 05/12/2016 01:20 PM, Tom Lendacky wrote: > On 05/10/2016 08:57 AM, Borislav Petkov wrote: >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: >>> Is it not possible to maintain some kind of kernel virtual address >>> mapping so memremap*() and friends can figure out when to twiddle

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On 05/12/2016 01:20 PM, Tom Lendacky wrote: > On 05/10/2016 08:57 AM, Borislav Petkov wrote: >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: >>> Is it not possible to maintain some kind of kernel virtual address >>> mapping so memremap*() and friends can figure out when to twiddle

Re: v4.6 kernel BUG at mm/rmap.c:1101!

On Tue, May 24, 2016 at 04:08:09PM +0200, Andrea Arcangeli wrote: > On Tue, May 24, 2016 at 11:12:23AM +0300, Mika Westerberg wrote: > > Hmm, the kernel shipped with Fedora 23 has that enabled: > > > > lahna % grep CONFIG_DEBUG_VM /boot/config-4.4.9-300.fc23.x86_64 > > CONFIG_DEBUG_VM=y > > #

Re: v4.6 kernel BUG at mm/rmap.c:1101!

On Tue, May 24, 2016 at 04:08:09PM +0200, Andrea Arcangeli wrote: > On Tue, May 24, 2016 at 11:12:23AM +0300, Mika Westerberg wrote: > > Hmm, the kernel shipped with Fedora 23 has that enabled: > > > > lahna % grep CONFIG_DEBUG_VM /boot/config-4.4.9-300.fc23.x86_64 > > CONFIG_DEBUG_VM=y > > #

BUG: drm, nouveau: slab-out-of-bounds read access in nv50_fbcon_imageblit()

While testing a kernel with KASan enabled I've encountered several out-of-bounds read warning in the nouveau driver. It seems to be caused by inconsistent alignment requirements. The function soft_cursor() (which I assume draw the cursor on the console) calls fb_get_buffer_offset() which make

BUG: drm, nouveau: slab-out-of-bounds read access in nv50_fbcon_imageblit()

While testing a kernel with KASan enabled I've encountered several out-of-bounds read warning in the nouveau driver. It seems to be caused by inconsistent alignment requirements. The function soft_cursor() (which I assume draw the cursor on the console) calls fb_get_buffer_offset() which make

Re: [PATCH] usb: core: add debugobjects support for urb object

On Tue, May 24, 2016 at 03:53:53PM +0800, changbin...@intel.com wrote: > From: "Du, Changbin" > > Add debugobject support to track the life time of struct urb. > This feature help us detect violation of urb operations by > generating a warning message from debugobject

Re: [PATCH] usb: core: add debugobjects support for urb object

On Tue, May 24, 2016 at 03:53:53PM +0800, changbin...@intel.com wrote: > From: "Du, Changbin" > > Add debugobject support to track the life time of struct urb. > This feature help us detect violation of urb operations by > generating a warning message from debugobject core. And we fix > the

Re: [PATCH] PCI/ASPM: fix reverse ASPM L0s assignment of upstream and downstream

On 5/24/2016 7:53 AM, Bjorn Helgaas wrote: > On Tue, May 24, 2016 at 06:29:44AM +, Ocean HY1 He wrote: >> > In pcie_config_aspm_link(), when convert ASPM state to >> > upstream/downstream ASPM register state, the upstream variable and >> > dwsream variable are reversed. This causes PCI/E link

Re: [PATCH] PCI/ASPM: fix reverse ASPM L0s assignment of upstream and downstream

On 5/24/2016 7:53 AM, Bjorn Helgaas wrote: > On Tue, May 24, 2016 at 06:29:44AM +, Ocean HY1 He wrote: >> > In pcie_config_aspm_link(), when convert ASPM state to >> > upstream/downstream ASPM register state, the upstream variable and >> > dwsream variable are reversed. This causes PCI/E link

Re: [RFC][PATCH 3/3] locking,netfilter: Fix nf_conntrack_lock()

On Tue, May 24, 2016 at 04:27:26PM +0200, Peter Zijlstra wrote: > nf_conntrack_lock{,_all}() is borken as it misses a bunch of memory > barriers to order the whole global vs local locks scheme. > > Even x86 (and other TSO archs) are affected. > > Signed-off-by: Peter Zijlstra (Intel)

Re: [PATCH 4/4] MAINTAINERS: mark bcache as orphan

On Tue, 2016-05-24 at 16:38 +0200, Jiri Kosina wrote: > The submitted patches are not being reacted upon, and Jens is only picking  > up stable fixes on an rather ad-hoc basis. > > Link: lkml.kernel.org/r/574462c5.40...@kernel.dk > Signed-off-by: Jiri Kosina > --- >  

Re: [RFC][PATCH 3/3] locking,netfilter: Fix nf_conntrack_lock()

On Tue, May 24, 2016 at 04:27:26PM +0200, Peter Zijlstra wrote: > nf_conntrack_lock{,_all}() is borken as it misses a bunch of memory > barriers to order the whole global vs local locks scheme. > > Even x86 (and other TSO archs) are affected. > > Signed-off-by: Peter Zijlstra (Intel) > --- >

Re: [PATCH 4/4] MAINTAINERS: mark bcache as orphan

On Tue, 2016-05-24 at 16:38 +0200, Jiri Kosina wrote: > The submitted patches are not being reacted upon, and Jens is only picking  > up stable fixes on an rather ad-hoc basis. > > Link: lkml.kernel.org/r/574462c5.40...@kernel.dk > Signed-off-by: Jiri Kosina > --- >  MAINTAINERS | 2 +- >  1

[PATCH 3/4] bcache: bch_gc_thread() is not freezable

From: Jiri Kosina bch_gc_thread() doesn't mark itself freezable, so calling try_to_freeze() in its context is just an expensive no-op. Signed-off-by: Jiri Kosina --- drivers/md/bcache/btree.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH 2/4] bcache: bch_allocator_thread() is not freezable

From: Jiri Kosina bch_allocator_thread() is calling try_to_freeze(), but that's just an expensive no-op given the fact that the thread is not marked freezable. Bucket allocator has to be up and running to the very last stages of the suspend, as the bcache I/O that's in flight

Re: [PATCH v2] kernel/kcov: unproxify debugfs file's fops

This issue has been debugged and reported by > Sasha Levin <sasha.le...@oracle.com>: > http://lkml.kernel.org/g/573f4200.3080...@oracle.com > > Applicable to linux-next 20160524. > In particular, it depends on > - c64688081490 ("debugfs: add support for self-prot

[RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

Introduce smp_acquire__after_ctrl_dep(), this construct is not uncommen, but the lack of this barrier is. Signed-off-by: Peter Zijlstra (Intel) --- include/linux/compiler.h | 14 ++ ipc/sem.c| 14 ++ 2 files changed, 12

[PATCH 3/4] bcache: bch_gc_thread() is not freezable

From: Jiri Kosina bch_gc_thread() doesn't mark itself freezable, so calling try_to_freeze() in its context is just an expensive no-op. Signed-off-by: Jiri Kosina --- drivers/md/bcache/btree.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/md/bcache/btree.c

[PATCH 2/4] bcache: bch_allocator_thread() is not freezable

From: Jiri Kosina bch_allocator_thread() is calling try_to_freeze(), but that's just an expensive no-op given the fact that the thread is not marked freezable. Bucket allocator has to be up and running to the very last stages of the suspend, as the bcache I/O that's in flight (think of

Re: [PATCH v2] kernel/kcov: unproxify debugfs file's fops

gt; http://lkml.kernel.org/g/1464011147-31836-1-git-send-email-nicsta...@gmail.com > > Changes to v1: > - Following the suggestion of Kees Cook, a comment explaining why the use >of debugfs_create_file_unsafe() is actually safe there has been added. > > This issue has been d

[RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

Introduce smp_acquire__after_ctrl_dep(), this construct is not uncommen, but the lack of this barrier is. Signed-off-by: Peter Zijlstra (Intel) --- include/linux/compiler.h | 14 ++ ipc/sem.c| 14 ++ 2 files changed, 12 insertions(+), 16 deletions(-)

<    4   5   6   7   8   9   10   11   12   13   >