On Wed, 18 Jun 2014, Steven Rostedt wrote:
> On Wed, 18 Jun 2014 18:43:59 +0200
> Oleg Nesterov wrote:
>
>
> > And (contrary to what I said initially) we can rely on this because -rt
> > converts spinlock_t into rt_mutex ?
>
> Correct. Because if spinlock_t has this behavior, rt_mutex must
On Wed, 18 Jun 2014, Steven Rostedt wrote:
On Wed, 18 Jun 2014 18:43:59 +0200
Oleg Nesterov o...@redhat.com wrote:
And (contrary to what I said initially) we can rely on this because -rt
converts spinlock_t into rt_mutex ?
Correct. Because if spinlock_t has this behavior, rt_mutex
On Wed, Jun 18, 2014 at 06:43:59PM +0200, Oleg Nesterov wrote:
> On 06/17, Paul E. McKenney wrote:
> >
> > + if (drop_boost_mutex) {
> > + rt_mutex_unlock(>boost_mtx);
> > complete(>boost_completion);
>
> Well, I still do not understand this
On Wed, 18 Jun 2014 18:43:59 +0200
Oleg Nesterov wrote:
> And (contrary to what I said initially) we can rely on this because -rt
> converts spinlock_t into rt_mutex ?
Correct. Because if spinlock_t has this behavior, rt_mutex must have it
too, otherwise -rt will suffer greatly from that. Who
On 06/17, Paul E. McKenney wrote:
>
> + if (drop_boost_mutex) {
> + rt_mutex_unlock(>boost_mtx);
> complete(>boost_completion);
Well, I still do not understand this ->boost_completion...
> - /* Wait until boostee is done accessing mtx
On 06/17, Paul E. McKenney wrote:
+ if (drop_boost_mutex) {
+ rt_mutex_unlock(rnp-boost_mtx);
complete(rnp-boost_completion);
Well, I still do not understand this -boost_completion...
- /* Wait until boostee is done accessing mtx
On Wed, 18 Jun 2014 18:43:59 +0200
Oleg Nesterov o...@redhat.com wrote:
And (contrary to what I said initially) we can rely on this because -rt
converts spinlock_t into rt_mutex ?
Correct. Because if spinlock_t has this behavior, rt_mutex must have it
too, otherwise -rt will suffer greatly
On Wed, Jun 18, 2014 at 06:43:59PM +0200, Oleg Nesterov wrote:
On 06/17, Paul E. McKenney wrote:
+ if (drop_boost_mutex) {
+ rt_mutex_unlock(rnp-boost_mtx);
complete(rnp-boost_completion);
Well, I still do not understand this
On Sat, Jun 14, 2014 at 10:40:58PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 13, 2014 at 05:08:30PM +0200, Oleg Nesterov wrote:
> > On 06/12, Paul E. McKenney wrote:
> > >
> > > @@ -398,11 +399,9 @@ void rcu_read_unlock_special(struct task_struct *t)
> > > #ifdef CONFIG_RCU_BOOST
> > >
On Sat, Jun 14, 2014 at 10:40:58PM -0700, Paul E. McKenney wrote:
On Fri, Jun 13, 2014 at 05:08:30PM +0200, Oleg Nesterov wrote:
On 06/12, Paul E. McKenney wrote:
@@ -398,11 +399,9 @@ void rcu_read_unlock_special(struct task_struct *t)
#ifdef CONFIG_RCU_BOOST
if
On Fri, Jun 13, 2014 at 05:08:30PM +0200, Oleg Nesterov wrote:
> On 06/12, Paul E. McKenney wrote:
> >
> > @@ -398,11 +399,9 @@ void rcu_read_unlock_special(struct task_struct *t)
> > #ifdef CONFIG_RCU_BOOST
> > if (>rcu_node_entry == rnp->boost_tasks)
> >
On Fri, Jun 13, 2014 at 05:08:30PM +0200, Oleg Nesterov wrote:
On 06/12, Paul E. McKenney wrote:
@@ -398,11 +399,9 @@ void rcu_read_unlock_special(struct task_struct *t)
#ifdef CONFIG_RCU_BOOST
if (t-rcu_node_entry == rnp-boost_tasks)
rnp-boost_tasks =
On 06/13, Thomas Gleixner wrote:
>
> On Fri, 13 Jun 2014, Oleg Nesterov wrote:
>
> > Perhaps you can look at http://marc.info/?t=14020737023 ?
>
> Looks good. Should I queue it with the other rtmutex stuff?
That would be great, thanks ;)
Oleg.
--
To unsubscribe from this list: send the line
On Fri, 13 Jun 2014, Oleg Nesterov wrote:
> On 06/12, Thomas Gleixner wrote:
> >
> > Just FYI, I have a patch pending which makes the release safe.
> >
> > http://marc.info/?l=linux-kernel=140251240630730=2
>
> Aha, great. I didn't see this version, and just in case I think it is fine.
>
On 06/12, Paul E. McKenney wrote:
>
> @@ -398,11 +399,9 @@ void rcu_read_unlock_special(struct task_struct *t)
> #ifdef CONFIG_RCU_BOOST
> if (>rcu_node_entry == rnp->boost_tasks)
> rnp->boost_tasks = np;
> - /* Snapshot/clear ->rcu_boost_mutex with
On 06/12, Thomas Gleixner wrote:
>
> Just FYI, I have a patch pending which makes the release safe.
>
> http://marc.info/?l=linux-kernel=140251240630730=2
Aha, great. I didn't see this version, and just in case I think it is fine.
Perhaps you can look at http://marc.info/?t=14020737023
On 06/12, Paul E. McKenney wrote:
>
> On Thu, Jun 12, 2014 at 07:28:44PM +0200, Oleg Nesterov wrote:
> > On 06/11, Paul E. McKenney wrote:
> > >
> > > On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
> > > > On 06/11, Paul E. McKenney wrote:
> > > > >
> > > > > I was thinking of
On 06/12, Paul E. McKenney wrote:
On Thu, Jun 12, 2014 at 07:28:44PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
I was thinking of -boost_completion as the way
On 06/12, Thomas Gleixner wrote:
Just FYI, I have a patch pending which makes the release safe.
http://marc.info/?l=linux-kernelm=140251240630730w=2
Aha, great. I didn't see this version, and just in case I think it is fine.
Perhaps you can look at http://marc.info/?t=14020737023 ?
On 06/12, Paul E. McKenney wrote:
@@ -398,11 +399,9 @@ void rcu_read_unlock_special(struct task_struct *t)
#ifdef CONFIG_RCU_BOOST
if (t-rcu_node_entry == rnp-boost_tasks)
rnp-boost_tasks = np;
- /* Snapshot/clear -rcu_boost_mutex with
On Fri, 13 Jun 2014, Oleg Nesterov wrote:
On 06/12, Thomas Gleixner wrote:
Just FYI, I have a patch pending which makes the release safe.
http://marc.info/?l=linux-kernelm=140251240630730w=2
Aha, great. I didn't see this version, and just in case I think it is fine.
Perhaps
On 06/13, Thomas Gleixner wrote:
On Fri, 13 Jun 2014, Oleg Nesterov wrote:
Perhaps you can look at http://marc.info/?t=14020737023 ?
Looks good. Should I queue it with the other rtmutex stuff?
That would be great, thanks ;)
Oleg.
--
To unsubscribe from this list: send the line
On Thu, Jun 12, 2014 at 03:27:48PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 12, 2014 at 11:40:07PM +0200, Thomas Gleixner wrote:
[ . . . ]
> > True. Why should we have users if we would test the crap we produce?
>
> Well, it seems to be passing initial tests as well. Must be my tests
>
On Thu, Jun 12, 2014 at 11:40:07PM +0200, Thomas Gleixner wrote:
> On Thu, 12 Jun 2014, Paul E. McKenney wrote:
> > On Thu, Jun 12, 2014 at 07:28:44PM +0200, Oleg Nesterov wrote:
> > > On 06/11, Paul E. McKenney wrote:
> > > >
> > > > On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
On Thu, 12 Jun 2014, Paul E. McKenney wrote:
> On Thu, Jun 12, 2014 at 07:28:44PM +0200, Oleg Nesterov wrote:
> > On 06/11, Paul E. McKenney wrote:
> > >
> > > On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
> > > > On 06/11, Paul E. McKenney wrote:
> > > > >
> > > > > I was
On Thu, Jun 12, 2014 at 07:28:44PM +0200, Oleg Nesterov wrote:
> On 06/11, Paul E. McKenney wrote:
> >
> > On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
> > > On 06/11, Paul E. McKenney wrote:
> > > >
> > > > I was thinking of ->boost_completion as the way to solve it easily, but
On 06/11, Paul E. McKenney wrote:
>
> On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
> > On 06/11, Paul E. McKenney wrote:
> > >
> > > I was thinking of ->boost_completion as the way to solve it easily, but
> > > what did you have in mind?
> >
> > I meant, rcu_boost() could
On 06/11, Paul E. McKenney wrote:
On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
I was thinking of -boost_completion as the way to solve it easily, but
what did you have in mind?
I meant, rcu_boost() could probably just do
On Thu, Jun 12, 2014 at 07:28:44PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
I was thinking of -boost_completion as the way to solve it easily, but
what did you
On Thu, 12 Jun 2014, Paul E. McKenney wrote:
On Thu, Jun 12, 2014 at 07:28:44PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
I was thinking of -boost_completion
On Thu, Jun 12, 2014 at 11:40:07PM +0200, Thomas Gleixner wrote:
On Thu, 12 Jun 2014, Paul E. McKenney wrote:
On Thu, Jun 12, 2014 at 07:28:44PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
On 06/11,
On Thu, Jun 12, 2014 at 03:27:48PM -0700, Paul E. McKenney wrote:
On Thu, Jun 12, 2014 at 11:40:07PM +0200, Thomas Gleixner wrote:
[ . . . ]
True. Why should we have users if we would test the crap we produce?
Well, it seems to be passing initial tests as well. Must be my tests
need more
On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
> On 06/11, Paul E. McKenney wrote:
> >
> > On Wed, Jun 11, 2014 at 07:17:34PM +0200, Oleg Nesterov wrote:
> > > On 06/11, Oleg Nesterov wrote:
> > > >
> > > > On 06/11, Paul E. McKenney wrote:
> > > >
> > > > >
On 06/11, Paul E. McKenney wrote:
>
> On Wed, Jun 11, 2014 at 07:17:34PM +0200, Oleg Nesterov wrote:
> > On 06/11, Oleg Nesterov wrote:
> > >
> > > On 06/11, Paul E. McKenney wrote:
> > >
> > > > raw_spin_unlock_irqrestore(>lock, flags);
> > > > rt_mutex_lock(); /* Side effect:
On Wed, Jun 11, 2014 at 07:17:34PM +0200, Oleg Nesterov wrote:
> On 06/11, Oleg Nesterov wrote:
> >
> > On 06/11, Paul E. McKenney wrote:
> >
> > > raw_spin_unlock_irqrestore(>lock, flags);
> > > rt_mutex_lock(); /* Side effect: boosts task t's priority. */
> > > rt_mutex_unlock(); /* Keep
On Wed, Jun 11, 2014 at 07:07:05PM +0200, Oleg Nesterov wrote:
> On 06/11, Paul E. McKenney wrote:
> >
> > @@ -1202,10 +1204,14 @@ static int rcu_boost(struct rcu_node *rnp)
> > t = container_of(tb, struct task_struct, rcu_node_entry);
> > rt_mutex_init_proxy_locked(, t);
> >
On 06/11, Oleg Nesterov wrote:
>
> On 06/11, Paul E. McKenney wrote:
>
> > raw_spin_unlock_irqrestore(>lock, flags);
> > rt_mutex_lock(); /* Side effect: boosts task t's priority. */
> > rt_mutex_unlock(); /* Keep lockdep happy. */
> >
> > + /* Wait until boostee is done accessing
On 06/11, Paul E. McKenney wrote:
>
> @@ -1202,10 +1204,14 @@ static int rcu_boost(struct rcu_node *rnp)
> t = container_of(tb, struct task_struct, rcu_node_entry);
> rt_mutex_init_proxy_locked(, t);
> t->rcu_boost_mutex =
> + init_completion(>boost_completion);
can't
On Tue, Jun 10, 2014 at 10:13:20PM +0200, Thomas Gleixner wrote:
> On Tue, 10 Jun 2014, Thomas Gleixner wrote:
> > On Tue, 10 Jun 2014, Steven Rostedt wrote:
> > > On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
> > > Thomas Gleixner wrote:
> > >
> > >
> > > > > Perhaps it could simply do ->owner =
On Tue, Jun 10, 2014 at 10:13:20PM +0200, Thomas Gleixner wrote:
On Tue, 10 Jun 2014, Thomas Gleixner wrote:
On Tue, 10 Jun 2014, Steven Rostedt wrote:
On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
Perhaps it could simply do -owner =
On 06/11, Paul E. McKenney wrote:
@@ -1202,10 +1204,14 @@ static int rcu_boost(struct rcu_node *rnp)
t = container_of(tb, struct task_struct, rcu_node_entry);
rt_mutex_init_proxy_locked(mtx, t);
t-rcu_boost_mutex = mtx;
+ init_completion(rnp-boost_completion);
can't
On 06/11, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
raw_spin_unlock_irqrestore(rnp-lock, flags);
rt_mutex_lock(mtx); /* Side effect: boosts task t's priority. */
rt_mutex_unlock(mtx); /* Keep lockdep happy. */
+ /* Wait until boostee is done accessing mtx
On Wed, Jun 11, 2014 at 07:07:05PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
@@ -1202,10 +1204,14 @@ static int rcu_boost(struct rcu_node *rnp)
t = container_of(tb, struct task_struct, rcu_node_entry);
rt_mutex_init_proxy_locked(mtx, t);
t-rcu_boost_mutex
On Wed, Jun 11, 2014 at 07:17:34PM +0200, Oleg Nesterov wrote:
On 06/11, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
raw_spin_unlock_irqrestore(rnp-lock, flags);
rt_mutex_lock(mtx); /* Side effect: boosts task t's priority. */
rt_mutex_unlock(mtx); /* Keep
On 06/11, Paul E. McKenney wrote:
On Wed, Jun 11, 2014 at 07:17:34PM +0200, Oleg Nesterov wrote:
On 06/11, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
raw_spin_unlock_irqrestore(rnp-lock, flags);
rt_mutex_lock(mtx); /* Side effect: boosts task t's
On Wed, Jun 11, 2014 at 07:59:34PM +0200, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
On Wed, Jun 11, 2014 at 07:17:34PM +0200, Oleg Nesterov wrote:
On 06/11, Oleg Nesterov wrote:
On 06/11, Paul E. McKenney wrote:
raw_spin_unlock_irqrestore(rnp-lock,
On Tue, 10 Jun 2014, Thomas Gleixner wrote:
> On Tue, 10 Jun 2014, Steven Rostedt wrote:
> > On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> >
> > > > Perhaps it could simply do ->owner = RT_MUTEX_HAS_WAITERS to make this
> > > > more
> > > > clear...
> > >
> > >
On Tue, 10 Jun 2014, Steven Rostedt wrote:
> On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
> Thomas Gleixner wrote:
>
>
> > > Perhaps it could simply do ->owner = RT_MUTEX_HAS_WAITERS to make this
> > > more
> > > clear...
> >
> > Good point. The new owner can cleanup the mess.
> >
>
> I
On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
Thomas Gleixner wrote:
> > Perhaps it could simply do ->owner = RT_MUTEX_HAS_WAITERS to make this more
> > clear...
>
> Good point. The new owner can cleanup the mess.
>
I thought about this too. It should work with the added overhead that
every
On Tue, 10 Jun 2014, Oleg Nesterov wrote:
> On 06/10, Thomas Gleixner wrote:
> >
> > On Mon, 9 Jun 2014, Steven Rostedt wrote:
> > > I think rtmutex has an
> > > issue with it too. Specifically in the slow_unlock case:
> > >
> > > if (!rt_mutex_has_waiters(lock)) {
> > > lock->owner =
On Tue, 10 Jun 2014, Oleg Nesterov wrote:
> On 06/10, Thomas Gleixner wrote:
> >
> > +static inline bool unlock_rt_mutex_safe(struct rt_mutex *lock)
> > + __releases(lock->wait_lock)
> > +{
> > + unsigned long owner, *p = (unsigned long *) >owner;
> > +
> > + owner = (unsigned long)
On 06/10, Thomas Gleixner wrote:
>
> +static inline bool unlock_rt_mutex_safe(struct rt_mutex *lock)
> + __releases(lock->wait_lock)
> +{
> + unsigned long owner, *p = (unsigned long *) >owner;
> +
> + owner = (unsigned long) rt_mutex_owner(lock);
> + clear_rt_mutex_waiters(lock);
On 06/10, Thomas Gleixner wrote:
>
> On Mon, 9 Jun 2014, Steven Rostedt wrote:
> > I think rtmutex has an
> > issue with it too. Specifically in the slow_unlock case:
> >
> > if (!rt_mutex_has_waiters(lock)) {
> > lock->owner = NULL;
> > raw_spin_unlock(>wait_lock);
> >
On Tue, Jun 10, 2014 at 08:35:53AM -0700, Linus Torvalds wrote:
> On Tue, Jun 10, 2014 at 5:56 AM, Paul E. McKenney
> wrote:
> >
> > So to safely free a structure containing a mutex, is there some better
> > approach than the following?
>
> Yes.
>
> A data structure *containing* a mutex is
On Tue, Jun 10, 2014 at 5:56 AM, Paul E. McKenney
wrote:
>
> So to safely free a structure containing a mutex, is there some better
> approach than the following?
Yes.
A data structure *containing* a mutex is fine. The problem only occurs
when that mutex also acts the lock for the data
On Tue, Jun 10, 2014 at 07:36:32AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 10, 2014 at 03:01:38PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 10, 2014 at 05:52:35AM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 10, 2014 at 10:37:26AM +0200, Peter Zijlstra wrote:
> > > > On Mon, Jun 09,
On Tue, Jun 10, 2014 at 04:48:30PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 10, 2014 at 05:56:55AM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 09, 2014 at 11:51:09AM -0700, Linus Torvalds wrote:
>
> > > This is subtle, and it is basically unavoidable. If a mutex (or
> > > counting semaphore)
On Tue, Jun 10, 2014 at 05:56:55AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 09, 2014 at 11:51:09AM -0700, Linus Torvalds wrote:
> > This is subtle, and it is basically unavoidable. If a mutex (or
> > counting semaphore) has a fast-path - and a mutex/semaphore without a
> > fast-path is shit -
On Tue, Jun 10, 2014 at 03:01:38PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 10, 2014 at 05:52:35AM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 10, 2014 at 10:37:26AM +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 09, 2014 at 09:26:13AM -0700, Paul E. McKenney wrote:
> > > > That would indeed
On Tue, Jun 10, 2014 at 05:52:35AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 10, 2014 at 10:37:26AM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 09, 2014 at 09:26:13AM -0700, Paul E. McKenney wrote:
> > > That would indeed be a bad thing, as it could potentially lead to
> > > use-after-free
On Mon, Jun 09, 2014 at 11:51:09AM -0700, Linus Torvalds wrote:
> On Mon, Jun 9, 2014 at 11:29 AM, Steven Rostedt wrote:
> >>
> >> And once again, note that the normal mutex is already unsafe (unless I
> >> missed
> >> something).
> >
> > Is it unsafe?
> >
> > This thread was started because of
On Tue, Jun 10, 2014 at 10:37:26AM +0200, Peter Zijlstra wrote:
> On Mon, Jun 09, 2014 at 09:26:13AM -0700, Paul E. McKenney wrote:
> > That would indeed be a bad thing, as it could potentially lead to
> > use-after-free bugs. Though one could argue that any code that resulted
> > in
On Mon, 9 Jun 2014, Steven Rostedt wrote:
> On Mon, 9 Jun 2014 11:51:09 -0700
> Linus Torvalds wrote:
> Because spinlocks are atomic, this is all fine, but if you have a
> mutex, then this is where you can have issues. I think rtmutex has an
> issue with it too. Specifically in the slow_unlock
On Mon, Jun 09, 2014 at 09:26:13AM -0700, Paul E. McKenney wrote:
> That would indeed be a bad thing, as it could potentially lead to
> use-after-free bugs. Though one could argue that any code that resulted
> in use-after-free would be quite aggressive. But still...
Let me hijack this thread
On Mon, Jun 09, 2014 at 09:26:13AM -0700, Paul E. McKenney wrote:
That would indeed be a bad thing, as it could potentially lead to
use-after-free bugs. Though one could argue that any code that resulted
in use-after-free would be quite aggressive. But still...
Let me hijack this thread for
On Mon, 9 Jun 2014, Steven Rostedt wrote:
On Mon, 9 Jun 2014 11:51:09 -0700
Linus Torvalds torva...@linux-foundation.org wrote:
Because spinlocks are atomic, this is all fine, but if you have a
mutex, then this is where you can have issues. I think rtmutex has an
issue with it too.
On Tue, Jun 10, 2014 at 10:37:26AM +0200, Peter Zijlstra wrote:
On Mon, Jun 09, 2014 at 09:26:13AM -0700, Paul E. McKenney wrote:
That would indeed be a bad thing, as it could potentially lead to
use-after-free bugs. Though one could argue that any code that resulted
in use-after-free
On Mon, Jun 09, 2014 at 11:51:09AM -0700, Linus Torvalds wrote:
On Mon, Jun 9, 2014 at 11:29 AM, Steven Rostedt rost...@goodmis.org wrote:
And once again, note that the normal mutex is already unsafe (unless I
missed
something).
Is it unsafe?
This thread was started because of a
On Tue, Jun 10, 2014 at 05:52:35AM -0700, Paul E. McKenney wrote:
On Tue, Jun 10, 2014 at 10:37:26AM +0200, Peter Zijlstra wrote:
On Mon, Jun 09, 2014 at 09:26:13AM -0700, Paul E. McKenney wrote:
That would indeed be a bad thing, as it could potentially lead to
use-after-free bugs.
On Tue, Jun 10, 2014 at 03:01:38PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 05:52:35AM -0700, Paul E. McKenney wrote:
On Tue, Jun 10, 2014 at 10:37:26AM +0200, Peter Zijlstra wrote:
On Mon, Jun 09, 2014 at 09:26:13AM -0700, Paul E. McKenney wrote:
That would indeed be a bad
On Tue, Jun 10, 2014 at 05:56:55AM -0700, Paul E. McKenney wrote:
On Mon, Jun 09, 2014 at 11:51:09AM -0700, Linus Torvalds wrote:
This is subtle, and it is basically unavoidable. If a mutex (or
counting semaphore) has a fast-path - and a mutex/semaphore without a
fast-path is shit - then
On Tue, Jun 10, 2014 at 04:48:30PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 05:56:55AM -0700, Paul E. McKenney wrote:
On Mon, Jun 09, 2014 at 11:51:09AM -0700, Linus Torvalds wrote:
This is subtle, and it is basically unavoidable. If a mutex (or
counting semaphore) has a
On Tue, Jun 10, 2014 at 07:36:32AM -0700, Paul E. McKenney wrote:
On Tue, Jun 10, 2014 at 03:01:38PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 05:52:35AM -0700, Paul E. McKenney wrote:
On Tue, Jun 10, 2014 at 10:37:26AM +0200, Peter Zijlstra wrote:
On Mon, Jun 09, 2014 at
On Tue, Jun 10, 2014 at 5:56 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
So to safely free a structure containing a mutex, is there some better
approach than the following?
Yes.
A data structure *containing* a mutex is fine. The problem only occurs
when that mutex also acts the
On Tue, Jun 10, 2014 at 08:35:53AM -0700, Linus Torvalds wrote:
On Tue, Jun 10, 2014 at 5:56 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
So to safely free a structure containing a mutex, is there some better
approach than the following?
Yes.
A data structure *containing* a
On 06/10, Thomas Gleixner wrote:
On Mon, 9 Jun 2014, Steven Rostedt wrote:
I think rtmutex has an
issue with it too. Specifically in the slow_unlock case:
if (!rt_mutex_has_waiters(lock)) {
lock-owner = NULL;
raw_spin_unlock(lock-wait_lock);
On 06/10, Thomas Gleixner wrote:
+static inline bool unlock_rt_mutex_safe(struct rt_mutex *lock)
+ __releases(lock-wait_lock)
+{
+ unsigned long owner, *p = (unsigned long *) lock-owner;
+
+ owner = (unsigned long) rt_mutex_owner(lock);
+ clear_rt_mutex_waiters(lock);
+
On Tue, 10 Jun 2014, Oleg Nesterov wrote:
On 06/10, Thomas Gleixner wrote:
+static inline bool unlock_rt_mutex_safe(struct rt_mutex *lock)
+ __releases(lock-wait_lock)
+{
+ unsigned long owner, *p = (unsigned long *) lock-owner;
+
+ owner = (unsigned long)
On Tue, 10 Jun 2014, Oleg Nesterov wrote:
On 06/10, Thomas Gleixner wrote:
On Mon, 9 Jun 2014, Steven Rostedt wrote:
I think rtmutex has an
issue with it too. Specifically in the slow_unlock case:
if (!rt_mutex_has_waiters(lock)) {
lock-owner = NULL;
On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
Perhaps it could simply do -owner = RT_MUTEX_HAS_WAITERS to make this more
clear...
Good point. The new owner can cleanup the mess.
I thought about this too. It should work with the added overhead that
On Tue, 10 Jun 2014, Steven Rostedt wrote:
On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
Perhaps it could simply do -owner = RT_MUTEX_HAS_WAITERS to make this
more
clear...
Good point. The new owner can cleanup the mess.
I thought
On Tue, 10 Jun 2014, Thomas Gleixner wrote:
On Tue, 10 Jun 2014, Steven Rostedt wrote:
On Tue, 10 Jun 2014 20:08:37 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
Perhaps it could simply do -owner = RT_MUTEX_HAS_WAITERS to make this
more
clear...
Good point.
On Mon, 9 Jun 2014 11:51:09 -0700
Linus Torvalds wrote:
> On Mon, Jun 9, 2014 at 11:29 AM, Steven Rostedt wrote:
> >>
> >> And once again, note that the normal mutex is already unsafe (unless I
> >> missed
> >> something).
> >
> > Is it unsafe?
> >
> > This thread was started because of a bug
On 06/09, Steven Rostedt wrote:
>
> On Mon, 9 Jun 2014 20:15:53 +0200
> Oleg Nesterov wrote:
>
> > > That would indeed be a bad thing, as it could potentially lead to
> > > use-after-free bugs. Though one could argue that any code that resulted
> > > in use-after-free would be quite aggressive.
On Mon, Jun 9, 2014 at 11:29 AM, Steven Rostedt wrote:
>>
>> And once again, note that the normal mutex is already unsafe (unless I missed
>> something).
>
> Is it unsafe?
>
> This thread was started because of a bug we triggered in -rt, which
> ended up being a change specific to -rt that
On Mon, 9 Jun 2014 20:15:53 +0200
Oleg Nesterov wrote:
> > That would indeed be a bad thing, as it could potentially lead to
> > use-after-free bugs. Though one could argue that any code that resulted
> > in use-after-free would be quite aggressive. But still...
>
> And once again, note that
On 06/09, Paul E. McKenney wrote:
>
> On Sun, Jun 08, 2014 at 03:07:18PM +0200, Oleg Nesterov wrote:
> >
> > I only meant that afaics rcu_read_unlock_special() equally depends on the
> > fact that rt_mutex_unlock() does nothing with "struct rt_mutex" after it
> > makes another rt_mutex_lock() +
On Sun, Jun 08, 2014 at 03:07:18PM +0200, Oleg Nesterov wrote:
> On 06/06, Paul E. McKenney wrote:
> >
> > On Tue, Jun 03, 2014 at 10:01:25PM +0200, Oleg Nesterov wrote:
> > >
> > > I'll try to recheck rt_mutex_unlock() tomorrow. _Perhaps_
> > > rcu_read_unlock()
> > > should be shifted from
On Sun, Jun 08, 2014 at 03:07:18PM +0200, Oleg Nesterov wrote:
On 06/06, Paul E. McKenney wrote:
On Tue, Jun 03, 2014 at 10:01:25PM +0200, Oleg Nesterov wrote:
I'll try to recheck rt_mutex_unlock() tomorrow. _Perhaps_
rcu_read_unlock()
should be shifted from lock_task_sighand()
On 06/09, Paul E. McKenney wrote:
On Sun, Jun 08, 2014 at 03:07:18PM +0200, Oleg Nesterov wrote:
I only meant that afaics rcu_read_unlock_special() equally depends on the
fact that rt_mutex_unlock() does nothing with struct rt_mutex after it
makes another rt_mutex_lock() +
On Mon, 9 Jun 2014 20:15:53 +0200
Oleg Nesterov o...@redhat.com wrote:
That would indeed be a bad thing, as it could potentially lead to
use-after-free bugs. Though one could argue that any code that resulted
in use-after-free would be quite aggressive. But still...
And once again,
On Mon, Jun 9, 2014 at 11:29 AM, Steven Rostedt rost...@goodmis.org wrote:
And once again, note that the normal mutex is already unsafe (unless I missed
something).
Is it unsafe?
This thread was started because of a bug we triggered in -rt, which
ended up being a change specific to -rt
On 06/09, Steven Rostedt wrote:
On Mon, 9 Jun 2014 20:15:53 +0200
Oleg Nesterov o...@redhat.com wrote:
That would indeed be a bad thing, as it could potentially lead to
use-after-free bugs. Though one could argue that any code that resulted
in use-after-free would be quite
On Mon, 9 Jun 2014 11:51:09 -0700
Linus Torvalds torva...@linux-foundation.org wrote:
On Mon, Jun 9, 2014 at 11:29 AM, Steven Rostedt rost...@goodmis.org wrote:
And once again, note that the normal mutex is already unsafe (unless I
missed
something).
Is it unsafe?
This thread
On 06/06, Paul E. McKenney wrote:
>
> On Tue, Jun 03, 2014 at 10:01:25PM +0200, Oleg Nesterov wrote:
> >
> > I'll try to recheck rt_mutex_unlock() tomorrow. _Perhaps_ rcu_read_unlock()
> > should be shifted from lock_task_sighand() to unlock_task_sighand() to
> > ensure that rt_mutex_unlock() does
On 06/06, Paul E. McKenney wrote:
On Tue, Jun 03, 2014 at 10:01:25PM +0200, Oleg Nesterov wrote:
I'll try to recheck rt_mutex_unlock() tomorrow. _Perhaps_ rcu_read_unlock()
should be shifted from lock_task_sighand() to unlock_task_sighand() to
ensure that rt_mutex_unlock() does nothihg
96 matches
Mail list logo
