linux-kernel - Re: [PATCH 4/4] disk-protect: Add a generic block layer queue freezing facility

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: <87ve3mfxv0.fsf@denkblock.local>
Date:	Sun, 16 Mar 2008 17:16:19 +0100
From:	Elias Oltmanns <eo@...ensachen.de>
To:	linux-ide@...r.kernel.org
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [PATCH 4/4] disk-protect: Add a generic block layer queue freezing facility

Pavel Machek <pavel@....cz> wrote:
> On Fri 2008-03-07 19:26:41, Elias Oltmanns wrote:
>> This patch provides a generic way to freeze the request queue of a block
>> device temporarily. This functionality is exposed to user space via sysfs.
>> 
>> Signed-off-by: Elias Oltmanns <eo@...ensachen.de>
>
> I guess this should have patch going to documentation. Otherwise it
> looks ok.

Yes, I'll add documentation eventually. There is more to be added before
this patch can go in because the protect attribute will appear for all
block devices employing request queues. In particular, we will have to
make sure that drivers will handle REQ_TYPE_LINUX_BLOCK requests
gracefully even if they don't implement support for a particular
command.

>
>> +/*
>> + * When reading the 'protect' attribute, we return seconds remaining
>> + * before the unfreeze timeout expires.
>> + */
>> +static ssize_t queue_protect_show(struct request_queue *q, char *page)
>> +{
>> +	unsigned int seconds = 0;
>> +
>> +	if (blk_queue_stopped(q) && timer_pending(&q->unfreeze_timer))
>> +		/*
>> +		 * Adding 1 in order to guarantee nonzero value until timer
>> +		 * has actually expired.
>> +		 */
>> +		seconds = jiffies_to_msecs(q->unfreeze_timer.expires
>> +					   - jiffies) / 1000 + 1;
>
> Is it okay to read expires without locking? 

No, I have been a bit careless with regard to locking in this patch. See
the revised version below.

Regards,

Elias

---

View attachment "tmp.patch" of type "text/x-patch" (6661 bytes)