linux-kernel - Re: [PATCH] mm: remove compressed copy from zram in-memory

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

Date:	Wed, 10 Apr 2013 09:16:13 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Hugh Dickins <hughd@...gle.com>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Nitin Gupta <ngupta@...are.org>,
	Konrad Rzeszutek Wilk <konrad@...nok.org>,
	Shaohua Li <shli@...nel.org>,
	Dan Magenheimer <dan.magenheimer@...cle.com>
Subject: Re: [PATCH] mm: remove compressed copy from zram in-memory

On Tue, Apr 09, 2013 at 12:54:23PM -0700, Andrew Morton wrote:
> On Tue, 9 Apr 2013 10:02:31 +0900 Minchan Kim <minchan@...nel.org> wrote:
> 
> > > Also, what's up with the SWP_BLKDEV test?  zram doesn't support
> > > SWP_FILE?  Why on earth not?
> > > 
> > > Putting swap_slot_free_notify() into block_device_operations seems
> > > rather wrong.  It precludes zram-over-swapfiles for all time and means
> > > that other subsystems cannot get notifications for swap slot freeing
> > > for swapfile-backed swap.
> > 
> > Zram is just pseudo-block device so anyone can format it with any FSes
> > and swapon a file. In such case, he can't get a benefit from
> > swap_slot_free_notify. But I think it's not a severe problem because
> > there is no reason to use a file-swap on zram. If anyone want to use it,
> > I'd like to know the reason. If it's reasonable, we have to rethink a
> > wheel and it's another story, IMHO.
> 
> My point is that making the swap_slot_free_notify() callback a
> blockdev-specific thing was restrictive.  What happens if someone wants
> to use it for swapfile-backed swap?  This has nothing to do with zram.

Agree that it's not specific to zram even if zram is only user at the memont.
IMHO, more general one is that we introduce SWP_INMEMORY with
QUEUE_FLAS_INMEMORY_OR_SOMETHING so we can register swap_slot_free_notify
if backed device has a such type.

Do you really want to do above work(or alternative one, hope someone
in this thread suggest better idea) prio to this patch?
If so, I am happy to do it.
But my concern that it will introduce to change core kernel for staging one
where everyone ignore and apparently someone will regist it so will be stucked,
again.

So, I need a excuse to tell him "Hey guy, akpm told me "let's resolve
the issue prio to solving duplicated copy problem of zram although
it is for staging one". :)

Could you give me a license to kill? 

> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

-- 
Kind regards,
Minchan Kim
--
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/