linux-kernel - Re: [PATCH 31/40] libata: take advantage of cmwq and remove concurrency limitations

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B5501A3.2010706@kernel.org>
Date:	Tue, 19 Jan 2010 09:49:39 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	torvalds@...ux-foundation.org, mingo@...e.hu, peterz@...radead.org,
	awalls@...ix.net, linux-kernel@...r.kernel.org, jeff@...zik.org,
	akpm@...ux-foundation.org, jens.axboe@...cle.com,
	rusty@...tcorp.com.au, cl@...ux-foundation.org,
	dhowells@...hat.com, arjan@...ux.intel.com, avi@...hat.com,
	johannes@...solutions.net, andi@...stfloor.org,
	Jeff Garzik <jgarzik@...ox.com>
Subject: Re: [PATCH 31/40] libata: take advantage of cmwq and remove concurrency
 limitations

Hello,

On 01/19/2010 12:48 AM, Stefan Richter wrote:
>> b. ata_aux_wq which is used for SCSI probing has single thread.  In
>>    cases where SCSI probing is stalled for extended period of time
>>    which is possible for ATAPI devices, this will stall all probing.
> 
> Are things like INQUIRY and possibly motor spin-up performed there?
> If yes, ...

For disks, they are all done by EH.  Responses to INQUIRYs are
constructed by libata from the data it has acquired during parallel
ATA probing, so there's nothing much going on there.  For ATAPI
devices, it's a different story tho.

>> @@ -3408,8 +3408,7 @@ void ata_scsi_scan_host(struct ata_port *ap, int sync)
>>  				"                  switching to async\n");
>>  	}
>>  
>> -	queue_delayed_work(ata_aux_wq, &ap->hotplug_task,
>> -			   round_jiffies_relative(HZ));
>> +	schedule_delayed_work(&ap->hotplug_task, round_jiffies_relative(HZ));
>>  }
>>  
>>  /**
> [...]
> 
> ... wouldn't queue_delayed_work(system_long_wq, &ap->hotplug_task, ...);
> be more appropriate then?

Hmmm... yeah, right, I'll update it.  I'm thinking about adding a
debug option to trigger a warning if a work queued on the default
workqueue takes longer than, say, 30secs to finish.

Thanks.

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