This prepares for speculative page faults looking up and copying vmas
under protection of an rcu read lock, instead of the usual mmap read lock.
Signed-off-by: Michel Lespinasse
---
include/linux/mm_types.h | 16 +++-
kernel/fork.c| 11 ++-
2 files changed, 21
Change mmap_lock_is_contended to return a bool value, rather than an
int which the callers are then supposed to interpret as a bool. This
is to ensure consistency with other mmap lock API functions (such as
the trylock functions).
Signed-off-by: Michel Lespinasse
---
include/linux/mmap_lock.h
where the entire page table walk (higher levels down to ptes)
needs special care in the speculative case.
Signed-off-by: Michel Lespinasse
---
mm/memory.c | 98 ++---
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/mm/memory.c b/mm
s
they will all be adjusted together before use, so they just need to be
consistent with each other, and using the original fault address and
pte allows us to reuse pte_map_lock() without any changes to it.
Signed-off-by: Michel Lespinasse
---
mm/filemap.c | 27 ---
1 file
Hi Bibo,
You introduced this code in commit 7df676974359f back in May.
Could you check that the change is correct ?
Thanks,
On Tue, Apr 06, 2021 at 06:44:28PM -0700, Michel Lespinasse wrote:
> update_mmu_tlb() can be used instead of update_mmu_cache() when the
> page fault handler detect
On Wed, Apr 07, 2021 at 03:35:27AM +0100, Matthew Wilcox wrote:
> On Tue, Apr 06, 2021 at 06:44:49PM -0700, Michel Lespinasse wrote:
> > In the speculative case, call the vm_ops->fault() method from within
> > an rcu read locked section, and verify the mmap sequence lock at th
ve come to depend on it (the old "common
law feature" issue).
Just a concern I have, with 0 evidence behind it, so I hope it turns
out not to be an actual issue.
Acked-by: Michel Lespinasse
On Thu, Apr 1, 2021 at 12:51 PM Liam Howlett wrote:
>
> find_vma() will continue to search up
On Thu, Apr 15, 2021 at 01:13:13AM -0600, Yu Zhao wrote:
> Page table scanning doesn't replace the existing rmap walk. It is
> complementary and only happens when it is likely that most of the
> pages on a system under pressure have been referenced, i.e., out of
> *inactive* pages, by definition of
On Tue, Feb 25, 2014 at 10:16 AM, Davidlohr Bueso wrote:
> This patch is a continuation of efforts trying to optimize find_vma(),
> avoiding potentially expensive rbtree walks to locate a vma upon faults.
> The original approach (https://lkml.org/lkml/2013/11/1/410), where the
> largest vma was al
On Tue, Feb 25, 2014 at 8:04 PM, Davidlohr Bueso wrote:
> On Tue, 2014-02-25 at 18:04 -0800, Michel Lespinasse wrote:
>> On Tue, Feb 25, 2014 at 10:16 AM, Davidlohr Bueso wrote:
>> > This patch is a continuation of efforts trying to optimize find_vma(),
>> > avoiding p
On Sun, Nov 3, 2013 at 11:36 PM, Ingo Molnar wrote:
> So I think it all really depends on the hit/miss cost difference. It makes
> little sense to add a more complex scheme if it washes out most of the
> benefits!
>
> Also note the historic context: the _original_ mmap_cache, that I
> implemented
On Tue, Nov 5, 2013 at 4:10 AM, Peter Zijlstra wrote:
> Hi all,
>
> During Kernel Summit Dave mentioned that there wasn't a clear maintainer for
> locking bits.
>
> To remedy this Ingo suggested gathering all the various locking primitives and
> lockdep into a single place: kernel/locking/.
I qui
On Tue, Nov 5, 2013 at 4:10 AM, Peter Zijlstra wrote:
> Index: linux-2.6/kernel/Makefile
> ===
> --- linux-2.6.orig/kernel/Makefile
> +++ linux-2.6/kernel/Makefile
> @@ -7,7 +7,7 @@ obj-y = fork.o exec_domain.o panic.o
>
On Tue, Nov 5, 2013 at 9:42 AM, Tim Chen wrote:
> In this patch series, we separated out the MCS lock code which was
> previously embedded in the mutex.c. This allows for easier reuse of
> MCS lock in other places like rwsem and qrwlock. We also did some micro
> optimizations and barrier cleanup
On Tue, Nov 5, 2013 at 1:20 PM, Peter Zijlstra wrote:
>> This is probably a stupid question, but I haven't been able to find
>> one kernel version that this applies cleanly over ???
>
> Oh my bad, it appears I made it against a working tree, not an actual
> published tree. That said, I don't think
On Wed, Nov 6, 2013 at 1:42 PM, H. Peter Anvin wrote:
> Perhaps I'm missing something here, but what is MCS lock and what is the
> value?
Its a kind of queued lock where each waiter spins on a a separate
memory word, instead of having them all spin on the lock's memory
word. This helps with scala
On Wed, Nov 6, 2013 at 5:39 PM, Linus Torvalds
wrote:
> Sorry about the HTML crap, the internet connection is too slow for my normal
> email habits, so I'm using my phone.
>
> I think the barriers are still totally wrong for the locking functions.
>
> Adding an smp_rmb after waiting for the lock i
On Wed, Nov 6, 2013 at 5:42 PM, Cody P Schafer wrote:
> From: Jan Kara
>
> The iterator rbtree_postorder_for_each_entry_safe() relies on pointer
> underflow behavior when testing for loop termination. In particular
> it expects that
> &rb_entry(NULL, type, field)->field
> is NULL. But the resul
ruct rb_node rb;
>
> /* following fields used for testing augmented rbtree functionality */
> u32 val;
Acked-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list:
the rbtree_postorder_for_each_entry_safe
macro - but as I mentioned in 01/11, I would prefer if we could do
without that API.
Acked-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send t
On Thu, Nov 7, 2013 at 4:06 AM, Linus Torvalds
wrote:
>
> On Nov 7, 2013 6:55 PM, "Michel Lespinasse" wrote:
>>
>> Rather than writing arch-specific locking code, would you agree to
>> introduce acquire and release memory operations ?
>
> Yes, that'
On Thu, Nov 7, 2013 at 6:31 AM, Paul E. McKenney
wrote:
> On Thu, Nov 07, 2013 at 04:50:23AM -0800, Michel Lespinasse wrote:
>> On Thu, Nov 7, 2013 at 4:06 AM, Linus Torvalds
>> wrote:
>> >
>> > On Nov 7, 2013 6:55 PM, "Michel Lespinasse" wrote:
&g
On Tue, Mar 11, 2014 at 1:07 PM, Davidlohr Bueso wrote:
> On Tue, 2014-03-11 at 15:39 -0400, Sasha Levin wrote:
>> I've ended up deleting the log file by mistake, but this bug does seem to be
>> important
>> so I'd rather not wait before the same issue is triggered again.
>>
>> The call chain is
ma;
> + }
> +
> + return NULL;
> +
> +}
> +#endif
I think the caller could do instead
vma = vmacache_find(mm, start)
if (vma && vma->vm_start == start && vma->vm_end == end) {
}
I.e. better deal with it at the call site than add a new vmacache
fu
ple interval-tree library as is.
>
> v2: Lots of help from Michel Lespinasse to only compile the code
> as required:
> - make INTERVAL_TREE a config option
> - make INTERVAL_TREE_TEST select the library functions
> and sanitize the filenames & Makefile
>
On Sun, Jan 26, 2014 at 5:54 AM, Daniel Vetter wrote:
> On Sun, Jan 26, 2014 at 12:24:33PM +, Chris Wilson wrote:
>> INTERVAL_TREE_DEFINE(struct interval_tree_node, rb,
>>unsigned long, __subtree_last,
>>START, LAST,, interval_tree)
>> +
>> +EXPORT_SYMB
On Thu, Nov 7, 2013 at 2:21 PM, Peter Zijlstra wrote:
> On Thu, Nov 07, 2013 at 01:15:51PM -0800, Tim Chen wrote:
>> Michel, are you planning to do an implementation of
>> load-acquire/store-release functions of various architectures?
>
> A little something like this:
> http://marc.info/?l=linux-a
On Sun, Nov 10, 2013 at 8:12 PM, Davidlohr Bueso wrote:
> 2) Oracle Data mining (4K pages)
> ++--+--+-+
> |mmap_cache type | hit-rate | cycles (billion) | stddev |
> ++--+--+-+
On Fri, Nov 1, 2013 at 1:43 AM, Peter Zijlstra wrote:
> AFAICT this isn't correct at all. We used to protect the vma interval
> tree with the root lock, now we don't. All we've got left is the
> mmap_sem, but anon_vma chains can cross address-spaces and thus we're up
> some creek without no paddle
On Fri, Nov 1, 2013 at 11:09 AM, Linus Torvalds
wrote:
> On Fri, Nov 1, 2013 at 10:49 AM, Davidlohr Bueso wrote:
>>
>> Andrea's last input from this kind of conversion is that it cannot be
>> done (at least yet): https://lkml.org/lkml/2013/9/30/53
>
> No, none of the invalidate_page users really
ion.org
>
> Thank you on behalf of the program committee:
>
> Storage:
> James Bottomley
> Martin K. Petersen
>
> Filesystems:
> Trond Myklebust
> Jeff Layton
> Dave Chinner
> Jan Kara
> Ted Ts'o
>
On Tue, Sep 16, 2014 at 7:25 PM, Lai Jiangshan wrote:
> The comment is copied from Documentation/rbtree.txt, but this comment
> is so important that it should also be in the code.
>
> CC: Andrew Morton
> CC: Michel Lespinasse
> Signed-off-by: Lai Jiangshan
Looks good, th
Two small fixes for google firmware drivers.
The patches are against v3.13; I am proposing this for inclusion to v3.14.
Michel Lespinasse (2):
firmware: fix google/gsmi duplicate efivars_sysfs_init()
drivers-firmware: google memconsole driver fixes
drivers/firmware/google/gsmi.c | 7
use ioremap_cache() / iounmap() around such
accesses.
As some unrelated changes, I also converted some printks to use pr_info()
and added some missing __init annotations.
Tested: booted dbg build, verified I could read /sys/firmware/log
Signed-off-by: Michel Lespinasse
---
drivers/firmware
+0xbd/0xe0()
[5.657699] sysfs: cannot create duplicate filename '/firmware/gsmi/vars'
Fixing this by removing the redundant efivars_sysfs_init() call in
gsmi_init().
Tested: booted, checked that /firmware/gsmi/vars was still present and
showed the expected contents.
Signed-off-
Hi,
Way back in 2010, Frederic added commit
ebc8827f75954fe315492883eee5cb3f355d547d to warn us about cases where
faults were incorrectly firing during NMI handling on x86, as the IRET
from such faults would possibly trigger nested NMIs.
Later (2012), Salman added commit
28696f434fef0efa97534b599
On Tue, Oct 22, 2013 at 9:20 AM, Linus Torvalds
wrote:
> On Tue, Oct 22, 2013 at 4:48 PM, wrote:
>> Generally the problems I see with mmap_sem are related to long latency
>> operations. Specifically, the mmap_sem write side is currently held
>> during the entire munmap operation, which iterates
On Tue, Oct 22, 2013 at 10:54 AM, Andy Lutomirski wrote:
> On 10/22/2013 08:48 AM, wal...@google.com wrote:
>> Generally the problems I see with mmap_sem are related to long latency
>> operations. Specifically, the mmap_sem write side is currently held
>> during the entire munmap operation, which
On Sun, Oct 27, 2013 at 12:14 AM, Josh Triplett wrote:
>> > +-f ::
>> > +--fixes=::
>> > + Add Fixes line for the specified commit at the end of the commit
>> > + log message. This line includes an abbreviated commit hash for
>> > + the specified commit; the `core.abbrev` option determines
(resending as text, sorry for previous post which didn't make it to the ML)
On Wed, Jul 29, 2015 at 7:12 AM, Michel Lespinasse wrote:
>
> On Wed, Jul 29, 2015 at 6:59 AM, Vladimir Davydov
> wrote:
> >> I guess the primary reason to rely on the pfn rather than the LRU wa
On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov wrote:
> On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka wrote:
>> Also from reading http://lwn.net/Articles/383162/ I understand that
>> correctness
>> also depends on the hierarchy and I wonder if there's a danger of
>> reintroducing
>>
On Thu, Nov 20, 2014 at 3:42 PM, Konstantin Khlebnikov wrote:
> On Thu, Nov 20, 2014 at 2:14 AM, Michel Lespinasse wrote:
>> On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov
>> wrote:
>>> On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka wrote:
>>>&
xisting
ones. I think this would be workable as well; I'm just not sure
whether this would be more or less generally applicable than your
proposal. Copying Josh in case he wants to chime in.
Reviewed-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debug
rence to this more generic comment.
Acked-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.k
On Sat, Feb 28, 2015 at 1:24 PM, Peter Zijlstra wrote:
> Implement a latched RB-tree in order to get RCU style lookups.
Looks fine to me.
I wanted to ask, you are writing this as a generic layer even though
there is a single use at the moment; do you anticipate this will get
more usage soon ? I
On Tue, Aug 13, 2019 at 03:46:18PM -0700, Davidlohr Bueso wrote:
> o The border cases for overlapping differ -- interval trees are closed,
> while memtype intervals are open. We need to maintain semantics such
> that conflict detection and getting the lowest match does not change.
Agree on the nee
On Tue, Aug 13, 2019 at 05:06:16PM -0700, Davidlohr Bueso wrote:
> On Tue, 02 Jul 2019, Michel Lespinasse wrote:
> > - The majority of interval tree users (though either the
> > interval_tree.h or the interval_tree_generic.h API) do not store any
> > overlapping intervals, an
e, in hugetlb
cases, and in dax code).
On Thu, Aug 22, 2019 at 11:17 AM Davidlohr Bueso wrote:
>
> >On Wed, 21 Aug 2019, Michel Lespinasse wrote:
> >>As I had commented some time ago, I wish the interval trees used [start,end)
> >>intervals instead of [start,last] - it wou
On Wed, Aug 21, 2019 at 9:49 PM Davidlohr Bueso wrote:
> On Wed, 21 Aug 2019, Michel Lespinasse wrote:
> >I'm not sure where to go with this - would it make sense to add a new
> >interval tree header file that uses [start,end) intervals (with the
> >thought of eventua
Hi Davidlohr,
On Wed, Sep 4, 2019 at 5:52 PM Davidlohr Bueso wrote:
> Ok, so for that I've added the following helper which will make the
> conversion a bit more straightforward:
>
> #define vma_interval_tree_foreach_stab(vma, root, start)
>vma_interval_tree_foreach(vma, root, start, star
On Thu, Oct 03, 2019 at 01:18:55PM -0700, Davidlohr Bueso wrote:
> The vma and anon vma interval tree really wants [a, b) intervals,
> not fully closed. As such convert it to use the new
> interval_tree_gen.h. Because of vma_last_pgoff(), the conversion
> is quite straightforward.
I am not certain
On Thu, Apr 30, 2020 at 12:28 AM Juri Lelli wrote:
> > --- a/include/linux/rbtree.h
> > +++ b/include/linux/rbtree.h
> > @@ -141,12 +141,18 @@ static inline void rb_insert_color_cache
> > rb_insert_color(node, &root->rb_root);
> > }
> >
> > -static inline void rb_erase_cached(struct rb_node
code is similar (if you checked and rejected it because of bad code,
please just say so).
Reviewed-by: Michel Lespinasse
I also looked at the other commits in the series, making use of the
helpers, and they seem very reasonable but I did not give them as
thorough a look at this one
On Fri, Jul 26, 2019 at 06:44:19PM -0700, Andrew Morton wrote:
> On Mon, 8 Jul 2019 05:24:09 -0700 Michel Lespinasse wrote:
>
> > Syncing up with v5.2, I see that there is a new use for augmented
> > rbtrees in mm/vmalloc.c which does not compile after applying my
> > pa
On Fri, Jan 11, 2019 at 3:47 PM David Lechner wrote:
>
> On 1/11/19 2:58 PM, Qian Cai wrote:
> > A GPF was reported,
> >
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault: [#1] SMP KASAN
> > kasa
I worry that the proposed change turns the search from an O(log N)
worst case into a O(N) one.
To see why the current search is O(log N), it is easiest to start by
imagining a simplified search algorithm that wouldn't include the low
and high address limits. In that algorithm, backtracking through
le aligned gaps. that is, for each subtree we would
store both the highest 4K aligned size that can be allocated, and the
highest 2M aligned size as well. That makes a more complete solution
but probably overkill as we are not hitting this frequently enough to
justify the complications.
>
n case of using generated callback we can eliminate
> compute_subtree_max_size() function and get rid of duplication.
>
> Signed-off-by: Uladzislau Rezki (Sony)
Reviewed-by: Michel Lespinasse
Love it. Thanks a lot for the cleanup!
On Sun, Aug 11, 2019 at 11:46 AM Uladzislau Rezki (Sony)
wrote:
>
> Recently there was introduced RB_DECLARE_CALLBACKS_MAX template.
> One of the callback, to be more specific *_compute_max(), calculates
> a maximum scalar value of node against its left/right sub-tree.
>
> To simplify the code and
_max function instead of
reimplementing similar functionality in multiple places.
Signed-off-by: Michel Lespinasse
---
lib/rbtree_test.c | 15 +-
mm/mmap.c | 26 +++
mm/vmalloc.c | 53 +++
3 files changed, 12 ins
On Thu, Jul 25, 2019 at 8:19 PM Andrew Morton wrote:
> On Tue, 2 Jul 2019 20:48:12 -0700 Michel Lespinasse
> wrote:
>
> > I should probably have done this in the same commit that changed the
> > main rbtree code to avoid generating code twice for the cached rbtree
>
On Mon, Jul 29, 2019 at 3:15 AM Uladzislau Rezki wrote:
>
> >
> > ---
> > a/lib/rbtree_test.c~augmented-rbtree-add-new-rb_declare_callbacks_max-macro-fix-2
> > +++ a/lib/rbtree_test.c
> > @@ -220,10 +220,6 @@ static void check_augmented(int nr_nodes
> > struct rb_node *rb;
> >
> > che
RBCOMPUTE function definitions.
Signed-off-by: Michel Lespinasse
---
arch/x86/mm/pat_rbtree.c | 19 +++---
drivers/block/drbd/drbd_interval.c | 29 +++--
include/linux/interval_tree_generic.h | 22 ++--
include/linux/rbtree_augmented.h | 36
ble enough to let the inlining decision
up to the compiler.
Michel Lespinasse (3):
augmented rbtree: add comments for RB_DECLARE_CALLBACKS macro
augmented rbtree: add new RB_DECLARE_CALLBACKS_MAX macro
augmented rbtree: rework the RB_DECLARE_CALLBACKS macro definition
arch/x86/mm/pa
Add a short comment summarizing the arguments to RB_DECLARE_CALLBACKS.
The arguments are also now capitalized. This copies the style of the
INTERVAL_TREE_DEFINE macro.
No functional changes in this commit, only comments and capitalization.
Signed-off-by: Michel Lespinasse
---
include/linux
BACKS macro arguments, following the
style of the INTERVAL_TREE_DEFINE macro, so that RBSTATIC and RBNAME
are passed last.
The motivation for this change is that I want to introduce augmented rbtree
uses where the augmented data for the subtree is a struct instead of a scalar.
Signed-off-by: M
On Tue, Jul 2, 2019 at 4:52 AM Peter Zijlstra wrote:
> > - Reorder the RB_DECLARE_CALLBACKS macro arguments, following the
> > style of the INTERVAL_TREE_DEFINE macro, so that RBSTATIC and RBNAME
> > are passed last.
>
> That's, IMO, a weird change. C has storage type and name first, why
> wou
On Tue, Jul 2, 2019 at 9:09 AM Davidlohr Bueso wrote:
>
> On Tue, 02 Jul 2019, Michel Lespinasse wrote:
>
> >diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
> >index fa16036fa592..2afad8e869fc 100644
> >--- a/arch/x86/mm/pat_rbtree.c
> >+++ b/arch
make as much of a difference there :)
Signed-off-by: Michel Lespinasse
---
tools/include/linux/rbtree.h | 71 +-
tools/include/linux/rbtree_augmented.h | 31 +--
tools/lib/rbtree.c | 37 ++
3 files changed, 62 insertions(+
link_rb as noinline. I did not add such a change to the
patchset; I felt it was reasonable enough to let the inlining decision
up to the compiler.
Michel Lespinasse (3):
augmented rbtree: add comments for RB_DECLARE_CALLBACKS macro
augmented rbtree: add new RB_DECLARE_CALLBACKS_MAX macro
augmen
nt to introduce augmented rbtree
uses where the augmented data for the subtree is a struct instead of a scalar.
Signed-off-by: Michel Lespinasse
---
include/linux/rbtree_augmented.h | 24
tools/include/linux/rbtree_augmented.h | 24
2 files ch
RBCOMPUTE function definitions.
Signed-off-by: Michel Lespinasse
---
arch/x86/mm/pat_rbtree.c | 19 +++---
drivers/block/drbd/drbd_interval.c | 29 +++--
include/linux/interval_tree_generic.h | 22 ++--
include/linux/rbtree_augmented.h | 36
Add a short comment summarizing the arguments to RB_DECLARE_CALLBACKS.
The arguments are also now capitalized. This copies the style of the
INTERVAL_TREE_DEFINE macro.
No functional changes in this commit, only comments and capitalization.
Signed-off-by: Michel Lespinasse
Acked-by: Davidlohr
: I0cb62be774fc0138b81188e6ae81d5f1da64578d
Signed-off-by: Michel Lespinasse
---
include/linux/rbtree.h | 70 +---
include/linux/rbtree_augmented.h | 27 +---
lib/rbtree.c | 40 ++
3 files changed, 59 insertions(+), 78 deletions(-)
diff --git a/include
Hi Davidlohr,
On Fri, Jun 28, 2019 at 9:56 AM Davidlohr Bueso wrote:
> I think this makes sense, and is more along the lines of the augmented
> cached doing the static inline instead of separate instantiations of the
> calls.
Thanks for the review.
> >Change-Id: I0cb62be774fc0138b81188e6ae81d5f
oduce augmented rbtree
uses where the augmented data for the subtree is a struct instead of a scalar.
Signed-off-by: Michel Lespinasse
---
arch/x86/mm/pat_rbtree.c | 11 --
drivers/block/drbd/drbd_interval.c | 13 ---
include/linux/interval_tree_generic.h | 13 +--
in
Add a short comment summarizing the arguments to RB_DECLARE_CALLBACKS.
The arguments are also now capitalized. This copies the style of the
INTERVAL_TREE_DEFINE macro.
No functional changes in this commit, only comments and capitalization.
Signed-off-by: Michel Lespinasse
---
include/linux
These changes are intended to make the RB_DECLARE_CALLBACKS macro
more generic (allowing the aubmented subtree information to be a struct
instead of a scalar) and tweak the macro arguments to be more similar
to INTERVAL_TREE_DEFINE().
Michel Lespinasse (2):
augmented rbtree: add comments for
>
> On Mon, Jul 01, 2019 at 09:46:30AM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 28, 2019 at 05:49:52PM -0700, Michel Lespinasse wrote:
>
> > > The motivation for this change is that I want to introduce augmented
> > > rbtree
> > > uses where the aug
modified; it would
probably be feasible to rely on the generated
free_vmap_area_rb_augment_cb_propagate function instead. mm/mmap.c
does something similar in vma_gap_update(), for a very similar use
case.
On Tue, Jul 2, 2019 at 9:02 PM Michel Lespinasse wrote:
>
> Add RB_DECLARE_CALLBA
Hi Peter,
I am getting a minor issue trying to boot a lockdep enabled x86_64
kernel with >64 CPUs.
The kernel boots the first 64 CPUs without issues, but then complains
that lockdep wants to allocate memory while start_secondary ->
init_espfix_ap has IRQs disabled:
[0.310566] x86: Booting SM
nts")
> Signed-off-by: Randy Dunlap
> Cc: Mauro Carvalho Chehab
> Cc: Michel Lespinasse
> Cc: Andrew Morton
Acked-by: Michel Lespinasse
Thanks for the fixes !
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
nly for testing, and it's only reachable by root through
> debugfs, so this doesn't really have any impact; however, if we want to add
> lockdep asserts into the GUP path, we need to have clean locking here.
>
> Signed-off-by: Jann Horn
Acked-by: Michel Lespinasse
Tha
ck before doing
> anything with `vma`, but that's because we actually don't do anything with
> it apart from the NULL check.)
>
> Signed-off-by: Jann Horn
Thanks for these cleanups :)
Acked-by: Michel Lespinasse
ensure that they hold the mmap lock when calling into GUP (unless the mm is
> > not yet globally visible), add an assertion to make sure it stays that way
> > going forward.
Thanks for doing this, there is a lot of value in ensuring that a
function's callers follows the prerequisites.
Acked-by: Michel Lespinasse
On Wed, Sep 30, 2020 at 1:15 PM Jann Horn wrote:
> On Wed, Sep 30, 2020 at 2:50 PM Jann Horn wrote:
> > On Wed, Sep 30, 2020 at 2:30 PM Jason Gunthorpe wrote:
> > > On Tue, Sep 29, 2020 at 06:20:00PM -0700, Jann Horn wrote:
> > > > In preparation for adding a mmap_assert_locked() check in
> > >
On Thu, Oct 1, 2020 at 6:25 PM Jann Horn wrote:
> Until now, the mmap lock of the nascent mm was ordered inside the mmap lock
> of the old mm (in dup_mmap() and in UML's activate_mm()).
> A following patch will change the exec path to very broadly lock the
> nascent mm, but fine-grained locking sh
On Fri, Oct 2, 2020 at 9:33 AM Jann Horn wrote:
> On Fri, Oct 2, 2020 at 11:18 AM Michel Lespinasse wrote:
> > On Thu, Oct 1, 2020 at 6:25 PM Jann Horn wrote:
> > > Until now, the mmap lock of the nascent mm was ordered inside the mmap
> > > lock
> > > of th
his by using
> e.g. u8 (assuming sizeof(bool) is 1, and bool is unsigned; if either of
> these properties don't match, you get EINVAL [2]).
>
> Supporting "bool" explicitly makes hooking this up easier and more
> portable for userspace.
Acked-by: Michel Lespinasse
Lo
On Wed, Oct 7, 2020 at 11:44 AM Axel Rasmussen wrote:
> The goal of these tracepoints is to be able to debug lock contention
> issues. This lock is acquired on most (all?) mmap / munmap / page fault
> operations, so a multi-threaded process which does a lot of these can
> experience significant co
tch has effectively no overhead unless tracepoints are enabled at
> runtime. If tracepoints are enabled, there is a performance impact, but
> how much depends on exactly what e.g. the BPF program does.
>
> Signed-off-by: Axel Rasmussen
Reviewed-by: Michel Lespinasse
Looks good to me, thanks!
On Wed, Jun 3, 2020 at 9:35 PM youling 257 wrote:
> I have build error about kernel/sys.c,
>
> kernel/sys.c: In function ‘prctl_set_vma’:
> kernel/sys.c:2392:18: error:
> ‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean
> ‘mmap_base’?
> 2392 | down_write(&mm->mmap_sem);
>
On Thu, Jun 4, 2020 at 1:16 AM youling 257 wrote:
> 2020-06-04 13:57 GMT+08:00, Michel Lespinasse :
> > However I would like more information about your report. Did you apply
> > the series yourself ? If so, what base tree did you apply it onto ? If
> > not, what tree did
On Fri, May 15, 2020 at 03:59:09PM +, Lai Jiangshan wrote:
> latch_tree_find() should be protected by caller via RCU or so.
> When it find a node in an attempt, the node must be a valid one
> in RCU's point's of view even the tree is (being) updated with a
> new node with the same key which is
On Fri, May 15, 2020 at 9:52 PM Lai Jiangshan
wrote:
>
> On Sat, May 16, 2020 at 12:28 PM Michel Lespinasse wrote:
> >
> > On Fri, May 15, 2020 at 03:59:09PM +, Lai Jiangshan wrote:
> > > latch_tree_find() should be protected by caller via RCU or so.
> > &g
On Wed, Aug 12, 2020 at 7:14 PM Chinwen Chang
wrote:
> Recently, we have observed some janky issues caused by unpleasantly long
> contention on mmap_lock which is held by smaps_rollup when probing large
> processes. To address the problem, we let smaps_rollup detect if anyone
> wants to acquire mm
On Thu, Aug 13, 2020 at 9:11 AM Chinwen Chang
wrote:
> On Thu, 2020-08-13 at 02:53 -0700, Michel Lespinasse wrote:
> > On Wed, Aug 12, 2020 at 7:14 PM Chinwen Chang
> > wrote:
> > > Recently, we have observed some janky issues caused by unpleasantly long
> > >
On Wed, Aug 12, 2020 at 7:14 PM Chinwen Chang
wrote:
>
> Add new API to query if someone wants to acquire mmap_lock
> for write attempts.
>
> Using this instead of rwsem_is_contended makes it more tolerant
> of future changes to the lock type.
>
> Signed-off-by: Chinwen
On Wed, Aug 12, 2020 at 7:13 PM Chinwen Chang
wrote:
> smaps_rollup will try to grab mmap_lock and go through the whole vma
> list until it finishes the iterating. When encountering large processes,
> the mmap_lock will be held for a longer time, which may block other
> write requests like mmap an
Hi,
I am wondering about how to describe the following situation to lockdep:
- lock A would be something that's already implemented (a mutex or
possibly a spinlock).
- lock B is a range lock, which I would be writing the code for
(including lockdep hooks). I do not expect lockdep to know about ra
501 - 600 of 610 matches
Mail list logo
