Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

a note to help improve the system] url: https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/add-support-for-Bluetooth-on-MT7622-SoC/20180403-160035 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse

[RFC PATCH] Bluetooth: hci_mediatek: mtk_recv_frame() can be static

Fixes: 9f2aacacb185 ("Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices") Signed-off-by: Fengguang Wu --- hci_mediatek.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bluetooth/hci_mediatek.c b/drivers/bluetooth/hci_mediatek.c index

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

On 04/03/2018 02:40 PM, Maxime Ripard wrote: On Tue, Apr 03, 2018 at 02:08:43PM +0300, Sergey Suloev wrote: On 04/03/2018 11:10 AM, Maxime Ripard wrote: On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote: There is no need to handle 3/4 empty/full interrupts as the maximum supported

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

On 04/03/2018 02:40 PM, Maxime Ripard wrote: On Tue, Apr 03, 2018 at 02:08:43PM +0300, Sergey Suloev wrote: On 04/03/2018 11:10 AM, Maxime Ripard wrote: On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote: There is no need to handle 3/4 empty/full interrupts as the maximum supported

[PATCH] kernel/bpf/syscall: fix warning defined but not used

There will be a build warning -Wunused-function if CONFIG_CGROUP_BPF isn't defined, since the only user is inside #ifdef CONFIG_CGROUP_BPF: kernel/bpf/syscall.c:1229:12: warning: ‘bpf_prog_attach_check_attach_type’ defined but not used [-Wunused-function] static int

[PATCH] kernel/bpf/syscall: fix warning defined but not used

There will be a build warning -Wunused-function if CONFIG_CGROUP_BPF isn't defined, since the only user is inside #ifdef CONFIG_CGROUP_BPF: kernel/bpf/syscall.c:1229:12: warning: ‘bpf_prog_attach_check_attach_type’ defined but not used [-Wunused-function] static int

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 11:51:18AM +0200, Ingo Molnar wrote: > If it's being relied on, or if there's actually something firmly planned, > which we could track, then I'd have no problem with reverting this change > and waiting one more kernel cycle or so. I don't see why the clang people can't go

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 11:51:18AM +0200, Ingo Molnar wrote: > If it's being relied on, or if there's actually something firmly planned, > which we could track, then I'd have no problem with reverting this change > and waiting one more kernel cycle or so. I don't see why the clang people can't go

Re: WARNING in account_page_dirtied

Hello, On Sun 01-04-18 10:01:02, syzbot wrote: > syzbot hit the following crash on upstream commit > 10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 2018 +) > Merge branch 'perf-urgent-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > syzbot dashboard link:

Re: WARNING in account_page_dirtied

Hello, On Sun 01-04-18 10:01:02, syzbot wrote: > syzbot hit the following crash on upstream commit > 10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 2018 +) > Merge branch 'perf-urgent-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > syzbot dashboard link:

[PATCH] media: gspca: fix Kconfig help info

Documentation/video4linux/gspca.txt is missing. It has moved to Documentation/media/v4l-drivers/gspca-cardlist.rst Signed-off-by: winton.liu <18502523...@163.com> --- drivers/media/usb/gspca/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] media: gspca: fix Kconfig help info

Documentation/video4linux/gspca.txt is missing. It has moved to Documentation/media/v4l-drivers/gspca-cardlist.rst Signed-off-by: winton.liu <18502523...@163.com> --- drivers/media/usb/gspca/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

RE: [PATCH v3 00/13] remoteproc: add fixed memory region support

Hi Bjorn, Just a gentle ping... As discussed during Linaro connect, I'll appreciate if you can share me your comments... Regards, Loic > -Original Message- > From: Loic PALLARDY > Sent: Thursday, March 01, 2018 5:24 PM > To: bjorn.anders...@linaro.org; o...@wizery.com > Cc:

RE: [PATCH v3 00/13] remoteproc: add fixed memory region support

Hi Bjorn, Just a gentle ping... As discussed during Linaro connect, I'll appreciate if you can share me your comments... Regards, Loic > -Original Message- > From: Loic PALLARDY > Sent: Thursday, March 01, 2018 5:24 PM > To: bjorn.anders...@linaro.org; o...@wizery.com > Cc:

[GIT pull] irq updates for 4.17

Linus, please pull the latest irq-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus The usual pile of boring changes: - Consolidate tasklet functions to share code instead of duplicating it - The first step for making the low level

[GIT pull] irq updates for 4.17

Linus, please pull the latest irq-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus The usual pile of boring changes: - Consolidate tasklet functions to share code instead of duplicating it - The first step for making the low level

Re: [RFC] Is it correctly that the usage for spin_{lock|unlock}_irq in clear_page_dirty_for_io

On Mon 02-04-18 19:50:50, Wang Long wrote: > > Hi,  Johannes Weiner and Tejun Heo > > I use linux-4.4.y to test the new cgroup controller io and the current > stable kernel linux-4.4.y has the follow logic > > > int clear_page_dirty_for_io(struct page *page){ > ... > ... >    

Re: [RFC] Is it correctly that the usage for spin_{lock|unlock}_irq in clear_page_dirty_for_io

On Mon 02-04-18 19:50:50, Wang Long wrote: > > Hi,  Johannes Weiner and Tejun Heo > > I use linux-4.4.y to test the new cgroup controller io and the current > stable kernel linux-4.4.y has the follow logic > > > int clear_page_dirty_for_io(struct page *page){ > ... > ... >    

Re: [PATCH] selftests/ftrace: fix spelling mistake: "tiggers" -> "triggers"

On Tue, 3 Apr 2018, Steven Rostedt wrote: > On Tue, 3 Apr 2018 13:07:05 +0300 > Dan Carpenter wrote: > > > On Fri, Mar 30, 2018 at 09:51:21AM -0600, Shuah Khan wrote: > > > On 03/29/2018 12:04 PM, Steven Rostedt wrote: > > > > On Thu, 29 Mar 2018 11:54:28 -0600 > > >

Re: [PATCH] selftests/ftrace: fix spelling mistake: "tiggers" -> "triggers"

On Tue, 3 Apr 2018, Steven Rostedt wrote: > On Tue, 3 Apr 2018 13:07:05 +0300 > Dan Carpenter wrote: > > > On Fri, Mar 30, 2018 at 09:51:21AM -0600, Shuah Khan wrote: > > > On 03/29/2018 12:04 PM, Steven Rostedt wrote: > > > > On Thu, 29 Mar 2018 11:54:28 -0600 > > > > Shuah Khan wrote: > > >

Re: linux-next: manual merge of the selinux tree with the security tree

On Tue, Apr 3, 2018 at 12:43 AM, Stephen Rothwell wrote: > Hi Paul, > > Today's linux-next merge of the selinux tree got a conflict in: > > include/linux/lsm_hooks.h > > between commit: > > 22402b0b736d ("security: convert security hooks to use hlist") > > from the

Re: linux-next: manual merge of the selinux tree with the security tree

On Tue, Apr 3, 2018 at 12:43 AM, Stephen Rothwell wrote: > Hi Paul, > > Today's linux-next merge of the selinux tree got a conflict in: > > include/linux/lsm_hooks.h > > between commit: > > 22402b0b736d ("security: convert security hooks to use hlist") > > from the security tree and commit: >

Re: [PATCH] selftests/ftrace: fix spelling mistake: "tiggers" -> "triggers"

On Tue, 3 Apr 2018 13:07:05 +0300 Dan Carpenter wrote: > On Fri, Mar 30, 2018 at 09:51:21AM -0600, Shuah Khan wrote: > > On 03/29/2018 12:04 PM, Steven Rostedt wrote: > > > On Thu, 29 Mar 2018 11:54:28 -0600 > > > Shuah Khan wrote: > > > > > >> I

Re: [PATCH] selftests/ftrace: fix spelling mistake: "tiggers" -> "triggers"

On Tue, 3 Apr 2018 13:07:05 +0300 Dan Carpenter wrote: > On Fri, Mar 30, 2018 at 09:51:21AM -0600, Shuah Khan wrote: > > On 03/29/2018 12:04 PM, Steven Rostedt wrote: > > > On Thu, 29 Mar 2018 11:54:28 -0600 > > > Shuah Khan wrote: > > > > > >> I will pick this up with your Ack Steve,

Re: [PATCH] vhost-net: add limitation of sent packets for tx polling

On Tue, Apr 03, 2018 at 08:08:26AM +, haibinzhang(张海斌) wrote: > handle_tx will delay rx for a long time when tx busy polling udp packets > with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT > takes into account only sent-bytes but no single packet length. > > Tests

Re: [PATCH] vhost-net: add limitation of sent packets for tx polling

On Tue, Apr 03, 2018 at 08:08:26AM +, haibinzhang(张海斌) wrote: > handle_tx will delay rx for a long time when tx busy polling udp packets > with small length(e.g. 1byte udp payload), because setting VHOST_NET_WEIGHT > takes into account only sent-bytes but no single packet length. > > Tests

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue, 2018-04-03 at 13:52 +0200, Petr Mladek wrote: > On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote: > > On (04/02/18 17:15), Andy Shevchenko wrote: > > > > > > > > Hmm, I have never seen the error code in this form. > > > > > > We have limited space to print it and error numbers

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue, 2018-04-03 at 13:52 +0200, Petr Mladek wrote: > On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote: > > On (04/02/18 17:15), Andy Shevchenko wrote: > > > > > > > > Hmm, I have never seen the error code in this form. > > > > > > We have limited space to print it and error numbers

Re: [PATCH v8 0/4] Fix issues with huge mapping in ioremap for ARM64

On 4/3/2018 2:13 PM, Marc Zyngier wrote: Hi Chintan, Hi Marc, On 03/04/18 09:00, Chintan Pandya wrote: This series of patches are follow up work (and depends on) Toshi Kani 's patches "fix memory leak/ panic in ioremap huge pages". This series of patches are tested on

Re: [PATCH v8 0/4] Fix issues with huge mapping in ioremap for ARM64

On 4/3/2018 2:13 PM, Marc Zyngier wrote: Hi Chintan, Hi Marc, On 03/04/18 09:00, Chintan Pandya wrote: This series of patches are follow up work (and depends on) Toshi Kani 's patches "fix memory leak/ panic in ioremap huge pages". This series of patches are tested on 4.9 kernel with

Re: [PATCH v6 RESEND 0/1] drm/xen-front: Add support for Xen PV display frontend

On 04/03/2018 02:23 PM, Oleksandr Andrushchenko wrote: Resending with even more checkpatch code-style fixes. Applied, thank you!

Re: [PATCH v6 RESEND 0/1] drm/xen-front: Add support for Xen PV display frontend

On 04/03/2018 02:23 PM, Oleksandr Andrushchenko wrote: Resending with even more checkpatch code-style fixes. Applied, thank you!

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote: > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote: > > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote: > > > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote: > > > > > On

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote: > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote: > > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote: > > > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote: > > > > > On

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote: > On (04/02/18 17:15), Andy Shevchenko wrote: > > > > > > Hmm, I have never seen the error code in this form. > > > > We have limited space to print it and error numbers currently can be up > > to 0xfff (4095). So, I have no better idea how

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote: > On (04/02/18 17:15), Andy Shevchenko wrote: > > > > > > Hmm, I have never seen the error code in this form. > > > > We have limited space to print it and error numbers currently can be up > > to 0xfff (4095). So, I have no better idea how

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 13:06:12 +0200 Michal Hocko wrote: > > I wonder if I should have the ring buffer allocate groups of pages, to > > avoid this. Or try to allocate with NORETRY, one page at a time, and > > when that fails, allocate groups of pages with RETRY_MAYFAIL, and that

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue, 3 Apr 2018 13:06:12 +0200 Michal Hocko wrote: > > I wonder if I should have the ring buffer allocate groups of pages, to > > avoid this. Or try to allocate with NORETRY, one page at a time, and > > when that fails, allocate groups of pages with RETRY_MAYFAIL, and that > > may keep it

Re: [PATCH v8 06/18] ext2, dax: introduce ext2_dax_aops

On Fri 30-03-18 21:02:41, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Otherwise, direct-I/O > triggers incorrect page cache assumptions and

Re: [PATCH v8 06/18] ext2, dax: introduce ext2_dax_aops

On Fri 30-03-18 21:02:41, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Otherwise, direct-I/O > triggers incorrect page cache assumptions and

Re: [PATCH v8 05/18] ext4, dax: introduce ext4_dax_aops

On Fri 30-03-18 21:02:36, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Otherwise, direct-I/O > triggers incorrect page cache assumptions and

Re: [PATCH v8 05/18] ext4, dax: introduce ext4_dax_aops

On Fri 30-03-18 21:02:36, Dan Williams wrote: > In preparation for the dax implementation to start associating dax pages > to inodes via page->mapping, we need to provide a 'struct > address_space_operations' instance for dax. Otherwise, direct-I/O > triggers incorrect page cache assumptions and

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote: > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote: > > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote: > > > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote: > > > > > > I

Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers

On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote: > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote: > > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote: > > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote: > > > > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote: > > > > > > I

[GIT PULL] EDAC tree for 4.17

Hi Linus, here's this round of EDAC updates. Noteworthy is the NVDIMM support by Tony Luck. Please pull, thanks! --- The following changes since commit bf8486709ac7fad99e4040dea73fe466c57a4ae1: EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL (2018-02-23 12:05:37

[GIT PULL] EDAC tree for 4.17

Hi Linus, here's this round of EDAC updates. Noteworthy is the NVDIMM support by Tony Luck. Please pull, thanks! --- The following changes since commit bf8486709ac7fad99e4040dea73fe466c57a4ae1: EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL (2018-02-23 12:05:37

Re: [lkp-robot] [sched/fair] d519329f72: unixbench.score -9.9% regression

Hi Xiaolong, On 02-Apr 11:20, kernel test robot wrote: > > Greeting, > > FYI, we noticed a -9.9% regression of unixbench.score due to commit: thanks for the report, I'll try to reproduce it locally to better understand what's going on. Meanwhile, I'm a little puzzled about some of the

[PATCH] f2fs: remove unmatched zero_user_segment when convert inline dentry

Since the layout of regular dentry block is different from inline dentry block, zero_user_segment starting from MAX_INLINE_DATA(dir) is not correct for regular dentry block, besides, bitmap is already copied and used, so there is no necessary to zero page at all, so just remove the

[PATCH] f2fs: remove unmatched zero_user_segment when convert inline dentry

Since the layout of regular dentry block is different from inline dentry block, zero_user_segment starting from MAX_INLINE_DATA(dir) is not correct for regular dentry block, besides, bitmap is already copied and used, so there is no necessary to zero page at all, so just remove the

Re: [lkp-robot] [sched/fair] d519329f72: unixbench.score -9.9% regression

Hi Xiaolong, On 02-Apr 11:20, kernel test robot wrote: > > Greeting, > > FYI, we noticed a -9.9% regression of unixbench.score due to commit: thanks for the report, I'll try to reproduce it locally to better understand what's going on. Meanwhile, I'm a little puzzled about some of the

Re: possible deadlock in skb_queue_tail

On 03.04.2018 14:25, Dmitry Vyukov wrote: > On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai wrote: >> On 02.04.2018 12:20, syzbot wrote: >>> Hello, >>> >>> syzbot hit the following crash on net-next commit >>> 06b19fe9a6df7aaa423cd8404ebe5ac9ec4b2960 (Sun Apr 1 03:37:33 2018

Re: possible deadlock in skb_queue_tail

On 03.04.2018 14:25, Dmitry Vyukov wrote: > On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai wrote: >> On 02.04.2018 12:20, syzbot wrote: >>> Hello, >>> >>> syzbot hit the following crash on net-next commit >>> 06b19fe9a6df7aaa423cd8404ebe5ac9ec4b2960 (Sun Apr 1 03:37:33 2018 +) >>> Merge branch

Re: [PATCH 3/4] mm: Add free()

On Tue, Apr 03, 2018 at 10:50:59AM +0200, Pavel Machek wrote: > > gcc already does some nice optimisations around free(). For example, it > > can eliminate dead stores: > > Are we comfortable with that optimalization for kernel? > > us: "Hey, let's remove those encryption keys before freeing

Re: [PATCH 3/4] mm: Add free()

On Tue, Apr 03, 2018 at 10:50:59AM +0200, Pavel Machek wrote: > > gcc already does some nice optimisations around free(). For example, it > > can eliminate dead stores: > > Are we comfortable with that optimalization for kernel? > > us: "Hey, let's remove those encryption keys before freeing

Re: NO_HZ_FULL and tick running within a reasonable amount of time

On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote: > Hello! > > I am hitting the following on today's mainline under rcutorture, but > only on scenarios built with CONFIG_NO_HZ_FULL=y: > > > > WARNING: CPU:

Re: NO_HZ_FULL and tick running within a reasonable amount of time

On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote: > Hello! > > I am hitting the following on today's mainline under rcutorture, but > only on scenarios built with CONFIG_NO_HZ_FULL=y: > > > > WARNING: CPU:

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

On Tue, Apr 03, 2018 at 02:08:43PM +0300, Sergey Suloev wrote: > On 04/03/2018 11:10 AM, Maxime Ripard wrote: > > On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote: > > > There is no need to handle 3/4 empty/full interrupts as the maximum > > > supported transfer length in PIO mode is

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

On Tue, Apr 03, 2018 at 02:08:43PM +0300, Sergey Suloev wrote: > On 04/03/2018 11:10 AM, Maxime Ripard wrote: > > On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote: > > > There is no need to handle 3/4 empty/full interrupts as the maximum > > > supported transfer length in PIO mode is

Re: [PATCH v3 2/6] Disable instrumentation for some code

On Tue, Apr 03, 2018 at 12:30:42PM +0100, Marc Zyngier wrote: > On 02/04/18 13:04, Abbott Liu wrote: > > From: Andrey Ryabinin > > > > Disable instrumentation for arch/arm/boot/compressed/* > > ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those > > code won't linkd

Re: [PATCH v3 2/6] Disable instrumentation for some code

On Tue, Apr 03, 2018 at 12:30:42PM +0100, Marc Zyngier wrote: > On 02/04/18 13:04, Abbott Liu wrote: > > From: Andrey Ryabinin > > > > Disable instrumentation for arch/arm/boot/compressed/* > > ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those > > code won't linkd with kernel image. > > > >

Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

On Tue 03-04-18 14:16:18, Kirill A. Shutemov wrote: > On Tue, Apr 03, 2018 at 12:58:15PM +0200, Michal Hocko wrote: > > On Tue 03-04-18 13:54:11, Kirill A. Shutemov wrote: > > > On Tue, Apr 03, 2018 at 10:34:51AM +0200, Michal Hocko wrote: > > > > On Tue 03-04-18 08:24:06, Naoya Horiguchi wrote: >

Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

On Tue 03-04-18 14:16:18, Kirill A. Shutemov wrote: > On Tue, Apr 03, 2018 at 12:58:15PM +0200, Michal Hocko wrote: > > On Tue 03-04-18 13:54:11, Kirill A. Shutemov wrote: > > > On Tue, Apr 03, 2018 at 10:34:51AM +0200, Michal Hocko wrote: > > > > On Tue 03-04-18 08:24:06, Naoya Horiguchi wrote: >

Re: [PATCH] mmc: dw_mmc-k3: Fix DDR52 mode by setting required clock divisor

On 2018/3/30 2:24, oscardagrach wrote: Need at least one line commit body. Signed-off-by: oscardagrach --- drivers/mmc/host/dw_mmc-k3.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c

Re: [PATCH] mmc: dw_mmc-k3: Fix DDR52 mode by setting required clock divisor

On 2018/3/30 2:24, oscardagrach wrote: Need at least one line commit body. Signed-off-by: oscardagrach --- drivers/mmc/host/dw_mmc-k3.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c index

Re: [PATCH v4 1/2] staging: vt6655: check for memory allocation failures

This will crash. Please see my comments that I just posted to v3. regards, dan carpenter

Re: [PATCH v4 1/2] staging: vt6655: check for memory allocation failures

This will crash. Please see my comments that I just posted to v3. regards, dan carpenter

Re: [PATCH v3 2/6] Disable instrumentation for some code

On 02/04/18 13:04, Abbott Liu wrote: > From: Andrey Ryabinin > > Disable instrumentation for arch/arm/boot/compressed/* > ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those > code won't linkd with kernel image. > > Disable kasan check in the function

Re: [PATCH v3 2/6] Disable instrumentation for some code

On 02/04/18 13:04, Abbott Liu wrote: > From: Andrey Ryabinin > > Disable instrumentation for arch/arm/boot/compressed/* > ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those > code won't linkd with kernel image. > > Disable kasan check in the function unwind_pop_register > because it doesn't

Re: [PATCH v3 01/14] KVM: s390: refactor crypto initialization

On Thu, 29 Mar 2018 14:57:22 -0400 Tony Krowiak wrote: > On 03/26/2018 04:44 AM, Cornelia Huck wrote: > > On Thu, 15 Mar 2018 15:55:39 +0100 > > Pierre Morel wrote: > > > >> On 15/03/2018 15:48, Tony Krowiak wrote: > >>> On 03/15/2018

Re: [PATCH v3 01/14] KVM: s390: refactor crypto initialization

On Thu, 29 Mar 2018 14:57:22 -0400 Tony Krowiak wrote: > On 03/26/2018 04:44 AM, Cornelia Huck wrote: > > On Thu, 15 Mar 2018 15:55:39 +0100 > > Pierre Morel wrote: > > > >> On 15/03/2018 15:48, Tony Krowiak wrote: > >>> On 03/15/2018 08:26 AM, Pierre Morel wrote: > On 14/03/2018

Re: possible deadlock in skb_queue_tail

On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai wrote: > On 02.04.2018 12:20, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on net-next commit >> 06b19fe9a6df7aaa423cd8404ebe5ac9ec4b2960 (Sun Apr 1 03:37:33 2018 +) >> Merge branch 'chelsio-inline-tls' >>

Re: possible deadlock in skb_queue_tail

On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai wrote: > On 02.04.2018 12:20, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on net-next commit >> 06b19fe9a6df7aaa423cd8404ebe5ac9ec4b2960 (Sun Apr 1 03:37:33 2018 +) >> Merge branch 'chelsio-inline-tls' >> syzbot dashboard link:

[PATCH v6 RESEND 1/1] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Add support for Xen para-virtualized frontend display driver. Accompanying backend [1] is implemented as a user-space application and its helper library [2], capable of running as a Weston client or DRM master. Configuration of both

[PATCH v6 RESEND 1/1] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Add support for Xen para-virtualized frontend display driver. Accompanying backend [1] is implemented as a user-space application and its helper library [2], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via

Re: [PATCH] genirq: only scan the present CPUs

On Tue, Apr 03, 2018 at 12:25:56PM +0200, Thomas Gleixner wrote: > On Mon, 2 Apr 2018, Li RongQing wrote: > > > lots of application will read /proc/stat, like ps and vmstat, but we > > find the reading time are spreading on Purley platform which has lots > > of possible CPUs and interrupt. > > >

Re: [PATCH] genirq: only scan the present CPUs

On Tue, Apr 03, 2018 at 12:25:56PM +0200, Thomas Gleixner wrote: > On Mon, 2 Apr 2018, Li RongQing wrote: > > > lots of application will read /proc/stat, like ps and vmstat, but we > > find the reading time are spreading on Purley platform which has lots > > of possible CPUs and interrupt. > > >

[PATCH v6 RESEND 0/1] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Resending with even more checkpatch code-style fixes. Hello! Boris/Daniel, I put your R-b tags, so please do let me know if this is not acceptable, so I remove the tags. This patch series adds support for Xen [1] para-virtualized

[PATCH v6 RESEND 0/1] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Resending with even more checkpatch code-style fixes. Hello! Boris/Daniel, I put your R-b tags, so please do let me know if this is not acceptable, so I remove the tags. This patch series adds support for Xen [1] para-virtualized frontend display driver. It

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

On 04/03/2018 11:10 AM, Maxime Ripard wrote: On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote: There is no need to handle 3/4 empty/full interrupts as the maximum supported transfer length in PIO mode is 64 bytes for sun4i-family SoCs. That assumes that you'll be able to treat the

Re: [PATCH 2/6] spi: sun4i: restrict transfer length in PIO-mode

On 04/03/2018 11:10 AM, Maxime Ripard wrote: On Thu, Mar 29, 2018 at 09:59:03PM +0300, Sergey Suloev wrote: There is no need to handle 3/4 empty/full interrupts as the maximum supported transfer length in PIO mode is 64 bytes for sun4i-family SoCs. That assumes that you'll be able to treat the

Re: [PATCH v1] xen-blkfront: dynamic configuration of per-vbd resources

On Mon, Apr 02, 2018 at 01:42:32PM -0400, Konrad Rzeszutek Wilk wrote: > From: Bob Liu > > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount

Re: [PATCH v1] xen-blkfront: dynamic configuration of per-vbd resources

On Mon, Apr 02, 2018 at 01:42:32PM -0400, Konrad Rzeszutek Wilk wrote: > From: Bob Liu > > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount of segments. > *

Re: [PATCH v4 2/2] staging: vt6655: add handling memory leak on vnt_start()

On Fri, Mar 30, 2018 at 02:51:55PM +0900, Ji-Hun Kim wrote: > There was no code for handling memory leaks of device_init_rings() and > request_irq(). It needs to free allocated memory in the device_init_rings() > , when request_irq() is failed. Add freeing sequences of irq and device > init rings.

Re: [PATCH v4 2/2] staging: vt6655: add handling memory leak on vnt_start()

On Fri, Mar 30, 2018 at 02:51:55PM +0900, Ji-Hun Kim wrote: > There was no code for handling memory leaks of device_init_rings() and > request_irq(). It needs to free allocated memory in the device_init_rings() > , when request_irq() is failed. Add freeing sequences of irq and device > init rings.

Re: [PATCH v3 09/14] s390: vfio-ap: sysfs interfaces to configure domains

On Wed, 14 Mar 2018 14:25:49 -0400 Tony Krowiak wrote: > Provides the sysfs interfaces for assigning AP domains to > and unassigning AP domains from a mediated matrix device. > > An AP domain ID corresponds to an AP queue index (APQI). For > each domain assigned to

Re: [PATCH v3 09/14] s390: vfio-ap: sysfs interfaces to configure domains

On Wed, 14 Mar 2018 14:25:49 -0400 Tony Krowiak wrote: > Provides the sysfs interfaces for assigning AP domains to > and unassigning AP domains from a mediated matrix device. > > An AP domain ID corresponds to an AP queue index (APQI). For > each domain assigned to the mediated matrix device,

Re: general protection fault in __mem_cgroup_free

On 04/03/2018 01:50 PM, Michal Hocko wrote: > Here we go > > From 38f0f08a3f9f19c106ae53350e43dc97e2e3a4d8 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Tue, 3 Apr 2018 12:40:41 +0200 > Subject: [PATCH] memcg: fix per_node_info cleanup > > syzbot has triggered a NULL

Re: general protection fault in __mem_cgroup_free

On 04/03/2018 01:50 PM, Michal Hocko wrote: > Here we go > > From 38f0f08a3f9f19c106ae53350e43dc97e2e3a4d8 Mon Sep 17 00:00:00 2001 > From: Michal Hocko > Date: Tue, 3 Apr 2018 12:40:41 +0200 > Subject: [PATCH] memcg: fix per_node_info cleanup > > syzbot has triggered a NULL ptr dereference

Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

On Tue, Apr 03, 2018 at 12:58:15PM +0200, Michal Hocko wrote: > On Tue 03-04-18 13:54:11, Kirill A. Shutemov wrote: > > On Tue, Apr 03, 2018 at 10:34:51AM +0200, Michal Hocko wrote: > > > On Tue 03-04-18 08:24:06, Naoya Horiguchi wrote: > > > > On Tue, Apr 03, 2018 at 09:59:28AM +0200, Michal

Re: [PATCH v1] mm: consider non-anonymous thp as unmovable page

On Tue, Apr 03, 2018 at 12:58:15PM +0200, Michal Hocko wrote: > On Tue 03-04-18 13:54:11, Kirill A. Shutemov wrote: > > On Tue, Apr 03, 2018 at 10:34:51AM +0200, Michal Hocko wrote: > > > On Tue 03-04-18 08:24:06, Naoya Horiguchi wrote: > > > > On Tue, Apr 03, 2018 at 09:59:28AM +0200, Michal

Re: [PATCH v5 08/13] ARM: sunxi: Add initialization of CNTVOFF

Hi Mylène, Thank you for the patch! Yet something to improve: [auto build test ERROR on arm-soc/for-next] [also build test ERROR on next-20180403] [cannot apply to v4.16] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH v5 08/13] ARM: sunxi: Add initialization of CNTVOFF

Hi Mylène, Thank you for the patch! Yet something to improve: [auto build test ERROR on arm-soc/for-next] [also build test ERROR on next-20180403] [cannot apply to v4.16] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH v2 2/2] io: prevent compiler reordering on the default readX() implementation

On Tue, Apr 3, 2018 at 12:49 PM, Mark Rutland wrote: > Hi, > > On Fri, Mar 30, 2018 at 11:58:13AM -0400, Sinan Kaya wrote: >> The default implementation of mapping readX() to __raw_readX() is wrong. >> readX() has stronger ordering semantics. Compiler is allowed to reorder

Re: [PATCH v2 2/2] io: prevent compiler reordering on the default readX() implementation

On Tue, Apr 3, 2018 at 12:49 PM, Mark Rutland wrote: > Hi, > > On Fri, Mar 30, 2018 at 11:58:13AM -0400, Sinan Kaya wrote: >> The default implementation of mapping readX() to __raw_readX() is wrong. >> readX() has stronger ordering semantics. Compiler is allowed to reorder >> __raw_readX(). > >

How to get lockref patch merged?

Hello, what's the best way to get the following lockref patch merged? The maintainers file doesn't list a maintainer. Should we go straight to Linus? Does one of you want to take it? We have a gfs2 patch that depends on it. Thanks, Andreas -- Forwarded message -- From: Andreas

How to get lockref patch merged?

Hello, what's the best way to get the following lockref patch merged? The maintainers file doesn't list a maintainer. Should we go straight to Linus? Does one of you want to take it? We have a gfs2 patch that depends on it. Thanks, Andreas -- Forwarded message -- From: Andreas

RE: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support

Hello Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, April 2, 2018 4:45 PM > To: Ioana Ciornei > Cc: Arnd Bergmann ; gregkh > ; Laurentiu Tudor > ; Linux

RE: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support

Hello Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, April 2, 2018 4:45 PM > To: Ioana Ciornei > Cc: Arnd Bergmann ; gregkh > ; Laurentiu Tudor > ; Linux Kernel Mailing List ker...@vger.kernel.org>; Stuart Yoder ; Ruxandra > Ioana Ciocoi

[tip:x86/urgent] x86/mm: Fix documentation of module mapping range with 4-level paging

Commit-ID: 9a3b7e5e65c4b4d332df5f607c0838c3fb918673 Gitweb: https://git.kernel.org/tip/9a3b7e5e65c4b4d332df5f607c0838c3fb918673 Author: Kirill A. Shutemov AuthorDate: Mon, 2 Apr 2018 15:10:25 +0300 Committer: Ingo Molnar CommitDate:

[tip:x86/urgent] x86/mm: Fix documentation of module mapping range with 4-level paging

Commit-ID: 9a3b7e5e65c4b4d332df5f607c0838c3fb918673 Gitweb: https://git.kernel.org/tip/9a3b7e5e65c4b4d332df5f607c0838c3fb918673 Author: Kirill A. Shutemov AuthorDate: Mon, 2 Apr 2018 15:10:25 +0300 Committer: Ingo Molnar CommitDate: Tue, 3 Apr 2018 12:59:02 +0200 x86/mm: Fix

<    9   10   11   12   13   14   15   16   17   18   >