From: Johannes Berg <[email protected]>
We're obviously not part of a memory reclaim path, so don't set the flag.
This also causes a warning in check_flush_dependency() since we end up
in a code path that flushes a non-reclaim workqueue, and we shouldn't do
that if we were really part of reclaim.
Reported-by: [email protected]
Signed-off-by: Johannes Berg <[email protected]>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 1cf22e62e3dd..6e0af815f25e 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3516,7 +3516,7 @@ static int __init init_mac80211_hwsim(void)
spin_lock_init(&hwsim_radio_lock);
- hwsim_wq = alloc_workqueue("hwsim_wq",WQ_MEM_RECLAIM,0);
+ hwsim_wq = alloc_workqueue("hwsim_wq", 0, 0);
if (!hwsim_wq)
return -ENOMEM;
rhashtable_init(&hwsim_radios_rht, &hwsim_rht_params);
--
2.15.1
On Wed, 2018-01-24 at 10:39 +0100, Benjamin Beichler wrote:
> sorry for introducing that error, but I'm a bit confused by the
> workqueue documentation.
> My assumption was, that deleting hwsim radios is reclaiming memory, and
> since this queue does nothing else it would save/necessary to set this flag.
>
> Maybe a hint in the documentation, that a work item on a WQ_MEM_RECLAIM
> queue must not call flush of an !WQ_MEM_RECLAIM queue would be nice.
> Maybe it's kind of obvious, but there is also a reminder not to forget
> that flag, if a queue may have work items that reclaim memory
Yeah, honestly, I'm not really sure either. Clearly we can't set it,
but other drivers also set it...
I don't think it was *intended* for when you're freeing memory, since I
think reclaiming is what happens when you write out dirty buffers to
disk etc.
johannes
Hi Johannes,
sorry for introducing that error, but I'm a bit confused by the
workqueue documentation.
My assumption was, that deleting hwsim radios is reclaiming memory, and
since this queue does nothing else it would save/necessary to set this flag.
Maybe a hint in the documentation, that a work item on a WQ_MEM_RECLAIM
queue must not call flush of an !WQ_MEM_RECLAIM queue would be nice.
Maybe it's kind of obvious, but there is also a reminder not to forget
that flag, if a queue may have work items that reclaim memory.
Again sorry for not seeing the warning on my test system ...
kind regards
Benjamin
Am 24.01.2018 um 08:40 schrieb Johannes Berg:
> From: Johannes Berg <[email protected]>
>
> We're obviously not part of a memory reclaim path, so don't set the flag.
>
> This also causes a warning in check_flush_dependency() since we end up
> in a code path that flushes a non-reclaim workqueue, and we shouldn't do
> that if we were really part of reclaim.
>
--
M.Sc. Benjamin Beichler
Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE
Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany
phone: +49 (0) 381 498 - 7278
email: [email protected]
www: http://www.imd.uni-rostock.de/