Quoting Jia-Ju Bai (2021-03-08 08:59:52)
> When i915_random_order() returns NULL to order, no error return code of
> igt_buddy_alloc_smoke() is assigned.
> To fix this bug, err is assigned with -EINVAL in this case.
It would not be EINVAL since that is used for a reference failure, but
in this
Quoting Jia-Ju Bai (2021-03-08 09:07:22)
> When kcalloc() returns NULL to tsk or thread, no error code of
> igt_threaded_blt() is returned.
> To fix this bug, -ENOMEM is returned as error code.
Because we decided to skip the test if it could not be run due to
insufficient memory, as opposed to
48 89 74 24
<4>[ 254.194312] RSP: 002b:7ffd9cc2c768 EFLAGS: 0246 ORIG_RAX:
0001
<4>[ 254.194337] RAX: ffda RBX: 0004 RCX:
7f07d79691e7
<4>[ 254.194352] RDX: 0004 RSI: 556ebfc63590 RDI:
000b
<4>[ 2
always
> initialized in icl_combo_phy_verify_state")
> Reported-by: Arnd Bergmann
> Signed-off-by: Nathan Chancellor
make CC=clang-11 now compiles cleanly for me as well,
Reviewed-by: Chris Wilson
-Chris
CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
Signed-off-by: Chris Wilson
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Andrew Morton
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Rasmus Villemoes
Cc
Quoting Kees Cook (2021-02-05 21:20:33)
> On Fri, Feb 05, 2021 at 09:16:01PM +0000, Chris Wilson wrote:
> > The subject should of course be changed, as it is no longer being
> > enabled by default.
>
> "default n" is redundant.
I thought being explicit would be p
, lift SYS_kcmp out of the non-default
CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
Signed-off-by: Chris Wilson
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Andrew Morton
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
---
init/Kconfig
The subject should of course be changed, as it is no longer being
enabled by default.
Something like
kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
Quoting Chris Wilson (2021-02-05 21:06:10)
> Userspace has discovered the functionality offered by SYS_kcmp and has
> s
/3046
Signed-off-by: Chris Wilson
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Andrew Morton
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
Acked-by: Daniel Vetter # DRM depends on SYS_kcmp
---
v2:
- Default n.
- Borrrow help message from man kcmp.
- Export
Quoting Jani Nikula (2021-01-28 13:23:48)
>
> A number of our CI systems are hitting redzone overwritten errors after
> s2idle, with the errors introduced between v5.11-rc4 and v5.11-rc5. See
> snippet below, full logs for one affected machine at [1].
>
> Known issue?
Fwiw, I think this should
Quoting Vinicius Tinti (2021-01-30 12:34:11)
> On Fri, Jan 29, 2021 at 08:55:54PM +0000, Chris Wilson wrote:
> > Quoting Vinicius Tinti (2021-01-29 18:15:19)
> > > By enabling -Wunreachable-code-aggressive on Clang the following code
> > > paths are unreachable
Quoting Vinicius Tinti (2021-01-29 18:15:19)
> By enabling -Wunreachable-code-aggressive on Clang the following code
> paths are unreachable.
That code exists as commentary and, especially for sdvo, library
functions that we may need in future.
The ivb-gt1 case => as we now set the gt level for
Quoting Randy Dunlap (2021-01-27 20:28:05)
> On 1/27/21 11:30 AM, Randy Dunlap wrote:
> > On 1/27/21 11:08 AM, Randy Dunlap wrote:
> >> On 1/27/21 6:44 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Note: the patch file has failed to upload :-(
> >>>
> >>> Changes since 20210125:
> >>>
> >>
Quoting Chris Wilson (2021-01-25 21:46:19)
> Quoting Mike Rapoport (2021-01-25 21:33:48)
> > On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> > > Mike: should we perhaps revert the first patch too (commit
> > > bde9cfa3afe4: "x86/setup: don'
next
Ta. Saves me having to do the fixup.
Reviewed-by: Chris Wilson
Will be applied to drm-intel-gt-next which is scheduled for inclusion in
5.13. It should apply against the 5.12 merge window if there's a tree
through which you want to migrate the tasklet API faster.
-Chris
Quoting Arnd Bergmann (2021-01-25 12:26:44)
> From: Arnd Bergmann
>
> CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
> to honor its dependencies:
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
> Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] &&
Quoting Mike Rapoport (2021-01-25 21:33:48)
> On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> > On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson
> > wrote:
> > >
> > > Quoting Linus Torvalds (2021-01-25 01:06:40)
> > > > Mike
Quoting Mike Rapoport (2021-01-25 21:04:56)
> On Mon, Jan 25, 2021 at 08:34:34PM +0000, Chris Wilson wrote:
> > Quoting Linus Torvalds (2021-01-25 01:06:40)
> > > Mike Rapoport (3):
> > ...
> > > mm: fix initialization of struct page for holes in memory lay
Quoting Linus Torvalds (2021-01-25 01:06:40)
> Mike Rapoport (3):
...
> mm: fix initialization of struct page for holes in memory layout
We have half a dozen or so different machines in CI that are silently
failing to boot, that we believe is bisected to this patch.
17:56 tsa
Quoting Arnd Bergmann (2021-01-25 12:25:34)
> From: Arnd Bergmann
>
> The x86-specific wbinvd_on_all_cpus() function is exported
> through asm/smp.h, causing a build failure in the i915 driver
> when SMP is disabled:
>
> drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of
>
pin_map()
> fails.
True.
> Let's fix the bug and silence the false positive.
>
> Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd
> accessible reg whitelist")
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris Wilson
-Chris
Quoting Pan Bian (2021-01-22 01:56:40)
> Object out is not released on path that no VMA instance found. The root
> cause is jumping to an unexpected label on the error path.
Wouldn't the root cause be whatever caused the allocation to fail?
Language notwithstanding,
Reviewed-by: Chris
Quoting Steven Rostedt (2021-01-14 21:32:06)
> On reboot, one of my test boxes now triggers the following warning:
057fe3535eb3 ("drm/i915: Disable RPM wakeref assertions during driver shutdown")
is included with the drm-intel-fixes PR.
-Chris
uiltin_constant_p(w) ? __const_hweight64(w) :
> __arch_hweight64(w))
>
> Change it to hweight_long() to avoid the warning.
>
> Signed-off-by: Arnd Bergmann
Reviewed-by:: Chris Wilson
-Chris
Quoting t...@redhat.com (2020-12-15 14:41:01)
> From: Tom Rix
>
> See Documentation/core-api/printk-formats.rst.
> h should no longer be used in the format specifier for printk.
It's understood by format_decode().
* 'h', 'l', or 'L' for integer fields
At least reference commit cbacb5ab0aa0
esno(info->name));
> +#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, yesno(info->name))
> DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG);
I thought that this was a macro that avoided adding the ';' to each
invocation. Perhaps another time.
Reviewed-by: Chris Wilson
-Chris
Quoting Xing Zhengjun (2020-11-27 01:51:41)
>
>
> On 11/27/2020 5:34 AM, Chris Wilson wrote:
> > Quoting Xing Zhengjun (2020-11-26 01:44:55)
> >>
> >>
> >> On 11/25/2020 4:47 AM, Chris Wilson wrote:
> >>> Quoting Oliver Sang (2020-11-19 07:
Quoting Xing Zhengjun (2020-11-26 01:44:55)
>
>
> On 11/25/2020 4:47 AM, Chris Wilson wrote:
> > Quoting Oliver Sang (2020-11-19 07:20:18)
> >> On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> >>> Hi,
> >>>
> >>> Coul
Quoting Oliver Sang (2020-11-19 07:20:18)
> On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> > Hi,
> >
> > Could you add intel-...@lists.freedesktop.org into reports going
> > forward.
> >
> > Quoting kernel test robot (2020-11-11 17:58:11)
> > >
> > > Greeting,
> > >
> > >
Quoting Lu Baolu (2020-11-20 10:17:12)
> Lu Baolu (3):
> iommu: Add quirk for Intel graphic devices in map_sg
> iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
> iommu/vt-d: Cleanup after converting to dma-iommu ops
>
> Tom Murphy (4):
> iommu: Handle freelists when using
Quoting Peter Zijlstra (2020-11-19 13:02:44)
>
> Chris, I suspect this is due to i915 calling stop machine with all sorts
> of locks held. Is there anything to be done about this? stop_machine()
> is really nasty to begin with.
>
> What problem is it typing to solve?
If there is any concurrent
Quoting Dan Carpenter (2020-11-16 10:08:38)
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 0062442ecfef0d82cd69e3e600d5006357f8d8e4
> commit: 27a5dcfe73f4b696b3de8c23a560199bb1c193a4 drm/i915/gem: Remove
> disordered per-file request list for
Quoting Chris Wilson (2020-10-28 17:40:48)
> Quoting Chris Wilson (2020-10-27 16:34:53)
> > Quoting Peter Zijlstra (2020-10-27 15:45:33)
> > > On Tue, Oct 27, 2020 at 01:29:10PM +, Chris Wilson wrote:
> > >
> > > > <4> [304
Quoting Chris Wilson (2020-10-27 16:34:53)
> Quoting Peter Zijlstra (2020-10-27 15:45:33)
> > On Tue, Oct 27, 2020 at 01:29:10PM +0000, Chris Wilson wrote:
> >
> > > <4> [304.908891] hm#2, depth: 6 [6], 3425cfea6ff31f7f != 547d92e9ec2ab9af
> > > <
Quoting Stephen Rothwell (2020-10-28 21:28:23)
> Hi all,
>
> Commit
>
> d13208a88f41 ("lockdep: Fix nr_unused_locks")
>
> is missing a Signed-off-by from its author.
>
> Also, the author's email name is missing the leading 'P'.
And it shouldn't be in the drm-intel-fixes tree.
-Chris
Quoting Peter Zijlstra (2020-10-27 12:48:34)
> On Tue, Oct 27, 2020 at 01:30:56PM +0100, Peter Zijlstra wrote:
> > This seems to make it happy. Not quite sure that's the best solution.
> >
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index 3e99dfef8408..81295bc760fe
Quoting Peter Zijlstra (2020-10-27 15:45:33)
> On Tue, Oct 27, 2020 at 01:29:10PM +0000, Chris Wilson wrote:
>
> > <4> [304.908891] hm#2, depth: 6 [6], 3425cfea6ff31f7f != 547d92e9ec2ab9af
> > <4> [304.908897] WARNING: CPU: 0 PID: 5658 at kernel/locking/lockdep.c:3
Quoting Peter Zijlstra (2020-10-27 12:30:56)
> On Tue, Oct 27, 2020 at 12:59:55PM +0100, Peter Zijlstra wrote:
> > On Tue, Oct 27, 2020 at 11:29:35AM +0000, Chris Wilson wrote:
> > > Quoting tip-bot2 for Peter Zijlstra (2020-10-07 17:20:13)
> > > > The fo
Quoting tip-bot2 for Peter Zijlstra (2020-10-07 17:20:13)
> The following commit has been merged into the locking/core branch of tip:
>
> Commit-ID: 24d5a3bffef117ed90685f285c6c9d2faa3a02b4
> Gitweb:
> https://git.kernel.org/tip/24d5a3bffef117ed90685f285c6c9d2faa3a02b4
> Author:
Quoting kernel test robot (2020-10-02 09:27:40)
> Greeting,
>
> FYI, we noticed a -36.0% regression of
> phoronix-test-suite.supertuxkart.1024x768.Windowed.Basic.1.OldMine.frames_per_second
> due to commit:
Where's the power consumption graph? You have a benchmark that although
is running
Quoting Joonas Lahtinen (2020-09-29 09:18:34)
> (+ intel-gfx for being i915 related)
> (+ Chris who has looked into the issue)
>
> Hi,
>
> Thanks for reporting!
Fixed in commit a4d63c3732f1a0c91abcf5b7f32b4ef7dcd82025
Author: Jason A. Donenfeld
Date: Mon Sep 28 12:35:07 2020 +0200
mm:
Quoting Lu Baolu (2020-08-24 07:31:23)
> Hi Chris,
>
> On 2020/8/22 2:33, Chris Wilson wrote:
> > Quoting Lu Baolu (2019-05-25 06:41:28)
> >> This allows the iommu generic layer to allocate a dma domain and
> >> attach it to a device through the iommu api's. Wit
Quoting Chris Wilson (2020-08-22 00:39:09)
> Quoting Andrew Morton (2020-08-21 23:34:12)
> > On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel wrote:
> >
> > > The __apply_to_page_range() function is also used to change and/or
> > > allocate page-table pages i
changes get synchronized to other page-tables in the
> > system by calling arch_sync_kernel_mappings() when necessary.
> >
> > Tested-by: Chris Wilson #x86-32
> > Cc: # v5.8+
>
> I'm trying to figure out how you figured out that this is 5.8+. Has a
> partic
Quoting Andrew Morton (2020-08-21 21:35:48)
> On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel wrote:
>
> > The __apply_to_page_range() function is also used to change and/or
> > allocate page-table pages in the vmalloc area of the address space.
> > Make sure these changes get synchronized to
system by calling arch_sync_kernel_mappings() when necessary.
>
> Tested-by: Chris Wilson #x86-32
> Cc: # v5.8+
> Signed-off-by: Joerg Roedel
I've doubled check that this patch by itself fixes our x86-32 vmapping
issue. Thanks,
-Chris
Quoting Lu Baolu (2019-05-25 06:41:28)
> This allows the iommu generic layer to allocate a dma domain and
> attach it to a device through the iommu api's. With all types of
> domains being delegated to upper layer, we can remove an internal
> flag which was used to distinguish domains mananged
Quoting Linus Torvalds (2020-08-21 13:41:03)
> On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson wrote:
> >
> > Since synchronising the PTE after assignment is a manual step, use the
> > newly exported interface to flush the PTE after assigning via
> > alloc_vm_area().
>
Quoting Chris Wilson (2020-08-21 11:39:19)
> Quoting Joerg Roedel (2020-08-21 11:23:43)
> > On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote:
> > > We need to store the initial addr, as here addr == end [or earlier on
> > > earlier], so range is (start, addr
Quoting Joerg Roedel (2020-08-21 11:23:43)
> On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote:
> > We need to store the initial addr, as here addr == end [or earlier on
> > earlier], so range is (start, addr).
>
> Right, I missed that, thanks for pointing it out.
Quoting Joerg Roedel (2020-08-21 11:22:04)
> On Fri, Aug 21, 2020 at 10:54:22AM +0100, Chris Wilson wrote:
> > Ok. I thought it had to be after assigning the *ptep. If we apply the
> > sync first, do not have to worry about PGTBL_PTE_MODIFIED from the
> > *ptep?
>
> Hm
Quoting Joerg Roedel (2020-08-21 11:09:02)
> @@ -2333,6 +2339,7 @@ static int __apply_to_page_range(struct mm_struct *mm,
> unsigned long addr,
> pgd_t *pgd;
> unsigned long next;
> unsigned long end = addr + size;
> + pgtbl_mod_mask mask = 0;
> int err = 0;
Quoting Joerg Roedel (2020-08-21 10:51:29)
> On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote:
> > The alloc_vm_area() is another method for drivers to
> > vmap/map_kernel_range that uses apply_to_page_range() rather than the
> > direct vmalloc walkers. This is m
Since synchronising the PTE after assignment is a manual step, use the
newly exported interface to flush the PTE after assigning via
alloc_vm_area().
Reported-by: Pavel Machek
References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were
modified")
Signed-off-by: Chris
tches")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Pavel Machek
Cc: # v5.8+
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 31 ++-
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/dr
Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(),
rather than a direct assignment.
Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_pa
were
modified")
References: 86cf69f1d893 ("x86/mm/32: implement arch_sync_kernel_mappings()")
Signed-off-by: Chris Wilson
Cc: Andrew Morton
Cc: Joerg Roedel
Cc: Linus Torvalds
Cc: Dave Airlie
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Pavel Machek
Cc: David Vrabel
Cc: # v5.8
A couple of trivial fixes for using %zd for size_t.
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
cc: Arnaldo Carvalho de Melo
---
tools/perf/util/session.c | 2 +-
tools/perf/util/zstd.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf
struct rchan *chan = container_of(kref, struct rchan, kref);
> + free_percpu(chan->buf);
> kfree(chan);
That catches the error path for relay_open as well, and the fixes is
correct. Worth a cc:stable, #v4.9+?
Reviewed-by: Chris Wilson
-Chris
engine->gt;
> > - int err;
> > + int err = 0;
>
> you don't need the initialization here.
But it's close enough that I can munge the patch inline.
Reviewed-by: Chris Wilson
-Chris
Quoting Alex Williamson (2020-07-26 14:30:52)
> On Sun, 26 Jul 2020 17:49:07 +1000
> Geoffrey McRae wrote:
>
> > Hi All,
> >
> > The commit 22540ca3d00d2990a4148a13b92209c3dc5422db causes a Windows KVM
> > guest running under QEMU with a VFIO passthrough GPU to randomly stall
> > when using
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: a7ef9b28aa8d72a1656fa6f0a01bbd1493886317
Gitweb:
https://git.kernel.org/tip/a7ef9b28aa8d72a1656fa6f0a01bbd1493886317
Author:Chris Wilson
AuthorDate:Sat, 25 Jul 2020 19:51:10 +01:00
-
2350439395 0.07 353.38 649647067.36 0.-32
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
---
kernel/locking/lockdep_proc.c | 2 +-
1 file changed, 1 insertion(+), 1
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: 062d3f95b630113e1156a31f376ad36e25da29a7
Gitweb:
https://git.kernel.org/tip/062d3f95b630113e1156a31f376ad36e25da29a7
Author:Chris Wilson
AuthorDate:Thu, 23 Jul 2020 21:10:42 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: da3520d750e36051ecd5847ef712659b9c68ce20
Gitweb:
https://git.kernel.org/tip/da3520d750e36051ecd5847ef712659b9c68ce20
Author:Chris Wilson
AuthorDate:Thu, 23 Jul 2020 21:10:42 +01:00
up during testing, the
warning is only compiled in under CONFIG_SCHED_DEBUG.
Signed-off-by: Chris Wilson
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
---
kernel/sched/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
Quoting Peter Zijlstra (2020-07-23 19:28:41)
> On Wed, Jul 22, 2020 at 10:57:56AM +0100, Chris Wilson wrote:
>
> > Perhaps more damning is that I can replace WF_ON_CPU with p->on_cpu to
> > suppress the warning:
>
> *argh*, I'm starting to go mad...
>
> Chri
Quoting pet...@infradead.org (2020-07-21 12:37:19)
> On Tue, Jul 21, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > Quoting Peter Zijlstra (2020-06-22 11:01:23)
> > > @@ -2378,6 +2385,9 @@ static inline bool ttwu_queue_cond(int c
> > > static bool ttwu_queue_wakelist
Quoting Peter Zijlstra (2020-06-22 11:01:23)
> @@ -2378,6 +2385,9 @@ static inline bool ttwu_queue_cond(int c
> static bool ttwu_queue_wakelist(struct task_struct *p, int cpu, int
> wake_flags)
> {
> if (sched_feat(TTWU_QUEUE) && ttwu_queue_cond(cpu, wake_flags)) {
> + if
Quoting Jisheng Zhang (2020-07-17 07:11:38)
> The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines
> isof_mbi_* APIs when ISOF_MBI is disabled.
>
> Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC platforms.
But it is required for Valleyview/Cherryview and we want to
Quoting YueHaibing (2020-07-15 04:21:04)
> It is not used since commit 058179e72e09 ("drm/i915/gt: Replace
> hangcheck by heartbeats")
>
> Signed-off-by: YueHaibing
Indeed, it is no more.
Reviewed-by: Chris Wilson
-Chris
Quoting Colin King (2020-07-13 15:25:51)
> From: Colin Ian King
>
> There is an error condition where err is not being set and an uninitialized
> garbage value in err is being returned. Fix this by assigning err to an
> appropriate error return value before taking the error exit path.
>
>
efine OAREPORTTRIG5_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */
Ok, these names are not copied straight from the docs, so renaming them
will not hinder us when finding the relevant fields.
Reviewed-by: Chris Wilson
-Chris
for reclaim at
the end of the dma operation [unpin_user_pages()], and for truly
longterm pins to be proactively recovered via device specific shrinkers
[i.e. stop the HW, allow the pages to be returned to the system, and
then compete again for the memory].
Signed-off-by: Chris Wilson
Cc: Andrew Morton
Cc
Quoting Jason Gunthorpe (2020-06-24 17:50:57)
> On Wed, Jun 24, 2020 at 03:37:32PM +0100, Chris Wilson wrote:
> > Quoting Jason Gunthorpe (2020-06-24 15:25:44)
> > > On Wed, Jun 24, 2020 at 03:21:49PM +0100, Chris Wilson wrote:
> > > > Quoting Jason Gunthorpe (2020-06
Quoting Jason Gunthorpe (2020-06-24 15:25:44)
> On Wed, Jun 24, 2020 at 03:21:49PM +0100, Chris Wilson wrote:
> > Quoting Jason Gunthorpe (2020-06-24 15:16:04)
> > > On Wed, Jun 24, 2020 at 03:12:42PM +0100, Chris Wilson wrote:
> > > > Quoting Jason Gunthorpe (2020-06
Quoting Jason Gunthorpe (2020-06-24 15:16:04)
> On Wed, Jun 24, 2020 at 03:12:42PM +0100, Chris Wilson wrote:
> > Quoting Jason Gunthorpe (2020-06-24 13:39:10)
> > > On Wed, Jun 24, 2020 at 01:21:03PM +0100, Chris Wilson wrote:
> > > > Quoting Jason Gunthorpe (2020-06
Quoting Jason Gunthorpe (2020-06-24 13:39:10)
> On Wed, Jun 24, 2020 at 01:21:03PM +0100, Chris Wilson wrote:
> > Quoting Jason Gunthorpe (2020-06-24 13:10:53)
> > > On Wed, Jun 24, 2020 at 09:02:47AM +0100, Chris Wilson wrote:
> > > > When direct reclaim enters the
Quoting Jason Gunthorpe (2020-06-24 13:10:53)
> On Wed, Jun 24, 2020 at 09:02:47AM +0100, Chris Wilson wrote:
> > When direct reclaim enters the shrinker and tries to reclaim pages, it
> > has to opportunitically unmap them [try_to_unmap_one]. For direct
> > reclaim, the calli
the information along that we are inside an
opportunistic unmap that can allow that page to remain referenced and
mapped, and let the callback opt in to avoiding a recursive wait.
Signed-off-by: Chris Wilson
Cc: Andrew Morton
CC: Jason Gunthorpe
---
include/linux/mmu_notifier.h | 15
and subsequently trying to reclaim parts of the
partially acquired object) we have to be careful never to wait on
anything being held by the calling context. Since that is unknown, we
have to avoid waiting from inside direct reclaim.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem
Quoting Pavel Machek (2020-06-22 09:52:59)
> Hi!
>
> Linux duo 5.8.0-rc1+ #117 SMP PREEMPT Mon Jun 15 16:13:54 CEST 2020 x86_64
> GNU/Linux
>
> [133747.719711] [ 17456] 0 17456 4166 271655360
> 0 sshd
> [133747.719718] [ 17466] 1000 17466 4166
"drm/i915/gt: Prevent timeslicing into unpreemptable
> requests")
> Signed-off-by: Gustavo A. R. Silva
Fair enough, I had sent out a patch that included this, but never split
it out for early adoption.
Reviewed-by: Chris Wilson
-Chris
Quoting Sumit Semwal (2020-06-16 13:42:13)
> Hello,
>
> If there are no objections to this, I will plan to merge it soon.
I was going to suggest running it against our CI, but that's unavailable
at the moment.
There's a particularly nasty BUG_ON() in dma_buf_release that we hit
irregularly,
:
> https://lore.kernel.org/lkml/b08611018fdb6d88757c6008a5c02fa0e07b32fb.ca...@perches.com
> Signed-off-by: Kees Cook
Reviewed-by: Chris Wilson
-Chris
Quoting Arnd Bergmann (2020-05-27 15:05:10)
> gcc has a problem following values through IS_ERR/PTR_ERR macros,
> leading to a false-positive warning in allmodconfig, with any
> compiler version:
>
> In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5892:
>
may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
>
> I could not figure out a good way to do this in a way that gcc
> understands better, so initialize the variable to zero, as last
> resort.
Does it look neater if we initialise it as a local? No.
Reviewed-by: Chris Wilson
-Chris
only bit is static, that would be interesting
if that was allowed to change mid gup :)
Reviewed-by: Chris Wilson
-Chris
Quoting John Hubbard (2020-05-22 00:38:41)
> Include FOLL_FAST_ONLY in the list of flags to *not* WARN()
> on, in internal_get_user_pages_fast().
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
> Cc: "Joonas Lahtinen"
> C
Quoting John Hubbard (2020-05-19 01:21:20)
> This needs to go through Andrew's -mm tree, due to adding a new gup.c
> routine. However, I would really love to have some testing from the
> drm/i915 folks, because I haven't been able to run-time test that part
> of it.
CI hit
<4> [185.667750]
Quoting Aishwarya Ramakrishnan (2020-05-18 16:03:36)
> Prefer ARRAY_SIZE instead of using sizeof
>
> Fixes coccicheck warning: Use ARRAY_SIZE
>
> Signed-off-by: Aishwarya Ramakrishnan
Reviewed-by: Chris Wilson
-Chris
Quoting Christophe JAILLET (2020-05-17 09:50:49)
> The label of the last gotos must be switched for the error handling code to
> work as expected.
>
> Fixes: 83bc4ec37210 ("drm/mm: Add a search-by-address variant to only inspect
> a single hole")
> Signed-off-by: Christophe JAILLET
> ---
>
off-by: Nathan Chancellor
I forgot to ping Mika about this,
Reviewed-by: Chris Wilson
-Chris
Quoting Daniel Vetter (2020-05-11 10:11:41)
> No need to micro-optmize when we're waiting in a mocked object ...
It's setting up the expected return values for the test.
-Chris
Quoting Jason A. Donenfeld (2020-04-30 23:10:16)
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something slower in the unlikely
Quoting Christoph Hellwig (2020-05-01 19:07:31)
> On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for
ink: https://github.com/ClangBuiltLinux/linux/issues/1016
> Signed-off-by: Nathan Chancellor
Thanks.
Reviewed-by: Chris Wilson
-Chris
Quoting Colin King (2019-10-09 10:39:35)
> From: Colin Ian King
>
> An earlier commit removed any error assignments to err and we
> are now left with a zero assignment to err and a check that is
> always false. Clean this up by removing the redundant variable
> err and the error check.
Oh, we
Quoting Chris Wilson (2019-10-04 15:08:57)
> Quoting Dan Carpenter (2019-10-04 11:22:51)
> > The "used" variables here come from the user in the ioctl and it can be
> > negative. It could result in an out of bounds write.
> >
> > Signed-off-by: Dan Carpent
Quoting Thomas Gleixner (2019-09-07 16:00:17)
> Does this only happen with that CPU0 hotplug stuff enabled or on CPUs other
> than CPU0 as well? That hotplug CPU0 stuff is a bandaid so I wouldn't be
> surprised if we broke that somehow.
If I ignore cpu0 in that test and so use
[ 133.847187]
1 - 100 of 1356 matches
Mail list logo
