Re: [PATCH 2/2] alx: add disable_wol paramenter

Hi Andrew, We have some machines using Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller, but none of them has the unintentional wake up issue. We're willing to fix it if we encountered the issue, but before we can do it, we need this feature is supported by the driver. Taking the

Re: vmalloc with GFP_NOFS

On Wed 09-05-18 15:02:31, Darrick J. Wong wrote: > On Wed, May 09, 2018 at 11:04:47PM +0200, Michal Hocko wrote: > > On Wed 09-05-18 08:13:51, Darrick J. Wong wrote: [...] > > > > FS resp. IO submitting code paths have to be careful when allocating > > > > > > Not sure what 'FS resp. IO' means

Re: [PATCH 2/2] alx: add disable_wol paramenter

Hi Andrew, We have some machines using Qualcomm Atheros Killer E2400 Gigabit Ethernet Controller, but none of them has the unintentional wake up issue. We're willing to fix it if we encountered the issue, but before we can do it, we need this feature is supported by the driver. Taking the

Re: vmalloc with GFP_NOFS

On Wed 09-05-18 15:02:31, Darrick J. Wong wrote: > On Wed, May 09, 2018 at 11:04:47PM +0200, Michal Hocko wrote: > > On Wed 09-05-18 08:13:51, Darrick J. Wong wrote: [...] > > > > FS resp. IO submitting code paths have to be careful when allocating > > > > > > Not sure what 'FS resp. IO' means

inconsistent lock state in fs_reclaim_acquire (2)

Hello, syzbot found the following crash on: HEAD commit:036db8bd9637 Merge branch 'for-4.17-fixes' of git://git.ke.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=146dab5b80 kernel config: https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79

inconsistent lock state in fs_reclaim_acquire (2)

Hello, syzbot found the following crash on: HEAD commit:036db8bd9637 Merge branch 'for-4.17-fixes' of git://git.ke.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=146dab5b80 kernel config: https://syzkaller.appspot.com/x/.config?x=31f4b3733894ef79

[PATCH v2 5/7] usb: mtu3: make USB_MTU3_DUAL_ROLE depend on EXTCON but not USB_MTU3

In fact the driver depends on EXTCON only when it's configed as USB_MTU3_DUAL_ROLE, so make USB_MTU3_DUAL_ROLE depend on EXTCON but not USB_MTU3. Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH v2 5/7] usb: mtu3: make USB_MTU3_DUAL_ROLE depend on EXTCON but not USB_MTU3

In fact the driver depends on EXTCON only when it's configed as USB_MTU3_DUAL_ROLE, so make USB_MTU3_DUAL_ROLE depend on EXTCON but not USB_MTU3. Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH v2 4/7] usb: mtu3: fix operation failure when test TEST_J/K

There is an error dialog popped up in PC when test TEST_J/K by EHSETT tool, due to not waiting for the completion of control transfer. Here fix it by entering test mode after Status Stage finish. Signed-off-by: Chunfeng Yun --- v2: 1. reset test_mode as default

[PATCH v2 3/7] usb: mtu3: fix an unrecognized issue when connected with PC

When boot on the platform with the USB cable connected to Win7, the Win7 will pop up an error dialog: "USB Device not recognized", but finally the Win7 can enumerate it successfully. The root cause is as the following: When the xHCI driver set PORT_POWER of the OTG port, and if both IDPIN and

[PATCH v2 3/7] usb: mtu3: fix an unrecognized issue when connected with PC

When boot on the platform with the USB cable connected to Win7, the Win7 will pop up an error dialog: "USB Device not recognized", but finally the Win7 can enumerate it successfully. The root cause is as the following: When the xHCI driver set PORT_POWER of the OTG port, and if both IDPIN and

[PATCH v2 4/7] usb: mtu3: fix operation failure when test TEST_J/K

There is an error dialog popped up in PC when test TEST_J/K by EHSETT tool, due to not waiting for the completion of control transfer. Here fix it by entering test mode after Status Stage finish. Signed-off-by: Chunfeng Yun --- v2: 1. reset test_mode as default value when controller is reset

[PATCH v2 7/7] usb: mtu3: fix uncontinuous SeqN issue after disable EP

Reset EP when disable it to reset data toggle for U2 EP, and SeqN, flow control status etc for U3 EP, this can avoid issue of uncontinuous SeqN Signed-off-by: Chunfeng Yun --- v2: add this patch --- drivers/usb/mtu3/mtu3_core.c | 4 1 file changed, 4

[PATCH v2 7/7] usb: mtu3: fix uncontinuous SeqN issue after disable EP

Reset EP when disable it to reset data toggle for U2 EP, and SeqN, flow control status etc for U3 EP, this can avoid issue of uncontinuous SeqN Signed-off-by: Chunfeng Yun --- v2: add this patch --- drivers/usb/mtu3/mtu3_core.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v2 6/7] usb: mtu3: re-enable controller to accept LPM request after LPM resume

After the controller receives a LPM request, it will reject the LPM request, and need software to re-enable it after LPM resume if the controller doesn't remote wakeup from L1 automatically Signed-off-by: Chunfeng Yun --- v2: add this patch ---

[PATCH v2 1/7] usb: mtu3: avoid TX data length truncated in SS/SSP mode

The variable of 'count' is declared as u8, this will cause an issue due to value truncated when works in SS or SSP mode and data length is greater than 255, so change it as u32. Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/mtu3_gadget_ep0.c | 2 +- 1 file changed,

[PATCH v2 2/7] usb: mtu3: remove repeated setting of gadget state

The usb_add_gadget_udc() will set the gadget state as USB_STATE_NOTATTACHED, so we needn't set it again. Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/mtu3_gadget.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git

[PATCH v2 1/7] usb: mtu3: avoid TX data length truncated in SS/SSP mode

The variable of 'count' is declared as u8, this will cause an issue due to value truncated when works in SS or SSP mode and data length is greater than 255, so change it as u32. Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/mtu3_gadget_ep0.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 2/7] usb: mtu3: remove repeated setting of gadget state

The usb_add_gadget_udc() will set the gadget state as USB_STATE_NOTATTACHED, so we needn't set it again. Signed-off-by: Chunfeng Yun --- drivers/usb/mtu3/mtu3_gadget.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/usb/mtu3/mtu3_gadget.c

[PATCH v2 6/7] usb: mtu3: re-enable controller to accept LPM request after LPM resume

After the controller receives a LPM request, it will reject the LPM request, and need software to re-enable it after LPM resume if the controller doesn't remote wakeup from L1 automatically Signed-off-by: Chunfeng Yun --- v2: add this patch --- drivers/usb/mtu3/mtu3_core.c | 8 +++- 1

Re: [PATCH net-next v1] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 10:21 PM, Jon Maxwell wrote: ... > if (th->rst) > @@ -723,11 +724,17 @@ static void tcp_v4_send_reset(const struct sock *sk, > struct sk_buff *skb) > arg.tos = ip_hdr(skb)->tos; > arg.uid = sock_net_uid(net, sk && sk_fullsock(sk) ? sk : NULL); >

Re: [PATCH net-next v1] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 10:21 PM, Jon Maxwell wrote: ... > if (th->rst) > @@ -723,11 +724,17 @@ static void tcp_v4_send_reset(const struct sock *sk, > struct sk_buff *skb) > arg.tos = ip_hdr(skb)->tos; > arg.uid = sock_net_uid(net, sk && sk_fullsock(sk) ? sk : NULL); >

[PATCH] staging: lustre: o2iblnd: Fix crash in kiblnd_handle_early_rxs()

Under upstream staging commit 5a2ca43fa54f561c252c2, the list handling code in kiblnd_handle_early_rxs() got changed to list_for_each_safe(). That protects against the current thread from deleting the current entry it is looking at. It does not protect against another thread from deleting the next

[PATCH] staging: lustre: o2iblnd: Fix crash in kiblnd_handle_early_rxs()

Under upstream staging commit 5a2ca43fa54f561c252c2, the list handling code in kiblnd_handle_early_rxs() got changed to list_for_each_safe(). That protects against the current thread from deleting the current entry it is looking at. It does not protect against another thread from deleting the next

[PATCH] ocfs2: ocfs2_inode_lock_tracker does not distinguish lock level

ocfs2_inode_lock_tracker as a variant of ocfs2_inode_lock, is used to prevent deadlock due to recursive lock acquisition. But this function does not distinguish whether the requested level is EX or PR. If a RP lock has been attained, this function will immediately return success afterwards even

[PATCH] ocfs2: ocfs2_inode_lock_tracker does not distinguish lock level

ocfs2_inode_lock_tracker as a variant of ocfs2_inode_lock, is used to prevent deadlock due to recursive lock acquisition. But this function does not distinguish whether the requested level is EX or PR. If a RP lock has been attained, this function will immediately return success afterwards even

[PATCH net-next v1] tcp: Add mark for TIMEWAIT sockets

This version has some suggestions by Eric Dumazet: - Use a local variable for the mark in IPv6 instead of ctl_sk to avoid SMP races. - Use the more elegant "IP4_REPLY_MARK(net, skb->mark) ?: sk->sk_mark" statement. Aidan McGurn from Openwave Mobility systems reported the following bug:

[PATCH net-next v1] tcp: Add mark for TIMEWAIT sockets

This version has some suggestions by Eric Dumazet: - Use a local variable for the mark in IPv6 instead of ctl_sk to avoid SMP races. - Use the more elegant "IP4_REPLY_MARK(net, skb->mark) ?: sk->sk_mark" statement. Aidan McGurn from Openwave Mobility systems reported the following bug:

Re: WARNING in event_function_local

On Sat, Jan 27, 2018 at 8:58 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on bpf-next commit > 8223967fe0b8eb2448cca5cfe3c64a0838e6f60d (Sat Jan 27 01:06:23 2018 +) > Merge branch 'fix-lpm-map' > > So far this crash

Re: WARNING in event_function_local

On Sat, Jan 27, 2018 at 8:58 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on bpf-next commit > 8223967fe0b8eb2448cca5cfe3c64a0838e6f60d (Sat Jan 27 01:06:23 2018 +) > Merge branch 'fix-lpm-map' > > So far this crash happened 2 times on bpf-next. > C reproducer is attached. >

Re: KASAN: slab-out-of-bounds Write in process_preds

On Wed, Apr 11, 2018 at 2:02 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > b284d4d5a6785f8cd07eda2646a95782373cd01e (Tue Apr 10 19:25:30 2018 +) > Merge tag 'ceph-for-4.17-rc1' of

Re: KASAN: slab-out-of-bounds Write in process_preds

On Wed, Apr 11, 2018 at 2:02 PM, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > b284d4d5a6785f8cd07eda2646a95782373cd01e (Tue Apr 10 19:25:30 2018 +) > Merge tag 'ceph-for-4.17-rc1' of git://github.com/ceph/ceph-client > syzbot dashboard link: >

[PATCH v4 2/2] input: misc: Add Spreadtrum vibrator driver

From: Xiaotong Lu This patch adds the Spreadtrum vibrator driver, which embedded in the Spreadtrum SC27xx series PMICs. Signed-off-by: Xiaotong Lu Signed-off-by: Baolin Wang --- Changes since v3: - No updates.

[PATCH v4 2/2] input: misc: Add Spreadtrum vibrator driver

From: Xiaotong Lu This patch adds the Spreadtrum vibrator driver, which embedded in the Spreadtrum SC27xx series PMICs. Signed-off-by: Xiaotong Lu Signed-off-by: Baolin Wang --- Changes since v3: - No updates. Changes since v2: - Fix the condition when disabling the vibrator. - Change

[PATCH v4 1/2] dt-bindings: input: Add Add Spreadtrum SC27xx vibrator documentation

From: Xiaotong Lu This patch adds the binding documentation for Spreadtrum SC27xx series vibrator device. Signed-off-by: Xiaotong Lu Signed-off-by: Baolin Wang --- Changes since v3: - Change compatible string to

[PATCH v4 1/2] dt-bindings: input: Add Add Spreadtrum SC27xx vibrator documentation

From: Xiaotong Lu This patch adds the binding documentation for Spreadtrum SC27xx series vibrator device. Signed-off-by: Xiaotong Lu Signed-off-by: Baolin Wang --- Changes since v3: - Change compatible string to explicit Soc name. - Add parent MFD node. Changes since v2: - No updates.

Re: [PATCH 5/8] export.h: remove code for prefixing symbols with underscore

Hi Mashahiro > Anyway VMLINUX_SYMBOL(), VMLINUX_SYMBOL_STR() will not live long. > I need some cycles for tree-wide cleaning, though. Fine, then there is no need to discuss the details of their current definition. Sam

Re: [PATCH 5/8] export.h: remove code for prefixing symbols with underscore

Hi Mashahiro > Anyway VMLINUX_SYMBOL(), VMLINUX_SYMBOL_STR() will not live long. > I need some cycles for tree-wide cleaning, though. Fine, then there is no need to discuss the details of their current definition. Sam

smp_call_function() friends and irq/bottom_half context

Hi, all. I'm reading kernel/smp.c code and I found comments on smp_call_function() and smp_call_function_[single/many] saying that these functions are cannot be called in interrupt disabled context or irq/bottom half handlers. I understand that there is a potential deadlock issue when caller CPU

smp_call_function() friends and irq/bottom_half context

Hi, all. I'm reading kernel/smp.c code and I found comments on smp_call_function() and smp_call_function_[single/many] saying that these functions are cannot be called in interrupt disabled context or irq/bottom half handlers. I understand that there is a potential deadlock issue when caller CPU

RE: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Dear Mauro > -Original Message- > > There was a recent discussion about the use/abuse of GFP_DMA flag when > allocating memories at LSF/MM 2018 (see Luis notes enclosed). > > The idea seems to be to remove it, using CMA instead. Before doing that, > better to check if what we have on

RE: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Dear Mauro > -Original Message- > > There was a recent discussion about the use/abuse of GFP_DMA flag when > allocating memories at LSF/MM 2018 (see Luis notes enclosed). > > The idea seems to be to remove it, using CMA instead. Before doing that, > better to check if what we have on

Re: bug in tag handling in blk-mq?

On Wed, 2018-05-09 at 13:50 -0600, Jens Axboe wrote: > On 5/9/18 12:31 PM, Mike Galbraith wrote: > > On Wed, 2018-05-09 at 11:01 -0600, Jens Axboe wrote: > >> On 5/9/18 10:57 AM, Mike Galbraith wrote: > >> > > Confirmed. Impressive high speed bug stomping. > > Well, that's good

Re: bug in tag handling in blk-mq?

On Wed, 2018-05-09 at 13:50 -0600, Jens Axboe wrote: > On 5/9/18 12:31 PM, Mike Galbraith wrote: > > On Wed, 2018-05-09 at 11:01 -0600, Jens Axboe wrote: > >> On 5/9/18 10:57 AM, Mike Galbraith wrote: > >> > > Confirmed. Impressive high speed bug stomping. > > Well, that's good

[PATCH v2] perf buildid-cache: Warn --purge-all failures

Warn perf buildid-cache --purge-all failures in non verbose mode. Ex, $ sudo chown root:root /home/ravi/.debug -R $ sudo chmod 700 /home/ravi/.debug/ -R $ ./perf buildid-cache -P Couldn't remove some caches. Error: Permission denied. Suggested-by: Masami Hiramatsu

[PATCH v2] perf buildid-cache: Warn --purge-all failures

Warn perf buildid-cache --purge-all failures in non verbose mode. Ex, $ sudo chown root:root /home/ravi/.debug -R $ sudo chmod 700 /home/ravi/.debug/ -R $ ./perf buildid-cache -P Couldn't remove some caches. Error: Permission denied. Suggested-by: Masami Hiramatsu Signed-off-by: Ravi

Re: [PATCH net-next] tcp: Add mark for TIMEWAIT sockets

On Thu, May 10, 2018 at 1:32 PM, Eric Dumazet wrote: > > > On 05/09/2018 07:07 PM, Jon Maxwell wrote: >> Aidan McGurn from Openwave Mobility systems reported the following bug: >> >> "Marked routing is broken on customer deployment. Its effects are large >> increase in

Re: [PATCH net-next] tcp: Add mark for TIMEWAIT sockets

On Thu, May 10, 2018 at 1:32 PM, Eric Dumazet wrote: > > > On 05/09/2018 07:07 PM, Jon Maxwell wrote: >> Aidan McGurn from Openwave Mobility systems reported the following bug: >> >> "Marked routing is broken on customer deployment. Its effects are large >> increase in Uplink retransmissions

Re: [GIT PULL] ARM: uniphier: fixes for v4.17

On Wed, May 9, 2018 at 9:18 PM, Masahiro Yamada wrote: > Hi Arnd, Olof, > > > 2018-04-29 0:47 GMT+09:00 Masahiro Yamada : >> Hi Arnd, Olof, >> >> Please pull some fixes of ARM UniPhier DT. > > > I am guessing why this has not been

Re: [GIT PULL] ARM: uniphier: fixes for v4.17

On Wed, May 9, 2018 at 9:18 PM, Masahiro Yamada wrote: > Hi Arnd, Olof, > > > 2018-04-29 0:47 GMT+09:00 Masahiro Yamada : >> Hi Arnd, Olof, >> >> Please pull some fixes of ARM UniPhier DT. > > > I am guessing why this has not been pulled yet. > Right, I was late - you had already sent the fixes

Re: printk feature for syzbot?

On (04/26/18 12:06), Petr Mladek wrote: > > > Petr, Steven, Fengguang, what do you think? Do you have any objections? > > Ideas? > > I wonder if we could create some mechanism that would help to extend > struct printk_log easier in the future. Hm, interesting idea. > I know only about crash

Re: printk feature for syzbot?

On (04/26/18 12:06), Petr Mladek wrote: > > > Petr, Steven, Fengguang, what do you think? Do you have any objections? > > Ideas? > > I wonder if we could create some mechanism that would help to extend > struct printk_log easier in the future. Hm, interesting idea. > I know only about crash

Re: [GIT PULL] ARM: uniphier: fixes for v4.17

Hi Arnd, Olof, 2018-04-29 0:47 GMT+09:00 Masahiro Yamada : > Hi Arnd, Olof, > > Please pull some fixes of ARM UniPhier DT. I am guessing why this has not been pulled yet. Right, I was late - you had already sent the fixes pull request to Linus. Do you have a

Re: [GIT PULL] ARM: uniphier: fixes for v4.17

Hi Arnd, Olof, 2018-04-29 0:47 GMT+09:00 Masahiro Yamada : > Hi Arnd, Olof, > > Please pull some fixes of ARM UniPhier DT. I am guessing why this has not been pulled yet. Right, I was late - you had already sent the fixes pull request to Linus. Do you have a chance to send another fixes PR

[RFC][PATCH] cgroup: Don't mess with tasks in exec

Semantically exec is supposed to be atomic with no user space visible intermediate points. Migrating tasks during exec may change that and lead to all manner of difficult to analyze and maintin corner cases. So avoid the problems by simply blocking cgroup migration over the entirety of exec.

[RFC][PATCH] cgroup: Don't mess with tasks in exec

Semantically exec is supposed to be atomic with no user space visible intermediate points. Migrating tasks during exec may change that and lead to all manner of difficult to analyze and maintin corner cases. So avoid the problems by simply blocking cgroup migration over the entirety of exec.

[PATCH RESEND v2 2/2] perf cs-etm: Remove redundant space

There have two spaces ahead function name cs_etm__set_pid_tid_cpu(), so remove one space and correct indentation. Signed-off-by: Leo Yan Acked-by: Mathieu Poirier --- tools/perf/util/cs-etm.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH RESEND v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace

CoreSight doesn't allocate thread structure for unknown_thread in etm auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't contain valid tid and then cs_etm__mem_access() uses unknown_thread instead as thread handler, this results in segmentation fault when

[PATCH RESEND v2 2/2] perf cs-etm: Remove redundant space

There have two spaces ahead function name cs_etm__set_pid_tid_cpu(), so remove one space and correct indentation. Signed-off-by: Leo Yan Acked-by: Mathieu Poirier --- tools/perf/util/cs-etm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/cs-etm.c

[PATCH RESEND v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace

CoreSight doesn't allocate thread structure for unknown_thread in etm auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't contain valid tid and then cs_etm__mem_access() uses unknown_thread instead as thread handler, this results in segmentation fault when

Re: [PATCH v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace

On Wed, May 09, 2018 at 09:51:50AM -0600, Mathieu Poirier wrote: > On Wed, May 09, 2018 at 12:15:11PM +0800, Leo Yan wrote: > > CoreSight doesn't allocate thread structure for unknown_thread in etm > > auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't > > contain valid tid and

Re: [PATCH v2 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace

On Wed, May 09, 2018 at 09:51:50AM -0600, Mathieu Poirier wrote: > On Wed, May 09, 2018 at 12:15:11PM +0800, Leo Yan wrote: > > CoreSight doesn't allocate thread structure for unknown_thread in etm > > auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't > > contain valid tid and

RE: [External] [RFC PATCH v1 3/6] mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE

> > On Wed 09-05-18 14:04:21, Huaisheng HS1 Ye wrote: > > > From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On > > > Behalf Of > Michal Hocko > > > > > > On Wed 09-05-18 04:22:10, Huaisheng HS1 Ye wrote: > [...] > > > > Current mm treats all memory regions equally, it divides

RE: [External] [RFC PATCH v1 3/6] mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE

> > On Wed 09-05-18 14:04:21, Huaisheng HS1 Ye wrote: > > > From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On > > > Behalf Of > Michal Hocko > > > > > > On Wed 09-05-18 04:22:10, Huaisheng HS1 Ye wrote: > [...] > > > > Current mm treats all memory regions equally, it divides

[PATCH 0/3] objtool: GCC 8 support

Now that GCC 8 is out, several people have complained about a bunch of objtool warnings. These patches fix all known warnings. Patch 1 is a repost of a previous fix -- unrelated to GCC 8, but a prereq for the following two patches. Patch 2 fixes the vast majority of the warnings, caused by GCC

[PATCH 1/3] objtool: Fix "noreturn" detection for recursive sibling calls

Objtool has some crude logic for detecting static "noreturn" functions (aka "dead ends"). This is necessary for being able to correctly follow GCC code flow when such functions are called. It's remotely possible for two functions to call each other via sibling calls. If they don't have RET

[PATCH 0/3] objtool: GCC 8 support

Now that GCC 8 is out, several people have complained about a bunch of objtool warnings. These patches fix all known warnings. Patch 1 is a repost of a previous fix -- unrelated to GCC 8, but a prereq for the following two patches. Patch 2 fixes the vast majority of the warnings, caused by GCC

[PATCH 1/3] objtool: Fix "noreturn" detection for recursive sibling calls

Objtool has some crude logic for detecting static "noreturn" functions (aka "dead ends"). This is necessary for being able to correctly follow GCC code flow when such functions are called. It's remotely possible for two functions to call each other via sibling calls. If they don't have RET

Re: [PATCH 5/8] export.h: remove code for prefixing symbols with underscore

Hi Sam, 2018-05-10 1:07 GMT+09:00 Sam Ravnborg : > Hi Masahiro > > On Wed, May 09, 2018 at 04:23:49PM +0900, Masahiro Yamada wrote: >> CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX was selected by BLACKFIN, METAG. >> They were removed by commit 4ba66a976072 ("arch: remove blackfin

[PATCH 3/3] objtool: Support GCC 8 switch tables

Add some additional checks to the switch jump table logic. This fixes the following warnings with GCC 8: drivers/block/virtio_blk.o: warning: objtool: virtio_queue_rq()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+72 net/ipv6/icmp.o: warning: objtool: icmpv6_rcv()+0x0: stack state mismatch:

Re: [PATCH 5/8] export.h: remove code for prefixing symbols with underscore

Hi Sam, 2018-05-10 1:07 GMT+09:00 Sam Ravnborg : > Hi Masahiro > > On Wed, May 09, 2018 at 04:23:49PM +0900, Masahiro Yamada wrote: >> CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX was selected by BLACKFIN, METAG. >> They were removed by commit 4ba66a976072 ("arch: remove blackfin port"), >> commit

[PATCH 3/3] objtool: Support GCC 8 switch tables

Add some additional checks to the switch jump table logic. This fixes the following warnings with GCC 8: drivers/block/virtio_blk.o: warning: objtool: virtio_queue_rq()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+72 net/ipv6/icmp.o: warning: objtool: icmpv6_rcv()+0x0: stack state mismatch:

[PATCH 2/3] objtool: Support GCC 8 cold subfunctions

GCC 8 moves a lot of unlikely code out of line to "cold" subfunctions in .text.unlikely. Properly detect the new subfunctions and treat them as extensions of the original functions. This fixes a bunch of warnings like: kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x33:

[PATCH 2/3] objtool: Support GCC 8 cold subfunctions

GCC 8 moves a lot of unlikely code out of line to "cold" subfunctions in .text.unlikely. Properly detect the new subfunctions and treat them as extensions of the original functions. This fixes a bunch of warnings like: kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x33:

Re: [PATCH net-next] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 07:07 PM, Jon Maxwell wrote: > Aidan McGurn from Openwave Mobility systems reported the following bug: > > "Marked routing is broken on customer deployment. Its effects are large > increase in Uplink retransmissions caused by the client never receiving > the final ACK to their

Re: [PATCH net-next] tcp: Add mark for TIMEWAIT sockets

On 05/09/2018 07:07 PM, Jon Maxwell wrote: > Aidan McGurn from Openwave Mobility systems reported the following bug: > > "Marked routing is broken on customer deployment. Its effects are large > increase in Uplink retransmissions caused by the client never receiving > the final ACK to their

[PATCH] bpf, arm32: Correct check_imm24

imm24 is signed, so the right range is: [-(2<<(24 - 1)), (2<<(24 - 1)) - 1] Note:this patch also fix a typo. Signed-off-by: Wang YanQing --- arch/arm/net/bpf_jit_32.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/arm/net/bpf_jit_32.c

[PATCH] bpf, arm32: Correct check_imm24

imm24 is signed, so the right range is: [-(2<<(24 - 1)), (2<<(24 - 1)) - 1] Note:this patch also fix a typo. Signed-off-by: Wang YanQing --- arch/arm/net/bpf_jit_32.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/arm/net/bpf_jit_32.c

[PATCH] bpf, arm32: Fix inconsistent naming about emit_a32_lsr_r64|emit_a32_lsr_i64

The reasonable names for emit_a32_lsr_r64|emit_a32_lsr_i64 are emit_a32_rsh_r64|emit_a32_rsh_i64. This patch also correct a wrong comment. Signed-off-by: Wang YanQing --- arch/arm/net/bpf_jit_32.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH] bpf, arm32: Fix inconsistent naming about emit_a32_lsr_r64|emit_a32_lsr_i64

The reasonable names for emit_a32_lsr_r64|emit_a32_lsr_i64 are emit_a32_rsh_r64|emit_a32_rsh_i64. This patch also correct a wrong comment. Signed-off-by: Wang YanQing --- arch/arm/net/bpf_jit_32.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 09, 2018 at 08:47:27PM +1000, Stephen Rothwell wrote: >On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote: >> >> On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote: >> > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote: >> >> > > I

Re: [Ksummit-discuss] bug-introducing patches

On Wed, May 09, 2018 at 08:47:27PM +1000, Stephen Rothwell wrote: >On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote: >> >> On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote: >> > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote: >> >> > > I think this is an excellent idea, copying

Re: [PATCH v2 2/2] leds: Add Spreadtrum SC27xx breathing light controller driver

Hi Pavel, On 9 May 2018 at 22:25, Pavel Machek wrote: > On Tue 2018-05-08 13:39:45, Baolin Wang wrote: >> From: Xiaotong Lu >> >> This patch adds Spreadtrum SC27xx PMIC series breathing light controller >> driver, which can support 3 LEDs. Each LED can

Re: [PATCH v2 2/2] leds: Add Spreadtrum SC27xx breathing light controller driver

Hi Pavel, On 9 May 2018 at 22:25, Pavel Machek wrote: > On Tue 2018-05-08 13:39:45, Baolin Wang wrote: >> From: Xiaotong Lu >> >> This patch adds Spreadtrum SC27xx PMIC series breathing light controller >> driver, which can support 3 LEDs. Each LED can work at normal PWM mode >> and breathing

Re: [RESEND PATCH 1/5] usb: mtu3: avoid TX data length truncated in SS/SSP mode

Hi, Greg On Thu, 2018-05-10 at 10:16 +0800, Chunfeng Yun wrote: > Hi, Greg > >Could you please pick up the series of patches, thanks a lot Please ignore it, I find a problem in [RESEND PATCH 4/5], and need send a new version. Very sorry > > On Sat, 2018-05-05 at 10:21 +0800, Chunfeng Yun

Re: [RESEND PATCH 1/5] usb: mtu3: avoid TX data length truncated in SS/SSP mode

Hi, Greg On Thu, 2018-05-10 at 10:16 +0800, Chunfeng Yun wrote: > Hi, Greg > >Could you please pick up the series of patches, thanks a lot Please ignore it, I find a problem in [RESEND PATCH 4/5], and need send a new version. Very sorry > > On Sat, 2018-05-05 at 10:21 +0800, Chunfeng Yun

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

Oleg Nesterov writes: > On 05/07, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > before your patch get_mem_cgroup_from_mm() looks at mm->owner == current >> > (in this case) and mem_cgroup_from_task() should return the correct memcg >> > even if

[PATCH] bpf, doc: clarification for the meaning of 'id'

For me, as a reader whose mother language isn't English, the old words bring a little difficulty to catch the meaning, this patch rewords the subsection in a more clarificatory way. This patch also add blank lines as separator at two places to improve readability. Signed-off-by: Wang YanQing

linux-next: build warning after merge of the sound-asoc tree

Hi all, After merging the sound-asoc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: modpost: missing MODULE_LICENSE() in sound/soc/omap/snd-soc-sdma.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in

Re: [PATCH] memcg: Replace mm->owner with mm->memcg

Oleg Nesterov writes: > On 05/07, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > before your patch get_mem_cgroup_from_mm() looks at mm->owner == current >> > (in this case) and mem_cgroup_from_task() should return the correct memcg >> > even if execing task migrates after

[PATCH] bpf, doc: clarification for the meaning of 'id'

For me, as a reader whose mother language isn't English, the old words bring a little difficulty to catch the meaning, this patch rewords the subsection in a more clarificatory way. This patch also add blank lines as separator at two places to improve readability. Signed-off-by: Wang YanQing

linux-next: build warning after merge of the sound-asoc tree

Hi all, After merging the sound-asoc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: modpost: missing MODULE_LICENSE() in sound/soc/omap/snd-soc-sdma.o see include/linux/module.h for more information WARNING: modpost: missing MODULE_LICENSE() in

[PATCH v5] block: add verifier for cmdline partition

I meet strange filesystem corruption issue recently, the reason is there are overlaps partitions in cmdline partition argument. This patch add verifier for cmdline partition, then if there are overlaps partitions, cmdline_partition will log a warning. We don't treat overlaps partition as a error:

[PATCH v5] block: add verifier for cmdline partition

I meet strange filesystem corruption issue recently, the reason is there are overlaps partitions in cmdline partition argument. This patch add verifier for cmdline partition, then if there are overlaps partitions, cmdline_partition will log a warning. We don't treat overlaps partition as a error:

Re: [PATCH 2/2] memcg: Close the race between migration and installing bprm->mm as mm

Oleg Nesterov writes: > On 05/04, Eric W. Biederman wrote: >> >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1044,6 +1044,8 @@ static int exec_mmap(struct mm_struct *mm) >> return 0; >> } >> mmdrop(active_mm); >> +/* The tsk may have migrated before the

Re: [PATCH 2/2] memcg: Close the race between migration and installing bprm->mm as mm

Oleg Nesterov writes: > On 05/04, Eric W. Biederman wrote: >> >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1044,6 +1044,8 @@ static int exec_mmap(struct mm_struct *mm) >> return 0; >> } >> mmdrop(active_mm); >> +/* The tsk may have migrated before the new mm was

[PATCH] soc: mediatek: remove unneeded semicolon

From: Sean Wang Fix up drivers/soc/mediatek/mtk-scpsys.c:255:2-3: Unneeded semicolon accidently being added in commit f9e2f65dd561 ("soc: mediatek: add a fixed wait for SRAM stable"). Fixes: f9e2f65dd561 ("soc: mediatek: add a fixed wait for SRAM stable") Reported-by:

[PATCH] soc: mediatek: remove unneeded semicolon

From: Sean Wang Fix up drivers/soc/mediatek/mtk-scpsys.c:255:2-3: Unneeded semicolon accidently being added in commit f9e2f65dd561 ("soc: mediatek: add a fixed wait for SRAM stable"). Fixes: f9e2f65dd561 ("soc: mediatek: add a fixed wait for SRAM stable") Reported-by: kbuild test robot

Re: fd3e45436660 ("ACPI / NUMA: ia64: Parse all entries of SRAT memory affinity table")

On Wed, May 9, 2018 at 6:26 PM, Michal Hocko wrote: > On Wed 09-05-18 18:07:16, Ganapatrao Kulkarni wrote: >> Hi Michal >> >> >> On Wed, May 9, 2018 at 5:54 PM, Michal Hocko wrote: >> > On Wed 11-04-18 12:48:32, Michal Hocko wrote: >> >> Hi, >> >> my

Re: fd3e45436660 ("ACPI / NUMA: ia64: Parse all entries of SRAT memory affinity table")

On Wed, May 9, 2018 at 6:26 PM, Michal Hocko wrote: > On Wed 09-05-18 18:07:16, Ganapatrao Kulkarni wrote: >> Hi Michal >> >> >> On Wed, May 9, 2018 at 5:54 PM, Michal Hocko wrote: >> > On Wed 11-04-18 12:48:32, Michal Hocko wrote: >> >> Hi, >> >> my attention was brought to the %subj commit and

  1   2   3   4   5   6   7   8   9   10   >