* [PATCH 1/2] mm/dmapool: Use might_alloc()
@ 2021-01-13 13:50 Daniel Vetter
2021-01-13 13:50 ` [PATCH 2/2] bdi: " Daniel Vetter
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Vetter @ 2021-01-13 13:50 UTC (permalink / raw)
To: LKML
Cc: Intel Graphics Development, Daniel Vetter, Daniel Vetter,
Andrew Morton, linux-mm
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
--
v2: git add everything ... :-/
---
mm/dmapool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index a97c97232337..f3791532fef2 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -28,6 +28,7 @@
#include <linux/mutex.h>
#include <linux/poison.h>
#include <linux/sched.h>
+#include <linux/sched/mm.h>
#include <linux/slab.h>
#include <linux/stat.h>
#include <linux/spinlock.h>
@@ -319,7 +320,7 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
size_t offset;
void *retval;
- might_sleep_if(gfpflags_allow_blocking(mem_flags));
+ might_alloc(mem_flags);
spin_lock_irqsave(&pool->lock, flags);
list_for_each_entry(page, &pool->page_list, page_list) {
--
2.29.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH 2/2] bdi: Use might_alloc()
2021-01-13 13:50 [PATCH 1/2] mm/dmapool: Use might_alloc() Daniel Vetter
@ 2021-01-13 13:50 ` Daniel Vetter
2021-01-14 5:07 ` kernel test robot
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Vetter @ 2021-01-13 13:50 UTC (permalink / raw)
To: LKML
Cc: Intel Graphics Development, Daniel Vetter, Daniel Vetter,
Andrew Morton, linux-mm
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
--
v2: git add everything ... oops
---
mm/backing-dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index e33797579338..5666a0056580 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -580,7 +580,7 @@ struct bdi_writeback *wb_get_create(struct backing_dev_info *bdi,
{
struct bdi_writeback *wb;
- might_sleep_if(gfpflags_allow_blocking(gfp));
+ might_alloc(gfp);
if (!memcg_css->parent)
return &bdi->wb;
--
2.29.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH 2/2] bdi: Use might_alloc()
2021-01-13 13:50 ` [PATCH 2/2] bdi: " Daniel Vetter
@ 2021-01-14 5:07 ` kernel test robot
0 siblings, 0 replies; 4+ messages in thread
From: kernel test robot @ 2021-01-14 5:07 UTC (permalink / raw)
To: Daniel Vetter, LKML
Cc: kbuild-all, Intel Graphics Development, Daniel Vetter,
Andrew Morton, Linux Memory Management List
[-- Attachment #1: Type: text/plain, Size: 3852 bytes --]
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/mm-dmapool-Use-might_alloc/20210113-215207
base: git://git.cmpxchg.org/linux-mmotm.git master
config: openrisc-randconfig-r011-20210113 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/95ad71591084350229e768f9c2be5350d504f896
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Daniel-Vetter/mm-dmapool-Use-might_alloc/20210113-215207
git checkout 95ad71591084350229e768f9c2be5350d504f896
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=openrisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
mm/backing-dev.c: In function 'wb_get_create':
>> mm/backing-dev.c:647:2: error: implicit declaration of function 'might_alloc'; did you mean 'might_lock'? [-Werror=implicit-function-declaration]
647 | might_alloc(gfp);
| ^~~~~~~~~~~
| might_lock
cc1: some warnings being treated as errors
vim +647 mm/backing-dev.c
616
617 /**
618 * wb_get_create - get wb for a given memcg, create if necessary
619 * @bdi: target bdi
620 * @memcg_css: cgroup_subsys_state of the target memcg (must have positive ref)
621 * @gfp: allocation mask to use
622 *
623 * Try to get the wb for @memcg_css on @bdi. If it doesn't exist, try to
624 * create one. The returned wb has its refcount incremented.
625 *
626 * This function uses css_get() on @memcg_css and thus expects its refcnt
627 * to be positive on invocation. IOW, rcu_read_lock() protection on
628 * @memcg_css isn't enough. try_get it before calling this function.
629 *
630 * A wb is keyed by its associated memcg. As blkcg implicitly enables
631 * memcg on the default hierarchy, memcg association is guaranteed to be
632 * more specific (equal or descendant to the associated blkcg) and thus can
633 * identify both the memcg and blkcg associations.
634 *
635 * Because the blkcg associated with a memcg may change as blkcg is enabled
636 * and disabled closer to root in the hierarchy, each wb keeps track of
637 * both the memcg and blkcg associated with it and verifies the blkcg on
638 * each lookup. On mismatch, the existing wb is discarded and a new one is
639 * created.
640 */
641 struct bdi_writeback *wb_get_create(struct backing_dev_info *bdi,
642 struct cgroup_subsys_state *memcg_css,
643 gfp_t gfp)
644 {
645 struct bdi_writeback *wb;
646
> 647 might_alloc(gfp);
648
649 if (!memcg_css->parent)
650 return &bdi->wb;
651
652 do {
653 rcu_read_lock();
654 wb = radix_tree_lookup(&bdi->cgwb_tree, memcg_css->id);
655 if (wb) {
656 struct cgroup_subsys_state *blkcg_css;
657
658 /* see whether the blkcg association has changed */
659 blkcg_css = cgroup_get_e_css(memcg_css->cgroup,
660 &io_cgrp_subsys);
661 if (unlikely(wb->blkcg_css != blkcg_css ||
662 !wb_tryget(wb)))
663 wb = NULL;
664 css_put(blkcg_css);
665 }
666 rcu_read_unlock();
667 } while (!wb && !cgwb_create(bdi, memcg_css, gfp));
668
669 return wb;
670 }
671
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 19846 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH 1/2] mm/dmapool: Use might_alloc()
@ 2021-01-13 13:40 Daniel Vetter
0 siblings, 0 replies; 4+ messages in thread
From: Daniel Vetter @ 2021-01-13 13:40 UTC (permalink / raw)
To: LKML; +Cc: Daniel Vetter, Daniel Vetter, Andrew Morton, linux-mm
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
---
mm/dmapool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index a97c97232337..d89c6966548d 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -319,7 +319,7 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
size_t offset;
void *retval;
- might_sleep_if(gfpflags_allow_blocking(mem_flags));
+ might_alloc(mem_flags);
spin_lock_irqsave(&pool->lock, flags);
list_for_each_entry(page, &pool->page_list, page_list) {
--
2.29.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-01-14 5:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-13 13:50 [PATCH 1/2] mm/dmapool: Use might_alloc() Daniel Vetter
2021-01-13 13:50 ` [PATCH 2/2] bdi: " Daniel Vetter
2021-01-14 5:07 ` kernel test robot
-- strict thread matches above, loose matches on Subject: below --
2021-01-13 13:40 [PATCH 1/2] mm/dmapool: " Daniel Vetter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).