On Fri, Jan 22, 2016 at 11:42 AM, Christian Borntraeger
wrote:
>
> Just want to mention that this patch breaks older versions of valgrind
> (including the current release)
> https://bugs.kde.org/show_bug.cgi?id=357833
Ugh. Looks like valgrind is doing something that fundamentally can't
be
On Fri, 22 Jan 2016 20:42:11 +0100 Christian Borntraeger
wrote:
> On 12/28/2015 11:22 PM, Linus Torvalds wrote:
> > On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
> >> Really sorry for delays. Konstantin, I slightly updated the
> >> changelog (to point where problem came from). Linus
On Fri, Jan 22, 2016 at 08:42:11PM +0100, Christian Borntraeger wrote:
> On 12/28/2015 11:22 PM, Linus Torvalds wrote:
> > On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
> >> Really sorry for delays. Konstantin, I slightly updated the
> >> changelog (to point where problem came from).
On 12/28/2015 11:22 PM, Linus Torvalds wrote:
> On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
>> Really sorry for delays. Konstantin, I slightly updated the
>> changelog (to point where problem came from). Linus are you
>> fine with accounting not only anonymous memory in VmData?
>
>
On Fri, 22 Jan 2016 20:42:11 +0100 Christian Borntraeger
wrote:
> On 12/28/2015 11:22 PM, Linus Torvalds wrote:
> > On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
> >> Really sorry for delays. Konstantin, I slightly updated the
> >>
On Fri, Jan 22, 2016 at 08:42:11PM +0100, Christian Borntraeger wrote:
> On 12/28/2015 11:22 PM, Linus Torvalds wrote:
> > On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
> >> Really sorry for delays. Konstantin, I slightly updated the
> >> changelog (to point where
On Fri, Jan 22, 2016 at 11:42 AM, Christian Borntraeger
wrote:
>
> Just want to mention that this patch breaks older versions of valgrind
> (including the current release)
> https://bugs.kde.org/show_bug.cgi?id=357833
Ugh. Looks like valgrind is doing something that
On 12/28/2015 11:22 PM, Linus Torvalds wrote:
> On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
>> Really sorry for delays. Konstantin, I slightly updated the
>> changelog (to point where problem came from). Linus are you
>> fine with accounting not only anonymous
On Mon, Dec 28, 2015 at 03:10:02PM -0800, Andrew Morton wrote:
> On Tue, 29 Dec 2015 00:10:15 +0300 Cyrill Gorcunov wrote:
...
>
> This clashes with
> mm-mmapc-remove-redundant-local-variables-for-may_expand_vm.patch,
> below. I resolved it thusly:
>
> bool may_expand_vm(struct mm_struct *mm,
On Mon, Dec 28, 2015 at 02:22:23PM -0800, Linus Torvalds wrote:
> On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
> > Really sorry for delays. Konstantin, I slightly updated the
> > changelog (to point where problem came from). Linus are you
> > fine with accounting not only anonymous
On Mon, Dec 28, 2015 at 02:22:23PM -0800, Linus Torvalds wrote:
> On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
> > Really sorry for delays. Konstantin, I slightly updated the
> > changelog (to point where problem came from). Linus are you
> > fine with accounting
On Mon, Dec 28, 2015 at 03:10:02PM -0800, Andrew Morton wrote:
> On Tue, 29 Dec 2015 00:10:15 +0300 Cyrill Gorcunov wrote:
...
>
> This clashes with
> mm-mmapc-remove-redundant-local-variables-for-may_expand_vm.patch,
> below. I resolved it thusly:
>
> bool
On Tue, 29 Dec 2015 00:10:15 +0300 Cyrill Gorcunov wrote:
> When inspecting a vague code inside prctl(PR_SET_MM_MEM)
> call (which testing the RLIMIT_DATA value to figure out
> if we're allowed to assign new @start_brk, @brk, @start_data,
> @end_data from mm_struct) it's been commited that
On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
> Really sorry for delays. Konstantin, I slightly updated the
> changelog (to point where problem came from). Linus are you
> fine with accounting not only anonymous memory in VmData?
The patch looks ok to me. I guess if somebody relies on
Really sorry for delays. Konstantin, I slightly updated the
changelog (to point where problem came from). Linus are you
fine with accounting not only anonymous memory in VmData?
Guys, take a look please, comments are highly appreciated.
---
From: Konstantin Khlebnikov
When inspecting a vague
On Mon, Dec 28, 2015 at 1:10 PM, Cyrill Gorcunov wrote:
> Really sorry for delays. Konstantin, I slightly updated the
> changelog (to point where problem came from). Linus are you
> fine with accounting not only anonymous memory in VmData?
The patch looks ok to me. I guess if
Really sorry for delays. Konstantin, I slightly updated the
changelog (to point where problem came from). Linus are you
fine with accounting not only anonymous memory in VmData?
Guys, take a look please, comments are highly appreciated.
---
From: Konstantin Khlebnikov
When
On Tue, 29 Dec 2015 00:10:15 +0300 Cyrill Gorcunov wrote:
> When inspecting a vague code inside prctl(PR_SET_MM_MEM)
> call (which testing the RLIMIT_DATA value to figure out
> if we're allowed to assign new @start_brk, @brk, @start_data,
> @end_data from mm_struct) it's been
On Mon, Dec 14, 2015 at 11:12:38AM +0300, Konstantin Khlebnikov wrote:
> Here several rated changes bundled together:
> * keep vma counting if CONFIG_PROC_FS=n, will be used for limits
> * replace mm->shared_vm with better defined mm->data_vm
> * account anonymous executable areas as executable
>
Here several rated changes bundled together:
* keep vma counting if CONFIG_PROC_FS=n, will be used for limits
* replace mm->shared_vm with better defined mm->data_vm
* account anonymous executable areas as executable
* account file-backed growsdown/up areas as stack
* drop struct file* argument
On Mon, Dec 14, 2015 at 11:12:38AM +0300, Konstantin Khlebnikov wrote:
> Here several rated changes bundled together:
> * keep vma counting if CONFIG_PROC_FS=n, will be used for limits
> * replace mm->shared_vm with better defined mm->data_vm
> * account anonymous executable areas as executable
>
Here several rated changes bundled together:
* keep vma counting if CONFIG_PROC_FS=n, will be used for limits
* replace mm->shared_vm with better defined mm->data_vm
* account anonymous executable areas as executable
* account file-backed growsdown/up areas as stack
* drop struct file* argument
22 matches
Mail list logo