Re: Linux 5.3-rc7

Quoting Thomas Gleixner (2019-09-07 15:29:19) > On Sat, 7 Sep 2019, Chris Wilson wrote: > > Quoting Linus Torvalds (2019-09-02 18:28:26) > > > Bandan Das: > > > x86/apic: Include the LDR when clearing out APIC registers > > > > Apologies if this is

Re: Linux 5.3-rc7

Quoting Linus Torvalds (2019-09-02 18:28:26) > Bandan Das: > x86/apic: Include the LDR when clearing out APIC registers Apologies if this is known already, I'm way behind on email. I've bisected [ 18.693846] smpboot: CPU 0 is now offline [ 19.707737] smpboot: Booting Node 0 Processor

Re: dma-buf: Add selftests for dma-fence

Quoting Geert Uytterhoeven (2019-08-27 13:30:04) > Hi Chris, > > When running the new dmabuf-selftests on two different systems, I get: > > dma-buf: Running sanitycheck > dma-buf: Running dma_fence > sizeof(dma_fence)=48 > dma-buf: Running dma_fence/sanitycheck > dma-buf:

Re: [PATCH] drm: selftests: Fix a typo in test-drm_mm.c

Quoting Masanari Iida (2019-08-19 14:05:52) > This patch fix a spelling typo in test-drm_mm.c > > Signed-off-by: Masanari Iida Reviewed-by: Chris Wilson -Chris

Re: [Intel-gfx] [PATCH] drm/i915: Stop reconfiguring our shmemfs mountpoint

Quoting Matthew Auld (2019-08-09 19:47:02) > On Thu, 8 Aug 2019 at 18:23, Chris Wilson wrote: > > > > The filesystem reconfigure API is undergoing a transition, breaking our > > current code. As we only set the default options, we can simply remove > > t

Re: 5.3-rc3: Frozen graphics with kcompactd migrating i915 pages

Quoting Martin Wilck (2019-08-09 13:41:42) > This happened to me today, running kernel 5.3.0-rc3-1.g571863b-default > (5.3-rc3 with just a few patches on top), after starting a KVM virtual > machine. The X screen was frozen. Remote login via ssh was still > possible, thus I was able to retrieve

Re: [PATCH 1/2] i915: convert to new mount API

> + ok = false; > } > > +out: > + if (!ok) > + pr_err("i915 gemfs reconfiguration failed\n"); Let's make it a bit more user friendly, dev_err(i915->drm.dev, "Unable to reconfigure internal shmemfs for preferred" " allocation strategy; continuing, but performance may suffer.\n"); Assuming that we can't just use vfs_kern_mount() instead, with the nits Reviewed-by: Chris Wilson -Chris

Re: [PATCH] drm/vgem: fix cache synchronization on arm/arm64

Quoting Rob Clark (2019-08-01 16:18:45) > On Thu, Aug 1, 2019 at 5:40 AM Chris Wilson wrote: > > > > Quoting Sean Paul (2019-07-31 20:23:31) > > > On Fri, Jul 19, 2019 at 11:21:53AM +0200, Daniel Vetter wrote: > > > > On Wed, Jul 17, 2019 at 02:15:37PM -0700,

Re: [PATCH] drm/vgem: fix cache synchronization on arm/arm64

Quoting Sean Paul (2019-07-31 20:23:31) > On Fri, Jul 19, 2019 at 11:21:53AM +0200, Daniel Vetter wrote: > > On Wed, Jul 17, 2019 at 02:15:37PM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > drm_cflush_pages() is no-op on arm/arm64. But instead we can use > > > dma_sync API. > > > >

Re: [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

Quoting Thomas Gleixner (2019-07-26 20:18:32) > On Fri, 26 Jul 2019, Chris Wilson wrote: > > Quoting Thomas Gleixner (2019-07-25 22:55:45) > > > On Thu, 25 Jul 2019, Josh Poimboeuf wrote: > > > > > > > Objtool reports: > > > > > > >

Re: [BUG] lockdep splat with kernfs lockdep annotations and slab mutex from drm patch??

Quoting Steven Rostedt (2019-07-11 03:57:20) > On Fri, 14 Jun 2019 08:38:37 -0700 > Tejun Heo wrote: > > > Hello, > > > > On Fri, Jun 14, 2019 at 04:08:33PM +0100, Chris Wilson wrote: > > > #ifdef CONFIG_MEMCG > > > if (slab

Re: NMI hardlock stacktrace deadlock [was Re: Linux 5.2-rc5]

Quoting Thomas Gleixner (2019-06-21 20:33:36) > On Fri, 21 Jun 2019, Chris Wilson wrote: > > > Quoting Thomas Gleixner (2019-06-21 16:30:52) > > > Chris, do you have the actual NMI lockup detector splats somewhere? > > > > Sorry, I'm having a hard time repro

Re: NMI hardlock stacktrace deadlock [was Re: Linux 5.2-rc5]

Quoting Thomas Gleixner (2019-06-21 16:30:52) > Chris, do you have the actual NMI lockup detector splats somewhere? Sorry, I'm having a hard time reproducing this at will now. The test case depends on the right timing of the wrong event to cause the GPU to hang. >From memory, I got the

Re: NMI hardlock stacktrace deadlock [was Re: Linux 5.2-rc5]

Quoting Linus Torvalds (2019-06-19 19:49:37) > On Wed, Jun 19, 2019 at 5:40 AM Chris Wilson wrote: > > > > I haven't bisected this, but with the merge of rc5 into our CI we > > started hitting an issue that resulted in a oops and the NMI watchdog > > firing as we dum

NMI hardlock stacktrace deadlock [was Re: Linux 5.2-rc5]

I haven't bisected this, but with the merge of rc5 into our CI we started hitting an issue that resulted in a oops and the NMI watchdog firing as we dumped the ftrace. This NMI watchdog locks up prior to the backtraces being printed, preventing the machine from rebooting, and can be avoided with

Re: [PATCH v4] page cache: Store only head pages in i_pages

Quoting Chris Wilson (2019-06-12 08:42:05) > Quoting Kirill A. Shutemov (2019-06-12 02:46:34) > > On Sun, Jun 02, 2019 at 10:47:35PM +0100, Chris Wilson wrote: > > > Quoting Matthew Wilcox (2019-03-07 15:30:51) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memor

Re: [PATCH v4] page cache: Store only head pages in i_pages

Quoting Kirill A. Shutemov (2019-06-12 02:46:34) > On Sun, Jun 02, 2019 at 10:47:35PM +0100, Chris Wilson wrote: > > Quoting Matthew Wilcox (2019-03-07 15:30:51) > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > > index 404acdcd0455..aaf88f85d492 100644 &

Re: [PATCH v4] page cache: Store only head pages in i_pages

Quoting Matthew Wilcox (2019-03-07 15:30:51) > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 404acdcd0455..aaf88f85d492 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2456,6 +2456,9 @@ static void __split_huge_page(struct page *page, struct > list_head *list, >

Re: [PATCH v4] page cache: Store only head pages in i_pages

Quoting Matthew Wilcox (2019-06-02 11:51:50) > On Sat, Jun 01, 2019 at 12:44:28PM +0100, Chris Wilson wrote: > > Quoting Chris Wilson (2019-06-01 10:26:21) > > > Quoting Matthew Wilcox (2019-03-07 15:30:51) > > > > Transparent Huge Pages are currently

Re: [PATCH v4] page cache: Store only head pages in i_pages

Quoting Matthew Wilcox (2019-06-02 11:51:50) > Thanks for the reports, Chris. > > I think they're both canaries; somehow the page cache / swap cache has > got corrupted and contains entries that it shouldn't. > > This second one (with the VM_BUG_ON_PAGE in __delete_from_swap_cache) > shows a

Re: [PATCH v4] page cache: Store only head pages in i_pages

Quoting Chris Wilson (2019-06-01 10:26:21) > Quoting Matthew Wilcox (2019-03-07 15:30:51) > > Transparent Huge Pages are currently stored in i_pages as pointers to > > consecutive subpages. This patch changes that to storing consecutive > > pointers to the head page in pr

Re: [PATCH v4] page cache: Store only head pages in i_pages

Quoting Matthew Wilcox (2019-03-07 15:30:51) > Transparent Huge Pages are currently stored in i_pages as pointers to > consecutive subpages. This patch changes that to storing consecutive > pointers to the head page in preparation for storing huge pages more > efficiently in i_pages. > > Large

Re: [PATCH v2] x86/fpu: Use fault_in_pages_writeable() for pre-faulting

ug here by putting the system under mempressure, and afterwards processes would die as the exit. This patch also greatly reduces cycletest latencies while under that mempressure, ~320ms -> ~16ms (on a bxt while also spinning on i915.ko). Tested-by: Chris Wilson -Chris

Re: [PATCH] gpu: i915: fix a missing check of get_free_page

Quoting Kangjie Lu (2019-03-09 04:24:50) > If the allocation fails, return false to avoid potential > NULL pointer dereference No. If we fail to allocate c->tmp, we do uncached reads instead. -Chris

Re: [Intel-gfx] [PATCH] drm/i915: Zero initialize this_cpu in busywait_stop

Quoting Nathan Chancellor (2019-03-08 01:20:24) > When building with -Wsometimes-uninitialized, Clang warns: > > drivers/gpu/drm/i915/i915_request.c:1032:6: warning: variable 'this_cpu' > is used uninitialized whenever '&&' condition is false > [-Wsometimes-uninitialized] > > time_after expands

Re: [PATCH] log2: make is_power_of_2() integer constant expression when possible

s. > > Make is_power_of_2() an integer constant expression when possible, > otherwise using the inline function to avoid multiple evaluation of the > parameter. > > Cc: Chris Wilson > Signed-off-by: Jani Nikula It does what it says on the tin and allows for static

Re: [PATCH 6/8] i915,uaccess: Fix redundant CLAC

ble > > AKA. you don't need user_access_end() if user_access_begin() fails. Cool, I had no idea if it was required or not. The closest to instructions on how to use user_access_begin() is in arch/x86/include/asm/uaccess.h ... which I guess is earlier in this series! > Cc: Chris Wilson &

Re: [Intel-gfx] [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE

Quoting Thomas Gleixner (2019-02-28 10:09:26) > On Thu, 28 Feb 2019, Chris Wilson wrote: > > > Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38) > > > On 2019-02-12 17:28:57 [+0100], To linux-kernel@vger.kernel.org wrote: > > > > The timer is initialized

Re: [Intel-gfx] [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE

Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38) > On 2019-02-12 17:28:57 [+0100], To linux-kernel@vger.kernel.org wrote: > > The timer is initialized with TIMER_IRQSAFE flag. It does look like the > > timer callback requires this flag at all. Its sole purpose is to ensure > >

Re: [PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails

mb operations") > Cc: Rodrigo Siqueira > Cc: Haneen Mohammed > Cc: Daniel Vetter > Cc: Chris Wilson > Cc: sta...@vger.kernel.org > Signed-off-by: Eric Biggers Reviewed-by: Chris Wilson -Chris

Re: [PATCH] drm/vgem: fix use-after-free when drm_gem_handle_create() fails

quot;drm/vgem: Enable dmabuf import interfaces") Cc: Chris Wilson Cc: Laura Abbott Cc: Daniel Vetter Sadly I reviewed it so I'm still culpable, but the fix is correct as the put purposely frees it on error. > Cc: sta...@vger.kernel.org > Signed-off-by: Eric Biggers > --- >

Re: [PATCH][next] drm/i915/selftests: fix memory leak of 'spin'

gned-off-by: Colin Ian King I hope already fixed by commit 2a4a2754039594c60b58b02b6781428a85f6d745 Author: Chris Wilson Date: Fri Feb 15 19:50:10 2019 + drm/i915/selftests: Always free spinner on __sseu_prepare error Thanks, -Chris

Re: [PATCH v3 1/3] drm/i915: Block fbdev HPD processing during suspend

g us from > actually processing any hotplug events we receive until it's safe. > > This fixes the wakeref leak observed on the T480s and as such, also > fixes suspend/resume with MST topologies connected on this machine. > > Changes since v2: > *

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Block fbdev HPD processing during suspend

Quoting Lyude Paul (2019-01-28 20:56:01) > When resuming, we check whether or not any previously connected > MST topologies are still present and if so, attempt to resume them. If > this fails, we disable said MST topologies and fire off a hotplug event > so that userspace knows to reprobe. > >

Re: [PATCH v2] drm/i915: Disable -Wuninitialized

itly disable the warning like commit 46e2068081e9 ("drm/i915: > > > Disable some extra clang warnings"). > > > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/220 > > > Signed-off-by: Nathan Chancellor > > > > Reviewed-by: Nick Desaulnier

Re: [PATCH] drm/i915_request.h: Remove duplicate header

Quoting Brajeswar Ghosh (2018-12-25 13:23:40) > Remove i915_scheduler.h which is included more than once > > Signed-off-by: Brajeswar Ghosh Thanks for the patch, pushed to dinq. -Chris

Re: [PATCH] drm/i915: Fix i915_gem_wait_for_idle oops due to active_requests check

Quoting Bin Yang (2018-12-20 08:01:35) > Normally, i915_request_alloc() and i915_request_add() will be called > in sequence with drm.struct_mutex locked. But in > intel_vgpu_create_workload(), it will pre-allocate the request and > call i915_request_add() in the workload thread for performance >

Re: [PATCH] drm/i915: Disable -Wuninitialized for intel_breadcrumbs.o

Quoting Nick Desaulniers (2018-10-25 23:20:58) > On Thu, Oct 25, 2018 at 12:36 PM Nathan Chancellor > wrote: > > > > This warning is disabled by default in scripts/Makefile.extrawarn when > > W= is not provided but this Makefile adds -Wall after this warning is > > disabled so it shows up in the

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

Quoting jgli...@redhat.com (2018-12-06 15:47:04) > From: Jérôme Glisse > > The debugfs take reference on fence without dropping them. Also the > rcu section are not well balance. Fix all that ... Wouldn't the code be a lot simpler (and a consistent snapshot) if it used

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

Quoting jgli...@redhat.com (2018-12-06 15:47:04) > From: Jérôme Glisse > > The debugfs take reference on fence without dropping them. Also the > rcu section are not well balance. Fix all that ... Wouldn't the code be a lot simpler (and a consistent snapshot) if it used

Re: [Intel-gfx] [PATCH 3/3] mm, notifier: Add a lockdep map for invalidate_range_start

Quoting Daniel Vetter (2018-11-27 07:49:18) > On Thu, Nov 22, 2018 at 05:51:06PM +0100, Daniel Vetter wrote: > > This is a similar idea to the fs_reclaim fake lockdep lock. It's > > fairly easy to provoke a specific notifier to be run on a specific > > range: Just prep it, and then munmap() it. >

Re: [Intel-gfx] [PATCH 3/3] mm, notifier: Add a lockdep map for invalidate_range_start

Quoting Daniel Vetter (2018-11-27 07:49:18) > On Thu, Nov 22, 2018 at 05:51:06PM +0100, Daniel Vetter wrote: > > This is a similar idea to the fs_reclaim fake lockdep lock. It's > > fairly easy to provoke a specific notifier to be run on a specific > > range: Just prep it, and then munmap() it. >

[PATCH] perf/x86: Bump INTEL_PMC_MAX_FIXED for Icelake

gt;[1.464221] hardirqs last enabled at (367): [] vprintk_emit+0x124/0x320 <4>[1.464252] hardirqs last disabled at (368): [] trace_hardirqs_off_thunk+0x1a/0x1c <4>[1.464287] softirqs last enabled at (0): [] copy_process.part.6+0x504/0x2250 <4>[ 1.464318] softirqs l

[PATCH] perf/x86: Bump INTEL_PMC_MAX_FIXED for Icelake

gt;[1.464221] hardirqs last enabled at (367): [] vprintk_emit+0x124/0x320 <4>[1.464252] hardirqs last disabled at (368): [] trace_hardirqs_off_thunk+0x1a/0x1c <4>[1.464287] softirqs last enabled at (0): [] copy_process.part.6+0x504/0x2250 <4>[ 1.464318] softirqs l

Re: Bug report: HiBMC crash

t; like this patch: > > commit 70109354fed232dfce8fb2c7cadf635acbe03e19 > Author: Chris Wilson > Date: Wed Sep 5 16:31:16 2018 +0100 > > drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c b

Re: Bug report: HiBMC crash

t; like this patch: > > commit 70109354fed232dfce8fb2c7cadf635acbe03e19 > Author: Chris Wilson > Date: Wed Sep 5 16:31:16 2018 +0100 > > drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c b

Re: [PATCH] bitops: Introduce BITS_PER_TYPE

Quoting Randy Dunlap (2018-07-06 18:55:57) > On 07/06/18 10:51, Chris Wilson wrote: > > Quoting Randy Dunlap (2018-07-06 18:48:55) > >> > >> On 07/06/18 02:44, Chris Wilson wrote: > >>> net_dim.h has a rather useful extension to BITS_PER_BYTE to com

Re: [PATCH] bitops: Introduce BITS_PER_TYPE

Quoting Randy Dunlap (2018-07-06 18:55:57) > On 07/06/18 10:51, Chris Wilson wrote: > > Quoting Randy Dunlap (2018-07-06 18:48:55) > >> > >> On 07/06/18 02:44, Chris Wilson wrote: > >>> net_dim.h has a rather useful extension to BITS_PER_BYTE to com

Re: [PATCH] bitops: Introduce BITS_PER_TYPE

Quoting Randy Dunlap (2018-07-06 18:48:55) > > On 07/06/18 02:44, Chris Wilson wrote: > > net_dim.h has a rather useful extension to BITS_PER_BYTE to compute the > > number of bits in a type (BITS_PER_BYTE * sizeof(T)), so promote the > > macro to bitops.h, alongside

Re: [PATCH] bitops: Introduce BITS_PER_TYPE

Quoting Randy Dunlap (2018-07-06 18:48:55) > > On 07/06/18 02:44, Chris Wilson wrote: > > net_dim.h has a rather useful extension to BITS_PER_BYTE to compute the > > number of bits in a type (BITS_PER_BYTE * sizeof(T)), so promote the > > macro to bitops.h, alongside

[PATCH] bitops: Introduce BITS_PER_TYPE

net_dim.h has a rather useful extension to BITS_PER_BYTE to compute the number of bits in a type (BITS_PER_BYTE * sizeof(T)), so promote the macro to bitops.h, alongside BITS_PER_BYTE, for wider usage. Signed-off-by: Chris Wilson Cc: Jani Nikula Cc: Andy Gospodarek Cc: David S. Miller Cc

[PATCH] bitops: Introduce BITS_PER_TYPE

net_dim.h has a rather useful extension to BITS_PER_BYTE to compute the number of bits in a type (BITS_PER_BYTE * sizeof(T)), so promote the macro to bitops.h, alongside BITS_PER_BYTE, for wider usage. Signed-off-by: Chris Wilson Cc: Jani Nikula Cc: Andy Gospodarek Cc: David S. Miller Cc

Re: [PATCH] drm/i915/selftests: fix spelling mistake: "parmaters" -> "parameters"

Quoting Colin King (2018-05-03 16:45:10) > From: Colin Ian King <colin.k...@canonical.com> > > Trivial fix to spelling mistake in pr_err error message > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [PATCH] drm/i915/selftests: fix spelling mistake: "parmaters" -> "parameters"

Quoting Colin King (2018-05-03 16:45:10) > From: Colin Ian King > > Trivial fix to spelling mistake in pr_err error message > > Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson -Chris

Re: [PATCH v3] drm/i915: Disable some extra clang warnings

Quoting Chris Wilson (2018-05-02 10:46:07) > Quoting Matthias Kaehlcke (2018-05-01 19:24:40) > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set > > warnings to full") enabled extra warnings for i915 to spot possible > > bugs in new c

Re: [PATCH v3] drm/i915: Disable some extra clang warnings

Quoting Chris Wilson (2018-05-02 10:46:07) > Quoting Matthias Kaehlcke (2018-05-01 19:24:40) > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set > > warnings to full") enabled extra warnings for i915 to spot possible > > bugs in new c

[PATCH] swiotlb: Suppress "Out of SW-IOMMU" errors for NO_WARN

This extends the warning suppression from commit d0bc0c2a31c9 ("swiotlb: suppress warning when __GFP_NOWARN is set") to suppress the warnings when DMA_ATTR_NO_WARN is given by caller. In such cases the caller wants to handle the error themselves. Fixes: d0bc0c2a31c9 ("swiotlb: suppress warning

[PATCH] swiotlb: Suppress "Out of SW-IOMMU" errors for NO_WARN

This extends the warning suppression from commit d0bc0c2a31c9 ("swiotlb: suppress warning when __GFP_NOWARN is set") to suppress the warnings when DMA_ATTR_NO_WARN is given by caller. In such cases the caller wants to handle the error themselves. Fixes: d0bc0c2a31c9 ("swiotlb: suppress warning

Re: [PATCH v3] drm/i915: Disable some extra clang warnings

ternal-declaration and initializer-overrides. If desired > they can be re-enabled after the code has been fixed. > > Signed-off-by: Matthias Kaehlcke <m...@chromium.org> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [PATCH v3] drm/i915: Disable some extra clang warnings

ternal-declaration and initializer-overrides. If desired > they can be re-enabled after the code has been fixed. > > Signed-off-by: Matthias Kaehlcke Reviewed-by: Chris Wilson -Chris

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable some extra clang warnings

Quoting Matthias Kaehlcke (2018-04-30 20:31:19) > On Mon, Mar 19, 2018 at 12:14:51PM -0700, Matthias Kaehlcke wrote: > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set > > warnings to full") enabled extra warnings for i915 to spot possible > > bugs in new code, and then

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable some extra clang warnings

Quoting Matthias Kaehlcke (2018-04-30 20:31:19) > On Mon, Mar 19, 2018 at 12:14:51PM -0700, Matthias Kaehlcke wrote: > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set > > warnings to full") enabled extra warnings for i915 to spot possible > > bugs in new code, and then

[PATCH] x86: Mark up large pm4/5 constants with UL

To silence sparse while maintaining compatibility with the assembly, use _UL which conditionally only appends the UL suffix for C code. Fixes: a7412546d8cb ("x86/mm: Adjust vmalloc base and size at boot-time") Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Ki

[PATCH] x86: Mark up large pm4/5 constants with UL

To silence sparse while maintaining compatibility with the assembly, use _UL which conditionally only appends the UL suffix for C code. Fixes: a7412546d8cb ("x86/mm: Adjust vmalloc base and size at boot-time") Signed-off-by: Chris Wilson Cc: Kirill A. Shutemov Cc: Peter Zijlstra

Re: [PATCH] drm/i915/selftests: Fix uninitialized variable

Quoting Gustavo A. R. Silva (2018-04-24 14:30:58) > > > On 04/24/2018 08:22 AM, Chris Wilson wrote: > > Quoting Gustavo A. R. Silva (2018-04-24 14:15:45) > >> There is a potential execution path in which variable err is > >> returned without being properly init

Re: [PATCH] drm/i915/selftests: Fix uninitialized variable

Quoting Gustavo A. R. Silva (2018-04-24 14:30:58) > > > On 04/24/2018 08:22 AM, Chris Wilson wrote: > > Quoting Gustavo A. R. Silva (2018-04-24 14:15:45) > >> There is a potential execution path in which variable err is > >> returned without being properly init

Re: [PATCH] drm/i915/selftests: Fix uninitialized variable

Quoting Gustavo A. R. Silva (2018-04-24 14:15:45) > There is a potential execution path in which variable err is > returned without being properly initialized previously. > > Fix this by initializing variable err to 0. err is only returned along an error path, returning 0 would not be useful.

Re: [PATCH] drm/i915/selftests: Fix uninitialized variable

Quoting Gustavo A. R. Silva (2018-04-24 14:15:45) > There is a potential execution path in which variable err is > returned without being properly initialized previously. > > Fix this by initializing variable err to 0. err is only returned along an error path, returning 0 would not be useful.

Re: [PATCH] drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path

ne to use kfree. Alternatively, the find_cmd_entry_any_ring() could be moved ahead of the kzalloc as this function must be externally serialised. Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [PATCH] drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path

f (info) { > gvt_err("%s %s duplicated\n", e->info->name, > info->name); > + kfree(e); e kzalloc'ed moments above, not yet added to any lists, so fine to use kfree. Alternatively, the find_cmd_entry_any_ri

Re: [PATCH] gup: return -EFAULT on access_ok failure

Quoting Michael S. Tsirkin (2018-04-05 20:34:08) > On Thu, Apr 05, 2018 at 11:43:27AM -0700, Linus Torvalds wrote: > > On Thu, Apr 5, 2018 at 11:28 AM, Michael S. Tsirkin wrote: > > > > > > to repeat what you are saying IIUC __get_user_pages_fast returns 0 if it > > > can't > >

Re: [PATCH] gup: return -EFAULT on access_ok failure

Quoting Michael S. Tsirkin (2018-04-05 20:34:08) > On Thu, Apr 05, 2018 at 11:43:27AM -0700, Linus Torvalds wrote: > > On Thu, Apr 5, 2018 at 11:28 AM, Michael S. Tsirkin wrote: > > > > > > to repeat what you are saying IIUC __get_user_pages_fast returns 0 if it > > > can't > > > pin any pages

[PATCH] trace: Fixup logic inversion on setting trace_global_clock defaults

ather than a if-block, but reverted back to using the if-block and accidentally left the predicate inverted. Fixes: 932066a15335 ("tracing: Default to using trace_global_clock if sched_clock is unstable") Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Steven Rostedt (VM

[PATCH] trace: Fixup logic inversion on setting trace_global_clock defaults

ather than a if-block, but reverted back to using the if-block and accidentally left the predicate inverted. Fixes: 932066a15335 ("tracing: Default to using trace_global_clock if sched_clock is unstable") Signed-off-by: Chris Wilson Cc: Steven Rostedt (VMware) --- kernel/trace/trace.c | 2 +

Re: [PATCH 1/1] drm/i915: Do not use kfree() to free kmem_cache_alloc() return value

Quoting Xidong Wang (2018-04-04 08:37:54) > In eb_lookup_vmas(), the return value of kmem_cache_alloc() is freed > with kfree(). I think the expected paired function is kmem_cahce_free(). > > Signed-off-by: Xidong Wang Thank you for the fix; applied. -Chris

Re: [PATCH 1/1] drm/i915: Do not use kfree() to free kmem_cache_alloc() return value

Quoting Xidong Wang (2018-04-04 08:37:54) > In eb_lookup_vmas(), the return value of kmem_cache_alloc() is freed > with kfree(). I think the expected paired function is kmem_cahce_free(). > > Signed-off-by: Xidong Wang Thank you for the fix; applied. -Chris

[PATCH v3] trace: Default to using trace_global_clock if sched_clock is unstable

to the trace global clock: echo global > /sys/kernel/debug/tracing/trace_clock Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Steven Rostedt (VMware) <rost...@goodmis.org> --- v2: Tell the user what's happening and what they can do to correct it. v3: Restore th

[PATCH v3] trace: Default to using trace_global_clock if sched_clock is unstable

to the trace global clock: echo global > /sys/kernel/debug/tracing/trace_clock Signed-off-by: Chris Wilson Cc: Steven Rostedt (VMware) --- v2: Tell the user what's happening and what they can do to correct it. v3: Restore the correct logic to switch only if the default trace cl

Re: [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

Quoting Chris Wilson (2018-03-30 16:01:31) > Across suspend, we may see a very large drift in timestamps if the sched > clock is unstable, prompting the global trace's ringbuffer code to warn > and suggest switching to the global clock. Preempt this request by > detecting when the

Re: [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

Quoting Chris Wilson (2018-03-30 16:01:31) > Across suspend, we may see a very large drift in timestamps if the sched > clock is unstable, prompting the global trace's ringbuffer code to warn > and suggest switching to the global clock. Preempt this request by > detecting when the

Re: [PATCH 1/1] drm/i915: Do not use kfree() to free kmem_cache_alloc() return value

d be doing, Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr") Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: <sta...@vger.kernel.org> # v4.14+ Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [PATCH 1/1] drm/i915: Do not use kfree() to free kmem_cache_alloc() return value

4 ("drm/i915: Replace execbuf vma ht with an idr") Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: # v4.14+ Reviewed-by: Chris Wilson -Chris

Re: Signal handling in a page fault handler

Quoting Matthew Wilcox (2018-04-02 15:10:58) > > Souptick and I have been auditing the various page fault handler routines > and we've noticed that graphics drivers assume that a signal should be > able to interrupt a page fault. In contrast, the page cache takes great > care to allow only fatal

Re: Signal handling in a page fault handler

Quoting Matthew Wilcox (2018-04-02 15:10:58) > > Souptick and I have been auditing the various page fault handler routines > and we've noticed that graphics drivers assume that a signal should be > able to interrupt a page fault. In contrast, the page cache takes great > care to allow only fatal

[PATCH v2 2/2] trace: Mention trace_clock=global when warning about unstable clocks

Mention the alternative of adding trace_clock=global to the kernel command line when we detect that we've used an unstable clock across a suspend/resume cycle. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Steven Rostedt <rost...@goodmis.org> --- kernel/trace/ring_

[PATCH v2 2/2] trace: Mention trace_clock=global when warning about unstable clocks

Mention the alternative of adding trace_clock=global to the kernel command line when we detect that we've used an unstable clock across a suspend/resume cycle. Signed-off-by: Chris Wilson Cc: Steven Rostedt --- kernel/trace/ring_buffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion

[PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

to the trace global clock: echo global > /sys/kernel/debug/tracing/trace_clock Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Steven Rostedt (VMware) <rost...@goodmis.org> --- v2: Tell the user what's happening and what they can do to correct it. --- kernel/tra

[PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

to the trace global clock: echo global > /sys/kernel/debug/tracing/trace_clock Signed-off-by: Chris Wilson Cc: Steven Rostedt (VMware) --- v2: Tell the user what's happening and what they can do to correct it. --- kernel/trace/trace.c | 19 +++ 1 file changed, 19 inserti

[PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

to the trace global clock: echo global > /sys/kernel/debug/tracing/trace_clock Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Steven Rostedt (VMware) <rost...@goodmis.org> --- kernel/trace/trace.c | 13 + 1 file changed, 13 insertions(+) diff --git

[PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

to the trace global clock: echo global > /sys/kernel/debug/tracing/trace_clock Signed-off-by: Chris Wilson Cc: Steven Rostedt (VMware) --- kernel/trace/trace.c | 13 + 1 file changed, 13 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 13baf85b2

Re: [PATCH v2 2/2] gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

Quoting Ben Skeggs (2018-03-26 13:34:54) > On Mon, Mar 26, 2018 at 4:01 AM, Arushi Singhal > wrote: > > It's better to use list_entry instead of list_{next/prev}_entry > > as it makes the code more clear to read. > > This patch replace list_entry with

Re: [PATCH v2 2/2] gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

Quoting Ben Skeggs (2018-03-26 13:34:54) > On Mon, Mar 26, 2018 at 4:01 AM, Arushi Singhal > wrote: > > It's better to use list_entry instead of list_{next/prev}_entry > > as it makes the code more clear to read. > > This patch replace list_entry with list_{next/prev}_entry. > > > >

Re: [PATCH] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs

Quoting Gustavo A. R. Silva (2018-03-22 18:21:54) > The checks are misleading and not required [1]. > > [1] https://lkml.org/lkml/2018/3/19/1792 > > Addresses-Coverity-ID: 1466017 > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Signed-off-by: Gustavo A. R. Silva <gu

Re: [PATCH] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs

Quoting Gustavo A. R. Silva (2018-03-22 18:21:54) > The checks are misleading and not required [1]. > > [1] https://lkml.org/lkml/2018/3/19/1792 > > Addresses-Coverity-ID: 1466017 > Cc: Chris Wilson > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Chris Wilson Zhenyu? -Chris

Re: [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

Quoting Colin Ian King (2018-03-21 19:18:28) > On 21/03/18 19:09, Joe Perches wrote: > > On Wed, 2018-03-21 at 19:06 +, Colin King wrote: > >> From: Colin Ian King > >> > >> The pointer workload is dereferenced before it is null checked, hence > >> there is a

Re: [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

Quoting Colin Ian King (2018-03-21 19:18:28) > On 21/03/18 19:09, Joe Perches wrote: > > On Wed, 2018-03-21 at 19:06 +, Colin King wrote: > >> From: Colin Ian King > >> > >> The pointer workload is dereferenced before it is null checked, hence > >> there is a potential for a null pointer

Re: [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

Quoting Gustavo A. R. Silva (2018-03-19 20:50:12) > Hi Chris, > > On 03/19/2018 03:38 PM, Chris Wilson wrote: > > Quoting Gustavo A. R. Silva (2018-03-19 19:30:53) > >> _workload_ is being dereferenced before it is null checked, hence > >> there is a p

Re: [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

Quoting Gustavo A. R. Silva (2018-03-19 20:50:12) > Hi Chris, > > On 03/19/2018 03:38 PM, Chris Wilson wrote: > > Quoting Gustavo A. R. Silva (2018-03-19 19:30:53) > >> _workload_ is being dereferenced before it is null checked, hence > >> there is a p

Re: [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

Quoting Gustavo A. R. Silva (2018-03-19 19:30:53) > _workload_ is being dereferenced before it is null checked, hence > there is a potential null pointer dereference. > > Fix this by moving the pointer dereference after _workload_ has > been null checked. The checks are misleading and not

Re: [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

Quoting Gustavo A. R. Silva (2018-03-19 19:30:53) > _workload_ is being dereferenced before it is null checked, hence > there is a potential null pointer dereference. > > Fix this by moving the pointer dereference after _workload_ has > been null checked. The checks are misleading and not

<    1   2   3   4   5   6   7   8   9   10   >