CONFIG_LIBCRC32C is not set
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
-
To unsubscribe from this list: send the
mily 1
NET: Registered protocol family 17
Using IPI Shortcut mode
VFS: Cannot open root device "" or unknown-block(8,18)
Please append a correct "root=" boot option; here are the available
partitions:
08001000944 sda driver: sd
Kernel panic - not syncing: VFS: Unable to mou
fixup fixups_table[] = {
{ PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5530_LEGACY, cs5530a_warm_reset },
{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA, cs5536_warm_reset },
+{ PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_SC1100_BRIDGE, cs5530a_warm_reset },
};
/*
--
Denys Fedoryshchenko
Technical Ma
df <0f>
0b eb fe 85 d2 89 73 2c 74 0a 8b 42 04 89 06 89 72 04 eb 06
[ 80.209000] EIP: [] jffs2_link_node_ref+0xbe/0x121 [jffs2]
SS:ESP 0068:d6949bdc
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
fferent CONFIG_HZ
> - 8139TOO_PIO = y
>
>
> > IRQ-problems with the Un-Interruptible-Power-Supply
>
> I wouldn't be surprised...
>
> Cheers,
> Jarek P.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the bo
re is SPARSEMEM
enabled, it doesn't make any noticeable difference)
Please CC me on reply, i am not in list.
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
18:21:54 all 26.130.00 16.08 18.590.007.040.00
32.16 8657.58
18:21:55 all 22.890.00 16.92 18.910.506.470.00
34.33 7957.43
18:21:56 all 28.140.00 21.61 17.590.506.030.00
26.13 8531.00
--
Denys Fedorys
00K easily)
What can cause delays ~350-360ms for userspace applications?
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
sk of 0x00 (No unit mask) count 10
> > samples %symbol name
> > 138991 14.0627 acpi_pm_read
> > 52401 5.3018 tcp_v4_rcv
> > 48466 4.9037 nf_iterate
> > 38043 3.8491 __slab_alloc
> > 34155 3.4557 ip_send_reply
> > 20963 2.1
ble i will have news after 2-3 hours max.
On Sun, 30 Sep 2007 14:25:37 +1000, Nick Piggin wrote
> Hi Denys, thanks for reporting (btw. please reply-to-all when
> replying on lkml).
>
> You say that SLAB is better than SLUB on an otherwise identical
> kernel, but I didn't see i
quot;.
On Sun, 30 Sep 2007 14:25:37 +1000, Nick Piggin wrote
> Hi Denys, thanks for reporting (btw. please reply-to-all when
> replying on lkml).
>
> You say that SLAB is better than SLUB on an otherwise identical
> kernel, but I didn't see if you quantified the actual numbers?
after this
[f85958151900f9d30fa5ff941b0ce71eaa45a7de] [NET]: random functions can use
nsec resolution instead of usec
On Sun, 30 Sep 2007 14:25:37 +1000, Nick Piggin wrote
> Hi Denys, thanks for reporting (btw. please reply-to-all when
> replying on lkml).
>
> You say that SLAB is better tha
ve 600-700 req/s. Maybe
there is some additional overhead in this calculations, or improper irq
locking? I am not guru in such stuff.
I guess who have similar workload can check mpstat 1, and see if there is
spikes in soft% or not.
>Denys a :
>> Hi
>>
>> I got
>>
&
of all of this on-stack nonsense. And in several
> cases (if the caller only needs the tv_sec value, for example)
> computations can be elided entirely.
>
> It would be constructive to experiment and see if this is in fact
> part of the problem.
--
Denys Fedoryshchenko
Technic
Already i did, and it didn't show real failure point.
On 01 Oct 2007 12:01:24 +0200, Andi Kleen wrote
> "Denys" <[EMAIL PROTECTED]> writes:
>
> > by mistake i will miss a point (it can detect bug easily, IF softirq in
> > mpstat 1 will jump up to 30+%. O
, 1 Oct 2007 13:14:41 +0200, Andi Kleen wrote
> On Mon, Oct 01, 2007 at 01:30:52PM +0300, Denys wrote:
> >
> > Already i did, and it didn't show real failure point.
>
> There was no difference between the profile of the working kernel
> and the high load kernel? Per
That 2.6.21 works fine and 2.6.22 MUCH worse on multiple servers with similar
workload.
Plus all userspace becoming extremely unstable, and definitely ping 127.0.0.1
must not reach 300ms.
On Mon, 1 Oct 2007 13:57:21 +0200, Andi Kleen wrote
> On Mon, Oct 01, 2007 at 02:52:03PM +0300, Denys wr
Not able to compile kernel with patch
drivers/built-in.o: In function `secure_tcp_sequence_number':
(.text+0x3ad02): undefined reference to `__divdi3'
make: *** [.tmp_vmlinux1] Error 1
On Mon, 01 Oct 2007 10:20:07 +0200, Eric Dumazet wrote
> Denys a :
> > Well, i can play
> >>
> >> That cannot be without some cost.
> >>
> >> ktime_get_real() is definitely a candidate for inlining especially in
> >> these kinds of cases where we'll happily get computations in local
> >> registers instead of all of this on-stack nonsense. An
On Friday 08 February 2013 21:15, Michael Kerrisk (man-pages) wrote:
> >> >Damn. But after I wrote this email I realized that llseek() probably can't
> >> > work. Because peek_offset/f_pos/whatever has to be shared with all
> >> > processes
> >> > which have this file opened.
> >
> > Yes. but I th
0x12/0x14
[ 7575.810373] [] cpuidle_enter_state+0x10/0x39
[ 7575.810840] [] cpuidle_idle_call+0x7e/0xa4
[ 7575.811306] [] cpu_idle+0x58/0xa2
[ 7575.811770] [] start_secondary+0x188/0x18d
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
--
To unsubscribe from this list: send the
On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin wrote:
>> > I suppose I had wondered along similar lines, but in a slightly
>> > different direction: would the use of a /proc interface to get the
>> > queued signals make some sense?
>>
>> I think that /proc interface beats adding magic flags and ma
On Mon, Feb 11, 2013 at 3:53 PM, Pavel Emelyanov wrote:
> On 02/11/2013 06:46 PM, Denys Vlasenko wrote:
>> On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin wrote:
>>>>> I suppose I had wondered along similar lines, but in a slightly
>>>>> different direction
On 2013-02-21 01:21, Stephen Hemminger wrote:
On Tue, 19 Feb 2013 23:45:25 +0200
Denys Fedoryshchenko wrote:
Hi
I tried recently to write my own tool based on amazing libmnl (which
makes understanding of netlink - easy), written
by Pablo Neira Ayuso, to manage QoS in Linux and faced problem
On 02/19/2013 07:25 AM, Amnon Shiloh wrote:
> Steven Rostedt wrote:
>
>> If only you, or a few people are using it (ie. distros don't see a
>> need), then it will be up to you to make the changes.
>
> I believe that this functionality is of a general nature and is needed
> by many, not only by my
On Tue, Sep 11, 2012 at 5:59 PM, Oleg Nesterov wrote:
> What do you think about the patch below?
Looks good.
You know that I like to *remove* code :)
--
vda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
ich will happily try to
free all info->fields again. BOOM.
This is the fix.
Signed-off-by: Oleg Nesterov
Signed-off-by: Denys Vlasenko
---
fs/binfmt_elf.c | 19 ---
1 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 7
This is a preparatory patch for the introduction of NT_SIGINFO elf note.
Signed-off-by: Denys Vlasenko
---
fs/binfmt_aout.c |2 +-
fs/binfmt_elf.c | 14 +++---
fs/binfmt_elf_fdpic.c|6 +++---
fs/binfmt_flat.c |2 +-
fs/coredump.c
patch adds a new elf note, NT_SIGINFO, which contains
the remaining fields of siginfo_t.
Signed-off-by: Denys Vlasenko
---
fs/binfmt_elf.c | 52 +-
include/linux/elf.h |5
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a
On Thu, Sep 13, 2012 at 5:36 PM, Oleg Nesterov wrote:
> On 09/13, Denys Vlasenko wrote:
>>
>> This patch adds a new elf note, NT_SIGINFO, which contains
>> the remaining fields of siginfo_t.
>
> I can't really comment this patch, but...
>
>> +struct core
12380.068978] Kernel panic - not syncing: Fatal
exception in interrupt
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:/
Maybe just registers addresses or way how TCO watchdog activated changed on
this chipset?
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
2008 14:15, Denys Fedoryshchenko wrote:
> >
> > On Fri, 1 Feb 2008 12:11:41 -0500, Len Brown wrote
> > >
> > > What do you see if you build with CONFIG_HIGH_RES_TIMERS=n
> > >
> > > Does it work better if you boot with "acpi=off"?
i will be able to find whats wrong there.
On Fri, 1 Feb 2008 15:39:08 -0500, Len Brown wrote
> On Friday 01 February 2008 14:15, Denys Fedoryshchenko wrote:
> >
> > On Fri, 1 Feb 2008 12:11:41 -0500, Len Brown wrote
> > >
> > > What do you see if you build with CONFIG
de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl vmx cid cx16 xtpr lahf_lm
bogomips: 6383.76
clflush size: 64
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP
Fri, 15 Feb 2008 16:24:56 +0100, Bart Van Assche wrote
> 2008/2/15 Denys Fedoryshchenko <[EMAIL PROTECTED]>:
> > I have random crashes, at least once per week. It is very difficult to
catch
> > error message, and only recently i setup netconsole. Now i got crash, but
>
Hi Stephen,
On Fri, Sep 21, 2012 at 8:26 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/compat_binfmt_elf.c:22:53: fatal error: asm/sigframe.h: No such file or
> directory
>
> Caused by commi
On Fri, Aug 3, 2012 at 7:21 AM, George Spelvin wrote:
> The same multiply-by-inverse technique can be used to
> convert division by 1 to a 32x32->64-bit multiply.
>
> Signed-off-by: George Spelvin
> ---
> lib/vsprintf.c | 60
> +++-
> 1
On Fri, Aug 3, 2012 at 7:21 AM, George Spelvin wrote:
> Shrink the reciprocal approximations used in put_dec_full4
> based on the comments in put_dec_full9.
>
> Signed-off-by: George Spelvin
> Cc: Denys Vlasenko
> Cc: Michal Nazarewicz
> ---
> lib/vsprintf.c |5 ++
Hi,
I noticed the following:
In linux-mmotm and parisc-2.6.git trees,
arch/parisc/include/asm/compat_signal.h file is just:
/* Use generic */
#include
which isn't correct since asm-generic/compat_signal.h doesn't exist.
Nobody noticed this because arch/parisc/include/asm/compat_signal.h
its
st those at the moment.
Denys Vlasenko (4):
coredump: pass siginfo_t* to do_coredump() and below, not merely
signr
compat: move compat_siginfo_t definition to asm/compat.h
coredump: add a new elf note with siginfo of the signal
coredump: extend core dump note section to contai
_signo/.
Signed-off-by: Denys Vlasenko
Reviewed-by: Oleg Nesterov
---
fs/binfmt_aout.c |2 +-
fs/binfmt_elf.c | 14 +++---
fs/binfmt_elf_fdpic.c|6 +++---
fs/binfmt_flat.c |2 +-
fs/coredump.c| 10 +-
include/linux/binfmts.h |
replaced by
__compat_uid[32]_t. compat_uptr_t had to be moved up before compat_siginfo_t
in asm/compat.h on a several architectures (tile already had it moved up).
compat_sigval_t had to be relocated from linux/compat.h to asm/compat.h.
Signed-off-by: Denys Vlasenko
---
arch/arm64/include/asm/compat.h
This note has the following format:
long count -- how many files are mapped
long page_size -- units for file_ofs
array of [COUNT] elements of
long start
long end
long file_ofs
followed by COUNT filenames in ASCII: "FILE1" NUL "FILE2" NUL...
Signed-off-by: Den
On Mon, Sep 24, 2012 at 2:35 PM, George Spelvin wrote:
>> Here is the comparison of the x86-32 assembly
>> of the fragment which does "x / 1" thing,
>> before and after the patch:
>
>> -01 c6 add%eax,%esi
>> -b8 59 17 b7 d1 mov$0xd1b71759,%eax
>> -f7 e6
On Tue, Sep 25, 2012 at 1:44 PM, George Spelvin wrote:
> Thanks to Denys Vlasenko for sending me his benchmarking code.
>
> I went and hacked on it to ransomize the numbers being converted more,
> since repeatedly converting the same number underestimates the number
> of branch
Hi,
I'm trying to figure out how to extend "perf trace".
Currently, it shows syscall names and arguments, and only them.
Meaning that syscalls such as open(2) are shown as:
open(filename: 140736118412184, flags: 0, mode: 140736118403776) = 3
The problem is, of course, that user wants to see
On 09/17/2013 09:06 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 17, 2013 at 05:10:55PM +0200, Denys Vlasenko escreveu:
>> I'm trying to figure out how to extend "perf trace".
>
>> Currently, it shows syscall names and arguments, and only them.
>> Me
On Wed, Sep 18, 2013 at 4:33 PM, Arnaldo Carvalho de Melo
wrote:
>> > Look at the tmp.perf/trace2 branch in my git repo, tglx and Ingo added a
>> > tracepoint to vfs_getname to use that.
>>
>> I know that this is the way how to fetch syscall args without stopping,
>> yes.
>>
>> The problem: ~100 m
On Thu, Sep 26, 2013 at 9:41 AM, Denys Vlasenko
wrote:
> On Wed, Sep 18, 2013 at 4:33 PM, Arnaldo Carvalho de Melo
> wrote:
>>> The problem: ~100 more tracepoints need to be added merely to get
>>> to the point where strace already is, wrt quality of syscall decoding.
&
2] [] path_openat+0x99/0x2c3
[4.361974] [] do_filp_open+0x26/0x67
[4.361977] [] ? alloc_fd+0xb7/0xc2
[4.361979] [] do_sys_open+0x5b/0xe6
[4.361980] [] sys_open+0x26/0x2c
[4.361981] [] syscall_call+0x7/0xb
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
--
To
On 2012-11-13 21:41, Dave, Tushar N wrote:
-Original Message-
From: netdev-ow...@vger.kernel.org
[mailto:netdev-ow...@vger.kernel.org]
On Behalf Of Denys Fedoryshchenko
Sent: Tuesday, November 13, 2012 5:59 AM
To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny,
Carolyn
el_rules.txt?
>
Will do. Thank you for bringing this to our attention.
Thanks for submitting the patch to stable, Greg has queued it for the
kernels he maintains. Denys, expect to see this fix in 3.6.8.
Thank you!
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
--
To unsubscr
hope not.
If this behavior existed from the start, strace
would not need a large, ugly chunk of code it currently has
to handle this quirk.
CCing Jan to hear his comments from gdb side.
Signed-off-by: Denys Vlasenko
CC: Jan Kratochvil
CC: Dmitry V. Levin
CC: Oleg Nesterov
---
kernel/ptrace.c
On 06/19/2013 06:32 PM, Oleg Nesterov wrote:
> On 06/19, Denys Vlasenko wrote:
>>
>> This is a user-visible behavior change.
>> Do we really have to introduce a separate
>> PTRACE_NOT_STUPID_DETACH? I hope not.
>
> Oh, I think yes.
>
>> @@ -1062,7 +1060,
RTSYS.
Signed-off-by: Denys Vlasenko
CC: Oleg Nesterov
---
fs/eventpoll.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 0cff4434..08f8076 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1598,7 +1598,7 @@ fetch_e
t;sigset_t ksigmask" member, I had to add
to linux/thread_info.h, which threw some
build errors about undefined smp barriers and such.
Removing include from linux/time.h
solved it.
Run-tested.
Signed-off-by: Denys Vlasenko
CC: Oleg Nesterov
---
fs/eventpoll.c
On Tuesday 25 June 2013 22:06, Oleg Nesterov wrote:
> > > In order to define a "sigset_t ksigmask" member,
> >
> > You do not need it. But the reason is not clear until the cleanup.
>
> I take this back, this is not as simple as I thought... and perhaps even
> not right.
>
> However. Probably you
Grepping for numeric constants is inconvenient.
No code changes.
Signed-off-by: Denys Vlasenko
---
include/linux/wait.h | 4
kernel/exit.c| 14 +++---
kernel/signal.c | 6 +++---
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/include/linux/wait.h b
SI_USER means that this signal is sent by another process
via kill(2) et al.
Other cases when kernel sends signals, such as ^C,
SIGHUP on tty close, SIGXCPU when time limit is up,
SIGALRM from alarm(2) etc, we set si_code to SI_KERNEL.
SIGPIPE seems to be inconsistent here.
Signed-off-by: Denys
On 07/03/2013 09:54 PM, Oleg Nesterov wrote:
> On 07/03, Denys Vlasenko wrote:
>>
>> @@ -514,7 +514,7 @@ pipe_write(struct kiocb *iocb, const struct iovec *_iov,
>> __pipe_lock(pipe);
>>
>> if (!pipe->readers) {
>> -send_sig(SIGP
%rbx,%rdi
e8 32 8c ff ff callq 490
48 8d 83 78 01 00 00lea0x178(%rbx),%rax
83 8b 70 01 00 00 01orl$0x1,0x170(%rbx)
83 8b 74 01 00 00 01orl$0x1,0x174(%rbx)
49 39 c4cmp%rax,%r12
0f 84 88 fa ff ff je 7304
Signed-off-by: Denys Vlasenko
CC
On Tue, Jul 2, 2013 at 10:01 PM, Oleg Nesterov wrote:
> On 07/01, Denys Vlasenko wrote:
>>
>> Grepping for numeric constants is inconvenient.
>
> Personally I agree very much, and I like the intent.
>
>> +#define WTERMSIG_MASK 0x7f
>> +#define WTERMSI
On 07/04/2013 11:13 AM, Gleb Natapov wrote:
> On Thu, Jul 04, 2013 at 10:58:29AM +0200, Denys Vlasenko wrote:
>> The check sits in switch() statement which itself can check
>> for opcode 0x90 far more efficiently.
>>
>> On assembler level, this change simply eliminates t
We do not need to check for reg == RAX for opcodes 0x91...0x97.
Signed-off-by: Denys Vlasenko
CC: Paolo Bonzini
CC: Avi Kivity
Signed-off-by: Denys Vlasenko
CC: Paolo Bonzini
CC: Avi Kivity
---
arch/x86/kvm/emulate.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
On Monday 17 June 2013 12:36, James Hogan wrote:
> On 14/06/13 17:03, James Hogan wrote:
> > MIPS has 128 signals, the highest of which has the number 128 (they
> > start from 1). The following command causes get_signal_to_deliver() to
> > pass this signal number straight through to do_group_exit()
On Wednesday 29 May 2013 23:56, James Hogan wrote:
> On 29 May 2013 18:36, Oleg Nesterov wrote:
> > On 05/29, David Daney wrote:
> >>
> >> On 05/29/2013 10:01 AM, James Hogan wrote:
> >>> MIPS has 128 signals, the highest of which has the number 128. The
> >>
> >> I wonder if we should change the
On Wednesday 26 June 2013 18:59, Ralf Baechle wrote:
> On Wed, Jun 26, 2013 at 06:14:52PM +0200, Oleg Nesterov wrote:
>
> > Or simply remove the BUG_ON(), this can equally confuse wait(status).
> > 128 & 0x7f == 0.
> >
> > Still I think it would be better to change _NSIG on mips.
>
> If it was t
On 03/19/2013 09:19 PM, Oleg Nesterov wrote:
>> The above is regarding the situation which I'm running my corepipe_app ,
>> i.e. my system doesn't have a disk to save a core file for parsing.
>
> Can't you process the data inplace? You do not need to save it to disk.
Daniel said:
>> I'm trying t
On 03/27/2013 04:26 AM, Daniel Walker wrote:
> On Mon, Mar 25, 2013 at 10:48:07AM +0100, Denys Vlasenko wrote:
>> On 03/19/2013 09:19 PM, Oleg Nesterov wrote:
>>>> The above is regarding the situation which I'm running my corepipe_app ,
>>>> i.e. my system d
This changeset is on top of "add support for %d=__get_dumpable() in core name"
patch currently in -mm.
Changes since previous version:
* save data in the form of siginfo_t structure instead of inventing
yet another representation of this data
* use copy_siginfo_to_user to copy
_signo/.
Signed-off-by: Denys Vlasenko
Reviewed-by: Oleg Nesterov
---
fs/binfmt_aout.c |2 +-
fs/binfmt_elf.c | 14 +++---
fs/binfmt_elf_fdpic.c|6 +++---
fs/binfmt_flat.c |2 +-
fs/coredump.c| 10 +-
include/linux/binfmts.h |
patch adds a new elf note, NT_SIGINFO, which contains
the complete siginfo_t of the signal which killed the process.
Signed-off-by: Denys Vlasenko
---
fs/binfmt_elf.c | 22 --
include/linux/elf.h |5 +
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a
available, "" string is encoded.
Changes since previous version: rediffed on top of NT_SIGINFO patches.
Signed-off-by: Denys Vlasenko
---
fs/binfmt_elf.c | 85 --
include/linux/elf.h |1 +
2 files changed, 82 insertions(+), 4
On Tue, Sep 18, 2012 at 6:41 PM, Roland McGrath wrote:
>> But, somehow I forgot about compat tasks when we discussed this before.
>> Perhaps the code above should do
>>
>> if (is_compat_task())
>> copy_siginfo_to_user32(...);
>> else
>> copy_siginfo_to_user(
This changeset is on top of "add support for %d=__get_dumpable() in core name"
patch currently in -mm.
Changes since previous version:
* fixed compat coredump generation
Denys Vlasenko (2):
coredump: pass siginfo_t* to do_coredump() and below, not merely
signr
coredump: add
_signo/.
Signed-off-by: Denys Vlasenko
Reviewed-by: Oleg Nesterov
---
fs/binfmt_aout.c |2 +-
fs/binfmt_elf.c | 14 +++---
fs/binfmt_elf_fdpic.c|6 +++---
fs/binfmt_flat.c |2 +-
fs/coredump.c| 10 +-
include/linux/binfmts.h |
patch adds a new elf note, NT_SIGINFO, which contains
the complete siginfo_t of the signal which killed the process.
Signed-off-by: Denys Vlasenko
---
fs/binfmt_elf.c| 26 --
fs/compat_binfmt_elf.c |7 +++
include/linux/elf.h|5 +
3 files changed
On Tue, Sep 18, 2012 at 6:58 PM, Roland McGrath wrote:
> The code needs to be macroized a bit so that compat_binfmt_elf.c will
> produce a version that encodes 32-bit values correctly so as to be
> compatible with the output of a native 32-bit kernel.
Just did it...
> It's doubtful that rolling
version:
* reworked the way we count file-backed vmas,
* switched to memmove for filename copying instead of open-coded loop,
* fixed note generation for compat coredump.
Signed-off-by: Denys Vlasenko
---
fs/binfmt_elf.c| 108 ++--
fs/compat
Hi,
Resending the patch after a while.
Jonathan, developer of CERT Triage Tools, expressed the need
to have this information, CCing him.
But before looking at the attached patch, we need a ruling.
In the last review it was proposed to maybe generate
this information in the form of ASCII text, a-
On Wednesday 11 July 2012 17:15, Oleg Nesterov wrote:
> On 07/11, Denys Vlasenko wrote:
> >
> > I propose to save this information in core dump, as a new note
> > in note segment.
>
> Denys, I am in no position to discuss whether we need this change or not,
> format,
ous version, code is simplified
as suggested by Oleg Nesterov.
Signed-off-by: Denys Vlasenko
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 1b52956..8e60c38 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1372,6 +1372,72 @@ static void fill_auxv_note(struct memelfnote *note,
decoded by strace as a (64-bit) shmget syscall.
This patch makes it so that in syscall-entry-stop caused by
"int 80" instruction, PTRACE_GETREGSET returns 32-bit regset.
Signed-off-by: Denys Vlasenko
--- linux-3.7.7/arch/x86/include/asm/uaccess.h
+++ linux-3.7.7_regset/arch/x86/include/asm/
On 02/14/2013 04:00 PM, Oleg Nesterov wrote:
> On 02/14, Denys Vlasenko wrote:
>> This patch makes it so that in syscall-entry-stop caused by
>> "int 80" instruction, PTRACE_GETREGSET returns 32-bit regset.
>
> Not sure...
>
> First of all, this is incompatib
On 02/14/2013 09:55 PM, Cyrill Gorcunov wrote:
> On Thu, Feb 14, 2013 at 11:21:12AM -0800, H. Peter Anvin wrote:
>> On 02/14/2013 11:18 AM, Oleg Nesterov wrote:
>>> On 02/14, H. Peter Anvin wrote:
>>>>
>>>> On 02/14/2013 07:00 AM, Oleg Nesterov w
On 02/14/2013 08:21 PM, H. Peter Anvin wrote:
> On 02/14/2013 11:18 AM, Oleg Nesterov wrote:
>> On 02/14, H. Peter Anvin wrote:
>>>
>>> On 02/14/2013 07:00 AM, Oleg Nesterov wrote:
>>>> On 02/14, Denys Vlasenko wrote:
>>>>>
>>>
M] ACPI backlight interface available,
not registering our own
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
--
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.
ng recursive fault
but reboot is needed!
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
--
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
ecode output
http://www.nuclearcat.com/files/panic-07012008/dmidecode.txt
lspci output
http://www.nuclearcat.com/files/panic-07012008/lspci.txt
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl vmx cid cx16 xtpr lahf_lm
bogomips: 6383.74
clflush size : 64
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
To
esp+0x5f/0xa5
[625138.255376] ===
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-
No, i am using vanilla kernel. It is one of production machines, and as i
know screen is not using epoll.
I will try to apply on all my production machines this patch. Sorry if it is
related.
On Mon, 21 Jan 2008 23:45:40 +0100, Stefan Richter wrote
> Denys Fedoryshchenko wrote:
> &
On Monday 01 October 2007 20:04, Davide Libenzi wrote:
> > They don't even need to read in parallel, just having shared fd is enough.
> > Think about pipes, sockets and terminals. A real-world scenario:
> >
> > * a process started from shell (interactive or shell script)
> > * it sets O_NONBLOCK a
On Tuesday 02 October 2007 17:35, Greg KH wrote:
> > > > > > I suggest the following optimizations:
> > > > > >
> > > > > > Change structure to
> > > > > >
> > > > > > typedef struct _INTEL_HEX_RECORD
> > > > > > {
> > > > > > __u8 type;
> > > > > > __u8 length;
> > > > > >
On Sunday 07 October 2007 17:47, Malte Schröder wrote:
> Hello,
> I am encountering some strange data corruption when transferring
> data from one of my PCs that I use as a file-server.
>
> on the server:
> FILE=; | cut -d" " -f1 | nc -lp5000 -q0; while nc
> -lp5000 -q0 < $FILE; do : ; done
$ cat
On Saturday 06 October 2007 20:13, Jan Engelhardt wrote:
> Colored kernel message output (1/2)
>
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time,
> and changed at run time.
IMHO: useless bloat.
And yes, I've r
On Tuesday 09 October 2007 12:25, Malte Schröder wrote:
> > Does it happen over loopback?
>
> I just tried a few times and yes, it also happens on loopback, but
> much less frequently. Now I am really confused ...
Actually, that eliminates a lot of cases.
Run memtest86 overnight ("bad hardware"
is not bug, probably good to document, that it is killing powersaving
features?
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
On Monday 17 December 2007 14:47, Patrick McHardy wrote:
> Please CC netfilter-devel on netfilter patches.
>
> Denys Vlasenko wrote:
> > Hi Patrick, Harald,
> >
> > I was working on unrelated problem and noticed that ip_tables.c
> > seem to abuse inline. I prepa
1 - 100 of 1376 matches
Mail list logo