Hello,
> kern :err : [ 187.461914] F2FS-fs (sda1): Swapfile does not align to
> section
> commit 02eb84b96bc1b382dd138bf60724edbefe77b025
> Author: huangjia...@oppo.com
> Date: Mon Mar 1 12:58:44 2021 +0800
> f2fs: check if swapfile is section-alligned
> If the swapfile isn't cr
Hello Dan,
Dan Williams writes:
>
> I see why this works, but I think the bug is in
> available_slots_show(). It is a bug for a sysfs attribute to reference
> driver-data without synchronizing against bind. So it should be
> possible for probe set that pointer whenever it wants. In other words
>
Hello,
The kmem memcg selftest causes the following lockdep splat on 5.9+
[ 67.534319] =
[ 67.534410] [ BUG: Invalid wait context ]
[ 67.534522] 5.9.1-22-default #125 Not tainted
[ 67.534647] -
[ 67.534732] ksoftirqd/5/36 is trying
ck, for example. It leads to an eventual underflow of the charge
> and triggers a warning.
>
> Fix it by linking all page counters to corresponding root page
> counters in the non-hierarchical mode.
>
> The patch doesn't affect how the hierarchical mode is working,
> which is the only sane and truly supported mode now.
>
> Thanks to Richard for reporting, debugging and providing an
> alternative version of the fix!
>
> Reported-by: l...@lists.linux.it
> Debugged-by: Richard Palethorpe
Much appreciated, thanks!
--
Thank you,
Richard.
d.c:292)
[9.846271] ? __kthread_bind_mask (kernel/kthread.c:245)
[9.846420] ret_from_fork (arch/x86/entry/entry_64.S:300)
[9.846531] ---[ end trace 8b5647c1eba9d18a ]---
Reported-by: l...@lists.linux.it
Signed-off-by: Richard Palethorpe
Acked-by: Roman Gushchin
Cc: Johannes Weiner
Cc: Andrew Morton
Hello,
Michal Koutný writes:
> Hi.
>
> On Tue, Oct 20, 2020 at 06:52:08AM +0100, Richard Palethorpe
> wrote:
>> I don't think that is relevant as we get the memcg from objcg->memcg
>> which is set during reparenting. I suppose however, we can determine i
_ancestor(c, counter)
> page_counter_cancel(c, nr_pages);
> }
>
> @@ -211,7 +214,7 @@ void page_counter_set_min(struct page_counter *counter,
> unsigned long nr_pages)
>
> WRITE_ONCE(counter->min, nr_pages);
>
> - for (c = counter; c; c = c->parent)
> + for_each_nonroot_ancestor(c, counter)
> propagate_protected_usage(c, atomic_long_read(&c->usage));
> }
>
> @@ -228,7 +231,7 @@ void page_counter_set_low(struct page_counter *counter,
> unsigned long nr_pages)
>
> WRITE_ONCE(counter->low, nr_pages);
>
> - for (c = counter; c; c = c->parent)
> + for_each_nonroot_ancestor(c, counter)
> propagate_protected_usage(c, atomic_long_read(&c->usage));
> }
This for sure prevents the counter underflow reported by madvise06 and
makes my patch redundant. Although perhaps this is significantly more
intrusive, so not suitable for the 5.9 stable branch?
Tested-by: Richard Palethorpe
--
Thank you,
Richard.
Hello,
Richard Palethorpe writes:
> Hello Shakeel,
>
> Shakeel Butt writes:
>>>
>>> V3: Handle common case where use_hierarchy=1 and update description.
>>>
>>> mm/memcontrol.c | 7 +--
>>> 1 file changed, 5 insertions(+), 2
Hello,
Richard Palethorpe writes:
> Hello Roman,
>
> Roman Gushchin writes:
>
>> -page_counter_init(&memcg->memory, NULL);
>> -page_counter_init(&memcg->swap, NULL);
>> -page_counter_init(&memcg->kmem, NULL
Hello Roman,
Roman Gushchin writes:
> On Fri, Oct 16, 2020 at 07:15:02PM +0200, Michal Koutny wrote:
>> On Fri, Oct 16, 2020 at 10:53:08AM -0400, Johannes Weiner
>> wrote:
>> > The central try_charge() function charges recursively all the way up
>> > to and including the root.
>> Except for us
Hello Shakeel,
Shakeel Butt writes:
>>
>> V3: Handle common case where use_hierarchy=1 and update description.
>>
>> mm/memcontrol.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 6877c765b8d0..34b8c4a66853 100644
>>
rk (kernel/workqueue.c:2358)
[9.846162] kthread (kernel/kthread.c:292)
[9.846271] ? __kthread_bind_mask (kernel/kthread.c:245)
[9.846420] ret_from_fork (arch/x86/entry/entry_64.S:300)
[9.846531] ---[ end trace 8b5647c1eba9d18a ]---
Reported-by: l...@lists.linux.it
Signed-off-by: Richard Palethorp
Hello,
Michal Koutný writes:
> On Fri, Oct 16, 2020 at 10:53:08AM -0400, Johannes Weiner
> wrote:
>> The central try_charge() function charges recursively all the way up
>> to and including the root.
> Except for use_hiearchy=0 (which is the case here as Richard
> wrote). The reparenting is he
Hello,
Richard Palethorpe writes:
> Hello Michal,
>
> Michal Koutný writes:
>
>> Hello.
>>
>> On Wed, Oct 14, 2020 at 08:07:49PM +0100, Richard Palethorpe
>> wrote:
>>> SLAB objects which outlive their memcg are moved to their parent
>>>
Hello Michal,
Michal Koutný writes:
> Hello.
>
> On Wed, Oct 14, 2020 at 08:07:49PM +0100, Richard Palethorpe
> wrote:
>> SLAB objects which outlive their memcg are moved to their parent
>> memcg where they may be uncharged. However if they are moved to the
>&g
Hello Roman,
Roman Gushchin writes:
> Hi Richard!
>
>> SLAB objects which outlive their memcg are moved to their parent
>> memcg where they may be uncharged. However if they are moved to the
>> root memcg, uncharging will result in negative page counter values as
>> root has no page counters.
>>
read_bind_mask (kernel/kthread.c:245)
[9.846420] ret_from_fork (arch/x86/entry/entry_64.S:300)
[9.846531] ---[ end trace 8b5647c1eba9d18a ]---
Reported-By: l...@lists.linux.it
Signed-off-by: Richard Palethorpe
Cc: Johannes Weiner
Cc: Roman Gushchin
Cc: Andrew Morton
Cc: Shakeel Butt
Cc:
driver and base libnvdimm
device-driver infrastructure")
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Cc: linux-nvd...@lists.01.org
Cc: linux-kernel@vger.kernel.org
Cc: Coly Li
Signed-off-by: Richard Palethorpe
---
V2:
+ Reviewed by Coly and removed unecessary lock
hen setting the driver
data.
Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm
device-driver infrastructure")
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Cc: linux-nvd...@lists.01.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Richard Palethorpe
Hello,
kernel test robot writes:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 12abeb544d548f55f56323fc6e5e6c0fb74f58e1 ("horrible test hack")
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/luto/linux.git
> random/kill-it
>
> in testcase: ltp
> with followin
Hello,
Eric Biggers writes:
> On Fri, Dec 01, 2017 at 10:40:12AM +0800, Fengguang Wu wrote:
>> Hi Eric,
>>
>> We noticed LTP keyctl06 test regression in
>>
>> commit: 3239b6f29bdfb4b0a2ba59df995fc9e6f4df7f1f ("KEYS: return full count
>> in keyring_read() if buffer is too small")
>> https://git
21 matches
Mail list logo
