After suffering some days from a not|mis configured tmpfs,
As the OOM killer is not Posix,
Better than to kill processes would be to resize tmpfs, to use tmpfs empty
space.
I'm using kernel 2.6.20.4. If someone ask I'll send a test application.
-
To unsubscribe from this list: send the
On Wednesday 11 April 2007 16:48, Willy Tarreau wrote:
> On Wed, Apr 11, 2007 at 02:23:31AM -0300, Pedro wrote:
> > After suffering some days from a not|mis configured tmpfs,
> >
> > As the OOM killer is not Posix,
> >
> > Better than to kill processes would
On Wednesday 11 April 2007 19:39, Alan Cox wrote:
> > 2) How should an application be written to not be killed by OOM?
>
> OOM isn't an application matter. The kernel has to choose between
> allowing overcommit on the basis it might run out of memory and have to
> kill stuff, or that it won't in
On Thursday 12 April 2007 02:04, Al Boldi wrote:
> > Pedro wrote:
> > 2) How should an application be written to not be killed by OOM?
>
> Try this:
>
> # echo -17 > /proc//oom_adj
I should know that to run a fail-safe application is a superuser privilege.
S
On Thursday 12 April 2007 08:25, Theodore Tso wrote:
> likely going to be in deep trouble anyway. Even if you disable the
> OOM killer, now random malloc()'s will start returning NULL because
> your system doesn't have enough memory. Do you have intelligent error
> handling and recovery mechanism
I wrote:
> > I deduce that a fail-safe application must scanf overcommit_memory,
> > warn the user and waitpid.
Alan Cox wrote:
> If you are building a fail safe system you need to look a bit beyond out
> of memory handling settings - power supplies, failover, fault tolerance
> requirements, err
Mr. Pedro Quezada & family has donated $750,000 USD to you. Contact email below
for more details about the donated funds.
pedroq...@gmail.com
Mr Pedro Quezada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.k
\
for (_i = 0; _i < pg->index; _i++) {\
rec = &pg->records[_i];
(other variants possible)
IOW, the outer loop only iterates if the inner loop completes. If there's
a break in the inner loop, t
On 09/04/2012 05:30 PM, Pedro Alves wrote:
> On 09/04/2012 04:35 PM, Steven Rostedt wrote:
>> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
>>
>>> Looking again at:
>>>
>>> +#define hash_for_each_size(name, bits, bkt, node, obj, member)
On 09/04/2012 06:17 PM, Steven Rostedt wrote:
> On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
>
>> BTW, you can also go a step further and remove the need to close with double
>> }},
>> with something like:
>>
>> #d
On 09/04/2012 09:59 PM, Steven Rostedt wrote:
> On Tue, 2012-09-04 at 18:21 +0100, Pedro Alves wrote:
>> On 09/04/2012 06:17 PM, Steven Rostedt wrote:
>>> On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
>>>
>>>> BTW, you can also go a step fu
. It's the comma
that separates function parameters that doesn't guarantee ordering.
--
Pedro Alves
--
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/
ing itself. On the other hand, if
> the
> internal loop has actually ended, then node will be NULL, and the outer loop
> will keep running.
>
> Is there anything I've missed?
Looks right to me, from a cursory look at hlist_for_each_entry. That's exactly
what I meant
ace between PTRACE_ME/PTRACE_ATTACH and
setting PTRACE_SETOPTIONS).
(For completeness, Windows' age old equivalent,
DebugSetProcessKillOnExit, it a tracer option, not tracee option, though
that's not as flexible.)
--
Pedro Alves
--
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/
On 11/08/2012 12:44 PM, Oleg Nesterov wrote:
> On 11/08, Pedro Alves wrote:
>> If this isn't inherited by the ptrace child's children, a fork child can
>> end up detached if the tracer dies before it had a chance of setting
>> the PTRACE_O_EXITKILL on the new
On 06/19/2013 05:09 PM, Jan Kratochvil wrote:
> On Wed, 19 Jun 2013 17:15:36 +0200, Denys Vlasenko wrote:
>> CCing Jan to hear his comments from gdb side.
PTRACE_DETACH takes a signal number in the data parameter.
What happens to if the tracer passes a non-zero signal?
--
Pedro Alv
Hi,
Bellow you'll find a bug report for a possible bug involving recursive
locking.
Thanks,
Pedro
[1.] One line summary of the problem:
Possible recursive locking on "tick_periodic()" and "do_timer()" because
of "xtime_lock" in 3.7.9
[2.] Ful
2332 R 66 0.0 0:00.67 cc1plus
24501 larroy20 0 687m 657m 8044 R 64 0.7 0:22.97 cc1plus
24933 larroy20 0 211m 177m 4008 R 62 0.2 0:01.79 cc1plus
24899 larroy20 0 327m 296m 4276 R 57 0.3 0:04.25 cc1plus
This is 3.2.0-26-generic on ubuntu 12.04
Regards.
Pedro
I didn't enable cgroups explicitly, and don't have userspace tools for
that installed.
Thanks.
Pedro.
On Mon, Aug 6, 2012 at 4:25 PM, Mike Galbraith wrote:
> On Mon, 2012-08-06 at 16:04 +0200, Pedro Larroy wrote:
>> Hi
>>
>> I think we are observing unfair s
biarch)
because
of this, for "(gdb) print $_siginfo".
I wish we had a PTRACE_GETSIGINFO variant that returned the siginfo_t in
layout of the program, not the kernel's..
> Note also that compat_binfmt_elf must deliver the 32-bit version
> of siginfo_t, i.e. as copy_siginfo_
INT_RESTORE. We'd miss the poke
variant, but that looks like something that could be always be added
later.
--
Pedro Alves
--
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/
On 02/15/2013 07:43 PM, Oleg Nesterov wrote:
> On 02/15, Pedro Alves wrote:
>>
>> Not sure I'm reading the patch right, but it looks like GDB would
>> be able to use this as alternative to PTRACE_GET_SIGINFO variant
>
> No, it is different. PTRACE_GETSIGINFO re
dded later" comment instead of actually requesting it. But if
we had it, we could make e.g., gdb inspect the signal queues,
and then be able to tweak a realtime signal before it is
delivered.
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
ngle macro/symbol both the
kernel and libc (any libc that needs this) define? Something
like both the kernel and userland doing:
#ifndef __IPV6_BITS_DEFINED
#define __IPV6_BITS_DEFINED
...
define in6_addr, sockaddr_in6, ipv6_mreq, whatnot
#endif
So whichever the application includes first, wi
d have only one macro for all
structs/enums (you could split into __IPV6_IN6_ADDR_DEFINED,
__IPV6_SOCKADDR_IN6_DEFINED, etc.) but to have the kernel
and libc agree on guard macros, instead of having the kernel
do #ifdef __GLIBC__ and glibc doing #ifdef _NETINET_IN_H.
But as Carlos says, th
gt; will look as a "normal" syscall. Like vsyscall_seccomp() does.
>
> But this needs much more changes.
I'd just like to add, that if any new syscall related option is
to be added, can we please just go all the way and add
PTRACE_EVENT_SYSCALL_ENTER|PTRACE_EVENT_SYSCALL_E
y used to check data integrity, and
that's the reason of the "avalanche effect", so even single bit errors
are propagated and it's effect is very noticeable at the output.
Regards.
--
Pedro Larroy Tovar | Linux & Network consultant | pedro%larroy.com
Make debian mirrors w
s. Are these voltages related to the quality of the
power supply, or the quality of the processor? How do we know which one
to choose?
Regards,
--
Pedro Ramalhais
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
PCI: Found IRQ 11 for device :00:1f.1
PCI: Cannot allocate resource region 0 of device :01:00.0
Any ideas or advice would be greatly appreciated.
Best regards,
Pedro
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
with
hyperthreading still disabled it fails in the same way, so the problem
seems to be with APIC. Any ideas what more I can try?
Thanks in advance!!
Pedro
Pedro Pla wrote:
>Hello,
>
>I'm running a system with an Asus NCCH-DL motherboard with dual Nocona
>Xeon 3.2 GHZ cpu's,
ing a kernel hacker might want to look at...
Pedro
Pedro Pla wrote:
>Hi Again,
>
>I've done some further tests disabling hyperthreading which then lets me
>disable apic on the motherboard and when I disable these I can boot a
>kernel compiled with smp, however it boots detectin
Hans's proposal - it would increase power consumption, because of
increased disk activity. about con's swap prefetch, I'm not so sure...
regards,
pedro venda.
--
Pedro João Lopes Venda
email: pjvenda < at > arrakis.dhis.org
http://arrakis.dhis.org
pgpzSMFT9Chwo.pgp
Description: PGP signature
ed pages could be useless if the
applications dies.
I don't know enough about the kernel VM to answer this on my own.
regards,
pedro venda.
--
Pedro João Lopes Venda
email: pjvenda < at > arrakis.dhis.org
http://arrakis.dhis.org
pgpaHmy4OBRTC.pgp
Description: PGP signature
lots of reboots, etc), but I'd like to know more about this.
I had to reboot it, so it's all normal now.
If the behavior maintains, how can I infer if there is really a memory
leak? What kind of tests could I perform?
Parag Warudkar wrote:
> On Wednesday 16 February 2005 06:28 pm, Pedro Venda wrote:
>
>>Having upgraded most of them to 2.6.10-ac12, one of them showed a linear
>>growth of used memory over the last 7 days, after the first 2.6.10-ac12
>>boot. It came to a point that it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Noel Maddy wrote:
| On Thu, Feb 17, 2005 at 12:02:33AM +, Pedro Venda wrote:
|
|
|>admin proc # cat slabinfo
|
| ...
|
|>biovec-1 74224 74354 16 2261 : tunables 120 600 :
slabdata329329 0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pedro Venda wrote:
| Noel Maddy wrote:
| | On Thu, Feb 17, 2005 at 12:02:33AM +, Pedro Venda wrote:
| |
| |
| |>admin proc # cat slabinfo
| |
| | ...
| |
| |>biovec-1 74224 74354 16 2261 : tunables 120
| 600 :
| sl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Parag Warudkar wrote:
| On Wednesday 16 February 2005 06:28 pm, Pedro Venda wrote:
|
|>Having upgraded most of them to 2.6.10-ac12, one of them showed a linear
|>growth of used memory over the last 7 days, after the first 2.6.10-ac12
|>boot. I
filesystem into a ramdisk and use it from there.
your kernel command line is wrong. it should have root=/dev/rd/0 or
root=/dev/ram0 instead of root=/dev/fd0.
after loading the initrd, your root filesystem is on a ramdisk.
regards,
pedro venda.
- --
Pedro João Lopes Venda
email: pjvenda < at >
adsl routers. Took a while to discover that since the
connection misteriously ceased to work from some boxes after some time
transmitting data ok. Looks like some manufacturers such as efficient
networks adsl routers, doesn't follow the standards.
I'd suggest running tcpdump and doing so
https://www.sourceware.org/ml/gdb-patches/2015-11/msg00076.html
https://www.sourceware.org/ml/gdb-patches/2015-11/msg00077.html
Guess that makes fs_base/gs_base user-writable, if the kernel allows it.
Thanks,
Pedro Alves
sg4.html
still fails for me on Fedora 23 with git master gdb.
Nevermind the misleading URL, that's a kernel patch.
$ gcc -g -m32 interrupt.c -o interrupt.32
...
(gdb) r
Starting program: /home/pedro/tmp/interrupt.32
talk to me baby
^C
Program received signal SIGINT, Interrup
y problem: seccomp is currently entirely insecure if a
>> malicious ptracer is attached.) As a minimal fix, this patch adds a
>> new flag TS_I386_REGS_POKED that handles the ptrace special case.
>>
>> Cc: Pedro Alves
>> Cc: Oleg Nesterov
>> Cc: Kees Cook
>>
198) exited with code 01]
(gdb) q
Is this expected?
This is the same testcase as before:
https://sourceware.org/ml/gdb/2014-05/msg4.html
Thanks,
Pedro Alves
This patch fixes the problem and passes my tests on the CS.DB field,
this includes the "push es" and the "high 16-bits of ESP" test cases.
Tested-by: Pedro Fonseca
On 10/27/17 1:36 AM, Wanpeng Li wrote:
From: Wanpeng Li
Pedro reported:
During tests that we conducte
On 10/20/2015 06:17 PM, Oleg Nesterov wrote:
> Jan, Pedro, could you please confirm this won't break gdb? I tried
> to look into gdb-7.1, and at first glance gdb uses __WCLONE only
> because __WALL doesn't work on older kernels, iow it seems to me
> that gdb actually wants
el error out on PTRACE_TRACEME issued
from a non-leader thread? Then between PTRACE_TRACEME and the parent's
waitpid, __WALL or !__WALL should make no difference.
(Also, in the original test case, if the child gets/raises a signal or execs
before exiting, the bash/init/whatever process won
On 21/06/2024 08:45, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop
On 22/06/2024 01:57, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop
On 24/06/2024 12:43, Yunseong Kim wrote:
Hi Pedro,
On 6/25/24 12:12 오전, Pedro Tammela wrote:
On 22/06/2024 01:57, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
[ 5301.595872] KASAN: null-
Em qua., 7 de abr. de 2021 às 15:31, Andrii Nakryiko
escreveu:
>
> On Tue, Apr 6, 2021 at 11:55 AM Pedro Tammela wrote:
> >
> > This macro was refactored out of the bpf selftests.
> >
> > Since percpu values are rounded up to '8' in the kernel, a carele
Em qua., 7 de abr. de 2021 às 16:58, Andrii Nakryiko
escreveu:
>
> On Wed, Apr 7, 2021 at 11:43 AM Joe Stringer wrote:
> >
> > Hi Pedro,
> >
> > On Tue, Apr 6, 2021 at 11:58 AM Pedro Tammela wrote:
> > >
> > > In 'bpf_ringbuf_reserve()'
Em qua., 7 de abr. de 2021 às 16:51, Andrii Nakryiko
escreveu:
>
> On Wed, Apr 7, 2021 at 12:30 PM Pedro Tammela wrote:
> >
> > Em qua., 7 de abr. de 2021 às 15:31, Andrii Nakryiko
> > escreveu:
> > >
> > > On Tue, Apr 6, 2021 at 11:55 AM Pedro Tamm
list the
following jump. And then if it's possible run a CFI generator
as a separate step over the source, it sounds like it should also
be possible to have the assembler do it instead too (again with
some new high level directive to trigger/help it).
Thanks,
Pedro Alves
--
To unsubscribe f
On 06/12/2015 03:10 PM, Josh Poimboeuf wrote:
> On Fri, Jun 12, 2015 at 12:18:16PM +0100, Pedro Alves wrote:
>> On 06/11/2015 03:10 PM, Josh Poimboeuf wrote:
>>
>>> C would definitely make more sense when analyzing object code. In fact,
>>> asmvalidate is written
patch makes positive returns from the callback a no-op.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/ringbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/ringbuf.c b/tools/lib/bpf/ringbuf.c
index 8caaafe7e312..e7a8d847161f 100644
--- a/tools/lib/bpf/ringbuf.c
From: Pedro Tammela
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/lpm_trie.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
index cec792a17e5f..1b7b8a6f34ee 100644
--- a/kernel/bpf/lpm_trie.c
+++ b/kernel/bpf
The patch itself is straightforward thanks to the infrastructure that is
already in-place.
The tests follows the other '*_map_batch_ops' tests with minor tweaks.
v1 -> v2:
Fixes for checkpatch warnings
Pedro Tammela (2):
bpf: add support for batched operations in LPM tr
From: Pedro Tammela
Uses the already existing infrastructure for testing batched ops.
The testing code is essentially the same, with minor tweaks for this use
case.
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
.../map_tests/lpm_trie_map_batch_ops.c (new) | 158
Em seg., 29 de mar. de 2021 às 13:10, Song Liu escreveu:
>
>
>
> > On Mar 28, 2021, at 9:10 AM, Pedro Tammela wrote:
> >
> > The current code only checks flags in 'bpf_ringbuf_output()'.
> >
> > Signed-off-by: Pedro Tammela
> > ---
> >
The current code only checks flags in 'bpf_ringbuf_output()'.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 8
kernel/bpf/ringbuf.c | 13 +++--
tools/include/uapi/linux/bpf.h | 8
3 files changed, 19 insertions(+), 10 deletion
The patch itself is straightforward thanks to the infrastructure that is
already in-place.
The tests follows the other '*_map_batch_ops' tests with minor tweaks.
Pedro Tammela (2):
bpf: add support for batched operations in LPM trie maps
bpf: selftests: add tests for batched ops i
From: Pedro Tammela
Uses the already existing infrastructure for testing batched ops.
The testing code is essentially the same, with minor tweaks for this use
case.
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
.../map_tests/lpm_trie_map_batch_ops.c (new) | 158
From: Pedro Tammela
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/lpm_trie.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
index cec792a17e5f..1b7b8a6f34ee 100644
--- a/kernel/bpf/lpm_trie.c
+++ b/kernel/bpf
ore descriptive notation for this value.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 8
tools/include/uapi/linux/bpf.h | 8
tools/testing/selftests/bpf/progs/ima.c| 2 +-
tools/testing/selftes
The current code only checks flags in 'bpf_ringbuf_output()'.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 8
kernel/bpf/ringbuf.c | 13 +++--
tools/include/uapi/linux/bpf.h | 8
3 files changed, 19 insertions(+), 10 deletion
'bpf_ring_buffer__poll()' abstracts the polling method, so abstract the
constants that make the implementation don't wait or wait indefinetly
for data.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/libbpf.h | 3 +++
tools/testing/selft
pu macros
v1 -> v2:
- Amended a more descriptive commit message
Pedro Tammela (3):
bpf: add batched ops support for percpu array
bpf: selftests: remove percpu macros from bpf_util.h
bpf: selftests: update array map tests for per-cpu batched ops
kernel/bpf/arraymap.c
i Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/arraymap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 463d25e1e67e..3c4105603f9d 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -698,6 +698,8 @@ const str
Signed-off-by: Pedro Tammela
---
tools/testing/selftests/bpf/bpf_util.h| 7 --
.../bpf/map_tests/htab_map_batch_ops.c| 87 +--
.../selftests/bpf/prog_tests/map_init.c | 9 +-
tools/testing/selftests/bpf/test_maps.c | 84 +++---
4 files changed
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 104 +-
1 file changed, 75 insertions(+), 29 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing
In 'bpf_ringbuf_reserve()' we require the flag to '0' at the moment.
For 'bpf_ringbuf_{discard,submit,output}' a flag of '0' might send a
notification to the process if needed.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 16
v3:
- Remove percpu macros as suggested by Andrii
- Update tests that used the per cpu macros
v1 -> v2:
- Amended a more descriptive commit message
Pedro Tammela (3):
bpf: add batched ops support for percpu array
bpf: selftests: remove percpu macros from bpf_util.h
bpf: selftests: update arr
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 110 +-
1 file changed, 80 insertions(+), 30 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing
Signed-off-by: Pedro Tammela
---
tools/testing/selftests/bpf/bpf_util.h| 7 --
.../bpf/map_tests/htab_map_batch_ops.c| 71
.../selftests/bpf/prog_tests/map_init.c | 9 +-
tools/testing/selftests/bpf/test_maps.c | 84 +++
4 files changed, 89
i Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/arraymap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 463d25e1e67e..3c4105603f9d 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -698,6 +698,8 @@ const str
refactored
out to libbpf, with some simplifications for reuse.
The tests were updated to reflect all the new changes.
v1 -> v2:
- Amended a more descriptive commit message
Pedro Tammela (3):
bpf: add batched ops support for percpu array
libbpf: selftests: refactor 'BPF_PERCPU_TYPE(
ops in the
percpu variant, let's provide a convenient macro to declare percpu map
value types.
Updates the tests to a "reference" usage of the new macro.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/bpf.h | 10
tools/testing/selftests/bpf/bpf_util.h
i Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/arraymap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 463d25e1e67e..3c4105603f9d 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -698,6 +698,8 @@ const str
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 114 +-
1 file changed, 85 insertions(+), 29 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing
In 'bpf_ringbuf_reserve()' we require the flag to '0' at the moment.
For 'bpf_ringbuf_{discard,submit,output}' a flag of '0' might send a
notification to the process if needed.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 7 +++
In older kernels, pre batched ops, it returns EINVAL as the arguments
are not supported in the syscall.
[1] https://lore.kernel.org/netdev/20200511165319.2251678-1-k...@kernel.org/
Signed-off-by: Pedro Tammela
---
kernel/bpf/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
Em dom., 18 de abr. de 2021 às 19:56, Alexei Starovoitov
escreveu:
>
> On Sun, Apr 18, 2021 at 1:03 PM Pedro Tammela wrote:
> >
> > ENOTSUPP is not a valid userland errno[1], which is annoying for
> > userland applications that implement a fallback to iterative, report
Em qua., 31 de mar. de 2021 às 04:02, Andrii Nakryiko
escreveu:
>
> On Tue, Mar 30, 2021 at 4:16 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, Mar 30, 2021 at 3:54 PM Pedro Tammela wrote:
> > >
> > > BPF_CALL_2(bpf_ringbuf_submit, void *, sample
Em qua., 31 de mar. de 2021 às 03:54, Andrii Nakryiko
escreveu:
>
> On Sun, Mar 28, 2021 at 9:11 AM Pedro Tammela wrote:
> >
> > The current way to provide a no-op flag to 'bpf_ringbuf_submit()',
> > 'bpf_ringbuf_discard()' and 'bpf_ringbuf_outp
refactored
out to libbpf, with some simplifications for reuse.
The tests were updated to reflect all the new changes.
Pedro Tammela (3):
bpf: add batched ops support for percpu array
libbpf: selftests: refactor 'BPF_PERCPU_TYPE()' and 'bpf_percpu()'
macros
bpf: selftes
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/arraymap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 463d25e1e67e..3c4105603f9d 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -698,6
ops in the
percpu variant, let's provide a convenient macro to declare percpu map
value types.
Updates the tests to a "reference" usage of the new macro.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/bpf.h | 10
tools/testing/selftests/bpf/bpf_util.h
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 114 +-
1 file changed, 85 insertions(+), 29 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing
gi?id=26754
I've went through GDB's code looking for potential issues with the change and
whether
it would affect GDBs already in the wild. Tricky corner cases abound, but I
think
we're good. Feel free to add my ack:
Acked-by: Pedro Alves
Thanks,
Pedro Alves
t hints inline to clang.
This change now enforces the proper definition for BPF programs
regardless of the include order.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/bpf_helpers.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/bpf_helpers.h b/too
This seems to be a reminiscent from the hashmap tests.
Signed-off-by: Pedro Tammela
---
tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing/selftests/bpf
report an event.
+10^6. With PTRACE_SYSCALL/sysgood, we don't have a way to trace
syscalls when single-stepping, which isn't much of a problem for
strace, but of course is for GDB. That is one of the things the
new API should definitely sort out.
--
Pedro Alves
--
To unsubscribe
d VMX registers */
> PTRACE_GETTM_CVMXREGS
> PTRACE_SETTM_CVMXREGS
Urgh, we're _still_ adding specialized register specific calls?
Why aren't these exported as new register sets, accessible through
PTRACE_GETREGSET / PTRACE_SETREGSET? That's supposed to be the
Modern Way to do thin
Does this support PTRACE_GETREGSET / PTRACE_SETREGSET ?
IMO, the kernel shouldn't accept ports without those anymore.
And IMHO, we shouldn't even allow new ports having PTRACE_GETREGS.
http://sourceware.org/ml/archer/2010-q3/msg00193.html
--
Pedro Alves
--
To unsubscribe from this
On 05/15/2014 03:36 PM, Denys Vlasenko wrote:
> On 05/14/2014 08:49 PM, Pedro Alves wrote:
>> I realized now that I responded to this. Sorry about that.
>>
>> On 01/19/2014 03:29 PM, Oleg Nesterov wrote:
>>> On 01/19, Sergio Durigan Junior wrote:
>>>
et)
> +{
> + if (!cpu_has_feature(CPU_FTR_TM))
> + return -ENODEV;
... unfortunately this will do the wrong thing.
Thanks,
--
Pedro Alves
--
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/
On 05/20/2014 09:14 AM, Anshuman Khandual wrote:
> On 05/19/2014 08:13 PM, Pedro Alves wrote:
>> On 05/19/2014 12:46 PM, Anshuman Khandual wrote:
>>
>>>>> I couldn't actually find any arch that currently returns -ENODEV in
>>>>> the &quo
break;
>
> which gets used for 32-bit compat ptrace(2). Perhaps the same logic
> should be added to putreg() if the child is a 32-bit process?
Sounds like the right fix to me.
--
Pedro Alves
--
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/
On 04/28/2014 11:30 AM, Anshuman Khandual wrote:
> On 04/26/2014 05:12 AM, Pedro Alves wrote:
>> On 04/02/2014 08:02 AM, Anshuman Khandual wrote:
>>> This patch adds following new sets of ptrace request macros for
>>> transactional
>>> memory expandin
1 - 100 of 197 matches
Mail list logo
