On Saturday 18 September 2010 01:21:41 Petr Vandrovec wrote:
>
> I'll try to come up with something for ncpfs.
Ok, good.
> Trivial lock replacement will open deadlock possibility when
> someone reads to page which is also mmaped from the same
> filesystem (like grep likes to do). BKL with its a
I'll try to come up with something for ncpfs.
Trivial lock replacement will open deadlock possibility when someone reads to
page which is also mmaped from the same filesystem (like grep likes to do). BKL
with its automated release on sleep helped (or papered over) a lot here.
Petr
"Arnd Bergma
On Thursday 16 September 2010 20:32:36 Jens Axboe wrote:
> On 2010-09-16 16:49, Steven Rostedt wrote:
> > Git blame shows this to be your code (copied from block/blktrace.c from
> > years past).
> >
> > Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
>
> It isn't, it can
Hi,
On 16 Sep 2010, at 16:04, Jan Kara wrote:
> On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
>> The big kernel lock is gone from almost all code in linux-next, this is
>> the status of what I think will happen to the remaining users:
> ...
>> fs/ncpfs:
>> Should be fixable if Petr still car
From: Samuel Ortiz
Date: Thu, 16 Sep 2010 18:57:56 +0200
> On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
>> net/appletalk:
>> net/ipx/af_ipx.c:
>> net/irda/af_irda.c:
>> Can probably be saved from retirement in drivers/staging if the
>> maintainers still care.
> I'll take care
On 2010-09-16 16:49, Steven Rostedt wrote:
> On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
>> The big kernel lock is gone from almost all code in linux-next, this is
>> the status of what I think will happen to the remaining users:
>
>> kernel/trace/blktrace.c:
>> Should be easy. In
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
> net/appletalk:
> net/ipx/af_ipx.c:
> net/irda/af_irda.c:
> Can probably be saved from retirement in drivers/staging if the
> maintainers still care.
I'll take care of the IrDA part.
Cheers,
Samuel.
On 2010-09-16 16:32:59, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
> fs/qnx4:
> Should be easy to fix, there are only a few places in the code that
> use the BKL. Anders
> net/appletalk:
> net/ipx/af_ipx.c:
> net/irda/af_irda.c:
> Can probably be saved from retirement in drivers/staging if the
> maintainers still care.
IPX and Appletalk both have active users. They also look fairly fixable
as the lock_kernel just maps to a stack private mutex, or in se
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
...
> fs/ncpfs:
> Should be fixable if Petr still cares about it. Otherwise suggest
> moving to drive
From: Alan Cox
Date: Thu, 16 Sep 2010 16:07:59 +0100
>> net/appletalk:
>> net/ipx/af_ipx.c:
>> net/irda/af_irda.c:
>> Can probably be saved from retirement in drivers/staging if the
>> maintainers still care.
>
> IPX and Appletalk both have active users. They also look fairly fixable
>
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
> The big kernel lock is gone from almost all code in linux-next, this is
> the status of what I think will happen to the remaining users:
> kernel/trace/blktrace.c:
> Should be easy. Ingo? Steven?
>
Jens,
Git blame shows this to be
12 matches
Mail list logo
