On 10/22/16 06:53, Chen Gang wrote:
>
> On 10/21/16 11:41, Andrew Morton wrote:
>> On Wed, 5 Oct 2016 21:40:10 +0800 cheng...@emindsoft.com.cn wrote:
>>
>>> In api itself, kernel does not use it -- it is divided into ac_etime_hi
>>> and ac_etime_lo. So kernel
e, kernel has to
know about it, but kernel still can keep original code no touch. So for
me, our changing is harmless.
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
...@emindsoft.com.cn wrote:
> From: Chen Gang
>
> In api itself, kernel does not use it -- it is divided into ac_etime_hi
> and ac_etime_lo. So kernel side only need generate the correct
> ac_etime_hi and ac_etime_lo, but need not know about comp2_t.
>
> At present, kernel us
Firstly, excuse me for replying late -- since I also agree, this patch
is not urgent ;-)
On 9/21/16 16:11, Michal Hocko wrote:
> On Wed 21-09-16 06:06:44, Chen Gang wrote:
>> On 9/20/16 16:09, Michal Hocko wrote:
> [...]
>
> skipping the large part of the email because I d
On 9/20/16 16:09, Michal Hocko wrote:
> On Tue 20-09-16 05:46:58, Chen Gang wrote:
>>
>> For me, it really need return false:
>>
>> - For real implementation, when do nothing, it will return false.
>>
>> - I assume that the input page already is in a n
angelog explaining why this makes
> sense.
>
If our original implementation already used bool, our this issue (return
-EAGAIN) would be avoided (compiler would help us to find this issue).
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
If necessary to send patch v3 for it, please let me know (I guess not).
Next, I shall try to find and make another patches for our kernel.
Thanks.
On 9/7/16 23:39, Chen Gang wrote:
>
> Thank you all for your work. Commonly, I should send patch v3 for it.
>
> And very sorry for
On 9/4/16 09:01, Al Viro wrote:
> On Sun, Sep 04, 2016 at 06:36:56AM +0800, Chen Gang wrote:
>
>> And for all: shall I provide the proof for another archs?
>>
>> For me, Boolean gives additional chance to compiler to improve the code.
>
> Whereas for compiler i
On 9/4/16 09:01, Al Viro wrote:
> On Sun, Sep 04, 2016 at 06:36:56AM +0800, Chen Gang wrote:
>
>> And for all: shall I provide the proof for another archs?
>>
>> For me, Boolean gives additional chance to compiler to improve the code.
>
> Whereas for compiler i
cc-6-s390x-linux-gnu and crosstool gcc:
>
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_s390x-linux.tar.xz
>
>> --- a/arch/s390/include/asm/bitops.h~a
>> +++ a/arch/s390/include/asm/bitops.h
>> @@ -40,6 +40,7 @@
>> #error only can be included directly
>> #endif
>>
>> +#include
>> #include
>> #include
>> #include
>
> Regards,
> Fengguang
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
On 9/3/16 08:07, Vineet Gupta wrote:
> On 09/02/2016 04:33 PM, Chen Gang wrote:
>> On 9/2/16 04:43, Al Viro wrote:
>>>>
>>>> Can you show a proof that it actually improves anything? He who proposes
>>>> a patch gets to defend it, not the other way rou
On 9/2/16 04:43, Al Viro wrote:
> On Tue, Aug 30, 2016 at 05:49:05AM +0800, Chen Gang wrote:
>
>> Could you provide the related proof?
>>
>> Or shall I try to analyze about it and get proof?
>
> Can you show a proof that it actually improves anything? He who pro
On 8/29/16 21:03, Arnd Bergmann wrote:
> On Sunday 28 August 2016, cheng...@emindsoft.com.cn wrote:
>> From: Chen Gang
>>
>> Also use the same changing to asm-generic, and also use bool variable
>> instead of int variable for mips, mn10300, parisc and tile related
&
On 8/30/16 00:48, Vineet Gupta wrote:
> On 08/29/2016 06:03 AM, Arnd Bergmann wrote:
>> On Sunday 28 August 2016, cheng...@emindsoft.com.cn wrote:
>>> From: Chen Gang
>>>
>>> Also use the same changing to asm-generic, and also use bool variable
>>&
__change_bit(nr, vaddr) change_bit(nr, vaddr)
>149
>150
> > 151static inline bool test_bit(int nr, const unsigned long *vaddr)
>152{
>153return (vaddr[nr >> 5] & (1UL << (nr & 31))) != 0;
>154}
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
On 7/13/16 15:53, Michal Hocko wrote:
> On Wed 13-07-16 00:50:12, Chen Gang wrote:
>>
>>
>> On 7/12/16 15:48, Michal Hocko wrote:
>>> On Tue 12-07-16 03:47:42, Chen Gang wrote:
>>> [...]
>>>> In our case, the 2 output size are same, but under x8
On 7/13/16 15:50, Michal Hocko wrote:
> On Wed 13-07-16 01:03:10, Chen Gang wrote:
>> On 7/12/16 05:17, Andrew Morton wrote:
>>> On Sun, 10 Jul 2016 01:17:05 +0800 cheng...@emindsoft.com.cn wrote:
>>>
>>>> For a pure output parameter:
>>>>
>
arameter (for me, it is OK, there are many cases like this).
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
On 7/12/16 15:48, Michal Hocko wrote:
> On Tue 12-07-16 03:47:42, Chen Gang wrote:
> [...]
>> In our case, the 2 output size are same, but under x86_64, the insns are
>> different. After uses bool, it uses push/pop instead of branch, for me,
>> it should be a little bette
On 7/12/16 12:20, Michael Ellerman wrote:
> Chen Gang writes:
>
>> On 7/11/16 07:47, Dave Hansen wrote:
>>> On 07/09/2016 09:29 AM, cheng...@emindsoft.com.cn wrote:
>>>> -static inline int arch_validate_prot(unsigned long prot)
>>>> +static inli
On 7/12/16 15:15, Vlastimil Babka wrote:
> On 07/11/2016 09:47 PM, Chen Gang wrote:
>>
>>
>> In our case, the 2 output size are same, but under x86_64, the insns are
>> different. After uses bool, it uses push/pop instead of branch, for me,
>> it should be a lit
On 7/11/16 08:26, Minchan Kim wrote:
> On Sat, Jul 09, 2016 at 11:55:04PM +0800, cheng...@emindsoft.com.cn wrote:
>> From: Chen Gang
>>
>> For pure bool function's return value, bool is a little better more or
>> less than int.
>>
>> And return bool
!cpu_has_feature(CPU_FTR_SAO))
return 0;
return 1;
equal to:
return !((prot & PROT_SAO) && !cpu_has_feature(CPU_FTR_SAO));
equal to:
return !(prot & PROT_SAO) || !!cpu_has_feature(CPU_FTR_SAO);
then:
return (prot & PROT_SAO) == 0 || cpu_has_feature(CPU_FTR_SAO);
Thanks
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
define" under arch/, for me, it is
blackfin's issue:
we need use
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
instead of
#define pr_fmt(fmt) "module %s: " fmt, mod->name
I shall send one blackfin patch for it.
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
On 6/10/16 14:14, Michal Hocko wrote:
> On Fri 10-06-16 08:40:30, Chen Gang wrote:
>>
>> On 6/9/16 23:46, Michal Hocko wrote:
> [...]
>>> That's being said, I appreciate an interest in making the code cleaner
>>> but try to think whether these changes are
On 6/9/16 23:46, Michal Hocko wrote:
> On Thu 09-06-16 23:23:52, cheng...@emindsoft.com.cn wrote:
>> From: Chen Gang
>>
>> Merge several statements to one return statement, since the new return
>> statement is still simple enough.
>>
>> Try to let the secon
On 6/10/16 01:39, Rik van Riel wrote:
> On Thu, 2016-06-09 at 23:23 +0800, cheng...@emindsoft.com.cn wrote:
>> From: Chen Gang
>>
>> Merge several statements to one return statement, since the new
>> return
>> statement is still simple enough.
>
> This
On 2016年05月30日 22:33, Joe Perches wrote:
> On Mon, 2016-05-30 at 22:21 +0800, Chen Gang wrote:
>> No, they are not necessary. But for me, it will be more clearer, since
>> in our kernel (at least in include/linux/), almost all Boolean functions
>> use Boolean value or expre
On 5/30/16 22:33, Joe Perches wrote:
> On Mon, 2016-05-30 at 22:21 +0800, Chen Gang wrote:
>> On 5/29/16 23:08, Joe Perches wrote:
>>> These !! uses are't necessary.
>>> The compiler makes the bool return 0 or 1.
>> No, they are not necessary. But for me, it
quot; are often used).
Please help check, and welcome any additional ideas, suggestions, and
completions.
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
Hello all:
Shall I send patch v2 for it? (if really need, please let me know, and I
shall try).
Default, I shall continue to try to find and send another patches for mm
in "include/linux/*.h".
Thanks.
On 5/3/16 00:38, Chen Gang wrote:
> On 5/3/16 00:23, Chen Gang wrote:
>&
On 5/3/16 00:23, Chen Gang wrote:
> On 5/2/16 23:35, Alexander Potapenko wrote:
>> On Mon, May 2, 2016 at 5:13 PM, Chen Gang wrote:
>>>
>>> OK. But it does not look quite easy to use kasan_disable_current() for
>>> INIT_KASAN which is used in INIT_TASK.
>>
On 5/2/16 23:35, Alexander Potapenko wrote:
> On Mon, May 2, 2016 at 5:13 PM, Chen Gang wrote:
>>
>> OK. But it does not look quite easy to use kasan_disable_current() for
>> INIT_KASAN which is used in INIT_TASK.
>>
>> If we have to set "kasan_depth
On 5/2/16 22:23, Alexander Potapenko wrote:
> On Mon, May 2, 2016 at 3:51 PM, Chen Gang wrote:
>>
>> OK, thanks.
>>
>> And for "kasan_depth == 1", I guess, its meaning is related with
>> kasan_depth[++|--] in kasan_[en|dis]able_current():
> Assumin
On 5/2/16 20:42, Alexander Potapenko wrote:
> On Mon, May 2, 2016 at 2:27 PM, Chen Gang wrote:
>> On 5/2/16 19:21, Dmitry Vyukov wrote:
>>>
>>> Signed counter looks good to me.
>>
>> Oh, sorry, it seems a little mess (originally, I need let the 2 patc
On 5/2/16 19:23, Alexander Potapenko wrote:
> On Mon, May 2, 2016 at 1:20 PM, Chen Gang wrote:
>> On 5/2/16 18:49, Alexander Potapenko wrote:
>>> On Mon, May 2, 2016 at 7:35 AM, wrote:
>>>>
>>>> According to their comments and the kasan_depth's
On 5/2/16 19:21, Dmitry Vyukov wrote:
> On Mon, May 2, 2016 at 1:11 PM, Chen Gang wrote:
>> On 5/2/16 16:26, Dmitry Vyukov wrote:
>>> If you want to improve kasan_depth handling, then please fix the
>>> comments and make disable increment and enable decrement (pote
On 5/2/16 19:34, Alexander Potapenko wrote:
> On Mon, May 2, 2016 at 7:36 AM, wrote:
>> From: Chen Gang
>>
>> According to kasan_[dis|en]able_current() comments and the kasan_depth'
>> s initialization, if kasan_depth is zero, it means disable.
> The comments
t;
>> Also remove useless comments for dummy kasan_slab_free().
>>
>> Signed-off-by: Chen Gang
>
> Acked-by: Alexander Potapenko
>
OK, thanks.
Another patch thread is also related with this patch thread, please help
check.
And sorry, originally, I did not let the 2
On 5/2/16 16:26, Dmitry Vyukov wrote:
> On Mon, May 2, 2016 at 7:36 AM, wrote:
>> From: Chen Gang
>>
>> According to kasan_[dis|en]able_current() comments and the kasan_depth'
>> s initialization, if kasan_depth is zero, it means disable.
>>
>
On 2/29/16 06:23, Theodore Ts'o wrote:
> On Sun, Feb 28, 2016 at 08:47:23AM +0800, Chen Gang wrote:
>>
>> Excuse me, when I sent this patch, I did not know who I shall send to, I
>> have to reference to "./scripts/get_maintainer.pl".
>>
>> If
On 2/28/16 21:27, Mel Gorman wrote:
> On Sun, Feb 28, 2016 at 08:21:40AM +0800, Chen Gang wrote:
>>
>> For me, NAK also needs reasons.
>>
>
> You already got the reasons. Not only does a patch of this type interfere
> with git blame which is important even in
On 2/28/16 07:14, Jiri Kosina wrote:
> On Sat, 27 Feb 2016, Chen Gang wrote:
>
>>> Mel, as an MM developer, has already NACK'ed the patch, which means
>>> you should not send the patch to **any** upstream maintainer for
>>> inclusion.
>>
>> I
On 2/28/16 00:53, Theodore Ts'o wrote:
> On Sat, Feb 27, 2016 at 10:32:04PM +0800, Chen Gang wrote:
>> I don't think so. Of cause NOT the "CODE CHURN". It is not correct to
>> make an early decision during discussing.
>
> There is no discussion. If
On 2/27/16 10:45, Theodore Ts'o wrote:
> On Fri, Feb 26, 2016 at 11:26:02PM +0800, Chen Gang wrote:
>>> As for coding style, actually IMHO this patch is even _not_ a coding
>>> style, more like a code shuffle, indeed.
>>>
>>
>> "80 column l
On 2/26/16 10:32, Jianyu Zhan wrote:
> On Fri, Feb 26, 2016 at 6:29 AM, Chen Gang wrote:
>> git is a tool mainly for analyzing code, but not mainly for normal
>> reading main code.
>>
>> So for me, the coding styles need not consider about git.
>
> For you, ma
On 2/26/16 07:12, SeongJae Park wrote:
>
> On Fri, 26 Feb 2016, Chen Gang wrote:
>
>>
>> git is a tool mainly for analyzing code, but not mainly for normal
>> reading main code.
>>
>> So for me, the coding styles need not consider about git.
>
>
&
On 2/26/16 06:39, Jiri Kosina wrote:
> On Fri, 26 Feb 2016, Chen Gang wrote:
>
>> git is a tool mainly for analyzing code, but not mainly for normal
>> reading main code.
>>
>> So for me, the coding styles need not consider about git.
>
> You are mistaken he
h
> is encountered then the tree before that commit needs to be examined
> which adds time. It's rare that cleanup patches on their own are useful
> and this is one of those cases.
>
git is a tool mainly for analyzing code, but not mainly for normal
reading main code.
So fo
On 2/25/16 23:12, Jiri Kosina wrote:
> On Thu, 25 Feb 2016, Chen Gang wrote:
>
>> I can understand for your NAK, it is a trivial patch.
>
> Not all trivial patches are NAKed :) But they have to be generally useful.
>
> Shuffling code around, without actually chang
hless:
The shared header files (e.g. in our case), have more chances to be
read or printed than the normal source code files. So for me, we need
take more care about the coding styles of them.
For git-blame:
- It really a good feature! Originally, I did not know about it :-).
- Can it instead of sending trivial patch? (I guess not).
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
On 2/25/16 17:27, Mel Gorman wrote:
> On Thu, Feb 25, 2016 at 06:26:31AM +0800, cheng...@emindsoft.com.cn wrote:
>> From: Chen Gang
>>
>> Always notice about 80 columns, and the white space near '|'.
>>
>> Let the wrapped function parameters align
rce gfp_t)___GFP_MOVABLE) /* ZONE_MOVABLE
allowed */
+#define __GFP_MOVABLE /* ZONE_MOVABLE allowed */ \
((__force gfp_t)___GFP_MOVABLE)
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
n can be applied to below similar changes, too.
>
At least for me, what you said above is OK (it is a common way).
And welcome other members' suggestions.
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
On 1/28/16 15:22, Heiko Carstens wrote:
> On Mon, Jan 25, 2016 at 04:58:18AM +0800, cheng...@emindsoft.com.cn wrote:
>> From: Chen Gang
>>
>> hlist_bl_unhashed() and hlist_bl_empty() are all boolean functions, so
>> return bool instead of int.
>>
>> Signe
ersion 6.0.0 20151121 (experimental) (GCC)
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
tomer in Guangzhou (but at last, I guess, it is not kernel issue).
Thanks.
On 1/14/16 23:39, Chen Gang wrote:
>
> On 1/14/16 06:54, Al Viro wrote:
>> On Thu, Jan 14, 2016 at 06:39:53AM +0800, Chen Gang wrote:
>>
>>>> As for the inlines... frankly, if gcc generates
gt; return movable_node_enabled;
> }
> @@ -397,14 +405,6 @@ static inline unsigned long memblock_reg
> for (idx = 0; idx < memblock_type->cnt; \
>idx++,rgn = &memblock_type->regions[idx])
>
> -#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
&
h/*/include/asm/".
So for me, at present, it is only used by x86, so is move to "arch/x86/
include/asm/"; if another archs want it, they can copy one. If quite a
few archs (e.g. > 3 archs) need it, move it to "include/asm-generic".
Thanks.
--
Chen Gang (陈刚)
It is a trivial patch.
Signed-off-by: Chen Gang
---
include/asm-generic/pgtable-nopmd.h | 3 ++-
include/asm-generic/pgtable-nopud.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/pgtable-nopmd.h
b/include/asm-generic/pgtable-nopmd.h
index 725612b
On 12/16/15 04:26, Joe Perches wrote:
> On Tue, 2015-12-15 at 22:15 +0800, Chen Gang wrote:
>> It is a trivial patch.
> []
>> diff --git a/include/asm-generic/pgtable-nopmd.h
>> b/include/asm-generic/pgtable-nopmd.h
> []
>> @@ -38,7 +38,8 @@ static
ion of macro
>> 'set_pud'
>> #define set_pgd(pgdptr, pgdval) (set_pud((pud_t *)(pgdptr), \
>>
>
> This is a result of the added braces, please redo the patch.
>
OK, thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which G
After this patch, I finish 'scanning' mm related headers in
"include/asm-genric/*".
Next I shall continue 'scanning' mm related headers in
"include/linux/*" to know about the common sense information.
Thanks.
On 12/15/15 22:15, Chen Gang wrote:
>
It is a trivial patch.
Signed-off-by: Chen Gang
---
include/asm-generic/pgtable-nopmd.h | 3 ++-
include/asm-generic/pgtable-nopud.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/pgtable-nopmd.h
b/include/asm-generic/pgtable-nopmd.h
index 725612b
, pgprot_writecombine is the part of pgprot_noncached.
for x86 arch, it has its own pgprot_modify.
Thanks.
On 12/13/15 17:12, Chen Gang wrote:
>
> pgprot_val() likes an empty operation, and all three checking statements
> are related with oldprot, so only check once is enough, the reason is:
>
Return the immediate number directly.
Signed-off-by: Chen Gang
---
include/asm-generic/pgtable.h | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index aecf0141..069536a 100644
--- a/include
free time).
And thank my company for the support.
Thanks.
On 12/13/15 17:08, Chen Gang wrote:
>
> Notice about 80 columns, and function parameters alignment.
>
> Export zero_pfn only once.
>
> Remove pte variable in ptep_get_and_clear_full().
>
> Signed-off-by: Che
;pgprot_noncached(oldprot) == pgprot_writecombine(oldprot)", too.
- So as the result, it is still equal to check once (for pgprot_device
can get the same result).
Then can return directly.
Signed-off-by: Chen Gang
---
include/asm-generic/pgtable.h | 6 +++---
1 file changed, 3 insertions(+)
Notice about 80 columns.
Notice about function parameter alignment.
Append 'UL' to hard code numbers which are related with the unsigned
long variables.
Signed-off-by: Chen Gang
---
include/asm-generic/tlb.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
Notice about 80 columns, and function parameters alignment.
Export zero_pfn only once.
Remove pte variable in ptep_get_and_clear_full().
Signed-off-by: Chen Gang
---
include/asm-generic/pgtable.h | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/include/asm
It is a trivial patch.
Signed-off-by: Chen Gang
---
include/asm-generic/page.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/page.h b/include/asm-generic/page.h
index 67cfb7d..e04cef4 100644
--- a/include/asm-generic/page.h
+++ b/include/asm-generic
define MADV_DONTNEED4 /* don't need these pages */
> -#define MADV_FREE5 /* free pages only if memory pressure */
>
> /* common parameters: try to keep these consistent across architectures */
> #define MADV_FREE8 /* fre
On 2015年10月28日 15:18, Minchan Kim wrote:
> Hello Chen,
>
> n Fri, Dec 05, 2014 at 06:58:29AM +0800, Chen Gang wrote:
>> For uapi, need try to let all macros have same value, and MADV_FREE is
>> added into main branch recently, so need redefine MADV_FREE for it.
>>
>&
>From 97df54f9625dae3c61f65e1f0da794718262cd69 Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Tue, 13 Oct 2015 23:24:02 +0800
Subject: [PATCH] arch/blackfin/kernel/stacktrace.c: Use __builtin_frame_address
instead of asm("FP")
When latest gcc build kernel with "-fno-omit-fram
>From 71fbe2eb02be288558b62045dbf56825afb99cbb Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Tue, 6 Oct 2015 00:16:23 +0800
Subject: [PATCH] mm/mmap.c: Do not initialize retval in mmap_pgoff()
When fget() fails, can return -EBADF directly.
Signed-off-by: Chen Gang
---
mm/mmap.c | 5 ++---
>From 4150fd59c4aa35d36e81920ecb2a522c8c7b68b9 Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Mon, 5 Oct 2015 23:43:30 +0800
Subject: [PATCH] mm/mmap.c: Remove redundant statement "error = -ENOMEM"
It is still a little better to remove it, although it should be skipped
by "-O
> From: aarca...@redhat.com
>
> Hello Chen,
>
> On Sun, Oct 04, 2015 at 12:55:29PM +0800, Chen Gang wrote:
>> Theoretically, the lock and unlock need to be symmetric, if we have to
>> lock f_mapping all firstly, then lock all anon_vma, probably, we also
>> need to
Oh, really. Thanks.
>
> git blame often explains funky code. :-)
>
Next, I shall check the git log before make patches, each time. :-)
Theoretically, the lock and unlock need to be symmetric, if we have to
lock f_mapping all firstly, then lock all anon_vma, probably, we also
ne
>From 5a6ffe3515c21d1152586e484c29fed91d2b0b6f Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sun, 4 Oct 2015 03:47:24 +0800
Subject: [PATCH] mm/mmap.c: Change static function __install_special_mapping
args' order
Let __install_special_mapping() args order match the caller, so the
ca
>From 36dbcc145819655682f80efd49e72b01515b4e9a Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sun, 4 Oct 2015 03:22:41 +0800
Subject: [PATCH] mm/mmap.c: Remove redundant vma looping
vma->vm_file->f_mapping and vma->anon_vma are shared with the same vma
looping, so merge them.
S
On 10/2/15 03:07, Jesper Nilsson wrote:
> Hi,
>
> On Sat, Jul 11, 2015 at 05:47:24AM +0800, Chen Gang wrote:
>> For arch-v10, there is no DTP0 register, and at present, assembler know
>> BAR, so use BAR instead of DTP0, the related error (with allmodconfig):
>>
>
%rbx,%rdi
5cd: e8 00 00 00 00 callq 5d2
5d2: 48 98 cltq
5d4: 48 85 c0test %rax,%rax
5d7: 48 0f 45 d8 cmovne %rax,%rbx
5db: e9 45 ff ff ff jmpq 525
Thank
On 9/11/15 02:19, Oleg Nesterov wrote:
> On 09/10, Chen Gang wrote:
>> - If "addr>= vm_start", we return this vma (else continue searching).
>
> This is optimization, we can stop the search because in this case
> vma == tmp is obviously the 1st vma with "addr
On 9/10/15 00:26, Oleg Nesterov wrote:
> On 09/08, Chen Gang wrote:
>>
>> I also want to consult: the comments of find_vma() says:
>
> Sorry, I don't understand the question ;)
>
>> "Look up the first VMA which satisfies addr < vm_end, ..."
>>
On 9/7/15 15:24, Michal Hocko wrote:
> On Sat 05-09-15 18:11:40, Chen Gang wrote:
>> Hello All:
>>
>> I have send 2 new patches about mm, and 1 patch for arch metag via my
>> 21cn mail. Could any members help to tell me, whether he/she have
>> received the patche
On 9/7/15 20:36, Oleg Nesterov wrote:
> On 09/05, Chen Gang wrote:
>>
>> From b12fa5a9263cf4c044988e59f0071f4bcc132215 Mon Sep 17 00:00:00 2001
>> From: Chen Gang
>> Date: Sat, 5 Sep 2015 21:49:56 +0800
>> Subject: [PATCH] mm/mmap.c: Remove useless stat
On 9/7/15 20:41, Oleg Nesterov wrote:
> On 09/05, Chen Gang wrote:
>>
>> From a1bf4726f71d6d0394b41309944646fc806a8a0c Mon Sep 17 00:00:00 2001
>> From: Chen Gang
>> Date: Sat, 5 Sep 2015 21:51:08 +0800
>> Subject: [PATCH] mm/mmap.c: Remove redunde
>From a1bf4726f71d6d0394b41309944646fc806a8a0c Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sat, 5 Sep 2015 21:51:08 +0800
Subject: [PATCH] mm/mmap.c: Remove redundent 'get_area' function pointer in
get_unmapped_area()
Call the function pointer directly, then let code a bit sim
>From b12fa5a9263cf4c044988e59f0071f4bcc132215 Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sat, 5 Sep 2015 21:49:56 +0800
Subject: [PATCH] mm/mmap.c: Remove useless statement "vma = NULL" in
find_vma()
Before the main looping, vma is already is NULL, so need not set it t
>From 89b6f4ac64f5204752fd98998df9db058b6b Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sat, 5 Sep 2015 17:29:23 +0800
Subject: [PATCH] metag/kernel/stacktrace.c: Use current_stack_pointer instead
of current_sp
Since we have defined current_stack_pointer, current_sp is redudancy,
lcome any ideas, suggestions, or completion.
Thanks.
On 9/4/15 18:09, Chen Gang wrote:
> Hello all:
>
> It seems 21cn mail can be accepted by our mailing list (I didn't receive
> any rejective notification mail from our mailing list).
>
> If it is necessary to send the patch again v
On 9/3/15 11:05, Chen Gang wrote:
> On 4/17/15 22:02, Chen Gang wrote:
>> On 4/17/15 11:02, Zhang, Sonic wrote:
>>> Hi Gang,
>>>
>>> Please only use the GCC for Blackfin 2013R1 or 2014R1 from
>>> https://sourceforge.net/projects/adi-buildroot/files/
lient.
Welcome any ideas, suggestions, and completions.
Thanks.
On 9/1/15 21:49, Chen Gang wrote:
>
> Sorry for the incorrect format of the patch. So I put the patch into the
> attachment which generated by "git format-patch -M HEAD^". Please help
> check, thanks.
>
> Next,
Hello Maintainers:
Please help check this patch when you have time.
Thanks.
On 8/24/15 01:18, Chen Gang wrote:
> In pfm_smpl_buffer_alloc, insert_vm_struct may also return -ENOMEM, so
> need check it too.
>
> And insert_vm_struct needn't consider about pfm_remap_buffer in
- it looks the comments is not match
the implementation, precisely (maybe not 1st VMA).
Thanks.
On 9/3/15 11:52, gang.chen.5...@gmail.com wrote:
> From: Chen Gang
>
> Before the main looping, vma is already is NULL, so need not set it to
> NULL, again.
>
> Signed-off-by: Chen
On 4/17/15 22:02, Chen Gang wrote:
> On 4/17/15 11:02, Zhang, Sonic wrote:
>> Hi Gang,
>>
>> Please only use the GCC for Blackfin 2013R1 or 2014R1 from
>> https://sourceforge.net/projects/adi-buildroot/files/ . Upstream GCC5 isn't
>> ported to Blackfin
4:54, Chen Gang wrote:
> When failure occurs, we need not call khugepaged_enter_vma_merge() or
> validate_mm().
>
> Also simplify do_munmap(): declare 'error' 1 time instead of 2 times in
> sub-blocks.
>
> Signed-o
When failure occurs, we need not call khugepaged_enter_vma_merge() or
validate_mm().
Also simplify do_munmap(): declare 'error' 1 time instead of 2 times in
sub-blocks.
Signed-off-by: Chen Gang
---
mm/mmap.c | 116 +++---
1 fi
s of the code
> conflicts.
>
> But as I've said, if others feel this is worthwhile I will not object.
>
OK, I can understand.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 8/25/15 05:25, Andrew Morton wrote:
> On Mon, 24 Aug 2015 13:32:13 +0200 Michal Hocko wrote:
>
>> On Mon 24-08-15 00:59:39, gang.chen.5...@qq.com wrote:
>>> From: Chen Gang
>>>
>>> When failure occurs and return, vma->vm_pgoff is already set, which
1 - 100 of 1721 matches
Mail list logo
