Hi Pavel,
>>>Well, you can have it as set of 0-1 "limits"...
>>
>>I have come up with a similar idea of regarding the ulimit
>>value as a bitmask, and I think it may work.
>>But it will be confusable for users to add the new concept of
>>0-1 limitation into the traditional resouce limitation feat
Hi Pavel,
The /proc// approach doesn't have these demerits, and it
has an advantage that users can change the bitmask of any process
at anytime.
>>>
>>>Well... not sure if it is advantage.
>>
>>For example, consider the following case:
>> a process forks many children and system admi
Hi,
>>>(run echo 1 > coremask, echo 0 > coremask in a loop while dumping
>>>core. Do you have enough locking to make it work as expected?)
>>
>>Currently, any lock isn't acquired. But I think the kernel only
>>have to preserve the coremask setting in a local variable at the
>>begining of core dum
Hi,
>(run echo 1 > coremask, echo 0 > coremask in a loop while dumping
>core. Do you have enough locking to make it work as expected?)
Currently, any lock isn't acquired. But I think the kernel only
have to preserve the coremask setting in a local variable at the
begining
Hi,
Thank you for your reply.
David Howells wrote:
>>I think that locking makes codes complex and generates overhead.
>>So I wouldn't like to use lock as far as possible. I think passing
>>the flag as an extra argument is the simplest implementation to
>>avoid the core file corruption.
>
> Act
Hi David and Robin,
Thank you for your reply.
Robin Holt wrote:
> On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
>
>>Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
>>
>>>Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
>
Hi,
Markus Gutschke wrote:
> Kawai, Hidehiro wrote:
>
>> This patch series is version 3 of the core dump masking feature,
>> which provides a per-process flag not to dump anonymous shared
>> memory segments.
>
> I just wanted to remind you that you need to be car
Hi,
I'm sorry that I couldn't reply you sooner.
Pavel Machek wrote:
>>Okay, I'll adopt your idea in the next version.
>>I'm going to provide the proc entry as follows:
>>
>> (1) /proc//core_flags/flags
>> (2) /proc//core_flags/omit_anon_shared
>>
>>(1) is the same as current core_flags. It is f
Hi,
This patch series is version 3 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
In this version, /proc//coredump_omit_anonymous_shared file
is provided as an interface instead of the previous
/proc//core_flags. If you have writt
This patch adds an interface to set/reset a flag which determines
anonymous shared memory segments should be dumped or not when a core
file is generated.
/proc//coredump_omit_anonymous_shared file is provided to access
the flag. You can change the flag status for a particular process by
writing to
This patch enables to omit anonymous shared memory from an ELF
formatted core file when it is generated.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
Index: linux-2.6.20-mm1/fs/binfmt_elf.c
==
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai <[E
This patch adds the documentation for
/proc//coredump_omit_anonymous_shared.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
Documentation/filesystems/proc.txt | 38 +++
1 files changed, 38 insertions(+)
Index: linux-2.6.20-mm1/Documentation/filesystems/proc.txt
=
Hi,
Thank you for your comments.
David Howells wrote:
>> static int elf_fdpic_dump_segments(struct file *file, struct mm_struct *mm,
>>-size_t *size, unsigned long *limit)
>>+size_t *size, unsigned long *limit,
>>+
Hi,
David Howells wrote:
> Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
>
>>To avoid the above situation we can limit the core file size by
>>setrlimit(2) or ulimit(1). But this method can lose important data
>>such as stack because core dumping is terminated h
Hi,
This patch series is version 2 of the core dump masking feature,
which enables you to specify the memory segment types you don't
want to dump into a core file.
In this version, the setting for which memory segment types are
dumped is stored as a bit field and placed next to `dumpable'
bit fi
This patch adds an interface to specify which memory segment types
should be dumped or not.
/proc//core_flags file is provided as the interface.
You can change the setting value (which memory segment types are
dumped or not) for a particular process by writing to or reading
from the file.
The set
This patch enables to omit anonymous shared memory from a core file
when it is generated.
If you don't want to dump shared memory segments of process,
set the bit 0 of the /proc//core_flags to 1.
$ echo 1 > /proc//core_flags
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are chan
This patch adds kernel.core_flags_enable sysctl parameter, which allows
root user to disable the /proc//core_flags feature globally.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c |3 ++-
fs/binfmt_elf_fdpic.c |3 ++-
fs/exec.c |1 +
incl
This patch adds the documentation for the following parameters:
/proc//core_flags
/proc/sys/kernel/core_flags_enable
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
Documentation/filesystems/proc.txt | 42 +++
Documentation/sysctl/kernel.txt| 11 +++
Hi Robin,
Robin Holt wrote:
> Can you make this a little more transparent? Having a magic bitmask does
> not seem like the best way to do stuff. Could you maybe make a core_flags
> directory with a seperate file for each flag. It could still map to a
> single field in the mm, but be broken out
Hi Pavel and Andrew,
Pavel Machek wrote:
>>This patch adds the documentation for the following parameters:
>> /proc//core_flags
>> /proc/sys/kernel/core_flags_enable
>
> Sysctl seems really strange to me. Either the feature is safe to use,
> or it is not. Users can already ulimit -c 0, and we d
Hi,
Robin Holt wrote:
>>>Can you make this a little more transparent? Having a magic bitmask does
>>>not seem like the best way to do stuff. Could you maybe make a core_flags
>>>directory with a seperate file for each flag. It could still map to a
>>>single field in the mm, but be broken out fo
Hi,
This patch provides a feature which enables you to specify the memory
segment types you don't want to dump into a core file. You can specify
them per process via /proc//coremask file. This file represents
the bitmask of memory segment types which are not written out when the
process is dumped
Hello Andrew,
Thank you for your reply and advice.
I'll send the revised patchset after I fix what you pointed out.
Andrew Morton wrote:
> Regarding the implementation: if we add
>
> unsigned char coredump_omit_anon_memory:1;
>
> into the mm_struct right next to `dumpable' then we avoid
Hi, Pavel
Pavel Machek wrote:
> > When a new process is created, the process inherits the coremask
> > setting from its parent. It is useful to set the coremask before
> > the program runs. For example:
> >
> > $ echo 1 > /proc/self/coremask
> > $ ./some_program
>
> User can already ulimit -
Hi,
$ echo 1 > /proc/self/coremask
$ ./some_program
>>>
>>>User can already ulimit -c 0 on himself, perhaps we want to use same
>>>interface here? ulimit -cmask=(bitmask)?
>>
>>Are you saying that 1) it is good to change ulimit (shell programs)
>>so that shell programs will read/write
Hi Randy,
Randy Dunlap wrote:
> Looks good. Just one typo below.
>
>
> --
>
>> Preface
>>@@ -2135,4 +2136,41 @@ those 64-bit counters, process A could s
>> More information about this can be found within the taskstats
Hi,
This patch series is version 5 of the core dump masking feature,
which controls which VMAs should be dumped based on their
memory types and per-process flags.
I adopted most of Andrew's suggestion at the previous version.
He also suggested using system call instead of /proc//
interface, I dec
This patch removes an unused argument from elf_fdpic_dump_segments().
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
fs/binfmt_elf_fdpic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.22-rc2-mm1/fs/binfmt_elf_fdpic.c
==
This patch enables core dump filtering for ELF-FDPIC-formatted
core file.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
fs/binfmt_elf_fdpic.c | 52 ++--
1 files changed, 35 insertions(+), 17 deletions(-)
Index: linux-2.6.22-rc2-mm1/fs/binfmt_elf_fdpi
This patch adds the documentation for /proc//coredump_filter.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
Documentation/filesystems/proc.txt | 38 +++
1 files changed, 38 insertions(+)
Index: linux-2.6.22-rc2-mm1/Documentation/filesystems/proc.txt
This patch changes mm_struct.dumpable to a pair of bit flags.
set_dumpable() converts three-value dumpable to two flags and
stores it into lower two bits of mm_struct.flags instead of
mm_struct.dumpable. get_dumpable() behaves in the opposite way.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]
This patch limits a value of suid_dumpable sysctl to the range of 0 to 2.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
kernel/sysctl.c |6 +-
1 files changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.22-rc2-mm1/kernel/sysctl.c
=
This patch adds an interface to set/reset flags which determines
each memory segment should be dumped or not when a core file is
generated.
/proc//coredump_filter file is provided to access the flags.
You can change the flag status for a particular process by
writing to or reading from the file.
This patch enables core dump filtering for ELF-formatted core file.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c | 30 +-
1 files changed, 21 insertions(+), 9 deletions(-)
Index: linux-2.6.22-rc2-mm1/fs/binfmt_elf.c
=
Hi Pavel,
I'm sorry for my late reply.
Pavel Machek wrote:
> Hi!
>
>>+If you don't want to dump all shared memory segments attached to pid 1234,
>>+write 0 to the process's proc file.
>>+
>>+ $ echo 1 > /proc/1234/coredump_omit_anonymous_shared
>
> Write 0?
Thank you for pointing out.
It see
, 02 Mar 2007 13:41:30 +0900
> "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote:
>
>
>>This patch series is version 4 of the core dump masking feature,
>>which provides a per-process flag not to dump anonymous shared
>>memory segments.
>
>
> First
Hi Pavel,
Thank you for your reply.
I'm sorry for my late reply.
I have discussed with my colleagues why you say "ugly" against my
procfs interface, then I noticed I may have misunderstood what you said.
Is the reason for saying "ugly" two interfaces, i.e. preexisting ulimit
(get/setrlimit) and m
Hi,
This patch series is version 4 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
In the previous version, the flag value was passed around the core
dump functions as an argument to use the same setting while dumping.
In this vers
This patch adds an interface to set/reset a flag which determines
anonymous shared memory segments should be dumped or not when a core
file is generated.
/proc//coredump_omit_anonymous_shared file is provided to access
the flag. You can change the flag status for a particular process by
writing to
This patch enables to omit anonymous shared memory from an ELF
formatted core file when it is generated.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
Index: linux-2.6.20-mm2/fs/binfmt_elf.c
===
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai <[E
This patch adds the documentation for
/proc//coredump_omit_anonymous_shared.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
Documentation/filesystems/proc.txt | 38 +++
1 files changed, 38 insertions(+)
Index: linux-2.6.20-mm2/Documentation/filesystems/proc.txt
=
Hi,
Thank you for your kind comments.
I'm sorry for my late reply.
Andrew Morton wrote:
> On Fri, 02 Mar 2007 13:41:30 +0900
> "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote:
>
>>This patch series is version 4 of the core dump masking feature,
>>whi
Hi,
Andrew Morton wrote:
> On Thu, 29 Mar 2007 20:16:59 +0100
> David Howells <[EMAIL PROTECTED]> wrote:
>
>>Pavel Machek <[EMAIL PROTECTED]> wrote:
>>
Userland core dumper is useful because it is relatively easy to be
customized, but its reliability highly depends on the application
>>>
Hi Xunlei,
> From: Xunlei Pang [mailto:xp...@redhat.com]
> Sent: Tuesday, September 20, 2016 4:40 PM
> On 2016/08/15/ at 19:22, Hidehiro Kawai wrote:
> > Hi Dave,
> >
> > Thank you for the review.
> >
> >> From: Dave Young [mailto:dyo...@redhat.com]
> >> Sent: Friday, August 12, 2016 12:17 PM
> >>
Here is the revised commit description reflecting Dave's
comment. Cc list was copied from -mm version.
From: Hidehiro Kawai
Subject: x86/panic: replace smp_send_stop() with kdump friendly version in
panic path
This patch fixes a problem reported by Daniel Walker
(https://lkml.org/lkml/2015/6/2
Dave Young suggested to me to explain the problem in more detail,
so here is the revised commit description. The patch is now in -mm,
so I copied Cc list from -mm version. Also I added Corey Minyard's
Tested-by and Reviewed-by.
From: Hidehiro Kawai
Subject: mips/panic: replace smp_send_stop() w
Hello Peter,
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of 河合英宏 / KAWAI，
>
> Hi,
>
> > From: Peter Zijlstra [mailto:pet...@infradead.org]
> >
> > On Sat, Aug 22, 2015 at 02:35:24AM +, 河合英宏 / KAWAI，HI
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> On Mon, Aug 31, 2015 at 08:53:11AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > I understand your question. I don't intend to permit the recursive
> > > call of crash_kexec() as for 'old_cpu != this_cpu' ch
Hello, Boris
Sorry for the late reply.
> On Mon, Oct 05, 2015 at 09:21:02AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > So, the problem for you is that "noextnmi" option is visible and effective
> > in the first kernel, isn't it?
>
> No, such an option shouldn&#
> On Fri, 25 Sep 2015, Hidehiro Kawai wrote:
>
> > This patch introduces new boot option "noextnmi" which disables
> > external NMI. This option is useful for the dump capture kernel
> > so that an HA application or administrator wouldn't mistakenly
> > shoot down the kernel by NMI.
> >
> > Curre
> * Thomas Gleixner wrote:
>
> > Borislav,
> >
> > On Mon, 5 Oct 2015, Borislav Petkov wrote:
> > > On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > That's different from my point of view. I'm not going to pas
> > By the way, I have a pending patch which expands this option like
> > this:
> >
> > apic_extnmi={ bsp | all | none }
> >
> > If apic_extnmi=all is specified, external NMIs are broadcast to
> > all CPUs. This raises the successful rate of kernel panic in the case
> > where an external NMI t
Hi,
> I just have a look at this thread. I am wondering why we don't use
> existing is_kdump_kernel() directly to disable external NMI if it's
> in kdump kernel. Then no need to introduce another boot option "noextnmi"
> which is used only for kdump kernel.
As I stated in another mail, there is a
> On Thu, Oct 01, 2015 at 02:33:18AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote:
> > > > This patch introduces new boot option "noextnmi" which disables
> > > > external NMI. This option is
> On Thu, Oct 01, 2015 at 07:01:50AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > I suppose that a sever which uses this feature will equip a BMC
> > and BMC mandatorily supports hard reset command for the server.
> > If the HA clustering software detects no response from
> On Thu, Oct 01, 2015 at 10:24:19AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > But how do we check if the starting kernel is a dump capture kernel?
>
> How does that first kernel pass info to the capture kernel?
As I described in the previous mail, You just have to ad
> On Fri, Oct 02, 2015 at 12:58:02AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > On Thu, Oct 01, 2015 at 10:24:19AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > But how do we check if the starting kernel is a dump capture kernel?
> > >
> > > How does that fi
> On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > That's different from my point of view. I'm not going to pass
> > some data from the first kernel to the second kernel. I'm just going to
> > provide a configurable option for the se
Hello,
Thanks for the reply.
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
[...]
> A specific hook for a very specific purpose when there is no other way
> we can consider.
So, is kmsg_dump like feature admissible?
> If you don't have something that generalises well into a general pu
Hi,
> From: Michal Hocko [mailto:mho...@kernel.org]
> On Fri 31-07-15 11:23:00, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > > > There is a timeout of 1000ms in nmi_shootdown_cpus(), so I don't know
> > > > why
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
>
> On 08/23/2015 08:52 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
> >> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
> >>
> >> On 08/17/2015 09:54 PM, 河合英宏 / KAWA
Hi,
> From: Peter Zijlstra [mailto:pet...@infradead.org]
>
> On Sat, Aug 22, 2015 at 02:35:24AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Peter Zijlstra [mailto:pet...@infradead.org]
> > >
> > > On Thu, Aug 06, 2015 at 02:45:43PM +0900, Hidehiro Ka
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
>
> On 08/24/2015 10:53 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
> >> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
> >>
> >> On 08/23/2015 08:52 PM, 河合英宏 / KAWA
Hi,
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> (2015/07/27 23:34), Michal Hocko wrote:
> > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
[...]
> > The check could be also relaxed a bit and nmi_panic would
> > return onl
> From: Michal Hocko [mailto:mho...@kernel.org]
> On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi,
> >
> > > From: linux-kernel-ow...@vger.kernel.org
> > > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> >
Hi,
> From: Michal Hocko [mailto:mho...@kernel.org]
>
> On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > > On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > Hi,
> > > >
Hi Michal,
> From: 河合英宏 / KAWAI，HIDEHIRO [mailto:hidehiro.kawai...@hitachi.com]
> > When I was testing my
> > previous approach (on 3.0 based kernel) I had basically the same thing
> > (one NMI to process panic) and others to return. This led to a strange
> > b
Hi,
> -Original Message-
> From: Michal Hocko [mailto:mho...@kernel.org]
>
> On Thu 30-07-15 07:33:15, 河合英宏 / KAWAI，HIDEHIRO wrote:
> [...]
> > Are you using SGI UV? On that platform, NMIs may be delivered to
> > all cpus because LVT1 of all cpus are not mask
> From: Michal Hocko [mailto:mho...@kernel.org]
>
> On Thu 30-07-15 01:45:35, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi,
> >
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > >
> > > On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEH
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> >> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> > [...]
> >> A specific hook for a very specific purpose when there is no other way
> >> we can consider.
> >
> > So, is kmsg_dump like feature admissible?
> >
> >> If you don't ha
Hello Corey,
> -Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
> Sent: Wednesday, August 12, 2015 1:13 PM
> To: 河合英宏 / KAWAI，HIDEHIRO
> Cc: openipmi-develo...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subje
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
>
> This patch will break ATN handling on the interfaces. So we can't do this.
I understand. So how about doing like this:
/* All states wait for ibf, so just do it here. */
- if (!check_ibf(kcs, status
Hello Borislav,
Sorry, I haven't replied to this mail yet.
> On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote:
...
> > +void crash_kexec(struct pt_regs *regs)
> > +{
> > + int old_cpu, this_cpu;
> > +
> > + /*
> > +* Only one CPU is allowed to execute the crash_kexec() code
> On Wed, Dec 02, 2015 at 11:57:38AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > We can do so, but I think resetting panic_cpu always would be
> > simpler and safer.
I'll state in detail.
When we call crash_kexec() without entering panic() and return from
it, panic() should
> @@ -357,7 +358,15 @@ static void default_do_nmi(struct pt_regs *regs)
> }
>
> /* Non-CPU-specific NMI: NMI sources can be processed on any CPU */
> - raw_spin_lock(&nmi_reason_lock);
> +
> + /*
> + * Another CPU may be processing panic routines with holding
> + * nm
> On Thu, Dec 03, 2015 at 02:01:38AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > On Wed, Dec 02, 2015 at 11:57:38AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > We can do so, but I think resetting panic_cpu always would be
> > > > simpler and safer.
> >
>
> On Fri, Nov 20, 2015 at 06:36:46PM +0900, Hidehiro Kawai wrote:
> > nmi_shootdown_cpus(), a subroutine of crash_kexec(), sends NMI IPI
> > to non-panic cpus to stop them while saving their register
>
>...to stop them and save their register...
Thanks for the correction.
> > inf
> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote:
> >
> > > + */
> > > + while (!raw_spin_trylock(&nmi_reason_lock))
> > > + poll_crash_ipi_and_callback(regs);
> >
> > Waaait a minute: so if we're getting NMIs broadcasted on every core but
> > we're *not* crash dumping, we
> On Fri, Nov 20, 2015 at 06:36:48PM +0900, Hidehiro Kawai wrote:
> > Currently, panic() and crash_kexec() can be called at the same time.
> > For example (x86 case):
> >
> > CPU 0:
> > oops_end()
> > crash_kexec()
> > mutex_trylock() // acquired
> > nmi_shootdown_cpus() // stop
> On Wed, Nov 25, 2015 at 05:51:59AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > `Infinite loop in NMI context' can happen:
> > > >
> > > > a. when a cpu panics on NMI while another cpu is processing panic
> > > > b. when a cpu received a
> On Wed, Nov 25, 2015 at 09:46:37AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
...
> > I prefer this, but we might want to add some more prefix or suffix.
> > For example, "conditionally_run_crash_nmi_callback".
>
> That's unnecessary IMO. If you need to expre
> On Fri, Nov 20, 2015 at 06:36:50PM +0900, Hidehiro Kawai wrote:
> > This patch introduces new boot option, apic_extnmi:
> >
> > apic_extnmi={ bsp | all | none}
> >
> > The default value is "bsp" and this is the current behavior; only
> > BSP receives external NMI. "all" allows external NMIs to
Hi Steven,
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> On Tue, Nov 24, 2015 at 11:48:53AM +0100, Borislav Petkov wrote:
> > > + */
> > > + while (!raw_spin_trylock(&nmi_reason_lock))
> > > + poll_crash_ipi_and_callback(regs);
> >
> > Waaait a minute: so if we're getting NMIs bro
Hi Guenter,
Thanks for the review.
> On 02/29/2016 05:50 PM, Hidehiro Kawai wrote:
> > commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers even
> > if looping in NMI context") introduced nmi_panic() which prevents
> > concurrent/recursive execution of panic(). It also saves registers
Hi Corey,
Thanks for the review.
> Sure, this is a good idea.
>
> Acked-by: Corey Minyard
>
> Note that nmi_panic() came in commit 1717f2096b5 (panic, x86: Fix
> re-entrance problem due to panic on NMI) and then the regs field
> was added in the commit you reference.
Yes. So, I'll change the
Hi,
> On Fri, Nov 20, 2015 at 06:36:44PM +0900, Hidehiro Kawai wrote:
> > If panic on NMI happens just after panic() on the same CPU, panic()
> > is recursively called. As the result, it stalls after failing to
> > acquire panic_lock.
> >
> > To avoid this problem, don't call panic() in NMI conte
> On Fri, Sep 25, 2015 at 12:13:55PM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the
> > previoius discussion, but it still exists. So, I didn't change
> > anything about panic_on_unrecovered_nmi.
> >
> On Fri, Sep 25, 2015 at 08:28:07PM +0900, Hidehiro Kawai wrote:
> > --- a/arch/x86/kernel/reboot.c
> > +++ b/arch/x86/kernel/reboot.c
> > @@ -718,6 +718,7 @@ void machine_crash_shutdown(struct pt_regs *regs)
> > static nmi_shootdown_cb shootdown_callback;
> >
> > static atomic_t waiting_for_cra
> On Mon, Sep 28, 2015 at 07:08:19AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > >> kernel/kexec_core.c:899:3: note: in expansion of macro 'atomic_xchg'
> > > atomic_xchg(&panic_cpu, -1);
> > > ^
> >
> > I changed to use atom
> On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote:
> > This patch introduces new boot option "noextnmi" which disables
> > external NMI. This option is useful for the dump capture kernel
> > so that an HA application or administrator wouldn't mistakenly
> > shoot down the kernel by
Hi Dave,
Thanks for your reply.
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Wednesday, July 13, 2016 11:04 AM
>
> On 07/12/16 at 02:49am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi Dave,
> >
> > Thanks for the comments.
> >
> > >
Hi,
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Monday, July 18, 2016 6:02 PM
> On 07/15/16 at 11:50am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi Dave,
> >
> > Thanks for your reply.
> >
> > > From: 'Dave Young' [mailto:dy
> From: 'Dave Young' [mailto:dyo...@redhat.com]
> Sent: Tuesday, July 19, 2016 3:52 PM
> Hi,
> On 07/19/16 at 05:51am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi,
> >
> > > From: 'Dave Young' [mailto:dyo...@redhat.com]
> > > Sent: Monday, Ju
Hi Dave,
Thanks for the comments.
> From: Dave Young [mailto:dyo...@redhat.com]
> Sent: Monday, July 11, 2016 5:35 PM
>
> On 07/05/16 at 08:33pm, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If crash_ke
Hi Xunlei,
Thanks for the review.
> From: Xunlei Pang [mailto:xp...@redhat.com]
> Sent: Tuesday, July 12, 2016 12:12 PM
> On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
> > This patch fixes one of the problems reported by Daniel Walker
> > (https://lkml.org/lkml/2015/6/24/44).
> >
> > If crash_kex
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Xunlei Pang
> Sent: Tuesday, July 12, 2016 3:57 PM
> On 2016/07/12 at 11:56, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi Xunlei,
> >
> > Thanks for the review.
> &g
Hi,
> From: Borislav Petkov [mailto:b...@alien8.de]
> On Wed, Mar 02, 2016 at 02:18:24PM +0100, Michal Hocko wrote:
> > On Wed 02-03-16 19:36:26, Hidehiro Kawai wrote:
> > [...]
> > > +void nmi_panic(struct pt_regs *regs, const char *fmt, ...)
> >
> > Do we really need vargs? All the current users
1 - 100 of 116 matches
Mail list logo
