* Re: [RFC v5 PATCH 2/2] mm: mmap: zap pages with read mmap_sem in munmap
From: Kirill A. Shutemov @ 2018-07-24 9:26 UTC (permalink / raw)
To: Yang Shi; +Cc: mhocko, willy, ldufour, akpm, linux-mm, linux-kernel
In-Reply-To: <1531956101-8526-3-git-send-email-yang.shi@linux.alibaba.com>
On Thu, Jul 19, 2018 at 07:21:41AM +0800, Yang Shi wrote:
> When running some mmap/munmap scalability tests with large memory (i.e.
> > 300GB), the below hung task issue may happen occasionally.
>
> INFO: task ps:14018 blocked for more than 120 seconds.
> Tainted: G E 4.9.79-009.ali3000.alios7.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
> message.
> ps D 0 14018 1 0x00000004
> ffff885582f84000 ffff885e8682f000 ffff880972943000 ffff885ebf499bc0
> ffff8828ee120000 ffffc900349bfca8 ffffffff817154d0 0000000000000040
> 00ffffff812f872a ffff885ebf499bc0 024000d000948300 ffff880972943000
> Call Trace:
> [<ffffffff817154d0>] ? __schedule+0x250/0x730
> [<ffffffff817159e6>] schedule+0x36/0x80
> [<ffffffff81718560>] rwsem_down_read_failed+0xf0/0x150
> [<ffffffff81390a28>] call_rwsem_down_read_failed+0x18/0x30
> [<ffffffff81717db0>] down_read+0x20/0x40
> [<ffffffff812b9439>] proc_pid_cmdline_read+0xd9/0x4e0
> [<ffffffff81253c95>] ? do_filp_open+0xa5/0x100
> [<ffffffff81241d87>] __vfs_read+0x37/0x150
> [<ffffffff812f824b>] ? security_file_permission+0x9b/0xc0
> [<ffffffff81242266>] vfs_read+0x96/0x130
> [<ffffffff812437b5>] SyS_read+0x55/0xc0
> [<ffffffff8171a6da>] entry_SYSCALL_64_fastpath+0x1a/0xc5
>
> It is because munmap holds mmap_sem exclusively from very beginning to
> all the way down to the end, and doesn't release it in the middle. When
> unmapping large mapping, it may take long time (take ~18 seconds to
> unmap 320GB mapping with every single page mapped on an idle machine).
>
> Zapping pages is the most time consuming part, according to the
> suggestion from Michal Hocko [1], zapping pages can be done with holding
> read mmap_sem, like what MADV_DONTNEED does. Then re-acquire write
> mmap_sem to cleanup vmas.
>
> But, some part may need write mmap_sem, for example, vma splitting. So,
> the design is as follows:
> acquire write mmap_sem
> lookup vmas (find and split vmas)
> detach vmas
> deal with special mappings
> downgrade_write
>
> zap pages
> free page tables
> release mmap_sem
>
> The vm events with read mmap_sem may come in during page zapping, but
> since vmas have been detached before, they, i.e. page fault, gup, etc,
> will not be able to find valid vma, then just return SIGSEGV or -EFAULT
> as expected.
>
> If the vma has VM_LOCKED | VM_HUGETLB | VM_PFNMAP or uprobe, they are
> considered as special mappings. They will be dealt with before zapping
> pages with write mmap_sem held. Basically, just update vm_flags.
>
> And, since they are also manipulated by unmap_single_vma() which is
> called by unmap_vma() with read mmap_sem held in this case, to
> prevent from updating vm_flags in read critical section, a new
> parameter, called "skip_flags" is added to unmap_region(), unmap_vmas()
> and unmap_single_vma(). If it is true, then just skip unmap those
> special mappings. Currently, the only place which pass true to this
> parameter is us.
>
> With this approach we don't have to re-acquire mmap_sem again to clean
> up vmas to avoid race window which might get the address space changed.
>
> And, since the lock acquire/release cost is managed to the minimum and
> almost as same as before, the optimization could be extended to any size
> of mapping without incuring significan penalty to small mappings.
>
> For the time being, just do this in munmap syscall path. Other
> vm_munmap() or do_munmap() call sites (i.e mmap, mremap, etc) remain
> intact for stability reason.
>
> With the patches, exclusive mmap_sem hold time when munmap a 80GB
> address space on a machine with 32 cores of E5-2680 @ 2.70GHz dropped to
> us level from second.
>
> munmap_test-15002 [008] 594.380138: funcgraph_entry: | vm_munmap_zap_rlock() {
> munmap_test-15002 [008] 594.380146: funcgraph_entry: !2485684 us | unmap_region();
> munmap_test-15002 [008] 596.865836: funcgraph_exit: !2485692 us | }
>
> Here the excution time of unmap_region() is used to evaluate the time of
> holding read mmap_sem, then the remaining time is used with holding
> exclusive lock.
>
> [1] https://lwn.net/Articles/753269/
>
> Suggested-by: Michal Hocko <mhocko@kernel.org>
> Suggested-by: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
> ---
> include/linux/mm.h | 2 +-
> mm/memory.c | 35 +++++++++++++------
> mm/mmap.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++-----
> 3 files changed, 117 insertions(+), 19 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index a0fbb9f..95a4e97 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1321,7 +1321,7 @@ void zap_vma_ptes(struct vm_area_struct *vma, unsigned long address,
> void zap_page_range(struct vm_area_struct *vma, unsigned long address,
> unsigned long size);
> void unmap_vmas(struct mmu_gather *tlb, struct vm_area_struct *start_vma,
> - unsigned long start, unsigned long end);
> + unsigned long start, unsigned long end, bool skip_flags);
skip_flags is not specific enough. Which flags? Maybe skip_vm_flags or
smething.
>
> /**
> * mm_walk - callbacks for walk_page_range
> diff --git a/mm/memory.c b/mm/memory.c
> index 7206a63..00ecdae 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1514,7 +1514,7 @@ void unmap_page_range(struct mmu_gather *tlb,
> static void unmap_single_vma(struct mmu_gather *tlb,
> struct vm_area_struct *vma, unsigned long start_addr,
> unsigned long end_addr,
> - struct zap_details *details)
> + struct zap_details *details, bool skip_flags)
> {
> unsigned long start = max(vma->vm_start, start_addr);
> unsigned long end;
> @@ -1525,11 +1525,13 @@ static void unmap_single_vma(struct mmu_gather *tlb,
> if (end <= vma->vm_start)
> return;
>
> - if (vma->vm_file)
> - uprobe_munmap(vma, start, end);
> + if (!skip_flags) {
> + if (vma->vm_file)
> + uprobe_munmap(vma, start, end);
>
> - if (unlikely(vma->vm_flags & VM_PFNMAP))
> - untrack_pfn(vma, 0, 0);
> + if (unlikely(vma->vm_flags & VM_PFNMAP))
> + untrack_pfn(vma, 0, 0);
> + }
>
> if (start != end) {
> if (unlikely(is_vm_hugetlb_page(vma))) {
> @@ -1546,7 +1548,19 @@ static void unmap_single_vma(struct mmu_gather *tlb,
> */
> if (vma->vm_file) {
> i_mmap_lock_write(vma->vm_file->f_mapping);
> - __unmap_hugepage_range_final(tlb, vma, start, end, NULL);
> + if (!skip_flags)
> + /*
> + * The vma is being unmapped with read
> + * mmap_sem.
> + * Can't update vm_flags, it will be
> + * updated later with exclusive lock
> + * held
> + */
Later? When? Don't we run this after mmap_sem is downgraded to read?
And wrap it into {}..
> + __unmap_hugepage_range(tlb, vma, start,
> + end, NULL);
> + else
> + __unmap_hugepage_range_final(tlb, vma,
> + start, end, NULL);
> i_mmap_unlock_write(vma->vm_file->f_mapping);
> }
> } else
> @@ -1574,13 +1588,14 @@ static void unmap_single_vma(struct mmu_gather *tlb,
> */
> void unmap_vmas(struct mmu_gather *tlb,
> struct vm_area_struct *vma, unsigned long start_addr,
> - unsigned long end_addr)
> + unsigned long end_addr, bool skip_flags)
> {
> struct mm_struct *mm = vma->vm_mm;
>
> mmu_notifier_invalidate_range_start(mm, start_addr, end_addr);
> for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next)
> - unmap_single_vma(tlb, vma, start_addr, end_addr, NULL);
> + unmap_single_vma(tlb, vma, start_addr, end_addr, NULL,
> + skip_flags);
> mmu_notifier_invalidate_range_end(mm, start_addr, end_addr);
> }
>
> @@ -1604,7 +1619,7 @@ void zap_page_range(struct vm_area_struct *vma, unsigned long start,
> update_hiwater_rss(mm);
> mmu_notifier_invalidate_range_start(mm, start, end);
> for ( ; vma && vma->vm_start < end; vma = vma->vm_next) {
> - unmap_single_vma(&tlb, vma, start, end, NULL);
> + unmap_single_vma(&tlb, vma, start, end, NULL, false);
>
> /*
> * zap_page_range does not specify whether mmap_sem should be
> @@ -1641,7 +1656,7 @@ static void zap_page_range_single(struct vm_area_struct *vma, unsigned long addr
> tlb_gather_mmu(&tlb, mm, address, end);
> update_hiwater_rss(mm);
> mmu_notifier_invalidate_range_start(mm, address, end);
> - unmap_single_vma(&tlb, vma, address, end, details);
> + unmap_single_vma(&tlb, vma, address, end, details, false);
> mmu_notifier_invalidate_range_end(mm, address, end);
> tlb_finish_mmu(&tlb, address, end);
> }
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2504094..f5d5312 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -73,7 +73,7 @@
>
> static void unmap_region(struct mm_struct *mm,
> struct vm_area_struct *vma, struct vm_area_struct *prev,
> - unsigned long start, unsigned long end);
> + unsigned long start, unsigned long end, bool skip_flags);
>
> /* description of effects of mapping type and prot in current implementation.
> * this is due to the limited x86 page protection hardware. The expected
> @@ -1824,7 +1824,7 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> fput(file);
>
> /* Undo any partial mapping done by a device driver. */
> - unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);
> + unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end, false);
> charged = 0;
> if (vm_flags & VM_SHARED)
> mapping_unmap_writable(file->f_mapping);
> @@ -2559,7 +2559,7 @@ static void remove_vma_list(struct mm_struct *mm, struct vm_area_struct *vma)
> */
> static void unmap_region(struct mm_struct *mm,
> struct vm_area_struct *vma, struct vm_area_struct *prev,
> - unsigned long start, unsigned long end)
> + unsigned long start, unsigned long end, bool skip_flags)
> {
> struct vm_area_struct *next = prev ? prev->vm_next : mm->mmap;
> struct mmu_gather tlb;
> @@ -2567,7 +2567,7 @@ static void unmap_region(struct mm_struct *mm,
> lru_add_drain();
> tlb_gather_mmu(&tlb, mm, start, end);
> update_hiwater_rss(mm);
> - unmap_vmas(&tlb, vma, start, end);
> + unmap_vmas(&tlb, vma, start, end, skip_flags);
> free_pgtables(&tlb, vma, prev ? prev->vm_end : FIRST_USER_ADDRESS,
> next ? next->vm_start : USER_PGTABLES_CEILING);
> tlb_finish_mmu(&tlb, start, end);
> @@ -2778,6 +2778,79 @@ static inline void munmap_mlock_vma(struct vm_area_struct *vma,
> }
> }
>
> +/*
> + * Zap pages with read mmap_sem held
> + *
> + * uf is the list for userfaultfd
> + */
> +static int do_munmap_zap_rlock(struct mm_struct *mm, unsigned long start,
> + size_t len, struct list_head *uf)
> +{
> + unsigned long end = 0;
> + struct vm_area_struct *start_vma = NULL, *prev, *vma;
> + int ret = 0;
> +
> + if (!munmap_addr_sanity(start, len))
> + return -EINVAL;
> +
> + len = PAGE_ALIGN(len);
> +
> + end = start + len;
> +
> + /*
> + * need write mmap_sem to split vmas and detach vmas
> + * splitting vma up-front to save PITA to clean if it is failed
Please fix all the comments to have consistent style.
> + */
> + if (down_write_killable(&mm->mmap_sem))
> + return -EINTR;
> +
> + ret = munmap_lookup_vma(mm, &start_vma, &prev, start, end);
> + if (ret != 1)
> + goto out;
> +
> + if (unlikely(uf)) {
> + ret = userfaultfd_unmap_prep(start_vma, start, end, uf);
> + if (ret)
> + goto out;
> + }
> +
> + /* Handle mlocked vmas */
> + if (mm->locked_vm)
> + munmap_mlock_vma(start_vma, end);
> +
> + /* Detach vmas from rbtree */
> + detach_vmas_to_be_unmapped(mm, start_vma, prev, end);
> +
> + /*
> + * Clear uprobe, VM_PFNMAP and hugetlb mapping in advance since they
> + * need update vm_flags with write mmap_sem
> + */
> + vma = start_vma;
> + for ( ; vma && vma->vm_start < end; vma = vma->vm_next) {
> + if (vma->vm_file)
> + uprobe_munmap(vma, vma->vm_start, vma->vm_end);
> + if (unlikely(vma->vm_flags & VM_PFNMAP))
> + untrack_pfn(vma, 0, 0);
> + if (is_vm_hugetlb_page(vma))
> + vma->vm_flags &= ~VM_MAYSHARE;
> + }
> +
> + downgrade_write(&mm->mmap_sem);
> +
> + /* zap mappings with read mmap_sem */
> + unmap_region(mm, start_vma, prev, start, end, true);
> +
> + arch_unmap(mm, start_vma, start, end);
> + remove_vma_list(mm, start_vma);
> + up_read(&mm->mmap_sem);
> +
> + return 0;
> +
> +out:
> + up_write(&mm->mmap_sem);
> + return ret;
> +}
> +
> /* Munmap is split into 2 main parts -- this part which finds
> * what needs doing, and the areas themselves, which do the
> * work. This now handles partial unmappings.
> @@ -2826,7 +2899,7 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len,
> * Remove the vma's, and unmap the actual pages
> */
> detach_vmas_to_be_unmapped(mm, vma, prev, end);
> - unmap_region(mm, vma, prev, start, end);
> + unmap_region(mm, vma, prev, start, end, false);
>
> arch_unmap(mm, vma, start, end);
>
> @@ -2836,6 +2909,17 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len,
> return 0;
> }
>
> +static int vm_munmap_zap_rlock(unsigned long start, size_t len)
> +{
> + int ret;
> + struct mm_struct *mm = current->mm;
> + LIST_HEAD(uf);
> +
> + ret = do_munmap_zap_rlock(mm, start, len, &uf);
> + userfaultfd_unmap_complete(mm, &uf);
> + return ret;
> +}
> +
> int vm_munmap(unsigned long start, size_t len)
> {
> int ret;
> @@ -2855,10 +2939,9 @@ int vm_munmap(unsigned long start, size_t len)
> SYSCALL_DEFINE2(munmap, unsigned long, addr, size_t, len)
> {
> profile_munmap(addr);
> - return vm_munmap(addr, len);
> + return vm_munmap_zap_rlock(addr, len);
> }
>
> -
> /*
> * Emulation of deprecated remap_file_pages() syscall.
> */
> @@ -3146,7 +3229,7 @@ void exit_mmap(struct mm_struct *mm)
> tlb_gather_mmu(&tlb, mm, 0, -1);
> /* update_hiwater_rss(mm) here? but nobody should be looking */
> /* Use -1 here to ensure all VMAs in the mm are unmapped */
> - unmap_vmas(&tlb, vma, 0, -1);
> + unmap_vmas(&tlb, vma, 0, -1, false);
> free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
> tlb_finish_mmu(&tlb, 0, -1);
>
> --
> 1.8.3.1
>
--
Kirill A. Shutemov
^ permalink raw reply
* [Bug 107328] radeon_gart_table_vram_pin takes 473 ms during ACPI S3 resume
From: bugzilla-daemon @ 2018-07-24 9:26 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-107328-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 1569 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=107328
Paul Menzel <pmenzel+bugs.freedesktop@molgen.mpg.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |INVALID
--- Comment #2 from Paul Menzel <pmenzel+bugs.freedesktop@molgen.mpg.de> ---
Just as a follow-up, the long time seems to have been caused by ftrace.
With the patch below on top of drm-tip from this morning, it only takes 7 ms.
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 1cef155cc933..f79a2f8b8d8e 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -175,10 +175,13 @@ int radeon_gart_table_vram_pin(struct radeon_device
*rdev)
/* We might have dropped some GART table updates while it
wasn't
* mapped, restore all entries
*/
+ DRM_INFO("GART: Restore entries: num cpu pages %u, num gpu
pages %u\n",
+ rdev->gart.num_cpu_pages,
rdev->gart.num_gpu_pages);
for (i = 0; i < rdev->gart.num_gpu_pages; i++)
radeon_gart_set_page(rdev, i,
rdev->gart.pages_entry[i]);
mb();
radeon_gart_tlb_flush(rdev);
+ DRM_INFO("GART: Done restoring entries\n");
}
return r;
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 3093 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v2 2/4] banned.h: mark strcat() as banned
From: Jeff King @ 2018-07-24 9:26 UTC (permalink / raw)
To: git; +Cc: Stefan Beller, Eric Sunshine, Junio C Hamano
In-Reply-To: <20180724092329.GA24250@sigill.intra.peff.net>
The strcat() function has all of the same overflow problems
as strcpy(). And as a bonus, it's easy to end up
accidentally quadratic, as each subsequent call has to walk
through the existing string.
The last strcat() call went away in f063d38b80 (daemon: use
cld->env_array when re-spawning, 2015-09-24). In general,
strcat() can be replaced either with a dynamic string
(strbuf or xstrfmt), or with xsnprintf if you know the
length is bounded.
Signed-off-by: Jeff King <peff@peff.net>
---
banned.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/banned.h b/banned.h
index c50091ad7d..32e0bae01d 100644
--- a/banned.h
+++ b/banned.h
@@ -12,5 +12,7 @@
#undef strcpy
#define strcpy(x,y) BANNED(strcpy)
+#undef strcat
+#define strcat(x,y) BANNED(strcat)
#endif /* BANNED_H */
--
2.18.0.542.g2bf2fc4f7e
^ permalink raw reply related
* [PATCH v2 1/4] automatically ban strcpy()
From: Jeff King @ 2018-07-24 9:26 UTC (permalink / raw)
To: git; +Cc: Stefan Beller, Eric Sunshine, Junio C Hamano
In-Reply-To: <20180724092329.GA24250@sigill.intra.peff.net>
There are a few standard C functions (like strcpy) which are
easy to misuse. E.g.:
char path[PATH_MAX];
strcpy(path, arg);
may overflow the "path" buffer. Sometimes there's an earlier
constraint on the size of "arg", but even in such a case
it's hard to verify that the code is correct. If the size
really is unbounded, you're better off using a dynamic
helper like strbuf:
struct strbuf path = STRBUF_INIT;
strbuf_addstr(path, arg);
or if it really is bounded, then use xsnprintf to show your
expectation (and get a run-time assertion):
char path[PATH_MAX];
xsnprintf(path, sizeof(path), "%s", arg);
which makes further auditing easier.
We'd usually catch undesirable code like this in a review,
but there's no automated enforcement. Adding that
enforcement can help us be more consistent and save effort
(and a round-trip) during review.
This patch teaches the compiler to report an error when it
sees strcpy (and will become a model for banning a few other
functions). This has a few advantages over a separate
linting tool:
1. We know it's run as part of a build cycle, so it's
hard to ignore. Whereas an external linter is an extra
step the developer needs to remember to do.
2. Likewise, it's basically free since the compiler is
parsing the code anyway.
3. We know it's robust against false positives (unlike a
grep-based linter).
The two big disadvantages are:
1. We'll only check code that is actually compiled, so it
may miss code that isn't triggered on your particular
system. But since presumably people don't add new code
without compiling it (and if they do, the banned
function list is the least of their worries), we really
only care about failing to clean up old code when
adding new functions to the list. And that's easy
enough to address with a manual audit when adding a new
function.
2. If this ends up generating false positives, it's going
to be harder to disable (as opposed to a separate
linter, which may have mechanisms for overriding a
particular case).
But the intent is to only ban functions which are
obviously bad, and for which we accept using an
alternative even when this particular use isn't buggy
(e.g., the xsnprintf alternative above).
The implementation here is simple: we'll define a macro for
the banned function which replaces it with a descriptively
named but undefined function. Replacing it with any invalid
code would work (since we just want to break compilation).
But ideally we'd meet these goals:
- it should be portable; ideally this would trigger
everywhere, and does not need to be part of a DEVELOPER=1
setup (because unlike warnings which may depend on the
compiler or system, this is a clear indicator of
something wrong in the code).
- it should generate a readable error that gives the
developer a clue what happened
- it should avoid generating too much other cruft that
makes it hard to see the actual error
- it should mention the original callsite in the error
The output with this patch looks like this (using gcc 7, on
a checkout without 022d2ac1f3, which removes the final
strcpy from blame.c):
CC builtin/blame.o
In file included from ./git-compat-util.h:1242:0,
from ./cache.h:4,
from builtin/blame.c:8:
builtin/blame.c: In function ‘cmd_blame’:
./banned.h:11:22: error: implicit declaration of function ‘sorry_strcpy_is_a_banned_function’ [-Werror=implicit-function-declaration]
#define BANNED(func) sorry_##func##_is_a_banned_function()
^
./banned.h:13:21: note: in expansion of macro ‘BANNED’
#define strcpy(x,y) BANNED(strcpy)
^~~~~~
builtin/blame.c:1074:4: note: in expansion of macro ‘strcpy’
strcpy(repeated_meta_color, GIT_COLOR_CYAN);
^~~~~~
This pretty clearly shows the original callsite along with
the descriptive function name, and it mentions banned.h,
which contains more information.
What's not perfectly ideal is:
1. We'll only trigger with -Wimplicit-function-declaration
(and only stop compilation with -Werror). These are
generally enabled by DEVELOPER=1. If you _don't_ have
that set, we'll still catch the problem, but only at
link-time, with a slightly less useful message:
/usr/bin/ld: builtin/blame.o: in function `cmd_blame':
/home/peff/tmp/builtin/blame.c:1074: undefined reference to `sorry_strcpy_is_a_banned_function'
collect2: error: ld returned 1 exit status
If instead we convert this to a reference to an
undefined variable, that always dies immediately. But
gcc seems to print the set of errors twice, which
clutters things up.
2. The expansion through BANNED() adds an extra layer of
error. Curiously, though, removing it (and just
expanding strcpy directly to the bogus function name)
causes gcc _not_ to report the original line of code.
So experimentally, this seems to behave pretty well on gcc.
Clang looks OK, too, though:
- it actually produces a better message for the undeclared
identifier than for the implicit function (it doesn't
double the errors, and for the implicit function it
actually produces an extra complaint about
strict-prototypes).
- the BANNED indirection has no effect (it shows the
original line of code either way)
So if we want to optimize for clang's output, we could
switch both of those decisions.
Note that the linux kernel has a similar mechanism which
goes by BUILD_BUG_ON_MSG(). It works by declaring a one-off
function with gcc's error attribute. That doesn't work for
us here, because we'd like to work even on non-gcc
compilers (and in my opinion the compiler output is actually
_less_ readable).
Signed-off-by: Jeff King <peff@peff.net>
---
banned.h | 16 ++++++++++++++++
git-compat-util.h | 6 ++++++
2 files changed, 22 insertions(+)
create mode 100644 banned.h
diff --git a/banned.h b/banned.h
new file mode 100644
index 0000000000..c50091ad7d
--- /dev/null
+++ b/banned.h
@@ -0,0 +1,16 @@
+#ifndef BANNED_H
+#define BANNED_H
+
+/*
+ * This header lists functions that have been banned from our code base,
+ * because they're too easy to misuse (and even if used correctly,
+ * complicate audits). Including this header turns them into compile-time
+ * errors.
+ */
+
+#define BANNED(func) sorry_##func##_is_a_banned_function()
+
+#undef strcpy
+#define strcpy(x,y) BANNED(strcpy)
+
+#endif /* BANNED_H */
diff --git a/git-compat-util.h b/git-compat-util.h
index 9a64998b24..89d37095c7 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -1239,4 +1239,10 @@ extern void unleak_memory(const void *ptr, size_t len);
#define UNLEAK(var) do {} while (0)
#endif
+/*
+ * This include must come after system headers, since it introduces macros that
+ * replace system names.
+ */
+#include "banned.h"
+
#endif
--
2.18.0.542.g2bf2fc4f7e
^ permalink raw reply related
* Re: automation: Creating a patchwork instance to improve pre-commit build testing
From: Lars Kurth @ 2018-07-24 9:26 UTC (permalink / raw)
To: Jan Beulich, Doug Goldstein, Wei Liu
Cc: Minios-devel, xen-devel, Iurii Artemenko,
committers@xenproject.org, Matt Spencer
In-Reply-To: <5B56EC0002000078001D708C@prv1-mh.provo.novell.com>
On 24/07/2018, 10:06, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> On 23.07.18 at 18:40, <lars.kurth@citrix.com> wrote:
> This does mean though that series which do not build or show other issues,
> will likely not be reviewed until the tests pass. This would lessen the
> burden on reviewers, as they will know whether the code submitted builds on a
> wide array of environments.
So how are dependencies between series intended to be dealt with? It
is not uncommon for someone to say "applies only on top of xyz". The
implication of "will likely not be reviewed until the tests pass" seems
unsuitable to me in such a case.
We should look at how this is done in communities which have systems in place that do some off-list verification of patches, such as qemu and linux (0 day test service).
Obviously in such cases the test bot would return results for a fail. The sensible thing to do would be the following:
* For the submitter of the patch to notify the reviewer(s) to highlight the test failure/dependency
* For the reviewer to spot the dependency
In any case, the reviewer would have to decide whether to review a series which cannot be automatically build tested off list at that stage.
Thinking about it a bit more, there are also two places at which things can go wrong:
a) Failure to apply the patch => this would probably be the most likely outcome with a dependency
b) Failure to build => if there was a missing dependency then probably fail in ALL build environments
In other words, there should be some tell-tales for this case, which can probably be highlighted in the bot results
Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-3.0 4/4] tests: torture release-ram in postcopy test
From: Juan Quintela @ 2018-07-24 9:25 UTC (permalink / raw)
To: Peter Xu; +Cc: qemu-devel, Dr . David Alan Gilbert
In-Reply-To: <20180723123305.24792-5-peterx@redhat.com>
Peter Xu <peterx@redhat.com> wrote:
> The release-ram capability will run some extra code for postcopy to
> release used ram right away, let's just turn that on for the postcopy
> unix test always to torture that code path too to make sure release-ram
> feature won't break again. The recovery test needs to turn that off
> since release-ram cannot coop with that.
>
> Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
But I think that the proper thing to do here is to have two tests. One
for postcopy and another for postcopy + release-ram.
^ permalink raw reply
* Re: [PATCH] app/testpmd: fix testpmd exit using ctrl+d
From: Iremonger, Bernard @ 2018-07-24 9:25 UTC (permalink / raw)
To: Singh, Jasvinder, dev@dpdk.org; +Cc: Pattan, Reshma
In-Reply-To: <20180723104425.10090-1-jasvinder.singh@intel.com>
Hi Jasvider,
> -----Original Message-----
> From: Singh, Jasvinder
> Sent: Monday, July 23, 2018 11:44 AM
> To: dev@dpdk.org
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>
> Subject: [PATCH] app/testpmd: fix testpmd exit using ctrl+d
>
> Fix testpmd app exit by pressing ctrl+d, End-of-Transmission character (EOT)
> on the empty command line.
>
> Fixes: 0ad778b398c6 ("app/testpmd: rework softnic forward mode")
>
> Reported-by: Mordechay Haimovsky <motih@mellanox.com>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> ---
> app/test-pmd/cmdline.c | 10 ++++++----
> lib/librte_cmdline/cmdline.c | 2 +-
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 5885289..edaf0e6 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -17581,12 +17581,14 @@ prompt(void)
>
> for (;;) {
> status = cmdline_poll(testpmd_cl);
> - if (status < 0)
> - rte_panic("CLI poll error (%" PRId32 ")\n", status);
> - else if (status == RDLINE_EXITED) {
> + if (status == RDLINE_EXITED || status == RDLINE_RES_EOF) {
> + if (status == RDLINE_RES_EOF)
> + pmd_test_exit();
> +
> cmdline_stdin_exit(testpmd_cl);
> rte_exit(0, "\n");
> - }
> + } else if (status < 0)
> + rte_panic("CLI poll error (%" PRId32 ")\n", status);
>
> #if defined RTE_LIBRTE_PMD_SOFTNIC
>
> diff --git a/lib/librte_cmdline/cmdline.c b/lib/librte_cmdline/cmdline.c index
> 591b78b..47b0f6a 100644
> --- a/lib/librte_cmdline/cmdline.c
> +++ b/lib/librte_cmdline/cmdline.c
> @@ -187,7 +187,7 @@ cmdline_in(struct cmdline *cl, const char *buf, int
> size)
> rdline_newline(&cl->rdl, cl->prompt);
> }
> else if (ret == RDLINE_RES_EOF)
> - return -1;
> + return RDLINE_RES_EOF;
> else if (ret == RDLINE_RES_EXITED)
> return -1;
> }
> --
> 2.9.3
The check-git-log script is showing the following error:
./devtools/check-git-log.sh -1
Line too long:
Fix testpmd app exit by pressing ctrl+d, End-of-Transmission character (EOT)
Regards,
Bernard.
^ permalink raw reply
* Re: automation: Creating a patchwork instance to improve pre-commit build testing
From: Wei Liu @ 2018-07-24 9:24 UTC (permalink / raw)
To: Jan Beulich
Cc: Lars Kurth, Iurii Artemenko, Wei Liu, Doug Goldstein,
Minios-devel, committers, xen-devel, Matt Spencer
In-Reply-To: <5B56EC0002000078001D708C@prv1-mh.provo.novell.com>
On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >>> On 23.07.18 at 18:40, <lars.kurth@citrix.com> wrote:
> > # How does this impact me?
> > The contribution workflow is *not* impacted by this change, but once up and
> > running the following will happen once you post a patch or patch series to
> > xen-devel:
> > * Patchwork will take patch series from the mailing list and applies it
> > * CI/DC testing is triggered
> > * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series)
> >
> > This does mean though that series which do not build or show other issues,
> > will likely not be reviewed until the tests pass. This would lessen the
> > burden on reviewers, as they will know whether the code submitted builds on a
> > wide array of environments.
>
> So how are dependencies between series intended to be dealt with? It
> is not uncommon for someone to say "applies only on top of xyz". The
> implication of "will likely not be reviewed until the tests pass" seems
> unsuitable to me in such a case.
>
We have been asking everyone to rebase to staging before posting a new
version for a long time. It is natural for the bot to assume that
everything should apply on top of staging. That would provide most value
to the community.
For special cases like you just mention, we should aim to provide
mechanisms to manually appoint a branch to be tested.
Wei.
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] btrfs: fix size_t format string
From: David Sterba @ 2018-07-24 8:19 UTC (permalink / raw)
To: Randy Dunlap
Cc: dsterba, Arnd Bergmann, Chris Mason, Josef Bacik, David Sterba,
Qu Wenruo, Nikolay Borisov, Su Yue, linux-btrfs, linux-kernel
In-Reply-To: <544184a7-25ae-55a6-3e81-0e1fa1e5cd1d@infradead.org>
On Mon, Jul 23, 2018 at 10:07:42AM -0700, Randy Dunlap wrote:
> On 07/17/2018 08:04 AM, David Sterba wrote:
> > On Tue, Jul 17, 2018 at 03:52:27PM +0200, Arnd Bergmann wrote:
> >> The newly added check_block_group_item() function causes a build warning
> >> on 32-bit architectures:
> >>
> >> fs/btrfs/tree-checker.c: In function 'check_block_group_item':
> >> fs/btrfs/tree-checker.c:404:41: error: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'unsigned int' [-Werror=format=]
> >>
> >> The type of a sizeof() expression is size_t, which is correctly printed
> >> using the %zu format string.
> >>
> >> Fixes: 9dc16aad5660 ("btrfs: tree-checker: Verify block_group_item")
> >
> > Folded to the commit, thanks.
> >
>
> Hi David,
> Where did this patch end up? linux-next-20180723 is still showing this
> format warning.
It's still in a local branch, I haven't pushed for-next for a few days
but will do today.
^ permalink raw reply
* Re: [PATCH v2] UBI: Add volume read and write statistics
From: Richard Weinberger @ 2018-07-24 8:19 UTC (permalink / raw)
To: Per Forlin, linux-block; +Cc: linux-mtd, Artem Bityutskiy, derosier, Per Forlin
In-Reply-To: <1532360342-52055-1-git-send-email-perfn@axis.com>
[Adding linux-block]
Am Montag, 23. Juli 2018, 17:39:02 CEST schrieb Per Forlin:
> Simple read and write statistics.
> * Number of reads
> * Number of writes
> * Bytes read
> * Bytes written
>
> This is useful to find out how the storage is being utilized.
> For block devices this already exists here:
> /sys/class/block/<device>/stat
>
> For UBI it now exists here:
> /sys/class/ubi/<volume>/stat
Please document it also in Documentation/ABI/stable/sysfs-class-ubi.
> Example:
> /sys/class/ubi/ubi0_21/stat
> 864 0 3106756 0 1057 0 2144256 0 0 0 0
>
> The output format is same as for block devices
> except that not all metrics are supported yet.
> Unsupported values are set to 0.
Let's ask block folks what they think about.
Per, did you check, which tools use the stats file in /sys?
I checked iostat, it seems to consume only /proc/diskstats.
To give more context, UBI and MTD devices offer access to raw flash
storage. So, we have filesystems on top of it.
Since these devices are not block devices, almost no tool know
about these.
With this patch we'd like to offer a interface to userspace such that
tools will also discover UBI devices.
Maybe MTD devices later too.
> ---
> Changelog:
>
> v2
> * Question: Translate bytes to sectors? iostats format expects sector unit.
Not sure. I'd wait for input from userspace and block folks.
> * Align with iostats format
> * Only count successful reads and writes
>
> drivers/mtd/ubi/eba.c | 11 ++++++++++-
> drivers/mtd/ubi/ubi.h | 19 +++++++++++++++++++
> drivers/mtd/ubi/vmt.c | 8 ++++++++
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
> index b98481b..c9a88b2 100644
> --- a/drivers/mtd/ubi/eba.c
> +++ b/drivers/mtd/ubi/eba.c
> @@ -731,6 +731,11 @@ int ubi_eba_read_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum,
> }
> }
>
> + if (!err) {
> + vol->stat.rcount++;
> + vol->stat.rbytes += len;
Can we please have a helper function for that?
> + }
> +
> if (scrub)
> err = ubi_wl_scrub_peb(ubi, pnum);
>
> @@ -1091,8 +1096,12 @@ int ubi_eba_write_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum,
> ubi_free_vid_buf(vidb);
>
> out:
> - if (err)
> + if (err) {
> ubi_ro_mode(ubi);
> + } else {
> + vol->stat.wcount++;
> + vol->stat.wbytes += len;
Same.
> + }
>
> leb_write_unlock(ubi, vol_id, lnum);
>
> diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
> index f5ba97c..0cb00f0 100644
> --- a/drivers/mtd/ubi/ubi.h
> +++ b/drivers/mtd/ubi/ubi.h
> @@ -293,6 +293,23 @@ struct ubi_eba_leb_desc {
> };
>
> /**
> + * struct ubi_volume_stat - Volume statistics
> + * @rbytes: the number of bytes read
> + * @wbytes: the number of bytes written
> + * @rcount: the number of read requests
> + * @wcount: the number of write requests
> + *
> + * This structure contains read and write statistics.
> + *
> + */
> +struct ubi_volume_stat {
> + u64 rbytes;
> + u64 wbytes;
> + u32 rcount;
> + u32 wcount;
Does the wide of these integers also match with block devices?
Thanks,
//richard
^ permalink raw reply
* [Qemu-devel] [PATCH for-3.1] s390x: remove 's390-squash-mcss' option
From: Cornelia Huck @ 2018-07-24 9:24 UTC (permalink / raw)
To: qemu-s390x
Cc: Christian Borntraeger, Alexander Graf, Richard Henderson,
David Hildenbrand, Thomas Huth, Halil Pasic, Xiao Feng Ren,
qemu-devel, libvir-list, Cornelia Huck
This option has been deprecated for two releases; remove it.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
---
hw/s390x/3270-ccw.c | 2 +-
hw/s390x/css-bridge.c | 1 -
hw/s390x/css.c | 6 ++----
hw/s390x/s390-ccw.c | 2 +-
hw/s390x/s390-virtio-ccw.c | 37 ++-----------------------------------
hw/s390x/virtio-ccw.c | 2 +-
include/hw/s390x/css-bridge.h | 1 -
include/hw/s390x/css.h | 9 +++------
include/hw/s390x/s390-virtio-ccw.h | 1 -
qemu-deprecated.texi | 8 --------
qemu-options.hx | 10 ----------
target/s390x/cpu.c | 10 ----------
target/s390x/cpu.h | 1 -
13 files changed, 10 insertions(+), 80 deletions(-)
diff --git a/hw/s390x/3270-ccw.c b/hw/s390x/3270-ccw.c
index 3af13ea027..cf58b81fc0 100644
--- a/hw/s390x/3270-ccw.c
+++ b/hw/s390x/3270-ccw.c
@@ -104,7 +104,7 @@ static void emulated_ccw_3270_realize(DeviceState *ds, Error **errp)
SubchDev *sch;
Error *err = NULL;
- sch = css_create_sch(cdev->devno, cbus->squash_mcss, errp);
+ sch = css_create_sch(cdev->devno, errp);
if (!sch) {
return;
}
diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c
index a02d708239..1bd6c8b458 100644
--- a/hw/s390x/css-bridge.c
+++ b/hw/s390x/css-bridge.c
@@ -106,7 +106,6 @@ VirtualCssBus *virtual_css_bus_init(void)
/* Create bus on bridge device */
bus = qbus_create(TYPE_VIRTUAL_CSS_BUS, dev, "virtual-css");
cbus = VIRTUAL_CSS_BUS(bus);
- cbus->squash_mcss = s390_get_squash_mcss();
/* Enable hotplugging */
qbus_set_hotplug_handler(bus, dev, &error_abort);
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 5424ea4562..5a9fe45ce8 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -2359,15 +2359,13 @@ const PropertyInfo css_devid_ro_propinfo = {
.get = get_css_devid,
};
-SubchDev *css_create_sch(CssDevId bus_id, bool squash_mcss, Error **errp)
+SubchDev *css_create_sch(CssDevId bus_id, Error **errp)
{
uint16_t schid = 0;
SubchDev *sch;
if (bus_id.valid) {
- if (squash_mcss) {
- bus_id.cssid = channel_subsys.default_cssid;
- } else if (!channel_subsys.css[bus_id.cssid]) {
+ if (!channel_subsys.css[bus_id.cssid]) {
css_create_css_image(bus_id.cssid, false);
}
diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c
index 214c940593..d1280bf631 100644
--- a/hw/s390x/s390-ccw.c
+++ b/hw/s390x/s390-ccw.c
@@ -78,7 +78,7 @@ static void s390_ccw_realize(S390CCWDevice *cdev, char *sysfsdev, Error **errp)
goto out_err_propagate;
}
- sch = css_create_sch(ccw_dev->devno, cbus->squash_mcss, &err);
+ sch = css_create_sch(ccw_dev->devno, &err);
if (!sch) {
goto out_mdevid_free;
}
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 7983185d04..380a41d806 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -282,19 +282,8 @@ static void ccw_init(MachineState *machine)
virtio_ccw_register_hcalls();
s390_enable_css_support(s390_cpu_addr2state(0));
- /*
- * Non mcss-e enabled guests only see the devices from the default
- * css, which is determined by the value of the squash_mcss property.
- */
- if (css_bus->squash_mcss) {
- ret = css_create_css_image(0, true);
- } else {
- ret = css_create_css_image(VIRTUAL_CSSID, true);
- }
- if (qemu_opt_get(qemu_get_machine_opts(), "s390-squash-mcss")) {
- warn_report("The machine property 's390-squash-mcss' is deprecated"
- " (obsoleted by lifting the cssid restrictions).");
- }
+
+ ret = css_create_css_image(VIRTUAL_CSSID, true);
assert(ret == 0);
if (css_migration_enabled()) {
@@ -575,21 +564,6 @@ static void machine_set_loadparm(Object *obj, const char *val, Error **errp)
ms->loadparm[i] = ' '; /* pad right with spaces */
}
}
-static inline bool machine_get_squash_mcss(Object *obj, Error **errp)
-{
- S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
-
- return ms->s390_squash_mcss;
-}
-
-static inline void machine_set_squash_mcss(Object *obj, bool value,
- Error **errp)
-{
- S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
-
- ms->s390_squash_mcss = value;
-}
-
static inline void s390_machine_initfn(Object *obj)
{
object_property_add_bool(obj, "aes-key-wrap",
@@ -614,13 +588,6 @@ static inline void s390_machine_initfn(Object *obj)
" to upper case) to pass to machine loader, boot manager,"
" and guest kernel",
NULL);
- object_property_add_bool(obj, "s390-squash-mcss",
- machine_get_squash_mcss,
- machine_set_squash_mcss, NULL);
- object_property_set_description(obj, "s390-squash-mcss", "(deprecated) "
- "enable/disable squashing subchannels into the default css",
- NULL);
- object_property_set_bool(obj, false, "s390-squash-mcss", NULL);
}
static const TypeInfo ccw_machine_info = {
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 7ddb378d52..3156e8d6e1 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -700,7 +700,7 @@ static void virtio_ccw_device_realize(VirtioCcwDevice *dev, Error **errp)
SubchDev *sch;
Error *err = NULL;
- sch = css_create_sch(ccw_dev->devno, cbus->squash_mcss, errp);
+ sch = css_create_sch(ccw_dev->devno, errp);
if (!sch) {
return;
}
diff --git a/include/hw/s390x/css-bridge.h b/include/hw/s390x/css-bridge.h
index cf0860432a..5a0203be5f 100644
--- a/include/hw/s390x/css-bridge.h
+++ b/include/hw/s390x/css-bridge.h
@@ -28,7 +28,6 @@ typedef struct VirtualCssBridge {
/* virtual css bus type */
typedef struct VirtualCssBus {
BusState parent_obj;
- bool squash_mcss;
} VirtualCssBus;
#define TYPE_VIRTUAL_CSS_BUS "virtual-css-bus"
diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
index 35facb47d2..9da5912921 100644
--- a/include/hw/s390x/css.h
+++ b/include/hw/s390x/css.h
@@ -266,11 +266,8 @@ extern const PropertyInfo css_devid_ro_propinfo;
/**
* Create a subchannel for the given bus id.
*
- * If @p bus_id is valid, and @p squash_mcss is true, verify that it is
- * not already in use in the default css, and find a free devno from the
- * default css image for it.
- * If @p bus_id is valid, and @p squash_mcss is false, verify that it is
- * not already in use, and find a free devno for it.
+ * If @p bus_id is valid, verify that it is not already in use, and find a
+ * free devno for it.
* If @p bus_id is not valid find a free subchannel id and device number
* across all subchannel sets and all css images starting from the default
* css image.
@@ -282,7 +279,7 @@ extern const PropertyInfo css_devid_ro_propinfo;
* The caller becomes owner of the returned subchannel structure and
* is responsible for unregistering and freeing it.
*/
-SubchDev *css_create_sch(CssDevId bus_id, bool squash_mcss, Error **errp);
+SubchDev *css_create_sch(CssDevId bus_id, Error **errp);
/** Turn on css migration */
void css_register_vmstate(void);
diff --git a/include/hw/s390x/s390-virtio-ccw.h b/include/hw/s390x/s390-virtio-ccw.h
index ab88d49d10..e9c4f4182b 100644
--- a/include/hw/s390x/s390-virtio-ccw.h
+++ b/include/hw/s390x/s390-virtio-ccw.h
@@ -29,7 +29,6 @@ typedef struct S390CcwMachineState {
bool aes_key_wrap;
bool dea_key_wrap;
uint8_t loadparm[8];
- bool s390_squash_mcss;
} S390CcwMachineState;
typedef struct S390CcwMachineClass {
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 9920a85adc..09f7b22fb1 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -126,14 +126,6 @@ The ``-nodefconfig`` argument is a synonym for ``-no-user-config``.
The @option{--balloon virtio} argument has been superseded by
@option{--device virtio-balloon}.
-@subsection -machine s390-squash-mcss=on|off (since 2.12.0)
-
-The ``s390-squash-mcss=on`` property has been obsoleted by allowing the
-cssid to be chosen freely. Instead of squashing subchannels into the
-default channel subsystem image for guests that do not support multiple
-channel subsystems, all devices can be put into the default channel
-subsystem image.
-
@subsection -fsdev handle (since 2.12.0)
The ``handle'' fsdev backend does not support symlinks and causes the 9p
diff --git a/qemu-options.hx b/qemu-options.hx
index b1bf0f485f..e57cec96a5 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -43,7 +43,6 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
" suppress-vmdesc=on|off disables self-describing migration (default=off)\n"
" nvdimm=on|off controls NVDIMM support (default=off)\n"
" enforce-config-section=on|off enforce configuration section migration (default=off)\n"
- " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n"
" memory-encryption=@var{} memory encryption object to use (default=none)\n",
QEMU_ARCH_ALL)
STEXI
@@ -96,15 +95,6 @@ controls whether DEA wrapping keys will be created to allow
execution of DEA cryptographic functions. The default is on.
@item nvdimm=on|off
Enables or disables NVDIMM support. The default is off.
-@item s390-squash-mcss=on|off
-Enables or disables squashing subchannels into the default css.
-The default is off.
-NOTE: This property is deprecated and will be removed in future releases.
-The ``s390-squash-mcss=on`` property has been obsoleted by allowing the
-cssid to be chosen freely. Instead of squashing subchannels into the
-default channel subsystem image for guests that do not support multiple
-channel subsystems, all devices can be put into the default channel
-subsystem image.
@item enforce-config-section=on|off
If @option{enforce-config-section} is set to @var{on}, force migration
code to send configuration section even if the machine-type sets the
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 271c5ce652..8ed4823d6e 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -421,16 +421,6 @@ void s390_crypto_reset(void)
}
}
-bool s390_get_squash_mcss(void)
-{
- if (object_property_get_bool(OBJECT(qdev_get_machine()), "s390-squash-mcss",
- NULL)) {
- return true;
- }
-
- return false;
-}
-
void s390_enable_css_support(S390CPU *cpu)
{
if (kvm_enabled()) {
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 2c3dd2d189..86b66dfeac 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -713,7 +713,6 @@ static inline void s390_do_cpu_load_normal(CPUState *cs, run_on_cpu_data arg)
/* cpu.c */
void s390_crypto_reset(void);
-bool s390_get_squash_mcss(void);
int s390_set_memory_limit(uint64_t new_limit, uint64_t *hw_limit);
void s390_cmma_reset(void);
void s390_enable_css_support(S390CPU *cpu);
--
2.14.4
^ permalink raw reply related
* Copy of: [Shared Post]netdev@vger.kernel.org
From: Midwest Insurance Brokerage @ 2018-07-24 8:01 UTC (permalink / raw)
To: netdev
Copy of:
This is an enquiry e-mail via http://www.mibltd.com/ from:
niushenjia <netdev@vger.kernel.org>
汇聚全球精彩赛事。皇冠/沙巴/波音/欧冠/应有尽有。半场结算,实时返水1%。WWW.2220162.COM
------------------
太学儒生东鲁客,二十辞家来射策。夜书细字缀语言,
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-3.0 3/4] tests: only update last_byte when at the edge
From: Juan Quintela @ 2018-07-24 9:23 UTC (permalink / raw)
To: Peter Xu; +Cc: qemu-devel, Dr . David Alan Gilbert
In-Reply-To: <20180723123305.24792-4-peterx@redhat.com>
Peter Xu <peterx@redhat.com> wrote:
> The only possible change of last_byte is when it reaches the edge.
> Setting it every time might let last_byte contain an invalid data when
> memory corruption is detected, then the check of the next byte will be
> incorrect. For example, a single page corruption at address 0x14ad000
> will also lead to a "fake" corruption at 0x14ae000:
>
> Memory content inconsistency at 14ad000 first_byte = 44 last_byte = 44 current = ef hit_edge = 0
> Memory content inconsistency at 14ae000 first_byte = 44 last_byte = ef current = 44 hit_edge = 0
>
> After the patch, it'll only report the corrputed page:
>
> Memory content inconsistency at 14ad000 first_byte = 44 last_byte = 44 current = ef hit_edge = 0
>
> Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Good catch. I was having this problem in the past, but never
investigated the problem so far.
^ permalink raw reply
* [PATCH v2 0/4] fail compilation with strcpy
From: Jeff King @ 2018-07-24 9:23 UTC (permalink / raw)
To: git; +Cc: Stefan Beller, Eric Sunshine, Junio C Hamano
In-Reply-To: <20180719203259.GA7869@sigill.intra.peff.net>
On Thu, Jul 19, 2018 at 04:32:59PM -0400, Jeff King wrote:
> This is a patch series to address the discussion in the thread at:
>
> https://public-inbox.org/git/20180713204350.GA16999@sigill.intra.peff.net/
>
> Basically, the question was: can we declare strcpy banned and have a
> linter save us the trouble of finding it in review. The answer is yes,
> the compiler is good at that. ;)
Here's a v2 that I think addresses the comments on the earlier series.
Thanks everybody for your review.
Changes here include:
- drop the mention in CodingGuidelines. That list is already long, and
we don't need to to waste mental effort on things that will be
enforced automatically
- we now #undef all macros before defining them to avoid redefinition
warnings
- the first patch now covers _just_ strcpy(), and each function gets
its own patch with an explanation (and suggested alternatives). My
thought is that these should be easy to dig up via blame, "log -S",
or "log --grep". Though another option would be comments in banned.h.
- added strcat and vsprintf to the banned list
- tweaked the first patch's commit message for clarity and to address
points raised in discussion
As before, this needs to go on top of 022d2ac1f3 (which I hope should
hit master soon anyway).
[1/4]: automatically ban strcpy()
[2/4]: banned.h: mark strcat() as banned
[3/4]: banned.h: mark sprintf() as banned
[4/4]: banned.h: mark strncpy() as banned
banned.h | 30 ++++++++++++++++++++++++++++++
git-compat-util.h | 6 ++++++
2 files changed, 36 insertions(+)
create mode 100644 banned.h
-Peff
^ permalink raw reply
* Re: [PATCHv4 01/12] atomic/tty: Fix up atomic abuse in ldsem
From: Mark Rutland @ 2018-07-24 9:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, mingo, andy.shevchenko, arnd, aryabinin, boqun.feng,
catalin.marinas, dvyukov, glider, hpa, linux-kernel, parri.andrea,
peter, tglx, will.deacon, linux-arm-kernel
In-Reply-To: <20180724092036.GN2494@hirez.programming.kicks-ass.net>
On Tue, Jul 24, 2018 at 11:20:36AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 24, 2018 at 09:15:18AM +0200, Ingo Molnar wrote:
> >
> > * Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > > From: Peter Zijlstra <peterz@infradead.org>
> > >
> > > Mark found ldsem_cmpxchg() needed an (atomic_long_t *) cast to keep
> > > working after making the atomic_long interface type safe.
> > >
> > > Needing casts is bad form, which made me look at the code. There are no
> > > ld_semaphore::count users outside of these functions so there is no
> > > reason why it can not be an atomic_long_t in the first place, obviating
> > > the need for this cast.
> > >
> > > That also ensures the loads use atomic_long_read(), which implies (at
> > > least) READ_ONCE() in order to guarantee single-copy-atomic loads.
> > >
> > > When using atomic_long_try_cmpxchg() the ldsem_cmpxchg() wrapper gets
> > > very thin (the only difference is not changing *old on success, which
> > > most callers don't seem to care about).
> > >
> > > So rework the whole thing to use atomic_long_t and its accessors
> > > directly.
> > >
> > > While there, fixup all the horrible comment styles.
> > >
> > > Cc: Peter Hurley <peter@hurleysoftware.com>
> > > Acked-by: Will Deacon <will.deacon@arm.com>
> > > Reported-by: Mark Rutland <mark.rutland@arm.com>
> > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Ingo Molnar <mingo@kernel.org>
> > > ---
> > > drivers/tty/tty_ldsem.c | 82 ++++++++++++++++++++---------------------------
> > > include/linux/tty_ldisc.h | 4 +--
> > > 2 files changed, 37 insertions(+), 49 deletions(-)
> > >
> > > Note: Greg has queued this via the in the tty tree for v4.19, which can be seen at:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=5fd691afdf929061c391d897fa627822c3b2fd5a
> >
> > Can this patch be skipped, or do the others depend on it?
>
> IIRC it depends on it, without this patch you get build issues due to
> atomic_long_cmpxchg() getting picky about it's arguments (type safety
> improved).
Yup. Without this patch, there will be a build regression at patch 9,
when we move to generated atomic_long_*() wrappers.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v12 03/16] s390, kexec_file: drop arch_kexec_mem_walk()
From: Philipp Rudo @ 2018-07-24 9:23 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: herbert, bhe, ard.biesheuvel, catalin.marinas, bhsharma,
will.deacon, linux-kernel, heiko.carstens, dhowells, arnd,
linux-arm-kernel, kexec, schwidefsky, james.morse, dyoung, davem,
vgoyal
In-Reply-To: <20180724065759.19186-4-takahiro.akashi@linaro.org>
Hi AKASHI,
the patch looks good to me.
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Thanks
Philipp
On Tue, 24 Jul 2018 15:57:46 +0900
AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> Since s390 already knows where to locate buffers, calling
> arch_kexec_mem_walk() has no sense. So we can just drop it as kbuf->mem
> indicates this while all other architectures sets it to 0 initially.
>
> This change is a preparatory work for the next patch, where all the
> variant memory walks, either on system resource or memblock, will be
> put in one common place so that it will satisfy all the architectures'
> need.
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Cc: Baoquan He <bhe@redhat.com>
> ---
> arch/s390/kernel/machine_kexec_file.c | 10 ----------
> kernel/kexec_file.c | 4 ++++
> 2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
> index f413f57f8d20..32023b4f9dc0 100644
> --- a/arch/s390/kernel/machine_kexec_file.c
> +++ b/arch/s390/kernel/machine_kexec_file.c
> @@ -134,16 +134,6 @@ int kexec_file_add_initrd(struct kimage *image, struct s390_load_data *data,
> return ret;
> }
>
> -/*
> - * The kernel is loaded to a fixed location. Turn off kexec_locate_mem_hole
> - * and provide kbuf->mem by hand.
> - */
> -int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> - int (*func)(struct resource *, void *))
> -{
> - return 1;
> -}
> -
> int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> Elf_Shdr *section,
> const Elf_Shdr *relsec,
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 63c7ce1c0c3e..bf39df5e5bb9 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -534,6 +534,10 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> {
> int ret;
>
> + /* Arch knows where to place */
> + if (kbuf->mem)
> + return 0;
> +
> ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
>
> return ret == 1 ? 0 : -EADDRNOTAVAIL;
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCHv4 01/12] atomic/tty: Fix up atomic abuse in ldsem
From: Mark Rutland @ 2018-07-24 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724092036.GN2494@hirez.programming.kicks-ass.net>
On Tue, Jul 24, 2018 at 11:20:36AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 24, 2018 at 09:15:18AM +0200, Ingo Molnar wrote:
> >
> > * Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > > From: Peter Zijlstra <peterz@infradead.org>
> > >
> > > Mark found ldsem_cmpxchg() needed an (atomic_long_t *) cast to keep
> > > working after making the atomic_long interface type safe.
> > >
> > > Needing casts is bad form, which made me look at the code. There are no
> > > ld_semaphore::count users outside of these functions so there is no
> > > reason why it can not be an atomic_long_t in the first place, obviating
> > > the need for this cast.
> > >
> > > That also ensures the loads use atomic_long_read(), which implies (at
> > > least) READ_ONCE() in order to guarantee single-copy-atomic loads.
> > >
> > > When using atomic_long_try_cmpxchg() the ldsem_cmpxchg() wrapper gets
> > > very thin (the only difference is not changing *old on success, which
> > > most callers don't seem to care about).
> > >
> > > So rework the whole thing to use atomic_long_t and its accessors
> > > directly.
> > >
> > > While there, fixup all the horrible comment styles.
> > >
> > > Cc: Peter Hurley <peter@hurleysoftware.com>
> > > Acked-by: Will Deacon <will.deacon@arm.com>
> > > Reported-by: Mark Rutland <mark.rutland@arm.com>
> > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Ingo Molnar <mingo@kernel.org>
> > > ---
> > > drivers/tty/tty_ldsem.c | 82 ++++++++++++++++++++---------------------------
> > > include/linux/tty_ldisc.h | 4 +--
> > > 2 files changed, 37 insertions(+), 49 deletions(-)
> > >
> > > Note: Greg has queued this via the in the tty tree for v4.19, which can be seen at:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=5fd691afdf929061c391d897fa627822c3b2fd5a
> >
> > Can this patch be skipped, or do the others depend on it?
>
> IIRC it depends on it, without this patch you get build issues due to
> atomic_long_cmpxchg() getting picky about it's arguments (type safety
> improved).
Yup. Without this patch, there will be a build regression at patch 9,
when we move to generated atomic_long_*() wrappers.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v12 03/16] s390, kexec_file: drop arch_kexec_mem_walk()
From: Philipp Rudo @ 2018-07-24 9:23 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: catalin.marinas, will.deacon, dhowells, vgoyal, herbert, davem,
dyoung, bhe, arnd, schwidefsky, heiko.carstens, ard.biesheuvel,
bhsharma, kexec, linux-kernel, james.morse, linux-arm-kernel
In-Reply-To: <20180724065759.19186-4-takahiro.akashi@linaro.org>
Hi AKASHI,
the patch looks good to me.
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Thanks
Philipp
On Tue, 24 Jul 2018 15:57:46 +0900
AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> Since s390 already knows where to locate buffers, calling
> arch_kexec_mem_walk() has no sense. So we can just drop it as kbuf->mem
> indicates this while all other architectures sets it to 0 initially.
>
> This change is a preparatory work for the next patch, where all the
> variant memory walks, either on system resource or memblock, will be
> put in one common place so that it will satisfy all the architectures'
> need.
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Cc: Baoquan He <bhe@redhat.com>
> ---
> arch/s390/kernel/machine_kexec_file.c | 10 ----------
> kernel/kexec_file.c | 4 ++++
> 2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
> index f413f57f8d20..32023b4f9dc0 100644
> --- a/arch/s390/kernel/machine_kexec_file.c
> +++ b/arch/s390/kernel/machine_kexec_file.c
> @@ -134,16 +134,6 @@ int kexec_file_add_initrd(struct kimage *image, struct s390_load_data *data,
> return ret;
> }
>
> -/*
> - * The kernel is loaded to a fixed location. Turn off kexec_locate_mem_hole
> - * and provide kbuf->mem by hand.
> - */
> -int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> - int (*func)(struct resource *, void *))
> -{
> - return 1;
> -}
> -
> int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> Elf_Shdr *section,
> const Elf_Shdr *relsec,
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 63c7ce1c0c3e..bf39df5e5bb9 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -534,6 +534,10 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> {
> int ret;
>
> + /* Arch knows where to place */
> + if (kbuf->mem)
> + return 0;
> +
> ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
>
> return ret == 1 ? 0 : -EADDRNOTAVAIL;
^ permalink raw reply
* Re: [PATCH] m68k/mac: Rework patch "use time64_t in RTC handling"
From: Arnd Bergmann @ 2018-07-24 9:23 UTC (permalink / raw)
To: Finn Thain; +Cc: Geert Uytterhoeven, linux-m68k, Linux Kernel Mailing List
In-Reply-To: <58f371f95c10969bacff4d5bc393ff0f0c6102fb.1532415410.git.fthain@telegraphics.com.au>
On Tue, Jul 24, 2018 at 9:07 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> This addresses the issues arising from commit 324caa29cd04
> ("m68k: mac: use time64_t in RTC handling").
>
> Adopt __u32 for the union in via_read_time(), consistent with changes
> to via_write_time().
>
> Use low_32_bits() in via_write_time(), consistent with changes to
> pmu_write_time() and cuda_write_time().
>
> Have via_read_time() return a time64_t, consistent with changes to
> pmu_read_time and cuda_read_time().
>
> Drop the pointless wraparound conditional in via_read_time().
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Thanks for fixing it up!
^ permalink raw reply
* [PATCH v12 03/16] s390, kexec_file: drop arch_kexec_mem_walk()
From: Philipp Rudo @ 2018-07-24 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724065759.19186-4-takahiro.akashi@linaro.org>
Hi AKASHI,
the patch looks good to me.
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Thanks
Philipp
On Tue, 24 Jul 2018 15:57:46 +0900
AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> Since s390 already knows where to locate buffers, calling
> arch_kexec_mem_walk() has no sense. So we can just drop it as kbuf->mem
> indicates this while all other architectures sets it to 0 initially.
>
> This change is a preparatory work for the next patch, where all the
> variant memory walks, either on system resource or memblock, will be
> put in one common place so that it will satisfy all the architectures'
> need.
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Cc: Baoquan He <bhe@redhat.com>
> ---
> arch/s390/kernel/machine_kexec_file.c | 10 ----------
> kernel/kexec_file.c | 4 ++++
> 2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
> index f413f57f8d20..32023b4f9dc0 100644
> --- a/arch/s390/kernel/machine_kexec_file.c
> +++ b/arch/s390/kernel/machine_kexec_file.c
> @@ -134,16 +134,6 @@ int kexec_file_add_initrd(struct kimage *image, struct s390_load_data *data,
> return ret;
> }
>
> -/*
> - * The kernel is loaded to a fixed location. Turn off kexec_locate_mem_hole
> - * and provide kbuf->mem by hand.
> - */
> -int arch_kexec_walk_mem(struct kexec_buf *kbuf,
> - int (*func)(struct resource *, void *))
> -{
> - return 1;
> -}
> -
> int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
> Elf_Shdr *section,
> const Elf_Shdr *relsec,
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 63c7ce1c0c3e..bf39df5e5bb9 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -534,6 +534,10 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> {
> int ret;
>
> + /* Arch knows where to place */
> + if (kbuf->mem)
> + return 0;
> +
> ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
>
> return ret == 1 ? 0 : -EADDRNOTAVAIL;
^ permalink raw reply
* Re: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20 bds for one transfer
From: Lucas Stach @ 2018-07-24 9:22 UTC (permalink / raw)
To: Robin Gong, vkoul@kernel.org, dan.j.williams@intel.com,
s.hauer@pengutronix.de, linux@armlinux.org.uk
Cc: dmaengine@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DB6PR04MB322323354B2184421502FC5889560@DB6PR04MB3223.eurprd04.prod.outlook.com>
Am Montag, den 23.07.2018, 13:55 +0000 schrieb Robin Gong:
> > -----Original Message-----
> > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > Sent: 2018年7月23日 18:54
> > To: Robin Gong <yibin.gong@nxp.com>; vkoul@kernel.org;
> > dan.j.williams@intel.com; s.hauer@pengutronix.de; linux@armlinux.or
> > g.uk
> > Cc: dmaengine@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> > kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20
> > bds for one
> > transfer
> >
> > Am Dienstag, den 24.07.2018, 01:46 +0800 schrieb Robin Gong:
> > > If multi-bds used in one transfer, all bds should be consisten
> > > memory.To easily follow it, enlarge the dma pool size into 20
> > > bds, and
> > > it will report error if the number of bds is over than 20. For
> > > dmatest, the max count for single transfer is NUM_BD *
> >
> > SDMA_BD_MAX_CNT
> > > = 20 * 65535 = ~1.28MB.
> >
> > Both the commit message and the comment need a lot more care to
> > actually
> > tell what this commit is trying to achieve. Currently I don't
> > follow at all. What
> > does "consisten" mean? Do you mean BDs should be contiguous in
> > memory?
>
> Yes, BDs should be contiguous one by one in memory.
Okay, but this isn't what the code change does. By increasing the size
parameter of the dma pool you just allocate 20 times as much memory as
needed for each BD. So actually the BDs end up being very non-
contiguous in memory as there are now holes of 19 BD sizes between the
start of each BD.
So something isn't right with this change.
Regards,
Lucas
> >
> > What do you gain by over-allocating each BD by a factor of 20?
>
> I guess dma_pool_alloc will return error in such case, and then cause
> dma setup
> transfer failure.
> >
> > Regards,
> > Lucas
> >
> > > Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> > > ---
> > > drivers/dma/imx-sdma.c | 17 ++++++++++++++++-
> > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> > > index
> > > b4ec2d2..5973489 100644
> > > --- a/drivers/dma/imx-sdma.c
> > > +++ b/drivers/dma/imx-sdma.c
> > > @@ -298,6 +298,15 @@ struct sdma_context_data {
> > > > u32 scratch7;
> > >
> > > } __attribute__ ((packed));
> > >
> > > +/*
> > > + * All bds in one transfer should be consitent on SDMA. To
> > > easily
> > > +follow it,just
> > > + * set the dma pool size as the enough bds. For example, in
> > > dmatest
> > > +case, the
> > > + * max 20 bds means the max for single transfer is NUM_BD *
> > > +SDMA_BD_MAX_CNT = 20
> > > + * * 65535 = ~1.28MB. 20 bds supposed to be enough basically.If
> > > it's
> > > +still not
> > > + * enough in some specific cases, enlarge it here.Warning
> > > message
> > > +would also
> > > + * appear if the bd numbers is over than 20.
> > > + */
> > > +#define NUM_BD 20
> > >
> > > struct sdma_engine;
> > >
> > > @@ -1273,7 +1282,7 @@ static int sdma_alloc_chan_resources(struct
> > > dma_chan *chan)
> > > > goto disable_clk_ahb;
> > > > sdmac->bd_pool = dma_pool_create("bd_pool", chan-
> > > > >device->dev,
> > > > - sizeof(struct
> > > > sdma_buffer_descriptor),
> > > > + NUM_BD * sizeof(struct
> > > > sdma_buffer_descriptor),
> > > > 32, 0);
> > > > return 0;
> > >
> > > @@ -1314,6 +1323,12 @@ static struct sdma_desc
> > > *sdma_transfer_init(struct sdma_channel *sdmac,
> > > {
> > > > struct sdma_desc *desc;
> > > > + if (bds > NUM_BD) {
> > > > + dev_err(sdmac->sdma->dev, "%d bds exceed the
> > > > max %d\n",
> > > > + bds, NUM_BD);
> > > > + goto err_out;
> > > > + }
> > >
> > > +
> > > > desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
> > > > if (!desc)
> > > > goto err_out;
^ permalink raw reply
* [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20 bds for one transfer
From: Lucas Stach @ 2018-07-24 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR04MB322323354B2184421502FC5889560@DB6PR04MB3223.eurprd04.prod.outlook.com>
Am Montag, den 23.07.2018, 13:55 +0000 schrieb Robin Gong:
> > -----Original Message-----
> > From: Lucas Stach [mailto:l.stach at pengutronix.de]
> > Sent: 2018?7?23? 18:54
> > To: Robin Gong <yibin.gong@nxp.com>; vkoul at kernel.org;
> > dan.j.williams at intel.com; s.hauer at pengutronix.de; linux at armlinux.or
> > g.uk
> > Cc: dmaengine at vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> > kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> > linux-kernel at vger.kernel.org
> > Subject: Re: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20
> > bds for one
> > transfer
> >
> > Am Dienstag, den 24.07.2018, 01:46 +0800 schrieb Robin Gong:
> > > If multi-bds used in one transfer, all bds should be consisten
> > > memory.To easily follow it, enlarge the dma pool size into 20
> > > bds, and
> > > it will report error if the number of bds is over than 20. For
> > > dmatest, the max count for single transfer is NUM_BD *
> >
> > SDMA_BD_MAX_CNT
> > > = 20 * 65535 = ~1.28MB.
> >
> > Both the commit message and the comment need a lot more care to
> > actually
> > tell what this commit is trying to achieve. Currently I don't
> > follow at all. What
> > does "consisten" mean? Do you mean BDs should be contiguous in
> > memory?
>
> Yes, BDs should be contiguous??one by one in memory.
Okay, but this isn't what the code change does. By increasing the size
parameter of the dma pool you just allocate 20 times as much memory as
needed for each BD. So actually the BDs end up being very non-
contiguous in memory as there are now holes of 19 BD sizes between the
start of each BD.
So something isn't right with this change.
Regards,
Lucas
> >
> > What do you gain by over-allocating each BD by a factor of 20?
>
> I guess dma_pool_alloc will return error in such case, and then cause
> dma setup
> transfer failure.
> >
> > Regards,
> > Lucas
> >
> > > Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> > > ---
> > > ?drivers/dma/imx-sdma.c | 17 ++++++++++++++++-
> > > ?1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> > > index
> > > b4ec2d2..5973489 100644
> > > --- a/drivers/dma/imx-sdma.c
> > > +++ b/drivers/dma/imx-sdma.c
> > > @@ -298,6 +298,15 @@ struct sdma_context_data {
> > > > ? u32??scratch7;
> > >
> > > ?} __attribute__ ((packed));
> > >
> > > +/*
> > > + * All bds in one transfer should be consitent on SDMA. To
> > > easily
> > > +follow it,just
> > > + * set the dma pool size as the enough bds. For example, in
> > > dmatest
> > > +case, the
> > > + * max 20 bds means the max for single transfer is NUM_BD *
> > > +SDMA_BD_MAX_CNT = 20
> > > + * * 65535 = ~1.28MB. 20 bds supposed to be enough basically.If
> > > it's
> > > +still not
> > > + * enough in some specific cases, enlarge it here.Warning
> > > message
> > > +would also
> > > + * appear if the bd numbers is over than 20.
> > > + */
> > > +#define NUM_BD 20
> > >
> > > ?struct sdma_engine;
> > >
> > > @@ -1273,7 +1282,7 @@ static int sdma_alloc_chan_resources(struct
> > > dma_chan *chan)
> > > > ? goto disable_clk_ahb;
> > > > ? sdmac->bd_pool = dma_pool_create("bd_pool", chan-
> > > > >device->dev,
> > > > - sizeof(struct
> > > > sdma_buffer_descriptor),
> > > > + NUM_BD * sizeof(struct
> > > > sdma_buffer_descriptor),
> > > > ? 32, 0);
> > > > ? return 0;
> > >
> > > @@ -1314,6 +1323,12 @@ static struct sdma_desc
> > > *sdma_transfer_init(struct sdma_channel *sdmac,
> > > ?{
> > > > ? struct sdma_desc *desc;
> > > > + if (bds > NUM_BD) {
> > > > + dev_err(sdmac->sdma->dev, "%d bds exceed the
> > > > max %d\n",
> > > > + bds, NUM_BD);
> > > > + goto err_out;
> > > > + }
> > >
> > > +
> > > > ? desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
> > > > ? if (!desc)
> > > > ? goto err_out;
^ permalink raw reply
* [v3,3/3] dmaengine: imx-sdma: allocate max 20 bds for one transfer
From: Lucas Stach @ 2018-07-24 9:22 UTC (permalink / raw)
To: Robin Gong, vkoul@kernel.org, dan.j.williams@intel.com,
s.hauer@pengutronix.de, linux@armlinux.org.uk
Cc: dmaengine@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Am Montag, den 23.07.2018, 13:55 +0000 schrieb Robin Gong:
> > -----Original Message-----
> > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > Sent: 2018年7月23日 18:54
> > To: Robin Gong <yibin.gong@nxp.com>; vkoul@kernel.org;
> > dan.j.williams@intel.com; s.hauer@pengutronix.de; linux@armlinux.or
> > g.uk
> > Cc: dmaengine@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> > kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20
> > bds for one
> > transfer
> >
> > Am Dienstag, den 24.07.2018, 01:46 +0800 schrieb Robin Gong:
> > > If multi-bds used in one transfer, all bds should be consisten
> > > memory.To easily follow it, enlarge the dma pool size into 20
> > > bds, and
> > > it will report error if the number of bds is over than 20. For
> > > dmatest, the max count for single transfer is NUM_BD *
> >
> > SDMA_BD_MAX_CNT
> > > = 20 * 65535 = ~1.28MB.
> >
> > Both the commit message and the comment need a lot more care to
> > actually
> > tell what this commit is trying to achieve. Currently I don't
> > follow at all. What
> > does "consisten" mean? Do you mean BDs should be contiguous in
> > memory?
>
> Yes, BDs should be contiguous one by one in memory.
Okay, but this isn't what the code change does. By increasing the size
parameter of the dma pool you just allocate 20 times as much memory as
needed for each BD. So actually the BDs end up being very non-
contiguous in memory as there are now holes of 19 BD sizes between the
start of each BD.
So something isn't right with this change.
Regards,
Lucas
> >
> > What do you gain by over-allocating each BD by a factor of 20?
>
> I guess dma_pool_alloc will return error in such case, and then cause
> dma setup
> transfer failure.
> >
> > Regards,
> > Lucas
> >
> > > Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> > > ---
> > > drivers/dma/imx-sdma.c | 17 ++++++++++++++++-
> > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> > > index
> > > b4ec2d2..5973489 100644
> > > --- a/drivers/dma/imx-sdma.c
> > > +++ b/drivers/dma/imx-sdma.c
> > > @@ -298,6 +298,15 @@ struct sdma_context_data {
> > > > u32 scratch7;
> > >
> > > } __attribute__ ((packed));
> > >
> > > +/*
> > > + * All bds in one transfer should be consitent on SDMA. To
> > > easily
> > > +follow it,just
> > > + * set the dma pool size as the enough bds. For example, in
> > > dmatest
> > > +case, the
> > > + * max 20 bds means the max for single transfer is NUM_BD *
> > > +SDMA_BD_MAX_CNT = 20
> > > + * * 65535 = ~1.28MB. 20 bds supposed to be enough basically.If
> > > it's
> > > +still not
> > > + * enough in some specific cases, enlarge it here.Warning
> > > message
> > > +would also
> > > + * appear if the bd numbers is over than 20.
> > > + */
> > > +#define NUM_BD 20
> > >
> > > struct sdma_engine;
> > >
> > > @@ -1273,7 +1282,7 @@ static int sdma_alloc_chan_resources(struct
> > > dma_chan *chan)
> > > > goto disable_clk_ahb;
> > > > sdmac->bd_pool = dma_pool_create("bd_pool", chan-
> > > > >device->dev,
> > > > - sizeof(struct
> > > > sdma_buffer_descriptor),
> > > > + NUM_BD * sizeof(struct
> > > > sdma_buffer_descriptor),
> > > > 32, 0);
> > > > return 0;
> > >
> > > @@ -1314,6 +1323,12 @@ static struct sdma_desc
> > > *sdma_transfer_init(struct sdma_channel *sdmac,
> > > {
> > > > struct sdma_desc *desc;
> > > > + if (bds > NUM_BD) {
> > > > + dev_err(sdmac->sdma->dev, "%d bds exceed the
> > > > max %d\n",
> > > > + bds, NUM_BD);
> > > > + goto err_out;
> > > > + }
> > >
> > > +
> > > > desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
> > > > if (!desc)
> > > > goto err_out;
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-3.0 2/4] migration: disallow recovery for release-ram
From: Juan Quintela @ 2018-07-24 9:21 UTC (permalink / raw)
To: Peter Xu; +Cc: qemu-devel, Dr . David Alan Gilbert
In-Reply-To: <20180723123305.24792-3-peterx@redhat.com>
Peter Xu <peterx@redhat.com> wrote:
> Postcopy recovery won't work well with release-ram capability since
> release-ram will drop the page buffer as long as the page is put into
> the send buffer. So if there is a network failure happened, any page
> buffers that have not yet reached the destination VM but have already
> been sent from the source VM will be lost forever. Let's refuse the
> client from resuming such a postcopy migration. Luckily release-ram was
> designed to only be used when src and destination VMs are on the same
> host, so it should be fine.
>
> Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
I wonder if we should have a FAQ somewhere and point an URL to there.
^ permalink raw reply
* selftests: bpf: test_progs: deadlock at trace_call_bpf
From: Naresh Kamboju @ 2018-07-24 9:21 UTC (permalink / raw)
To: netdev, ast, Daniel Borkmann, rostedt
Cc: open list, open list:KERNEL SELFTEST FRAMEWORK
Deadlock warning on x86 machine while testing selftests: bpf:
test_progs and running linux next 4.18.0-rc3-next-20180705 and still
happening on 4.18.0-rc5-next-20180720.
Any one noticed this kernel warning about deadlock ?
selftests: bpf: test_progs
libbpf: incorrect bpf_call opcode
libbpf: incorrect bpf_call opcode
test_pkt_access:FAIL:ipv4 err 0 errno 2 retval 0 duration 126
test_pkt_access:FAIL:ipv6 err 0 errno 2 retval 0 duration 115
test_xdp:FAIL:ipv4 err 0 errno 2 retval 3 size 74
test_xdp:FAIL:ipv6 err 0 errno 2 retval 3 size 114
test_xdp_adjust_tail:FAIL:ipv4 err 0 errno 2 retval 1 size 54
test_xdp_adjust_tail:FAIL:ipv6 err 0 errno 2 retval 3 siz[ 69.901655]
[ 69.903862] ========================================================
[ 69.910213] WARNING: possible irq lock inversion dependency detected
[ 69.916559] 4.18.0-rc3-next-20180705 #1 Not tainted
[ 69.921428] --------------------------------------------------------
[ 69.927774] dd/2928 just changed the state of lock:
[ 69.932643] 0000000022eeb38d (&head->lock){+...}, at:
pcpu_freelist_push+0x28/0x50
[ 69.940208] but this lock was taken by another, HARDIRQ-safe lock
in the past:
[ 69.947420] (&rq->lock){-.-.}
[ 69.947421]
[ 69.947421]
[ 69.947421] and interrupts could create inverse lock ordering between them.
[ 69.947421]
[ 69.961842]
[ 69.961842] other info that might help us debug this:
[ 69.968357] Possible interrupt unsafe locking scenario:
[ 69.968357]
[ 69.975136] CPU0 CPU1
[ 69.979659] ---- ----
[ 69.984184] lock(&head->lock);
[ 69.987406] local_irq_disable();
[ 69.993319] lock(&rq->lock);
[ 69.998882] lock(&head->lock);
[ 70.004618] <Interrupt>
[ 70.007235] lock(&rq->lock);
[ 70.010461]
[ 70.010461] *** DEADLOCK ***
[ 70.010461]
[ 70.016372] 1 lock held by dd/2928:
[ 70.019856] #0: 00000000ab9293c8 (rcu_read_lock){....}, at:
trace_call_bpf+0x37/0x1d0
[ 70.027768]
[ 70.027768] the shortest dependencies between 2nd lock and 1st lock:
[ 70.035586] -> (&rq->lock){-.-.} ops: 1401365 {
[ 70.040204] IN-HARDIRQ-W at:
[ 70.043428] lock_acquire+0xd5/0x1c0
[ 70.048820] _raw_spin_lock+0x2f/0x40
[ 70.054299] scheduler_tick+0x51/0xf0
[ 70.059781] update_process_times+0x47/0x60
[ 70.065779] tick_periodic+0x2b/0xc0
[ 70.071171] tick_handle_periodic+0x25/0x70
[ 70.077168] timer_interrupt+0x15/0x20
[ 70.082731] __handle_irq_event_percpu+0x48/0x320
[ 70.089250] handle_irq_event_percpu+0x32/0x80
[ 70.095505] handle_irq_event+0x39/0x60
[ 70.101157] handle_level_irq+0x7f/0x100
[ 70.106893] handle_irq+0x6f/0x110
[ 70.112112] do_IRQ+0x5c/0x110
[ 70.116982] ret_from_intr+0x0/0x1d
[ 70.122286] _raw_spin_unlock_irqrestore+0x38/0x50
[ 70.128891] __setup_irq+0x45d/0x700
[ 70.134281] setup_irq+0x4c/0x90
[ 70.139324] hpet_time_init+0x25/0x37
[ 70.144803] x86_late_time_init+0xf/0x1c
[ 70.150538] start_kernel+0x40c/0x4ca
[ 70.156017] x86_64_start_reservations+0x24/0x26
[ 70.162445] x86_64_start_kernel+0x6f/0x72
[ 70.168357] secondary_startup_64+0xa4/0xb0
[ 70.174356] IN-SOFTIRQ-W at:
[ 70.177578] lock_acquire+0xd5/0x1c0
[ 70.182970] _raw_spin_lock+0x2f/0x40
[ 70.188448] try_to_wake_up+0x31b/0x540
[ 70.194097] wake_up_process+0x15/0x20
[ 70.199661] swake_up_locked+0x24/0x40
[ 70.205226] swake_up_one+0x1f/0x30
[ 70.210530] rcu_gp_kthread_wake+0x3b/0x40
[ 70.216441] rcu_accelerate_cbs_unlocked+0x9c/0xe0
[ 70.223048] rcu_process_callbacks+0x111/0x10c0
[ 70.229396] __do_softirq+0xbf/0x493
[ 70.234788] irq_exit+0xc3/0xd0
[ 70.239743] smp_apic_timer_interrupt+0x93/0x2a0
[ 70.246176] apic_timer_interrupt+0xf/0x20
[ 70.252084] console_unlock+0x4e8/0x620
[ 70.257737] vprintk_emit+0x254/0x430
[ 70.263214] vprintk_default+0x1f/0x30
[ 70.268776] vprintk_func+0x27/0x60
[ 70.274082] printk+0x52/0x6e
[ 70.278864] native_cpu_up+0x71b/0x7a0
[ 70.284431] bringup_cpu+0x2a/0xb0
[ 70.289648] cpuhp_invoke_callback+0xb2/0xb20
[ 70.295818] _cpu_up+0xae/0x160
[ 70.300776] do_cpu_up+0x8d/0xb0
[ 70.305818] cpu_up+0x13/0x20
[ 70.310602] smp_init+0x67/0xc4
[ 70.315559] kernel_init_freeable+0x134/0x259
[ 70.321731] kernel_init+0xe/0x110
[ 70.326947] ret_from_fork+0x3a/0x50
[ 70.332339] INITIAL USE at:
[ 70.335477] lock_acquire+0xd5/0x1c0
[ 70.340780] _raw_spin_lock_irqsave+0x3a/0x50
[ 70.346864] rq_attach_root+0x1b/0xc0
[ 70.352255] sched_init+0x310/0x432
[ 70.357472] start_kernel+0x26e/0x4ca
[ 70.362861] x86_64_start_reservations+0x24/0x26
[ 70.369207] x86_64_start_kernel+0x6f/0x72
[ 70.375048] secondary_startup_64+0xa4/0xb0
[ 70.380958] }
[ 70.382710] ... key at: [<ffffffff8716faf8>] __key.69482+0x0/0x8
[ 70.389310] ... acquired at:
[ 70.392364] _raw_spin_lock+0x2f/0x40
[ 70.396192] pcpu_freelist_pop+0x7a/0xd0
[ 70.400286] bpf_get_stackid+0x1ca/0x470
[ 70.404383] bpf_get_stackid_tp+0x11/0x20
[ 70.408559] ___bpf_prog_run+0x7f2/0x1090
[ 70.412739] __bpf_prog_run32+0x39/0x50
[ 70.416742] trace_call_bpf+0xc8/0x1d0
[ 70.420659] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.425444] perf_trace_sched_switch+0x116/0x190
[ 70.430227] __schedule+0x6d8/0xa20
[ 70.433883] schedule+0x3d/0x90
[ 70.437194] worker_thread+0xd0/0x410
[ 70.441025] kthread+0x10d/0x140
[ 70.444424] ret_from_fork+0x3a/0x50
[ 70.448165]
[ 70.449658] -> (&head->lock){+...} ops: 61660 {
[ 70.454181] HARDIRQ-ON-W at:
[ 70.457319] lock_acquire+0xd5/0x1c0
[ 70.462536] _raw_spin_lock+0x2f/0x40
[ 70.467841] pcpu_freelist_push+0x28/0x50
[ 70.473492] bpf_get_stackid+0x43a/0x470
[ 70.479054] bpf_get_stackid_tp+0x11/0x20
[ 70.484724] ___bpf_prog_run+0x7f2/0x1090
[ 70.490372] __bpf_prog_run32+0x39/0x50
[ 70.495852] trace_call_bpf+0xc8/0x1d0
[ 70.501243] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.507500] perf_trace_urandom_read+0xbf/0x100
[ 70.513670] urandom_read+0x1ce/0x340
[ 70.518975] __vfs_read+0x37/0x160
[ 70.524027] vfs_read+0xa8/0x150
[ 70.528898] ksys_read+0x58/0xc0
[ 70.533766] __x64_sys_read+0x1a/0x20
[ 70.539092] do_syscall_64+0x4f/0x190
[ 70.544401] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.551092] INITIAL USE at:
[ 70.554143] lock_acquire+0xd5/0x1c0
[ 70.559272] _raw_spin_lock+0x2f/0x40
[ 70.564491] pcpu_freelist_populate+0xb6/0x110
[ 70.570489] htab_map_alloc+0x3b6/0x4c0
[ 70.575878] map_create+0xf0/0x370
[ 70.580836] __x64_sys_bpf+0x10b/0x260
[ 70.586138] do_syscall_64+0x4f/0x190
[ 70.591356] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.597960] }
[ 70.599624] ... key at: [<ffffffff87d4c5a0>] __key.11024+0x0/0x8
[ 70.606142] ... acquired at:
[ 70.609104] mark_lock+0x392/0x570
[ 70.612676] __lock_acquire+0x5cd/0x13c0
[ 70.616767] lock_acquire+0xd5/0x1c0
[ 70.620511] _raw_spin_lock+0x2f/0x40
[ 70.624342] pcpu_freelist_push+0x28/0x50
[ 70.628519] bpf_get_stackid+0x43a/0x470
[ 70.632610] bpf_get_stackid_tp+0x11/0x20
[ 70.636785] ___bpf_prog_run+0x7f2/0x1090
[ 70.640965] __bpf_prog_run32+0x39/0x50
[ 70.644969] trace_call_bpf+0xc8/0x1d0
[ 70.648886] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.653668] perf_trace_urandom_read+0xbf/0x100
[ 70.658366] urandom_read+0x1ce/0x340
[ 70.662199] __vfs_read+0x37/0x160
[ 70.665768] vfs_read+0xa8/0x150
[ 70.669166] ksys_read+0x58/0xc0
[ 70.672562] __x64_sys_read+0x1a/0x20
[ 70.676393] do_syscall_64+0x4f/0x190
[ 70.680223] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.685440]
[ 70.686933]
[ 70.686933] stack backtrace:
[ 70.691283] CPU: 3 PID: 2928 Comm: dd Not tainted 4.18.0-rc3-next-20180705 #1
[ 70.698405] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 70.705875] Call Trace:
[ 70.708321] dump_stack+0x68/0x95
[ 70.711631] print_irq_inversion_bug.part.41+0x1a5/0x1b1
[ 70.716935] check_usage_backwards+0x14b/0x160
[ 70.721374] mark_lock+0x392/0x570
[ 70.724771] ? mark_lock+0x392/0x570
[ 70.728340] ? print_shortest_lock_dependencies+0x1a0/0x1a0
[ 70.733904] __lock_acquire+0x5cd/0x13c0
[ 70.737823] ? find_get_entry+0x1a2/0x2f0
[ 70.741825] lock_acquire+0xd5/0x1c0
[ 70.745397] ? lock_acquire+0xd5/0x1c0
[ 70.749141] ? pcpu_freelist_push+0x28/0x50
[ 70.753317] _raw_spin_lock+0x2f/0x40
[ 70.756974] ? pcpu_freelist_push+0x28/0x50
[ 70.761153] pcpu_freelist_push+0x28/0x50
[ 70.765156] bpf_get_stackid+0x43a/0x470
[ 70.769073] bpf_get_stackid_tp+0x11/0x20
[ 70.773077] ___bpf_prog_run+0x7f2/0x1090
[ 70.777083] __bpf_prog_run32+0x39/0x50
[ 70.780912] ? lock_acquire+0xd5/0x1c0
[ 70.784656] trace_call_bpf+0xc8/0x1d0
[ 70.788399] perf_trace_run_bpf_submit+0x42/0xb0
[ 70.793013] perf_trace_urandom_read+0xbf/0x100
[ 70.797544] urandom_read+0x1ce/0x340
[ 70.801202] __vfs_read+0x37/0x160
[ 70.804598] ? security_file_permission+0x8d/0xb0
[ 70.809297] ? security_file_permission+0x8d/0xb0
[ 70.813993] vfs_read+0xa8/0x150
[ 70.817218] ksys_read+0x58/0xc0
[ 70.820442] __x64_sys_read+0x1a/0x20
[ 70.824106] do_syscall_64+0x4f/0x190
[ 70.827764] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 70.832807] RIP: 0033:0x7f302526f160
[ 70.836378] Code: b6 fe ff ff 48 8d 3d 97 b1 08 00 48 83 ec 08 e8
66 d3 01 00 66 0f 1f 44 00 00 83 3d e9 15 2c 00 00 75 10 b8 00 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 7e 94 01 00 48 89
04 24
[ 70.855253] RSP: 002b:00007fff096fd4e8 EFLAGS: 00000246 ORIG_RAX:
0000000000000000
[ 70.862812] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f302526f160
[ 70.869935] RDX: 0000000000000200 RSI: 000000000070f000 RDI: 0000000000000000
[ 70.877060] RBP: 0000000000000200 R08: 000000000070f000 R09: 0000000000711060
[ 70.884183] R10: 0000000000000871 R11: 0000000000000246 R12: 000000000070f000
[ 70.891306] R13: 0000000000000000 R14: 0000000000000200 R15: 0000000000000000
e 54
test_l4lb:FAIL:ipv4 err 0 errno 2 retval 7 size 54 magic 1234
Full kernel selftest test log,
https://lkft.validation.linaro.org/scheduler/job/314724#L2142
Best regards
Naresh Kamboju
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.