Re: [BUG] Build failure and alleged fix for next-20240523

2024-05-30 Thread Paul E. McKenney
On Thu, May 30, 2024 at 08:28:17PM +0200, Thierry Reding wrote: > On Thu May 30, 2024 at 6:55 PM CEST, Paul E. McKenney wrote: > > On Fri, May 24, 2024 at 12:57:58PM -0700, Abhinav Kumar wrote: > > > Hello > > > > > > On 5/24/2024 12:55 PM, P

Re: [BUG] Build failure and alleged fix for next-20240523

2024-05-30 Thread Paul E. McKenney
On Fri, May 24, 2024 at 12:57:58PM -0700, Abhinav Kumar wrote: > Hello > > On 5/24/2024 12:55 PM, Paul E. McKenney wrote: > > Hello! > > > > I get the following allmodconfig build error on x86 in next-20240523: > > > > Traceback (most recent call

[BUG] Build failure and alleged fix for next-20240523

2024-05-24 Thread Paul E. McKenney
Hello! I get the following allmodconfig build error on x86 in next-20240523: Traceback (most recent call last):   File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in main()   File "drivers/gpu/drm/msm/registers/gen_header.py", line 951, in main

Re: [PATCH 24/29] mm: vmscan: make global slab shrink lockless

2023-07-03 Thread Paul E. McKenney
On Fri, Jun 23, 2023 at 04:29:39PM +1000, Dave Chinner wrote: > On Thu, Jun 22, 2023 at 05:12:02PM +0200, Vlastimil Babka wrote: > > On 6/22/23 10:53, Qi Zheng wrote: > > > @@ -1067,33 +1068,27 @@ static unsigned long shrink_slab(gfp_t gfp_mask, > > > int nid, > > > if (!mem_cgroup_disabled()

Re: [BUG?] INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-.... } 3 jiffies s: 309 root: 0x1/.

2023-04-13 Thread Paul E. McKenney
On Thu, Apr 13, 2023 at 04:32:32PM +0100, Rui Salvaterra wrote: > Hi, Paul, > > On Thu, 13 Apr 2023 at 15:43, Paul E. McKenney wrote: > > > > My guess would be that you have CONFIG_RCU_EXP_CPU_STALL_TIMEOUT set to > > some small non-zero number, for example, you

Re: [BUG?] INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-.... } 3 jiffies s: 309 root: 0x1/.

2023-04-13 Thread Paul E. McKenney
On Thu, Apr 13, 2023 at 08:30:02AM +0100, Rui Salvaterra wrote: > Hi again, everyone. > > So, while preparing to file the bug report with the requested > information, I got a trace completely unrelated to DRM (on a swapon > call, it seems). > > [4.868340] rcu: INFO: rcu_sched detected

Re: Stack-frame warnings in display_mode_vba_32.c

2022-07-30 Thread Paul E. McKenney
On Sat, Jul 30, 2022 at 02:06:10AM -0700, Guenter Roeck wrote: > On 7/29/22 22:12, Paul E. McKenney wrote: > > On Fri, Jul 29, 2022 at 11:41:55PM -0300, André Almeida wrote: > > > Hi Paul, > > > > > > Às 23:25 de 29/07/22, Paul E. McKenney escreveu: > &g

Re: Stack-frame warnings in display_mode_vba_32.c

2022-07-29 Thread Paul E. McKenney
On Fri, Jul 29, 2022 at 11:41:55PM -0300, André Almeida wrote: > Hi Paul, > > Às 23:25 de 29/07/22, Paul E. McKenney escreveu: > > Hello! > > > > I am seeing the following in allmodconfig builds of recent -next on x86: > > > > drivers/gpu

Stack-frame warnings in display_mode_vba_32.c

2022-07-29 Thread Paul E. McKenney
Hello! I am seeing the following in allmodconfig builds of recent -next on x86: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c: In function ‘DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation’:

Re: [PATCH linux-next] video: fbdev: fbmem: fix pointer reference to null device field

2022-02-10 Thread Paul E. McKenney
On Thu, Feb 10, 2022 at 02:58:24PM +0800, Zhouyi Zhou wrote: > In function do_remove_conflicting_framebuffers, if device is NULL, there > will be null pointer reference. The patch add a check to the if expression. > > Signed-off-by: Zhouyi Zhou > --- > Dear Linux folks > > I discover this bug

Re: WARNING: suspicious RCU usage in modeset_lock

2020-12-17 Thread Paul E. McKenney
On Thu, Dec 17, 2020 at 11:03:20AM +0100, Daniel Vetter wrote: > On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote: > > > > On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote: > > > On Wed, Dec 16, 2020 at 2:14 AM syzbot > > > wrote: > > &g

Re: WARNING: suspicious RCU usage in modeset_lock

2020-12-16 Thread Paul E. McKenney
On Wed, Dec 16, 2020 at 10:52:06AM +0100, Daniel Vetter wrote: > On Wed, Dec 16, 2020 at 2:14 AM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:94801e5c Merge tag 'pinctrl-v5.10-3' of git://git.kernel.o.. > > git tree: upstream > >

Re: [PATCH 04/65] mm: Extract might_alloc() debug check

2020-10-23 Thread Paul E. McKenney
> equivalent for GFP_NOWAIT, hence this check can't go wrong due to > memalloc_no*_save/restore contexts. > > Cc: Paul E. McKenney > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Andrew Morton > Cc: Peter Zijlstra > Cc

Re: [PATCH tip/core/rcu 11/15] drm/i915: Cleanup PREEMPT_COUNT leftovers

2020-10-01 Thread Paul E. McKenney
On Thu, Oct 01, 2020 at 10:25:06AM +0200, Thomas Gleixner wrote: > On Thu, Oct 01 2020 at 10:17, Joonas Lahtinen wrote: > > Quoting paul...@kernel.org (2020-09-29 02:30:58) > >> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be > >> removed. Cleanup the leftovers before doing so. > >

Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-17 Thread Paul E. McKenney
On Thu, Sep 17, 2020 at 09:52:30AM +0200, Daniel Vetter wrote: > On Thu, Sep 17, 2020 at 12:39 AM Paul E. McKenney wrote: > > > > On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote: > > > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney > > > wrot

Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-16 Thread Paul E. McKenney
On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote: > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney wrote: > > > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney > > > wrot

Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-16 Thread Paul E. McKenney
On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney wrote: > > > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds > > > wrote: >

Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-16 Thread Paul E. McKenney
On Wed, Sep 16, 2020 at 08:23:52PM +0100, Matthew Wilcox wrote: > On Mon, Sep 14, 2020 at 11:55:24PM +0200, Thomas Gleixner wrote: > > But just look at any check which uses preemptible(), especially those > > which check !preemptible(): > > hmm. > > +++ b/include/linux/preempt.h > @@ -180,7

Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-16 Thread Paul E. McKenney
On Wed, Sep 16, 2020 at 11:32:00AM -0700, Linus Torvalds wrote: > On Wed, Sep 16, 2020 at 8:29 AM Paul E. McKenney wrote: > > > > All fair, but some of us need to write code that must handle being > > invoked from a wide variety of contexts. > > Note that I th

Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-16 Thread Paul E. McKenney
On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds > wrote: > > > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner wrote: > > > > > > OTOH, having a working 'preemptible()' or maybe better named > > > 'can_schedule()' check makes tons

Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Paul E. McKenney
On Mon, Sep 14, 2020 at 01:59:15PM -0700, Linus Torvalds wrote: > On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner wrote: > > > > Recently merged code does: > > > > gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; > > > > Looks obviously correct, except for the fact that preemptible() is >

Re: [PATCH 11/11] rcu: constify sysrq_key_op

2020-05-13 Thread Paul E. McKenney
On Wed, May 13, 2020 at 10:43:51PM +0100, Emil Velikov wrote: > With earlier commits, the API no longer discards the const-ness of the > sysrq_key_op. As such we can add the notation. > > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: linux-ker...@vger.kernel.org > Cc: &qu

Re: [PATCH 03/35] docs: fix broken references to text files

2020-04-08 Thread Paul E. McKenney
irier # > hwtracing/coresight/Kconfig > Signed-off-by: Mauro Carvalho Chehab For the memory-barrier.txt portions: Reviewed-by: Paul E. McKenney > --- > Documentation/memory-barriers.txt| 2 +- > Documentation/process/submit-checklist.rst | 2 +- >

Re: rcu_barrier() no longer allowed within mmap_sem?

2020-03-30 Thread Paul E. McKenney
On Mon, Mar 30, 2020 at 03:00:35PM +0200, Daniel Vetter wrote: > Hi all, for all = rcu, cpuhotplug and perf maintainers > > We've hit an interesting new lockdep splat in our drm/i915 CI: > >

[PATCH] Make drm_dp_mst_dsc_aux_for_port() safe for old compilers

2020-03-04 Thread Paul E. McKenney
introduced into v5.6-rc1. Fixes: 5b03f9d86880 ("drm/dp_mst: Add new quirk for Synaptics MST hubs") Suggested-by: Chris Wilson Suggested-by: Joe Perches Suggested-by: Christoph Hellwig Signed-off-by: Paul E. McKenney Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter diff --g

Re: drm_dp_mst_topology.c and old compilers

2020-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2020 at 07:58:58AM +, Chris Wilson wrote: > Quoting Alex Deucher (2020-02-20 02:52:32) > > On Wed, Feb 19, 2020 at 7:42 PM Paul E. McKenney wrote: > > > > > > Hello! > > > > > > A box with GCC 4.8.3 compiler didn't like drm_dp_

drm_dp_mst_topology.c and old compilers

2020-02-19 Thread Paul E. McKenney
Hello! A box with GCC 4.8.3 compiler didn't like drm_dp_mst_topology.c. The following (lightly tested) patch makes it happy and seems OK for newer compilers as well. Is this of interest? Thanx, Paul

[tip: core/rcu] drm/i915: Replace rcu_swap_protected() with rcu_replace_pointer()

2019-10-31 Thread tip-bot2 for Paul E. McKenney
The following commit has been merged into the core/rcu branch of tip: Commit-ID: 1feace5d6a4a1acf44dde2bfb5c36cc0b1cf559c Gitweb: https://git.kernel.org/tip/1feace5d6a4a1acf44dde2bfb5c36cc0b1cf559c Author:Paul E. McKenney AuthorDate:Mon, 23 Sep 2019 15:22:15 -07:00

Re: [PATCH tip/core/rcu 03/10] drivers/gpu: Replace rcu_swap_protected() with rcu_replace()

2019-10-28 Thread Paul E. McKenney
On Mon, Oct 28, 2019 at 02:57:26PM +0200, Joonas Lahtinen wrote: > Quoting paul...@kernel.org (2019-10-22 22:12:08) > > From: "Paul E. McKenney" > > > > This commit replaces the use of rcu_swap_protected() with the more > > intuitively appealing rcu

Re: [PATCH 1/7] docs: fix broken doc references due to renames

2019-07-29 Thread Paul E. McKenney
Reviewed-by: Jerry Hoemann # hpwdt.rst Acked-by: Paul E. McKenney > --- > Documentation/RCU/rculist_nulls.txt | 2 +- > Documentation/devicetree/bindings/arm/idle-states.txt | 2 +- > Documentation/locking/spinlocks.rst | 4 ++-- >

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-10 Thread Paul E. McKenney
On Tue, Apr 09, 2019 at 02:04:11PM -0400, Mathieu Desnoyers wrote: > - On Apr 9, 2019, at 1:55 PM, paulmck paul...@linux.ibm.com wrote: > [...] > > The current state is not horrible, so my thought would be to give it > > some time to see if better thoughts arise. > > > > Either way,

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-10 Thread Paul E. McKenney
> >> >> > j...@joelfernandes.org > >> >> >> >> > wrote: > >> >> >> >> > > >> >> >> >> > > On Sun, Apr 07, 2019 at 03:26:16PM -0400,

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-10 Thread Paul E. McKenney
gt; >> > > >> >> >> >> >> > - On Apr 7, 2019, at 3:32 PM, Joel Fernandes, Google > >> >> >> >> >> > j...@joelfernandes.org > >> >> >> >> &g

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-09 Thread Paul E. McKenney
7, 2019, at 3:32 PM, Joel Fernandes, Google > >> >> > j...@joelfernandes.org > >> >> > wrote: > >> >> > > >> >> > > On Sun, Apr 07, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote: > >> >> > >> - On Apr 7, 2019, at 9:59

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-09 Thread Paul E. McKenney
> >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com wrote: > >> > >> > >> > >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote: > >> > >> >> On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fern

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-08 Thread Paul E. McKenney
On Sat, Apr 06, 2019 at 01:33:27PM +, Joel Fernandes wrote: > On Fri, Apr 05, 2019 at 04:28:35PM -0700, Paul E. McKenney wrote: > > On Wed, Apr 03, 2019 at 09:20:39AM -0700, Paul E. McKenney wrote: > > > On Wed, Apr 03, 2019 at 10:27:42AM -0400, Mathieu Desnoyers wrote: >

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-08 Thread Paul E. McKenney
On Sun, Apr 07, 2019 at 08:36:46PM -0400, Joel Fernandes wrote: > On Sun, Apr 07, 2019 at 10:05:14AM -0700, Paul E. McKenney wrote: > > On Sun, Apr 07, 2019 at 03:46:13PM +, Joel Fernandes wrote: > > > On Sun, Apr 07, 2019 at 06:59:37AM -0700, Paul E. McKenney wrote: >

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-08 Thread Paul E. McKenney
On Wed, Apr 03, 2019 at 09:20:39AM -0700, Paul E. McKenney wrote: > On Wed, Apr 03, 2019 at 10:27:42AM -0400, Mathieu Desnoyers wrote: > > - On Apr 3, 2019, at 9:32 AM, paulmck paul...@linux.ibm.com wrote: > > > > > On Tue, Apr 02, 2019 at 11:34:07AM -0400,

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-08 Thread Paul E. McKenney
7, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote: > > >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com wrote: > > >> > > >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrot

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-08 Thread Paul E. McKenney
On Sun, Apr 07, 2019 at 03:46:13PM +, Joel Fernandes wrote: > On Sun, Apr 07, 2019 at 06:59:37AM -0700, Paul E. McKenney wrote: > > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote: > > > On Sat, Apr 06, 2019 at 07:06:13PM -0400, Jo

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-08 Thread Paul E. McKenney
On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote: > On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote: [ . . . ] > > > diff --git a/include/asm-generic/vmlinux.lds.h > > > b/include/asm-generic/vmlinux.lds.h > > > index f8f

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-08 Thread Paul E. McKenney
On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote: > On Fri, Apr 05, 2019 at 04:28:35PM -0700, Paul E. McKenney wrote: > > On Wed, Apr 03, 2019 at 09:20:39AM -0700, Paul E. McKenney wrote: > > > On Wed, Apr 03, 2019 at 10:27:42AM -0400, Mathieu Desnoyers wrote: >

Re: [PATCH RFC tip/core/rcu 3/4] drivers/gpu/drm/amd: Dynamically allocate kfd_processes_srcu

2019-04-05 Thread Paul E. McKenney
On Tue, Apr 02, 2019 at 05:40:54PM +, Kuehling, Felix wrote: > On 2019-04-02 10:29 a.m., Paul E. McKenney wrote: > > Having DEFINE_SRCU() or DEFINE_STATIC_SRCU() in a loadable module > > requires that the size of the reserved region be increased, which is > > not som

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-04 Thread Paul E. McKenney
On Wed, Apr 03, 2019 at 10:27:42AM -0400, Mathieu Desnoyers wrote: > - On Apr 3, 2019, at 9:32 AM, paulmck paul...@linux.ibm.com wrote: > > > On Tue, Apr 02, 2019 at 11:34:07AM -0400, Mathieu Desnoyers wrote: > >> - On Apr 2, 2019, at 11:23 AM, paulmck paul...@linux.ibm.com wrote: > >> >

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-04 Thread Paul E. McKenney
On Tue, Apr 02, 2019 at 11:34:07AM -0400, Mathieu Desnoyers wrote: > - On Apr 2, 2019, at 11:23 AM, paulmck paul...@linux.ibm.com wrote: > > > On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote: > >> - On Apr 2, 2019, at 10:28 AM, paulmck paul...@linux.ibm.com wrote: > >>

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-04 Thread Paul E. McKenney
On Tue, Apr 02, 2019 at 02:40:54PM -0400, Joel Fernandes wrote: > On Tue, Apr 02, 2019 at 08:23:34AM -0700, Paul E. McKenney wrote: > > On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote: > > > - On Apr 2, 2019, at 10:28 AM, paulmck paul...@l

[PATCH RFC tip/core/rcu 2/4] drivers/gpu/drm: Dynamically allocate drm_unplug_srcu

2019-04-03 Thread Paul E. McKenney
includes dynamically allocated srcu_struct structures), and therefore cannot tell whether it is being called on something that has been passed to init_srcu_struct(). Thus the code added to drm_core_init() is a bit non-standard. Reported-by: kbuild test robot Signed-off-by: Paul E. McKenney Cc

[PATCH RFC tip/core/rcu 3/4] drivers/gpu/drm/amd: Dynamically allocate kfd_processes_srcu

2019-04-03 Thread Paul E. McKenney
of defining kfd_processes_srcu as a simple srcu_struct, initializing it in amdgpu_amdkfd_init(), and cleaning it up in amdgpu_amdkfd_fini(). Reported-by: kbuild test robot Signed-off-by: Paul E. McKenney Tested-by: kbuild test robot Cc: Oded Gabbay Cc: Alex Deucher Cc: "Christian König"

Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-03 Thread Paul E. McKenney
On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote: > - On Apr 2, 2019, at 10:28 AM, paulmck paul...@linux.ibm.com wrote: > > > Hello! > > > > This series prohibits use of DEFINE_SRCU() and DEFINE_STATIC_SRCU() > > by loadable modules. The reason for this prohibition is the

[PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules

2019-04-03 Thread Paul E. McKenney
Hello! This series prohibits use of DEFINE_SRCU() and DEFINE_STATIC_SRCU() by loadable modules. The reason for this prohibition is the fact that using these two macros within modules requires that the size of the reserved region be increased, which is not something we want to be doing all that

Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/

2018-09-05 Thread Paul E. McKenney
, but I rather not > if we just want to delete them anyway. > > As a starting point, remove all index-files and references to 00-INDEX and > see where the discussion is going. For the RCU portions: Acked-by: Paul E. McKenney > Again, sorry for the insanely wide distribution. &

Re: linux-next: build failure after merge of the rcu tree

2017-03-08 Thread Paul E. McKenney
On Wed, Mar 08, 2017 at 11:13:38AM +0100, Daniel Vetter wrote: > On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote: > > Hi Paul, > > > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig) > > failed like this: > > > > In file included from

[PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"

2016-08-12 Thread Paul E. McKenney
On Fri, Aug 12, 2016 at 08:25:43PM +0200, Peter Zijlstra wrote: > On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote: > > If my upcoming testing of the two changes together pans out, I will > > give you a Tested-by -- I am guessing that you don't want to wait > >

[PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"

2016-08-11 Thread Paul E. McKenney
On Thu, Aug 11, 2016 at 12:38:59PM +0200, Daniel Vetter wrote: > On Thu, Aug 11, 2016 at 11:50:21AM +0200, Johannes Berg wrote: > > From: Johannes Berg > > > > This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad. > > > > As Peter explained: > > [...] lockless_dereference() is

drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

2016-08-11 Thread Paul E. McKenney
On Thu, Aug 11, 2016 at 11:44:08AM +0200, Peter Zijlstra wrote: > On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote: > > We are only documenting that the read is outside of the lock, and do not > > require strict ordering on the operation. In this case the more relaxed > >

linux-next: build failure after merge of the tip tree (from the drm-intel tree)

2016-07-05 Thread Paul E. McKenney
On Tue, Jul 05, 2016 at 10:25:12AM +0200, Peter Zijlstra wrote: > On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote: > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index d3502c0603e5..1f91f187b2a8 100644 > > ---

reservation.h: build error with lockdep disabled

2015-11-26 Thread Paul E. McKenney
On Thu, Nov 26, 2015 at 01:43:40PM +, Russell King - ARM Linux wrote: > As of 3c3b177a9369 ("reservation: add suppport for read-only access > using rcu") linux/reservation.h uses lockdep macros: > > +#define reservation_object_held(obj) lockdep_is_held(&(obj)->lock.base) > > This results in

[RESUBMIT] [PATCH] Replace mentions of "list_struct" to "list_head"

2014-11-14 Thread Paul E. McKenney
On Fri, Nov 14, 2014 at 05:09:55AM +0400, Andrey Utkin wrote: > There's no such thing as "list_struct". > > Signed-off-by: Andrey Utkin May as well get group rates on the acks... ;-) Acked-by: Paul E. McKenney > --- > drivers/gpu/drm/

[PATCH] list: Fix order of arguments for hlist_add_after(_rcu)

2014-06-06 Thread Paul E. McKenney
On Fri, Jun 06, 2014 at 03:56:52PM +, David Laight wrote: > From: Behalf Of Ken Helias > > All other add functions for lists have the new item as first argument and > > the > > position where it is added as second argument. This was changed for no good > > reason in this function and makes

Re: 3.1-rc1-git9: Reported regressions 2.6.39 - 3.0

2011-08-16 Thread Paul E. McKenney
On Sun, Aug 14, 2011 at 09:02:27PM +0200, Rafael J. Wysocki wrote: [NOTE: We already have a bug entry for tracking regressions from 3.0: http://bugzilla.kernel.org/show_bug.cgi?id=40982 but there are no reports linked to it, mostly because Maciej is on vacation, but also because the

3.1-rc1-git9: Reported regressions 2.6.39 -> 3.0

2011-08-15 Thread Paul E. McKenney
On Sun, Aug 14, 2011 at 09:02:27PM +0200, Rafael J. Wysocki wrote: > [NOTE: > We already have a bug entry for tracking regressions from 3.0: > > http://bugzilla.kernel.org/show_bug.cgi?id=40982 > > but there are no reports linked to it, mostly because Maciej is on vacation, > but also