== Series Details ==
Series: drm/i915/hwmon: Enable PL1 power limit (rev3)
URL : https://patchwork.freedesktop.org/series/113578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12686_full -> Patchwork_113578v3_full
Summary
On Tue, 2023-01-24 at 13:27 +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 24.01.23 um 10:10 schrieb Jouni Högander:
> > After disconnecting damage worker from update logic our dirty
> > callback
> > is not called on fbcon events. This is causing problems to features
> > (PSR, FBC, DRRS) relying on
>
> On Thu, 02 Feb 2023, "Kandpal, Suraj" wrote:
> >>
> >> On Thu, 02 Feb 2023, Suraj Kandpal wrote:
> >> > According to Bpec: 49259 VDSC spec implies that 108 lines is an
> >> > optimal slice height, but any size can be used as long as vertical
> >> > active integer multiple and maximum
== Series Details ==
Series: Fix logic to get slice_height for dp (rev2)
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12685_full -> Patchwork_113594v2_full
Summary
== Series Details ==
Series: More error capture improvements
URL : https://patchwork.freedesktop.org/series/113628/
State : warning
== Summary ==
Error: dim checkpatch failed
eb15e24f1a93 drm/i915/guc: Fix missing ecodes
-:15: WARNING:REPEATED_WORD: Possible repeated word: 'if'
#15:
v2: if
> From: Alex Williamson
> Sent: Friday, February 3, 2023 7:13 AM
>
> On Thu, 2 Feb 2023 23:04:10 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Friday, February 3, 2023 3:42 AM
> > >
> > >
> > > LGTM. I'm not sure moving the functions to vfio_main really buys us
> > >
== Series Details ==
Series: More drm_dbg to guc_dbg changes
URL : https://patchwork.freedesktop.org/series/113624/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1:
On Thu, Feb 02, 2023 at 04:57:08PM -0800, Lucas De Marchi wrote:
> Register 0x9424 is not replicated on any platform, so it shouldn't be
> declared with REG_MCR(). Declaring it with _MMIO() is basically
> duplicate of the GEN7 version, so just remove the GEN8 and change all
> the callers to use
From: John Harrison
The seqno value actually written out to memory is no longer in the
regular HWSP and therefore no longer visible in an error capture.
Instead, it is now in its own private timeline buffer. So include that
buffer in the capture too.
Signed-off-by: John Harrison
---
From: John Harrison
The comparison in the search for a matching register capture node was
not the most readable. So remove two redundant terms and re-format to
keep each term on a single line, and only one term per line.
Signed-off-by: John Harrison
---
From: John Harrison
Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
number that is meant to distinguish similar seeming bugs with
different underlying signatures. It is a combination of two ring state
registers. Unfortunately, the register state being used is only valid
From: John Harrison
Ecodes got lost with the switch to GuC based register lists. Put them
back.
Seqno values got lost with the switch to per context timelines. Put
hose back too.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc: Fix missing ecodes
drm/i915/guc: Clean up of
INF_UNIT_LEVEL_CLKGATE is not replicated, but since it's not actually
used it can just be removed.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
Register 0x9424 is not replicated on any platform, so it shouldn't be
declared with REG_MCR(). Declaring it with _MMIO() is basically
duplicate of the GEN7 version, so just remove the GEN8 and change all
the callers to use the right functions.
Also use intel_uncore_rmw() rather than a read +
== Series Details ==
Series: drm/i915: Make sure dsm_size has correct granularity (rev2)
URL : https://patchwork.freedesktop.org/series/113282/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684_full -> Patchwork_113282v2_full
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_gt_print.h | 3 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 3 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 3 +++
3 files
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 8 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 60 -
2 files changed, 26 insertions(+), 42
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 35 ++-
.../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 ++--
From: John Harrison
Update more print messages to the new scheme.
Signed-off-by: John Harrison
John Harrison (6):
drm/i915/guc: More debug print updates - UC firmware
drm/i915/guc: More debug print updates - GSC firmware
drm/i915/guc: More debug print updates - GuC reg capture
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 ---
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 42
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 116 +++
2 files changed, 73 insertions(+), 85
On 1/31/2023 2:28 PM, Michal Wajdeczko wrote:
Like we did it for GuC, introduce some helper print macros for
HuC to have unified format of messages that also include GT#.
While around improve some messages and use %pe if possible.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
== Series Details ==
Series: drm/i915/hwmon: Enable PL1 power limit (rev3)
URL : https://patchwork.freedesktop.org/series/113578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12686 -> Patchwork_113578v3
Summary
---
== Series Details ==
Series: drm/i915: add guard page to ggtt->error_capture (rev2)
URL : https://patchwork.freedesktop.org/series/113560/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12686 -> Patchwork_113560v2
Summary
On Thu, 2 Feb 2023 23:04:10 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Friday, February 3, 2023 3:42 AM
> >
> > On Thu, 2 Feb 2023 11:24:42 -0500
> > Matthew Rosato wrote:
> >
> > > After 51cdc8bc120e, we have another deadlock scenario between the
> > > kvm->lock and
> From: Alex Williamson
> Sent: Friday, February 3, 2023 3:42 AM
>
> On Thu, 2 Feb 2023 11:24:42 -0500
> Matthew Rosato wrote:
>
> > After 51cdc8bc120e, we have another deadlock scenario between the
> > kvm->lock and the vfio group_lock with two different codepaths acquiring
> > the locks in
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev5)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684_full -> Patchwork_113535v5_full
== Series Details ==
Series: drm/i915/dmc: allocate dmc struct dynamically
URL : https://patchwork.freedesktop.org/series/113622/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12686 -> Patchwork_113622v1
Summary
---
== Series Details ==
Series: drm/i915/dmc: allocate dmc struct dynamically
URL : https://patchwork.freedesktop.org/series/113622/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
sizeof(struct intel_dmc) > 1024 bytes, allocated on all platforms as
part of struct drm_i915_private, whether they have DMC or not.
Allocate struct intel_dmc dynamically, and hide all the dmc details
behind an opaque pointer in intel_dmc.c.
Care must be taken to take into account all cases: DMC
The ucode part in the init, fini, suspend and resume function names is
just unnecessary. Drop it.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/display/intel_dmc.c | 20 ++--
There's only one reference to the struct intel_dmc members dc_state,
target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the
question why they are under struct intel_dmc to begin with.
Moreover, the only references to i915->display.dmc outside of
intel_dmc.c are to these members.
Allocate the >1k dmc struct dynamically, only for platforms that need
it.
Jani Nikula (3):
drm/i915/power: move dc state members to struct i915_power_domains
drm/i915/dmc: drop "ucode" from function names
drm/i915/dmc: allocate dmc structure dynamically
== Series Details ==
Series: Fix logic to get slice_height for dp (rev2)
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12685 -> Patchwork_113594v2
Summary
---
== Series Details ==
Series: drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv (rev2)
URL : https://patchwork.freedesktop.org/series/113568/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684_full -> Patchwork_113568v2_full
Hello,
On Thu, Feb 02, 2023 at 02:26:06PM +, Tvrtko Ursulin wrote:
> When you say active/inactive - to what you are referring in the cgroup
> world? Offline/online? For those my understanding was offline was a
> temporary state while css is getting destroyed.
Oh, it's just based on activity.
On Thu, 2 Feb 2023 11:24:42 -0500
Matthew Rosato wrote:
> After 51cdc8bc120e, we have another deadlock scenario between the
> kvm->lock and the vfio group_lock with two different codepaths acquiring
> the locks in different order. Specifically in vfio_open_device, vfio
> holds the vfio
On Thu, 02 Feb 2023, "Kandpal, Suraj" wrote:
>>
>> On Thu, 02 Feb 2023, Suraj Kandpal wrote:
>> > According to Bpec: 49259 VDSC spec implies that 108 lines is an
>> > optimal slice height, but any size can be used as long as vertical
>> > active integer multiple and maximum vertical slice count
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 11/13] drm/i915/dsb: Write each legacy LUT entry
> twice with DSB
>
> From: Ville Syrjälä
>
> The DSB
== Series Details ==
Series: drm/i915: Make sure dsm_size has correct granularity (rev2)
URL : https://patchwork.freedesktop.org/series/113282/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684 -> Patchwork_113282v2
According VDSC spec 1.2a Section 3.8 Options for Slice
implies that 108 lines is an optimal slice height, but any
size can be used as long as vertical active
integer multiple and maximum vertical slice count requirements are met.
Bspec: 49259
Cc: Jani Nikula
Cc: Ankit Nautiyal
Cc: Swati Sharma
== Series Details ==
Series: i915: fix memory leak with using debugfs_lookup()
URL : https://patchwork.freedesktop.org/series/113603/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683_full -> Patchwork_113603v1_full
== Series Details ==
Series: drm/i915/dmc: some dmc id related fixes and cleanups
URL : https://patchwork.freedesktop.org/series/113596/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683_full -> Patchwork_113596v1_full
DSM granularity is 1MB so make sure we stick to that.
v2: replace "1 * SZ_1M" with SZ_1M (Andrzej).
Cc: Matthew Auld
Suggested-by: Lucas De Marchi
Signed-off-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
1 file changed, 1 insertion(+), 1
>
> On Thu, 02 Feb 2023, Suraj Kandpal wrote:
> > According to Bpec: 49259 VDSC spec implies that 108 lines is an
> > optimal slice height, but any size can be used as long as vertical
> > active integer multiple and maximum vertical slice count requirements are
> met.
>
> The commit message
== Series Details ==
Series: Fix logic to get slice_height for dp
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683_full -> Patchwork_113594v1_full
Summary
---
== Series Details ==
Series: drm/i915/hwmon: Enable PL1 power limit (rev2)
URL : https://patchwork.freedesktop.org/series/113578/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12684 -> Patchwork_113578v2
Summary
---
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 07/13] drm/i915/dsb: Nuke the DSB debug
>
> From: Ville Syrjälä
>
> We'll be wanting to start the DSB
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/13] drm/i915/dsb: Allow vblank synchronized
> DSB execution
>
> From: Ville Syrjälä
>
> Allow the
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev5)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684 -> Patchwork_113535v5
On Thu, 2023-02-02 at 08:43 +, Tvrtko Ursulin wrote:
>
> On 02/02/2023 08:13, Alan Previn wrote:
> > MESA driver is creating protected context on every driver handle
> > initialization to query caps bit for app. So when running CI tests,
> > they are observing hundreds of drm_errors when
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/13] drm/i915/dsb: Dump the DSB command
> buffer when DSB fails
>
> From: Ville Syrjälä
>
> Dump the
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:09PM -0800, Niranjana Vishwanathapura wrote:
> Support dump capture of persistent mappings upon user request.
>
> Capture of a mapping is requested with the VM_BIND ioctl and
> processed during the GPU error handling. They are synchronously
> unbound
The following changes since commit 5c11a3742947810ee8bffbd476eb5a1b0c7999f2:
amdgpu: Add VCN 4.0.2 firmware (2023-01-25 07:40:41 -0500)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware.git dmc-adlp_2.18
for you to fetch changes up to
== Series Details ==
Series: We need to have additional checks for DP MST UHBR (rev2)
URL : https://patchwork.freedesktop.org/series/112876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_112876v2_full
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:08PM -0800, Niranjana Vishwanathapura wrote:
> Properly build the sg table for persistent mapping which can
> be partial map of the underlying object. Ensure the sg pages
> are properly set for page backed regions. The dump capture
> support requires
== Series Details ==
Series: drm/i915: Consolidate TLB invalidation flow (rev2)
URL : https://patchwork.freedesktop.org/series/113563/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_113563v2_full
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:06PM -0800, Niranjana Vishwanathapura wrote:
> Update i915 documentation to include VM_BIND changes
> and render all VM_BIND related documentation.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
looks good!
Reviewed-by:
Previous documentation suggested that PL1 power limit is always
enabled. However we now find this not to be the case on some
platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
initialization.
Bspec: 51864
v2: Add Bspec reference (Gwan-gyeong)
Signed-off-by: Ashutosh Dixit
After 51cdc8bc120e, we have another deadlock scenario between the
kvm->lock and the vfio group_lock with two different codepaths acquiring
the locks in different order. Specifically in vfio_open_device, vfio
holds the vfio group_lock when issuing device->ops->open_device but some
drivers (like
== Series Details ==
Series: drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv (rev2)
URL : https://patchwork.freedesktop.org/series/113568/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684 -> Patchwork_113568v2
== Series Details ==
Series: introduce vm_flags modifier functions
URL : https://patchwork.freedesktop.org/series/113606/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/113606/revisions/1/mbox/ not
applied
Applying: mm: introduce vma->vm_flags
== Series Details ==
Series: drm/i915/pxp: limit drm-errors or warnings on firmware API failures
URL : https://patchwork.freedesktop.org/series/113584/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_113584v1_full
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:04PM -0800, Niranjana Vishwanathapura wrote:
> Only support vm_bind mode with non-recoverable contexts.
> With new vm_bind mode with eb3 submission path, we need not
> support older recoverable contexts.
>
> Reviewed-by: Matthew Auld
> Signed-off-by:
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev4)
URL : https://patchwork.freedesktop.org/series/113535/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_113535v4_full
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:15:58PM -0800, Niranjana Vishwanathapura wrote:
> Update the execbuf path to use common execbuf functions to
> reduce code duplication with the newer execbuf3 path.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
Reviewed-by:
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/13] drm/i915/dsb: Introduce intel_dsb_finish()
>
> From: Ville Syrjälä
>
> Introduce a function to
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 03/13] drm/i915/dsb: Split intel_dsb_wait() from
> intel_dsb_commit()
>
> From: Ville Syrjälä
>
>
On Thu, Feb 02, 2023 at 02:04:52PM +0200, Jani Nikula wrote:
> Add validity checks for the dmc ids computed from pipe parameters in
> intel_dmc_enable_pipe() and intel_dmc_disable_pipe(). It's slightly
> difficult for humans and static analyzers alike to ensure the resulting
> dmc ids are within
== Series Details ==
Series: i915: fix memory leak with using debugfs_lookup()
URL : https://patchwork.freedesktop.org/series/113603/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683 -> Patchwork_113603v1
Summary
Hi Nirmoy,
On Mon, Jan 30, 2023 at 02:13:58PM +0100, Nirmoy Das wrote:
> Use sysfs_emit() and sysfs_emit_at() in show() callback
> as recommended by Documentation/filesystems/sysfs.rst
>
> Cc: Andi Shyti
> Signed-off-by: Nirmoy Das
Pushed in drm-intel-gt-next.
Thank you,
Andi
> ---
>
[Public]
> -Original Message-
> From: dim-tools On Behalf Of
> John Paul Adrian Glaubitz
> Sent: Monday, January 23, 2023 10:01 AM
> To: tzimmerm...@suse.de
> Cc: tvrtko.ursu...@linux.intel.com; dim-to...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org;
== Series Details ==
Series: drm/i915/dmc: some dmc id related fixes and cleanups
URL : https://patchwork.freedesktop.org/series/113596/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683 -> Patchwork_113596v1
Summary
mmap_assert_write_locked() is used in vm_flags modifiers. Because
mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes
modified from from inside a module, it's necessary to export
dump_mm() function.
Signed-off-by: Suren Baghdasaryan
---
mm/debug.c | 1 +
1 file changed, 1
Hi
A user in Debian, cc'ed reporte the following issue when resuming from
hibernation, tested as well on recent 6.1.7 kernel, context see
https://bugs.debian.org/971068
> Can repro on the sid kernel, uname -a of
> Linux nabtop 6.1.0-2-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1
>
On Wed 25-01-23 00:38:48, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
Is this a manual (git grep) based work or have you used Coccinele for
the patch
On 28/01/2023 01:11, Tejun Heo wrote:
On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin wrote:
...
+ /*
+* 1st pass - reset working values and update hierarchical weights and
+* GPU utilisation.
+*/
+ if (!__start_scanning(root, period_us))
+
Hi Thomas!
On 1/23/23 16:35, Thomas Zimmermann wrote:
The only thing that is not supported any longer is hardware-accelerated 3d
rendering.
However, this has not worked anyway, as Mesa has dropped support for those
chips a long
time ago.
Correct me if I'm wrong, but I thought that's what
On Wed 25-01-23 00:38:51, Suren Baghdasaryan wrote:
> mmap_assert_write_locked() is used in vm_flags modifiers. Because
> mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes
> modified from from inside a module, it's necessary to export
> dump_mm() function.
>
> Signed-off-by:
vm_flags are among VMA attributes which affect decisions like VMA merging
and splitting. Therefore all vm_flags modifications are performed after
taking exclusive mmap_lock to prevent vm_flags updates racing with such
operations. Introduce modifier functions for vm_flags to be used whenever
flags
On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > vm_flags are among VMA attributes which affect decisions like VMA merging
> > and splitting. Therefore all vm_flags modifications are performed after
> > taking
On Wed, Jan 25, 2023 at 12:38:49AM -0800, Suren Baghdasaryan wrote:
> Replace indirect modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
> vm_flags
On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin
wrote:
> +static int drmcs_can_attach(struct cgroup_taskset *tset)
> +{
> + int ret;
> +
> + /*
> + * As processes are getting moved between groups we need to ensure
> + * both that the old group does not see a sudden
On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > Replace indirect modifications to vma->vm_flags with calls to modifier
> > functions to be able to track flag changes and to keep vma locking
> > correctness. Add a
On Wed, Jan 25, 2023 at 9:08 AM Michal Hocko wrote:
>
> On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote:
> > On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
> > wrote:
> > >
> > > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > > > Replace indirect modifications to
On Thu, Jan 26, 2023 at 05:57:24PM +, Tvrtko Ursulin
wrote:
> So even if the RFC shows just a simple i915 implementation, the controller
> itself shouldn't prevent a smarter approach (via exposed ABI).
scan/query + over budget notification is IMO limited in guarantees.
> [...]
> Yes
On Wed, Jan 25, 2023 at 12:38:51AM -0800, Suren Baghdasaryan wrote:
> mmap_assert_write_locked() is used in vm_flags modifiers. Because
> mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes
> modified from from inside a module, it's necessary to export
> dump_mm() function.
>
>
On Wed, Jan 25, 2023 at 12:38:47AM -0800, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
>
In cases when VMA flags are modified after VMA was isolated and mmap_lock
was downgraded, flags modifications would result in an assertion because
mmap write lock is not held.
Introduce mod_vm_flags_nolock to be used in such situation.
Pass a hint to untrack_pfn to conditionally use
On Wed 25-01-23 00:38:47, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Michal Hocko
> ---
> include/linux/mm.h | 4 ++--
>
On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > + /*
> > > + * Flags, see mm.h.
> > > + * WARNING! Do not modify directly.
> > > + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
>
Replace indirect modifications to vma->vm_flags with calls to modifier
functions to be able to track flag changes and to keep vma locking
correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
vm_flags modification attempts.
Signed-off-by: Suren Baghdasaryan
---
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> vm_flags are among VMA attributes which affect decisions like VMA merging
> and splitting. Therefore all vm_flags modifications are performed after
> taking exclusive mmap_lock to prevent vm_flags updates racing with such
>
To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
replace it with VM_LOCKED_MASK bitmask and convert all users.
Signed-off-by: Suren Baghdasaryan
---
include/linux/mm.h | 4 ++--
kernel/fork.c | 2 +-
mm/hugetlb.c | 4 ++--
mm/mlock.c | 6 +++---
mm/mmap.c
Hi Thomas!
On 1/23/23 16:13, Thomas Zimmermann wrote:
Driver Changes:
* Remove obsolete drivers for userspace modesetting i810, mga, r128,
savage, sis, tdfx, via
Is the Rage 128 GPU still supported via the generic modesetting driver?
I'm asking because, we're still supporting PowerMacs
On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > > Replace indirect modifications to vma->vm_flags with calls to modifier
> > > functions to be able to
On Wed, Jan 25, 2023 at 1:42 AM Michal Hocko wrote:
>
> On Wed 25-01-23 00:38:50, Suren Baghdasaryan wrote:
> > In cases when VMA flags are modified after VMA was isolated and mmap_lock
> > was downgraded, flags modifications would result in an assertion because
> > mmap write lock is not held.
>
On Wed, Jan 25, 2023 at 10:37 AM Matthew Wilcox wrote:
>
> On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> > On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > > + /*
> > > > + * Flags, see mm.h.
> > > > + * WARNING! Do not modify directly.
> > > > +
Hi,
On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> [...]
>
1 - 100 of 162 matches
Mail list logo
