Hello!
This series contains torture-test updates:
1. Record grace periods in forward-progress histogram.
2. Explain and simplify odd "for" loop in mkinitrd.sh.
3. Add grace period after CPU offline.
4. Stop abusing IS_ENABLED().
5-9.Fixes to nolibc, plus move it to
On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
> i2c_device_remove does not clear this. When rebinding an I2C device,
> whos IRQ provider has also been rebound this means that an IRQ mapping
> will never
From: Sebastian Andrzej Siewior
srcu_queue_delayed_work_on() disables preemption (and therefore CPU
hotplug in RCU's case) and then checks based on its own accounting if a
CPU is online. If the CPU is online it uses queue_delayed_work_on()
otherwise it fallbacks to queue_delayed_work().
The
The current SRCU implementation has an idx argument of zero or one,
and never anything else. This commit therefore adds a WARN_ON_ONCE()
to complain if this restriction is violated.
Signed-off-by: Paul E. McKenney
---
include/linux/srcu.h | 1 +
1 file changed, 1 insertion(+)
diff --git
On Wed, Jan 9, 2019 at 9:52 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > If I understand things correctly it is valid to set all import/export
> > > callbacks (prime_handle_to_fd, prime_fd_to_handle,
> > > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
> > > supporting dma-buf
Hello!
This series contains SRCU updates:
1. Check for invalid idx argument in srcu_read_unlock().
2. Remove srcu_queue_delayed_work_on(), courtesy of Sebastian
Andrzej Siewior.
Thanx, Paul
* Vignesh R [190109 09:11]:
> 8250_omap is DT only driver so dev->of_node always exists. Drop check
> for existence of valid dev->of_node to simplify omap8250_probe().
That part seems safe to me now.
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
...
> -
On Wed, 2019-01-09 at 12:12 -0800, Andy Lutomirski wrote:
> On Wed, Jan 9, 2019 at 11:46 AM James Bottomley
> wrote:
[...]
> > > I’m not sure I follow. Here are the two properties I’d like to
> > > see:
> > >
> > > 1. If you have an encrypted hibernation image, the only thing you
> > > should
This commit updates the DYNTICK_IRQ_NONIDLE header comment to remove
the obsolete commentary about unmatched rcu_irq_{enter,exit}().
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index
This commit removes the "@irq" argument from the rcu_nmi_exit() docbook
header, given that this function now has no arguments.
Reported-by: kbuild test robot
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/rcu/tree.c
Although the name rcu_process_callbacks() still makes sense for Tiny
RCU, where most of what it does is invoke callbacks, it no longer makes
much sense for Tree RCU, especially given that the actually callback
invocation is relegated to rcu_do_batch(), or, for no-CBs CPUs, to the
rcuo kthreads.
It turns out that it is queue_delayed_work_on() rather than
queue_work_on() that has difficulties when used concurrently with
CPU-hotplug removal operations. It is therefore unnecessary to protect
CPU identification and queue_work_on() with preempt_disable().
This commit therefore removes the
This commit adds the missing asterisks required to make Sphinx pick up
the current header comments for these two functions.
Signed-off-by: Paul E. McKenney
---
include/linux/rcupdate.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/rcupdate.h
Hello!
This series contains miscellaneous fixes:
1. Add docbook for rcu_head_init() and rcu_head_after_call_rcu().
2. Rename rcu_check_callbacks() to rcu_sched_clock_irq().
3. Rename rcu_process_callbacks() to rcu_core() for Tree RCU.
4. Remove preemption disabling from
Both CONTEXT_TRACKING and CONTEXT_TRACKING_FORCE are currently defined
in kernel/rcu/kconfig, which might have made sense at some point, but
no longer does given that RCU refers to neither of these Kconfig options.
This commit therefore moves them to kernel/time/Kconfig, where the rest
of the
The name rcu_check_callbacks() arguably made sense back in the early
2000s when RCU was quite a bit simpler than it is today, but it has
become quite misleading, especially with the advent of dyntick-idle
and NO_HZ_FULL. The rcu_check_callbacks() function is RCU's hook into
the scheduling-clock
From: "Joel Fernandes (Google)"
The rcu_assign_pointer() function currently doesn't do any sparse checking
on the assigned-to pointer. So its possible that a pointer that is
not __rcu annotated is assigned with rcu_assign_pointer without sparse
complaints. Because rcu_dereference() already
The mm-of-the-moment snapshot 2019-01-09-13-40 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
* Rob Herring [190109 19:38]:
> On Wed, Jan 9, 2019 at 1:02 PM H. Nikolaus Schaller
> wrote:
> >
> > From: Tony Lindgren
> >
> > We're currently getting a warning with make dtbs:
> >
> > arch/arm/boot/dts/omap3-gta04.dtsi:720.7-727.4: Warning (graph_port):
> >
From: Junchang Wang
Fix outdated links in whatisRCU.txt.
Signed-off-by: Junchang Wang
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/whatisRCU.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
On Tue, Jan 8, 2019 at 10:30 PM Rong Chen wrote:
> I tested the commit on another machine and the warnings are exist.
> I found " -Wno-vla" was lost after the commit, so I think it's a real problem.
>
> -Werror=designated-init -fplugin-arg-arm_ssp_per_task_plugin-tso=1
>
The rcutree.jiffies_till_sched_qs kernel boot parameter used to solicit
help only from rcu_note_context_switch(), but now also solicits help
from cond_resched(). This commit therefore updates kernel-parameters.txt
accordingly.
Signed-off-by: Paul E. McKenney
---
SRCU's synchronize_srcu() may not be invoked from CPU-hotplug notifiers,
due to the fact that SRCU grace periods make use of timers and the
possibility of timers being temporarily stranded on the outgoing CPU.
This stranding of timers means that timers posted to the outgoing CPU
will not fire
Hi,
* Heiner Kallweit [190109 19:28]:
> On 09.01.2019 20:06, Tony Lindgren wrote:
> > Commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") caused
> > a regression where suspend resume cycle fails to bring up Ethernet on at
> > least cpsw on am437x-sk-evm.
> >
> What kind of PHY and
Hi arm-soc maintainers,
Please help to look into the following changes and merge them if
they look good.
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
mixing that up. This series is about the FlexSPI
> controller in the Layerscape SOCs.
Thanks for the explanation - I've indeed mixed up things a bit :-).
I was of course thinking about the QuadSPI driver - as in [1].
>
> The QuadSPI driver is already in linux-next to be merged in 5.1
Hello!
This series contains RCU documentation updates:
1. Record the fact that jiffies_till_sched_qs solicits help from
cond_resched().
2. Document that CPU-hotplug notifiers cannot invoke
synchronize_srcu() or srcu_barrier().
3. Fix outdated links, courtesy of
Jacek
On 1/9/19 3:28 PM, Jacek Anaszewski wrote:
> On 1/9/19 10:12 PM, Dan Murphy wrote:
>> On 1/9/19 2:12 PM, Jacek Anaszewski wrote:
>>> Hi Dan,
>>>
>>> On 1/8/19 10:22 PM, Dan Murphy wrote:
On 1/8/19 3:16 PM, Jacek Anaszewski wrote:
> On 1/8/19 9:53 PM, Dan Murphy wrote:
>> Jacek
Dear Sir
My name is Dijana Georgieva of the International Monetary and Financial
Committee (IMFC) of the IMF. The IMF through an electronic random pick has
chosen your name for compensation/payment. At the meeting of heads of
international financial institutions held recently in Geneva
From: "Zhang, Jun"
Currently, __note_gp_changes() checks to see if the rcu_node structure's
->gp_seq_needed is greater than or equal to that of the rcu_data
structure, and if so, updates the rcu_data structure's ->gp_seq_needed
field. This results in a useless store in the case where the two
If a grace period fails to start (for example, because you commented
out the last two lines of rcu_accelerate_cbs_unlocked()), rcu_core()
will invoke rcu_check_gp_start_stall(), which will notice and complain.
However, this complaint is lacking crucial debugging information such
as when the last
Given that RCU has a perfectly good per-CPU rcu_data structure, most
per-CPU quantities should be stored there.
This commit therefore moves the rcu_cpu_has_work per-CPU variable to
the rcu_data structure. This also makes this variable unconditionally
present, which should be acceptable given the
Given that RCU has a perfectly good per-CPU rcu_data structure, most
per-CPU quantities should be stored there.
This commit therefore moves the rcu_cpu_kthread_status per-CPU variable
to the rcu_data structure. This also makes this variable unconditionally
present, which should be acceptable
The rcu_cpu_kthread_loops variable used to provide debugfs information,
but is no longer used. This commit therefore removes it.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.h| 1 -
kernel/rcu/tree_plugin.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/kernel/rcu/tree.h
From: "Zhang, Jun"
The rcu_gp_kthread_wake() function is invoked when it might be necessary
to wake the RCU grace-period kthread. Because self-wakeups are normally
a useless waste of CPU cycles, if rcu_gp_kthread_wake() is invoked from
this kthread, it naturally refuses to do the wakeup.
This commit updates a few obsolete comments in the RCU callback-offload
code.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree_plugin.h | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
Given that RCU has a perfectly good per-CPU rcu_data structure, most
per-CPU quantities should be stored there.
This commit therefore moves the rcu_cpu_kthread_task per-CPU variable to
the rcu_data structure. This also makes this variable unconditionally
present, which should be acceptable given
The rcu_cpu_kthread_cpu used to provide debugfs information, but is no
longer used. This commit therefore removes it.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.h | 4
1 file changed, 4 deletions(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index
Hello!
This series contains commits that improve RCU's ability to make forward
progress on grace periods:
1. Accommodate zero jiffies_till_first_fqs and kthread kicking.
2-6.Move per-CPU variables to rcu_data structure, now that rcu_data
is strictly per-CPU itself due to there
It is perfectly fine to set the rcutree.jiffies_till_first_fqs boot
parameter to zero, in fact, this can be useful on specialty systems that
usually have at least one idle CPU and that need fast grace periods.
This is because this setting causes the RCU grace-period kthread to
scan for idle
Life is hard if RCU manages to get stuck without triggering RCU CPU
stall warnings or triggering the rcu_check_gp_start_stall() checks
for failing to start a grace period. This commit therefore adds a
boot-time-selectable sysrq key (commandeering "y") that allows manually
dumping Tree RCU state.
The rcu_check_gp_kthread_starvation() function can be invoked without
holding locks, so the access to the rcu_state structure's ->gp_flags
field must be protected with READ_ONCE(). This commit therefore adds
this protection.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 2 +-
1 file
On 1/9/19 10:12 PM, Dan Murphy wrote:
On 1/9/19 2:12 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/8/19 10:22 PM, Dan Murphy wrote:
On 1/8/19 3:16 PM, Jacek Anaszewski wrote:
On 1/8/19 9:53 PM, Dan Murphy wrote:
Jacek
On 1/8/19 2:33 PM, Jacek Anaszewski wrote:
Dan,
On 12/19/18 5:26 PM, Dan
On Wed, Jan 09, 2019 at 11:27:31AM -0800, Andrew Morton wrote:
> On Wed, 9 Jan 2019 11:13:44 + Mel Gorman
> wrote:
>
> > Full compaction of a node passes in negative orders which can lead to array
> > boundary issues. While it could be addressed in the control flow of the
> > primary loop,
On 1/9/19 8:04 PM, Sergei Shtylyov wrote:
> On 01/09/2019 09:49 PM, Geert Uytterhoeven wrote:
>
Add a driver for Renesas R-Car Gen3 RPC-IF SPI controller.
Signed-off-by: Mason Yang
>>>
>>>You now need to add:
>>>
>>> Signed-off-by: Sergei Shtylyov
>>
---
On Wed, Jan 09, 2019 at 12:36:11PM -0800, Yang Shi wrote:
> As I mentioned above, if we know some page caches from some memcgs
> are referenced one-off and unlikely shared, why just keep them
> around to increase memory pressure?
It's just not clear to me that your scenarios are generic enough to
On 12/24/18 8:00 PM, Aditya Pakki wrote:
> Currently, vc5_pll_recalc_rate() may produce incorrect output when
> regmap_bulk_read() fails. The fix checks the return value of the
> latter function and returns 0 in case of failure.
>
> Signed-off-by: Aditya Pakki
> ---
>
On Tue, Jan 08, 2019 at 08:29:31PM +0100, Sam Ravnborg wrote:
> Move drm_can_sleep() out of drmP.h to allow users
> to get rid of the drmP.h include.
>
> There was no header file that was a good match for this helper function.
> So add this to drm_util with the relevant includes.
>
> Update
Given that rcu_force_quiescent_state() is a simple wrapper around
force_quiescent_state(), this commit saves a few lines of code by
inlining force_quiescent_state() into rcu_force_quiescent_state(),
and changing all references to force_quiescent_state() to instead
invoke
During expedited RCU grace-period initialization, IPIs are sent to
all non-idle online CPUs. The IPI handler checks to see if the CPU is
in quiescent state, reporting one if so. This handler looks at three
different cases: (1) The CPU is not in an rcu_read_lock()-based critical
section, (2) The
Now that the RCU flavors have been consolidated, RCU_BH_FLAVOR and
RCU_SCHED_FLAVOR are no longer used. This commit therefore saves a
few lines by removing them.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcu.h | 2 --
kernel/rcu/tree.c | 2 --
2 files changed, 4 deletions(-)
diff --git
Back when there could be multiple RCU flavors running in the same kernel
at the same time, it was necessary to specify the expedited grace-period
IPI handler at runtime. Now that there is only one RCU flavor, the
IPI handler can be determined at build time. There is therefore no
longer any
Now that synchronize_rcu() waits for preempt-disable regions of
code as well as RCU read-side critical sections, synchronize_sched()
can be replaced by synchronize_rcu(), in fact, synchronize_sched()
is now completely equivalent to synchronize_rcu(). This commit
therefore replaces
Now that call_rcu()'s callback is not invoked until after all
preempt-disable regions of code have completed (in addition to explicitly
marked RCU read-side critical sections), call_rcu() can be used in place
of call_rcu_sched(). This commit therefore makes that change.
While in the area, this
Given RCU flavor consolidation, the name rcu_spawn_all_nocb_kthreads()
is quite misleading. It no longer ever creates more than one kthread,
and it does so only for the specified CPU. This commit therefore changes
this name to the more descriptive rcu_spawn_cpu_nocb_kthread(), and also
fixes up
Now that _synchronize_rcu_expedited() has only one caller, and given that
this is a tail call, this commit inlines _synchronize_rcu_expedited()
into synchronize_rcu_expedited().
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree_exp.h | 81 +++
1 file
The rcu_kthread_do_work() function has a single-line body and only one
remaining caller. This commit therefore saves a few lines of code by
inlining rcu_kthread_do_work() into its sole remaining caller.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree_plugin.h | 7 +--
1 file changed, 1
Now that rcu_blocking_is_gp() makes the correct immediate-return
decision for both PREEMPT and !PREEMPT, a single implementation of
synchronize_rcu() will work correctly under both configurations.
This commit therefore eliminates a few lines of code by consolidating
the two implementations of
Back when there were multiple flavors of RCU, it was necessary to
separately count lazy and non-lazy callbacks for each CPU. These counts
were used in CONFIG_RCU_FAST_NO_HZ kernels to determine how long a newly
idle CPU should be allowed to sleep before handling its RCU callbacks.
But now that
The CONFIG_PREEMPT=n and CONFIG_PREEMPT=y implementations of
synchronize_rcu_expedited() are quite similar, and with small
modifications to rcu_blocking_is_gp() can be made identical. This commit
therefore makes this change in order to save a few lines of code and to
reduce the amount of
Hello!
This series contains additional cleanups for RCU flavor consolidation:
1-2.Replace scheduler _sched() APIs with _rcu() counterparts.
3. Renaming and commenting changes due to only one rcuo kthread
per CPU.
4. Make expedited IPI handler return after handling
On Thu, Jan 3, 2019 at 4:13 PM Haiyang Zhang wrote:
> > From: Adrian Vladu
> > Sent: Thursday, January 3, 2019 2:43 PM
> > To: linux-kernel@vger.kernel.org
> > Cc: Adrian Vladu ; KY Srinivasan
> > ; Haiyang Zhang ; Stephen
> > Hemminger ; Sasha Levin ;
> > David S. Miller ; apilotti
> >
> >
On Thu, 2019-01-10 at 08:01 +1100, Dave Chinner wrote:
> On Wed, Jan 09, 2019 at 03:53:29PM -0500, Qian Cai wrote:
> > Easy to reproduce:
> >
> > 1. run LTP oom02 workload to let kswapd acquire this locking order:
> > fs_reclaim -> sb_internal.
> >
> > # grep -i fs_reclaim -C 3
On 1/9/19 2:12 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> On 1/8/19 10:22 PM, Dan Murphy wrote:
>> On 1/8/19 3:16 PM, Jacek Anaszewski wrote:
>>> On 1/8/19 9:53 PM, Dan Murphy wrote:
Jacek
On 1/8/19 2:33 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 12/19/18 5:26 PM, Dan
On Wed, Jan 09, 2019 at 05:34:11PM +0100, Paul Menzel wrote:
> Is there a way to trace the value of `boot_cpu_data` from
> `arch/x86/include/asm/cpufeature.h` with some Linux Kernel magic?
>
> #define boot_cpu_has(bit) cpu_has(_cpu_data, bit)
>
> Or is rebuilding with print statements
On Thu, Dec 20, 2018 at 10:24:27AM -0200, Shayenne Moura wrote:
> This patch serie removes drm_mode_object dependency from
> drm_display_mode struct. This is part of KMS cleanup.
>
> Shayenne Moura (7):
> drm: msm: Cleanup drm_display_mode print str
> drm: omapdrm: Cleanup drm_display_mode
From: Alan Stern
The recent commit adding support for SRCU to the Linux Kernel Memory
Model ended up changing the names and meanings of several relations.
This patch updates the explanation.txt documentation file to reflect
those changes.
It also revises the statement of the RCU Guarantee to a
From: Luc Maranget
This commit checks that the return value of srcu_read_lock() is passed
to the matching srcu_read_unlock(), where "matching" is determined by
nesting. This check operates as follows:
1. srcu_read_lock() creates an integer token, which is stored into
the generated
From: Alan Stern
Add support for SRCU. Herd creates srcu events and linux-kernel.def
associates them with three possible annotations (srcu-lock,
srcu-unlock, and sync-srcu) corresponding to the API routines
srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu().
The linux-kernel.bell
From: Alan Stern
In preparation for adding support for SRCU, rename "crit" to
"rcu-rscs", rename "rscs" to "rcu-rscsi", and remove the restriction
to only the outermost level of nesting.
The name change is needed for disambiguating RCU read-side critical
sections from SRCU read-side critical
From: Alan Stern
In preparation for adding support for SRCU, refactor the definitions
of rcu-fence, rcu-rscsi, rcu-link, and rb by moving the po and po?
terms from the first two to the second two. An rcu-gp relation is
added; it is equivalent to gp with the po and po? terms removed.
This is
This commit updates the section on LKMM limitations to no longer say
that SRCU is not modeled, but instead describe how LKMM's modeling of
SRCU departs from the Linux-kernel implementation.
TL;DR: There is no known valid use case that cares about the Linux
kernel's ability to have partially
From: Will Deacon
David Laight explains:
| A long time ago there was a document from Intel that said that
| inb/outb weren't necessarily synchronised wrt memory accesses.
| (Might be P-pro era). However no processors actually behaved that
| way and more recent docs say that inb/outb are
Hello!
This series contains updates for the Linux-kernel memory model:
1-3.Add SRCU support, courtesy of Alan Stern.
4. Update README for adding of SRCU support.
5. Update memory-barriers.txt on enforcing heavy ordering for
port-I/O accesses, courtesy of Will Deacon.
Make sure that all lock order entries that refer to a class are removed
from the list_entries[] array when a kernel module is unloaded.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h | 1 +
kernel/locking/lockdep.c | 19
This patch does not change any functionality but makes the patch that
frees lock classes that are no longer in use easier to read.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h | 14 +++---
1 file changed, 7
This patch does not change the behavior of these functions but makes the
patch that frees unused lock classes easier to read.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 74 +---
1 file
A previous patch introduced a lock chain leak. Fix that leak by reusing
lock chains that have been freed.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 62 ++--
1 file changed, 34
The patch that frees unused lock classes will modify the behavior of
lockdep_free_key_range() and lockdep_reset_lock() depending on whether
or not these functions are called from the context of the lockdep
selftests. Hence make it easy to detect whether or not lockdep code
is called from the
Instead of leaving lock classes that are no longer in use in the
lock_classes array, reuse entries from that array that are no longer
in use. Maintain a linked list of free lock classes with list head
'free_lock_class'. Initialize that list from inside register_lock_class()
instead of from inside
Make sure that add_chain_cache() returns 0 and does not modify the
chain hash if nr_chain_hlocks == MAX_LOCKDEP_CHAIN_HLOCKS before this
function is called.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 11 +--
1
Debugging lockdep data structure inconsistencies is challenging. Add
code that verifies data structure consistency at runtime. That code is
disabled by default because it is very CPU intensive.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
Commit 87915adc3f0a ("workqueue: re-add lockdep dependencies for flushing")
improved deadlock checking in the workqueue implementation. Unfortunately
that patch also introduced a few false positive lockdep complaints. This
patch suppresses these false positives by allocating the workqueue mutex
This patch does not change any functionality. A later patch will reuse
lock classes that have been freed. In combination with that patch this
patch wil have the effect of initializing lock class order lists once
instead of every time a lock class structure is reinitialized.
Cc: Peter Zijlstra
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index acf61dbb8b30..72cff86829e6 100644
---
Hi Peter and Ingo,
A known shortcoming of the current lockdep implementation is that it requires
lock keys to be allocated statically. This forces certain unrelated
synchronization objects to share keys and this key sharing can cause false
positive deadlock reports. This patch series adds support
A shortcoming of the current lockdep implementation is that it requires
lock keys to be allocated statically. That forces certain lock objects
to share lock keys. Since lock dependency analysis groups lock objects
per key sharing lock keys can cause false positive lockdep reports.
Make it possible
This patch does not change any functionality but makes the next patch in
this series easier to read.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 16 +++-
kernel/locking/lockdep_internals.h | 3 ++-
Make sure that the lockdep_register_key() and lockdep_unregister_key()
code is tested when running the lockdep tests.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
tools/lib/lockdep/include/liblockdep/common.h | 2 ++
Change the sizeof(array element time) * (array size) expressions into
sizeof(array). This fixes the size computations of the classhash_table[]
and chainhash_table[] arrays. Commit a63f38cc4ccf ("locking/lockdep:
Convert hash tables to hlists") namely changed the type of the elements
of that array
Instead of abandoning elements of list_entries[] that are no longer in
use, make alloc_list_entry() reuse array elements that have been freed.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 48
On Wed, Jan 09, 2019 at 03:53:29PM -0500, Qian Cai wrote:
> Easy to reproduce:
>
> 1. run LTP oom02 workload to let kswapd acquire this locking order:
>fs_reclaim -> sb_internal.
>
> # grep -i fs_reclaim -C 3 /proc/lockdep_chains | grep -C 5 sb_internal
> [826b9172] >s_umount_key#27
Wolfgang
On 11/3/18 5:45 AM, Wolfgang Grandegger wrote:
> Hello Dan,
>
> Am 31.10.2018 um 21:15 schrieb Dan Murphy:
>> Wolfgang
>>
>> Thanks for the review
>>
>> On 10/27/2018 09:19 AM, Wolfgang Grandegger wrote:
>>> Hello Dan,
>>>
>>> for the RFC, could you please just do the necessary changes
The changes to split ring allocation from open/close, broke
the cleanup of subchannels. This resulted in problems using
uio on network devices because the subchannel was left behind
when the network device was unbound.
The cause was in the disconnect logic which used list splice
to move the
Easy to reproduce:
1. run LTP oom02 workload to let kswapd acquire this locking order:
fs_reclaim -> sb_internal.
# grep -i fs_reclaim -C 3 /proc/lockdep_chains | grep -C 5 sb_internal
[826b9172] >s_umount_key#27
[5fa8b2ac] sb_pagefaults
[33f1247e] sb_internal
Hi,
> > If I understand things correctly it is valid to set all import/export
> > callbacks (prime_handle_to_fd, prime_fd_to_handle,
> > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
> > supporting dma-buf import/export and still advertise DRIVER_PRIME to
> > indicate the
On Tue, 2018-12-18 at 14:41 -0800, Jaegeuk Kim wrote:
> [ ... ]
Please post new versions of a patch as a new e-mail thread instead of
as a reply to a previous e-mail.
> [ ... ]
>
> if (lo->lo_offset != info->lo_offset ||
> lo->lo_sizelimit != info->lo_sizelimit) {
> +
Hi Paweł,
Thank you for the patch.
On 1/9/19 7:00 PM, Paweł Chmiel wrote:
This commit corrects max and step values for v4l2 control for
V4L2_CID_JPEG_RESTART_INTERVAL. Max should be 0x and step should be 1.
It was found by using v4l2-compliance tool and checking result of
Do you have photos for editing? We asked this because we see your photos on
your website.
We mainly supply service for photos cut out , clipping path, and
retouching.
You may just send us a photo, we can provide you test editing to check
quality.
Thanks,
Jane
Quoting Jianxin Pan (2018-12-17 08:24:10)
> diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c
> new file mode 100644
> index 000..2582a98
> --- /dev/null
> +++ b/drivers/clk/meson/mmc-clkc.c
> @@ -0,0 +1,304 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + *
301 - 400 of 1253 matches
Mail list logo
