On Sun, Dec 24, 2000 at 11:23:33AM +1100, Andrew Morton wrote:
> ack.
This patch against 2.2.19pre3 should fix all races. (note that wait->flags
doesn't need to be initialized in the critical section in test1X too)
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19p
On Sun, Dec 24, 2000 at 04:17:10PM +1100, Andrew Morton wrote:
> I was talking about a different scenario:
>
> add_wait_queue_exclusive(&q->wait_for_request, &wait);
> for (;;) {
> __set_current_state(TASK_UNINTERRUPTIBLE);
> /* WINDOW */
> sp
Andrea Arcangeli wrote:
>
> On Sun, Dec 24, 2000 at 01:28:59PM +1100, Andrew Morton wrote:
> > This could happen with the old scheme where exclusiveness
> > was stored in the task, not the waitqueue.
> >
> > >From test4:
> >
> > for (;;) {
> > __set_current_state(TASK_UNIN
On Sun, Dec 24, 2000 at 01:28:59PM +1100, Andrew Morton wrote:
> This could happen with the old scheme where exclusiveness
> was stored in the task, not the waitqueue.
>
> >From test4:
>
> for (;;) {
> __set_current_state(TASK_UNINTERRUPTIBLE | TASK_EXCLUSIVE);
> /*
Andrea Arcangeli wrote:
>
> ...
> > if (rq)
> > break;
> > generic_unplug_device(q);
> > schedule();
> > }
> > remove_wait_queue(&q->wait_for_request, &wait);
> > current->state = TASK_RUNNING;
> >
On Sun, Dec 24, 2000 at 11:23:33AM +1100, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> > 1) could be fixed trivially by making the waitqueue_lock a spinlock, but
> > this way doesn't solve 2). And if we solve 2) properly than 1) gets fixed as
BTW (follow up myself), really making the lock a s
Andrea Arcangeli wrote:
>
> On Sat, Dec 23, 2000 at 05:56:42PM +1100, Andrew Morton wrote:
> > If we elect to not address this problem in 2.2 and to rely upon the network
>
> I see. There are two races:
>
> 1) race inside __wake_up when it's run on the same waitqueue: 2.2.19pre3
>
On Sat, Dec 23, 2000 at 05:56:42PM +1100, Andrew Morton wrote:
> If we elect to not address this problem in 2.2 and to rely upon the network
I see. There are two races:
1) race inside __wake_up when it's run on the same waitqueue: 2.2.19pre3
is affected as well as 2.2.18aa2, and 2.4
Andrea Arcangeli wrote:
>
> [ 2.2 waitqueue stuff ]
>
Andrea, it occurs to me...
__wake_up() is using read_lock(waitqueue_lock). This means that
two CPUs could simultaneously run __wake_up(). They could both
find the same task and they could both try to wake it up. The
net result would be two
On Fri, Dec 22, 2000 at 06:33:00PM +1100, Andrew Morton wrote:
> add_waitqueue_exclusive() and TASK_EXCLUSIVE, add a
There's no add_waitqueue_exclusive in my patch.
> Except for this bit, which looks slightly fatal:
>
> /*
> * We can drop the read-lock early if this
> *
Andrea Arcangeli wrote:
>
> > > Other thing about your patch, adding TASK_EXCLUSIVE to
> > > wake_up/wake_up_interruptible is useless.
> >
> > This enables wake_up_all().
>
> It is useless as it is in 2.2.19pre2: there's no wake_up_all in 2.2.19pre2.
#define wake_up_all(x) __wake_up((x),TASK_UN
On Wed, Dec 20, 2000 at 02:28:58PM +0100, Andrea Arcangeli wrote:
> I was in the process of fixing this (I also just backported the thinkpad
> %edx clobber fix), but if somebody is going to work on this please let
> me know so we stay in sync.
Ok this should fix the e820 memory detection, against
On Thu, 21 Dec 2000, Andrea Arcangeli wrote:
> It would also be nice if you could show a real life
> showstopper-production-bottleneck where we need C) to fix it. I
> cannot see any useful usage of C in production 2.2.x.
Me neither. I'm just wondering at the reason why 2.2 semantics
would be di
On Thu, Dec 21, 2000 at 03:07:08PM -0200, Rik van Riel wrote:
> c) will also implement a) in an obviously right and simple way.
So go ahead. If you think that's so simple and obviously right you can post
here a patch here against 2.2.19pre2 that implements C) to show real facts.
My B is here:
On Thu, 21 Dec 2000, Andrea Arcangeli wrote:
> > The key question is: which of the following do we want?
> >
> > a) A simple, specific accept()-accelerator, and 2.2 remains without
> >an exclusive wq API or
>
> To make the accellerator we need a minimal wake-one support. So a) doesn't
> mak
On Thu, Dec 21, 2000 at 09:38:43PM +1100, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> >
> > The fact you could mix non-exclusive and exlusive wakeups in the same waitqueue
> > was a feature not a misfeature. Then of course you cannot register in two
> > waitqueues one with wake-one and one w
Andrea Arcangeli wrote:
>
> The fact you could mix non-exclusive and exlusive wakeups in the same waitqueue
> was a feature not a misfeature. Then of course you cannot register in two
> waitqueues one with wake-one and one with wake-all but who does that anyways?
> Definitely not an issue for 2.2
On Wed, Dec 20, 2000 at 03:48:06PM -0200, Rik van Riel wrote:
> On Wed, 20 Dec 2000, Andrea Arcangeli wrote:
> > On Thu, Dec 21, 2000 at 01:57:15AM +1100, Andrew Morton wrote:
> > > If a task is on two waitqueues at the same time it becomes a bug:
> > > if the outer waitqueue is non-exclusive and
On Wed, 20 Dec 2000, Andrea Arcangeli wrote:
> On Thu, Dec 21, 2000 at 01:57:15AM +1100, Andrew Morton wrote:
> > If a task is on two waitqueues at the same time it becomes a bug:
> > if the outer waitqueue is non-exclusive and the inner is exclusive,
>
> Your 2.2.x won't allow that either. You s
On Thu, Dec 21, 2000 at 01:57:15AM +1100, Andrew Morton wrote:
> If a task is on two waitqueues at the same time it becomes a bug:
> if the outer waitqueue is non-exclusive and the inner is exclusive,
Your 2.2.x won't allow that either. You set the `current->task_exclusive = 1'
and so you will ge
Andrea Arcangeli wrote:
>
> > o wake_one semantics for accept() (Andrew Morton)
>
> I dislike the implementation. I stick with my faster and nicer implementation
> that was just included in aa kernels for some time (2.2.18aa2 included it for
> example). Andrew, I guess you di
On Sat, Dec 16, 2000 at 07:11:47PM +, Alan Cox wrote:
> o E820 memory detect backport from 2.4(Michael Chen)
It's broken, it will crash machines:
for (i = 0; i < e820.nr_map; i++) {
unsigned long start, end;
/* RAM? */
if (e
On Wed, Dec 20, 2000 at 12:32:54PM +0200, Petri Kaukasoina wrote:
> OK, I booted 2.4.0-test12 which even prints that list:
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0009fc00 @ (usable)
> BIOS-e820: 0400 @ 0009fc00 (reserved)
> BIOS-e820:
On Sun, Dec 17, 2000 at 04:38:02PM +0100, Kurt Garloff wrote:
> On Sun, Dec 17, 2000 at 12:56:56PM +0200, Petri Kaukasoina wrote:
> > I guess the new memory detect does not work correctly with my old work
> > horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with
> > a versio
Hi,
On Sun, Dec 17, 2000 at 12:56:56PM +0200, Petri Kaukasoina wrote:
> I guess the new memory detect does not work correctly with my old work
> horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with
> a version number of 51-000-0001169_0011-101094-SIS550X-H.
>
> 2.2.18
I guess the new memory detect does not work correctly with my old work
horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with
a version number of 51-000-0001169_0011-101094-SIS550X-H.
2.2.18 reports:
Memory: 55536k/57344k available (624k kernel code, 412k reserved, 732k
Merge the Andrea VM changes. Nothing else in this pre-patch so we can be
sure we know if it broke something. The other stuff is still on my in queue
so don't resend it.
2.2.19pre2
o Drop the page aging for a moment to merge the
Andrea VM
o Merge Andrea's VM-global patch
27 matches
Mail list logo
