On 1/29/24 08:44, Christian König wrote:
> Am 26.01.24 um 17:29 schrieb Matthew Brost:
>> On Fri, Jan 26, 2024 at 11:32:57AM +0100, Christian König wrote:
>>> Am 25.01.24 um 18:30 schrieb Matthew Brost:
On Thu, Jan 25, 2024 at 04:12:58PM +0100, Christian König wrote:
> Am 24.01.24 um
ail.com/
> Reported-and-tested-by: Mario Limonciello
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3124
> Link:
> https://lore.kernel.org/all/20240123021155.2775-1-mario.limoncie...@amd.com/
> Reported-by: Vlastimil Babka
Can change to Reported-and-tested-by:
On 1/23/24 03:11, Mario Limonciello wrote:
> commit f7fe64ad0f22 ("drm/sched: Split free_job into own work item")
> causes graphics hangs at GDM or right after logging in on a
> Framework 13 AMD laptop (containing a Phoenix APU).
>
> This reverts commit f7fe64ad0f22ff034f8ebcfbd7299ee9cc9b57d7.
>
On 1/24/24 16:31, Donald Carr wrote:
> On Wed, Jan 24, 2024 at 7:06 AM Vlastimil Babka wrote:
>> When testing the rc1 on my openSUSE Tumbleweed desktop, I've started
>> experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that
>> everything freeze
On 1/10/24 20:49, Dave Airlie wrote:
> Hi Linus,
>
> This is the main drm pull request for 6.8.
When testing the rc1 on my openSUSE Tumbleweed desktop, I've started
experiencing "frozen desktop" (KDE/Wayland) issues. The symptoms are that
everything freezes including mouse cursor. After a while
On 7/12/23 18:24, Felix Kuehling wrote:
> Allocations in the heap and stack tend to be small, with several
> allocations sharing the same page. Sharing the same page for different
> allocations with different access patterns leads to thrashing when we
> migrate data back and forth on GPU and
On 6/22/23 10:53, Qi Zheng wrote:
> The shrinker_rwsem is a global read-write lock in
> shrinkers subsystem, which protects most operations
> such as slab shrink, registration and unregistration
> of shrinkers, etc. This can easily cause problems in
> the following cases.
>
> 1) When the memory
On 6/22/23 10:53, Qi Zheng wrote:
> The mm/vmscan.c file is too large, so separate the shrinker-related
> code from it into a separate file. No functional changes.
>
> Signed-off-by: Qi Zheng
Maybe do this move as patch 01 so the further changes are done in the new
file already?
On 6/22/23 10:53, Qi Zheng wrote:
> To prepare for the dynamic allocation of shrinker instances
> embedded in other structures, add a private_data field to
> struct shrinker, so that we can use shrinker::private_data
> to record and get the original embedded structure.
>
> Signed-off-by: Qi Zheng
On 12/1/22 15:16, Konstantin Ryabitsev wrote:
On Thu, Dec 01, 2022 at 02:34:41PM +0100, Javier Martinez Canillas wrote:
Konstantin,
Can you add a rule in b4 to exclude sta...@vger.kernel.org
(sta...@kernel.org as well?) from getting the whole patchset?
sta...@kernel.org is a pipe to
ple, a VM running with VFIO could run into the memlock limit and
> fail to run. However, we essentially had the same behavior already in
> commit 17839856fd58 ("gup: document and work around "COW can break either
> way" issue") which got merged into some enterprise distros, and there were
> not any such complaints. So most probably, we're fine.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Vlastimil Babka
pud() also handles it
> correctly, for example, splitting the huge zeropage on FAULT_FLAG_UNSHARE
> such that we can handle FAULT_FLAG_UNSHARE on the PTE level.
>
> This change is a requirement for reliable long-term R/O pinning in
> COW mappings.
>
> Signed-off-by: David Hildenb
; Let's just split (->zap) + fallback in that case.
>
> This is a preparation for more generic FAULT_FLAG_UNSHARE support in
> COW mappings.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Vlastimil Babka
Nits:
> ---
> mm/memory.c | 24 +++-
>
ate mappings last.
>
> While at it, use folio-based functions instead of page-based functions
> where we touch the code either way.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Vlastimil Babka
preparation for reliable R/O long-term pinning of pages in
> private mappings, whereby we want to make sure that we will never break
> COW in a read-only private mapping.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Vlastimil Babka
> ---
> mm/memory.c | 8
>
-
> mm/huge_memory.c | 3 ---
> mm/hugetlb.c | 5 -
> mm/memory.c | 23 ---
> 3 files changed, 20 insertions(+), 11 deletions(-)
Reviewed-by: Vlastimil Babka
te it. So let's prepare for non-anon
> tests by renaming to "cow".
>
> Signed-off-by: David Hildenbrand
Acked-by: Vlastimil Babka
On 9/28/22 14:01, Alistair Popple wrote:
> This series aims to fix a number of page reference counting issues in
> drivers dealing with device private ZONE_DEVICE pages. These result in
> use-after-free type bugs, either from accessing a struct page which no
> longer exists because it has been
Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Vlastimil Babka
Cc: Roman Gushchin
Cc: Hyeonggon Yoo <42.hye...@gmail.com>
Cc: Marco Elver
Cc: linux...@kvack.org
Signed-off-by: Kees Cook
Thanks for your patch, which is now commit 63caa04ec60583b1 ("slab:
Remove __
Morton
Cc: Vlastimil Babka
Cc: Roman Gushchin
Cc: Hyeonggon Yoo <42.hye...@gmail.com>
Cc: Marco Elver
Cc: linux...@kvack.org
Signed-off-by: Kees Cook
Thanks for your patch, which is now commit 63caa04ec60583b1 ("slab:
Remove __malloc attribute from realloc functions") in next-2022092
On 9/23/22 22:28, Kees Cook wrote:
Round up allocations with kmalloc_size_roundup() so that mempool's use
of ksize() is always accurate and no special handling of the memory is
needed by KASAN, UBSAN_BOUNDS, nor FORTIFY_SOURCE.
Cc: Andrew Morton
Cc: linux...@kvack.org
Signed-off-by: Kees Cook
ld I get for a given size?".
Introduce kmalloc_size_roundup(), to serve this function so we can start
replacing the "anticipatory resizing" uses of ksize().
[1] https://github.com/ClangBuiltLinux/linux/issues/1599
https://github.com/KSPP/linux/issues/183
Cc: Vlastimil Babka
Cc:
On 9/22/22 23:49, Kees Cook wrote:
> On Thu, Sep 22, 2022 at 11:05:47PM +0200, Vlastimil Babka wrote:
>> On 9/22/22 17:55, Kees Cook wrote:
>> > On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote:
>> > [...]
>> > > So when this patch set is ab
On 9/22/22 17:55, Kees Cook wrote:
> On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote:
>> Am 22.09.22 um 05:10 schrieb Kees Cook:
>> > Hi,
>> >
>> > This series fixes up the cases where callers of ksize() use it to
>> > opportunistically grow their buffer sizes, which can run afoul
s, plus it's a bit more meaningful in
> what we're checking for here.
>
> Signed-off-by: Daniel Vetter
> Cc: Andrew Morton
> Cc: linux...@kvack.org
Reviewed-by: Vlastimil Babka
> ---
> mm/mempool.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
On 6/5/22 17:25, Daniel Vetter wrote:
> ... instead of open codding it. Completely equivalent code, just
> a notch more meaningful when reading.
>
> Signed-off-by: Daniel Vetter
> Cc: Andrew Morton
> Cc: linux...@kvack.org
Reviewed-by: Vlastimil Babka
> ---
> mm/pag
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Joonsoo Kim
> Cc: Andrew Morton
> Cc: Vlastimil Babka
> Cc: Roman Gushchin
> Cc: linux...@kvack.org
Thanks, added to slab/for-5.20/cleanup as it's slab-specific and independent
from 1/3 and 3/3.
ng
> it on to stack_depot_save().
>
> Rather than adding filter_irq_stacks() to all current users of
> stack_depot_save(), it became clear that stack_depot_save() should
> simply do filter_irq_stacks().
Agree.
> Signed-off-by: Marco Elver
Acked-by: Vlastimil Babka
Thanks.
> ---
On 10/22/21 05:38, Andrew Morton wrote:
> On Thu, 21 Oct 2021 19:51:20 +0200 Vlastimil Babka wrote:
>
>> >> Then we have to figure out how to order a fix between DRM and mmotm...
>> >
>> > That is the question! The problem exists only in the merge
On 10/21/21 10:40, Jani Nikula wrote:
> On Thu, 21 Oct 2021, Vlastimil Babka wrote:
>> This one seems a bit more tricky and I could really use some advice.
>> cd06ab2fd48f adds stackdepot usage to drm_modeset_lock which itself has a
>> number of different users and re
On 10/20/21 20:24, Naresh Kamboju wrote:
> Following kernel crash noticed on linux next 20211020 tag.
> while booting on arm64 architecture dragonboard 410c device.
>
> I see the following config is enabled in 20211020 tag builds.
> CONFIG_STACKDEPOT=y
>
> Crash log,
> [ 18.583097] Unable to
On 10/13/21 09:30, Vlastimil Babka wrote:
> Currently, enabling CONFIG_STACKDEPOT means its stack_table will be allocated
> from memblock, even if stack depot ends up not actually used. The default size
> of stack_table is 4MB on 32-bit, 8MB on 64-bit.
>
> This is fine for use-case
On 10/14/21 12:16, Mike Rapoport wrote:
> On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
>> On 10/14/21 10:54, kernel test robot wrote:
>>
>> In my local testing of the patch, when stackdepot was initialized through
>> page owner init,
kvmalloc()")
> url:
> https://github.com/0day-ci/linux/commits/Vlastimil-Babka/lib-stackdepot-allow-optional-init-and-stack_table-allocation-by-kvmalloc/20211012-170816
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
>
> in testcase: rcutorture
> version:
&
), and don't
unnecessarily align the memblock allocation to its own size anymore.
[1]
https://lore.kernel.org/all/CAMuHMdW=eovzm1re5fvoen87nkfilmm2+ah7enu2kxehcvb...@mail.gmail.com/
Signed-off-by: Vlastimil Babka
Acked-by: Dmitry Vyukov
Reviewed-by: Marco Elver # stackdepot
Cc: Marco Elver
Cc
), and don't
unnecessarily align the memblock allocation to its own size anymore.
[1]
https://lore.kernel.org/all/CAMuHMdW=eovzm1re5fvoen87nkfilmm2+ah7enu2kxehcvb...@mail.gmail.com/
Signed-off-by: Vlastimil Babka
Acked-by: Dmitry Vyukov
Cc: Marco Elver
Cc: Vijayanand Jitta
Cc: Maarten Lankhorst
On 10/11/21 19:08, Marco Elver wrote:
> On Mon, 11 Oct 2021 at 19:02, Vlastimil Babka wrote:
> [...]
>> > On the other hand, the lazy initialization mode you're introducing
>> > requires an explicit stack_depot_init() call somewhere and isn't as
>> > straightforw
On 10/7/21 13:01, Marco Elver wrote:
> On Thu, Oct 07, 2021 at 11:58AM +0200, Vlastimil Babka wrote:
> [...]
>> - Add a CONFIG_STACKDEPOT_ALWAYS_INIT flag to keep using the current
>> well-defined point of allocation as part of mem_init(). Make CONFIG_KASAN
>> sele
unnecessarily align the memblock allocation to its own size anymore.
[1]
https://lore.kernel.org/all/CAMuHMdW=eovzm1re5fvoen87nkfilmm2+ah7enu2kxehcvb...@mail.gmail.com/
Signed-off-by: Vlastimil Babka
Cc: Marco Elver
Cc: Vijayanand Jitta
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas
On 9/10/21 16:10, Imran Khan wrote:
> This change is in response to discussion at [1].
> The patch has been created on top of my earlier changes [2] and [3].
> If needed I can resend all of these patches together, though my
> earlier patches have been Acked.
I think you sent those at the
so change above mentioned users to use this helper.
>
> Signed-off-by: Imran Khan
> Suggested-by: Vlastimil Babka
Acked-by: Vlastimil Babka
A comment below:
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -214,6 +214,29 @@ static inline struct stack_record *find_sta
On 8/25/21 19:49, Ralph Campbell wrote:
>
> On 8/25/21 4:15 AM, Vlastimil Babka wrote:
>> On 8/25/21 05:48, Alex Sierra wrote:
>>> From: Ralph Campbell
>>>
>>> ZONE_DEVICE struct pages have an extra reference count that complicates the
>>> code
On 8/25/21 05:48, Alex Sierra wrote:
> From: Ralph Campbell
>
> ZONE_DEVICE struct pages have an extra reference count that complicates the
> code for put_page() and several places in the kernel that need to check the
> reference count to see that a page is not being used (gup, compaction,
>
On 4/9/21 9:17 AM, Christian König wrote:
> To be able to switch to a spinlock and reduce lock contention in the TTM
> shrinker we don't want to hold a mutex while unmapping and freeing pages
> from the pool.
Does using spinlock instead of mutex really reduce lock contention?
> But then we
who use
regular krealloc() to reallocate arrays. Let's provide an actual
krealloc_array() implementation.
Signed-off-by: Bartosz Golaszewski
Makes sense.
Acked-by: Vlastimil Babka
---
include/linux/slab.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/slab.h
contexts.
Cc: Paul E. McKenney
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Vlastimil Babka
Cc: Mathieu Desnoyers
Cc: Sebastian Andrzej Siewior
Cc: Michel Lespinasse
Cc: Daniel Vetter
Cc: Waiman Long
Cc
On 8/17/19 2:20 AM, Petr Vandrovec wrote:
> Vlastimil Babka wrote on 8/16/2019 5:47 AM:
>> On 8/15/19 9:13 PM, Petr Vandrovec wrote:
>>> With iommu=off disks are visible, but USB keyboard (and other USB
>>> devices) does not work:
>>
>> I've been told io
On 8/15/19 9:13 PM, Petr Vandrovec wrote:
> Vlastimil Babka wrote on 8/15/2019 7:32 AM:
>>
>> Does the issue still happen with rc4? Could you apply the 3 attached
>> patches (work in progress), configure-enable CONFIG_DEBUG_PAGEALLOC and
>> CONFIG_PAGE_OWNER and boot
rc4? Could you apply the 3 attached
patches (work in progress), configure-enable CONFIG_DEBUG_PAGEALLOC and
CONFIG_PAGE_OWNER and boot kernel with debug_pagealloc=on page_owner=on
parameters? That should print stacktraces of allocation and first
freeing (assuming this is a double free).
Vlastimil
>From 5b4c
You should have CC'd the ION maintainers/lists per
./scripts/get_maintainer.pl - CCing now.
On 3/14/19 12:06 PM, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> Two action for this patch:
> 1. set a batch size for system heap's shrinker, which can have it buffer
> reasonable page blocks in
On 07/12/2018 08:45 AM, Joe Perches wrote:
> On Wed, 2018-07-11 at 20:50 +0200, Daniel Vetter wrote:
>> On Wed, Jul 11, 2018 at 8:30 PM, Jens Axboe wrote:
>>> On 7/11/18 10:45 AM, Tejun Heo wrote:
On Wed, Jul 11, 2018 at 09:40:58AM -0700, Tejun Heo wrote:
> On Mon, Jul 09, 2018 at
On 12/01/2016 10:02 PM, Michal Nazarewicz wrote:
> On Thu, Dec 01 2016, Michal Hocko wrote:
>> I am not familiar with this code so I cannot really argue but a quick
>> look at rmem_cma_setup doesn't suggest any speicific placing or
>> anything...
>
> early_cma parses âcmaâ command line
On 12/01/2016 08:21 AM, Michal Hocko wrote:
> Forgot to CC Joonsoo. The email thread starts more or less here
> http://lkml.kernel.org/r/20161130092239.GD18437 at dhcp22.suse.cz
>
> On Thu 01-12-16 08:15:07, Michal Hocko wrote:
>> On Wed 30-11-16 20:19:03, Robin H. Johnson wrote:
>> [...]
>> >
On 12/01/2016 07:21 AM, Robin H. Johnson wrote:
> On Wed, Nov 30, 2016 at 10:24:59PM +0100, Vlastimil Babka wrote:
>> [add more CC's]
>>
>> On 11/30/2016 09:19 PM, Robin H. Johnson wrote:
>> > Somewhere in the Radeon/DRM codebase, CMA page allocation has either
[add more CC's]
On 11/30/2016 09:19 PM, Robin H. Johnson wrote:
> Somewhere in the Radeon/DRM codebase, CMA page allocation has either
> regressed in the timeline of 4.5->4.9, and/or the drm/radeon code is
> doing something different with pages.
Could be that it didn't use
On 05/31/2016 02:01 AM, Minchan Kim wrote:
> Per Vlastimi's review comment.
>
> Thanks for the detail review, Vlastimi!
> If you have another concern, feel free to say.
I don't for now :)
[...]
> Cc: Rik van Riel
> Cc: Vlastimil Babka
> Cc: Joonsoo Kim
> Cc: Mel Go
On 05/30/2016 06:25 PM, Minchan Kim wrote:
>>> --- a/mm/compaction.c
>>> +++ b/mm/compaction.c
>>> @@ -81,6 +81,39 @@ static inline bool migrate_async_suitable(int
>>> migratetype)
>>>
>>> #ifdef CONFIG_COMPACTION
>>>
>>> +int PageMovable(struct page *page)
>>> +{
>>> + struct address_space
On 05/30/2016 03:39 AM, Minchan Kim wrote:
> After isolation, VM calls migratepage of driver with isolated page.
> The function of migratepage is to move content of the old page to new page
> and set up fields of struct page newpage. Keep in mind that you should
> clear PG_movable of oldpage via
On 05/30/2016 03:33 AM, Minchan Kim wrote:
>>
>>
>>> + page->mapping = (void *)((unsigned long)page->mapping &
>>> + PAGE_MAPPING_MOVABLE);
>>
>> This should be negated to clear... use ~PAGE_MAPPING_MOVABLE ?
>
> No.
>
> The intention is to clear only mapping value but
On 05/20/2016 04:23 PM, Minchan Kim wrote:
> We have allowed migration for only LRU pages until now and it was
> enough to make high-order pages. But recently, embedded system(e.g.,
> webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
> so we have seen several reports about
On 04/04/2016 07:12 AM, Minchan Kim wrote:
> On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote:
>> Might have been better as a separate migration patch and then a
>> compaction patch. It's prefixed mm/compaction, but most changed are
>> in mm/migrate.c
>
>
of subsystem should
> clear PG_isolated via ClearPageIsolated.
>
> 5. If a subsystem want to release isolated page, it should
> clear PG_isolated but not PG_movable. Instead, VM will do it.
Under lock? Or just with ClearPageIsolated?
> Cc: Vlastimil Babka
> Cc: Mel Gorman
>
fires its first vblank irq after
> drm_vblank_post_modeset() was already called.
>
> Reported-by: Vlastimil Babka
> Signed-off-by: Mario Kleiner
> Reviewed-by: Daniel Vetter
> Tested-by: Vlastimil Babka
FWIW I have applied patches 1-4 of this v2 to 4.4.2 and it works fine so
fires its first vblank irq after
> drm_vblank_post_modeset() was already called.
>
> Reported-by: Vlastimil Babka
FWIW, I've applied the whole patchset to 4.4 and the kde5 login problem
didn't occur. I can test the next version too.
Thanks,
Vlastimil
On 02/08/2016 02:58 AM, Mario Kleiner wrote:
Now i just need to actually code and test it first.
>>>
>>> Ping, any news? :)
>>>
>
> Ok, so that series "drm vblank regression fixes for Linux 4.4+" i just
> sent out should hopefully fix this bug and related bugs.
Thanks, I'll test on Wed
On 01/22/2016 06:08 PM, Mario Kleiner wrote:
> Anyway, some more hours of thinking and code browsing later, now i think
> i have a simple and safe solution which should hopefully restore the
> drm_vblank_pre/post_modeset behaviour with only a few lines of core
> code. At the same time it should
ual glitch could
> happen. However that glitch would hopefully be hidden by the blanking of
> the crtc during modeset. A small fix to power management makes sure to
> check for this and prevent unbalanced vblank reference counts due to
> mismatched drm_vblank_get/put.
>
> Reported
On 01/21/2016 09:28 AM, Mario Kleiner wrote:
>> ... just like drm_vblank_pre/post_modeset. That those were broken is a
>> regression which needs to be fixed anyway. I don't think switching to
>> drm_vblank_on/off is suitable for stable trees.
>>
>> Looking at Vlastimil's original post again, I'd
On 01/18/2016 11:49 AM, Vlastimil Babka wrote:
> On 01/16/2016 05:24 AM, Mario Kleiner wrote:
>>
>>
>> On 01/15/2016 01:26 PM, Ville Syrjälä wrote:
>>> On Fri, Jan 15, 2016 at 11:34:08AM +0100, Vlastimil Babka wrote:
>>
>> I'm currently running...
&g
On 01/18/2016 11:49 AM, Vlastimil Babka wrote:
> On 01/16/2016 05:24 AM, Mario Kleiner wrote:
>> I think a drm.debug=0x21 setting and grep'ping the syslog for "vblank"
>> should probably give useful info around the time of the hang.
>
> Attached. Captured b
On 01/16/2016 05:24 AM, Mario Kleiner wrote:
>
>
> On 01/15/2016 01:26 PM, Ville Syrjälä wrote:
>> On Fri, Jan 15, 2016 at 11:34:08AM +0100, Vlastimil Babka wrote:
>
> I'm currently running...
>
> while xinit /usr/bin/ksplashqml --test -- :1 ; do echo yay; done
On 01/15/2016 01:26 PM, Ville Syrjälä wrote:
> On Fri, Jan 15, 2016 at 11:34:08AM +0100, Vlastimil Babka wrote:
>>
>> I have suspected that kwin is waiting for some event, but nevertheless
>> tried bisecting the kernel between 4.3 and 4.4, which lead to:
>
Hi,
since kernel 4.4 I'm unable to login to kde5 desktop (on openSUSE
Tumbleweed). There's a screen with progressbar showing the startup,
which normally fades away after reaching 100%. But with kernel 4.4, the
progress gets stuck somewhere between 1/2 and 3/4 (not always the same).
Top shows
On 08/26/2015 09:20 AM, Michal Hocko wrote:
> On Tue 25-08-15 15:03:00, Eric B Munson wrote:
> [...]
>> Would you drop your objections to the VMA flag if I drop the portions of
>> the patch that expose it to userspace?
>>
>> The rework to not use the VMA flag is pretty sizeable and is much more
>>
On 08/25/2015 03:41 PM, Michal Hocko wrote:
> On Fri 21-08-15 14:31:32, Eric B Munson wrote:
> [...]
>> I am in the middle of implementing lock on fault this way, but I cannot
>> see how we will hanlde mremap of a lock on fault region. Say we have
>> the following:
>>
>> addr = mmap(len,
On 08/24/2015 03:50 PM, Konstantin Khlebnikov wrote:
> On Mon, Aug 24, 2015 at 4:30 PM, Vlastimil Babka wrote:
>> On 08/24/2015 12:17 PM, Konstantin Khlebnikov wrote:
>>>>
>>>>
>>>> I am in the middle of implementing lock on fault this way, bu
On 08/24/2015 12:17 PM, Konstantin Khlebnikov wrote:
>>
>> I am in the middle of implementing lock on fault this way, but I cannot
>> see how we will hanlde mremap of a lock on fault region. Say we have
>> the following:
>>
>> addr = mmap(len, MAP_ANONYMOUS, ...);
>> mlock(addr, len,
On 22.8.2015 6:48, Arthur Marsh wrote:
>
>
> Vlastimil Babka wrote on 21/08/15 21:18:
>> On 08/21/2015 01:37 PM, Vlastimil Babka wrote:
>>>
>>> That, said, looking at the memory values:
>>>
>>> rc6: Fre
On 08/19/2015 11:33 PM, Eric B Munson wrote:
> On Wed, 12 Aug 2015, Michal Hocko wrote:
>
>> On Sun 09-08-15 01:22:53, Eric B Munson wrote:
>>
>> I do not like this very much to be honest. We have only few bits
>> left there and it seems this is not really necessary. I thought that
>> LOCKONFAULT
CKONFAULT, it will not be set.
>
> Signed-off-by: Eric B Munson
> Acked-by: Kirill A. Shutemov
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc: Jonathan Corbet
> Cc: "Kirill A. Shutemov"
> Cc: linux-kernel at vger.kernel.org
> Cc: dri-devel at lists.freedeskt
On 07/13/2015 10:35 AM, Gioh Kim wrote:
> From: Gioh Kim
>
> Migration is completely generalized so that migrating mobile page
> is processed with lru-pages in move_to_new_page.
>
> Signed-off-by: Gioh Kim
> Acked-by: Rafael Aquini
Why not just fold this to Patch 3? You already modify this
On 07/13/2015 10:35 AM, Gioh Kim wrote:
> From: Gioh Kim
>
> Add framework to register callback functions and check page mobility.
> There are some modes for page isolation so that isolate interface
> has arguments of page address and isolation mode while putback
> interface has only page address
On 07/22/2015 08:43 PM, Eric B Munson wrote:
> On Wed, 22 Jul 2015, Vlastimil Babka wrote:
>
>>
>> Hi,
>>
>> I think you should include a complete description of which
>> transitions for vma states and mlock2/munlock2 flags applied on them
>> are
On 07/21/2015 09:59 PM, Eric B Munson wrote:
> The cost of faulting in all memory to be locked can be very high when
> working with large mappings. If only portions of the mapping will be
> used this can incur a high penalty for locking.
>
> For the example of a large file, this is the usage
On 05/06/2015 09:28 AM, Jan Kara wrote:
> Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
> This removes the knowledge about vmas and mmap_sem locking from exynos
> driver. Also it fixes a problem that the function has been mapping user
> provided address without holding
On 05/06/2015 09:28 AM, Jan Kara wrote:
> Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
> hand made mapping of virtual address to physical address. Also the
> function leaked page reference from get_user_pages() so fix that by
> properly release the reference when
> their buffers.
>
> Signed-off-by: Jan Kara
Acked-by: Vlastimil Babka
With some nitpicks below...
> ---
> include/linux/mm.h | 44 +++
> mm/gup.c | 214
> +
> 2 files changed, 258 insertions(+)
On 11/12/2014 12:31 AM, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 06 Nov 2014 17:28:41 + bugzilla-daemon at bugzilla.kernel.org
> wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=87891
>>
>>
gt; [ 97.273617] [<410837ad>] SyS_exit_group+0x2d/0x30
> [ 97.274088] [<42153251>] sysenter_do_call+0x12/0x3c
> [ 97.274560] Disabling lock debugging due to kernel taint
> * All processes ended within 1 seconds
>
> That oops message looks very like the one I reported for this
89 matches
Mail list logo
