Displaying 20 results from an estimated 35 matches for "compound_mapcount".
2020 Sep 02
0
[PATCH v2 1/7] mm/thp: fix __split_huge_pmd_locked() for migration PMD
...17,34 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
pte = pte_offset_map(&_pmd, addr);
BUG_ON(!pte_none(*pte));
set_pte_at(mm, addr, pte, entry);
- atomic_inc(&page[i]._mapcount);
- pte_unmap(pte);
- }
-
- /*
- * Set PG_double_map before dropping compound_mapcount to avoid
- * false-negative page_mapped().
- */
- if (compound_mapcount(page) > 1 && !TestSetPageDoubleMap(page)) {
- for (i = 0; i < HPAGE_PMD_NR; i++)
+ if (!pmd_migration)
atomic_inc(&page[i]._mapcount);
+ pte_unmap(pte);
}
- lock_page_memcg(page);
- if (atomic_add...
2020 Sep 02
1
[PATCH v2 1/7] mm/thp: fix __split_huge_pmd_locked() for migration PMD
...struct vm_area_struct *vma, pmd_t *pmd,
> pte = pte_offset_map(&_pmd, addr);
> BUG_ON(!pte_none(*pte));
> set_pte_at(mm, addr, pte, entry);
> - atomic_inc(&page[i]._mapcount);
> - pte_unmap(pte);
> - }
> -
> - /*
> - * Set PG_double_map before dropping compound_mapcount to avoid
> - * false-negative page_mapped().
> - */
> - if (compound_mapcount(page) > 1 && !TestSetPageDoubleMap(page)) {
> - for (i = 0; i < HPAGE_PMD_NR; i++)
> + if (!pmd_migration)
> atomic_inc(&page[i]._mapcount);
> + pte_unmap(pte);
> }
>...
2020 Sep 03
1
[PATCH v3] mm/thp: fix __split_huge_pmd_locked() for migration PMD
...17,34 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
pte = pte_offset_map(&_pmd, addr);
BUG_ON(!pte_none(*pte));
set_pte_at(mm, addr, pte, entry);
- atomic_inc(&page[i]._mapcount);
- pte_unmap(pte);
- }
-
- /*
- * Set PG_double_map before dropping compound_mapcount to avoid
- * false-negative page_mapped().
- */
- if (compound_mapcount(page) > 1 && !TestSetPageDoubleMap(page)) {
- for (i = 0; i < HPAGE_PMD_NR; i++)
+ if (!pmd_migration)
atomic_inc(&page[i]._mapcount);
+ pte_unmap(pte);
}
- lock_page_memcg(page);
- if (atomic_add...
2020 Sep 02
10
[PATCH v2 0/7] mm/hmm/nouveau: add THP migration to migrate_vma_*
This series adds support for transparent huge page migration to
migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers.
An earlier version was posted previously [1]. This version now
supports splitting a THP midway in the migration process which
led to a number of changes.
The patches apply cleanly to the current linux-mm tree. Since there
are a couple of patches in linux-mm from Dan
2018 Aug 05
2
[PATCH net-next 0/6] virtio_net: Add ethtool stat items
...-2048 of size 2048
[ 46.168938] The buggy address is located 128 bytes inside of
2048-byte region [ffff8803400da588, ffff8803400dad88)
[ 46.168942] The buggy address belongs to the page:
[ 46.168947] page:ffffea000d003600 count:1 mapcount:0
mapping:ffff880355011540 index:0x0 compound_mapcount: 0
[ 46.169272] flags: 0x2fffff80008100(slab|head)
[ 46.169358] raw: 002fffff80008100 ffffea000d13a608 ffffea000d43e608
ffff880355011540
[ 46.169364] raw: 0000000000000000 00000000000d000d 00000001ffffffff
0000000000000000
[ 46.169369] page dumped because: kasan: bad access detected
[...
2018 Aug 05
2
[PATCH net-next 0/6] virtio_net: Add ethtool stat items
...-2048 of size 2048
[ 46.168938] The buggy address is located 128 bytes inside of
2048-byte region [ffff8803400da588, ffff8803400dad88)
[ 46.168942] The buggy address belongs to the page:
[ 46.168947] page:ffffea000d003600 count:1 mapcount:0
mapping:ffff880355011540 index:0x0 compound_mapcount: 0
[ 46.169272] flags: 0x2fffff80008100(slab|head)
[ 46.169358] raw: 002fffff80008100 ffffea000d13a608 ffffea000d43e608
ffff880355011540
[ 46.169364] raw: 0000000000000000 00000000000d000d 00000001ffffffff
0000000000000000
[ 46.169369] page dumped because: kasan: bad access detected
[...
2018 Jul 31
1
KASAN: use-after-free Read in vhost_transport_send_pkt
...ich belongs to the cache kmalloc-65536 of size 65536
> The buggy address is located 36076 bytes inside of
> 65536-byte region [ffff880194d05f80, ffff880194d15f80)
> The buggy address belongs to the page:
> page:ffffea0006534000 count:1 mapcount:0 mapping:ffff8801dac02500 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea0006599808 ffff8801dac01e48 ffff8801dac02500
> raw: 0000000000000000 ffff880194d05f80 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy addre...
2018 Jul 13
3
[PATCH 0/2] drm/nouveau: Fix connector memory corruption issues
This fixes some nasty issues I found in nouveau that were being caused
looping through connectors using racy legacy methods, along with some
caused by making incorrect assumptions about the drm_connector structs
in nouveau's connector list. Most of these memory corruption issues
could be reproduced by using an MST hub with nouveau.
Cc: Karol Herbst <karolherbst at gmail.com>
Cc: stable
2018 Jul 05
0
KASAN: stack-out-of-bounds Read in __netif_receive_skb_core
...which belongs to the cache kmalloc-2048 of size 2048
> The buggy address is located 1896 bytes inside of
> 2048-byte region [ffff8801a852ca80, ffff8801a852d280)
> The buggy address belongs to the page:
> page:ffffea0006a14b00 count:1 mapcount:0 mapping:ffff8801da800c40 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea0006c6bd08 ffffea0006c7f688 ffff8801da800c40
> raw: 0000000000000000 ffff8801a852c200 0000000100000003 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy addres...
2018 Jul 13
0
[PATCH 2/2] drm/nouveau: Avoid looping through fake MST connectors
...48
[ 201.039559] The buggy address is located 1192 bytes inside of
2048-byte region [ffff88076738c1a8, ffff88076738c9a8)
[ 201.039563] The buggy address belongs to the page:
[ 201.039567] page:ffffea001d9ce200 count:1 mapcount:0 mapping:ffff88084000d0c0 index:0x0 compound_mapcount: 0
[ 201.039573] flags: 0x8000000000008100(slab|head)
[ 201.039578] raw: 8000000000008100 ffffea001da3be08 ffffea001da25a08 ffff88084000d0c0
[ 201.039582] raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
[ 201.039585] page dumped because: kasan: bad access detected
[ 20...
2018 Aug 05
0
[PATCH net-next 0/6] virtio_net: Add ethtool stat items
...?? 46.168938] The buggy address is located 128 bytes inside of
> ??????????????? 2048-byte region [ffff8803400da588, ffff8803400dad88)
> [?? 46.168942] The buggy address belongs to the page:
> [?? 46.168947] page:ffffea000d003600 count:1 mapcount:0
> mapping:ffff880355011540 index:0x0 compound_mapcount: 0
> [?? 46.169272] flags: 0x2fffff80008100(slab|head)
> [?? 46.169358] raw: 002fffff80008100 ffffea000d13a608 ffffea000d43e608
> ffff880355011540
> [?? 46.169364] raw: 0000000000000000 00000000000d000d 00000001ffffffff
> 0000000000000000
> [?? 46.169369] page dumped because: ka...
2018 Jul 25
2
[PATCH net-next 0/6] virtio_net: Add ethtool stat items
On Mon, Jul 23, 2018 at 11:36:03PM +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp>
>
> Add some ethtool stat items useful for performance analysis.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp>
Series:
Acked-by: Michael S. Tsirkin <mst at redhat.com>
Patch 1 seems appropriate for stable, even
2018 Jul 25
2
[PATCH net-next 0/6] virtio_net: Add ethtool stat items
On Mon, Jul 23, 2018 at 11:36:03PM +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp>
>
> Add some ethtool stat items useful for performance analysis.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp>
Series:
Acked-by: Michael S. Tsirkin <mst at redhat.com>
Patch 1 seems appropriate for stable, even
2018 Aug 03
0
[net-next, v6, 6/7] net-sysfs: Add interface for Rx queue(s) map per Tx queue
...> [ 7.277769] The buggy address is located 3840 bytes inside of
> [ 7.277769] 4096-byte region [ffff8801d4449100, ffff8801d444a100)
> [ 7.277932] The buggy address belongs to the page:
> [ 7.278066] page:ffffea0007511200 count:1 mapcount:0 mapping:ffff8801db002600 index:0x0 compound_mapcount: 0
> [ 7.278230] flags: 0x17fff8000008100(slab|head)
> [ 7.278363] raw: 017fff8000008100 dead000000000100 dead000000000200 ffff8801db002600
> [ 7.278516] raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
> [ 7.278664] page dumped because: kasan: bad ac...
2020 Nov 06
0
[PATCH v3 3/6] mm: support THP migration to device private memory
...it_huge_page(head, &extra_pins)) {
+ if (!remap)
+ extra_pins = thp_nr_pages(page) - 1 +
+ is_device_private_page(head);
+ else if (!can_split_huge_page(head, &extra_pins)) {
ret = -EBUSY;
goto out_unlock;
}
- unmap_page(head);
+ if (remap)
+ unmap_page(head);
VM_BUG_ON_PAGE(compound_mapcount(head), head);
/* prevent PageLRU to go away from under us, and freeze lru stats */
@@ -2717,7 +2756,7 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
if (!mapcount && page_ref_freeze(head, 1 + extra_pins)) {
if (!list_empty(page_deferred_list(head))) {...
2018 Jul 13
2
[PATCH v2 0/2] drm/nouveau: Fix connector memory corruption issues
This fixes some nasty issues I found in nouveau that were being caused
looping through connectors using racy legacy methods, along with some
caused by making incorrect assumptions about the drm_connector structs
in nouveau's connector list. Most of these memory corruption issues
could be reproduced by using an MST hub with nouveau.
Next version of
2017 Jun 05
0
BUG: KASAN: use-after-free in free_old_xmit_skbs
...149] The buggy address is located 32 bytes inside of
> > [ 310.208149] 8192-byte region [ffff88006aa64200, ffff88006aa66200)
> > [ 310.209929] The buggy address belongs to the page:
> > [ 310.210763] page:ffffea0001aa9800 count:1 mapcount:0 mapping: (null)
> > index:0x0 compound_mapcount: 0
> > [ 310.212499] flags: 0x1ffff8000008100(slab|head)
> > [ 310.213373] raw: 01ffff8000008100 0000000000000000 0000000000000000
> > 0000000100030003
> > [ 310.214481] raw: dead000000000100 dead000000000200 ffff88006cc02700
> > 0000000000000000
> > [ 310.21...
2017 Jun 05
0
BUG: KASAN: use-after-free in free_old_xmit_skbs
...149] The buggy address is located 32 bytes inside of
> > [ 310.208149] 8192-byte region [ffff88006aa64200, ffff88006aa66200)
> > [ 310.209929] The buggy address belongs to the page:
> > [ 310.210763] page:ffffea0001aa9800 count:1 mapcount:0 mapping: (null)
> > index:0x0 compound_mapcount: 0
> > [ 310.212499] flags: 0x1ffff8000008100(slab|head)
> > [ 310.213373] raw: 01ffff8000008100 0000000000000000 0000000000000000
> > 0000000100030003
> > [ 310.214481] raw: dead000000000100 dead000000000200 ffff88006cc02700
> > 0000000000000000
> > [ 310.21...
2016 May 27
2
[PATCH v6 02/12] mm: migrate: support non-lru movable page migration
....
> + */
> + if (unlikely(!trylock_page(page)))
> + goto out_putpage;
> +
> + if (!PageMovable(page) || PageIsolated(page))
> + goto out_no_isolated;
> +
> + mapping = page_mapping(page);
Hmm so on first tail page of a THP compound page, page->mapping will alias with
compound_mapcount. That can easily have a value matching PageMovable flags and
we'll proceed and start inspecting the compound head in page_mapping()... maybe
it's not a big deal, or we better check and skip PageTail first, must think
about it more...
[...]
> @@ -755,33 +844,69 @@ static int move_to_...
2016 May 27
2
[PATCH v6 02/12] mm: migrate: support non-lru movable page migration
....
> + */
> + if (unlikely(!trylock_page(page)))
> + goto out_putpage;
> +
> + if (!PageMovable(page) || PageIsolated(page))
> + goto out_no_isolated;
> +
> + mapping = page_mapping(page);
Hmm so on first tail page of a THP compound page, page->mapping will alias with
compound_mapcount. That can easily have a value matching PageMovable flags and
we'll proceed and start inspecting the compound head in page_mapping()... maybe
it's not a big deal, or we better check and skip PageTail first, must think
about it more...
[...]
> @@ -755,33 +844,69 @@ static int move_to_...