Re: [PATCH] Repair misuse of sv_lock in 5.10.16-rt30.

On Fri, Feb 26, 2021 at 03:15:46PM +, Chuck Lever wrote: > > > > On Feb 26, 2021, at 10:00 AM, J. Bruce Fields wrote: > > > > Adding Chuck, linux-nfs. > > > > Makes sense to me.--b. > > Joe, I can add this to nfsd-5.12-rc. Would it be appropriate to add: > > Fixes: 719f8bcc883e

[PATCH] Repair misuse of sv_lock in 5.10.16-rt30.

et a serv->sv_lock -> softirq_ctrl.lock dependency established. Deadlock. Fix is to make serv->sv_lock be locked with spin_lock_bh everywhere, no exceptions. Signed-off-by: Joe Korty [ OK ] Stopped target NFS client services. Stopping Logout off all iSCSI sessions on shutdown...

Re: [ANNOUNCE] v4.4.231-rt202

Ping? On Mon, Jul 27, 2020 at 03:10:33PM -0400, Steven Rostedt wrote: > On Sun, 26 Jul 2020 13:55:12 +0200 > Daniel Wagner wrote: > > > Hi, > > > > On 24.07.20 15:41, Daniel Wagner wrote: > > > Known issues: > > > > > > sigwaittest with hackbench as workload is able to trigger a crash on

Re: [BUG 4.4.178] x86_64 compat mode futexes broken

On Thu, Jun 06, 2019 at 04:11:30PM -0700, Nathan Chancellor wrote: > On Thu, Jun 06, 2019 at 09:11:43PM +0000, Joe Korty wrote: > > Starting with 4.4.178, the LTP test > > > > pthread_cond_wait/2-3 > > > > when compiled on x86_64 with 'gcc -m32', started fai

[BUG 4.4.178] x86_64 compat mode futexes broken

been backported in the first place. Signed-off-by: Joe Korty

Re: [ptrace, rt] erratic behaviour in PTRACE_SINGLESET on 4.13-rt and later.

n I first sent out to the mailing list. Joe PS: Oh, I forgot to do.... Signed-off-by: Joe Korty > On Tue, 20 Nov 2018 12:29:00 -0500 > Steven Rostedt wrote: > > > [ Adding Clark and John who manage the rt-tests repo ] > > > > -- Steve > > > >

Re: [ptrace, rt] erratic behaviour in PTRACE_SINGLESET on 4.13-rt and later.

n I first sent out to the mailing list. Joe PS: Oh, I forgot to do.... Signed-off-by: Joe Korty > On Tue, 20 Nov 2018 12:29:00 -0500 > Steven Rostedt wrote: > > > [ Adding Clark and John who manage the rt-tests repo ] > > > > -- Steve > > > >

[ptrace, rt] erratic behaviour in PTRACE_SINGLESET on 4.13-rt and later.

Hi Julia & the RT team, The following program might make a good addition to the rt test suite. It tests the reliability of PTRACE_SINGLESTEP. It does by default 10,000 ssteps against a simple, spinner tracee. Also by default, it spins off ten of these tracer/tracee pairs, all of which are to

[ptrace, rt] erratic behaviour in PTRACE_SINGLESET on 4.13-rt and later.

Hi Julia & the RT team, The following program might make a good addition to the rt test suite. It tests the reliability of PTRACE_SINGLESTEP. It does by default 10,000 ssteps against a simple, spinner tracee. Also by default, it spins off ten of these tracer/tracee pairs, all of which are to

Re: [PATCH RT v2] sched/migrate_disable: fallback to preempt_disable() instead barrier()

On Fri, Jul 06, 2018 at 12:58:57PM +0200, Sebastian Andrzej Siewior wrote: > On SMP + !RT migrate_disable() is still around. It is not part of spin_lock() > anymore so it has almost no users. However the futex code has a workaround for > the !in_atomic() part of migrate disable which fails because

Re: [PATCH RT v2] sched/migrate_disable: fallback to preempt_disable() instead barrier()

On Fri, Jul 06, 2018 at 12:58:57PM +0200, Sebastian Andrzej Siewior wrote: > On SMP + !RT migrate_disable() is still around. It is not part of spin_lock() > anymore so it has almost no users. However the futex code has a workaround for > the !in_atomic() part of migrate disable which fails because

Re: [PATCH RT] sched/migrate_disable: fallback to preempt_disable() instead barrier()

On Thu, Jul 05, 2018 at 05:50:34PM +0200, Sebastian Andrzej Siewior wrote: > migrate_disable() does nothing !SMP && !RT. This is bad for two reasons: > - The futex code relies on the fact migrate_disable() is part of spin_lock(). > There is a workaround for the !in_atomic() case in

Re: [PATCH RT] sched/migrate_disable: fallback to preempt_disable() instead barrier()

On Thu, Jul 05, 2018 at 05:50:34PM +0200, Sebastian Andrzej Siewior wrote: > migrate_disable() does nothing !SMP && !RT. This is bad for two reasons: > - The futex code relies on the fact migrate_disable() is part of spin_lock(). > There is a workaround for the !in_atomic() case in

[PATCH RT] sample fix for splat in futex_[un]lock_pi for !rt

t releases in which migrate_enable != preempt_enable for !rt kernels. Signed-off-by: Joe Korty Index: b/kernel/futex.c === --- a/kernel/futex.c +++ b/kernel/futex.c @@ -2838,7 +2838,14 @@ retry_private: spin_unlock(

[PATCH RT] sample fix for splat in futex_[un]lock_pi for !rt

t releases in which migrate_enable != preempt_enable for !rt kernels. Signed-off-by: Joe Korty Index: b/kernel/futex.c === --- a/kernel/futex.c +++ b/kernel/futex.c @@ -2838,7 +2838,14 @@ retry_private: spin_unlock(

Re: [PATCH RT] Defer migrate_enable migration while task state != TASK_RUNNING

Oh well. Makes me wonder why might_sleep is testing for !TASK_RUNNABLE though. Thanks for the correction, Joe On Mon, Mar 26, 2018 at 11:35:15AM -0400, Steven Rostedt wrote: > On Fri, 23 Mar 2018 13:21:31 -0400 > joe.ko...@concurrent-rt.com wrote: > > > My understanding is, in standard Linux

Re: [PATCH RT] Defer migrate_enable migration while task state != TASK_RUNNING

Oh well. Makes me wonder why might_sleep is testing for !TASK_RUNNABLE though. Thanks for the correction, Joe On Mon, Mar 26, 2018 at 11:35:15AM -0400, Steven Rostedt wrote: > On Fri, 23 Mar 2018 13:21:31 -0400 > joe.ko...@concurrent-rt.com wrote: > > > My understanding is, in standard Linux

Re: [PATCH RT] Defer migrate_enable migration while task state != TASK_RUNNING

Hi Julia, Thanks for the quick response! On Fri, Mar 23, 2018 at 11:59:21AM -0500, Julia Cartwright wrote: > Hey Joe- > > Thanks for the writeup. > > On Fri, Mar 23, 2018 at 11:09:59AM -0400, joe.ko...@concurrent-rt.com wrote: > > I see the below kernel splat in 4.9-rt when I run a test program

Re: [PATCH RT] Defer migrate_enable migration while task state != TASK_RUNNING

Hi Julia, Thanks for the quick response! On Fri, Mar 23, 2018 at 11:59:21AM -0500, Julia Cartwright wrote: > Hey Joe- > > Thanks for the writeup. > > On Fri, Mar 23, 2018 at 11:09:59AM -0400, joe.ko...@concurrent-rt.com wrote: > > I see the below kernel splat in 4.9-rt when I run a test program

[PATCH RT] Defer migrate_enable migration while task state != TASK_RUNNING

p->migrate_enable_deferred = 1; 38 + } 39 } 40 41 unpin_current_cpu(); EOF The rt patch sched-migrate-disable-handle-updated-task-mask-mg-di.patch appears to have i

[PATCH RT] Defer migrate_enable migration while task state != TASK_RUNNING

;comm); 37 + p->migrate_enable_deferred = 1; 38 + } 39 } 40 41 unpin_current_cpu(); EOF The rt patch sched-migrate-disable-handle-updated-task-mask-mg-di.patch appears to h

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Tue, Nov 28, 2017 at 07:22:34PM -0500, Steven Rostedt wrote: > On Tue, 21 Nov 2017 10:33:17 -0500 > joe.ko...@concurrent-rt.com wrote: > > > On Tue, Nov 21, 2017 at 09:33:52AM -0500, joe.ko...@concurrent-rt.com wrote: > > > On Mon, Nov 20, 2017 at 11:57:51PM -0500, Steven Rostedt wrote: > >

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Tue, Nov 28, 2017 at 07:22:34PM -0500, Steven Rostedt wrote: > On Tue, 21 Nov 2017 10:33:17 -0500 > joe.ko...@concurrent-rt.com wrote: > > > On Tue, Nov 21, 2017 at 09:33:52AM -0500, joe.ko...@concurrent-rt.com wrote: > > > On Mon, Nov 20, 2017 at 11:57:51PM -0500, Steven Rostedt wrote: > >

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Tue, Nov 21, 2017 at 09:33:52AM -0500, joe.ko...@concurrent-rt.com wrote: > On Mon, Nov 20, 2017 at 11:57:51PM -0500, Steven Rostedt wrote: > > On Mon, 20 Nov 2017 23:02:07 -0500 > > Steven Rostedt wrote: > > > > > > > Ideally, I would like to stay close to what upstream

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Tue, Nov 21, 2017 at 09:33:52AM -0500, joe.ko...@concurrent-rt.com wrote: > On Mon, Nov 20, 2017 at 11:57:51PM -0500, Steven Rostedt wrote: > > On Mon, 20 Nov 2017 23:02:07 -0500 > > Steven Rostedt wrote: > > > > > > > Ideally, I would like to stay close to what upstream -rt does. Would > >

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Mon, Nov 20, 2017 at 11:57:51PM -0500, Steven Rostedt wrote: > On Mon, 20 Nov 2017 23:02:07 -0500 > Steven Rostedt wrote: > > > > Ideally, I would like to stay close to what upstream -rt does. Would > > you be able to backport the 4.11-rt patch? > > > > I'm currently

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Mon, Nov 20, 2017 at 11:57:51PM -0500, Steven Rostedt wrote: > On Mon, 20 Nov 2017 23:02:07 -0500 > Steven Rostedt wrote: > > > > Ideally, I would like to stay close to what upstream -rt does. Would > > you be able to backport the 4.11-rt patch? > > > > I'm currently working on releasing

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

t; > > > stmt to schedule() and running a simple affinity rotation > > program I wrote, one that rotates the threads of stress(1). > > While rotating, I got the expected kernel error messages. > > With this patch applied the messages disappeared. > > > > Si

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

t; > > > stmt to schedule() and running a simple affinity rotation > > program I wrote, one that rotates the threads of stress(1). > > While rotating, I got the expected kernel error messages. > > With this patch applied the messages disappeared. > > > > Sig

[PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

(...) stmt to schedule() and running a simple affinity rotation program I wrote, one that rotates the threads of stress(1). While rotating, I got the expected kernel error messages. With this patch applied the messages disappeared. Signed-off-by: Joe Korty <joe.ko...@concurrent-rt.com> Index: b/

[PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

(...) stmt to schedule() and running a simple affinity rotation program I wrote, one that rotates the threads of stress(1). While rotating, I got the expected kernel error messages. With this patch applied the messages disappeared. Signed-off-by: Joe Korty Index: b/kernel/sched/core.c

Re: tunnels: Don't apply GRO to multiple layers of encapsulation.

Hi Sasha, The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971 tunnels: Don't apply GRO to multiple layers of encapsulation into 4.1 missed a hunk. The same backport into 3.18 was done correctly. This patch introduces the missing hunk into 4.1. Excepts from some emails: Joe Korty

Re: tunnels: Don't apply GRO to multiple layers of encapsulation.

Hi Sasha, The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971 tunnels: Don't apply GRO to multiple layers of encapsulation into 4.1 missed a hunk. The same backport into 3.18 was done correctly. This patch introduces the missing hunk into 4.1. Excepts from some emails: Joe Korty

Re: tunnels: Don't apply GRO to multiple layers of encapsulation.

[ resend due to mail problems at my end ] Hi Jesse, The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971, "tunnels: Don't apply GRO to multiple layers of encapsulation", to linux-4.1.y seems to have missed a line. The 4.1 commit is 066b300e5be43cb61697539e2a3a9aac5afb422f. The potentially

Re: tunnels: Don't apply GRO to multiple layers of encapsulation.

[ resend due to mail problems at my end ] Hi Jesse, The backport of fac8e0f579695a3ecbc4d3cac369139d7f819971, "tunnels: Don't apply GRO to multiple layers of encapsulation", to linux-4.1.y seems to have missed a line. The 4.1 commit is 066b300e5be43cb61697539e2a3a9aac5afb422f. The potentially

[PATCH] Fix kfree bug in sendmsg and recvmsg

commit da184284. Signed-off-by: Joe Korty <joe.ko...@ccur.com> Index: b/net/socket.c === --- a/net/socket.c +++ b/net/socket.c @@ -1960,7 +1960,8 @@ out_freectl: if (ctl_buf != ctl) sock_kfree_s(sock->sk

[PATCH] Fix kfree bug in sendmsg and recvmsg

commit da184284. Signed-off-by: Joe Korty Index: b/net/socket.c === --- a/net/socket.c +++ b/net/socket.c @@ -1960,7 +1960,8 @@ out_freectl: if (ctl_buf != ctl) sock_kfree_s(sock->sk, ctl_buf, ctl_

[no subject]

subscribe

[no subject]

subscribe

Re: [ANNOUNCE] 3.12.6-rt9

On Tue, Jan 21, 2014 at 01:39:10AM -0500, Muli Baron wrote: > On 21/1/2014 04:17, Steven Rostedt wrote: > > On Sat, 18 Jan 2014 04:15:29 +0100 > > Mike Galbraith wrote: > > > > > >>> So you also have the timers-do-not-raise-softirq-unconditionally.patch? > >> > > > > People have been complaining

Re: [ANNOUNCE] 3.12.6-rt9

On Tue, Jan 21, 2014 at 01:39:10AM -0500, Muli Baron wrote: On 21/1/2014 04:17, Steven Rostedt wrote: On Sat, 18 Jan 2014 04:15:29 +0100 Mike Galbraith bitbuc...@online.de wrote: So you also have the timers-do-not-raise-softirq-unconditionally.patch? People have been complaining

[PATCH] jrcu-3.6-1

, as well as expand its uses beyond its original parameters (small SMP, large frame). Rewrite based on comments from Andi Kleen on the 3.4-1 version last May. 3.5-1: basic port from 3.4-1, no new functionality added. Signed-off-by: Joe Korty Index: b/kernel/jrcu.c

[PATCH] jrcu-3.6-1

, as well as expand its uses beyond its original parameters (small SMP, large frame). Rewrite based on comments from Andi Kleen on the 3.4-1 version last May. 3.5-1: basic port from 3.4-1, no new functionality added. Signed-off-by: Joe Korty joe.ko...@ccur.com Index: b/kernel/jrcu.c

Re: possible corrections in the docs (Re: [PATCH] [7/50] x86: expand /proc/interrupts to include missing vectors, v2)

Looks good to me. Joe Acked-by: Joe Korty <[EMAIL PROTECTED]> - 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-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: possible corrections in the docs (Re: [PATCH] [7/50] x86: expand /proc/interrupts to include missing vectors, v2)

Looks good to me. Joe Acked-by: Joe Korty [EMAIL PROTECTED] - 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-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Fix section mismatch in the Adaptec DPT SCSI Raid driver

on the failure of a single device? Module exit implies that other, non-failing adaptec raid devices will also get shut down. Signed-off-by: Joe Korty <[EMAIL PROTECTED]> Index: 2.6.23-rc3-git1/drivers/scsi/dpt_i2o.c === ---

[PATCH] Fix section mismatch in the Adaptec DPT SCSI Raid driver

Fix section mismatch in the Adaptec DPT SCSI Raid driver. Signed-off-by: Joe Korty <[EMAIL PROTECTED]> Index: 2.6.23-rc3-git1/drivers/scsi/dpt_i2o.c === --- 2.6.23-rc3-git1.orig/drivers/scsi/dpt_i2o.c 2007-08-17 16:36:05.000

[PATCH] Fix section mismatch in the Adaptec DPT SCSI Raid driver

Fix section mismatch in the Adaptec DPT SCSI Raid driver. Signed-off-by: Joe Korty [EMAIL PROTECTED] Index: 2.6.23-rc3-git1/drivers/scsi/dpt_i2o.c === --- 2.6.23-rc3-git1.orig/drivers/scsi/dpt_i2o.c 2007-08-17 16:36:05.0

Re: [PATCH] Fix section mismatch in the Adaptec DPT SCSI Raid driver

? Module exit implies that other, non-failing adaptec raid devices will also get shut down. Signed-off-by: Joe Korty [EMAIL PROTECTED] Index: 2.6.23-rc3-git1/drivers/scsi/dpt_i2o.c === --- 2.6.23-rc3-git1.orig/drivers/scsi/dpt_i2o.c 2007-08

[PATCH] hres_timers_resume must block interrupts

that users of hres_timers_resume() do the IRQ blocking, this patch makes the blocking part of the hres_timers_resume() functionality. (Also remove the meaningless WARN_ON_ONCE() call in hres_timers_resume) Signed-off-by: Joe Korty ([EMAIL PROTECTED]) Index: 2.6.23-rc3/kernel/hrtimer.c

[PATCH] hres_timers_resume must block interrupts

that users of hres_timers_resume() do the IRQ blocking, this patch makes the blocking part of the hres_timers_resume() functionality. (Also remove the meaningless WARN_ON_ONCE() call in hres_timers_resume) Signed-off-by: Joe Korty ([EMAIL PROTECTED]) Index: 2.6.23-rc3/kernel/hrtimer.c

Re: WARN_ON() which sometimes sucks

On Wed, Aug 01, 2007 at 02:20:48PM +1000, Paul Mackerras wrote: > Linus Torvalds writes: > > > Umm. The WARN_ON() might actually get a "long long" value for all we know. > > Ie it's perfectly possible that the WARN_ON might look like > > > > /* Must not have high bits on */ > >

Re: WARN_ON() which sometimes sucks

On Wed, Aug 01, 2007 at 02:20:48PM +1000, Paul Mackerras wrote: Linus Torvalds writes: Umm. The WARN_ON() might actually get a long long value for all we know. Ie it's perfectly possible that the WARN_ON might look like /* Must not have high bits on */ WARN_ON(offset

[PATCH] expand /proc/interrupts to include missing vectors, v4

. Signed-off-by: Joe Korty <[EMAIL PROTECTED]> Index: 2.6.23-rc1-git7/arch/i386/kernel/apic.c === --- 2.6.23-rc1-git7.orig/arch/i386/kernel/apic.c2007-07-31 16:31:09.0 -0400 +++ 2.6.23-rc1-git7/arch/i386/kernel/

Re: [PATCH] expand /proc/interrupts to include missing vectors, v3

On Tue, Jul 31, 2007 at 07:02:01PM +0200, Andi Kleen wrote: Hi Andi, Thanks for the review. I implemented many of your suggestions and for the rest, here mention why not, in case you want to respond further. Regards, Joe > Joe Korty <[EMAIL PROTECTED]> writes: > > A threshold i

Re: [PATCH] expand /proc/interrupts to include missing vectors, v3

flooding. Signed-off-by: Joe Korty <[EMAIL PROTECTED]> Index: 2.6.23-rc1-git7/arch/i386/kernel/apic.c === --- 2.6.23-rc1-git7.orig/arch/i386/kernel/apic.c2007-07-30 19:08:05.0 -0400 +++ 2.6.23-rc1-git7/arch/i386/

Re: [PATCH] expand /proc/interrupts to include missing vectors, v3

flooding. Signed-off-by: Joe Korty [EMAIL PROTECTED] Index: 2.6.23-rc1-git7/arch/i386/kernel/apic.c === --- 2.6.23-rc1-git7.orig/arch/i386/kernel/apic.c2007-07-30 19:08:05.0 -0400 +++ 2.6.23-rc1-git7/arch/i386/kernel

Re: [PATCH] expand /proc/interrupts to include missing vectors, v3

On Tue, Jul 31, 2007 at 07:02:01PM +0200, Andi Kleen wrote: Hi Andi, Thanks for the review. I implemented many of your suggestions and for the rest, here mention why not, in case you want to respond further. Regards, Joe Joe Korty [EMAIL PROTECTED] writes: A threshold interrupt occurs when

[PATCH] expand /proc/interrupts to include missing vectors, v4

. Signed-off-by: Joe Korty [EMAIL PROTECTED] Index: 2.6.23-rc1-git7/arch/i386/kernel/apic.c === --- 2.6.23-rc1-git7.orig/arch/i386/kernel/apic.c2007-07-31 16:31:09.0 -0400 +++ 2.6.23-rc1-git7/arch/i386/kernel/apic.c

[PATCH] expand /proc/interrupts to include missing vectors, v2

the APIC hardware will assume a vector of 0xff. Rescheduling, call, and TLB flush interrupts are sent from one CPU to another per the needs of the OS. Typically, their statistics would be used to discover if an interrupt flood of the given type has been occuring. Signed-off-by: Joe Korty <[EM

Re: [PATCH] create /proc/all-interrupts

On Mon, Jul 30, 2007 at 12:32:06PM -0700, Andrew Morton wrote: > On Mon, 30 Jul 2007 10:33:17 -0700 > Sven-Thorsten Dietrich <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-07-26 at 11:56 -0700, H. Peter Anvin wrote: > > > Joe Korty wrote: > > > > Create /pro

Re: [PATCH] create /proc/all-interrupts

On Mon, Jul 30, 2007 at 12:32:06PM -0700, Andrew Morton wrote: On Mon, 30 Jul 2007 10:33:17 -0700 Sven-Thorsten Dietrich [EMAIL PROTECTED] wrote: On Thu, 2007-07-26 at 11:56 -0700, H. Peter Anvin wrote: Joe Korty wrote: Create /proc/all-interrupts for some architectures. Would

[PATCH] expand /proc/interrupts to include missing vectors, v2

the APIC hardware will assume a vector of 0xff. Rescheduling, call, and TLB flush interrupts are sent from one CPU to another per the needs of the OS. Typically, their statistics would be used to discover if an interrupt flood of the given type has been occuring. Signed-off-by: Joe Korty [EMAIL

[PATCH] create /proc/all-interrupts

longstanding script. However, these kinds of changes traditionally do not affect scripts, so it might be reasonable to fold /proc/all-interrupts back into /proc/interrupts. Signed-off-by: Joe Korty <[EMAIL PROTECTED]> Index: 2.6.22.1-rt8/arch/i386/kernel/

[PATCH] create /proc/all-interrupts

longstanding script. However, these kinds of changes traditionally do not affect scripts, so it might be reasonable to fold /proc/all-interrupts back into /proc/interrupts. Signed-off-by: Joe Korty [EMAIL PROTECTED] Index: 2.6.22.1-rt8/arch/i386/kernel/apic.c

Re: [PATCH 1/2] PTRACE_PEEKDATA consolidation

On Tue, Jun 12, 2007 at 12:52:25AM +0400, Alexey Dobriyan wrote: > On Mon, Jun 11, 2007 at 09:35:17PM +0100, Christoph Hellwig wrote: > > On Tue, Jun 12, 2007 at 12:40:06AM +0400, Alexey Dobriyan wrote: > > > Identical implementations of PTRACE_PEEKDATA go into > > > simple_ptrace_peekdata()

Re: [PATCH 1/2] PTRACE_PEEKDATA consolidation

On Tue, Jun 12, 2007 at 12:52:25AM +0400, Alexey Dobriyan wrote: On Mon, Jun 11, 2007 at 09:35:17PM +0100, Christoph Hellwig wrote: On Tue, Jun 12, 2007 at 12:40:06AM +0400, Alexey Dobriyan wrote: Identical implementations of PTRACE_PEEKDATA go into simple_ptrace_peekdata() function.

add_timer_on and CONFIG_NO_HZ

Hi Thomas, It seems that when add_timer_on() is used to put a timer on another cpu's timer queue, that remote cpu should be made to reprogram its hardware APIC timer, when CONFIG_NO_HZ=y and the new timer is put at the front of the timer wheel. Regards, Joe - To unsubscribe from this list: send

add_timer_on and CONFIG_NO_HZ

Hi Thomas, It seems that when add_timer_on() is used to put a timer on another cpu's timer queue, that remote cpu should be made to reprogram its hardware APIC timer, when CONFIG_NO_HZ=y and the new timer is put at the front of the timer wheel. Regards, Joe - To unsubscribe from this list: send

Re: FW: [RFC] A more general timeout specification

On Thu, Sep 01, 2005 at 04:32:49PM +0200, Roman Zippel wrote: > On Thu, 1 Sep 2005, Joe Korty wrote: > > Kernel time sucks. It is just a single clock, it may not have > > the attributes of the clock that the user really wished to use. > > Wrong. The kernel time is

Re: FW: [RFC] A more general timeout specification

On Thu, Sep 01, 2005 at 01:50:33AM +0200, Roman Zippel wrote: > When you convert a user time to kernel time you can > automatically validate Kernel time sucks. It is just a single clock, it may not have the attributes of the clock that the user really wished to use. Joe - To unsubscribe from

Re: FW: [RFC] A more general timeout specification

On Thu, Sep 01, 2005 at 11:22:32AM +0200, Roman Zippel wrote: > For a timeout? Please get real. > If you need more precision, use a dedicated timer API, but don't make the > general case more complex for the 99.99% of other users. Struct timeout is just a struct timespec + a bit for

Re: FW: [RFC] A more general timeout specification

On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote: > You still didn't explain what's the point in choosing > different clock sources for a _timeout_. Well, if CLOCK_REALTIME is set forward by a minute, timers & timeout specified against that clock will expire a minute earlier than

Re: FW: [RFC] A more general timeout specification

On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote: You still didn't explain what's the point in choosing different clock sources for a _timeout_. Well, if CLOCK_REALTIME is set forward by a minute, timers timeout specified against that clock will expire a minute earlier than

Re: FW: [RFC] A more general timeout specification

On Thu, Sep 01, 2005 at 11:22:32AM +0200, Roman Zippel wrote: For a timeout? Please get real. If you need more precision, use a dedicated timer API, but don't make the general case more complex for the 99.99% of other users. Struct timeout is just a struct timespec + a bit for

Re: FW: [RFC] A more general timeout specification

On Thu, Sep 01, 2005 at 01:50:33AM +0200, Roman Zippel wrote: When you convert a user time to kernel time you can automatically validate Kernel time sucks. It is just a single clock, it may not have the attributes of the clock that the user really wished to use. Joe - To unsubscribe from this

Re: FW: [RFC] A more general timeout specification

On Thu, Sep 01, 2005 at 04:32:49PM +0200, Roman Zippel wrote: On Thu, 1 Sep 2005, Joe Korty wrote: Kernel time sucks. It is just a single clock, it may not have the attributes of the clock that the user really wished to use. Wrong. The kernel time is simple and effective for almost all

Re: FW: [RFC] A more general timeout specification

On Wed, Aug 31, 2005 at 03:20:03PM -0600, Christopher Friesen wrote: > Perez-Gonzalez, Inaky wrote: > >In this structure, > >the user specifies: > >whether the time is absolute, or relative to 'now'. > > > >Timeout_sleep has a return argument, endtime, which is also in > >'struct timeout'

Re: FW: [RFC] A more general timeout specification

On Wed, Aug 31, 2005 at 01:55:54PM -0700, Perez-Gonzalez, Inaky wrote: > Hi Andrew > > This was developed by Joe Korty <[EMAIL PROTECTED]>, greatly > enhancing something I had done before, so I am signing it out > (although Joe should too, Joe?). The fusyn (robust mute

Re: FW: [RFC] A more general timeout specification

On Wed, Aug 31, 2005 at 01:55:54PM -0700, Perez-Gonzalez, Inaky wrote: Hi Andrew This was developed by Joe Korty [EMAIL PROTECTED], greatly enhancing something I had done before, so I am signing it out (although Joe should too, Joe?). The fusyn (robust mutexes) project proposes

Re: FW: [RFC] A more general timeout specification

On Wed, Aug 31, 2005 at 03:20:03PM -0600, Christopher Friesen wrote: Perez-Gonzalez, Inaky wrote: In this structure, the user specifies: whether the time is absolute, or relative to 'now'. Timeout_sleep has a return argument, endtime, which is also in 'struct timeout' format. If the

[PATCH] add EOWNERDEAD and ENOTRECOVERABLE version 2

-by: Joe Korty <[EMAIL PROTECTED]> 2.6.12-rc2-jak/include/asm-alpha/errno.h |4 2.6.12-rc2-jak/include/asm-generic/errno.h |4 2.6.12-rc2-jak/include/asm-mips/errno.h|4 2.6.12-rc2-jak/include/asm-parisc/errno.h |4 2.6.12-rc2-jak/include/asm-sparc/e

[PATCH] add EOWNERDEAD and ENOTRECOVERABLE version 2

-by: Joe Korty [EMAIL PROTECTED] 2.6.12-rc2-jak/include/asm-alpha/errno.h |4 2.6.12-rc2-jak/include/asm-generic/errno.h |4 2.6.12-rc2-jak/include/asm-mips/errno.h|4 2.6.12-rc2-jak/include/asm-parisc/errno.h |4 2.6.12-rc2-jak/include/asm-sparc/errno.h

Re: FUSYN and RT

On Tue, Apr 12, 2005 at 11:15:02AM -0700, Daniel Walker wrote: > It seems like these two locks are going to interact on a very limited > basis. Fusyn will be the user space mutex, and the RT mutex is only in > the kernel. You can't lock an RT mutex and hold it, then lock a Fusyn > mutex (anyone

[PATCH] add EOWNERDEAD and ENOTRECOVERABLE

tested. Signed-off-by: Joe Korty <[EMAIL PROTECTED]> 2.6.12-rc2-jak/include/asm-alpha/errno.h |3 +++ 2.6.12-rc2-jak/include/asm-generic/errno.h |3 +++ 2.6.12-rc2-jak/include/asm-mips/errno.h|3 +++ 2.6.12-rc2-jak/include/asm-parisc/errno.h |3 +++ 2.6.12-rc2-jak/inclu

[PATCH] add EOWNERDEAD and ENOTRECOVERABLE

tested. Signed-off-by: Joe Korty [EMAIL PROTECTED] 2.6.12-rc2-jak/include/asm-alpha/errno.h |3 +++ 2.6.12-rc2-jak/include/asm-generic/errno.h |3 +++ 2.6.12-rc2-jak/include/asm-mips/errno.h|3 +++ 2.6.12-rc2-jak/include/asm-parisc/errno.h |3 +++ 2.6.12-rc2-jak/include/asm

Re: FUSYN and RT

On Tue, Apr 12, 2005 at 11:15:02AM -0700, Daniel Walker wrote: It seems like these two locks are going to interact on a very limited basis. Fusyn will be the user space mutex, and the RT mutex is only in the kernel. You can't lock an RT mutex and hold it, then lock a Fusyn mutex (anyone

Re: x86 TSC time warp puzzle

On Mon, Apr 04, 2005 at 09:59:22AM +0100, [EMAIL PROTECTED] wrote: > Jonathan Lundell wrote: > >Well, not actually a time warp, though it feels like one. > > > >I'm doing some real-time bit-twiddling in a driver, using the TSC to > >measure out delays on the order of hundreds of nanoseconds.

Re: x86 TSC time warp puzzle

On Mon, Apr 04, 2005 at 09:59:22AM +0100, [EMAIL PROTECTED] wrote: Jonathan Lundell wrote: Well, not actually a time warp, though it feels like one. I'm doing some real-time bit-twiddling in a driver, using the TSC to measure out delays on the order of hundreds of nanoseconds. Because I

Re: [PATCH/RFC] Futex mmap_sem deadlock

On Tue, Feb 22, 2005 at 01:30:27PM -0800, Linus Torvalds wrote: > > We really have this already, and it's called "current->preempt". It > handles any lock at all, and doesn't add yet another special case to all > the architectures. > > Just do > > repeat: >

Re: [PATCH/RFC] Futex mmap_sem deadlock

On Tue, Feb 22, 2005 at 01:30:27PM -0800, Linus Torvalds wrote: We really have this already, and it's called current-preempt. It handles any lock at all, and doesn't add yet another special case to all the architectures. Just do repeat:

memset argument order misuses

Hi Andrew, A simple 'grep memset.*\<0);' shows argument order errors in several uses of memset. This grep was inspired by Al Viro's recent patch, megaraid_mbox fix, which fixed this problem in the megaraid driver. Completely untested. Regards, Joe -- "Money can buy bandwidth, but latency is

memset argument order misuses

Hi Andrew, A simple 'grep memset.*\0);' shows argument order errors in several uses of memset. This grep was inspired by Al Viro's recent patch, megaraid_mbox fix, which fixed this problem in the megaraid driver. Completely untested. Regards, Joe -- Money can buy bandwidth, but latency is