[tip:irq/core] genirq: Remove redundant NULL check of irq_desc

Commit-ID: fe3464ca8710012a247bb4586dde21b080f88514 Gitweb: http://git.kernel.org/tip/fe3464ca8710012a247bb4586dde21b080f88514 Author: Jianyu Zhan AuthorDate: Sat, 19 Mar 2016 21:59:19 +0800 Committer: Thomas Gleixner CommitDate: Fri, 10 Jun 2016 17:07:49 +0200 genirq: Remove

Re: Possible race in copy of fpu->state in copy_process against the exeve'ing parent?

se non-lazy fpu restore for processors supporting xsave") seems unintendedly fix this ? Regards, Jianyu Zhan

Re: Possible race in copy of fpu->state in copy_process against the exeve'ing parent?

On Wed, Apr 13, 2016 at 11:11 AM, Jianyu Zhan wrote: > > So I suspect there is a possible race: > > >Parent: > >sys_execve > do_execve >do_execve_common > search_binary_handler > load_elf_binary

Possible race in copy of fpu->state in copy_process against the exeve'ing parent?

;state is NULL. The race window seems quite small, and I have checked the Parent's 'sum_exec_runtime' is 536920255(~0.53s). I checked the mainline, and found commit 304bceda6a18(" x86, fpu: use non-lazy fpu restore for processors supporting xsave") seems unintendedly fix this? Regards, Jianyu Zhan

[PATCH] Documentation/IRQ-domain.txt: Document irq_domain_create_{linear, tree}

They have the same functionalities as irq_domain_add_{linear, tree}, except fro accepting different first argument. Signed-off-by: Jianyu Zhan --- v1->v2: Fix spelling error. Documentation/IRQ-domain.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/

[PATCH] Documentation/IRQ-domain.txt: Document irq_domain_create_{linear, tree}

They have the same functionalities as irq_domain_add_{linear, tree}, except fro accepting different first argument. Signed-off-by: Jianyu Zhan --- Documentation/IRQ-domain.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ

[PATCH] genirq: Remove redundent check of NUll'ness of irq_desc

for_each_irq_desc() macro has already skipped NULL irq_desc, don't bother to check it again. Signed-off-by: Jianyu Zhan --- kernel/irq/proc.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c index 4e1b947..50a8f28 100644 --- a/k

Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on

et. Thank you for your patient explanation .:-) Regards, Jianyu Zhan

Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on

On Sun, Mar 13, 2016 at 5:11 PM, Thomas Gleixner wrote: > On Sun, 13 Mar 2016, Jianyu Zhan wrote: >> On Sun, Mar 13, 2016 at 3:55 PM, Thomas Gleixner wrote: >> > if LOCAL_APIC is disabled it does not use the interrupt, simply because >> > there >> > is no way

Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on

(for self IPI), though it could * be turned on ! CONFIG_X86_LOCAL_APIC. * 0xef: * Local APIC timer vector. Regards, Jianyu Zhan

Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on

On Sun, Mar 13, 2016 at 3:25 PM, Jianyu Zhan wrote: > My purpose of posting this patch set is trying to make the system vector > layout > reveal this fact. > > we have SMP system vector defined first( these may rely on or not rely > on CONFIG_X86_LOCAL_APIC),

Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on

r_bit_from(i, used_vectors, first_system_vector) { >> > >> > And how exactly is this here supposed to compile when >> > CONFIG_X86_LOCAL_APIC=n? >> >> Dunno. I guess this code on !CONFIG_X86_LOCAL_APIC case hasn't been >> tested yet ? > > It's your job to at least compile test your patches not the job of others. > Will do in next round. Regards, Jianyu Zhan

Re: [PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on

e #define FIRST_SYSTEM_VECTOR NR_VECTORS #endif For CONFIG_X86_LOCAL_APIC case, the define makes sense. But for ! CONFIG_X86_LOCAL_APIC case, why we confine it to NR_VECTORS is a mystery to me. Have digged into git history, but found no proof. So to maintain consistency, this patch just retain what it is, but we do not bother update it for !CONFIG_X86_LOCAL_APIC case. Regards, Jianyu Zhan

Re: [PATCH 2/3] x86/irq: refactor native_init_IRQ

HI, This patch is based on tip/master. I have built it locally on my box and did not encounter such problem. Please recheck. Regards, Jianyu Zhan On Sat, Mar 12, 2016 at 11:30 PM, kbuild test robot wrote: > Hi Jianyu, > > [auto build test ERROR on tip/x86/core] > [also build t

[PATCH 3/3] x86/irq: update first_system_vector only when X86_LOCAL_PIC is on

During native_init_IRQ(), we will update first_system_vector conditionally when we init system vector. But on !CONFIG_X86_LOCAL_PIC, we prefer it to NR_IRQS, so don't bother set it on this case. Signed-off-by: Jianyu Zhan --- arch/x86/include/asm/desc.h | 2 ++ arch/x86/kernel/irqinit.c

[PATCH 2/3] x86/irq: refactor native_init_IRQ

After prepatory patch(x86/asm/irq: Rearrange definitoin of specical irq vectors and cleanup) is applied, now refactor native_init_IRQ() per the special irq vectors layout. Signed-off-by: Jianyu Zhan --- arch/x86/kernel/irqinit.c | 68 --- 1 file

[PATCH 1/3] x86/asm/irq: Rearrange definitoin of specical irq vectors and cleanup.

this layout. Signed-off-by: Jianyu Zhan --- arch/x86/include/asm/irq_vectors.h | 72 +- 1 file changed, 55 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h index 6ca9fd6..b785a19 100644

[PATCH 0/3] x86/irq: Refactor special vector definition and cleanup

set has been rebased on tip/master and have done build test and run it for hours, doing daily jobs, and found no problem. Jianyu Zhan (3): x86/asm/irq: Rearrange definitoin of specical irq vectors and cleanup. x86/irq: refactor native_init_IRQ x86/irq: update first_system_vector only when

Re: [PATCH 1/2] [PATCH 1/2] Introduce new macros min_lt and max_lt for comparing with larger type

operation when they have the same type size, so it might be signed or unsigned, depending on the type of y. So, in this /proc/fs/vmcore case you should rather just explicit cast the operand to avoid truncation. [1] http://www.tti.unipa.it/~ricrizzo/KS/Data/PBurden/chap4.usual.conversions.html Regards, Jianyu Zhan

[tip:x86/asm] x86/entry/traps: Show unhandled signal for i386 in do_trap()

Commit-ID: 10ee73865e9e4705ba8b3f4d6149e8e68d902bb7 Gitweb: http://git.kernel.org/tip/10ee73865e9e4705ba8b3f4d6149e8e68d902bb7 Author: Jianyu Zhan AuthorDate: Thu, 10 Mar 2016 20:19:58 +0800 Committer: Ingo Molnar CommitDate: Thu, 10 Mar 2016 18:37:25 +0100 x86/entry/traps: Show

[PATCH RFC] x86/traps: show unhandled signal for i386 in do_trap()

, but nothing. This patch turns it on for i386 in do_trap(). Signed-off-by: Jianyu Zhan --- arch/x86/kernel/traps.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index ade185a..ef54dbb 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kern

[tip:locking/core] futex: Replace barrier() in unqueue_me() with READ_ONCE()

Commit-ID: 29b75eb2d56a714190a93d7be4525e617591077a Gitweb: http://git.kernel.org/tip/29b75eb2d56a714190a93d7be4525e617591077a Author: Jianyu Zhan AuthorDate: Mon, 7 Mar 2016 09:32:24 +0800 Committer: Thomas Gleixner CommitDate: Tue, 8 Mar 2016 17:04:02 +0100 futex: Replace barrier

[PATCH v3] futex: replace bare barrier() with more lightweight READ_ONCE()

302 1e06: 4c 89 ffmov%r15,%rdi 1e09: e8 00 00 00 00 callq 1e0e Code size is also the same. Many thanks to Darren Hart for reviewing and suggestion. Acked-by: Christian Borntraeger Signed-off-by: Jianyu Zhan --- kernel/futex.c | 8 ++--

Re: [PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

ould be added here: if (unlikely(lock_ptr != READ_ONCE(q->lock_ptr))) { <-- spin_unlock(lock_ptr); goto retry; } And I think this are two problem, and should be separated into two patches? Regards, Jianyu Zhan

[PATCH] futex: replace bare barrier() with more lightweight READ_ONCE()

302 1e06: 4c 89 ffmov%r15,%rdi 1e09: e8 00 00 00 00 callq 1e0e Code size is also the same. Suggested-by: Darren Hart Acked-by: Christian Borntraeger Signed-off-by: Jianyu Zhan --- kernel/futex.c | 7 +-- 1 file changed, 5 insertions(+),

Re: about get_maintainer.pl not showing the original author of the modified code

email would be spit out only if given --git-blame, instead of by default, which really surprises people. Since most time we will cc original author, we have to use --git-blame explicitly, thus pay the running time cost. So the runtime argument don't stands, why not just enable it by default? Regards, Jianyu Zhan

about get_maintainer.pl not showing the original author of the modified code

n might be just code polishing. To dig out the original author, we might need go up the commit history and git must be equipped with ability of pattern recognization to analyze code. What do you think? Regards, Jianyu Zhan

Re: a question about slub in function __slab_free()

he list move". But how do we handle this? Easy, just mark it frozen, and latter that CPU's per-cpu freelist queue will use it. Regards, Jianyu Zhan

Re: [PATCH v2] futex: replace bare barrier() with a READ_ONCE()

Maybe simplify the comment to something like > > /* Prevent the compiler to read lock_ptr twice (if and spin_lock) */ Will do. Regards, Jianyu Zhan

[PATCH v2] futex: replace bare barrier() with a READ_ONCE()

the compiler from doing this: | |while (tmp = READ_ONCE(a)) | do_something_with(tmp); Suggested-by: Darren Hart Signed-off-by: Jianyu Zhan --- v1->v2: According to suggestion by Darren Hart, revise the commit log to justify the replacement. I also cc'ed the s390

Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

> Which is already covered by the barrier() in place today as a more general > compiler barrier. > > Your argument is then simply that READ_ONCE is a more specific solution to the > problem. > Yep. And after re-thinking, I am now less convinced in this second argument, since it involves a comparison of q->lock_ptr in the loop body, so this may defeat any attempts that compilers try to optimize the load out of the loop, even without a READ_ONCE(). But I will also incorporate this in the second submission for review . Regards, Jianyu Zhan

Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

ould be a disassembly of the code > block before and after, demonstrating the compiler generating broken code and > the > compiler generating correct code. > > In addition to this, however, I would want to see a strong convincing argument > that the READ_ONCE volatile cast is sufficient to cover the original case > which > motivated the addition of the barrier() (not "apparently" and "could be"). As for #2, this is pure theoretical induction from this quotation, I do have no convincing argument and again I would like Paul to help clarify this. Thanks very much! Regards, Jianyu Zhan

Re: [PATCH] futex: replace bare barrier() with a READ_ONCE()

call to do_something_with(). Again, use READ_ONCE() to prevent the compiler from doing this: while (tmp = READ_ONCE(a)) do_something_with(tmp); So, due to these two reason, I propose this patch. Thanks, Jianyu Zhan

[PATCH] futex: replace bare barrier() with a READ_ONCE()

s effectively the same with: while (lock_ptr = q->lock_ptr) do_something_with(lock_ptr); and compiler is at its will to merge successive load of q->lock_ptr, which is also problematic at this scenario. READ_ONCE() can avoid this problem. Signed-off-by: Jianyu Z

Re: [RFC][PATCH v3 1/2] mm/page_poison.c: Enable PAGE_POISONING as a separate option

return; >>> + >>> + if (enable) >>> + unpoison_pages(page, numpages); >>> + else >>> + poison_pages(page, numpages); >>> +} >>> + >>> +#ifndef CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC >>> +void __kernel_map_pages(struct page *page, int numpages, int enable) >>> +{ >>> + /* This function does nothing, all work is done via poison pages >>> */ >>> +} >>> +#endif >> >> >> IMHO, kernel_map_pages is originally incorporated for debugging page >> allocation. >> And latter for archs that do not support arch-specific page poisoning, >> a software poisoning >> method was used. >> >> So I think it is not appropriate to use two interfaces in the alloc/free >> hooks. >> >> The kernel_poison_pages actually should be an implementation detail >> and should be hided >> in the kernel_map_pages interface. >> > > We want to have the poisoning independent of anything that kernel_map_pages > does. It was originally added for software poisoning for arches that > didn't have the full ARCH_SUPPORTS_DEBUG_PAGEALLOC support but there's > nothing that specifically ties it to mapping. It's beneficial even when > we aren't mapping/unmapping the pages so putting it in kernel_map_pages > would defeat what we're trying to accomplish here. > Ok, fair enough. If so, I suggest you add this clarification into the code, or as least, in the changelog. Thanks, Jianyu Zhan

Re: [RFC][PATCH v3 1/2] mm/page_poison.c: Enable PAGE_POISONING as a separate option

DEBUG_PAGEALLOC > +void __kernel_map_pages(struct page *page, int numpages, int enable) > +{ > + /* This function does nothing, all work is done via poison pages */ > +} > +#endif IMHO, kernel_map_pages is originally incorporated for debugging page allocation. And latter for archs that do not support arch-specific page poisoning, a software poisoning method was used. So I think it is not appropriate to use two interfaces in the alloc/free hooks. The kernel_poison_pages actually should be an implementation detail and should be hided in the kernel_map_pages interface. Thanks, Jianyu Zhan

Re: [PATCH trivial] include/linux/gfp.h: Improve the coding styles

for a non-layman contributor to keep generating such code churn. Thanks, Jianyu Zhan

Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores

smp_*mb() is processor-level barrier" by rote , especially for the new comers to memory-barriers.txt. ;-) Thanks, Jianyu Zhan

Re: [RFC] mm: why we should clear page when do anonymous page fault

age. IIRC, Windows zeros the pages at freeing time. Linux instead does it lazily. And for the userspace zeroing action, it is another problem - user just wants a clean, definitive context to act on ( and we can be sure he/she is a self-disciplined guy who does not peek into other's secret, but we can not assume that for all). Thanks, Jianyu Zhan

Re: [RFC][PATCH 2/3] mm/page_poison.c: Enable PAGE_POISONING as a separate option

PORTS_DEBUG_PAGEALLOC. IIUC, calling kernel_poison_pages() before kernel_map_pages() will be equivalent to call kernel_poison_pages() twice?! Thanks, Jianyu Zhan

Re: [RFC][PATCH 1/3] mm/debug-pagealloc.c: Split out page poisoning from debug page_alloc

UG_PAGEALLOC ). How about like this: +static bool want_page_poisoning __read_mostly = + !IS_ENABLED(CONFIG_PAGE_POISONING ); Or just let it default to 'true', since we only compile this page_poison.c when we enable CONFIG_PAGE_POISONING. Thanks, Jianyu Zhan

Re: Inconsistent description in memory-barrier.txt

correctly states that > barrier() may be used to prevent compiler reordering when more than one > leg of the control-dependent "if" statement start with identical stores. > This is incorrect at high optimization levels. This commit therefore > updates the s

Inconsistent description in memory-barrier.txt

each leg of the "if" statement. This part is incorporated in commit 9b2b3bf53124 ("Documentation/memory-barriers.txt: Need barriers() for some control dependencies"), on 2014-02-12. I think you missed fixing the summary part? Thanks, Jianyu Zhan -- To unsubscribe from this

[PATCH] timekeeping: update raw_time with extra arch_gettimeoffset in timekeeping_forward_now

timekeeping_get_ns_raw helper. This patch unifies the meaning of raw_time. Also, it cleanups the timekeeping_get_ns_raw helper, to make timekeeping_get_ns and timekeeping_forward_now based on it. Signed-off-by: Jianyu Zhan --- kernel/time/timekeeping.c | 52

[PATCH] mm, gfp: escalatedly define GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE

make GFP_HIGHUSER and GFP_HIGHUSER_MOVABLE escalatedly defined to reflect this fact. It also makes the definition clear and texturally warn on any furture break-up of this escalated relastionship. Signed-off-by: Jianyu Zhan --- include/linux/gfp.h | 7 ++- 1 file changed, 2 insertions(+), 5

Re: [PATCH] Documentation/memory-barriers.txt: match table to its comment followed

Hi, Some one has submitted a patch addressing this issue a few days ago. The patch is now being cooked in the paulk's tree now, IIRC. Thanks, Jianyu Zhan On Tue, Sep 16, 2014 at 4:51 PM, Yao Dongdong wrote: > The table shows CPU2's sequence of events as "x = B; y = A;

Re: [PATCH RFC] sysfs: fix the race of "parent deleted before child added"

race window, please track it down and then determine what the proper > fix is. You're now trying to change the basic objection lifetime > rules of the driver model without root causing what's actually going > on. Please don't do things like this. Yep, you are right. Thanks,

Re: [PATCH RFC] sysfs: fix the race of "parent deleted before child added"

o create_dir(), but I think this isn't the real fix, it just narrow down the racy window. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[PATCH RFC] sysfs: fix the race of "parent deleted before child added"

From: Jianyu Zhan I've met such a race conditon the same as what commit 3a198886 ("sysfs: handle 'parent deleted before child added'") tackled. The senario got triggered under a torturing test of quick disk removal and plugging. The forementioned commit 3a198886 didn&#

Re: [PATCH RESEND] kprobes: be more permissive when user specifies both symbol name and address

Sorry for the noise, plz add these Acked-by and Signed-off-by: Acked-by: Masami Hiramatsu Signed-off-by: Jianyu Zhan Thanks, Jianyu Zhan On Tue, Jul 29, 2014 at 8:47 PM, Jianyu Zhan wrote: > Hi, Ingo, > > Here is the new patch with typo fixed. > > Thanks. > > ---8&

Re: [PATCH RESEND] kprobes: be more permissive when user specifies both symbol name and address

Hi, Ingo, Here is the new patch with typo fixed. Thanks. ---8<--- Currently, if user specifies both symbol name and address, we just bail out. This might be too rude. This patch makes it give more tolerance. If both are specified, check address first, if the symbol found does not match the one

[PATCH RESEND] kprobes: be more permissive when user specifies both symbol name and address

;t bother to check symbol name. Acked-by: Masami Hiramatsu Signed-off-by: Jianyu Zhan --- Documentation/kprobes.txt | 4 +++- kernel/kprobes.c | 32 +--- 2 files changed, 32 insertions(+), 4 deletions(-) diff --git a/Documentation/kprobes.txt b/Documen

[tip:perf/core] perf tools: Fix 'make help' message error

Commit-ID: fc9cabeabf42d76854059e7bce81a02645e7e5ca Gitweb: http://git.kernel.org/tip/fc9cabeabf42d76854059e7bce81a02645e7e5ca Author: Jianyu Zhan AuthorDate: Tue, 3 Jun 2014 00:44:34 +0800 Committer: Jiri Olsa CommitDate: Tue, 3 Jun 2014 21:35:12 +0200 perf tools: Fix 'make

Re: [PATCH] perf: fix 'make help' message error

wever, "prefix" is unconditionally assigned to $HOME, regardless of what it is set to from command line. So our "prefix" setting got no respect and the actual destination falls back to $HOME. This patch fixes this issue and corrects the help message. Acked-by: Namhyung Kim Signed-of

Re: [PATCH] fix some coding style problem in drivers/staging/iio/frequency/ad9832.c

nge program. That is a good start to kernel hacking. But also please honour the community rule - the inline patch is preferred than in attachment form . Please have a look at Documentation/SubmittingPatches file in kernel source directory first before submitting patches. Thanks, Jianyu Zhan -- To

Re: [PATCH] perf: fix 'make help' message error

On Tue, Jun 3, 2014 at 12:44 AM, Jianyu Zhan wrote: > Hi, Namhyung, > >>I don't know what's the correct way to do this. But it seems like the >>prefix was overwritten when given from user, so below patch will work >>also. > > This does work too.

Re: [PATCH] perf: fix 'make help' message error

Hi, Namhyung, >I don't know what's the correct way to do this. But it seems like the >prefix was overwritten when given from user, so below patch will work >also. This does work too. So I update the patch as below: ---8<--- From: Jianyu Zhan Date: Sat, 24 May 2014

[PATCH] mm/page-writeback.c: remove outdated comment

global_dirtyable_memory(), which renders this comment ambiguous and useless. Remove it. Signed-off-by: Jianyu Zhan --- mm/page-writeback.c | 18 -- 1 file changed, 18 deletions(-) diff --git a/mm/page-writeback.c b/mm/page-writeback.c index a4317da..f2683ac 100644 --- a/mm/page-writeback.c

[PATCH] perf: fix 'make help' message error

t takes effect is the "DESTDIR" variable. In this case, "DESTDIR" has a empty value, so the actual install directory falls back $HOME, not '/usr/local'. Specifying "DESTDIR=/usr/local" will work as desired. This patch fixes the help message. Signed-off-by:

[PATCH] perf: fix 'make help' message error

t takes effect is the "DESTDIR" variable. In this case, "DESTDIR" has a empty value, so the actual install directory falls back $HOME, not '/usr/local'. Specifying "DESTDIR=/usr/local" will work as desired. This patch fixes the help message. Signed-off-by:

Re: [PATCH] mm/vmscan: Do not block forever at shrink_inactive_list().

d for too long. */ > + if (i == 50 && (current->flags & PF_KTHREAD)) > + break; > } > > lru_add_drain(); Hi, Tetsuo Handa I think it is good to use a MACRO for this magic number instead of harding code it, in a l

Re: time to move fs/bio.c to block/ ?

could make code skeleton more clear and could avoid such mis-sending patches in a long term maintainability view. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH] mm/vmscan.c: use DIV_ROUND_UP for calculation of zone's balance_gap and correct comments.

uot;, not "present pages". This patch also corrects the comment and do some rephrasing. Signed-off-by: Jianyu Zhan --- include/linux/swap.h | 8 mm/vmscan.c | 10 -- 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/include/linux/swap.h b/includ

[PATCH] mm, hugetlb: move the error handle logic out of normal code path

alloc_huge_page() now mixes normal code path with error handle logic. This patches move out the error handle logic, to make normal code path more clean and redue code duplicate. Signed-off-by: Jianyu Zhan --- mm/hugetlb.c | 26 +- 1 file changed, 13 insertions(+), 13

[PATCH] mm, hugetlb: use list_for_each_entry in region_xxx

each_entry is enough. Signed-off-by: Jianyu Zhan --- mm/hugetlb.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index c82290b..26b1464 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -156,7 +156,7 @@ struct file_region { static long region

Re: [PATCH] scripts/tags.sh: add regular expression replacement pattern for memcg

ar expression replacement pattern for such symbols, like what have done for the PageXXX flag. It will teach ctags to find out the definition for us. Signed-off-by: Jianyu Zhan --- scripts/tags.sh | 8 1 file changed, 8 insertions(+) diff --git a/scripts/tags.sh b/scripts/tags.sh inde

[PATCH RESEND] scripts/tags.sh: add regular expression replacement pattern for memcg

id of it. Signed-off-by: Jianyu Zhan --- scripts/tags.sh | 8 1 file changed, 8 insertions(+) diff --git a/scripts/tags.sh b/scripts/tags.sh index f2c5b00..7d3ebfe 100755 --- a/scripts/tags.sh +++ b/scripts/tags.sh @@ -187,6 +187,10 @@ exuberant() --regex-c++='/TESTCL

Re: [PATCH 2/3] mm: use a light-weight __mod_zone_page_state in mlocked_vma_newpage()

Andrew, since the previous patch [PATCH 1/3] mm: add comment for __mod_zone_page_stat is updated, update this one accordingly. -<8- >From 9701fbdb3f9e7730b89780a5bf22effd1580cf35 Mon Sep 17 00:00:00 2001 From: Jianyu Zhan Date: Tue, 13 May 2014 01:48:01 +0800 Subject: [PATCH] mm

Re: [PATCH 1/3] mm: add comment for __mod_zone_page_stat

>Preemption is mis-spelled throughout. > >Otherwise > >Reviewed-by: Christoph Lameter Oops, corrected. Thanks. -<8- >From 1d0a080429542accfeac7de03e159a0bea12abba Mon Sep 17 00:00:00 2001 From: Jianyu Zhan Date: Tue, 13 May 2014 00:19:08 +0800 Subject: [PAT

Re: [PATCH 1/3] mm: add comment for __mod_zone_page_stat

age_state() and some of its callsites. The comment above __mod_zone_page_state() is from Hugh Dickins, and acked by Christoph. Most credits to Hugh and Christoph for the clarification on the usage of the __mod_zone_page_state(). Suggested-by: Andrew Morton Signed-off-by: Hugh Dickins S

Re: [PATCH 1/3] mm: add comment for __mod_zone_page_stat

On Mon, May 12, 2014 at 10:01 PM, Christoph Lameter wrote: > > > >/* > > * For use when we know that interrupts are disabled, > > * or when we know that preemption is disabled and that > > * particular counter cannot be updated from interrupt context. > > */ > > The description above looks ok to m

Re: [PATCH 2/3] mm: use a light-weight __mod_zone_page_state in mlocked_vma_newpage()

age() into its only call site, page_add_new_anon_rmap, to make it open-cocded. Suggested-by: Andrew Morton Suggested-by: Hugh Dickins Signed-off-by: Jianyu Zhan --- mm/internal.h | 31 --- mm/rmap.c | 22 +++--- 2 files changed, 19 insertions(+

Re: [PATCH 1/3] mm: add comment for __mod_zone_page_stat

via the pagetables, and the pte is locked while calling page_add_new_anon_rmap(), so we need not use an irq-safe mod_zone_page_state() here, using a light-weight version __mod_zone_page_state() would be OK. This patch also documents __mod_zone_page_state() and some of its callsites. Suggeste

[PATCH 3/3] mm: rename mlocked_vma_newpage to newpage_in_mlocked_vma

mlocked_vma_newpage is used to determine if a new page is mapped into a *mlocked* vma. It is poorly named, so rename it to newpage_in_mlocked_vma. Signed-off-by: Jianyu Zhan --- mm/internal.h | 4 ++-- mm/rmap.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/mm

[PATCH 2/3] mm: use a light-weight __mod_zone_page_state in mlocked_vma_newpage()

page_add_new_anon_rmap() in rmap.c, with detailed document added. Suggested-by: Andrew Morton Signed-off-by: Jianyu Zhan --- mm/internal.h | 22 ++ mm/rmap.c | 24 2 files changed, 26 insertions(+), 20 deletions(-) diff --git a/mm/internal.h b/mm/internal.h

[PATCH 1/3] mm: add comment for __mod_zone_page_stat

__mod_zone_page_stat() is not irq-safe, so it should be used carefully. And it is not appropirately documented now. This patch adds comment for it, and also documents for some of its call sites. Suggested-by: Andrew Morton Signed-off-by: Jianyu Zhan --- mm/page_alloc.c | 2 ++ mm/rmap.c

Re: [PATCH] mm: use a irq-safe __mod_zone_page_state in mlocked_vma_newpage()

a *new* page. And such page is initially only visible via the pagetables, and the pte is locked while calling page_add_new_anon_rmap(), so we need not use an irq-safe mod_zone_page_state() here, using a light-weight version __mod_zone_page_state() would be OK. Signed-off-by: Jianyu Zhan --- mm/in

[PATCH] mm: use a irq-safe __mod_zone_page_state in mlocked_vma_newpage()

() here. Signed-off-by: Jianyu Zhan --- mm/internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/internal.h b/mm/internal.h index 07b6736..69079b1 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -196,7 +196,7 @@ static inline int mlocked_vma_newpage(struct vm_area_struct

Re: [PATCH] rmap: validate pointer in anon_vma_clone

ointer. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[PATCH 3/3] mm: introdule compound_head_by_tail()

lines, but with a reduced object size. I still believe this helper deserves to exsit. Signed-off-by: Jianyu Zhan --- include/linux/mm.h | 29 + mm/swap.c | 2 +- 2 files changed, 18 insertions(+), 13 deletions(-) diff --git a/include/linux/mm.h b/include/lin

[PATCH 1/3] mm/swap.c: introduce put_[un]refcounted_compound_page helpers for spliting put_compound_page

e path (2), respectively. They both are tagged __always_inline, thus it elmiates function call overhead, making them operating the same way as before. They are almost copied verbatim(except one place, a "goto out_put_single" is expanded), with some comments rephrasing. Signed-off-by: Jian

[PATCH 2/3] mm/swap.c: split put_compound_page function

g has no functinal change, but it brings readability. This patch and the previous one blow the code by 32 lines, which mostly credits to comments. Signed-off-by: Jianyu Zhan --- mm/swap.c | 142 +++--- 1 file changed, 16 insertions(+), 126 dele

Re: [PATCH RFC 2/2] mm: introdule compound_head_by_tail()

ell compiler unlikely, so it happily did as we told it) # all code are compiled by gcc (GCC) 4.8.2 > and why didn't your changelog include this useful information? Sorry, I would have done so. I will resend the patch. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "u

Re: [PATCH RFC 1/2] mm/swap.c: split put_compound_page function

On Mon, Apr 28, 2014 at 11:00 PM, Michal Hocko wrote: > This is a big change and really hard to review to be honest. Maybe a > split up would make it easier to follow. Ok, actually it is quite simple, but the diff looks messy, I will try to split up this patch to several phases. Thanks,

Re: [PATCH RFC 2/2] mm: introdule compound_head_by_tail()

ctually, I checked the assembled code, the compiler is _not_ so smart to recognize this case. It just does optimization as the hint unlikely() told it. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vg

[PATCH RFC 1/2] mm/swap.c: split put_compound_page function

with the original one). Besides, this patch rearranges/rewrites some comments(hope I don't do it wrong). Signed-off-by: Jianyu Zhan --- mm/swap.c | 227 -- 1 file changed, 131 insertions(+), 96 deletions(-) diff --git a/mm/swap.c

[PATCH RFC 2/2] mm: introdule compound_head_by_tail()

compound_head_by_tail() which deal with a possible tail page(though it could be spilt by a racy thread), and make compound_head() a wrapper on it. Signed-off-by: Jianyu Zhan --- include/linux/mm.h | 34 ++ mm/swap.c | 2 +- 2 files changed, 23 insertions

Re: [PATCH] kernfs: move the last knowledge of sysfs out from kernfs

ould be kernfs user specific, so this patch moves it out. Kerrnfs user should specify their magic number while mouting. Signed-off-by: Jianyu Zhan Acked-by: Tejun Heo --- fs/kernfs/mount.c | 11 ++- fs/sysfs/mount.c | 4 +++- include/linux/kernfs.h | 13 - kernel/c

Re: [PATCH 2/4] mm/memcontrol.c: use accessor to get id from css

m and will be sent out soon, so just forget this patch and wait. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Pleas

Re: [PATCH] blk-cgroup: explicitly init the early_init field

is there, docment it should be needed. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/2] mm/memcontrol.c: remove meaningless while loop in mem_cgroup_iter()

ch better to read. hmm, I agree. I will give it more thinking. Seem this has been merged into -mm. Andrew, please drop it! Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More m

Re: [PATCH] netprio_cgroup: explicitly init the early_init field

another field(css_alloc) is a good thing, but since it is there, docment it should be needed. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.o

Re: [PATCH 1/2] mm/memcontrol.c: remove meaningless while loop in mem_cgroup_iter()

nd while loop, and thus omit the while loop, to save a mem_cgroup_iter_update() and a mem_cgroup_iter_update() But it maybe a bit hard to read. If it is OK, I could resend a new one. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the bod

Re: [PATCH 1/2] mm/memcontrol.c: remove meaningless while loop in mem_cgroup_iter()

is condition could be reduced to conditon 2.1 Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 2/4] mm/memcontrol.c: use accessor to get id from css

On Tue, Apr 22, 2014 at 2:30 PM, Jianyu Zhan wrote: > This is a prepared patch for converting from per-cgroup id to > per-subsystem id. > > We should not access per-cgroup id directly, since this is implemetation > detail. Use the accessor css_from_id() instead. > > This pa

Re: [PATCH 4/4] cgroup: convert from per-cgroup id to per-subsys id

ved to css->css_id so that lookups are successful until the target css is released. Signed-off-by: Jianyu Zhan --- include/linux/cgroup.h | 26 +++ kernel/cgroup.c| 88 -- 2 files changed, 56 insertions(+), 58 deletions(-)

Re: [PATCH] cgroup: use uninitialized_var() for may-be uninitialized variable

Hi, Li, On Tue, Apr 22, 2014 at 2:26 PM, Li Zefan wrote: > > I don't see this warning, and I don't see how this is possible. You are right. No such warning. It is triggered by the other patch, should be fixed in that patch. Thanks, Jianyu Zhan -- To unsubscribe from thi

Re: [PATCH] perf-event/cgroup: explicitly init the early_init field

d be needed. I could resend the patch with more comment. Thanks, Jianyu Zhan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 2/4] mm/memcontrol.c: use accessor to get id from css

Cc Andrew. Thanks, Jianyu Zhan On Tue, Apr 22, 2014 at 2:30 PM, Jianyu Zhan wrote: > This is a prepared patch for converting from per-cgroup id to > per-subsystem id. > > We should not access per-cgroup id directly, since this is implemetation > detail. Use the accessor css_fr

Re: [PATCH] hugetlb_cgroup: explicitly init the early_init field

implementation, ->css_alloc will be called earlier before mm_init(). I don't think that the value of one field(early_init) has a so subtle restrition on the another field(css_alloc) is a good thing, but since it is there, docment it should be needed. Thanks, Jianyu Zhan -- To unsubscribe from th

  1   2   >