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]
Message-ID: <5511978F.6050100@redhat.com>
Date:	Tue, 24 Mar 2015 12:57:51 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Boaz Harrosh <boaz@...xistor.com>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>
CC:	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	axboe@...nel.dk, linux-nvdimm@...1.01.org,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	linux-raid@...r.kernel.org, mgorman@...e.de, hch@...radead.org,
	linux-fsdevel@...r.kernel.org,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [RFC PATCH 0/7] evacuate struct page from the block layer

On 03/24/2015 05:41 AM, Boaz Harrosh wrote:
> On 03/23/2015 05:19 PM, Rik van Riel wrote:

>> There are two things going on here:
>>
>> 1) You want to keep using struct page for now, while there are
>>    subsystems that require it. This is perfectly legitimate.
>>
>> 2) Matthew and Dan are changing over some subsystems to no longer
>>    require struct page. This is perfectly legitimate.
>>
> 
> How is this legitimate when you need to Interface the [1] subsystems
> under the [2] subsystem? A subsystem that expects pages is now not
> usable by [2].
> 
> Today *All* the Kernel subsystems are [1] Period.

That's not true. In the graphics subsystem it is very normal to
mmap graphics memory without ever using a struct page. There are
other callers of remap_pfn_range() too.

In these cases, refcounting is done by keeping a refcount on the
entire object, not on individual pages (since we have none).

> How does it become
> legitimate to now start *two* competing, do the same differently, abstraction,
> in our kernel. We have two much diversity not to little.

We are already able to refcount either the whole object, or an
individual page.

One issue is that not every subsystem can do the whole object
refcounting, and that it would be nice to have the refcounting
done by one single interface.

If we want the code to be the same everywhere, we could achieve
that just as well with an abstraction as with a single data
structure.

Maybe even something as simplistic as these, with the internals
automatically taking and releasing a refcount on the proper object:

get_reference(file, memory_address)

put_reference(file, memory_address)

-- 
All rights reversed
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ