On Mon, Apr 8, 2019 at 9:57 PM Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:
>
> On 2019-04-08 21:33:55 [+0200], Daniel Vacek wrote:
> > On Mon, Apr 8, 2019 at 7:31 PM Sebastian Andrzej Siewior
> > <bigeasy@xxxxxxxxxxxxx> wrote:
> > >
> > > On 2019-03-29 09:38:33 [+0100], Bernhard Landauer wrote:
> > > >
> > > > > How do I reproduce this?
> > > >
> > > > For me this happens reliably when I launch a fresh instance of ff and it
> > > > automatically tries to restore tabs of the previous session.
> > > > Alternatively, when I select 'Restore Previous Session' from the menu.
> > >
> > > Does this help?
> >
> > >From an uninvolved lurker, how is this supposed to change a thing?
>
> on RT
> local_irq_disable() + spin_lock() != spin_lock_irq()
Nah, the rt_mutex... I always fall into this trap :-/
> > Moreover, I'd say the original version is better readable.
>
> how so? You remove the irq/irq_save() from a lock and put a local_irq_()
> in front of it. Is the only purpose is to avoid enabling/disabling twice
> in a row?
What I meant is that it's two different locks so it's easier to see
that you a) disable interrupts and then b) do the work with the locks.
But yeah, you would have to change this to
local_irq_{dis,en}able_nort() to achieve what you did here. Still I'd
argue that doing this would be clearer to document the intention.
Anyways, please disregard. I'll back to lurking...
--nX
> > --nX
>
> Sebastian
