Re: [Qestion] Is preempt_disable/enable needed in non-preemption code path

2021-04-18 Thread Xu, Yanfei
On 4/17/21 1:26 AM, Paul E. McKenney wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Fri, Apr 16, 2021 at 06:51:10PM +0800, Xu, Yanfei wrote: On 4/16/21 1:07 AM, Paul E. McKenney wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Fri, Apr 16

Re: [Qestion] Is preempt_disable/enable needed in non-preemption code path

2021-04-16 Thread Xu, Yanfei
On 4/16/21 1:07 AM, Paul E. McKenney wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Fri, Apr 16, 2021 at 12:18:42AM +0800, Xu, Yanfei wrote: On 4/15/21 11:43 PM, Paul E. McKenney wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Thu, Apr 15

Re: [Qestion] Is preempt_disable/enable needed in non-preemption code path

2021-04-15 Thread Xu, Yanfei
On 4/16/21 12:18 AM, Xu, Yanfei wrote: On 4/15/21 11:43 PM, Paul E. McKenney wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Thu, Apr 15, 2021 at 11:04:05PM +0800, Xu, Yanfei wrote: Hi experts, I am learning rcu mechanism and its codes. When looking

Re: [Qestion] Is preempt_disable/enable needed in non-preemption code path

2021-04-15 Thread Xu, Yanfei
On 4/15/21 11:43 PM, Paul E. McKenney wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Thu, Apr 15, 2021 at 11:04:05PM +0800, Xu, Yanfei wrote: Hi experts, I am learning rcu mechanism and its codes. When looking at the rcu_blocking_is_gp(), I found there is a pair

[Qestion] Is preempt_disable/enable needed in non-preemption code path

2021-04-15 Thread Xu, Yanfei
Hi experts, I am learning rcu mechanism and its codes. When looking at the rcu_blocking_is_gp(), I found there is a pair preemption disable/enable operation in non-preemption code path. And it has been a long time. I can't understand why we need it? Is there some thing I missed? If not, can

Re: [PATCH v2 0/2] mm: khugepaged: cleanup and a minor tuning in THP

2021-04-13 Thread Xu, Yanfei
Gentle ping. On 4/7/21 11:05 AM, yanfei...@windriver.com wrote: From: Yanfei Xu v1-->v2: 1.correct the wrong location where the goto jump to. 2.keep the cond_resched() dropped in v1 still there. Thanks for Yang's review. Yanfei Xu (2): mm: khugepaged: use macro to align addresses mm:

Re: [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas

2021-04-05 Thread Xu, Yanfei
On 4/6/21 10:51 AM, Xu, Yanfei wrote: On 4/6/21 2:20 AM, Yang Shi wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Sun, Apr 4, 2021 at 8:33 AM wrote: From: Yanfei Xu We could check MMF_DISABLE_THP ahead of iterating over all of vma. Otherwise if some mm_struct

Re: [PATCH 2/2] mm: khugepaged: check MMF_DISABLE_THP ahead of iterating over vmas

2021-04-05 Thread Xu, Yanfei
On 4/6/21 2:20 AM, Yang Shi wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Sun, Apr 4, 2021 at 8:33 AM wrote: From: Yanfei Xu We could check MMF_DISABLE_THP ahead of iterating over all of vma. Otherwise if some mm_struct contain a large number of vma, there will

Re: [PATCH] block: export disk_part_iter_* helpers

2021-03-26 Thread Xu, Yanfei
On 3/26/21 8:13 PM, Christoph Hellwig wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Fri, Mar 26, 2021 at 08:10:59PM +0800, yanfei...@windriver.com wrote: From: Yanfei Xu disk_part_iter_* helpers might be used by other external modules, like lttng-modules. But it

Re: [PATCH] mm/hugetlb: remove duplicate codes of setting compound_nr

2021-02-02 Thread Xu, Yanfei
Sorry. Please ignore this patch, it's incorrect. Thanks, Yanfei On 2/3/21 12:40 PM, yanfei...@windriver.com wrote: From: Yanfei Xu set_compound_order() set both of page's compound_order and compound_nr. It's no need to assign to compound_nr again, so remove it. Signed-off-by: Yanfei Xu ---

Re: [PATCH v2] mm/hugetlb: remove redundant check in preparing and destroying gigantic page

2021-02-02 Thread Xu, Yanfei
I'm sorry for forgetting to add David. Now add David :) Thanks, Yanfei On 2/2/21 7:20 PM, yanfei...@windriver.com wrote: From: Yanfei Xu Gigantic page is a compound page and its order is more than 1. Thus it must be available for hpage_pincount. Let's remove the redundant check for gigantic

Re: [PATCH] mm/hugetlb: remove a meaningless if statement in gigantic page initialization

2021-02-02 Thread Xu, Yanfei
On 2/2/21 6:06 PM, David Hildenbrand wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On 02.02.21 11:12, yanfei...@windriver.com wrote: From: Yanfei Xu Gigantic page is a compound page and its order is more than 1. Thus it must be available for hpage_pincount. Let's

Re: KASAN: invalid-free in p9_client_create

2020-11-17 Thread Xu, Yanfei
How about this patch? If it is appropriate, I will send a real one. mm/slub: fix slab double-free when release callback of sysfs trigger Signed-off-by: Yanfei Xu diff --git a/mm/slub.c b/mm/slub.c index 4148235ba554..d10c4fbf8c84 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -5653,7

Re: [External] Re: [PATCH] mm/memory.c: Introduce non-atomic __{Set,Clear}PageSwapCache

2020-10-20 Thread Xu, Yanfei
On 10/20/20 9:08 PM, Muchun Song wrote: On Tue, Oct 20, 2020 at 7:51 PM Xu, Yanfei wrote: On 10/19/20 10:58 PM, Muchun Song wrote: On Mon, Oct 19, 2020 at 8:31 PM Michal Hocko wrote: On Mon 19-10-20 18:15:20, Muchun Song wrote: For the exclusive reference page, the non-atomic

Re: [External] Re: [PATCH] mm/memory.c: Introduce non-atomic __{Set,Clear}PageSwapCache

2020-10-20 Thread Xu, Yanfei
On 10/19/20 10:58 PM, Muchun Song wrote: On Mon, Oct 19, 2020 at 8:31 PM Michal Hocko wrote: On Mon 19-10-20 18:15:20, Muchun Song wrote: For the exclusive reference page, the non-atomic operations is enough, so replace them to non-atomic operations. I do expect you do not see any

Re: [PATCH v2] mm/compaction: Rename 'start_pfn' to 'iteration_start_pfn' in compact_zone()

2020-10-19 Thread Xu, Yanfei
On 10/19/20 6:48 PM, Vlastimil Babka wrote: On 10/19/20 12:29 PM, Xu, Yanfei wrote: On 10/19/20 5:40 PM, Vlastimil Babka wrote: On 10/19/20 10:36 AM, yanfei...@windriver.com wrote: From: Yanfei Xu There are two 'start_pfn' declared in compact_zone() which have different meaning. Rename

Re: [PATCH v2] mm/compaction: Rename 'start_pfn' to 'iteration_start_pfn' in compact_zone()

2020-10-19 Thread Xu, Yanfei
On 10/19/20 5:40 PM, Vlastimil Babka wrote: On 10/19/20 10:36 AM, yanfei...@windriver.com wrote: From: Yanfei Xu There are two 'start_pfn' declared in compact_zone() which have different meaning. Rename the second one to 'iteration_start_pfn' to prevent trace_mm_compaction_end() from

Re: [PATCH] mm/compaction: Remove some useless code in compact_zone()

2020-10-19 Thread Xu, Yanfei
On 10/16/20 11:05 PM, Vlastimil Babka wrote: On 10/14/20 2:28 PM, David Hildenbrand wrote: On 14.10.20 09:23, yanfei...@windriver.com wrote: From: Yanfei Xu start_pfn has been declared at the begin of compact_zone(), it's no need to declare it again. And remove an useless semicolon.

Re: [PATCH] Bluetooth: Use lock_sock() when acquiring lock in sco_conn_del

2020-10-18 Thread Xu, Yanfei
On 10/16/20 12:10 PM, Hillf Danton wrote: On Fri, 16 Oct 2020 11:15:27 +0800 Yanfei Xu wrote: On 10/14/20 8:31 PM, Hillf Danton wrote: On Wed, 14 Oct 2020 15:17:31 +0800 From: Yanfei Xu Locking slock-AF_BLUETOOTH-BTPROTO_SCO may happen in process context or BH context. If in process

Re: [PATCH] Bluetooth: Use lock_sock() when acquiring lock in sco_conn_del

2020-10-15 Thread Xu, Yanfei
On 10/14/20 8:31 PM, Hillf Danton wrote: On Wed, 14 Oct 2020 15:17:31 +0800 From: Yanfei Xu Locking slock-AF_BLUETOOTH-BTPROTO_SCO may happen in process context or BH context. If in process context, we should use lock_sock(). As blow warning, sco_conn_del() is called in process context,

Re: inconsistent lock state in sco_conn_del

2020-10-10 Thread Xu, Yanfei
> syzbot has found a reproducer for the following issue on: > > HEAD commit:e8878ab8 Merge tag 'spi-fix-v5.9-rc4' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1213075990 > kernel config:

Re: [PATCH v2] sched, mm: Optimize current_gfp_context()

2020-09-19 Thread Xu, Yanfei
On 9/18/20 11:18 PM, Waiman Long wrote: On 9/18/20 2:44 AM, Xu, Yanfei wrote: Hi Waiman, On 8/12/20 6:29 AM, Andrew Morton wrote: On Thu, 18 Jun 2020 17:29:36 -0400 Waiman Long wrote: The current_gfp_context() converts a number of PF_MEMALLOC_* per-process flags into the corresponding

Re: [PATCH v2] sched, mm: Optimize current_gfp_context()

2020-09-18 Thread Xu, Yanfei
Hi Waiman, On 8/12/20 6:29 AM, Andrew Morton wrote: On Thu, 18 Jun 2020 17:29:36 -0400 Waiman Long wrote: The current_gfp_context() converts a number of PF_MEMALLOC_* per-process flags into the corresponding GFP_* flags for memory allocation. In that function, current->flags is accessed 3

Re: [PATCH] mm/page_alloc.c: avoid inheritting current's flags when invoked in interrupt

2020-09-15 Thread Xu, Yanfei
On 9/16/20 9:17 AM, Andrew Morton wrote: On Tue, 15 Sep 2020 15:56:35 +0800 wrote: From: Yanfei Xu alloc_mask shouldn't inherit the current task's flags when __alloc_pages_nodemask is invoked in interrupt. ... --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4889,7 +4889,8 @@

Re: [PATCH] mm/page_alloc.c: variable type of 'progress' should be 'unsigned long'

2020-09-15 Thread Xu, Yanfei
On 9/16/20 8:48 AM, Andrew Morton wrote: On Tue, 15 Sep 2020 18:46:20 +0800 wrote: From: Yanfei Xu try_to_free_pages returns the number of pages reclaimed, and the type of returns is 'unsigned long'. So we should use a matched type for storing it. __perform_reclaim() returns an int,

Re: [PATCH] USB: integrate macro definitions into include/linux/usb.h

2020-08-29 Thread Xu, Yanfei
I just think it is a clear up to make these macros get togather which have the samilar attributes. That's why :) Thanks, Yanfei On 8/28/20 3:48 PM, Greg KH wrote: On Tue, Aug 25, 2020 at 11:44:21PM +0800, yanfei...@windriver.com wrote: From: Yanfei Xu include/linux/usb.h also contains 'Hard

Re: [PATCH] USB: core: limit access to rawdescriptors which were not allocated

2020-08-26 Thread Xu, Yanfei
On 8/26/20 2:00 AM, Alan Stern wrote: On Wed, Aug 26, 2020 at 12:16:59AM +0800, yanfei...@windriver.com wrote: From: Yanfei Xu When using systemcall to read the rawdescriptors, make sure we won't access to the rawdescriptors never allocated, which are number exceed the USB_MAXCONFIG.

Re: [PATCH] mm/memory.c: Correct the function name in comment

2020-08-18 Thread Xu, Yanfei
On 8/18/20 3:34 PM, David Hildenbrand wrote: On 18.08.20 09:29, yanfei...@windriver.com wrote: From: Yanfei Xu Correct the function name which is "pte_alloc_pne" to "pte_alloc_one" I'd have phrased this like "mm/memory: Fix typo in __do_fault() comment It's "pte_alloc_one", not

Re: [PATCH] userfaultfd: avoid the duplicated release for userfaultfd_ctx

2020-07-19 Thread Xu, Yanfei
On 7/20/20 12:57 AM, Al Viro wrote: On Sun, Jul 19, 2020 at 09:58:34PM +0800, Xu, Yanfei wrote: ping Al Viro Could you please help to review this patch? Thanks a lot. That's -next, right? As for the patch itself... Frankly, Yes, it's -next. Daniel's patch looks seriously wrong. Get

Re: [PATCH] userfaultfd: avoid the duplicated release for userfaultfd_ctx

2020-07-19 Thread Xu, Yanfei
ping Al Viro Could you please help to review this patch? Thanks a lot. Yanfei On 7/15/20 12:12 AM, yanfei...@windriver.com wrote: From: Yanfei Xu when get_unused_fd_flags gets failure, userfaultfd_ctx_cachep will be freed by userfaultfd_fops's release function which is the

Re: [PATCH] userfaultfd: avoid the duplicated release for userfaultfd_ctx

2020-07-14 Thread Xu, Yanfei
Add maintainer Alexander Viro :) On 7/15/20 12:12 AM, yanfei...@windriver.com wrote: From: Yanfei Xu when get_unused_fd_flags gets failure, userfaultfd_ctx_cachep will be freed by userfaultfd_fops's release function which is the userfaultfd_release. So we could return directly after fput().

Re: BUG:loop:blk_update_request: I/O error, dev loop6, sector 49674 op 0x9:(WRITE_ZEROES)

2020-05-14 Thread Xu, Yanfei
On 5/14/20 12:41 AM, Darrick J. Wong wrote: [add fsdevel to cc] On Tue, May 12, 2020 at 08:22:08PM -0600, Jens Axboe wrote: On 5/12/20 8:14 PM, Xu, Yanfei wrote: Hi, After operating the /dev/loop which losetup with an image placed in**tmpfs, I got the following ERROR messages

BUG:loop:blk_update_request: I/O error, dev loop6, sector 49674 op 0x9:(WRITE_ZEROES)

2020-05-13 Thread Xu, Yanfei
Hi, After operating the /dev/loop which losetup with an image placed in tmpfs. I got the following ERROR messages: [cut here]- [ 183.110770] blk_update_request: I/O error, dev loop6, sector 524160 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio

[loop]efcfec579: BUG:blk_update_request: I/O error, dev loop6, sector 49674 op 0x9:(WRITE_ZEROES)

2020-05-12 Thread Xu, Yanfei
Hi, After operating the /dev/loop which losetup with an image placed in tmpfs, I got the following ERROR messages: [cut here]- [ 183.110770] blk_update_request: I/O error, dev loop6, sector 524160 op 0x9:(WRITE_ZEROES) flags 0x1000800 phys_seg 0 prio