search for: kmmio_fault_pages

Because Linux might use bigger pages than the 4K pages to handle those mmio ioremaps, the kmmio code shouldn't rely on the pade id as it currently does. Using the memory address instead of the page id let's us lookup how big the page is and what it's base address is, so that we won't get a page fault within the same page twice anymore. I don't know if I got this right though,

After every iounmap mmiotrace has to free kmmio_fault_pages, but it can't do it directly, so it defers freeing by RCU. It usually works, but when mmiotraced code calls ioremap-iounmap multiple times without sleeping between (so RCU won't kick in and start freeing) it can be given the same virtual address, so at every iounmap mmiotrace will schedule...

After every iounmap mmiotrace has to free kmmio_fault_pages, but it can't do it directly, so it defers freeing by RCU. It usually works, but when mmiotraced code calls ioremap-iounmap multiple times without sleeping between (so RCU won't kick in and start freeing) it can be given the same virtual address, so at every iounmap mmiotrace will schedule...

From: Karol Herbst <nouveau at karolherbst.de> This patch has been added to the 4.1 stable tree. If you have any objections, please let us know. =============== [ Upstream commit cfa52c0cfa4d727aa3e457bf29aeff296c528a08 ] Because Linux might use bigger pages than the 4K pages to handle those mmio ioremaps, the kmmio code shouldn't rely on the pade id as it currently does. Using the

From: Karol Herbst <nouveau at karolherbst.de> This patch has been added to the 3.18 stable tree. If you have any objections, please let us know. =============== [ Upstream commit cfa52c0cfa4d727aa3e457bf29aeff296c528a08 ] Because Linux might use bigger pages than the 4K pages to handle those mmio ioremaps, the kmmio code shouldn't rely on the pade id as it currently does. Using the

Hi, I think I got mmiotracing back to work on my machine. Would you please test this patch on your machines too? I still got some UNKNOWN entries in the mmiotrace file, but besides that it seems to work. I have no idea if that's the right way though, and it needs a big cleanup, but I just wanted to see if the basic idea works the patch should apply just fine on any 4.4 kernel happy

4.5-stable review patch. If anyone has any objections, please let me know. ------------------ From: Karol Herbst <nouveau at karolherbst.de> commit cfa52c0cfa4d727aa3e457bf29aeff296c528a08 upstream. Because Linux might use bigger pages than the 4K pages to handle those mmio ioremaps, the kmmio code shouldn't rely on the pade id as it currently does. Using the memory address instead

4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Karol Herbst <nouveau at karolherbst.de> commit cfa52c0cfa4d727aa3e457bf29aeff296c528a08 upstream. Because Linux might use bigger pages than the 4K pages to handle those mmio ioremaps, the kmmio code shouldn't rely on the pade id as it currently does. Using the memory address instead

...in ioremapping code Jiri Slaby (1): x86-64, mm: Initialize VDSO earlier on 64 bits Kenji Kaneshige (2): x86, ioremap: Fix incorrect physical address handling in PAE mode x86, ioremap: Fix normal ram range check Marcin Slusarz (1): x86, kmmio/mmiotrace: Fix double free of kmmio_fault_pages Yasuaki Ishimatsu (1): x86: Ioremap: fix wrong physical address handling in PAT code arch/x86/mm/dump_pagetables.c | 32 ++++++++++++++++++++++++++------ arch/x86/mm/ioremap.c | 14 ++++++-------- arch/x86/mm/kmmio.c | 16 +++++++++++++--- arch/x86/mm/pat.c...

add_kmmio_fault_page using -1 instead of the -ENOMEM defined macro to specify kmmio_fault_page allocation failed. Smatch tool warning: arch/x86/mm/kmmio.c:389 add_kmmio_fault_page() warn: returning -1 instead of -ENOMEM is sloppy Signed-off-by: Vasyl Gomonovych <gomonovych at gmail.com> --- arch/x86/mm/kmmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

If something calls ioremap with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap the address passed to unregister_kmmio_probe was PAGE_SIZE aligned by the caller leading to a complete freeze of the machine. We should always page

4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but

3.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but

4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but

4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap() the address passed to

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap() the address passed to

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap() the address passed to

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ] If something calls ioremap() with an address not aligned to PAGE_SIZE, the returned address might be not aligned as well. This led to a probe registered on exactly the returned address, but the entire page was armed for mmiotracing. On calling iounmap() the address passed to

There are ~4300 uses of pr_warn and ~250 uses of the older pr_warning in the kernel source tree. Make the use of pr_warn consistent across all kernel files. This excludes all files in tools/ as there is a separate define pr_warning for that directory tree and pr_warn is not used in tools/. Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing. Miscellanea: o Coalesce formats and