Re: [PATCH] perf config: ignore generated files in feature-checks

Why not? They're generated files aren't they? By the way, I just found out that test-* will be built depend on the detected features. Should I include them all? Thanks, Chunwei Chen 2013/12/19 Ingo Molnar mi...@kernel.org: * Chunwei Chen tux...@gmail.com wrote: Signed-off-by: Chunwei Chen

Re: [PATCH] perf config: ignore generated files in feature-checks

How about this: test-* !*.c So that we don't ignore *.c and we don't have to change file name. Anyway, I'll reupload tomorrow when I have my computer. Thanks, Chunwei Chen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

Re: [PATCH] vfs: check i_count under lock in evict_inodes

Hi Al, I'm not sure about the in-tree fs, but in zfsonlinux, it would offload iput to a thread, so this would happen there. And it would wait for the thread in put_super(), so that part is not a problem... Thanks 2016-07-11 17:46 GMT-07:00 Al Viro : > On Mon, Jul 11,

Re: RCU nocb list not reclaiming causing OOM

k to sleep. Thanks, David From: Paul E. McKenney Sent: Friday, July 27, 2018 3:31 PM To: David Chen Cc: linux-kernel@vger.kernel.org Subject: Re: RCU nocb list not reclaiming causing OOM   On Fri, Jul 27, 2018 at 07:07:46PM +, David Chen wrote: > Hi Paul, > > I'd like to opinio

Re: RCU nocb list not reclaiming causing OOM

up the follower. Thanks, David From: Paul E. McKenney Sent: Friday, July 27, 2018 4:47 PM To: David Chen Cc: linux-kernel@vger.kernel.org Subject: Re: RCU nocb list not reclaiming causing OOM   On Fri, Jul 27, 2018 at 11:16:39PM +, David Chen wrote: > Hi Paul, > > Thanks for the ad

Re: RCU nocb list not reclaiming causing OOM

Hi Paul, Just want to know what's your plan on stable branches regarding this issue. Do you intend to backport the ->nocb_lock? Or are you going with just the memory barrier change? Thanks, David From: Paul E. McKenney Sent: Saturday, July 28, 2018 1:29 AM To: David Chen Cc: linux-ker

[PATCH] rcu: Fix NOCB follower not waking up causing OOM

From: Chunwei Chen In 4.9 stable branch, we hit an issue where one of the NOCB follower thread wasn't waking up, even though the follower list is not empty. The follower list just kept on growing and never got reclaimed, and finally caused the system to run out of memory. This issue is similar

Backport 35a2897c2a (sched/wait: Remove the lockless swait_active() check in swake_up*()) to 4.9 branch

Hi Peter, In 4.9 branch, we hit an issue in RCU, where the NOCB follower list not getting reclaimed and causing OOM. In discussion with Paul, we were able to figure out the problem was because of missed wake up resulted from lack of proper memory barrier between setting wake up condition and

Re: RCU nocb list not reclaiming causing OOM

ead) { + if (rdp != my_rdp) { /* * List was empty, wake up the follower. * Memory barriers supplied by atomic_long_add(). From: David Chen Sent: Friday, July 20, 2018 5:12 PM To: paul...@linux.vnet.ibm.com Cc: linux-kernel@vger.kernel.org Subject: Re: RCU nocb list

RCU nocb list not reclaiming causing OOM

Hi Paul, We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too large, and not getting reclaimed, causing the system to OOM. Printing the culprit rcu_sched_data: nocb_q_count = { counter = 32369635 }, nocb_follower_head = 0x88ae901c0a00, nocb_follower_tail

blk_mq_freeze_queue hang and possible race in percpu-refcount

Hi Tejun, We recently hit an issue where several tasks hung in blk_mq_freeze_queue_wait. All the task have the same stack trace as the one below, which is doing fput on loop device. Which is strange because the task should be no more than a open(2), a couple pread(2), and close(2) on a loop

Re: blk_mq_freeze_queue hang and possible race in percpu-refcount

Hi Tejun, Thanks, I see I missed the RCU part. I'll try the force atomic thing. Though so far I haven't been able to reproduce it yet. Thanks, David 2018-03-14 8:43 GMT-07:00 Tejun Heo <t...@kernel.org>: > Hello, David. > > On Tue, Mar 13, 2018 at 03:50:47PM -0700, D

PROBLEM: SCSI write error not seen by Linux AIO?

[1.] SCSI write error not seen by Linux AIO? [2.] Full description of the problem/report: I filed a bug ( https://bugzilla.kernel.org/show_bug.cgi?id=201257 ) that looks pretty serious but quite possibly I've made some mistake. I emailed the Linux AIO mailing list about it over a week ago but

Re: [PATCH] perf config: ignore generated files in feature-checks

Why not? They're generated files aren't they? By the way, I just found out that test-* will be built depend on the detected features. Should I include them all? Thanks, Chunwei Chen 2013/12/19 Ingo Molnar : > > * Chunwei Chen wrote: > >> Signed-off-by: Chunwei Chen >> --- >>

Re: [PATCH] perf config: ignore generated files in feature-checks

How about this: test-* !*.c So that we don't ignore *.c and we don't have to change file name. Anyway, I'll reupload tomorrow when I have my computer. Thanks, Chunwei Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

blk_mq_freeze_queue hang and possible race in percpu-refcount

Hi Tejun, We recently hit an issue where several tasks hung in blk_mq_freeze_queue_wait. All the task have the same stack trace as the one below, which is doing fput on loop device. Which is strange because the task should be no more than a open(2), a couple pread(2), and close(2) on a loop

Re: blk_mq_freeze_queue hang and possible race in percpu-refcount

Hi Tejun, Thanks, I see I missed the RCU part. I'll try the force atomic thing. Though so far I haven't been able to reproduce it yet. Thanks, David 2018-03-14 8:43 GMT-07:00 Tejun Heo : > Hello, David. > > On Tue, Mar 13, 2018 at 03:50:47PM -0700, David Chen wrote: >&

Re: RCU nocb list not reclaiming causing OOM

ead) { + if (rdp != my_rdp) { /* * List was empty, wake up the follower. * Memory barriers supplied by atomic_long_add(). From: David Chen Sent: Friday, July 20, 2018 5:12 PM To: paul...@linux.vnet.ibm.com Cc: linux-kernel@vger.kernel.org Subject: Re: RCU nocb list

Re: RCU nocb list not reclaiming causing OOM

k to sleep. Thanks, David From: Paul E. McKenney Sent: Friday, July 27, 2018 3:31 PM To: David Chen Cc: linux-kernel@vger.kernel.org Subject: Re: RCU nocb list not reclaiming causing OOM   On Fri, Jul 27, 2018 at 07:07:46PM +, David Chen wrote: > Hi Paul, > > I'd like to opinio

Re: RCU nocb list not reclaiming causing OOM

up the follower. Thanks, David From: Paul E. McKenney Sent: Friday, July 27, 2018 4:47 PM To: David Chen Cc: linux-kernel@vger.kernel.org Subject: Re: RCU nocb list not reclaiming causing OOM   On Fri, Jul 27, 2018 at 11:16:39PM +, David Chen wrote: > Hi Paul, > > Thanks for the ad

Re: RCU nocb list not reclaiming causing OOM

Hi Paul, Just want to know what's your plan on stable branches regarding this issue. Do you intend to backport the ->nocb_lock? Or are you going with just the memory barrier change? Thanks, David From: Paul E. McKenney Sent: Saturday, July 28, 2018 1:29 AM To: David Chen Cc: linux-ker

[PATCH] rcu: Fix NOCB follower not waking up causing OOM

From: Chunwei Chen In 4.9 stable branch, we hit an issue where one of the NOCB follower thread wasn't waking up, even though the follower list is not empty. The follower list just kept on growing and never got reclaimed, and finally caused the system to run out of memory. This issue is similar

Backport 35a2897c2a (sched/wait: Remove the lockless swait_active() check in swake_up*()) to 4.9 branch

Hi Peter, In 4.9 branch, we hit an issue in RCU, where the NOCB follower list not getting reclaimed and causing OOM. In discussion with Paul, we were able to figure out the problem was because of missed wake up resulted from lack of proper memory barrier between setting wake up condition and

[PATCH] [V2]r8152: Add support for MAC address pass through on RTL8153-BD

From: David Chen RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through. Per confirming with Realtek all devices containing RTL8153-BD should activate MAC pass through and there won't use pass through bit on efuse like

[PATCH] r8152: Fix an error on RTL8153-BD MAC Address Passthrough support

From: David Chen RTL8153-BD is used in Dell DA300 type-C dongle. Added RTL8153-BD support to activate MAC address pass through on DA300. Apply correction on previously submitted patch in net.git tree. Signed-off-by: David Chen --- drivers/net/usb/r8152.c | 2 +- 1 file changed, 1 insertion

Re: [PATCH] [V2]r8152: Add support for MAC address pass through on RTL8153-BD

Hi Jiri, Thanks for your comments. BND_MASK and BD_MASK are defined separately, and I have tested RTL8153-BD and RTL8153-BND devices, both work as expected. Thanks and Regards, -David > Jiri Slaby 於 2019年2月18日 下午10:22 寫道： > >> On 18. 02. 19, 15:00, David Chen wrote: >>

[PATCH] r8152: Add support for MAC address pass through on RTL8153-BD

From: David Chen RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through. Per confirming with Realtek all devices containing RTL8153-BD should activate MAC pass through and there won't use pass through bit on efuse like

[PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.

From: David Chen Per confirming with Realtek all devices containing RTL8153-BD should activate MAC pass through and there won't use pass through bit on efuse like in RTL8153-AD. Signed-off-by: David Chen --- drivers/net/usb/r8152.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.

Hi Oliver, Thanks for reviewing. I have made some mistake, will correct it and resend. Thanks and Regards, -David > Oliver Neukum 於 2019年2月18日 下午4:04 寫道： > >> On Mo, 2019-02-18 at 11:48 +0800, David Chen wrote: >> From: David Chen >> >> Per confirming with

RCU nocb list not reclaiming causing OOM

Hi Paul, We hit an RCU issue on 4.9.37 kernel. One of the nocb_follower list grows too large, and not getting reclaimed, causing the system to OOM. Printing the culprit rcu_sched_data: nocb_q_count = { counter = 32369635 }, nocb_follower_head = 0x88ae901c0a00, nocb_follower_tail

PROBLEM: SCSI write error not seen by Linux AIO?

[1.] SCSI write error not seen by Linux AIO? [2.] Full description of the problem/report: I filed a bug ( https://bugzilla.kernel.org/show_bug.cgi?id=201257 ) that looks pretty serious but quite possibly I've made some mistake. I emailed the Linux AIO mailing list about it over a week ago but

Re: [PATCH] vfs: check i_count under lock in evict_inodes

Hi Al, I'm not sure about the in-tree fs, but in zfsonlinux, it would offload iput to a thread, so this would happen there. And it would wait for the thread in put_super(), so that part is not a problem... Thanks 2016-07-11 17:46 GMT-07:00 Al Viro : > On Mon, Jul 11, 2016 at 05:15:04PM -0700,