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
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.
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 <cheng...@emindsoft.com.cn>
>
> 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 com
...@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, kerne
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
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
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
og 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.
og 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
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
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
with Debian's gcc-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.
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/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 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 <cheng...@emindsoft.com.cn>
>>
>> Also use the same changing to asm-generic, and also use bool variable
>> instead of int variable for mips,
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 <cheng...@emindsoft.com.cn>
>>>
>>> Also use the same changing to asm-generic, and
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
>>&
static 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.
static 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: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:
>>>>
>
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:
>>>>
>
ter (for me, it is OK, there are many cases like this).
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
ter (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 li
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 li
On 7/12/16 12:20, Michael Ellerman wrote:
> Chen Gang <cheng...@emindsoft.com.cn> 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(unsig
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/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 <cheng...@emindsoft.com.cn>
>>
>> For pure bool function's return value, bool is a little better more or
>> less than int.
>>
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 boolea
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.
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.
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.
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 a
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 a
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 <cheng...@emindsoft.com.cn>
>>
>> Merge several statements to one return statement, since the new return
>> statement is still simple enough.
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 <cheng...@emindsoft.com.cn>
>>
>> Merge several statements to one return statement, since the new
>> return
>> statement
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.
>
>
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
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
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 will
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 will
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.
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:
>&
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 <cheng...@emindsoft.com.cn> wrote:
>>>
>>> OK. But it does not look quite easy to use kasan_disable_current() for
>>> INIT_KASAN
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 <cheng...@emindsoft.com.cn> 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
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_d
On 5/2/16 22:23, Alexander Potapenko wrote:
> On Mon, May 2, 2016 at 3:51 PM, Chen Gang <cheng...@emindsoft.com.cn> wrote:
>>
>> OK, thanks.
>>
>> And for "kasan_depth == 1", I guess, its meaning is related with
>> kasan_depth[++|--] in kasan_[
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():
> Assu
On 5/2/16 20:42, Alexander Potapenko wrote:
> On Mon, May 2, 2016 at 2:27 PM, Chen Gang <cheng...@emindsoft.com.cn> wrote:
>> On 5/2/16 19:21, Dmitry Vyukov wrote:
>>>
>>> Signed counter looks good to me.
>>
>> Oh, sorry, it seems a little mess (origina
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 <cheng...@emindsoft.com.cn> wrote:
>> On 5/2/16 18:49, Alexander Potapenko wrote:
>>> On Mon, May 2, 2016 at 7:35 AM, <cheng...@emindsoft.com.cn> wrote:
>>
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 i
On 5/2/16 19:21, Dmitry Vyukov wrote:
> On Mon, May 2, 2016 at 1:11 PM, Chen Gang <cheng...@emindsoft.com.cn> 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 disab
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 (p
On 5/2/16 19:34, Alexander Potapenko wrote:
> On Mon, May 2, 2016 at 7:36 AM, <cheng...@emindsoft.com.cn> wrote:
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> According to kasan_[dis|en]able_current() comments and the kasan_depth'
>> s initializ
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 for t
about the 0 overflow.
>>
>> Also remove useless comments for dummy kasan_slab_free().
>>
>> Signed-off-by: Chen Gang <gang.chen.5...@gmail.com>
>
> Acked-by: Alexander Potapenko <gli...@google.com>
>
OK, thanks.
Another patch thread is also related wi
;
>> 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 patch
On 5/2/16 16:26, Dmitry Vyukov wrote:
> On Mon, May 2, 2016 at 7:36 AM, <cheng...@emindsoft.com.cn> wrote:
>> From: Chen Gang <cheng...@emindsoft.com.cn>
>>
>> According to kasan_[dis|en]able_current() comments and the kasan_depth'
>> s initialization, i
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 any m
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 any m
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
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
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 don'
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 don'
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 the ma
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 the ma
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 limita
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 limita
On 2/26/16 10:32, Jianyu Zhan wrote:
> On Fri, Feb 26, 2016 at 6:29 AM, Chen Gang <cheng...@emindsoft.com.cn> 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 a
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
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 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
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
ch
> 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 for me, the
ch
> 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 for me, the
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
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
1 - 100 of 3442 matches
Mail list logo
