lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 09 Mar 2014 18:53:38 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	ben@...adent.org.uk
Cc:	mkl@...gutronix.de, linux-rt-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	kernel@...gutronix.de
Subject: Re: [PATCH] net: sched: dev_deactivate_many(): use msleep(1)
 instead of yield() to wait for outstanding qdisc_run calls

From: Ben Hutchings <ben@...adent.org.uk>
Date: Sun, 09 Mar 2014 19:09:20 +0000

> On Thu, 2014-03-06 at 16:06 -0500, David Miller wrote:
>> From: Marc Kleine-Budde <mkl@...gutronix.de>
>> Date: Wed,  5 Mar 2014 00:49:47 +0100
>> 
>> > @@ -839,7 +839,7 @@ void dev_deactivate_many(struct list_head *head)
>> >       /* Wait for outstanding qdisc_run calls. */
>> >       list_for_each_entry(dev, head, unreg_list)
>> >               while (some_qdisc_is_busy(dev))
>> > -                     yield();
>> > +                     msleep(1)
>> >  }
>> 
>> I don't understand this.
>> 
>> yield() should really _mean_ yield.
>> 
>> The intent of a yield() call, like this one here, is unambiguously
>> that the current thread cannot do anything until some other thread
>> gets onto the cpu and makes forward progress.
>>
>> Therefore it should allow lower priority threads to run, not just
>> equal or higher priority ones.
> 
> Until when?
> 
> yield() is not a sensible operation in a preemptive multitasking system,
> regardless of RT.

To me it means "I've got nothing to do if other tasks want to run right
now"  Yes, I even see it having this meaning when an RT task executes
it.

How else can you interpret the intent above?

If you change it to msleep(1), you're assigning an extra completely
arbitrary time limit to the yield.  The code doesn't want to sleep
for 1ms, that's not what it's asking for.

On the other hand, I do completely agree with other replies stating
that it would be better if we found a way for this code to wait on
something explicitly via a wait queue.

Unfortunately, that's undesirable from another perspective, in that it
would probably require making the fast paths of the qdiscs more
expensive.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists