All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@nokia.com>
To: "Syrjala Ville (Nokia-D/Helsinki)" <ville.syrjala@nokia.com>
Cc: "Valkeinen Tomi (Nokia-D/Helsinki)" <Tomi.Valkeinen@nokia.com>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory
Date: Fri, 19 Mar 2010 07:46:04 +0000	[thread overview]
Message-ID: <20100319074604.GA19537@localhost> (raw)
In-Reply-To: <20100318152604.GM18243@nokia.com>

On Thu, Mar 18, 2010 at 04:26:04PM +0100, Syrjala Ville (Nokia-D/Helsinki) wrote:
> [...]
> > > Just tried it and seems to be mostly OK. We get lockdep checking as a
> > > bonus. It didn't like setup_plane taking the same rwsem twice so I
> > > added a check to see if the old and new regions are the same and just
> > > lock once in that case. I thought rwsem was supposed to be OK with
> > > read recursion but perhaps I was mitaken, or perhaps it's just lockdep
> > > that's misbehaving.
> > 
> > Ah ok, so it's not so obvious change. Nested read locks could really lead
> > to a deadlock I think. A read lock will block if there is a write waiter
> > in the queue to avoid write starvation..
> 
> Yes but I think in out case it should be fine because if we hit this:
> 
>  t  thread 1     thread 2
>  |
>  |  down_read(0)
>  |               down_write(1)
>  v  down_read(1)
> 
> then thread 2 will eventually do a up_write() without taking any
> other region rwsem, and thread 1 can then continue.

Yes and things will work fine with the extra ordering you added. But
lockdep was right in that without the ordering you can get - the not
too likely - scenario:

t thread 1        thread 2       thread 3      thread 4
| down_read(0)
|                 down_write(0)
|                                down_read(1)
|                                              down_write(1)
| down_read(1)
v                                down_read(0)

--Imre


WARNING: multiple messages have this Message-ID (diff)
From: Imre Deak <imre.deak@nokia.com>
To: "Syrjala Ville (Nokia-D/Helsinki)" <ville.syrjala@nokia.com>
Cc: "Valkeinen Tomi (Nokia-D/Helsinki)" <Tomi.Valkeinen@nokia.com>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions
Date: Fri, 19 Mar 2010 09:46:04 +0200	[thread overview]
Message-ID: <20100319074604.GA19537@localhost> (raw)
In-Reply-To: <20100318152604.GM18243@nokia.com>

On Thu, Mar 18, 2010 at 04:26:04PM +0100, Syrjala Ville (Nokia-D/Helsinki) wrote:
> [...]
> > > Just tried it and seems to be mostly OK. We get lockdep checking as a
> > > bonus. It didn't like setup_plane taking the same rwsem twice so I
> > > added a check to see if the old and new regions are the same and just
> > > lock once in that case. I thought rwsem was supposed to be OK with
> > > read recursion but perhaps I was mitaken, or perhaps it's just lockdep
> > > that's misbehaving.
> > 
> > Ah ok, so it's not so obvious change. Nested read locks could really lead
> > to a deadlock I think. A read lock will block if there is a write waiter
> > in the queue to avoid write starvation..
> 
> Yes but I think in out case it should be fine because if we hit this:
> 
>  t  thread 1     thread 2
>  |
>  |  down_read(0)
>  |               down_write(1)
>  v  down_read(1)
> 
> then thread 2 will eventually do a up_write() without taking any
> other region rwsem, and thread 1 can then continue.

Yes and things will work fine with the extra ordering you added. But
lockdep was right in that without the ordering you can get - the not
too likely - scenario:

t thread 1        thread 2       thread 3      thread 4
| down_read(0)
|                 down_write(0)
|                                down_read(1)
|                                              down_write(1)
| down_read(1)
v                                down_read(0)

--Imre


  reply	other threads:[~2010-03-19  7:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-05 13:26 [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions ville.syrjala
2010-03-05 13:26 ` ville.syrjala
2010-03-05 13:26 ` [PATCH 2/4] DSS2: Check if display supports update mode changes ville.syrjala
2010-03-05 13:26   ` ville.syrjala
2010-03-05 13:26 ` [PATCH 3/4] DSS2: Make wait_for_go() succeed for disabled displays ville.syrjala
2010-03-05 13:26   ` ville.syrjala
2010-03-05 13:26 ` [PATCH 4/4] DSS2: clear spurious SYNC_LOST_DIGIT interrupts ville.syrjala
2010-03-05 13:26   ` ville.syrjala
2010-03-05 15:19   ` Aguirre, Sergio
2010-03-05 15:19     ` Aguirre, Sergio
2010-03-05 15:25     ` Tomi Valkeinen
2010-03-05 15:25       ` Tomi Valkeinen
2010-03-05 15:28       ` Aguirre, Sergio
2010-03-05 15:28         ` Aguirre, Sergio
2010-03-17 13:50 ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Tomi Valkeinen
2010-03-17 13:50   ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Tomi Valkeinen
2010-03-17 15:51   ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Ville Syrjälä
2010-03-17 15:51     ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Ville Syrjälä
2010-03-17 17:34 ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Imre Deak
2010-03-17 17:34   ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Imre Deak
2010-03-17 20:14   ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Ville Syrjälä
2010-03-17 20:14     ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Ville Syrjälä
2010-03-18  8:52     ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Imre Deak
2010-03-18  8:52       ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Imre Deak
2010-03-18 15:26       ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Ville Syrjälä
2010-03-18 15:26         ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Ville Syrjälä
2010-03-19  7:46         ` Imre Deak [this message]
2010-03-19  7:46           ` Imre Deak
2010-03-19 12:23           ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory Ville Syrjälä
2010-03-19 12:23             ` [PATCH v3 1/4] DSS2: OMAPFB: Add support for switching memory regions Ville Syrjälä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100319074604.GA19537@localhost \
    --to=imre.deak@nokia.com \
    --cc=Tomi.Valkeinen@nokia.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ville.syrjala@nokia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.