Re: [patch 4/8] mm: memcg: push !mm handling out to page cache charge function
On Wed 12-03-14 10:56:11, Johannes Weiner wrote:
> On Wed, Mar 12, 2014 at 02:11:52PM +0100, Michal Hocko wrote:
> > On Tue 11-03-14 21:28:30, Johannes Weiner wrote:
> > [...]
> > > @@ -4070,6 +4061,12 @@ int mem_cgroup_cache_charge(struct page *page,
> > > struct mm_struct *mm,
> > > return 0;
> > >
> > > if (!PageSwapCache(page)) {
> > > + /*
> > > + * Page cache insertions can happen without an actual
> > > + * task context, e.g. during disk probing on boot.
> >
> > We read a page cache during disk probing? I have tried to find such a
> > code path but failed. Could you point me to such a path, please?
> > I thought that such probing is done from udev context but I am not
> > familiar with this area TBH.
>
> Yes, I tried to remove the !mm case entirely and hit the following
> during boot:
OK, I wonder why I haven't triggered that. Anyway, could you mention
this path in the changelog? This is really hard to find when jumping in
the code.
Anyway thanks!
> [1.869561] BUG: unable to handle kernel NULL pointer dereference at
> 0320
> [1.869565] IP: [] get_mem_cgroup_from_mm+0x32/0x80
> [1.869566] PGD 0
> [1.869567] Oops: [#1] SMP
> [1.869569] CPU: 3 PID: 65 Comm: kworker/u8:6 Not tainted
> 3.14.0-rc6-7-g3856318f53a0-dirty #133
> [1.869569] Hardware name: To Be Filled By O.E.M. To Be Filled By
> O.E.M./H61M-DGS, BIOS P1.30 05/10/2012
> [1.869573] Workqueue: events_unbound async_run_entry_fn
> [1.869573] task: 8800ce82d3c0 ti: 8800ce8c6000 task.ti:
> 8800ce8c6000
> [1.869575] RIP: 0010:[] []
> get_mem_cgroup_from_mm+0x32/0x80
> [1.869576] RSP: :8800ce8c78f8 EFLAGS: 00010246
> [1.869576] RAX: 003fffc1 RBX: RCX:
> 0001
> [1.869577] RDX: 00d0 RSI: RDI:
>
> [1.869577] RBP: 8800ce8c7908 R08: 81713232 R09:
> ea00033a1680
> [1.869578] R10: 1723 R11: c90004e4dfff R12:
>
> [1.869578] R13: 0001 R14: R15:
> 00d0
> [1.869579] FS: () GS:88021f38()
> knlGS:
> [1.869579] CS: 0010 DS: ES: CR0: 80050033
> [1.869580] CR2: 0320 CR3: 017a5000 CR4:
> 000407e0
> [1.869580] Stack:
> [1.869581] ea00033a1640 8800ce8c7948
> 8113a112
> [1.869582] 0001ce8c7978 ea00033a1640
> 000200d0
> [1.869583] 81174520 8800ce8c7970
> 8113be0a
> [1.869583] Call Trace:
> [1.869586] [] mem_cgroup_charge_common+0x42/0xf0
> [1.869589] [] ? blkdev_write_begin+0x30/0x30
> [1.869590] [] mem_cgroup_cache_charge+0x7a/0xb0
> [1.869592] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00
> TB/931 GiB)
> [1.869594] [] add_to_page_cache_locked+0x3d/0x150
> [1.869595] [] add_to_page_cache_lru+0x1a/0x40
> [1.869597] [] do_read_cache_page+0x6f/0x1a0
> [1.869598] [] read_cache_page+0x19/0x30
> [1.869601] [] read_dev_sector+0x2d/0x90
> [1.869603] [] read_lba+0xef/0x1a0
> [1.869604] [] ? find_valid_gpt+0xc3/0x640
> [1.869605] [] find_valid_gpt+0xe1/0x640
> [1.869607] [] ? string.isra.4+0x3b/0xf0
> [1.869609] [] ? find_valid_gpt+0x640/0x640
> [1.869610] [] efi_partition+0x76/0x3f0
> [1.869611] [] ? vsnprintf+0x1f4/0x610
> [1.869612] [] ? snprintf+0x39/0x40
> [1.869613] [] ? find_valid_gpt+0x640/0x640
> [1.869615] [] check_partition+0x108/0x240
> [1.869616] [] rescan_partitions+0xb4/0x2c0
> [1.869617] [] __blkdev_get+0x2dc/0x400
> [1.869618] [] blkdev_get+0x1ad/0x320
> [1.869619] sd 1:0:0:0: [sdb] Write Protect is off
> [1.869621] [] ? unlock_new_inode+0x43/0x70
> [1.869622] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> [1.869622] [] ? bdget+0x136/0x150
> [1.869624] [] add_disk+0x394/0x4a0
> [1.869627] [] sd_probe_async+0x127/0x1d0
> [1.869628] [] async_run_entry_fn+0x37/0x130
> [1.869629] [] process_one_work+0x16e/0x3e0
> [1.869630] [] worker_thread+0x121/0x3a0
> [1.869631] [] ? process_one_work+0x3e0/0x3e0
> [1.869633] [] kthread+0xd2/0xf0
> [1.869634] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
> doesn't support DPO or FUA
> [1.869636] [] ? __kthread_parkme+0x70/0x70
> [1.869638] [] ret_from_fork+0x7c/0xb0
> [1.869639] [] ? __kthread_parkme+0x70/0x70
> [1.869648] Code: 89 e5 41 54 49 89 fc 53 eb 21 0f 1f 80 00 00 00 00 f6 43
> 48 01 75 52 48 8b 43 18 a8 03 75 52 65 ff 00 b8 01 00 00 00 84 c0 75 3e <49>
> 8b 84 24 20 03 00 00 48 85 c0 74 10 48 8b 80 98 06 00 00 48
> [1.869650] RIP [] get_mem_cgroup_from_mm+0x32/0x80
> [1.869650] RSP
> [1.869650] CR2: 0320
> [1.869653]
Re: [patch 4/8] mm: memcg: push !mm handling out to page cache charge function
On Wed, Mar 12, 2014 at 02:11:52PM +0100, Michal Hocko wrote:
> On Tue 11-03-14 21:28:30, Johannes Weiner wrote:
> [...]
> > @@ -4070,6 +4061,12 @@ int mem_cgroup_cache_charge(struct page *page,
> > struct mm_struct *mm,
> > return 0;
> >
> > if (!PageSwapCache(page)) {
> > + /*
> > +* Page cache insertions can happen without an actual
> > +* task context, e.g. during disk probing on boot.
>
> We read a page cache during disk probing? I have tried to find such a
> code path but failed. Could you point me to such a path, please?
> I thought that such probing is done from udev context but I am not
> familiar with this area TBH.
Yes, I tried to remove the !mm case entirely and hit the following
during boot:
[1.869561] BUG: unable to handle kernel NULL pointer dereference at
0320
[1.869565] IP: [] get_mem_cgroup_from_mm+0x32/0x80
[1.869566] PGD 0
[1.869567] Oops: [#1] SMP
[1.869569] CPU: 3 PID: 65 Comm: kworker/u8:6 Not tainted
3.14.0-rc6-7-g3856318f53a0-dirty #133
[1.869569] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./H61M-DGS, BIOS P1.30 05/10/2012
[1.869573] Workqueue: events_unbound async_run_entry_fn
[1.869573] task: 8800ce82d3c0 ti: 8800ce8c6000 task.ti:
8800ce8c6000
[1.869575] RIP: 0010:[] []
get_mem_cgroup_from_mm+0x32/0x80
[1.869576] RSP: :8800ce8c78f8 EFLAGS: 00010246
[1.869576] RAX: 003fffc1 RBX: RCX: 0001
[1.869577] RDX: 00d0 RSI: RDI:
[1.869577] RBP: 8800ce8c7908 R08: 81713232 R09: ea00033a1680
[1.869578] R10: 1723 R11: c90004e4dfff R12:
[1.869578] R13: 0001 R14: R15: 00d0
[1.869579] FS: () GS:88021f38()
knlGS:
[1.869579] CS: 0010 DS: ES: CR0: 80050033
[1.869580] CR2: 0320 CR3: 017a5000 CR4: 000407e0
[1.869580] Stack:
[1.869581] ea00033a1640 8800ce8c7948
8113a112
[1.869582] 0001ce8c7978 ea00033a1640
000200d0
[1.869583] 81174520 8800ce8c7970
8113be0a
[1.869583] Call Trace:
[1.869586] [] mem_cgroup_charge_common+0x42/0xf0
[1.869589] [] ? blkdev_write_begin+0x30/0x30
[1.869590] [] mem_cgroup_cache_charge+0x7a/0xb0
[1.869592] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00
TB/931 GiB)
[1.869594] [] add_to_page_cache_locked+0x3d/0x150
[1.869595] [] add_to_page_cache_lru+0x1a/0x40
[1.869597] [] do_read_cache_page+0x6f/0x1a0
[1.869598] [] read_cache_page+0x19/0x30
[1.869601] [] read_dev_sector+0x2d/0x90
[1.869603] [] read_lba+0xef/0x1a0
[1.869604] [] ? find_valid_gpt+0xc3/0x640
[1.869605] [] find_valid_gpt+0xe1/0x640
[1.869607] [] ? string.isra.4+0x3b/0xf0
[1.869609] [] ? find_valid_gpt+0x640/0x640
[1.869610] [] efi_partition+0x76/0x3f0
[1.869611] [] ? vsnprintf+0x1f4/0x610
[1.869612] [] ? snprintf+0x39/0x40
[1.869613] [] ? find_valid_gpt+0x640/0x640
[1.869615] [] check_partition+0x108/0x240
[1.869616] [] rescan_partitions+0xb4/0x2c0
[1.869617] [] __blkdev_get+0x2dc/0x400
[1.869618] [] blkdev_get+0x1ad/0x320
[1.869619] sd 1:0:0:0: [sdb] Write Protect is off
[1.869621] [] ? unlock_new_inode+0x43/0x70
[1.869622] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[1.869622] [] ? bdget+0x136/0x150
[1.869624] [] add_disk+0x394/0x4a0
[1.869627] [] sd_probe_async+0x127/0x1d0
[1.869628] [] async_run_entry_fn+0x37/0x130
[1.869629] [] process_one_work+0x16e/0x3e0
[1.869630] [] worker_thread+0x121/0x3a0
[1.869631] [] ? process_one_work+0x3e0/0x3e0
[1.869633] [] kthread+0xd2/0xf0
[1.869634] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[1.869636] [] ? __kthread_parkme+0x70/0x70
[1.869638] [] ret_from_fork+0x7c/0xb0
[1.869639] [] ? __kthread_parkme+0x70/0x70
[1.869648] Code: 89 e5 41 54 49 89 fc 53 eb 21 0f 1f 80 00 00 00 00 f6 43
48 01 75 52 48 8b 43 18 a8 03 75 52 65 ff 00 b8 01 00 00 00 84 c0 75 3e <49> 8b
84 24 20 03 00 00 48 85 c0 74 10 48 8b 80 98 06 00 00 48
[1.869650] RIP [] get_mem_cgroup_from_mm+0x32/0x80
[1.869650] RSP
[1.869650] CR2: 0320
[1.869653] ---[ end trace 4cda1f5484a90d6d ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/8] mm: memcg: push !mm handling out to page cache charge function
On Tue 11-03-14 21:28:30, Johannes Weiner wrote:
[...]
> @@ -4070,6 +4061,12 @@ int mem_cgroup_cache_charge(struct page *page, struct
> mm_struct *mm,
> return 0;
>
> if (!PageSwapCache(page)) {
> + /*
> + * Page cache insertions can happen without an actual
> + * task context, e.g. during disk probing on boot.
We read a page cache during disk probing? I have tried to find such a
code path but failed. Could you point me to such a path, please?
I thought that such probing is done from udev context but I am not
familiar with this area TBH.
Thanks!
> + */
> + if (!mm)
> + memcg = root_mem_cgroup;
> ret = __mem_cgroup_try_charge(mm, gfp_mask, 1, , true);
> if (ret != -ENOMEM)
> __mem_cgroup_commit_charge(memcg, page, 1, type, false);
> --
> 1.9.0
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/8] mm: memcg: push !mm handling out to page cache charge function
On Wed, Mar 12, 2014 at 02:11:52PM +0100, Michal Hocko wrote:
On Tue 11-03-14 21:28:30, Johannes Weiner wrote:
[...]
@@ -4070,6 +4061,12 @@ int mem_cgroup_cache_charge(struct page *page,
struct mm_struct *mm,
return 0;
if (!PageSwapCache(page)) {
+ /*
+* Page cache insertions can happen without an actual
+* task context, e.g. during disk probing on boot.
We read a page cache during disk probing? I have tried to find such a
code path but failed. Could you point me to such a path, please?
I thought that such probing is done from udev context but I am not
familiar with this area TBH.
Yes, I tried to remove the !mm case entirely and hit the following
during boot:
[1.869561] BUG: unable to handle kernel NULL pointer dereference at
0320
[1.869565] IP: [811369a2] get_mem_cgroup_from_mm+0x32/0x80
[1.869566] PGD 0
[1.869567] Oops: [#1] SMP
[1.869569] CPU: 3 PID: 65 Comm: kworker/u8:6 Not tainted
3.14.0-rc6-7-g3856318f53a0-dirty #133
[1.869569] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./H61M-DGS, BIOS P1.30 05/10/2012
[1.869573] Workqueue: events_unbound async_run_entry_fn
[1.869573] task: 8800ce82d3c0 ti: 8800ce8c6000 task.ti:
8800ce8c6000
[1.869575] RIP: 0010:[811369a2] [811369a2]
get_mem_cgroup_from_mm+0x32/0x80
[1.869576] RSP: :8800ce8c78f8 EFLAGS: 00010246
[1.869576] RAX: 003fffc1 RBX: RCX: 0001
[1.869577] RDX: 00d0 RSI: RDI:
[1.869577] RBP: 8800ce8c7908 R08: 81713232 R09: ea00033a1680
[1.869578] R10: 1723 R11: c90004e4dfff R12:
[1.869578] R13: 0001 R14: R15: 00d0
[1.869579] FS: () GS:88021f38()
knlGS:
[1.869579] CS: 0010 DS: ES: CR0: 80050033
[1.869580] CR2: 0320 CR3: 017a5000 CR4: 000407e0
[1.869580] Stack:
[1.869581] ea00033a1640 8800ce8c7948
8113a112
[1.869582] 0001ce8c7978 ea00033a1640
000200d0
[1.869583] 81174520 8800ce8c7970
8113be0a
[1.869583] Call Trace:
[1.869586] [8113a112] mem_cgroup_charge_common+0x42/0xf0
[1.869589] [81174520] ? blkdev_write_begin+0x30/0x30
[1.869590] [8113be0a] mem_cgroup_cache_charge+0x7a/0xb0
[1.869592] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00
TB/931 GiB)
[1.869594] [810db06d] add_to_page_cache_locked+0x3d/0x150
[1.869595] [810db19a] add_to_page_cache_lru+0x1a/0x40
[1.869597] [810dbdef] do_read_cache_page+0x6f/0x1a0
[1.869598] [810dce79] read_cache_page+0x19/0x30
[1.869601] [8123952d] read_dev_sector+0x2d/0x90
[1.869603] [8123a21f] read_lba+0xef/0x1a0
[1.869604] [8123a663] ? find_valid_gpt+0xc3/0x640
[1.869605] [8123a681] find_valid_gpt+0xe1/0x640
[1.869607] [81249e6b] ? string.isra.4+0x3b/0xf0
[1.869609] [8123abe0] ? find_valid_gpt+0x640/0x640
[1.869610] [8123ac56] efi_partition+0x76/0x3f0
[1.869611] [8124aec4] ? vsnprintf+0x1f4/0x610
[1.869612] [8124b799] ? snprintf+0x39/0x40
[1.869613] [8123abe0] ? find_valid_gpt+0x640/0x640
[1.869615] [812396c8] check_partition+0x108/0x240
[1.869616] [81239264] rescan_partitions+0xb4/0x2c0
[1.869617] [8117584c] __blkdev_get+0x2dc/0x400
[1.869618] [81175b1d] blkdev_get+0x1ad/0x320
[1.869619] sd 1:0:0:0: [sdb] Write Protect is off
[1.869621] [81157603] ? unlock_new_inode+0x43/0x70
[1.869622] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[1.869622] [81174f66] ? bdget+0x136/0x150
[1.869624] [81236b34] add_disk+0x394/0x4a0
[1.869627] [8135b327] sd_probe_async+0x127/0x1d0
[1.869628] [81065c87] async_run_entry_fn+0x37/0x130
[1.869629] [810595fe] process_one_work+0x16e/0x3e0
[1.869630] [81059991] worker_thread+0x121/0x3a0
[1.869631] [81059870] ? process_one_work+0x3e0/0x3e0
[1.869633] [810602c2] kthread+0xd2/0xf0
[1.869634] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[1.869636] [810601f0] ? __kthread_parkme+0x70/0x70
[1.869638] [815dbaac] ret_from_fork+0x7c/0xb0
[1.869639] [810601f0] ? __kthread_parkme+0x70/0x70
[1.869648] Code: 89 e5 41 54 49 89 fc 53 eb 21 0f 1f 80 00 00 00 00 f6 43
48 01 75 52 48 8b 43 18 a8 03 75 52 65 ff 00 b8 01 00 00 00 84 c0 75 3e 49 8b
84 24 20 03 00 00 48 85 c0 74 10 48 8b 80 98 06 00 00 48
Re: [patch 4/8] mm: memcg: push !mm handling out to page cache charge function
On Wed 12-03-14 10:56:11, Johannes Weiner wrote:
On Wed, Mar 12, 2014 at 02:11:52PM +0100, Michal Hocko wrote:
On Tue 11-03-14 21:28:30, Johannes Weiner wrote:
[...]
@@ -4070,6 +4061,12 @@ int mem_cgroup_cache_charge(struct page *page,
struct mm_struct *mm,
return 0;
if (!PageSwapCache(page)) {
+ /*
+ * Page cache insertions can happen without an actual
+ * task context, e.g. during disk probing on boot.
We read a page cache during disk probing? I have tried to find such a
code path but failed. Could you point me to such a path, please?
I thought that such probing is done from udev context but I am not
familiar with this area TBH.
Yes, I tried to remove the !mm case entirely and hit the following
during boot:
OK, I wonder why I haven't triggered that. Anyway, could you mention
this path in the changelog? This is really hard to find when jumping in
the code.
Anyway thanks!
[1.869561] BUG: unable to handle kernel NULL pointer dereference at
0320
[1.869565] IP: [811369a2] get_mem_cgroup_from_mm+0x32/0x80
[1.869566] PGD 0
[1.869567] Oops: [#1] SMP
[1.869569] CPU: 3 PID: 65 Comm: kworker/u8:6 Not tainted
3.14.0-rc6-7-g3856318f53a0-dirty #133
[1.869569] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./H61M-DGS, BIOS P1.30 05/10/2012
[1.869573] Workqueue: events_unbound async_run_entry_fn
[1.869573] task: 8800ce82d3c0 ti: 8800ce8c6000 task.ti:
8800ce8c6000
[1.869575] RIP: 0010:[811369a2] [811369a2]
get_mem_cgroup_from_mm+0x32/0x80
[1.869576] RSP: :8800ce8c78f8 EFLAGS: 00010246
[1.869576] RAX: 003fffc1 RBX: RCX:
0001
[1.869577] RDX: 00d0 RSI: RDI:
[1.869577] RBP: 8800ce8c7908 R08: 81713232 R09:
ea00033a1680
[1.869578] R10: 1723 R11: c90004e4dfff R12:
[1.869578] R13: 0001 R14: R15:
00d0
[1.869579] FS: () GS:88021f38()
knlGS:
[1.869579] CS: 0010 DS: ES: CR0: 80050033
[1.869580] CR2: 0320 CR3: 017a5000 CR4:
000407e0
[1.869580] Stack:
[1.869581] ea00033a1640 8800ce8c7948
8113a112
[1.869582] 0001ce8c7978 ea00033a1640
000200d0
[1.869583] 81174520 8800ce8c7970
8113be0a
[1.869583] Call Trace:
[1.869586] [8113a112] mem_cgroup_charge_common+0x42/0xf0
[1.869589] [81174520] ? blkdev_write_begin+0x30/0x30
[1.869590] [8113be0a] mem_cgroup_cache_charge+0x7a/0xb0
[1.869592] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00
TB/931 GiB)
[1.869594] [810db06d] add_to_page_cache_locked+0x3d/0x150
[1.869595] [810db19a] add_to_page_cache_lru+0x1a/0x40
[1.869597] [810dbdef] do_read_cache_page+0x6f/0x1a0
[1.869598] [810dce79] read_cache_page+0x19/0x30
[1.869601] [8123952d] read_dev_sector+0x2d/0x90
[1.869603] [8123a21f] read_lba+0xef/0x1a0
[1.869604] [8123a663] ? find_valid_gpt+0xc3/0x640
[1.869605] [8123a681] find_valid_gpt+0xe1/0x640
[1.869607] [81249e6b] ? string.isra.4+0x3b/0xf0
[1.869609] [8123abe0] ? find_valid_gpt+0x640/0x640
[1.869610] [8123ac56] efi_partition+0x76/0x3f0
[1.869611] [8124aec4] ? vsnprintf+0x1f4/0x610
[1.869612] [8124b799] ? snprintf+0x39/0x40
[1.869613] [8123abe0] ? find_valid_gpt+0x640/0x640
[1.869615] [812396c8] check_partition+0x108/0x240
[1.869616] [81239264] rescan_partitions+0xb4/0x2c0
[1.869617] [8117584c] __blkdev_get+0x2dc/0x400
[1.869618] [81175b1d] blkdev_get+0x1ad/0x320
[1.869619] sd 1:0:0:0: [sdb] Write Protect is off
[1.869621] [81157603] ? unlock_new_inode+0x43/0x70
[1.869622] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[1.869622] [81174f66] ? bdget+0x136/0x150
[1.869624] [81236b34] add_disk+0x394/0x4a0
[1.869627] [8135b327] sd_probe_async+0x127/0x1d0
[1.869628] [81065c87] async_run_entry_fn+0x37/0x130
[1.869629] [810595fe] process_one_work+0x16e/0x3e0
[1.869630] [81059991] worker_thread+0x121/0x3a0
[1.869631] [81059870] ? process_one_work+0x3e0/0x3e0
[1.869633] [810602c2] kthread+0xd2/0xf0
[1.869634] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[1.869636] [810601f0] ? __kthread_parkme+0x70/0x70
[1.869638]
Re: [patch 4/8] mm: memcg: push !mm handling out to page cache charge function
On Tue 11-03-14 21:28:30, Johannes Weiner wrote:
[...]
@@ -4070,6 +4061,12 @@ int mem_cgroup_cache_charge(struct page *page, struct
mm_struct *mm,
return 0;
if (!PageSwapCache(page)) {
+ /*
+ * Page cache insertions can happen without an actual
+ * task context, e.g. during disk probing on boot.
We read a page cache during disk probing? I have tried to find such a
code path but failed. Could you point me to such a path, please?
I thought that such probing is done from udev context but I am not
familiar with this area TBH.
Thanks!
+ */
+ if (!mm)
+ memcg = root_mem_cgroup;
ret = __mem_cgroup_try_charge(mm, gfp_mask, 1, memcg, true);
if (ret != -ENOMEM)
__mem_cgroup_commit_charge(memcg, page, 1, type, false);
--
1.9.0
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 4/8] mm: memcg: push !mm handling out to page cache charge function
Only page cache charges can happen without an mm context, so push this
special case out of the inner core and into the cache charge function.
An ancient comment explains that the mm can also be NULL in case the
task is currently being migrated, but that is not actually true with
the current case, so just remove it.
Signed-off-by: Johannes Weiner
---
mm/memcontrol.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cfdb9c385d8d..c40186cf22ad 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2737,15 +2737,6 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
if (gfp_mask & __GFP_NOFAIL)
oom = false;
-
- /*
-* We always charge the cgroup the mm_struct belongs to.
-* The mm_struct's mem_cgroup changes on task migration if the
-* thread group leader migrates. It's possible that mm is not
-* set, if so charge the root memcg (happens for pagecache usage).
-*/
- if (!*ptr && !mm)
- *ptr = root_mem_cgroup;
again:
if (*ptr) { /* css should be a valid one */
memcg = *ptr;
@@ -4070,6 +4061,12 @@ int mem_cgroup_cache_charge(struct page *page, struct
mm_struct *mm,
return 0;
if (!PageSwapCache(page)) {
+ /*
+* Page cache insertions can happen without an actual
+* task context, e.g. during disk probing on boot.
+*/
+ if (!mm)
+ memcg = root_mem_cgroup;
ret = __mem_cgroup_try_charge(mm, gfp_mask, 1, , true);
if (ret != -ENOMEM)
__mem_cgroup_commit_charge(memcg, page, 1, type, false);
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 4/8] mm: memcg: push !mm handling out to page cache charge function
Only page cache charges can happen without an mm context, so push this
special case out of the inner core and into the cache charge function.
An ancient comment explains that the mm can also be NULL in case the
task is currently being migrated, but that is not actually true with
the current case, so just remove it.
Signed-off-by: Johannes Weiner han...@cmpxchg.org
---
mm/memcontrol.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cfdb9c385d8d..c40186cf22ad 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2737,15 +2737,6 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
if (gfp_mask __GFP_NOFAIL)
oom = false;
-
- /*
-* We always charge the cgroup the mm_struct belongs to.
-* The mm_struct's mem_cgroup changes on task migration if the
-* thread group leader migrates. It's possible that mm is not
-* set, if so charge the root memcg (happens for pagecache usage).
-*/
- if (!*ptr !mm)
- *ptr = root_mem_cgroup;
again:
if (*ptr) { /* css should be a valid one */
memcg = *ptr;
@@ -4070,6 +4061,12 @@ int mem_cgroup_cache_charge(struct page *page, struct
mm_struct *mm,
return 0;
if (!PageSwapCache(page)) {
+ /*
+* Page cache insertions can happen without an actual
+* task context, e.g. during disk probing on boot.
+*/
+ if (!mm)
+ memcg = root_mem_cgroup;
ret = __mem_cgroup_try_charge(mm, gfp_mask, 1, memcg, true);
if (ret != -ENOMEM)
__mem_cgroup_commit_charge(memcg, page, 1, type, false);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
