info test, fix for mips n32
Again, I can't review 1-3, I know nothing about the non-x86 architectures.
As for 4-6, feel free to add
Reviewed-by: Oleg Nesterov
and avoid #ifdef + test_thread_flag(TIF_SECCOMP). CONFIG_GENERIC_ENTRY is
not defined, so test_syscall_work(SECCOMP) will check TIF_SECCOMP.
Signed-off-by: Oleg Nesterov
Acked-by: Thomas Bogendoerfer
Reviewed-by: Kees Cook
---
arch/mips/kernel/ptrace.c | 20 ++--
1 file
After the previous change 'sd' is always NULL.
Signed-off-by: Oleg Nesterov
Reviewed-by: Kees Cook
---
kernel/seccomp.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 281e853bae8c..4bd2eb50f77b 10
After the previous changes 'sd' is always NULL.
Signed-off-by: Oleg Nesterov
Reviewed-by: Kees Cook
---
arch/powerpc/kernel/ptrace/ptrace.c | 2 +-
include/linux/seccomp.h | 6 +++---
kernel/entry/common.c | 2 +-
kernel/seccomp.c
("seccomp: Stub for !HAVE_ARCH_SECCOMP_FILTER")
Signed-off-by: Oleg Nesterov
---
include/linux/seccomp.h | 8 ++--
kernel/seccomp.c| 14 ++
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index e4
Hello,
Link to v1: https://lore.kernel.org/all/20250120134409.ga21...@redhat.com/
Only 2/4 was changed, please see interdiff at the end.
I've included the acks I got on 1/4, 3/4, and 4/4 (thanks!).
Oleg.
---
arch/mips/kernel/ptrace.c | 20 ++-
arch/powerpc/kernel/ptra
On 01/20, Kees Cook wrote:
>
> On Mon, Jan 20, 2025 at 02:44:52PM +0100, Oleg Nesterov wrote:
> > Depending on CONFIG_HAVE_ARCH_SECCOMP_FILTER, __secure_computing(NULL)
> > will crash or not, this is not consistent/safe.
>
> Right now this never happens beca
After the previous change 'sd' is always NULL.
Signed-off-by: Oleg Nesterov
---
kernel/seccomp.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index c29dfe82139e..75e293d3c1a1 100644
--- a/kernel/secco
After the previous changes 'sd' is always NULL.
Signed-off-by: Oleg Nesterov
---
arch/powerpc/kernel/ptrace/ptrace.c | 2 +-
include/linux/seccomp.h | 8
kernel/entry/common.c | 2 +-
kernel/seccomp.c| 7 +++
4 files
__secure_computing(sd) is always called
with sd == NULL, so it is clear that we can remove the code which makes
no sense.
Signed-off-by: Oleg Nesterov
---
include/linux/seccomp.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
and avoid #ifdef + test_thread_flag(TIF_SECCOMP). CONFIG_GENERIC_ENTRY is
not defined, so test_syscall_work(SECCOMP) will check TIF_SECCOMP.
Signed-off-by: Oleg Nesterov
---
arch/mips/kernel/ptrace.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/arch/m
Hello,
I know nothing about arch/mips and I don't have a mips machine, 1/4 wasn't
even compile tested.
Oleg.
---
arch/mips/kernel/ptrace.c | 20 ++--
arch/powerpc/kernel/ptrace/ptrace.c | 2 +-
include/linux/seccomp.h | 12
kernel/entry/common
On 02/04, Ravi Bangoria wrote:
>
> +static int get_instr(struct mm_struct *mm, unsigned long addr, u32 *instr)
> +{
> + struct page *page;
> + struct vm_area_struct *vma;
> + void *kaddr;
> + unsigned int gup_flags = FOLL_FORCE | FOLL_SPLIT_PMD;
> +
> + if (get_user_pages_remote
On 01/19, Ravi Bangoria wrote:
>
> Probe on 2nd word of a prefixed instruction is invalid scenario and
> should be restricted.
I don't understand this ppc-specific problem, but...
> +#ifdef CONFIG_PPC64
> +int arch_uprobe_verify_opcode(struct page *page, unsigned long vaddr,
> +
Christophe, et al,
So what?
Are you going to push your change or should I re-send 1-2 without
whitespace cleanups?
On 11/19, Oleg Nesterov wrote:
>
> On 11/19, Christophe Leroy wrote:
> >
> > I think the following should work, and not require the first patch (compi
On 11/19, Christophe Leroy wrote:
>
> I think the following should work, and not require the first patch (compile
> tested only).
>
> --- a/arch/powerpc/kernel/ptrace/ptrace-view.c
> +++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
> @@ -234,9 +234,21 @@ static int gpr_get(struct task_struct *target,
On 11/19, Christophe Leroy wrote:
>
>
> Le 19/11/2020 à 17:01, Oleg Nesterov a écrit :
> >Can we finally fix this problem? ;)
> >
> >My previous attempt was ignored, see
>
> That doesn't seems right.
>
> Michael made some suggestion it seem
On 11/19, Christophe Leroy wrote:
>
>
> Le 19/11/2020 à 17:02, Oleg Nesterov a écrit :
> >gpr_get() does membuf_write() twice to override pt_regs->msr in between.
>
> Is there anything wrong with that ?
Nothing wrong, but imo the code and 2/2 looks simpler after this p
On 11/19, Oleg Nesterov wrote:
>
> This is not consistent and this breaks the user-regs-peekpoke test
> from https://sourceware.org/systemtap/wiki/utrace/tests/
See the test-case below.
Oleg.
/* Test case for PTRACE_SETREGS modifying the requested ragisters.
x86* counterpart of
are.org/systemtap/wiki/utrace/tests/
Reported-by: Jan Kratochvil
Signed-off-by: Oleg Nesterov
---
arch/powerpc/kernel/ptrace/ptrace-tm.c | 8 +++-
arch/powerpc/kernel/ptrace/ptrace-view.c | 8 +++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ptra
after membuf_write().
Signed-off-by: Oleg Nesterov
---
arch/powerpc/kernel/ptrace/ptrace-tm.c | 13 +
arch/powerpc/kernel/ptrace/ptrace-view.c | 13 +
include/linux/regset.h | 12
3 files changed, 22 insertions(+), 16 deletions(-)
diff -
Can we finally fix this problem? ;)
My previous attempt was ignored, see
https://lore.kernel.org/lkml/20190917121256.ga8...@redhat.com/
Now that gpr_get() was changed to use membuf API we can make a simpler fix.
Sorry, uncompiled/untested, I don't have a ppc machine.
Oleg.
arch/power
On 06/11, Madhavan Srinivasan wrote:
>
>
> On 6/10/20 8:37 PM, Oleg Nesterov wrote:
> >Hi,
> >
> >looks like this patch was forgotten.
>
> yep, I missed this. But mpe did have comments for the patch.
>
> https://lkml.org/lkml/2019/9/19/107
Yes, and I though
Hi,
looks like this patch was forgotten.
Do you think this should be fixed or should we document that
PTRACE_GETREGS is not consistent with PTRACE_PEEKUSER on ppc64?
On 09/17, Oleg Nesterov wrote:
>
> I don't have a ppc machine, this patch wasn't even compile tested,
> coul
t;softe as is.
This is not consistent and this breaks
http://sourceware.org/systemtap/wiki/utrace/tests/user-regs-peekpoke
Reported-by: Jan Kratochvil
Signed-off-by: Oleg Nesterov
---
arch/powerpc/kernel/ptrace.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arc
t;softe as is.
This is not consistent and this breaks
http://sourceware.org/systemtap/wiki/utrace/tests/user-regs-peekpoke
Reported-by: Jan Kratochvil
Signed-off-by: Oleg Nesterov
---
arch/powerpc/kernel/ptrace.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arc
On 05/23, Christian Brauner wrote:
>
> So given that we would really need another find_next_open_fd() I think
> sticking to the simple cond_resched() version I sent before is better
> for now until we see real-world performance issues.
OK, agreed.
Oleg.
On 05/23, Christian Brauner wrote:
>
> +int __close_range(struct files_struct *files, unsigned fd, unsigned max_fd)
> +{
> + unsigned int cur_max;
> +
> + if (fd > max_fd)
> + return -EINVAL;
> +
> + rcu_read_lock();
> + cur_max = files_fdtable(files)->max_fds;
> + r
On 05/22, Christian Brauner wrote:
>
> +static struct file *pick_file(struct files_struct *files, unsigned fd)
> {
> - struct file *file;
> + struct file *file = NULL;
> struct fdtable *fdt;
>
> spin_lock(&files->file_lock);
> @@ -632,15 +629,65 @@ int __close_fd(struct files
asm-generic/ptrace.h | 74 --
> 3 files changed, 80 deletions(-)
> delete mode 100644 include/asm-generic/ptrace.h
Acked-by: Oleg Nesterov
On 05/20, Christoph Hellwig wrote:
>
> Doing the indirection through macros for the regs accessors just
> makes them harder to read, so implement the helpers directly.
Acked-by: Oleg Nesterov
On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PID
On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov wrote:
> > On 05/16, Christian Brauner wrote:
> > >
> > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > created pidfds at process creation time.
> >
> >
roup leader we might return the old leader.
> + */
> + tsk = pid_task(p, PIDTYPE_TGID);
> + if (!tsk)
> + ret = -ESRCH;
> + rcu_read_unlock();
> +
> + fd = ret ?: pidfd_create(p);
> + put_pid(p);
> + return fd;
> +}
Looks correc
On 05/15, Oleg Nesterov wrote:
>
> On 05/15, Christian Brauner wrote:
> >
> > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags)
> > +{
> > + int fd, ret;
> > + struct pid *p;
> > + struct task_struct *tsk;
> > +
> > + if (f
On 05/15, Christian Brauner wrote:
>
> On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote:
> >
> > it seems that you can do a single check
> >
> > tsk = pid_task(p, PIDTYPE_TGID);
> > if (!tsk)
> > ret = -ESRCH;
> >
On 05/15, Christian Brauner wrote:
>
> +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags)
> +{
> + int fd, ret;
> + struct pid *p;
> + struct task_struct *tsk;
> +
> + if (flags)
> + return -EINVAL;
> +
> + if (pid <= 0)
> + return -EINVAL;
> +
On 04/16, Dmitry V. Levin wrote:
>
> [Andrew, could you take this patchset into your tree, please?]
Just in case...
I have already acked 6/7.
Other patches look good to me too, just I don't think I can actually review
these non-x86 changes.
Oleg.
On 05/01, Christoph Hellwig wrote:
>
> Hi all,
>
> asm-generic/ptrace.h is a little weird in that it doesn't actually
> implement any functionality, but it provided multiple layers of macros
> that just implement trivial inline functions. We implement those
> directly in the few architectures and
On 04/30, Sudeep Holla wrote:
>
> On Mon, Mar 18, 2019 at 04:33:22PM +0100, Oleg Nesterov wrote:
> >
> > And it seems that _TIF_WORK_SYSCALL_ENTRY needs some cleanups too... We
> > don't need
> > "& _TIF_WORK_SYSCALL_ENTRY" in syscall_trace_enter
On 03/19, Oleg Nesterov wrote:
>
> Well, personally I see no point... Again, after the trivial simplification
> x86 does
>
> if (work & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) {
> ret = tracehook_report_syscall_entry(regs);
> if (ret ||
On 03/18, Sudeep Holla wrote:
>
> On Mon, Mar 18, 2019 at 06:33:41PM +0100, Oleg Nesterov wrote:
> > On 03/18, Sudeep Holla wrote:
> > >
> > > On Mon, Mar 18, 2019 at 06:20:24PM +0100, Oleg Nesterov wrote:
> > > >
> > > > Again, to me
On 03/18, Sudeep Holla wrote:
>
> On Mon, Mar 18, 2019 at 06:20:24PM +0100, Oleg Nesterov wrote:
> >
> > Again, to me this patch just makes the code look worse. Honestly, I don't
> > think that the new (badly named) ptrace_syscall_enter() hook makes any
> > sen
On 03/18, Sudeep Holla wrote:
>
@@ -534,6 +534,10 @@ static int ptrace_detach(struct task_struct *child,
unsigned int data)
> /* Architecture-specific hardware disable .. */
> ptrace_disable(child);
>
> +#ifdef TIF_SYSCALL_EMU
> + clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
>
On 03/18, Sudeep Holla wrote:
>
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -3278,35 +3278,29 @@ long do_syscall_trace_enter(struct pt_regs *regs)
>
> user_exit();
>
> - flags = READ_ONCE(current_thread_info()->flags) &
> - (_TIF_SYSCALL_
On 03/18, Sudeep Holla wrote:
>
> --- a/arch/x86/entry/common.c
> +++ b/arch/x86/entry/common.c
> @@ -70,22 +70,16 @@ static long syscall_trace_enter(struct pt_regs *regs)
>
> struct thread_info *ti = current_thread_info();
> unsigned long ret = 0;
> - bool emulated = false;
>
On 12/16, Dmitry V. Levin wrote:
>
> long do_syscall_trace_enter(struct pt_regs *regs)
> {
> + u32 cached_flags;
> +
> user_exit();
>
> - if (test_thread_flag(TIF_SYSCALL_EMU)) {
> - /*
> - * A nonzero return code from tracehook_report_syscall_entry()
> -
On 12/07, Dmitry V. Levin wrote:
>
> Please make either v5 or v6 edition of this fix, or any similar fix,
> into v4.20.
IIUC, v5 above means
[PATCH v5 23/25] powerpc/ptrace: replace ptrace_report_syscall() with a
tracehook call
you sent in another series...
> long do_syscall_trace_ent
On 12/07, Dmitry V. Levin wrote:
>
> On Fri, Dec 07, 2018 at 10:12:49PM +1100, Michael Ellerman wrote:
>
> > > Sorry, this patch does not work, please ignore it.
> >
> > Hmm OK. Why exactly?
>
> Unfortunately, I have no idea why it doesn't work.
> All I can say is it breaks strace because the kerne
On 11/02, Miroslav Benes wrote:
>
> On Wed, 1 Nov 2017, Oleg Nesterov wrote:
>
> > Note also that wake_up_state(TASK_INTERRUPTIBLE) won't wakeup the TASK_IDLE
> > kthreads, and most of the kthreads which use TASK_INTERRUPTIBLE should use
> > TASK_I
On 11/01, Petr Mladek wrote:
>
> On Tue 2017-10-31 12:48:52, Miroslav Benes wrote:
> > + if (task->flags & PF_KTHREAD) {
> > + /*
> > +* Wake up a kthread which still has not been migrated.
> > +*/
> > + wake_up_p
On 06/29, James Morse wrote:
>
> compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK,
> instead using those in ptrace_request(). The compat variant should
> read a compat_sigset_t from userspace instead of ptrace_request()s
> sigset_t.
Acked-by: Oleg Nesterov
On 09/28, Kees Cook wrote:
>
> This is where the flags are actually built from what's coming in
> through the newly created exported function vm_brk_flags() below. The
> only flag we're acting on is VM_EXEC (passed in from set_brk() above).
> I think do_brk_flags() should mask the valid flags, or w
On 08/10, Denys Vlasenko wrote:
>
> Currently, to support 32-bit binaries with PLT in BSS kernel maps *entire
> brk area* with executable rights for all binaries, even --secure-plt ones.
>
> Stop doing that.
Can't really review this patch, but at least the change in mm/mmap.c looks
technically cor
On 07/15, Topi Miettinen wrote:
>
> On 07/15/16 15:14, Oleg Nesterov wrote:
> >
> > Btw this is not right. The same for the previous patch which tracks
> > RLIMIT_STACK. The "current" task can debugger/etc.
>
> acct_stack_growth() is called from expand_upwar
On 07/15, Topi Miettinen wrote:
>
> Track maximum size of locked memory, to be able to configure
> RLIMIT_MEMLOCK resource limits. The information is available
> with taskstats and cgroupstats netlink socket.
So I personally still dislike the very idea of this series... but I won't
argue if you co
On 11/07, Andy Lutomirski wrote:
>
> On Wed, Nov 4, 2015 at 4:50 PM, Amanieu d'Antras wrote:
> > One issue that isn't resolved in this series is sending signals between a
> > 32-bit
> > process and 64-bit process. Sending a si_int will work correctly, but a
> > si_ptr
> > value will likely get c
On 01/15, Christian Borntraeger wrote:
>
> Am 15.01.2015 um 20:38 schrieb Oleg Nesterov:
> > On 01/15, Christian Borntraeger wrote:
> >>
> >> --- a/arch/x86/include/asm/spinlock.h
> >> +++ b/arch/x86/include/asm/spinlock.h
> >> @@ -186,7 +186,7 @
On 01/15, Christian Borntraeger wrote:
>
> --- a/arch/x86/include/asm/spinlock.h
> +++ b/arch/x86/include/asm/spinlock.h
> @@ -186,7 +186,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t
> *lock)
> __ticket_t head = ACCESS_ONCE(lock->tickets.head);
>
> for (;;) {
> -
1]
> some time ago but was never merged.
>
> [1]: http://marc.info/?l=linux-kernel&m=127144305403241&w=2
>
> Signed-off-by: Aaron Tomlin
> Acked-by: Michael Ellerman
Acked-by: Oleg Nesterov
___
Linuxppc-dev mail
On 09/04, Aaron Tomlin wrote:
>
> +#define task_stack_end_corrupted(task) \
> + (*(end_of_stack(task)) != STACK_END_MAGIC)
and it is always used along with "tsk != init_task".
But why we exclude swapper/0? Can't we add
end_of_stack(current) = STACK_END_MAGIC;
somewhere at th
On 07/13, Benjamin Herrenschmidt wrote:
>
> On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
> > OK, looks like this is compiler bug,
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
> >
> > Thanks to Dan who informed me privately.
>
>
OK, looks like this is compiler bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Thanks to Dan who informed me privately.
On 07/12, Oleg Nesterov wrote:
>
> Hello,
>
> I am not sure I should ask here, but since Documentation/memory-barriers.txt
> mentions load/store tea
Hello,
I am not sure I should ask here, but since Documentation/memory-barriers.txt
mentions load/store tearing perhaps my question is not completely off-topic...
I am fighting with mysterious RHEL bug, it can be reproduced on ppc and s390
but not on x86. Finally I seem to understand the problem,
On 10/29, Peter Zijlstra wrote:
>
> On Tue, Oct 29, 2013 at 11:30:57AM +0100, Peter Zijlstra wrote:
> > @@ -154,9 +175,11 @@ int perf_output_begin(struct perf_output
> > * Userspace could choose to issue a mb() before updating the
> > * tail pointer. So that all reads will
On 10/28, Paul E. McKenney wrote:
>
> On Mon, Oct 28, 2013 at 02:26:34PM +0100, Peter Zijlstra wrote:
> > --- linux-2.6.orig/kernel/events/ring_buffer.c
> > +++ linux-2.6/kernel/events/ring_buffer.c
> > @@ -87,10 +87,31 @@ static void perf_output_put_handle(struc
> > goto out;
> >
> >
On 10/28, Peter Zijlstra wrote:
>
> Lets add Paul and Oleg to the thread; this is getting far more 'fun'
> that it should be ;-)
Heh. All I can say is that I would like to see the authoritative answer,
you know who can shed a light ;)
But to avoid the confusion, wmb() added by this patch looks "o
ate any user of ptrace_get/put_breakpoints
in arch/ (simply remove these calls), then change the core kernel code, then
fix arch/86.
--
From: Oleg Nesterov
Subject: ptrace/powerpc: revert "hw_breakpoints: Fix racy access to ptrace
brea
arch_dup_task_struct() does flush_ptrace_hw_breakpoint(src), this
destroys the parent's breakpoints for no reason. We should clear
child->thread.ptrace_bps[] copied by dup_task_struct() instead.
Signed-off-by: Oleg Nesterov
Acked-by: Michael Neuling
--- x/arch/powerpc/kernel/process
On 03/22, Ananth N Mavinakayanahalli wrote:
>
> Some architectures like powerpc have multiple variants of the trap
> instruction. Introduce an additional helper is_trap_insn() for run-time
> handling of non-uprobe traps on such architectures.
Looks fine to me.
I am going to take this into my tree
On 03/22, Ananth N Mavinakayanahalli wrote:
>
> +/**
> + * is_trap_insn - check if instruction is breakpoint instruction.
> + * @insn: instruction to be checked.
> + * Default implementation of is_trap_insn
> + * Returns true if @insn is a breakpoint instruction.
> + *
> + * This function is needed
On 03/22, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Mar 21, 2013 at 04:58:09PM +0100, Oleg Nesterov wrote:
> >
> > - verify_opcode()->is_swbp_insn() means:
> >
> > is this insn fine for uprobe? (we do not care about
> > gdb, we
On 03/21, Ananth N Mavinakayanahalli wrote:
?
> On Wed, Mar 20, 2013 at 05:07:28PM +0100, Oleg Nesterov wrote:
> > On 03/20, Ananth N Mavinakayanahalli wrote:
> > >
> > > On Wed, Mar 20, 2013 at 01:43:01PM +0100, Oleg Nesterov wrote:
> > > > On 03/20, Oleg Ne
On 03/21, Ananth N Mavinakayanahalli wrote:
>
> On Wed, Mar 20, 2013 at 05:06:44PM +0100, Oleg Nesterov wrote:
>
> > > > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> > > > verify. If not, we need 2 definitions. is_uprobe_i
On 03/20, Ananth N Mavinakayanahalli wrote:
>
> On Wed, Mar 20, 2013 at 01:43:01PM +0100, Oleg Nesterov wrote:
> > On 03/20, Oleg Nesterov wrote:
> > >
> > > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> > > verify. If not
On 03/20, Ananth N Mavinakayanahalli wrote:
>
> On Wed, Mar 20, 2013 at 01:26:39PM +0100, Oleg Nesterov wrote:
> > But, at the same time, is the new definition fine for verify_opcode()?
> >
> > IOW, powerpc has another is_trap() insn(s) used by gdb, lets denote it X.
&
On 03/20, Oleg Nesterov wrote:
>
> But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> verify. If not, we need 2 definitions. is_uprobe_insn() should still check
> insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap().
>
> And I am just
Hi Ananth,
First of all, let me remind that I know nothing about powerpc ;)
But iirc we already discussed this a bit, I forgot the details but
still I have some concerns...
On 03/20, Ananth N Mavinakayanahalli wrote:
>
> GDB uses a variant of the trap instruction that is different from the
> one
On 03/05, Lai Jiangshan wrote:
>
> On 03/03/13 01:20, Oleg Nesterov wrote:
> > On 03/02, Lai Jiangshan wrote:
> >>
> >> +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw)
> >> +{
> >> + switch (__this_cpu_read(*lgrw->reader_refcnt)) {
>
On 03/05, Lai Jiangshan wrote:
>
> On 03/03/13 01:06, Oleg Nesterov wrote:
> > On 03/02, Michel Lespinasse wrote:
> >>
> >> My version would be slower if it needs to take the
> >> slow path in a reentrant way, but I'm not sure it matters either :)
On 03/02, Oleg Nesterov wrote:
>
> On 03/02, Lai Jiangshan wrote:
> >
> > +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw)
> > +{
> > + switch (__this_cpu_read(*lgrw->reader_refcnt)) {
> > + case 1:
> > +
On 03/02, Lai Jiangshan wrote:
>
> +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw)
> +{
> + switch (__this_cpu_read(*lgrw->reader_refcnt)) {
> + case 1:
> + __this_cpu_write(*lgrw->reader_refcnt, 0);
> + lg_local_unlock(&lgrw->lglock);
> + return
On 03/02, Michel Lespinasse wrote:
>
> My version would be slower if it needs to take the
> slow path in a reentrant way, but I'm not sure it matters either :)
I'd say, this doesn't matter at all, simply because this can only happen
if we race with the active writer.
Oleg.
__
On 03/02, Lai Jiangshan wrote:
>
> On 02/03/13 02:28, Oleg Nesterov wrote:
> > Lai, I didn't read this discussion except the code posted by Michel.
> > I'll try to read this patch carefully later, but I'd like to ask
> > a couple of questions.
> >
>
Lai, I didn't read this discussion except the code posted by Michel.
I'll try to read this patch carefully later, but I'd like to ask
a couple of questions.
This version looks more complex than Michel's, why? Just curious, I
am trying to understand what I missed. See
http://marc.info/?l=linux-kern
On 02/28, Oleg Nesterov wrote:
> On 02/28, Michel Lespinasse wrote:
> >
> > On Thu, Feb 28, 2013 at 3:25 AM, Oleg Nesterov wrote:
> > > On 02/27, Michel Lespinasse wrote:
> > >>
> > >> +void lg_rwlock_local_read_lock(struct lgrwlock
On 02/28, Michel Lespinasse wrote:
>
> On Thu, Feb 28, 2013 at 3:25 AM, Oleg Nesterov wrote:
> > On 02/27, Michel Lespinasse wrote:
> >>
> >> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
> >> +{
> >> + preempt_disable();
> >&g
On 02/27, Michel Lespinasse wrote:
>
> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
> +{
> + preempt_disable();
> +
> + if (__this_cpu_read(*lgrw->local_refcnt) ||
> + arch_spin_trylock(this_cpu_ptr(lgrw->lglock->lock))) {
> + __this_cpu_inc(*lgrw->loca
On 02/11, Srivatsa S. Bhat wrote:
>
> On 02/09/2013 04:40 AM, Paul E. McKenney wrote:
> >> +static void announce_writer_inactive(struct percpu_rwlock *pcpu_rwlock)
> >> +{
> >> + unsigned int cpu;
> >> +
> >> + drop_writer_signal(pcpu_rwlock, smp_processor_id());
> >
> > Why do we drop ourselves
On 02/11, Srivatsa S. Bhat wrote:
>
> On 02/10/2013 11:36 PM, Oleg Nesterov wrote:
> >>> +static void announce_writer_inactive(struct percpu_rwlock *pcpu_rwlock)
> >>> +{
> >>> + unsigned int cpu;
> >>> +
> >>> + drop_writer
only one cosmetic nit...
On 01/22, Srivatsa S. Bhat wrote:
>
> +#define READER_PRESENT (1UL << 16)
> +#define READER_REFCNT_MASK (READER_PRESENT - 1)
> +
> #define reader_uses_percpu_refcnt(pcpu_rwlock, cpu) \
> (ACCESS_ONCE(per_cpu(*((pcpu_rwlock)->
On 02/08, Paul E. McKenney wrote:
>
> On Tue, Jan 22, 2013 at 01:03:53PM +0530, Srivatsa S. Bhat wrote:
> >
> > void percpu_read_unlock(struct percpu_rwlock *pcpu_rwlock)
> > {
> > - read_unlock(&pcpu_rwlock->global_rwlock);
>
> We need an smp_mb() here to keep the critical section ordered befo
On 01/23, Michel Lespinasse wrote:
>
> On Tue, Jan 22, 2013 at 11:32 AM, Steven Rostedt wrote:
> >
> > I thought global locks are now fair. That is, a reader will block if a
> > writer is waiting. Hence, the above should deadlock on the current
> > rwlock_t types.
>
> I believe you are mistaken he
On 08/23, Benjamin Herrenschmidt wrote:
>
> On Thu, 2012-08-23 at 11:02 +0530, Srikar Dronamraju wrote:
> > >
> >
> > insn is updated/accessed in the arch independent code. Size of
> > uprobe_opcode_t could be different for different archs.
> > uprobe_opcode_t
> > represents the size of the smalles
On 08/22, Ananth N Mavinakayanahalli wrote:
>
> +int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, struct mm_struct
> *mm, unsigned long addr)
> +{
> + unsigned int insn;
> +
> + if (addr & 0x03)
> + return -EINVAL;
> +
> + memcpy(&insn, auprobe->insn, MAX_UINSN_BYT
On 08/21, Ananth N Mavinakayanahalli wrote:
>
> On Fri, Aug 17, 2012 at 05:00:31PM +0200, Oleg Nesterov wrote:
>
> > > We should also take
> > > care of the in-memory copy, in case gdb had inserted a breakpoint at the
> > > same location, right?
> >
&g
On 08/17, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Aug 16, 2012 at 05:21:12PM +0200, Oleg Nesterov wrote:
>
> > Hmm, I am not sure. is_swbp_insn(insn), as it is used in the arch agnostic
> > code, should only return true if insn == UPROBE_SWBP_INSN (just in case,
>
On 08/16, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Aug 16, 2012 at 07:41:53AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-08-15 at 18:59 +0200, Oleg Nesterov wrote:
> > > On 07/26, Ananth N Mavinakayanahalli wrote:
> > > >
> &g
On 07/26, Ananth N Mavinakayanahalli wrote:
>
> From: Ananth N Mavinakayanahalli
>
> This is the port of uprobes to powerpc. Usage is similar to x86.
I am just curious why this series was ignored by powerpc maintainers...
Of course I can not review this code, I know nothing about powerpc,
but th
On 06/14, Srikar Dronamraju wrote:
>
> * Oleg Nesterov [2012-06-13 21:15:19]:
>
> > For example. Suppose there is some instruction in /lib64/libc.so which
> > is valid for 64-bit, but not for 32-bit.
> >
> > Suppose that a 32-bit application does mmap("/l
1 - 100 of 112 matches
Mail list logo
