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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 7 May 2010 12:24:50 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	jassi brar <jassisinghbrar@...il.com>
Cc:	ngupta@...are.org, Greg KH <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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....

On Fri, May 7, 2010 at 11:56 AM, jassi brar <jassisinghbrar@...il.com> wrote:
> 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.

I think the flag is cleaner and I'm not convinced by the above
speculative arguments that we should switch to a static inline
function.

Hugh, Linus, would you mind voicing your opinion which way to go here?
--
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/