linux-kernel - Re: function call fw_iso_resource_mange(..) (core-iso.c) does not return

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 22 May 2013 09:21:58 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	stephan.gatzka@...il.com
CC:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Tejun Heo <tj@...nel.org>,
	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: function call fw_iso_resource_mange(..) (core-iso.c) does not
 return

On 05/22/2013 09:06 AM, Stephan Gatzka wrote:
>> Solution 2 --- Perform interdependent works in different queue instances.
>> (Keep the WQ_MEM_RECLAIM flag set at those workqueues that have to take
>> work which is necessary for progress of memory reclaim.  If this and only
>> this solution is employed for an SBP-2 initiator, we need two if not more
>> WQ_MEM_RECLAIM workqueue instances.)
>
> I would go for this solution. I have no problems with lots of workqueues around, because there is only a relatively small structure required for each workqueue.

Now that we more fully understand the cause, this would be my choice as
well (despite my earlier advocacy for the return to tasklets).

Although we do need to carefully review the other work items (bm_work,br_work)
to ensure that there aren't unwanted dependencies with those as well.

Also, wqs that are WQ_MEM_RECLAIM aren't free as each wq will have a
dedicated rescue thread.

[The other advantage with tasklets is the reduced latency but I do
understand the advantages of the RT characteristics of worklets.]

Regards,
Peter Hurley

>
>>
>> Solution 3 --- Remove the dependency between worklets:
>>
>>     Solution 3a --- Remove the lower-level worklet altogether.
>>     E.g. reimplement the lower-level worklet as a tasklet.
>
> No, I like the workqueue context. :)
>
>
>>     Solution 3b --- Remove the higher-level worklet's dependency.
>>     E.g. reimplement the higher-level worklet such that it is woken by
>>     a timer and then aborts or reschedules ( = lets the lower-level
>>     worklet bubble up in the queue).
>
> This looks more difficult to me and not so easy to test.
>
> Stephan

--
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/