linux-kernel - Re: [PATCH 1/3] Add flag to identify block swap devices

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, 7 May 2010 17:56:44 +0900
From:	jassi brar <jassisinghbrar@...il.com>
To:	ngupta@...are.org
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>,
	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 1/3] Add flag to identify block swap devices

On Fri, May 7, 2010 at 5:16 PM, Nitin Gupta <ngupta@...are.org> wrote:
> On 05/07/2010 01:33 PM, jassi brar wrote:
>> On Fri, May 7, 2010 at 4:25 PM, Nitin Gupta <ngupta@...are.org> wrote:
>>> Added SWP_BLKDEV flag to distinguish block and regular file backed
>>> swap devices. We could also check if a swap is entire block device,
>>> rather than a file, by:
>>> S_ISBLK(swap_info_struct->swap_file->f_mapping->host->i_mode)
>>> but, I think, simply checking this flag is more convenient.
>> This might make it convenient for now but is likely to increase complexity and
>> redundancy. Why not define a macro/inline to figure that out?
>>
>
> Accessing such long pointer chain is maybe not good thing to do for
> every swap_entry_free() call? Simple checking a flag is perhaps slightly
> faster? I also can't see how this flag can later increase complexity
> compared to creating new macro for this check.

 I am not sure about effects on the speed, that needs to be seen.
 But here are points against using a new flag....

a) Defining a new flag hogs up precious real-estate of remaining just 2 bits
   (apparently the new flags are to go before SWP_SCANNING)

b) Over time, some dependent code might evolve to depend upon this flag, while
     others might use the indirection to deduct if it is block device
or not. That
    will make it complicated to make any relevant change in future as we'll have
    to keep track of more than one way to check the status. Creating a new
   macro doesn't create a new path to reach the status, but a FLAG does.
--
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/