* [PATCH 1/5] maple_tree: Allow external locks to be configured with their map
2024-08-22 19:13 [PATCH 0/5] regmap: Improve lock handling with maple tree Mark Brown
@ 2024-08-22 19:13 ` Mark Brown
2024-08-22 19:21 ` Matthew Wilcox
2024-08-22 19:13 ` [PATCH 2/5] regmap: Hold the regmap lock when allocating and freeing the cache Mark Brown
` (4 subsequent siblings)
5 siblings, 1 reply; 13+ messages in thread
From: Mark Brown @ 2024-08-22 19:13 UTC (permalink / raw)
To: Liam R. Howlett
Cc: Cristian Ciocaltea, maple-tree, linux-mm, linux-kernel,
Mark Brown
Currently the maple tree code allows external locks to be configured by
passing the lock itself. This is generally helpful and convenient but is
not ideal for situations like the regmap maple tree cache where we support
configurable locking at the regmap level and don't have the lock type when
we are configuring the maple tree. Add a helper that allows us to pass the
dep map directly to help with these situations. Since such code is already
peering at the lockdep internals enough to be looking at the map no stub
is provided.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
include/linux/maple_tree.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/maple_tree.h b/include/linux/maple_tree.h
index a53ad4dabd7e..bdc6b133abdc 100644
--- a/include/linux/maple_tree.h
+++ b/include/linux/maple_tree.h
@@ -193,6 +193,9 @@ typedef struct lockdep_map *lockdep_map_p;
#define mt_set_external_lock(mt, lock) \
(mt)->ma_external_lock = &(lock)->dep_map
+#define mt_set_external_lock_dep_map(mt, dep_map) \
+ (mt)->ma_external_lock = dep_map
+
#define mt_on_stack(mt) (mt).ma_external_lock = NULL
#else
typedef struct { /* nothing */ } lockdep_map_p;
--
2.39.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 1/5] maple_tree: Allow external locks to be configured with their map
2024-08-22 19:13 ` [PATCH 1/5] maple_tree: Allow external locks to be configured with their map Mark Brown
@ 2024-08-22 19:21 ` Matthew Wilcox
2024-08-22 19:48 ` Mark Brown
0 siblings, 1 reply; 13+ messages in thread
From: Matthew Wilcox @ 2024-08-22 19:21 UTC (permalink / raw)
To: Mark Brown
Cc: Liam R. Howlett, Cristian Ciocaltea, maple-tree, linux-mm,
linux-kernel
On Thu, Aug 22, 2024 at 08:13:35PM +0100, Mark Brown wrote:
> Currently the maple tree code allows external locks to be configured by
> passing the lock itself. This is generally helpful and convenient but is
No, it's a really bad idea. Stop doing it. Use the internal lock.
It's a temporary hack we put in and I'm really regretting allowing it.
> not ideal for situations like the regmap maple tree cache where we support
> configurable locking at the regmap level and don't have the lock type when
> we are configuring the maple tree. Add a helper that allows us to pass the
> dep map directly to help with these situations. Since such code is already
> peering at the lockdep internals enough to be looking at the map no stub
> is provided.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> include/linux/maple_tree.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/maple_tree.h b/include/linux/maple_tree.h
> index a53ad4dabd7e..bdc6b133abdc 100644
> --- a/include/linux/maple_tree.h
> +++ b/include/linux/maple_tree.h
> @@ -193,6 +193,9 @@ typedef struct lockdep_map *lockdep_map_p;
> #define mt_set_external_lock(mt, lock) \
> (mt)->ma_external_lock = &(lock)->dep_map
>
> +#define mt_set_external_lock_dep_map(mt, dep_map) \
> + (mt)->ma_external_lock = dep_map
> +
> #define mt_on_stack(mt) (mt).ma_external_lock = NULL
> #else
> typedef struct { /* nothing */ } lockdep_map_p;
>
> --
> 2.39.2
>
>
> --
> maple-tree mailing list
> maple-tree@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/maple-tree
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 1/5] maple_tree: Allow external locks to be configured with their map
2024-08-22 19:21 ` Matthew Wilcox
@ 2024-08-22 19:48 ` Mark Brown
2024-08-22 19:55 ` Matthew Wilcox
0 siblings, 1 reply; 13+ messages in thread
From: Mark Brown @ 2024-08-22 19:48 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Liam R. Howlett, Cristian Ciocaltea, maple-tree, linux-mm,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
On Thu, Aug 22, 2024 at 08:21:40PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 22, 2024 at 08:13:35PM +0100, Mark Brown wrote:
> > Currently the maple tree code allows external locks to be configured by
> > passing the lock itself. This is generally helpful and convenient but is
> No, it's a really bad idea. Stop doing it. Use the internal lock.
> It's a temporary hack we put in and I'm really regretting allowing it.
I mean, we do use the internal lock here since otherwise lockdep moans
but it's pure overhead which just complicates the code. It's only ever
taken within another lock, meaning it winds up protecting nothing for
these maple trees. We can't go the other way round and use the maple
tree lock as the regmap lock since apart from anything else it's a spin
lock and we need to use a mutex most of the time to support busses that
sleep during I/O.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/5] maple_tree: Allow external locks to be configured with their map
2024-08-22 19:48 ` Mark Brown
@ 2024-08-22 19:55 ` Matthew Wilcox
2024-08-22 20:45 ` Mark Brown
0 siblings, 1 reply; 13+ messages in thread
From: Matthew Wilcox @ 2024-08-22 19:55 UTC (permalink / raw)
To: Mark Brown
Cc: Liam R. Howlett, Cristian Ciocaltea, maple-tree, linux-mm,
linux-kernel
On Thu, Aug 22, 2024 at 08:48:56PM +0100, Mark Brown wrote:
> On Thu, Aug 22, 2024 at 08:21:40PM +0100, Matthew Wilcox wrote:
> > On Thu, Aug 22, 2024 at 08:13:35PM +0100, Mark Brown wrote:
>
> > > Currently the maple tree code allows external locks to be configured by
> > > passing the lock itself. This is generally helpful and convenient but is
>
> > No, it's a really bad idea. Stop doing it. Use the internal lock.
> > It's a temporary hack we put in and I'm really regretting allowing it.
>
> I mean, we do use the internal lock here since otherwise lockdep moans
> but it's pure overhead which just complicates the code. It's only ever
> taken within another lock, meaning it winds up protecting nothing for
> these maple trees. We can't go the other way round and use the maple
> tree lock as the regmap lock since apart from anything else it's a spin
> lock and we need to use a mutex most of the time to support busses that
> sleep during I/O.
When it's an uncontended spinlock, there's really no overhead. I wish I'd
been firmer on that point earlier and prohibited the external lock hack.
The point is that the lock protects the tree. If we are ever going to
be able to defragment slabs (and I believe this is an ability that Linux
must gain), we must be able to go from the object (the maple node) to
a lock that will let us reallocate the node. If there's some external
lock that protects the tree, we can't possibly do that.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/5] maple_tree: Allow external locks to be configured with their map
2024-08-22 19:55 ` Matthew Wilcox
@ 2024-08-22 20:45 ` Mark Brown
0 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2024-08-22 20:45 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Liam R. Howlett, Cristian Ciocaltea, maple-tree, linux-mm,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
On Thu, Aug 22, 2024 at 08:55:20PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 22, 2024 at 08:48:56PM +0100, Mark Brown wrote:
> > I mean, we do use the internal lock here since otherwise lockdep moans
> > but it's pure overhead which just complicates the code. It's only ever
> When it's an uncontended spinlock, there's really no overhead. I wish I'd
> been firmer on that point earlier and prohibited the external lock hack.
> The point is that the lock protects the tree. If we are ever going to
> be able to defragment slabs (and I believe this is an ability that Linux
> must gain), we must be able to go from the object (the maple node) to
> a lock that will let us reallocate the node. If there's some external
> lock that protects the tree, we can't possibly do that.
If the external lock guarantees that nothing can possibly be contending
access to the tree (including the read side) I don't see any issue
there?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 2/5] regmap: Hold the regmap lock when allocating and freeing the cache
2024-08-22 19:13 [PATCH 0/5] regmap: Improve lock handling with maple tree Mark Brown
2024-08-22 19:13 ` [PATCH 1/5] maple_tree: Allow external locks to be configured with their map Mark Brown
@ 2024-08-22 19:13 ` Mark Brown
[not found] ` <CGME20240828100239eucas1p2afc0d3088c66468061baf81c5676882a@eucas1p2.samsung.com>
2024-08-22 19:13 ` [PATCH 3/5] regmap: Use locking during kunit tests Mark Brown
` (3 subsequent siblings)
5 siblings, 1 reply; 13+ messages in thread
From: Mark Brown @ 2024-08-22 19:13 UTC (permalink / raw)
To: Liam R. Howlett
Cc: Cristian Ciocaltea, maple-tree, linux-mm, linux-kernel,
Mark Brown
For the benefit of the maple tree's lockdep checking hold the lock while
creating and exiting the cache.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/regcache.c | 4 ++++
drivers/base/regmap/regmap.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index 7ec1ec605335..d3659ba3cc11 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -195,7 +195,9 @@ int regcache_init(struct regmap *map, const struct regmap_config *config)
if (map->cache_ops->init) {
dev_dbg(map->dev, "Initializing %s cache\n",
map->cache_ops->name);
+ map->lock(map->lock_arg);
ret = map->cache_ops->init(map);
+ map->unlock(map->lock_arg);
if (ret)
goto err_free;
}
@@ -223,7 +225,9 @@ void regcache_exit(struct regmap *map)
if (map->cache_ops->exit) {
dev_dbg(map->dev, "Destroying %s cache\n",
map->cache_ops->name);
+ map->lock(map->lock_arg);
map->cache_ops->exit(map);
+ map->unlock(map->lock_arg);
}
}
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index bfc6bc1eb3a4..9ed842d17642 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1445,6 +1445,7 @@ void regmap_exit(struct regmap *map)
struct regmap_async *async;
regcache_exit(map);
+
regmap_debugfs_exit(map);
regmap_range_exit(map);
if (map->bus && map->bus->free_context)
--
2.39.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 3/5] regmap: Use locking during kunit tests
2024-08-22 19:13 [PATCH 0/5] regmap: Improve lock handling with maple tree Mark Brown
2024-08-22 19:13 ` [PATCH 1/5] maple_tree: Allow external locks to be configured with their map Mark Brown
2024-08-22 19:13 ` [PATCH 2/5] regmap: Hold the regmap lock when allocating and freeing the cache Mark Brown
@ 2024-08-22 19:13 ` Mark Brown
2024-08-22 19:13 ` [PATCH 4/5] regmap: Wrap maple tree locking Mark Brown
` (2 subsequent siblings)
5 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2024-08-22 19:13 UTC (permalink / raw)
To: Liam R. Howlett
Cc: Cristian Ciocaltea, maple-tree, linux-mm, linux-kernel,
Mark Brown
There is no reason to bypass the locking when running the kunit tests,
leave it enabled as standard.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/regmap-kunit.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/base/regmap/regmap-kunit.c b/drivers/base/regmap/regmap-kunit.c
index d790c7df5cac..b80b447c87a2 100644
--- a/drivers/base/regmap/regmap-kunit.c
+++ b/drivers/base/regmap/regmap-kunit.c
@@ -151,8 +151,6 @@ static struct regmap *gen_regmap(struct kunit *test,
struct reg_default *defaults;
config->cache_type = param->cache;
- config->disable_locking = config->cache_type == REGCACHE_RBTREE ||
- config->cache_type == REGCACHE_MAPLE;
if (config->max_register == 0) {
config->max_register = param->from_reg;
--
2.39.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 4/5] regmap: Wrap maple tree locking
2024-08-22 19:13 [PATCH 0/5] regmap: Improve lock handling with maple tree Mark Brown
` (2 preceding siblings ...)
2024-08-22 19:13 ` [PATCH 3/5] regmap: Use locking during kunit tests Mark Brown
@ 2024-08-22 19:13 ` Mark Brown
2024-08-22 19:13 ` [PATCH 5/5] regmap: Don't double lock maple cache when using a regmap provided lock Mark Brown
2024-08-23 22:57 ` (subset) [PATCH 0/5] regmap: Improve lock handling with maple tree Mark Brown
5 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2024-08-22 19:13 UTC (permalink / raw)
To: Liam R. Howlett
Cc: Cristian Ciocaltea, maple-tree, linux-mm, linux-kernel,
Mark Brown
In preparation for using the regmap lock when available with the maple
tree lock wrap all the maple tree locking with some local functions and
only do the maple tree locking if the maple tree has it's own lock.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/regcache-maple.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/base/regmap/regcache-maple.c b/drivers/base/regmap/regcache-maple.c
index 2dea9d259c49..d2de3eba1646 100644
--- a/drivers/base/regmap/regcache-maple.c
+++ b/drivers/base/regmap/regcache-maple.c
@@ -13,6 +13,18 @@
#include "internal.h"
+static inline void regmap_mas_lock(struct ma_state *mas)
+{
+ if (!mt_external_lock(mas->tree))
+ mas_lock(mas);
+}
+
+static inline void regmap_mas_unlock(struct ma_state *mas)
+{
+ if (!mt_external_lock(mas->tree))
+ mas_unlock(mas);
+}
+
static int regcache_maple_read(struct regmap *map,
unsigned int reg, unsigned int *value)
{
@@ -89,12 +101,12 @@ static int regcache_maple_write(struct regmap *map, unsigned int reg,
* is redundant, but we need to take it due to lockdep asserts
* in the maple tree code.
*/
- mas_lock(&mas);
+ regmap_mas_lock(&mas);
mas_set_range(&mas, index, last);
ret = mas_store_gfp(&mas, entry, map->alloc_flags);
- mas_unlock(&mas);
+ regmap_mas_unlock(&mas);
if (ret == 0) {
kfree(lower);
@@ -118,7 +130,7 @@ static int regcache_maple_drop(struct regmap *map, unsigned int min,
lower = NULL;
upper = NULL;
- mas_lock(&mas);
+ regmap_mas_lock(&mas);
mas_for_each(&mas, entry, max) {
/*
@@ -126,7 +138,7 @@ static int regcache_maple_drop(struct regmap *map, unsigned int min,
* Maple lock is redundant, but we need to take it due
* to lockdep asserts in the maple tree code.
*/
- mas_unlock(&mas);
+ regmap_mas_unlock(&mas);
/* Do we need to save any of this entry? */
if (mas.index < min) {
@@ -156,7 +168,7 @@ static int regcache_maple_drop(struct regmap *map, unsigned int min,
}
kfree(entry);
- mas_lock(&mas);
+ regmap_mas_lock(&mas);
mas_erase(&mas);
/* Insert new nodes with the saved data */
@@ -178,7 +190,7 @@ static int regcache_maple_drop(struct regmap *map, unsigned int min,
}
out:
- mas_unlock(&mas);
+ regmap_mas_unlock(&mas);
out_unlocked:
kfree(lower);
kfree(upper);
@@ -300,11 +312,11 @@ static int regcache_maple_exit(struct regmap *map)
if (!mt)
return 0;
- mas_lock(&mas);
+ regmap_mas_lock(&mas);
mas_for_each(&mas, entry, UINT_MAX)
kfree(entry);
__mt_destroy(mt);
- mas_unlock(&mas);
+ regmap_mas_unlock(&mas);
kfree(mt);
map->cache = NULL;
@@ -327,13 +339,13 @@ static int regcache_maple_insert_block(struct regmap *map, int first,
for (i = 0; i < last - first + 1; i++)
entry[i] = map->reg_defaults[first + i].def;
- mas_lock(&mas);
+ regmap_mas_lock(&mas);
mas_set_range(&mas, map->reg_defaults[first].reg,
map->reg_defaults[last].reg);
ret = mas_store_gfp(&mas, entry, map->alloc_flags);
- mas_unlock(&mas);
+ regmap_mas_unlock(&mas);
if (ret)
kfree(entry);
--
2.39.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 5/5] regmap: Don't double lock maple cache when using a regmap provided lock
2024-08-22 19:13 [PATCH 0/5] regmap: Improve lock handling with maple tree Mark Brown
` (3 preceding siblings ...)
2024-08-22 19:13 ` [PATCH 4/5] regmap: Wrap maple tree locking Mark Brown
@ 2024-08-22 19:13 ` Mark Brown
2024-08-23 22:57 ` (subset) [PATCH 0/5] regmap: Improve lock handling with maple tree Mark Brown
5 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2024-08-22 19:13 UTC (permalink / raw)
To: Liam R. Howlett
Cc: Cristian Ciocaltea, maple-tree, linux-mm, linux-kernel,
Mark Brown
It is not possible to use the maple tree without holding a lock of some
kind, by default the maple tree incorporates a lock but it does have
support for registering an external lock which will be asserted against
instead. At present regmap uses the maple tree's internal lock which is
unfortunate since there is also regmap level locking above the cache which
protects the cache data structure and things like read/modify/write
operations.
Let's reduce the overhead here by telling the maple tree about the regmap
level lock for cases where regmap does it's own locking. We also support
external and custom locking for regmap, neither of which will benefit from
this, but this will cover the vast majority of users.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/internal.h | 12 ++++++++++++
drivers/base/regmap/regcache-maple.c | 9 +++++++++
drivers/base/regmap/regmap.c | 4 ++++
3 files changed, 25 insertions(+)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 83acccdc1008..a5fe052a70ce 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -59,6 +59,9 @@ struct regmap {
unsigned long raw_spinlock_flags;
};
};
+#ifdef CONFIG_LOCKDEP
+ struct lockdep_map *lockdep;
+#endif
regmap_lock lock;
regmap_unlock unlock;
void *lock_arg; /* This is passed to lock/unlock functions */
@@ -344,4 +347,13 @@ struct regmap *__regmap_init_raw_ram(struct device *dev,
#define regmap_init_raw_ram(dev, config, data) \
__regmap_lockdep_wrapper(__regmap_init_raw_ram, #dev, dev, config, data)
+#ifdef CONFIG_LOCKDEP
+static inline void regmap_set_lockdep(struct regmap *m, struct lockdep_map *l)
+{
+ m->lockdep = l;
+}
+#else
+#define regmap_set_lockdep(m, l)
+#endif
+
#endif
diff --git a/drivers/base/regmap/regcache-maple.c b/drivers/base/regmap/regcache-maple.c
index d2de3eba1646..1247ff3ae397 100644
--- a/drivers/base/regmap/regcache-maple.c
+++ b/drivers/base/regmap/regcache-maple.c
@@ -365,7 +365,16 @@ static int regcache_maple_init(struct regmap *map)
return -ENOMEM;
map->cache = mt;
+#ifdef CONFIG_LOCKDEP
+ if (map->lockdep) {
+ mt_init_flags(mt, MT_FLAGS_LOCK_EXTERN);
+ mt_set_external_lock_dep_map(mt, map->lockdep);
+ } else {
+ mt_init(mt);
+ }
+#else
mt_init(mt);
+#endif
if (!map->num_reg_defaults)
return 0;
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 9ed842d17642..f66b5ef56cf8 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -729,12 +729,15 @@ struct regmap *__regmap_init(struct device *dev,
map->unlock = regmap_unlock_raw_spinlock;
lockdep_set_class_and_name(&map->raw_spinlock,
lock_key, lock_name);
+ regmap_set_lockdep(map,
+ &map->raw_spinlock.dep_map);
} else {
spin_lock_init(&map->spinlock);
map->lock = regmap_lock_spinlock;
map->unlock = regmap_unlock_spinlock;
lockdep_set_class_and_name(&map->spinlock,
lock_key, lock_name);
+ regmap_set_lockdep(map, &map->spinlock.dep_map);
}
} else {
mutex_init(&map->mutex);
@@ -743,6 +746,7 @@ struct regmap *__regmap_init(struct device *dev,
map->can_sleep = true;
lockdep_set_class_and_name(&map->mutex,
lock_key, lock_name);
+ regmap_set_lockdep(map, &map->mutex.dep_map);
}
map->lock_arg = map;
}
--
2.39.2
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: (subset) [PATCH 0/5] regmap: Improve lock handling with maple tree
2024-08-22 19:13 [PATCH 0/5] regmap: Improve lock handling with maple tree Mark Brown
` (4 preceding siblings ...)
2024-08-22 19:13 ` [PATCH 5/5] regmap: Don't double lock maple cache when using a regmap provided lock Mark Brown
@ 2024-08-23 22:57 ` Mark Brown
5 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2024-08-23 22:57 UTC (permalink / raw)
To: Liam R. Howlett, Mark Brown
Cc: Cristian Ciocaltea, maple-tree, linux-mm, linux-kernel
On Thu, 22 Aug 2024 20:13:34 +0100, Mark Brown wrote:
> The lockdep asserts in the maple tree code and the double locking that
> we're doing continue to cause issues, most recently some warnings
> reported by Cristian Ciocaltea due to dynamic cache allocations in
> interrupt context (which are an issue in themselves, but still). Let's
> start trying to improve the situation by configuring the regmap lock as
> an external lock for maple tree, allowing it to do it's asserts without
> having a separate lock.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[2/5] regmap: Hold the regmap lock when allocating and freeing the cache
commit: fd4ebc07b4dff7e1abedf1b7fd477bc04b69ae55
[3/5] regmap: Use locking during kunit tests
commit: 290d6e5d6498703accffc66849b7fb2d4d7503ff
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply [flat|nested] 13+ messages in thread