On 2016/04/20 at 21:17, Peter Zijlstra wrote:
> On Wed, Apr 20, 2016 at 09:00:32PM +0800, Xunlei Pang wrote:
>
>>> But what happens? How is it changed when it is blocked?
>> The top waiter's policy can be changed by other tasks through
>> sched_setattr() sys
Hi Peter,
On 2016/04/20 at 21:49, Xunlei Pang wrote:
> On 2016/04/20 at 21:19, Peter Zijlstra wrote:
>> On Thu, Apr 14, 2016 at 07:37:03PM +0800, Xunlei Pang wrote:
>>> + /* Updated under pi_lock and rtmutex lock */
>>> struct rb_node *pi_waiters_leftm
On 2016/04/07 at 02:14, Peter Zijlstra wrote:
> On Wed, Apr 06, 2016 at 08:59:15PM +0800, Xunlei Pang wrote:
>> A crash happened while I'm playing with deadline PI rtmutex.
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0018
>> I
sk" was already initiated.
After that we again safely removed the NULL cpumask judgement from
find_lowest_rq() and find_later_rq(), because "sched_pp_shared_mask"
was surely initialized before the first SMP scheduling happens.
Inspired-by: Peter Zijlstra
Signed-off-by: Xunlei
On 2016/04/09 at 02:59, Peter Zijlstra wrote:
> On Fri, Apr 08, 2016 at 02:50:55PM -0400, Steven Rostedt wrote:
>> On Fri, 8 Apr 2016 19:38:35 +0200
>> Peter Zijlstra wrote:
>>
>>> On Fri, Apr 08, 2016 at 12:25:10PM -0400, Steven Rostedt wrote:
>>>
So the preempt_disable() is to allow us to s
On 2016/04/09 at 03:28, Steven Rostedt wrote:
> On Fri, 8 Apr 2016 15:15:42 -0400
> Steven Rostedt wrote:
>
>> From what I understand, the slowfn() modifies the task pi_list (or
>> rbtree, as it is today). As this is an unlock, the task being woken
>> (the next one to grab the lock) is removed fro
On 2016/04/09 at 21:29, Peter Zijlstra wrote:
> On Sat, Apr 09, 2016 at 11:25:39AM +0800, Xunlei Pang wrote:
>
>>> In any case, I just realized we do not in fact provide this guarantee
>>> (of pointing to a blocked task) that needs a bit more work.
>> Current pa
On 2016/04/04 at 22:58, Michael Holzheu wrote:
> Hello Xunlei,
>
> On Sat, 2 Apr 2016 09:23:50 +0800
> Xunlei Pang wrote:
>
>> On 2016/04/02 at 01:41, Michael Holzheu wrote:
>>> Hello Xunlei again,
>>>
>>> Some initial comments below...
>>&g
mory to be mapped
initially, so get rid of S390 crash kernel memblock removal
in reserve_crashkernel(). Once kdump kernel is loaded, the
new arch_kexec_protect_crashkres() implemented for S390 will
actually unmap the pgtable like before.
Cc: Heiko Carstens
Signed-off-by: Xunlei Pang
Signed-off-b
On 2016/04/02 at 05:51, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 09:34:24PM +0800, Xunlei Pang wrote:
>
>>>> I checked the code, currently only deadline accesses the
>>>> pi_waiters/pi_waiters_leftmost
>>>> without pi_lock held via rt_mutex_get_top
On 2016/04/05 at 17:13, Michael Holzheu wrote:
> Hello Xunlei,
>
> On Tue, 5 Apr 2016 15:09:59 +0800
> Xunlei Pang wrote:
>> Commit 3f625002581b ("kexec: introduce a protection mechanism
>> for the crashkernel reserved memory") is a similar mechanism
>>
On 2016/04/05 at 17:29, Peter Zijlstra wrote:
> On Tue, Apr 05, 2016 at 11:19:54AM +0200, Peter Zijlstra wrote:
>> Or did I miss something (again) ? :-)
>>
>> ---
>> kernel/locking/rtmutex.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/locking/rtmutex.c b/
On 2016/03/31 at 11:52, Xunlei Pang wrote:
> Hi Bao,
>
> On 2016/03/31 at 10:52, Baoquan He wrote:
>> On 03/31/16 at 10:43am, Minfei Huang wrote:
>>> On 03/30/16 at 08:30pm, Baoquan He wrote:
>>>> Hi Xunlei,
>>>>
>>>> I have two questio
task.
We don't remove rt_mutex:pi_waiters_leftmost, as it is quite possible
for many tasks sharing one rtmutex.
Thus, hereby remove pi_waiters_leftmost from task_struct.
Signed-off-by: Xunlei Pang
---
include/linux/init_task.h | 1 -
include/linux/sched.h | 1 -
ker
, with several
tweaks and improvements by me.
Tested-by: Xunlei Pang
Originally-From: Peter Zijlstra (Intel)
Signed-off-by: Xunlei Pang
---
Without the patch, kernel crashes in seconds, after the patch
it can survive overnight.
include/linux/init_task.h | 3 +-
include/linux/sched.h |
so above logic will always
return 0, this is wrong.
To solve this, we added extra deadline comparing, and let the
task with smaller deadline win, or the top waiter win if equal.
Signed-off-by: Xunlei Pang
---
kernel/locking/rtmutex.c | 19 ---
1 file changed, 16 insertions(+), 3
On 2016/04/06 at 17:30, Peter Zijlstra wrote:
> On Sat, Apr 02, 2016 at 06:14:28PM +0800, Xunlei Pang wrote:
>> Your proposal is very nice!
>>
>> At the sched_init() stage we only have one (to be "idle") task and with irq
>> disabled,
>> no scheduling
On 2016/04/18 at 16:23, Thomas Gleixner wrote:
> On Thu, 14 Apr 2016, Xunlei Pang wrote:
>> We should deboost before waking the high-prio task such that
>> we don't run two tasks with the 'same' priority.
> No. This is fundamentaly broken.
>
> T1 (prio 0)
On 2016/04/18 at 17:02, Thomas Gleixner wrote:
> On Mon, 18 Apr 2016, Xunlei Pang wrote:
>> On 2016/04/18 at 16:23, Thomas Gleixner wrote:
>>> On Thu, 14 Apr 2016, Xunlei Pang wrote:
>>>> We should deboost before waking the high-prio task such that
>>>
mory to be mapped
initially, this is done in machine_kdump_pm_init() which is
after reserve_crashkernel(). Once kdump kernel is loaded, the
new arch_kexec_protect_crashkres() implemented for S390 will
actually unmap the pgtable like before.
Acked-by: Michael Holzheu
Cc: Heiko Carstens
Signed-off-
tor.
Suggested-by: Peter Zijlstra
Signed-off-by: Xunlei Pang
---
v3 -> v4:
Improved changelog.
kernel/futex.c | 5 ++---
kernel/locking/rtmutex.c| 28
kernel/locking/rtmutex_common.h | 1 +
3 files changed, 27 insertions(+), 7 deletions(-)
ex.
Originally-From: Peter Zijlstra
Signed-off-by: Xunlei Pang
---
v3 -> v4:
Cache a task_struct pi_top_task pointer instead of rt_mutex_waiter.
include/linux/init_task.h | 1 +
include/linux/sched.h | 2 ++
include/linux/sched/rt.h | 1 +
kernel/for
d0)
([<0063067c>] system_call+0x244/0x264)
Cc: Michael Holzheu
Signed-off-by: Xunlei Pang
---
Tested kexec/kdump on S390x
arch/s390/kernel/machine_kexec.c | 86 ++--
arch/s390/kernel/setup.c | 7 ++--
include/linux/kexec.h
ap/unmap_reserved_pages() and
arch_kexec_protect(unprotect)_crashkres()
[Patch03(x86_64)] kexec: provide arch_kexec_protect(unprotect)_crashkres()
I don't know if it is possible to reorder that since they are already in
"linux-next", ask Andrew for help :-)
Regards,
Xunlei
>&
ue_pi() and rt_mutex_dequeue_pi()
lock rq when operating "pi_waiters" and "pi_waiters_leftmost".
We need this iff lock owner has the deadline priority.
Signed-off-by: Xunlei Pang
---
include/linux/sched/deadline.h | 3 +++
kernel/locking/rtmutex.c | 18 ++
Unlike rt tasks, we (should) have no deadline tasks in
booting phase before the mask is allocated, so we can
safely remove the check.
Signed-off-by: Xunlei Pang
---
kernel/sched/deadline.c | 4
1 file changed, 4 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
On 2016/04/01 at 19:29, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 07:13:18PM +0800, Xunlei Pang wrote:
>> Unlike rt tasks, we (should) have no deadline tasks in
>> booting phase before the mask is allocated, so we can
>> safely remove the check.
> Why? And have th
On 2016/04/01 at 19:38, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 07:00:18PM +0800, Xunlei Pang wrote:
>> I found a kernel crash while playing with deadline PI rtmutex.
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0018
>> I
On 2016/04/01 at 21:12, Peter Zijlstra wrote:
>
> On 1 April 2016 14:23:58 CEST, Xunlei Pang wrote:
>
>>>> We need this iff lock owner has the deadline priority.
>>> How is this deadline specific, those functions you modify are
>>> deadline/rt agnostic
On 2016/04/02 at 01:41, Michael Holzheu wrote:
> Hello Xunlei again,
>
> Some initial comments below...
>
> On Wed, 30 Mar 2016 19:47:21 +0800
> Xunlei Pang wrote:
>
>> Commit 3f625002581b ("kexec: introduce a protection mechanism
>> for the crashkernel re
On 2016/04/02 at 00:21, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 08:16:37PM +0800, Xunlei Pang wrote:
>> On 2016/04/01 at 19:29, Peter Zijlstra wrote:
>>> On Fri, Apr 01, 2016 at 07:13:18PM +0800, Xunlei Pang wrote:
>>>> Unlike rt tasks, we (should) have no
On 2016/04/02 at 05:51, Peter Zijlstra wrote:
> On Fri, Apr 01, 2016 at 09:34:24PM +0800, Xunlei Pang wrote:
>
>>>> I checked the code, currently only deadline accesses the
>>>> pi_waiters/pi_waiters_leftmost
>>>> without pi_lock held via rt_mutex_get_top
On 2016／04／10 at 16:22, Xunlei Pang wrote:
> On 2016/04/09 at 21:29, Peter Zijlstra wrote:
>> On Sat, Apr 09, 2016 at 11:25:39AM +0800, Xunlei Pang wrote:
>>
>>>> In any case, I just realized we do not in fact provide this guarantee
>>>> (of pointing to a b
On 2016/04/12 at 23:51, Peter Zijlstra wrote:
> On Tue, Apr 12, 2016 at 11:08:04AM +0800, Xunlei Pang wrote:
>> I spotted another issue, we access pi_task without any lock in
>> enqueue_task_dl(),
> OK, so I'm on the road and entirely jetlagged, but how can
> enqueue_t
From: Xunlei Pang
WQ_CPU_INTENSIVE is meaningless for the unbound workqueue, so remove it.
Signed-off-by: Xunlei Pang
---
drivers/md/dm-crypt.c | 4 ++--
drivers/md/dm-verity.c | 3 ++-
drivers/md/raid5.c | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md
From: Xunlei Pang
Currently, get_unbound_pool() uses kzalloc() to allocate the
worker pool. Actually, we can use the right node to do the
allocation, achieving local memory access.
This patch selects target node first, and uses kzalloc_node()
instead.
Signed-off-by: Xunlei Pang
---
kernel
e, since we
> need to start a new timer if the current one is in the process of
> finishing.
>
> Signed-off-by: Ben Segall
> ---
We've also suffered from this performance issue recently:
Reviewed-by: Xunlei Pang
> kernel/sched/fair.c | 7 +++
> kernel/sched/sched.
On 12/08/2016 at 10:37 AM, zhongjiang wrote:
> From: zhong jiang
>
> A soft lookup will occur when I run trinity in syscall kexec_load.
> the corresponding stack information is as follows.
>
> [ 237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
> [ 237.242699] Kernel panic -
On 01/23/2017 at 10:50 PM, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 09:35:53PM +0800, Xunlei Pang wrote:
>> One possible timing sequence would be:
>> 1st kernel running on multiple cpus panicked
>> then the crash dump code starts
>> the crash dump code stops
On 01/24/2017 at 01:51 AM, Borislav Petkov wrote:
> Hey Tony,
>
> a "welcome back" is in order? :-)
>
> On Mon, Jan 23, 2017 at 09:40:09AM -0800, Luck, Tony wrote:
>> If the system had experienced some memory corruption, but
>> recovered ... then there would be some pages sitting around
>> that the
On 01/24/2017 at 09:46 AM, Xunlei Pang wrote:
> On 01/24/2017 at 01:51 AM, Borislav Petkov wrote:
>> Hey Tony,
>>
>> a "welcome back" is in order? :-)
>>
>> On Mon, Jan 23, 2017 at 09:40:09AM -0800, Luck, Tony wrote:
>>> If the system had e
On 01/24/2017 at 02:14 AM, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 10:01:53AM -0800, Luck, Tony wrote:
>> will ignore the machine check on the other cpus ... assuming
>> that "cpu_is_offline(smp_processor_id())" does the right thing
>> in the kexec case where this is an "old" cpu that isn'
On 01/24/2017 at 08:22 PM, Borislav Petkov wrote:
> On Tue, Jan 24, 2017 at 09:27:45AM +0800, Xunlei Pang wrote:
>> It occurred on real hardware when testing crash dump.
>>
>> 1) SysRq-c was injected for the test in 1st kernel
>> [ 49.897279] SysRq : Trigger a crash 2)
CRASH_KERNEL_ADDR_MAX has been missing for a long time,
update it with more detailed explanation.
Cc: Robert LeBlanc
Cc: Baoquan He
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/setup.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86
/patch/6167631/
https://lists.gt.net/linux/kernel/2146557
Cc: Naoya Horiguchi
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/cpu/mcheck/mce.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck
On 01/23/2017 at 04:48 PM, Dave Young wrote:
> Hi, Xunlei
>
> On 01/23/17 at 02:48pm, Xunlei Pang wrote:
>> CRASH_KERNEL_ADDR_MAX has been missing for a long time,
>> update it with more detailed explanation.
>>
>> Cc: Robert LeBlanc
>> Cc: Ba
On 01/23/2017 at 08:51 PM, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 04:01:51PM +0800, Xunlei Pang wrote:
>> We met an issue for kdump: after kdump kernel boots up,
>> and there comes a broadcasted mce in first kernel, the
> How does that even happen?
>
> Lemm
ction.
>
> While we are at it we also optimize things further calling setup_new_dl_
> entity only for already queued tasks, since (as pointed out by Xunlei)
> we already do the very same update at tasks wakeup time anyway.
>
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc:
On 2016/07/18 at 21:04, Juri Lelli wrote:
> On 15/07/16 18:39, Xunlei Pang wrote:
>> On 2016/07/13 at 18:58, Juri Lelli wrote:
> [...]
>
>> Since this is only called for queued cases now, there is no need to
>> check boosted stuff here. As enqueue_task(ENQUEUE_REP
On 2016/06/14 at 18:21, Juri Lelli wrote:
> Hi,
>
> On 07/06/16 21:56, Peter Zijlstra wrote:
>> From: Xunlei Pang
>>
>> A crash happened while I was playing with deadline PI rtmutex.
>>
>> BUG: unable to handle kernel NULL pointer de
On 2016/07/13 at 09:50, Wanpeng Li wrote:
> 2016-07-13 1:25 GMT+08:00 :
>> Konstantin Khlebnikov writes:
>>
>>> On 11.07.2016 15:12, Xunlei Pang wrote:
>>>> On 2016/07/11 at 17:54, Wanpeng Li wrote:
>>>>> Hi Konstantin, Xunlei,
>>>>
On 2016/07/25 at 11:04, Wei, Jiangang wrote:
> Hi He,
>
> Thanks for your response firstly.
>
> On Fri, 2016-07-22 at 18:40 +0800, Baoquan He wrote:
>> Hi Jiangang,
>>
>> This is very nice, should be the stuff Eric and Ingo would like to see.
>> But I have several questions:
>>
>> 1) Are you not go
Ping
On 2016/05/12 at 11:36, Xunlei Pang wrote:
> On 2016/05/11 at 14:49, Peter Zijlstra wrote:
>> On Tue, May 10, 2016 at 11:19:44AM -0700, bseg...@google.com wrote:
>>> Xunlei Pang writes:
>>>
>>>> Two minor fixes for cfs_rq_clock_task().
>>>>
Ping
Could someone have some comments on this bug?
On 2016/04/26 at 16:30, Xunlei Pang wrote:
> A crash happened while I was playing with deadline PI rtmutex.
>
> BUG: unable to handle kernel NULL pointer dereference at 0018
> IP: [] rt_mutex_get_top_task+0x1f/0x
can survive the kdump tests.
CC: Myron Stowe
CC: Don Brace
CC: Baoquan He
CC: Dave Young
Tested-by: Joseph Szczypek
Signed-off-by: Xunlei Pang
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers
Ccing David
On 2016/11/16 at 17:02, Xunlei Pang wrote:
> We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
> under kdump, it can be steadily reproduced on several different machines,
> the dmesg log is like:
> HP HPSA Driver (v 3.4.16-0)
> hpsa :02:00.0:
On 2016/11/16 at 22:58, Myron Stowe wrote:
> On Wed, Nov 16, 2016 at 2:13 AM, Xunlei Pang wrote:
>> Ccing David
>> On 2016/11/16 at 17:02, Xunlei Pang wrote:
>>> We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
>>> under kdump, it can
Ping David for confirmation
On 2016/09/19 at 20:18, Joerg Roedel wrote:
> [Cc'ing David]
>
> On Mon, Sep 12, 2016 at 10:49:11AM +0800, Xunlei Pang wrote:
>> According to the vt-d spec, the size of pasid (state) entry is 8B
>> which equals 3 in power of 2, the number of p
Ping Joerg/David, do you have any comment on it?
On 2016/11/19 at 00:23, Xunlei Pang wrote:
> We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
> under kdump, it can be steadily reproduced on several different machines,
> the dmesg log is like(running on 4.9.0-rc
es us 1MiB
> tables — still not ideal, but better than before.
>
> Reported by Mika Kuoppala and also by
> Xunlei Pang who submitted a simpler patch to fix
> only the allocation (and not the free) to the "correct" limit... which
> was still problematic.
>
> Si
On 12/19/2016 at 11:23 AM, Baoquan He wrote:
> On 12/09/16 at 03:16pm, Xunlei Pang wrote:
>> On 12/09/2016 at 01:13 PM, zhong jiang wrote:
>>> On 2016/12/8 17:41, Xunlei Pang wrote:
>>>> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
>>>>> From: zhong jia
On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote:
> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote:
>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
>>> When trying to configure crashkernel greater than about 800 MB, the
>>> kernel fails to allocate memory on x86 and x86_64. This is due to an
>>>
On 12/14/2016 at 11:08 AM, Xunlei Pang wrote:
> On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote:
>> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote:
>>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
>>>> When trying to configure crashkernel greater than about 80
On 12/15/2016 at 01:50 AM, Robert LeBlanc wrote:
> On Tue, Dec 13, 2016 at 8:08 PM, Xunlei Pang wrote:
>> On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote:
>>> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote:
>>>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
CRASH_KERNEL_ADDR_MAX was missing for a long time, update it
with more detailed explanation.
Cc: Robert LeBlanc
Cc: Baoquan He
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/setup.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86
On 12/22/2016 at 11:22 AM, Baoquan He wrote:
> On 12/15/16 at 11:30am, Xunlei Pang wrote:
>> CRASH_KERNEL_ADDR_MAX was missing for a long time, update it
>> with more detailed explanation.
>>
>> Cc: Robert LeBlanc
>> Cc: Baoquan He
>> Signed-off-by:
On 12/01/2016 at 06:33 PM, Joerg Roedel wrote:
> On Thu, Dec 01, 2016 at 10:15:45AM +0800, Xunlei Pang wrote:
>> index 3965e73..624eac9 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -2024,6 +2024,25 @@ static int domain
vt-d: Copy translation tables from old kernel")
Fixes: dbcd861f252d ("iommu/vt-d: Do not re-use domain-ids from the old kernel")
Fixes: cf484d0e6939 ("iommu/vt-d: Mark copied context entries")
Signed-off-by: Xunlei Pang
---
v2->v3:
Flush context cache only and add Fixes-tag, ac
On 11/29/2016 at 10:35 PM, Joerg Roedel wrote:
> On Thu, Nov 17, 2016 at 10:47:28AM +0800, Xunlei Pang wrote:
>> As per the comment, the code here only needs to flush context caches
>> for the special domain 0 which is used to tag the
>> non-present/erroneous caches, seems we
On 11/30/2016 at 10:26 PM, Joerg Roedel wrote:
> On Wed, Nov 30, 2016 at 06:23:34PM +0800, Baoquan He wrote:
>> OK, talked with Xunlei. The old cache could be entry with present bit
>> set.
> -EPARSE
>
> Anyway, what I was trying to say is, that the IOMMU TLB is tagged with
> domain-ids, and that t
ff-by: Xunlei Pang
---
v1 -> v2:
Flush caches using old domain id.
drivers/iommu/intel-iommu.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3965e73..653304d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b
On 12/09/2016 at 01:13 PM, zhong jiang wrote:
> On 2016/12/8 17:41, Xunlei Pang wrote:
>> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
>>> From: zhong jiang
>>>
>>> A soft lookup will occur when I run trinity in syscall kexec_load.
>>> the
On 03/21/2017 at 11:33 AM, Eric W. Biederman wrote:
> Xunlei Pang writes:
>
>> As Eric said,
>> "what we need to do is move the variable vmcoreinfo_note out
>> of the kernel's .bss section. And modify the code to regenerate
>> and keep this inform
On 03/22/2017 at 04:55 PM, Xunlei Pang wrote:
> On 03/21/2017 at 11:33 AM, Eric W. Biederman wrote:
>> Xunlei Pang writes:
>>
>>> As Eric said,
>>> "what we need to do is move the variable vmcoreinfo_note out
>>> of the kernel's .bss section.
On 03/22/2017 at 04:55 PM, Xunlei Pang wrote:
> On 03/21/2017 at 11:33 AM, Eric W. Biederman wrote:
>> Xunlei Pang writes:
>>
>>> As Eric said,
>>> "what we need to do is move the variable vmcoreinfo_note out
>>> of the kernel's .bss section.
On 03/22/2017 at 12:30 PM, Dave Young wrote:
> On 03/21/17 at 10:18pm, Eric W. Biederman wrote:
>> Dave Young writes:
>>
>>> On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
>>>> Xunlei Pang writes:
>>>>
>>>>> As Eric said,
>
On 03/23/2017 at 04:48 AM, Michael Holzheu wrote:
> Am Wed, 22 Mar 2017 12:30:04 +0800
> schrieb Dave Young :
>
>> On 03/21/17 at 10:18pm, Eric W. Biederman wrote:
>>> Dave Young writes:
>>>
> [snip]
>
I think makedumpfile is using it, but I also vote to remove the
CRASHTIME. It is bette
On 03/18/2017 at 01:22 AM, Eric W. Biederman wrote:
> Xunlei Pang writes:
>
>> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
>> it has the risk of being modified by some wrong code during system
>> is running.
>>
>> As a result,
On 03/19/2017 at 02:23 AM, Petr Tesarik wrote:
> On Thu, 16 Mar 2017 21:40:58 +0800
> Xunlei Pang wrote:
>
>> On 03/16/2017 at 09:18 PM, Baoquan He wrote:
>>> On 03/16/17 at 08:36pm, Xunlei Pang wrote:
>>>> On 03/16/2017 at 08:27 PM, Baoquan He wrote:
>>
On 03/18/2017 at 01:38 AM, Eric W. Biederman wrote:
> Xunlei Pang writes:
>
>> kexec setups identity mappings for all the memory mapped in 1st kernel,
>> this is not necessary for the kdump case. Actually it can cause extra
>> memory consumption for paging structures, whi
On 03/20/2017 at 10:13 AM, Baoquan He wrote:
> On 03/17/17 at 12:22pm, Eric W. Biederman wrote:
>> Xunlei Pang writes:
>>
>>> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
>>> it has the risk of being modified by some wrong code during sy
On 03/20/2017 at 11:55 AM, Baoquan He wrote:
> On 03/20/17 at 10:39am, Xunlei Pang wrote:
>> On 03/20/2017 at 10:13 AM, Baoquan He wrote:
>>> On 03/17/17 at 12:22pm, Eric W. Biederman wrote:
>>>> Xunlei Pang writes:
>>>>
>>>>> Currentl
se
vmcoreinfo now is kept far away from other kernel data structures.
Suggested-by: Eric Biederman
Signed-off-by: Xunlei Pang
---
arch/ia64/kernel/machine_kexec.c | 5 -
arch/x86/kernel/crash.c | 2 +-
include/linux/kexec.h| 2 +-
kernel/kexec_core
se this new one instead in
the following crash_save_vmcoreinfo().
BTW, we do not touch vmcoreinfo_note, because it will be fully updated
using the protected vmcoreinfo_data after crash which is surely correct
just like the cpu crash note.
Signed-off-by: Xunlei Pang
---
include/linux/kexec.h | 3 +
x it, also this change should be safe
and backward compatible.
After this, we can get rid of variable vmcoreinfo_max_size,
let's use the macro VMCOREINFO_BYTES instead, fewer variables
means more safety for vmcoreinfo operation.
Signed-off-by: Xunlei Pang
---
arch/powerpc/kernel/fadump.c |
Cc: Kirill A. Shutemov
Signed-off-by: Xunlei Pang
---
arch/x86/mm/ident_map.c| 22 ++
include/asm-generic/5level-fixup.h | 6 +++---
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c
index 04210a
On 03/20/2017 at 09:04 PM, Petr Tesarik wrote:
> On Mon, 20 Mar 2017 10:17:42 +0800
> Xunlei Pang wrote:
>
>> On 03/19/2017 at 02:23 AM, Petr Tesarik wrote:
>>> On Thu, 16 Mar 2017 21:40:58 +0800
>>> Xunlei Pang wrote:
>>>
>>>> On 03/16/2017
On 03/24/2017 at 01:46 AM, Michael Holzheu wrote:
> Am Thu, 23 Mar 2017 17:23:53 +0800
> schrieb Xunlei Pang :
>
>> On 03/23/2017 at 04:48 AM, Michael Holzheu wrote:
>>> Am Wed, 22 Mar 2017 12:30:04 +0800
>>> schrieb Dave Young :
>>>
>>>> On 03
teed.
Signed-off-by: Xunlei Pang
---
kernel/kexec_core.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index bfe62d5..1bfdd96 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1367,12 +1
you think?
Regards,
Xunlei
>
> Baoquan
>
> On 03/16/17 at 08:16pm, Xunlei Pang wrote:
>> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
>> it has the risk of being modified by some wrong code during system
>> is running.
>>
>> As a resu
On 03/16/2017 at 09:18 PM, Baoquan He wrote:
> On 03/16/17 at 08:36pm, Xunlei Pang wrote:
>> On 03/16/2017 at 08:27 PM, Baoquan He wrote:
>>> Hi Xunlei,
>>>
>>> Did you really see this ever happened? Because the vmcore size estimate
>>> feature, namel
ave_vmcoreinfo() to see if
the signature was broken, if so we have to re-save the vmcoreinfo data
to get the correct vmcoreinfo for kdump as possible as we can.
Signed-off-by: Xunlei Pang
---
v1->v2:
- Keep crash_save_vmcoreinfo_init() because "makedumpfile --mem-usage"
uses the informati
the
crash memory and the ISA memory(may be needed by purgatory/kdump boot).
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/machine_kexec_64.c | 34 ++
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/
Ping Boris
On 02/23/2017 at 09:36 PM, Xunlei Pang wrote:
> We met an issue for kdump: after kdump kernel boots up,
> and there comes a broadcasted mce in first kernel, the
> other cpus remaining in first kernel will enter the old
> mce handler of first kernel, then timeout and panic
On 02/20/2017 at 07:09 PM, Borislav Petkov wrote:
> On Mon, Feb 20, 2017 at 02:10:37PM +0800, Xunlei Pang wrote:
>> @@ -1128,8 +1129,9 @@ void do_machine_check(struct pt_regs *regs, long
>> error_code)
>> */
>> int lmce = 1;
>>
>> -/
/linux/kernel/2146557
Cc: Naoya Horiguchi
Suggested-by: Borislav Petkov
Signed-off-by: Xunlei Pang
---
v1->v2:
Using crashing_cpu according to Borislav's suggestion.
v2->v3:
- Used crashing_cpu in mce.c explicitly, not skip crashing_cpu.
- Added some comments.
arch/x86/include/a
On 02/22/2017 at 02:20 AM, Luck, Tony wrote:
>> It's from my understanding, I didn't get the explicit description from the
>> intel SDM on this point.
>> If a broadcast SRAO comes on real hardware, will MSR_IA32_MCG_STATUS of each
>> cpu have MCG_STATUS_RIPV bit set?
> MCG_STATUS is a per-thread
On 02/23/2017 at 02:50 AM, Luck, Tony wrote:
> On Wed, Feb 22, 2017 at 12:11:14PM +0800, Xunlei Pang wrote:
>> +/*
>> + * Cases to bail out to avoid rendezvous process timeout:
>> + * 1)If this CPU is offline.
>> + * 2)If crashing_cpu was set, e.g. ente
/linux/kernel/2146557
Cc: Naoya Horiguchi
Suggested-by: Borislav Petkov
Signed-off-by: Xunlei Pang
---
v1->v2:
- Using crashing_cpu according to Borislav's suggestion.
v2->v3:
- Used crashing_cpu in mce.c explicitly, not skip crashing_cpu.
- Added some comments.
v3->v4:
- A
On 01/26/2017 at 02:44 PM, Borislav Petkov wrote:
> On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
>> The hardware machine check is hard to reproduce, but the mce code of
>> RHEL7 is quite the same as that of tip/master, anyway we are able to
>> inject softwar
301 - 400 of 553 matches
Mail list logo
