On Sat, Feb 01, 2025 at 04:01:43PM +0800, Kairui Song wrote:
> On Thu, Jan 30, 2025 at 6:02 PM Kirill A. Shutemov
> wrote:
> >
> > The recently introduced PG_dropbehind allows for freeing folios
> > immediately after writeback. Unlike PG_reclaim, it does not need vmscan
&
On Wed, Jan 15, 2025 at 10:18:16PM -0800, Christoph Hellwig wrote:
> On Wed, Jan 15, 2025 at 11:31:35AM +0200, Kirill A. Shutemov wrote:
> > Now as PG_reclaim is gone, its name can be reclaimed for better
> > use :)
> >
> > Rename PG_dropbehind to PG_reclaim and r
On Wed, Jan 15, 2025 at 02:46:44PM -0700, Yu Zhao wrote:
> On Wed, Jan 15, 2025 at 2:35 PM Matthew Wilcox wrote:
> >
> > On Wed, Jan 15, 2025 at 11:31:29AM +0200, Kirill A. Shutemov wrote:
> > > -static void lru_deactivate_file(struct lruvec *lruvec, st
On Mon, Jan 13, 2025 at 03:28:43PM +, Matthew Wilcox wrote:
> On Mon, Jan 13, 2025 at 11:34:53AM +0200, Kirill A. Shutemov wrote:
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index caadbe393aa2..beba72da5e33 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
&
On Mon, Jan 13, 2025 at 08:17:20AM -0800, Yosry Ahmed wrote:
> On Mon, Jan 13, 2025 at 1:35 AM Kirill A. Shutemov
> wrote:
> >
> > The recently introduced PG_dropbehind allows for freeing folios
> > immediately after writeback. Unlike PG_reclaim, it does not need vmscan
&
On Mon, Jan 13, 2025 at 01:45:48PM +, Matthew Wilcox wrote:
> On Mon, Jan 13, 2025 at 11:34:45AM +0200, Kirill A. Shutemov wrote:
> > Use PG_dropbehind instead of PG_reclaim and remove PG_reclaim.
>
> I was hoping we'd end up with the name PG_reclaim instead of the
On Thu, Sep 23, 2021 at 08:21:03PM +0200, Borislav Petkov wrote:
> On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote:
> > Unless we find other way to guarantee RIP-relative access, we must use
> > fixup_pointer() to access any global variables.
>
> Yah, I&#x
On Wed, Sep 22, 2021 at 09:52:07PM +0200, Borislav Petkov wrote:
> On Wed, Sep 22, 2021 at 05:30:15PM +0300, Kirill A. Shutemov wrote:
> > Not fine, but waiting to blowup with random build environment change.
>
> Why is it not fine?
>
> Are you suspecting that the co
On Wed, Sep 22, 2021 at 08:40:43AM -0500, Tom Lendacky wrote:
> On 9/21/21 4:58 PM, Kirill A. Shutemov wrote:
> > On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
> > > On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
> > > > On Tue, Sep 21, 2021 at 11:
On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
> On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
> > On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
> > > On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
> > >
On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
> On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
> > I still believe calling cc_platform_has() from __startup_64() is totally
> > broken as it lacks proper wrapping while accessing global varia
mm/mem_encrypt_identity.c
@@ -288,7 +288,7 @@ void __init sme_encrypt_kernel(struct boot_params *bp)
unsigned long pgtable_area_len;
unsigned long decrypted_base;
- if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
+ if (1 || !cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
return;
/*
--
Kirill A. Shutemov
ave a special version of
the helper). Note that only AMD requires these cc_platform_has() to return
true.
--
Kirill A. Shutemov
On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote:
> On 8/11/21 7:19 AM, Kirill A. Shutemov wrote:
> > On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
> >> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
> >>>
> >>>
&g
thing with this shared/unencrypted
> area, though? Or since it is shared, there's actually nothing you need to
> do (the bss decrpyted section exists even if CONFIG_AMD_MEM_ENCRYPT is not
> configured)?
AFAICS, only kvmclock uses __bss_decrypted. We don't enable kvmclock in
TDX at the moment. It may change in the future.
--
Kirill A. Shutemov
es across the
> board.
>
> Dave.
>
> drm-fixes-2021-07-16:
> drm fixes for 5.14-rc2
Dave, Daniel,
Looks like the fix[1] for nouveau regression[2] is missing. Hm?
[1]
https://lore.kernel.org/nouveau/20210609172902.1937-1-christian.koe...@amd.com/
[2] https://lore.kernel.org/lkml/YOC4uekpD7iA3xPi@Red/T/#u
--
Kirill A. Shutemov
Nouveau now doesn't init the GEM object for internally allocated BOs,
> so make sure that we at least initialize some necessary fields.
>
> Could be that the patch needs to be send to stable as well.
The regression is present in v5.14-rc1. Any idea when it will hit
upstream? I don't see it being applied to drm=next.
--
Kirill A. Shutemov
On Wed, Nov 04, 2020 at 04:58:14PM -0500, Lyude Paul wrote:
> ACK, I will send out a patch for this asap
Any update. AFAICS, v5.10-rc3 is still buggy.
--
Kirill A. Shutemov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
re NULL. It worked.
In my setup I stepped onto nv50_msto_help->atomic_enable == NULL. But
there are two more drm_encoder_helper_funcs in dispnv50/disp.c that don't
have atomic_enable/disable set: nv50_dac_help, nv50_pior_help.
--
Kirill A. Shutemov
___
tise support
> for them. Doing so would imply compatibility
> between devices with incompatible memory layouts.
>
> Tested with Xorg 1.20 modesetting driver,
> weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
> gnome & KDE wayland desktops from Ubuntu 18.04,
> kmscube hacke
gt; >> modifier. To accomplish this, some layout
> > > >> parameters must be assumed to match properties of
> > > >> the device targeted by the relevant ioctls. To
> > > >> avoid perpetuating misuse of the old-style
> > > >> modifie
f4c0cf150 RSI: c0406481 RDI: 0009
RBP: c0406481 R08: 55db823225e8 R09: 55db8231b5e8
R10: 7fbe79ce0920 R11: 0246 R12: 55db823115e0
R13: 0009 R14: 55db8230ffc0 R15: 55db8230f380
--
Kirill A. Shutemov
___
On Wed, Jul 01, 2020 at 10:57:19AM +0300, Kirill A. Shutemov wrote:
> On Tue, Jun 30, 2020 at 09:40:19PM -0700, James Jones wrote:
> > This implies something is trying to use one of the old
> > DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without
> > first c
X
> driver if it isn't modesetting, or glamour?
Modesetting without anything tricky.
--
Kirill A. Shutemov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Dec 18, 2019 at 02:15:53PM -0800, John Hubbard wrote:
> On 12/18/19 7:52 AM, Kirill A. Shutemov wrote:
> > On Mon, Dec 16, 2019 at 02:25:13PM -0800, John Hubbard wrote:
> > > +static void put_compound_head(struct page *page, int refs)
> > > +{
> > > + /*
vmas arg is NULL)
> + * and return -ENOTSUPP if DAX isn't allowed in this case:
> + */
> + return __gup_longterm_locked(tsk, mm, start, nr_pages, pages,
> + vm
e condition would save you an indentation level.
> + int count = page_ref_dec_return(page);
> +
> + /*
> + * devmap page refcounts are 1-based, rather than 0-based: if
> + * refcount is 1, then the page is free and the refcount is
>
page);
> +}
It's not terribly efficient. Maybe something like:
VM_BUG_ON_PAGE(page_ref_count(page) < ref, page);
if (refs > 2)
page_ref_sub(page, refs - 1);
put_page(page);
?
--
Kirill A. Shutemov
_
users included here:
>
> https://cgit.freedesktop.org/~thomash/linux/log/?h=coherent-rebased
>
> Do you think this could work? The reason that the "mm: Add write-protect and
> clean.." code is still in mm as a set of helpers, is of course that much of
> the needed functi
On Fri, Sep 27, 2019 at 09:39:48AM -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 5:17 AM Kirill A. Shutemov
> wrote:
> >
> > > Call it "walk_page_mapping()". And talk extensively about how the
> > > locking differs a lot from the usual "walk
from PMD layer and it's bogus. i_mmap_lock()
works fine for file mappings.
The PMD was intended for THP case at the time when there were only
anon-THP. The check was relaxed and later dropped for file-THP on PMD
level. It has to be dropped on PUD too. We don't have anon-THP on PUD
r walking in pagewalk.c would seem to be
> the simplest model.
>
> Call it "walk_page_mapping()". And talk extensively about how the
> locking differs a lot from the usual "walk_page_vma()" things.
Walking mappings of a page is what rmap does. This code thas to be
ted
> F: drivers/gpu/drm/vmwgfx/
> F: include/uapi/drm/vmwgfx_drm.h
> +F: mm/as_dirty_helpers.c
Emm.. No. Core MM functinality cannot belong to random driver.
--
Kirill A. Shutemov
On Mon, Dec 14, 2015 at 11:20:00AM +0100, David Herrmann wrote:
> Hi
>
> On Mon, Dec 14, 2015 at 9:19 AM, Kirill A. Shutemov
> wrote:
> > On Thu, Dec 10, 2015 at 11:28:58AM +0100, David Herrmann wrote:
> >> Hi
> >>
> >> On Mon, Nov 30, 20
On Thu, Dec 10, 2015 at 11:28:58AM +0100, David Herrmann wrote:
> Hi
>
> On Mon, Nov 30, 2015 at 3:17 AM, Kirill A. Shutemov
> wrote:
> > There are few defects in vga_get() related to signal hadning:
> >
> > - we shouldn't check for pending signals fo
On Mon, Nov 30, 2015 at 04:17:31AM +0200, Kirill A. Shutemov wrote:
> There are few defects in vga_get() related to signal hadning:
>
> - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
> case;
>
> - if we found pending signal we must remove
te, I guess.
Signed-off-by: Kirill A. Shutemov
---
Alex, I try to get KVM with VGA passthrough working properly. I have i915
(HD 4600) on the host and GTX 580 for the guest. The guest GPU is not
capabale of EFI, so I have to use x-vga=on. It's kinda work with your
patch for i915.enable_hd_vga
LL_MLOCK flag to communicate the locked state of a VMA.
> >FOLL_POPULATE will now only control if the VMA should be populated and
> >in the case of VM_LOCKONFAULT, it will not be set.
> >
> >Signed-off-by: Eric B Munson
> >Acked-by: Kirill A. Shutemov
> >Cc:
the case of VM_LOCKONFAULT, it will not be set.
>
> Signed-off-by: Eric B Munson
> 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.freedesktop.org
> Cc: l
work well) we'd need to pimp shmem to a)
> > hand large pages to us b) forward the migrate calls. Probably that means
> > we need to build our own gemfs reusing shmemfs code.
>
> AFAIK there are efforts ongoing to make large pages work with shmem.
>
> Kirill, IIRC you mentioned that you're were looking into this a while
> back?
I work in this direction, but don't have anything to show at the moment.
Hugh has published his implementation of huge tmpfs back in February:
http://lkml.kernel.org/g/alpine.LSU.2.11.1502201941340.14414 at eggly.anvils
--
Kirill A. Shutemov
On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote:
> On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter &g
On Tue, Nov 11, 2014 at 05:56:03PM -0800, Andrew Morton wrote:
> On Wed, 12 Nov 2014 03:47:03 +0200 "Kirill A. Shutemov" shutemov.name> wrote:
>
> > On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> > > On Tue, Nov 11, 2014 at 04:49:13PM -080
On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
> On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
> > On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter > linux.com> wrote:
> >
> > > On Tue, 11 Nov 2014, Andrew Morton wr
GFP_HIGHMEM is bit 1.
>
> Ah, yes, OK.
>
> I suppose it's possible that __GFP_HIGHMEM was set.
>
> do_huge_pmd_anonymous_page
> ->pte_alloc_one
> ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)
do_huge_pmd_anonymous_page
alloc_hugepage_vma
alloc_pages_vma(GFP_TRANSHUGE)
GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.
--
Kirill A. Shutemov
+ if ((pipe != 0) && (pipe != 2)) {
It would be nice to remove redundant parentheses while you're there.
Otherwise
Acked-by: Kirill A. Shutemov
> DRM_ERROR("Invalid parameter\n");
> return;
> }
>
>
> --
>
+ if ((pipe != 0) && (pipe != 2)) {
It would be nice to remove redundant parentheses while you're there.
Otherwise
Acked-by: Kirill A. Shutemov
> DRM_ERROR("Invalid parameter\n");
> return;
> }
>
>
> --
> To
to use the new config_enabled() macro. :)
The first [direct] user of config_enabled()! :)
Acked-by: Kirill A. Shutemov
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/gma500/opregion.c
> b/drivers/gpu/drm/gma500/opregion.c
> index 05661bf..d2125ba 100644
> ---
to use the new config_enabled() macro. :)
The first [direct] user of config_enabled()! :)
Acked-by: Kirill A. Shutemov
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/gma500/opregion.c
> b/drivers/gpu/drm/gma500/opregion.c
> index 05661bf..d2125ba 100644
> ---
On Thu, Apr 12, 2012 at 12:05:29AM +0200, Jesper Juhl wrote:
> drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to
> '#include ' - so don't.
>
> Signed-off-by: Jesper Juhl
Acked-by: Kirill A. Shutemov
--
Kirill A. Shutemov
-- next part -
On Thu, Apr 12, 2012 at 12:05:29AM +0200, Jesper Juhl wrote:
> drivers/gpu/drm/gma500/mdfld_dsi_output.h does not need to
> '#include ' - so don't.
>
> Signed-off-by: Jesper Juhl
Acked-by: Kirill A. Shutemov
--
Kirill A. Shutemov
signature.asc
Des
From: "Kirill A. Shutemov"
drivers/built-in.o: In function `mdfld_dsi_connector_set_property':
mdfld_dsi_output.c:(.text+0x6e909): undefined reference to
`mdfld_set_brightness'
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Kirill A. Shutemov
---
drivers/gpu/drm/gma50
From: "Kirill A. Shutemov"
drivers/built-in.o: In function `mdfld_dsi_connector_set_property':
mdfld_dsi_output.c:(.text+0x6e909): undefined reference to
`mdfld_set_brightness'
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Kirill A. Shutemov
---
drivers/gpu/drm/gma50
On Mon, Dec 05, 2011 at 09:37:15AM -0500, Adam Jackson wrote:
> On Sat, 2011-12-03 at 19:35 +0200, Kirill A. Shutemov wrote:
> > Hi,
> >
> > Commit dc22ee6 introduces regression on my laptop HP EliteBook 8440p. I see
> > nothing on the panel after mode setting. Rev
On Mon, Dec 05, 2011 at 09:37:15AM -0500, Adam Jackson wrote:
> On Sat, 2011-12-03 at 19:35 +0200, Kirill A. Shutemov wrote:
> > Hi,
> >
> > Commit dc22ee6 introduces regression on my laptop HP EliteBook 8440p. I see
> > nothing on the panel after mode setting. Rev
00 00 00 00 00 00 01 02 00
e0: 00 00 00 00 01 00 00 00 00 80 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 ab 0f 18 00 18 d0 6f bb
--
Kirill A. Shutemov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mail
00 00 00 00 00 00 01 02 00
e0: 00 00 00 00 01 00 00 00 00 80 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 ab 0f 18 00 18 d0 6f bb
--
Kirill A. Shutemov
56 matches
Mail list logo
