linux-kernel - Re: [PATCH 2/3] Add swap slot free callback to block_device

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]

Date:	Fri, 07 May 2010 15:18:56 +0530
From:	Nitin Gupta <ngupta@...are.org>
To:	nigel@...onice.net
CC:	Greg KH <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Cyp <cyp561@...il.com>, Minchan Kim <minchan.kim@...il.com>,
	Al Viro <viro@...IV.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	driverdev <devel@...verdev.osuosl.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] Add swap slot free callback to block_device_operations

On 05/07/2010 02:52 PM, Nigel Cunningham wrote:
> Hi.
> 
> On 07/05/10 17:25, Nitin Gupta wrote:
>> This callback is required when RAM based devices are used as swap disks.
>> One such device is ramzswap which is used as compressed in-memory swap
>> disk.  For such devices, we need a callback as soon as a swap slot is no
>> longer used to allow freeing memory allocated for this slot.  Without
>> this
>> callback, stale data can quickly accumulate in memory defeating the whole
>> purpose of such devices.
>>
>> Signed-off-by: Nitin Gupta<ngupta@...are.org>
>> ---
>>   include/linux/blkdev.h |    2 ++
>>   mm/swapfile.c          |    4 ++++
>>   2 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
>> index 6690e8b..413284a 100644
>> --- a/include/linux/blkdev.h
>> +++ b/include/linux/blkdev.h
>> @@ -1287,6 +1287,8 @@ struct block_device_operations {
>>                           unsigned long long);
>>       int (*revalidate_disk) (struct gendisk *);
>>       int (*getgeo)(struct block_device *, struct hd_geometry *);
>> +    /* this callback is with swap_lock and sometimes page table lock
>> held */
>> +    void (*swap_slot_free_notify) (struct block_device *, unsigned
>> long);
>>       struct module *owner;
>>   };
>>
>> diff --git a/mm/swapfile.c b/mm/swapfile.c
>> index ecb069e..f5ccc47 100644
>> --- a/mm/swapfile.c
>> +++ b/mm/swapfile.c
>> @@ -574,6 +574,7 @@ static unsigned char swap_entry_free(struct
>> swap_info_struct *p,
>>
>>       /* free if no reference */
>>       if (!usage) {
>> +        struct gendisk *disk = p->bdev->bd_disk;
>>           if (offset<  p->lowest_bit)
>>               p->lowest_bit = offset;
>>           if (offset>  p->highest_bit)
>> @@ -583,6 +584,9 @@ static unsigned char swap_entry_free(struct
>> swap_info_struct *p,
>>               swap_list.next = p->type;
>>           nr_swap_pages++;
>>           p->inuse_pages--;
>> +        if ((p->flags&  SWP_BLKDEV)&&
>> +                disk->fops->swap_slot_free_notify)
>> +            disk->fops->swap_slot_free_notify(p->bdev, offset);
> 
> Is this p->flags & SWP_BLKDEV logic reversed? (Don't you want the
> notifier called for devices that aren't backed by a block device?)
>

No, the logic here is correct: ramzswap is a block device for which
we want this callback. Though its a RAM backed, it is still a block
device.

(I hope it answers your question in the other mail also).
 
> I also wonder whether leaving the p->flags & SWP_BLKDEV part out might
> be a good idea. Other potential notifier users?
> 

For regular files, 'offset' used here makes little sense. For block devices,
its simply offset in real device. Also, I doubt if *files* would ever
like to have such a callback.

Thanks,
Nitin
--
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/