Reviewed-by: Mark Williamson
On Tue, Jul 21, 2015 at 9:17 AM, Naoya Horiguchi
wrote:
> On Tue, Jul 14, 2015 at 06:37:49PM +0300, Konstantin Khlebnikov wrote:
>> This patch sets bit 56 in pagemap if this page is mapped only once.
>> It allows to detect exclusively used pages witho
(my review on this patch comes with the caveat that the specifics of
hugetlb / thp are a bit outside my experience)
On Fri, Jul 24, 2015 at 7:17 PM, Mark Williamson
wrote:
> Reviewed-by: Mark Williamson
>
> On Tue, Jul 21, 2015 at 9:43 AM, Konstantin Khlebnikov
> wrote:
>&
Reviewed-by: Mark Williamson
On Tue, Jul 21, 2015 at 9:39 AM, Konstantin Khlebnikov wrote:
> On Tue, Jul 21, 2015 at 11:11 AM, Naoya Horiguchi
> wrote:
>> On Tue, Jul 14, 2015 at 06:37:47PM +0300, Konstantin Khlebnikov wrote:
>>> This patch makes pagemap readable for n
Reviewed-by: Mark Williamson
On Tue, Jul 21, 2015 at 9:43 AM, Konstantin Khlebnikov wrote:
> On Tue, Jul 21, 2015 at 11:00 AM, Naoya Horiguchi
> wrote:
>> On Tue, Jul 14, 2015 at 06:37:39PM +0300, Konstantin Khlebnikov wrote:
>>> This patch moves pmd dissection out of
(within the limits of my understanding of the mm code)
Reviewed-by: Mark Williamson
On Tue, Jul 21, 2015 at 9:06 AM, Naoya Horiguchi
wrote:
> On Tue, Jul 14, 2015 at 06:37:35PM +0300, Konstantin Khlebnikov wrote:
>> This patch moves permission checks from pagemap_read() into pag
Hi Konstantin,
Thank you for the further update - I tested this patchset against our
code and it allows our software to work correctly (with minor userland
changes, as before).
I'll follow up with review messages but there aren't really any
concerns that I can see.
Cheers,
Mark
On Tue, Jul 14,
Reviewed-by: Mark Williamson mwilliam...@undo-software.com
On Tue, Jul 21, 2015 at 9:43 AM, Konstantin Khlebnikov koc...@gmail.com wrote:
On Tue, Jul 21, 2015 at 11:00 AM, Naoya Horiguchi
n-horigu...@ah.jp.nec.com wrote:
On Tue, Jul 14, 2015 at 06:37:39PM +0300, Konstantin Khlebnikov wrote
Hi Konstantin,
Thank you for the further update - I tested this patchset against our
code and it allows our software to work correctly (with minor userland
changes, as before).
I'll follow up with review messages but there aren't really any
concerns that I can see.
Cheers,
Mark
On Tue, Jul 14,
(within the limits of my understanding of the mm code)
Reviewed-by: Mark Williamson mwilliam...@undo-software.com
On Tue, Jul 21, 2015 at 9:06 AM, Naoya Horiguchi
n-horigu...@ah.jp.nec.com wrote:
On Tue, Jul 14, 2015 at 06:37:35PM +0300, Konstantin Khlebnikov wrote:
This patch moves permission
Reviewed-by: Mark Williamson mwilliam...@undo-software.com
On Tue, Jul 21, 2015 at 9:17 AM, Naoya Horiguchi
n-horigu...@ah.jp.nec.com wrote:
On Tue, Jul 14, 2015 at 06:37:49PM +0300, Konstantin Khlebnikov wrote:
This patch sets bit 56 in pagemap if this page is mapped only once.
It allows
Reviewed-by: Mark Williamson mwilliam...@undo-software.com
On Tue, Jul 21, 2015 at 9:39 AM, Konstantin Khlebnikov koc...@gmail.com wrote:
On Tue, Jul 21, 2015 at 11:11 AM, Naoya Horiguchi
n-horigu...@ah.jp.nec.com wrote:
On Tue, Jul 14, 2015 at 06:37:47PM +0300, Konstantin Khlebnikov wrote
(my review on this patch comes with the caveat that the specifics of
hugetlb / thp are a bit outside my experience)
On Fri, Jul 24, 2015 at 7:17 PM, Mark Williamson
mwilliam...@undo-software.com wrote:
Reviewed-by: Mark Williamson mwilliam...@undo-software.com
On Tue, Jul 21, 2015 at 9:43 AM
Thanks! No outstanding issues with the patchset, from our side.
Reviewed-by: mwilliam...@undo-software.com
On Mon, Jun 15, 2015 at 6:56 AM, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov
>
> This patch removes page-shift bits (scheduled to remove since 3.11) and
> completes
Thanks! No outstanding issues with the patchset, from our side.
Reviewed-by: mwilliam...@undo-software.com
On Mon, Jun 15, 2015 at 6:56 AM, Konstantin Khlebnikov koc...@gmail.com wrote:
From: Konstantin Khlebnikov khlebni...@yandex-team.ru
This patch removes page-shift bits (scheduled to
Hi Konstantin,
Thanks very much for your help on this.
>From our side, I've tested our application against a patched kernel
and I confirm that the functionality can replace what we lost when
PFNs were removed from /proc/PID/pagemap. This addresses the
functionality regression from our PoV (just
One tiny nitpick / typo, inline below - functionally, this looks good
from our side...
Reviewed-by: mwilliam...@undo-software.com
Tested-by: mwilliam...@undo-software.com
On Tue, Jun 9, 2015 at 9:00 PM, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov
<...snip...>
> -#define
This looks good from our side - thanks!
Reviewed-by: mwilliam...@undo-software.com
Tested-by: mwilliam...@undo-software.com
On Tue, Jun 9, 2015 at 9:00 PM, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov
>
> This patch makes pagemap readable for normal users back but hides physical
This looks good from our side - thanks!
Reviewed-by: mwilliam...@undo-software.com
Tested-by: mwilliam...@undo-software.com
On Tue, Jun 9, 2015 at 9:00 PM, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov
>
> This patch sets bit 56 in pagemap if this page is mapped only once.
> It
This looks good from our side - thanks!
Reviewed-by: mwilliam...@undo-software.com
Tested-by: mwilliam...@undo-software.com
On Tue, Jun 9, 2015 at 9:00 PM, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov
>
> This patch moves permission checks from pagemap_read() into pagemap_open().
This looks good from our side - thanks!
Reviewed-by: mwilliam...@undo-software.com
Tested-by: mwilliam...@undo-software.com
On Tue, Jun 9, 2015 at 9:00 PM, Konstantin Khlebnikov koc...@gmail.com wrote:
From: Konstantin Khlebnikov khlebni...@yandex-team.ru
This patch sets bit 56 in pagemap if
This looks good from our side - thanks!
Reviewed-by: mwilliam...@undo-software.com
Tested-by: mwilliam...@undo-software.com
On Tue, Jun 9, 2015 at 9:00 PM, Konstantin Khlebnikov koc...@gmail.com wrote:
From: Konstantin Khlebnikov khlebni...@yandex-team.ru
This patch moves permission checks
This looks good from our side - thanks!
Reviewed-by: mwilliam...@undo-software.com
Tested-by: mwilliam...@undo-software.com
On Tue, Jun 9, 2015 at 9:00 PM, Konstantin Khlebnikov koc...@gmail.com wrote:
From: Konstantin Khlebnikov khlebni...@yandex-team.ru
This patch makes pagemap readable for
One tiny nitpick / typo, inline below - functionally, this looks good
from our side...
Reviewed-by: mwilliam...@undo-software.com
Tested-by: mwilliam...@undo-software.com
On Tue, Jun 9, 2015 at 9:00 PM, Konstantin Khlebnikov koc...@gmail.com wrote:
From: Konstantin Khlebnikov
Hi Konstantin,
Thanks very much for your help on this.
From our side, I've tested our application against a patched kernel
and I confirm that the functionality can replace what we lost when
PFNs were removed from /proc/PID/pagemap. This addresses the
functionality regression from our PoV (just
On Thu, May 14, 2015 at 7:40 PM, Mark Williamson
wrote:
> Hi Konstantin,
>
> I modified our code to check for the map-exclusive flag where it used
> to compare pageframe numbers. First tests look pretty promising, so
> this patch looks like a viable approach for us.
>
> Is ther
On Thu, May 14, 2015 at 7:40 PM, Mark Williamson
mwilliam...@undo-software.com wrote:
Hi Konstantin,
I modified our code to check for the map-exclusive flag where it used
to compare pageframe numbers. First tests look pretty promising, so
this patch looks like a viable approach for us
Hi Konstantin,
On Wed, May 13, 2015 at 11:51 AM, Konstantin Khlebnikov
wrote:
> On 12.05.2015 15:05, Mark Williamson wrote:
>> 1. I was hoping we'd be able to backport a compatible fix to older
>> kernels that might adopt the pagemap permissions change. Using the V2
>> f
, Mark Williamson
wrote:
> Hi Konstantin,
>
> Thanks very much for continuing to look at this! It's very much
> appreciated. I've been investigating from our end but got caught up
> in some gnarly details of our pagemap-consuming code.
>
> I like the approach and it seems
, Mark Williamson
mwilliam...@undo-software.com wrote:
Hi Konstantin,
Thanks very much for continuing to look at this! It's very much
appreciated. I've been investigating from our end but got caught up
in some gnarly details of our pagemap-consuming code.
I like the approach and it seems like
Hi Konstantin,
On Wed, May 13, 2015 at 11:51 AM, Konstantin Khlebnikov
khlebni...@yandex-team.ru wrote:
On 12.05.2015 15:05, Mark Williamson wrote:
snip
1. I was hoping we'd be able to backport a compatible fix to older
kernels that might adopt the pagemap permissions change. Using the V2
Hi Konstantin,
I hope you won't mind me thinking out loud here on the idea of adding
a flag to the v2 pagemap fields... From a kernel PoV, I agree that
this seems like the cleanest approach. However, with my application
developer hat on:
1. I was hoping we'd be able to backport a compatible
Hi Konstantin,
Comments inline...
On Tue, May 12, 2015 at 10:43 AM, Konstantin Khlebnikov
wrote:
> This patch makes pagemap readable for normal users back but hides physical
> addresses from them. For some use cases PFN isn't required at all: flags
> give information about presence, page type
Hi Konstantin,
Thanks very much for continuing to look at this! It's very much
appreciated. I've been investigating from our end but got caught up
in some gnarly details of our pagemap-consuming code.
I like the approach and it seems like the information you're exposing
will be useful for our
Hi Konstantin,
Thanks very much for continuing to look at this! It's very much
appreciated. I've been investigating from our end but got caught up
in some gnarly details of our pagemap-consuming code.
I like the approach and it seems like the information you're exposing
will be useful for our
Hi Konstantin,
I hope you won't mind me thinking out loud here on the idea of adding
a flag to the v2 pagemap fields... From a kernel PoV, I agree that
this seems like the cleanest approach. However, with my application
developer hat on:
1. I was hoping we'd be able to backport a compatible
Hi Konstantin,
Comments inline...
On Tue, May 12, 2015 at 10:43 AM, Konstantin Khlebnikov
khlebni...@yandex-team.ru wrote:
This patch makes pagemap readable for normal users back but hides physical
addresses from them. For some use cases PFN isn't required at all: flags
give information about
>> Something like this (see patch in attachment)
>
> THP is not covered.
>
> Any comments on kcmp() idea?
It seems like a modified kcmp() would also be a valid approach but, as
you noted, probably speed-limited for our purposes. As you say, there
is the option of a vector-oriented equivalent.
Hi all,
On Thu, Apr 30, 2015 at 2:11 PM, Konstantin Khlebnikov wrote:
> On Thu, Apr 30, 2015 at 2:43 PM, Konstantin Khlebnikov
> wrote:
>> What about exposing shared/exclusive bit in pagemap == 1 if
>> page_mapcount() > 1, otherwise 0 (or vise versa).
>>
>> Seems like this should work for
On Wed, Apr 29, 2015 at 10:02 PM, Linus Torvalds
wrote:
> On Wed, Apr 29, 2015 at 1:44 PM, Konstantin Khlebnikov
> wrote:
>>
>> This's no longer true. After recent fixes for "anon_vma endless growing" new
>> vma
>> might reuse old anon_vma from grandparent vma.
>
> Oh well. I guess that was
On Wed, Apr 29, 2015 at 10:02 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Apr 29, 2015 at 1:44 PM, Konstantin Khlebnikov koc...@gmail.com
wrote:
This's no longer true. After recent fixes for anon_vma endless growing new
vma
might reuse old anon_vma from grandparent vma.
Hi all,
On Thu, Apr 30, 2015 at 2:11 PM, Konstantin Khlebnikov koc...@gmail.com wrote:
On Thu, Apr 30, 2015 at 2:43 PM, Konstantin Khlebnikov koc...@gmail.com
wrote:
What about exposing shared/exclusive bit in pagemap == 1 if
page_mapcount() 1, otherwise 0 (or vise versa).
Seems like this
Something like this (see patch in attachment)
THP is not covered.
Any comments on kcmp() idea?
It seems like a modified kcmp() would also be a valid approach but, as
you noted, probably speed-limited for our purposes. As you say, there
is the option of a vector-oriented equivalent. It
Hi,
On Wed, Apr 29, 2015 at 8:36 PM, Kirill A. Shutemov
wrote:
> On Wed, Apr 29, 2015 at 07:44:57PM +0100, Mark Williamson wrote:
>> Hi all,
... snip ...
>> For context, we were previously using pagemap as a cross-platform way
>> to get soft-dirty-like functionality. Spec
Hi again,
On Wed, Apr 29, 2015 at 7:44 PM, Mark Williamson
wrote:
> We've been investigating further and found a snag with the PFN-hiding
> approach discussed last week - looks like it won't be enough on all
> the architectures we support. Our product runs on x86_32, x86_64 and
> A
post another thread for.
On Fri, Apr 24, 2015 at 5:43 PM, Mark Williamson
wrote:
> Hi Mark,
>
> On Fri, Apr 24, 2015 at 4:26 PM, Mark Seaborn wrote:
>> I'm curious, what do you use the physical page addresses for?
>>
>> Since you pointed to http://undo-software.com, whi
Hi Andy,
On Fri, Apr 24, 2015 at 5:10 PM, Andy Lutomirski wrote:
> Even though I've been accused (correctly?) of suggesting that, I'm not
> sure I like it anymore. Suppose I map some anonymous memory, learn
> its (scrambled) pfn, then unmap it and remap a setuid file. Now I can
> tell whether
Hi again,
On Wed, Apr 29, 2015 at 7:44 PM, Mark Williamson
mwilliam...@undo-software.com wrote:
We've been investigating further and found a snag with the PFN-hiding
approach discussed last week - looks like it won't be enough on all
the architectures we support. Our product runs on x86_32
for.
On Fri, Apr 24, 2015 at 5:43 PM, Mark Williamson
mwilliam...@undo-software.com wrote:
Hi Mark,
On Fri, Apr 24, 2015 at 4:26 PM, Mark Seaborn mseab...@chromium.org wrote:
I'm curious, what do you use the physical page addresses for?
Since you pointed to http://undo-software.com, which talks
Hi,
On Wed, Apr 29, 2015 at 8:36 PM, Kirill A. Shutemov
kir...@shutemov.name wrote:
On Wed, Apr 29, 2015 at 07:44:57PM +0100, Mark Williamson wrote:
Hi all,
... snip ...
For context, we were previously using pagemap as a cross-platform way
to get soft-dirty-like functionality. Specifically
Hi Andy,
On Fri, Apr 24, 2015 at 5:10 PM, Andy Lutomirski l...@amacapital.net wrote:
Even though I've been accused (correctly?) of suggesting that, I'm not
sure I like it anymore. Suppose I map some anonymous memory, learn
its (scrambled) pfn, then unmap it and remap a setuid file. Now I can
Hi Linus,
Thanks for responding so quickly!
On Fri, Apr 24, 2015 at 5:08 PM, Linus Torvalds
wrote:
> So the one exception to the regression rule is "security fixes", but
> even for security fixes we do try to be as reasonable as humanly
> possible to make them not break things.
Understood -
Hi Mark,
On Fri, Apr 24, 2015 at 4:26 PM, Mark Seaborn wrote:
> I'm curious, what do you use the physical page addresses for?
>
> Since you pointed to http://undo-software.com, which talks about
> reversible debugging tools, I can guess you would use the soft-dirty
> flag to implement
e physical pageframe addresses zeroed.
Would this be an acceptable approach?
Thank you,
Mark Williamson
---
Undo Software - http://undo-software.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
Hi Linus,
Thanks for responding so quickly!
On Fri, Apr 24, 2015 at 5:08 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
So the one exception to the regression rule is security fixes, but
even for security fixes we do try to be as reasonable as humanly
possible to make them not break
Hi Mark,
On Fri, Apr 24, 2015 at 4:26 PM, Mark Seaborn mseab...@chromium.org wrote:
I'm curious, what do you use the physical page addresses for?
Since you pointed to http://undo-software.com, which talks about
reversible debugging tools, I can guess you would use the soft-dirty
flag to
up with a patch that provides unprivileged access
to /proc/PID/pagemap with the physical pageframe addresses zeroed.
Would this be an acceptable approach?
Thank you,
Mark Williamson
---
Undo Software - http://undo-software.com/
--
To unsubscribe from this list: send the line unsubscribe linux
> Really the only sane way of keeping track of whiteouts seems some external
> store. We did an experiment with Unionfs, and moving the whiteout handling
> to effectively a "library" that did all the dirty work cleaned up the code
> considerably [2,3].
What about keeping track of whiteouts in a
Really the only sane way of keeping track of whiteouts seems some external
store. We did an experiment with Unionfs, and moving the whiteout handling
to effectively a library that did all the dirty work cleaned up the code
considerably [2,3].
What about keeping track of whiteouts in a special
> I reviewed your sample implementation, and it appears to infringe 3
> patents already.You should do some research on this.
Are you able to tell us which areas of the code infringe existing patents?
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no
I reviewed your sample implementation, and it appears to infringe 3
patents already.You should do some research on this.
Are you able to tell us which areas of the code infringe existing patents?
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no
> > +
> > + err = xenbus_printf(xbt, dev->nodename,
> > + "ring-ref","%u", info->ring_ref);
>
> why do you need your own printf?
xenbus_printf isn't a printf replacement - it is used for writing a formatted
string into XenStore (which contains VM configuration data in a
+
+ err = xenbus_printf(xbt, dev-nodename,
+ ring-ref,%u, info-ring_ref);
why do you need your own printf?
xenbus_printf isn't a printf replacement - it is used for writing a formatted
string into XenStore (which contains VM configuration data in a
> > - Pseudo faults:
>
> These are a problem, because they turn what would be a single
> pageout into a pageout, a pagein, and another pageout, in
> effect tripling the amount of IO that needs to be done.
The Disco VMM tackled this by detecting attempts to double-page using a
special virtual
- Pseudo faults:
These are a problem, because they turn what would be a single
pageout into a pageout, a pagein, and another pageout, in
effect tripling the amount of IO that needs to be done.
The Disco VMM tackled this by detecting attempts to double-page using a
special virtual swap
64 matches
Mail list logo
