Commit-ID: fe3464ca8710012a247bb4586dde21b080f88514
Gitweb: http://git.kernel.org/tip/fe3464ca8710012a247bb4586dde21b080f88514
Author: Jianyu Zhan <nasa4...@gmail.com>
AuthorDate: Sat, 19 Mar 2016 21:59:19 +0800
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Fri,
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
restore for
processors supporting xsave") seems
unintendedly fix this ?
Regards,
Jianyu Zhan
supporting xsave") seems
unintendedly fix this ?
Regards,
Jianyu Zhan
On Wed, Apr 13, 2016 at 11:11 AM, Jianyu Zhan <nasa4...@gmail.com> wrote:
>
> So I suspect there is a possible race:
>
>
>Parent:
>
>sys_execve
> do_execve
>do_execve_common
> search_binary_handl
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
ace 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
e 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
They have the same functionalities as irq_domain_add_{linear, tree},
except fro accepting different first argument.
Signed-off-by: Jianyu Zhan <nasa4...@gmail.com>
---
v1->v2:
Fix spelling error.
Documentation/IRQ-domain.txt | 12
1 file changed, 12 insertions(+)
d
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/
They have the same functionalities as irq_domain_add_{linear, tree},
except fro accepting different first argument.
Signed-off-by: Jianyu Zhan <nasa4...@gmail.com>
---
Documentation/IRQ-domain.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/IRQ-domain
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
for_each_irq_desc() macro has already skipped NULL irq_desc, don't
bother to check it again.
Signed-off-by: Jianyu Zhan <nasa4...@gmail.com>
---
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..5
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/kernel
ank you for your patient explanation .:-)
Regards,
Jianyu Zhan
atient explanation .:-)
Regards,
Jianyu Zhan
On Sun, Mar 13, 2016 at 5:11 PM, Thomas Gleixner <t...@linutronix.de> wrote:
> On Sun, 13 Mar 2016, Jianyu Zhan wrote:
>> On Sun, Mar 13, 2016 at 3:55 PM, Thomas Gleixner <t...@linutronix.de> wrote:
>> > if LOCAL_APIC is disabled it does not use
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
C(for self
IPI), though it could
* be turned on ! CONFIG_X86_LOCAL_APIC.
* 0xef:
* Local APIC timer vector.
Regards,
Jianyu Zhan
self
IPI), though it could
* be turned on ! CONFIG_X86_LOCAL_APIC.
* 0xef:
* Local APIC timer vector.
Regards,
Jianyu Zhan
On Sun, Mar 13, 2016 at 3:25 PM, Jianyu Zhan <nasa4...@gmail.com> 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_LOC
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_API
-#endif
>> >> for_each_clear_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
(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
fine 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
IRST_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
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 <l...@intel.com> wrote:
> Hi Jianyu,
>
> [auto build test ERROR on tip/x86/core
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 buil
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 <nasa4...@gmail.com>
---
arch/x86/include/asm/desc.h | 2 ++
ar
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 | 3
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 <nasa4...@gmail.com>
---
arch/x86/kernel/irqinit.
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
this
layout.
Signed-off-by: Jianyu Zhan <nasa4...@gmail.com>
---
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 6
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
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
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
s the final type to use in 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
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
Commit-ID: 10ee73865e9e4705ba8b3f4d6149e8e68d902bb7
Gitweb: http://git.kernel.org/tip/10ee73865e9e4705ba8b3f4d6149e8e68d902bb7
Author: Jianyu Zhan <nasa4...@gmail.com>
AuthorDate: Thu, 10 Mar 2016 20:19:58 +0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 10 Ma
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
in log, but nothing.
This patch turns it on for i386 in do_trap().
Signed-off-by: Jianyu Zhan <nasa4...@gmail.com>
---
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/ker
in log, 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
Commit-ID: 29b75eb2d56a714190a93d7be4525e617591077a
Gitweb: http://git.kernel.org/tip/29b75eb2d56a714190a93d7be4525e617591077a
Author: Jianyu Zhan <nasa4...@gmail.com>
AuthorDate: Mon, 7 Mar 2016 09:32:24 +0800
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Tue
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
eviewing and
suggestion.
Acked-by: Christian Borntraeger <borntrae...@de.ibm.com>
Signed-off-by: Jianyu Zhan <nasa4...@gmail.com>
---
kernel/futex.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 5d6ce64..25dbfe
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 ++--
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
ded 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
-by: Christian Borntraeger <borntrae...@de.ibm.com>
Signed-off-by: Jianyu Zhan <nasa4...@gmail.com>
---
kernel/futex.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 5d6ce64..58c1bcc 100644
--- a/kernel/futex.c
+++ b/kernel/
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(+)
lines:14/248=6%,removed_lines:49/119=41%)
So original author's 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
l 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
tion 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
tion 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
;we can defer the 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
ve".
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
clarification.
> Maybe simplify the comment to something like
>
> /* Prevent the compiler to read lock_ptr twice (if and spin_lock) */
Will do.
Regards,
Jianyu Zhan
plify the comment to something like
>
> /* Prevent the compiler to read lock_ptr twice (if and spin_lock) */
Will do.
Regards,
Jianyu Zhan
iler from doing this:
|
|while (tmp = READ_ONCE(a))
| do_something_with(tmp);
Suggested-by: Darren Hart <dvh...@infradead.org>
Signed-off-by: Jianyu Zhan <nasa4...@gmail.com>
---
v1->v2:
According to suggestion by Darren Hart, revise the commit log to justify t
iler 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 maintainers
gt; many times, quoted from
>
> 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
>
> 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
er would 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
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
nt and
the 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
thing_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
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: Jia
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
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
>>> + 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
UPPORTS_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
> +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
hes.
I don't think it is helpful for a non-layman contributor to keep
generating such code churn.
Thanks,
Jianyu Zhan
a non-layman contributor to keep
generating such code churn.
Thanks,
Jianyu Zhan
er() is compiler-level
barrier, and smp_*mb() is processor-level barrier" by rote ,
especially for the new comers to memory-barriers.txt. ;-)
Thanks,
Jianyu Zhan
smp_*mb() is processor-level barrier" by rote ,
especially for the new comers to memory-barriers.txt. ;-)
Thanks,
Jianyu Zhan
data in that very page.
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
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
PORTS_DEBUG_PAGEALLOC.
IIUC, calling kernel_poison_pages() before kernel_map_pages() will be
equivalent to call kernel_poison_pages()
twice?!
Thanks,
Jianyu Zhan
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
NG users(currently only DEBUG_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
age poisoning scheme for
!ARCH_SUPPORTS_DEBUG_PAGEALLOC.
IIUC, calling kernel_poison_pages() before kernel_map_pages() will be
equivalent to call kernel_poison_pages()
twice?!
Thanks,
Jianyu Zhan
incorrectly 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
tion levels. This commit therefore
> updates the summary to match the detailed description.
>
> Reported by: Jianyu Zhan <nasa4...@gmail.com>
> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
>
> diff --git a/Documentation/memory-barriers.
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
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
the 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
the 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 nasa4...@gmail.com
---
kernel/time/timekeeping.c | 52
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
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 jianyu.z...@emc.com
---
include/linux/gfp.h | 7 ++-
1 file changed, 2
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;", bu
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 yaodongd...@huawei.com wrote:
The table shows CPU2's sequence of events as x = B; y
nd 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,
Jianyu Zhan
--
To unsubscribe from this list: send the
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/
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't really fix
From: Jianyu Zhan jianyu.z...@emc.com
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't really
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/
are right.
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/
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.
>
> -
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
1 - 100 of 307 matches
Mail list logo
