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
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
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 at the
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
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 w
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: k
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
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
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 w
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
---
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 p
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 rem
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 +5653,
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
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 differ
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 meani
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 tracin
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.
Signe
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 cont
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, so
> 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:
https://syzkaller.appspot.com/x/.co
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
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 tim
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 @@ __alloc_pag
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, so
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
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.
Repor
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 "pte_al
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 seriou
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
userfaultfd_releas
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().
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
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 clas
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 class
34 matches
Mail list logo
