Re: [RFC 13/20] mm/tlb: introduce tlb_start_ptes() and tlb_end_ptes()
On Sat, 30. Jan 16:11, Nadav Amit wrote:
> From: Nadav Amit
>
> Introduce tlb_start_ptes() and tlb_end_ptes() which would be called
> before and after PTEs are updated and TLB flushes are deferred. This
> will be later be used for fine granualrity deferred TLB flushing
> detection.
>
> In the meanwhile, move flush_tlb_batched_pending() into
> tlb_start_ptes(). It was not called from mapping_dirty_helpers by
> wp_pte() and clean_record_pte(), which might be a bug.
>
> No additional functional change is intended.
>
> Signed-off-by: Nadav Amit
> Cc: Andrea Arcangeli
> Cc: Andrew Morton
> Cc: Andy Lutomirski
> Cc: Dave Hansen
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Yu Zhao
> Cc: Nick Piggin
> Cc: x...@kernel.org
> ---
> fs/proc/task_mmu.c | 2 ++
> include/asm-generic/tlb.h | 18 ++
> mm/madvise.c | 6 --
> mm/mapping_dirty_helpers.c | 15 +--
> mm/memory.c| 2 ++
> mm/mprotect.c | 3 ++-
> 6 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 4cd048ffa0f6..d0cce961fa5c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1168,6 +1168,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> long addr,
> return 0;
>
> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> + tlb_start_ptes(>tlb);
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
>
> @@ -1190,6 +1191,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> long addr,
> tlb_flush_pte_range(>tlb, addr, PAGE_SIZE);
> ClearPageReferenced(page);
> }
> + tlb_end_ptes(>tlb);
> pte_unmap_unlock(pte - 1, ptl);
> cond_resched();
> return 0;
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index 041be2ef4426..10690763090a 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -58,6 +58,11 @@
> *Defaults to flushing at tlb_end_vma() to reset the range; helps when
> *there's large holes between the VMAs.
> *
> + * - tlb_start_ptes() / tlb_end_ptes; makr the start / end of PTEs change.
Hello Nadav,
short nid makr/mark
Damian
> + *
> + *Does internal accounting to allow fine(r) granularity checks for
> + *pte_accessible() on certain configuration.
> + *
> * - tlb_remove_table()
> *
> *tlb_remove_table() is the basic primitive to free page-table
> directories
> @@ -373,6 +378,10 @@ static inline void tlb_flush(struct mmu_gather *tlb)
> flush_tlb_range(tlb->vma, tlb->start, tlb->end);
> }
> }
> +#endif
> +
> +#if __is_defined(tlb_flush) ||
> \
> + IS_ENABLED(CONFIG_ARCH_WANT_AGGRESSIVE_TLB_FLUSH_BATCHING)
>
> static inline void
> tlb_update_vma(struct mmu_gather *tlb, struct vm_area_struct *vma)
> @@ -523,6 +532,15 @@ static inline void mark_mm_tlb_gen_done(struct mm_struct
> *mm, u64 gen)
>
> #endif /* CONFIG_ARCH_HAS_TLB_GENERATIONS */
>
> +#define tlb_start_ptes(tlb) \
> + do {\
> + struct mmu_gather *_tlb = (tlb);\
> + \
> + flush_tlb_batched_pending(_tlb->mm);\
> + } while (0)
> +
> +static inline void tlb_end_ptes(struct mmu_gather *tlb) { }
> +
> /*
> * tlb_flush_{pte|pmd|pud|p4d}_range() adjust the tlb->start and tlb->end,
> * and set corresponding cleared_*.
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 0938fd3ad228..932c1c2eb9a3 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -392,7 +392,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> #endif
> tlb_change_page_size(tlb, PAGE_SIZE);
> orig_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
> arch_enter_lazy_mmu_mode();
> for (; addr < end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
> @@ -468,6 +468,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> }
>
> arch_leave_lazy_mmu_mode();
> + tlb_end_ptes(tlb);
> pte_unmap_unlock(orig_pte, ptl);
> if (pageout)
> reclaim_pages(_list);
> @@ -588,7 +589,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
Re: [RFC 13/20] mm/tlb: introduce tlb_start_ptes() and tlb_end_ptes()
On Sat, 30. Jan 16:11, Nadav Amit wrote:
> From: Nadav Amit
>
> Introduce tlb_start_ptes() and tlb_end_ptes() which would be called
> before and after PTEs are updated and TLB flushes are deferred. This
> will be later be used for fine granualrity deferred TLB flushing
> detection.
>
> In the meanwhile, move flush_tlb_batched_pending() into
> tlb_start_ptes(). It was not called from mapping_dirty_helpers by
> wp_pte() and clean_record_pte(), which might be a bug.
>
> No additional functional change is intended.
>
> Signed-off-by: Nadav Amit
> Cc: Andrea Arcangeli
> Cc: Andrew Morton
> Cc: Andy Lutomirski
> Cc: Dave Hansen
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Yu Zhao
> Cc: Nick Piggin
> Cc: x...@kernel.org
> ---
> fs/proc/task_mmu.c | 2 ++
> include/asm-generic/tlb.h | 18 ++
> mm/madvise.c | 6 --
> mm/mapping_dirty_helpers.c | 15 +--
> mm/memory.c| 2 ++
> mm/mprotect.c | 3 ++-
> 6 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 4cd048ffa0f6..d0cce961fa5c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1168,6 +1168,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> long addr,
> return 0;
>
> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> + tlb_start_ptes(>tlb);
> for (; addr != end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
>
> @@ -1190,6 +1191,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned
> long addr,
> tlb_flush_pte_range(>tlb, addr, PAGE_SIZE);
> ClearPageReferenced(page);
> }
> + tlb_end_ptes(>tlb);
> pte_unmap_unlock(pte - 1, ptl);
> cond_resched();
> return 0;
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index 041be2ef4426..10690763090a 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -58,6 +58,11 @@
> *Defaults to flushing at tlb_end_vma() to reset the range; helps when
> *there's large holes between the VMAs.
> *
> + * - tlb_start_ptes() / tlb_end_ptes; makr the start / end of PTEs change.
Hello Nadav,
short nid makr/mark
Damian
> + *
> + *Does internal accounting to allow fine(r) granularity checks for
> + *pte_accessible() on certain configuration.
> + *
> * - tlb_remove_table()
> *
> *tlb_remove_table() is the basic primitive to free page-table
> directories
> @@ -373,6 +378,10 @@ static inline void tlb_flush(struct mmu_gather *tlb)
> flush_tlb_range(tlb->vma, tlb->start, tlb->end);
> }
> }
> +#endif
> +
> +#if __is_defined(tlb_flush) ||
> \
> + IS_ENABLED(CONFIG_ARCH_WANT_AGGRESSIVE_TLB_FLUSH_BATCHING)
>
> static inline void
> tlb_update_vma(struct mmu_gather *tlb, struct vm_area_struct *vma)
> @@ -523,6 +532,15 @@ static inline void mark_mm_tlb_gen_done(struct mm_struct
> *mm, u64 gen)
>
> #endif /* CONFIG_ARCH_HAS_TLB_GENERATIONS */
>
> +#define tlb_start_ptes(tlb) \
> + do {\
> + struct mmu_gather *_tlb = (tlb);\
> + \
> + flush_tlb_batched_pending(_tlb->mm);\
> + } while (0)
> +
> +static inline void tlb_end_ptes(struct mmu_gather *tlb) { }
> +
> /*
> * tlb_flush_{pte|pmd|pud|p4d}_range() adjust the tlb->start and tlb->end,
> * and set corresponding cleared_*.
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 0938fd3ad228..932c1c2eb9a3 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -392,7 +392,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> #endif
> tlb_change_page_size(tlb, PAGE_SIZE);
> orig_pte = pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, );
> - flush_tlb_batched_pending(mm);
> + tlb_start_ptes(tlb);
> arch_enter_lazy_mmu_mode();
> for (; addr < end; pte++, addr += PAGE_SIZE) {
> ptent = *pte;
> @@ -468,6 +468,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
> }
>
> arch_leave_lazy_mmu_mode();
> + tlb_end_ptes(tlb);
> pte_unmap_unlock(orig_pte, ptl);
> if (pageout)
> reclaim_pages(_list);
> @@ -588,7 +589,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
Re: [PATCH 1/2] mm: Allow architectures to request 'old' entries when prefaulting
On Sun, 27. Dec 11:38, Linus Torvalds wrote:
> On Sat, Dec 26, 2020 at 6:38 PM Hugh Dickins wrote:
> >
> > This patch (like its antecedents) moves the pte_unmap_unlock() from
> > after do_fault_around()'s "check if the page fault is solved" into
> > filemap_map_pages() itself (which apparently does not NULLify vmf->pte
> > after unmapping it, which is poor, but good for revealing this issue).
> > That looks cleaner, but of course there was a very good reason for its
> > original positioning.
>
> Good catch.
>
> > Maybe you want to change the ->map_pages prototype, to pass down the
> > requested address too, so that it can report whether the requested
> > address was resolved or not. Or it could be left to __do_fault(),
> > or even to a repeated fault; but those would be less efficient.
>
> Let's keep the old really odd "let's unlock in the caller" for now,
> and minimize the changes.
>
> Adding a big big comment at the end of filemap_map_pages() to note the
> odd delayed page table unlocking.
>
> Here's an updated patch that combines Kirill's original patch, his
> additional incremental patch, and the fix for the pte lock oddity into
> one thing.
>
> Does this finally pass your testing?
>
>Linus
Hello together,
when i try to build this patch, i got the following error:
CC arch/x86/kernel/cpu/mce/threshold.o
mm/memory.c:3716:19: error: static declaration of ‘do_set_pmd’ follows
non-static declaration
static vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page)
^~
In file included from mm/memory.c:43:
./include/linux/mm.h:984:12: note: previous declaration of ‘do_set_pmd’ was here
vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page);
^~
make[3]: *** [scripts/Makefile.build:279: mm/memory.o] Error 1
make[2]: *** [Makefile:1805: mm] Error 2
make[2]: *** Waiting for unfinished jobs
CC arch/x86/kernel/cpu/mce/therm_throt.o
Best regards
Damian
> From 4d221d934d112aa40c3f4978460be098fc9ce831 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov"
> Date: Sat, 19 Dec 2020 15:19:23 +0300
> Subject: [PATCH] mm: Cleanup faultaround and finish_fault() codepaths
>
> alloc_set_pte() has two users with different requirements: in the
> faultaround code, it called from an atomic context and PTE page table
> has to be preallocated. finish_fault() can sleep and allocate page table
> as needed.
>
> PTL locking rules are also strange, hard to follow and overkill for
> finish_fault().
>
> Let's untangle the mess. alloc_set_pte() has gone now. All locking is
> explicit.
>
> The price is some code duplication to handle huge pages in faultaround
> path, but it should be fine, having overall improvement in readability.
>
> Signed-off-by: Kirill A. Shutemov
> Signed-off-by: Linus Torvalds
> ---
> include/linux/mm.h | 8 +-
> include/linux/pgtable.h | 11 +++
> mm/filemap.c| 168 ++--
> mm/memory.c | 161 +++---
> 4 files changed, 192 insertions(+), 156 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5299b90a6c40..c0643a0ad5ff 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -535,8 +535,8 @@ struct vm_fault {
>* is not NULL, otherwise pmd.
>*/
> pgtable_t prealloc_pte; /* Pre-allocated pte page table.
> - * vm_ops->map_pages() calls
> - * alloc_set_pte() from atomic context.
> + * vm_ops->map_pages() sets up a page
> + * table from from atomic context.
>* do_fault_around() pre-allocates
>* page table to avoid allocation from
>* atomic context.
> @@ -981,7 +981,9 @@ static inline pte_t maybe_mkwrite(pte_t pte, struct
> vm_area_struct *vma)
> return pte;
> }
>
> -vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct page *page);
> +vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page);
> +void do_set_pte(struct vm_fault *vmf, struct page *page);
> +
> vm_fault_t finish_fault(struct vm_fault *vmf);
> vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf);
> #endif
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 8fcdfa52eb4b..36eb748f3c97 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1314,6 +131
Re: [PATCH] Fix compat regression in process_vm_rw()
On Mo, 26. Okt 18:03, Jens Axboe wrote:
> The removal of compat_process_vm_{readv,writev} didn't change
> process_vm_rw(), which always assumes it's not doing a compat syscall.
> Instead of passing in 'false' unconditionally for 'compat', make it
> conditional on in_compat_syscall().
>
> Fixes: c3973b401ef2 ("mm: remove compat_process_vm_{readv,writev}")
> Reported-by: Kyle Huey
> Signed-off-by: Jens Axboe
>
> ---
>
> diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
> index fd12da80b6f2..05676722d9cd 100644
> --- a/mm/process_vm_access.c
> +++ b/mm/process_vm_access.c
> @@ -273,7 +273,8 @@ static ssize_t process_vm_rw(pid_t pid,
> return rc;
> if (!iov_iter_count())
> goto free_iov_l;
> - iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r, false);
> + iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r,
> + in_compat_syscall());
> if (IS_ERR(iov_r)) {
> rc = PTR_ERR(iov_r);
> goto free_iov_l;
>
> --
> Jens Axboe
>
Hello Jens,
i got the following error when i try to build.
m/process_vm_access.c: In Funktion »process_vm_rw«:
mm/process_vm_access.c:277:5: Fehler: Implizite Deklaration der Funktion
»in_compat_syscall«; meinten Sie »in_ia32_syscall«?
[-Werror=implicit-function-declaration]
277 | in_compat_syscall());
| ^
| in_ia32_syscall
--
VG
Damian Tometzki
Re: [PATCH v3 1/1] eventfd: implementation of EFD_MASK flag
Hi Paul,
On 2020-06-19 7:16 p.m., Paul Elder wrote:
> Hello Damian, Martin, and all,
>
> I came across this (quite old by now) patch to extend eventfd's polling
> functionality. I was wondering what happened to it (why it hasn't been
> merged yet) and if we could, or what is needed to, move it forward.
I think there was an open question about whether it was
best to move the definitions of EFD_SEMAPHORE, etc out of
/include/linux/eventfd.h and into a newly created
/include/uapi/linux/eventfd.h as this patch does.
I don't know if the maintainers have any concerns on this matter, or the
patch in general, that would prevent this from moving forward.
Thank you,
Damian
>
> I was thinking to use it for V4L2 events support via polling in the V4L2
> compatibility layer for libcamera [1]. We can signal V4L2 buffer
> availability POLLOUT via write(), but there is no way to signal V4L2
> events, as they are signaled via POLLPRI.
>
>
> Thank you,
>
> Paul
>
> [1] https://libcamera.org/docs.html#id1
>
> On Thu, Oct 15, 2015 at 10:42:08AM +0900, Damian Hobson-Garcia wrote:
>> From: Martin Sustrik
>>
>> When implementing network protocols in user space, one has to implement
>> fake file descriptors to represent the sockets for the protocol.
>>
>> Polling on such fake file descriptors is a problem (poll/select/epoll
>> accept only true file descriptors) and forces protocol implementers to use
>> various workarounds resulting in complex, non-standard and convoluted APIs.
>>
>> More generally, ability to create full-blown file descriptors for
>> userspace-to-userspace signalling is missing. While eventfd(2) goes half
>> the way towards this goal it has follwoing shorcomings:
>>
>> I. There's no way to signal POLLPRI, POLLHUP etc.
>> II. There's no way to signal arbitrary combination of POLL* flags. Most
>> notably, simultaneous !POLLIN and !POLLOUT, which is a perfectly valid
>> combination for a network protocol (rx buffer is empty and tx buffer is
>> full), cannot be signaled using eventfd.
>>
>> This patch implements new EFD_MASK flag which solves the above problems.
>>
>> The semantics of EFD_MASK are as follows:
>>
>> eventfd(2):
>>
>> If eventfd is created with EFD_MASK flag set, it is initialised in such a
>> way as to signal no events on the file descriptor when it is polled on.
>> The 'initval' argument is ignored.
>>
>> write(2):
>>
>> User is allowed to write only buffers containing a 32-bit value
>> representing any combination of event flags as defined by the poll(2)
>> function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.). Specified events
>> will be signaled when polling (select, poll, epoll) on the eventfd is
>> done later on.
>>
>> read(2):
>>
>> read is not supported and will fail with EINVAL.
>>
>> select(2), poll(2) and similar:
>>
>> When polling on the eventfd marked by EFD_MASK flag, all the events
>> specified in last written event flags shall be signaled.
>>
>> Signed-off-by: Martin Sustrik
>>
>> [dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3]
>> Signed-off-by: Damian Hobson-Garcia
>> ---
>> fs/eventfd.c | 102
>> ++-
>> include/linux/eventfd.h | 16 +--
>> include/uapi/linux/eventfd.h | 33 ++
>> 3 files changed, 126 insertions(+), 25 deletions(-)
>> create mode 100644 include/uapi/linux/eventfd.h
>>
>> diff --git a/fs/eventfd.c b/fs/eventfd.c
>> index 8d0c0df..1310779 100644
>> --- a/fs/eventfd.c
>> +++ b/fs/eventfd.c
>> @@ -2,6 +2,7 @@
>> * fs/eventfd.c
>> *
>> * Copyright (C) 2007 Davide Libenzi
>> + * Copyright (C) 2013 Martin Sustrik
>> *
>> */
>>
>> @@ -22,18 +23,31 @@
>> #include
>> #include
>>
>> +#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
>> +#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | EFD_MASK)
>> +#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR |
>> POLLHUP)
>> +
>> struct eventfd_ctx {
>> struct kref kref;
>> wait_queue_head_t wqh;
>> -/*
>> - * Every time that a write(2) is performed on an eventfd, the
>> - * value of the __u64 being written is added to "count" and a
>> - * wakeup is performed on "wqh". A read(2) will return the "count"
>> - * value to userspace, and will reset "count" to zero. The kernel
>> - * side eventfd
Re: [patch V9 20/39] x86/irq: Use generic irq_regs implementation
On Do, 28. Mai 11:50, Thomas Gleixner wrote: > Damian, > > damian writes: > > with this patch i got the following build error: > > > > LD .tmp_vmlinux.kallsyms1 > > /home/damian/kernel/buildroot/output/host/bin/x86_64-buildroot-linux-uclibc-ld: > > arch/x86/kernel/irq.o: in function `get_irq_regs': > > /home/damian/kernel/buildroot/output/build/linux-custom/./arch/x86/include/asm/irq_regs.h:19: > > undefined reference to `irq_regs' > > Can you provide the .config please? > > Thanks, > > tglx Hello Thomas, I found out self the reason. I rebuild the kernel from scratch again and now it works. Many Thnaks Damian
Re: [patch V9 20/39] x86/irq: Use generic irq_regs implementation
Hello Thomas, with this patch i got the following build error: LD .tmp_vmlinux.kallsyms1 /home/damian/kernel/buildroot/output/host/bin/x86_64-buildroot-linux-uclibc-ld: arch/x86/kernel/irq.o: in function `get_irq_regs': /home/damian/kernel/buildroot/output/build/linux-custom/./arch/x86/include/asm/irq_regs.h:19: undefined reference to `irq_regs' /home/damian/kernel/buildroot/output/host/bin/x86_64-buildroot-linux-uclibc-ld: arch/x86/kernel/irq.o: in function `set_irq_regs': /home/damian/kernel/buildroot/output/build/linux-custom/./arch/x86/include/asm/irq_regs.h:27: undefined reference to `irq_regs' /home/damian/kernel/buildroot/output/host/bin/x86_64-buildroot-linux-uclibc-ld: /home/damian/kernel/buildroot/output/build/linux-custom/./arch/x86/include/asm/irq_regs.h:27: undefined reference to `irq_regs' /home/damian/kernel/buildroot/output/host/bin/x86_64-buildroot-linux-uclibc-ld: arch/x86/kernel/irq.o: in function `get_irq_regs': /home/damian/kernel/buildroot/output/build/linux-custom/./arch/x86/include/asm/irq_regs.h:19: undefined reference to `irq_regs' /home/damian/kernel/buildroot/output/host/bin/x86_64-buildroot-linux-uclibc-ld: arch/x86/kernel/irq.o: in function `set_irq_regs': /home/damian/kernel/buildroot/output/build/linux-custom/./arch/x86/include/asm/irq_regs.h:27: undefined reference to `irq_regs' Best regards Damian
Re: [PATCH v6 01/10] mm/memunmap: Don't access uninitialized memmap in memunmap_pages()
Hello David,
patch 05/10 is missing in the patch series.
On Sun, 06. Oct 10:56, David Hildenbrand wrote:
> From: "Aneesh Kumar K.V"
>
> With an altmap, the memmap falling into the reserved altmap space are
> not initialized and, therefore, contain a garbage NID and a garbage
> zone. Make sure to read the NID/zone from a memmap that was initialzed.
>
> This fixes a kernel crash that is observed when destroying a namespace:
>
> [ 81.356173] kernel BUG at include/linux/mm.h:1107!
> cpu 0x1: Vector: 700 (Program Check) at [c00274087890]
> pc: c04b9728: memunmap_pages+0x238/0x340
> lr: c04b9724: memunmap_pages+0x234/0x340
> ...
> pid = 3669, comm = ndctl
> kernel BUG at include/linux/mm.h:1107!
> [c00274087ba0] c09e3500 devm_action_release+0x30/0x50
> [c00274087bc0] c09e4758 release_nodes+0x268/0x2d0
> [c00274087c30] c09dd144 device_release_driver_internal+0x174/0x240
> [c00274087c70] c09d9dfc unbind_store+0x13c/0x190
> [c00274087cb0] c09d8a24 drv_attr_store+0x44/0x60
> [c00274087cd0] c05a7470 sysfs_kf_write+0x70/0xa0
> [c00274087d10] c05a5cac kernfs_fop_write+0x1ac/0x290
> [c00274087d60] c04be45c __vfs_write+0x3c/0x70
> [c00274087d80] c04c26e4 vfs_write+0xe4/0x200
> [c00274087dd0] c04c2a6c ksys_write+0x7c/0x140
> [c00274087e20] c000bbd0 system_call+0x5c/0x68
>
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: Logan Gunthorpe
> Cc: Ira Weiny
> Signed-off-by: Aneesh Kumar K.V
> [ minimze code changes, rephrase description ]
> Signed-off-by: David Hildenbrand
> ---
> mm/memremap.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memremap.c b/mm/memremap.c
> index 557e53c6fb46..8c2fb44c3b4d 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -123,6 +123,7 @@ static void dev_pagemap_cleanup(struct dev_pagemap *pgmap)
> void memunmap_pages(struct dev_pagemap *pgmap)
> {
> struct resource *res = >res;
> + struct page *first_page;
> unsigned long pfn;
> int nid;
>
> @@ -131,14 +132,16 @@ void memunmap_pages(struct dev_pagemap *pgmap)
> put_page(pfn_to_page(pfn));
> dev_pagemap_cleanup(pgmap);
>
> + /* make sure to access a memmap that was actually initialized */
> + first_page = pfn_to_page(pfn_first(pgmap));
> +
> /* pages are dead and unused, undo the arch mapping */
> - nid = page_to_nid(pfn_to_page(PHYS_PFN(res->start)));
> + nid = page_to_nid(first_page);
Why we need 'nid = page_to_nid(first_page)' we didnt use it anymore in this
function ?
>
> mem_hotplug_begin();
> if (pgmap->type == MEMORY_DEVICE_PRIVATE) {
> - pfn = PHYS_PFN(res->start);
> - __remove_pages(page_zone(pfn_to_page(pfn)), pfn,
> - PHYS_PFN(resource_size(res)), NULL);
> + __remove_pages(page_zone(first_page), PHYS_PFN(res->start),
> + PHYS_PFN(resource_size(res)), NULL);
> } else {
> arch_remove_memory(nid, res->start, resource_size(res),
> pgmap_altmap(pgmap));
> --
> 2.21.0
>
Best regards
Damian
linux
linux
test
test
tt
tt
[PATCH v7 3/4] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
From: Quentin Schulz
Document the bindings used for the Cadence MHDP DPI/DP bridge.
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/cdns,mhdp.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
new file mode 100644
index ..df2a00163ccf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
@@ -0,0 +1,47 @@
+Cadence MHDP bridge
+==
+
+The Cadence MHDP bridge is a DPI to DP bridge.
+
+Required properties:
+- compatible: should be "cdns,mhdp8546",
+- reg: physical base address and length of the controller's registers,
+- clocks: DP bridge clock, it's used by the IP to know how to translate
+ a number of clock cycles into a time (which is used to comply
+ with DP standard timings and delays),
+- phys: see the Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
+- phy-names: must be "dpphy"
+
+Required subnodes:
+- ports: Ports as described in Documentation/devictree/bindings/graph.txt
+ Port 0 - input port representing the DP bridge input
+ Port 1 - output port representing the DP bridge output
+
+Example:
+
+ mhdp: dp-bridge@f0fb00 {
+ compatible = "cdns,mhdp8546";
+ reg = <0xf0 0xfb00 0x0 0x100>;
+ clocks = <_clock>;
+ phys = <_phy>;
+ phy-names = "dpphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dp_bridge_input: endpoint {
+ remote-endpoint = <_dpi_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_bridge_output: endpoint {
+ remote-endpoint =
<_dp_connector_input>;
+ };
+ };
+ };
+ };
--
2.17.1
[PATCH v7 4/4] drm: bridge: add support for Cadence MHDP DPI/DP bridge
From: Quentin Schulz
This adds support for Cadence MHDP DPI to DP bridge.
Basically, it takes a DPI stream as input and output it encoded in DP
format. It supports SST and MST modes.
Changes made in the low level driver (cdn-dp-reg.*):
- moved it to from drivers/gpu/drm/rockchip to
drivers/gpu/drm/bridge/cdns-mhdp-common.c and
include/drm/bridge/cdns-mhdp-common.h
- functions for sending/receiving commands are now public
- added functions for reading registers and link training
adjustment
Changes made in RK's driver (cdn-dp-core.*):
- Moved audio_info and audio_pdev fields from cdn_dp_device to
cdns_mhdp_device structure.
Signed-off-by: Quentin Schulz
Signed-off-by: Piotr Sroka
Signed-off-by: Damian Kos
---
drivers/gpu/drm/bridge/Kconfig|9 +
drivers/gpu/drm/bridge/Makefile |3 +
.../cdns-mhdp-common.c} | 186 ++-
drivers/gpu/drm/bridge/cdns-mhdp-mst.c| 549 +++
drivers/gpu/drm/bridge/cdns-mhdp.c| 1349 +
drivers/gpu/drm/bridge/cdns-mhdp.h| 209 +++
drivers/gpu/drm/rockchip/Kconfig |4 +-
drivers/gpu/drm/rockchip/Makefile |2 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 34 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h|5 +-
include/drm/bridge/cdns-mhdp-cbs.h| 29 +
.../drm/bridge/cdns-mhdp-common.h | 68 +-
12 files changed, 2384 insertions(+), 63 deletions(-)
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.c => bridge/cdns-mhdp-common.c}
(85%)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-mst.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.h
create mode 100644 include/drm/bridge/cdns-mhdp-cbs.h
rename drivers/gpu/drm/rockchip/cdn-dp-reg.h =>
include/drm/bridge/cdns-mhdp-common.h (91%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..2b7c568756fb 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -35,6 +35,15 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CDNS_MHDP
+ tristate "Cadence DPI/DP bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ depends on OF
+ help
+ Support Cadence DPI to DP bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..b80f3d6ed2a6 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -16,4 +16,7 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_CDNS_MHDP) += mhdp8546.o
obj-y += synopsys/
+
+mhdp8546-objs := cdns-mhdp-common.o cdns-mhdp.o cdns-mhdp-mst.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
similarity index 85%
rename from drivers/gpu/drm/rockchip/cdn-dp-reg.c
rename to drivers/gpu/drm/bridge/cdns-mhdp-common.c
index a32ee26fd36b..f0160df52aed 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
* Author: Chris Zhong
@@ -13,14 +14,17 @@
*/
#include
-#include
#include
+#include
#include
#include
#include
-#include "cdn-dp-core.h"
-#include "cdn-dp-reg.h"
+#include
+
+#include
+#include
+#include
#define CDNS_DP_SPDIF_CLK 2
#define FW_ALIVE_TIMEOUT_US100
@@ -29,10 +33,27 @@
#define LINK_TRAINING_RETRY_MS 20
#define LINK_TRAINING_TIMEOUT_MS 500
+static inline u32 get_unaligned_be24(const void *p)
+{
+ const u8 *_p = p;
+
+ return _p[0] << 16 | _p[1] << 8 | _p[2];
+}
+
+static inline void put_unaligned_be24(u32 val, void *p)
+{
+ u8 *_p = p;
+
+ _p[0] = val >> 16;
+ _p[1] = val >> 8;
+ _p[2] = val;
+}
+
void cdns_mhdp_set_fw_clk(struct cdns_mhdp_device *mhdp, unsigned long clk)
{
writel(clk / 100, mhdp->regs + SW_CLK_H);
}
+EXPORT_SYMBOL(cdns_mhdp_set_fw_clk);
void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
{
@@ -82,6 +103,7 @@ void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
/* enable Mailbox and PIF interrupt */
writel(0, mhdp->regs + APB_INT_MASK);
}
+EXPORT_SYMBOL(cdns_mhdp_clock_reset);
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
{
@@ -128,7 +150,7 @@
[PATCH v7 2/4] drm/dp: fix link probing for devices supporting DP 1.4+
From: Quentin Schulz
DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
"true capabilities" of DPRX device.
Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
might falsely return lower capabilities to "avoid interoperability
issues with some of the existing DP Source devices that malfunction
when they discover the higher capabilities within those three
registers.".
Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was reserved
and read 0 so it's safe to check against it even if DP revision is
<1.4
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
Reviewed-by: Andrzej Hajda
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/drm_dp_helper.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 54120b6319e7..4e36d708fdce 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -372,10 +372,38 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
{
u8 values[3];
int err;
+ unsigned int addr;
memset(link, 0, sizeof(*link));
- err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+ /*
+* DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
+* DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
+* DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
+* DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
+* DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
+* "true capabilities" of DPRX device.
+*
+* Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
+* might falsely return lower capabilities to "avoid interoperability
+* issues with some of the existing DP Source devices that malfunction
+* when they discover the higher capabilities within those three
+* registers.".
+*
+* Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was
+* reserved and read 0 so it's safe to check against it even if
+* DP revision is <1.4
+*/
+ err = drm_dp_dpcd_readb(aux, DP_TRAINING_AUX_RD_INTERVAL, values);
+ if (err < 0)
+ return err;
+
+ if (values[0] & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)
+ addr = DP_DP13_DPCD_REV;
+ else
+ addr = DP_DPCD_REV;
+
+ err = drm_dp_dpcd_read(aux, addr, values, sizeof(values));
if (err < 0)
return err;
--
2.17.1
[PATCH v7 1/4] drm/rockchip: prepare common code for cdns and rk dpi/dp driver
- Extracted common fields from cdn_dp_device to a new cdns_mhdp_device
structure which will be used by two separate drivers later on.
- Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format,
video_info) from cdn-dp-core.c to cdn-dp-reg.h.
- Changed prefixes from cdn_dp to cdns_mhdp
cdn -> cdns to match the other Cadence's drivers
dp -> mhdp to distinguish it from a "just a DP" as the IP underneath
this registers map can be a HDMI (which is internally different,
but the interface for commands, events is pretty much the same).
- Modified cdn-dp-core.c to use the new driver structure and new function
names.
Signed-off-by: Damian Kos
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 220 +++--
drivers/gpu/drm/rockchip/cdn-dp-core.h | 40 +--
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 428 +
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 114 +--
4 files changed, 431 insertions(+), 371 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index f7b9d45aa1d6..2026bc7ffcce 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -31,11 +31,10 @@
#include
#include "cdn-dp-core.h"
-#include "cdn-dp-reg.h"
#include "rockchip_drm_vop.h"
#define connector_to_dp(c) \
- container_of(c, struct cdn_dp_device, connector)
+ container_of(c, struct cdn_dp_device, mhdp.connector)
#define encoder_to_dp(c) \
container_of(c, struct cdn_dp_device, encoder)
@@ -70,17 +69,18 @@ MODULE_DEVICE_TABLE(of, cdn_dp_dt_ids);
static int cdn_dp_grf_write(struct cdn_dp_device *dp,
unsigned int reg, unsigned int val)
{
+ struct device *dev = dp->mhdp.dev;
int ret;
ret = clk_prepare_enable(dp->grf_clk);
if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to prepare_enable grf clock\n");
+ DRM_DEV_ERROR(dev, "Failed to prepare_enable grf clock\n");
return ret;
}
ret = regmap_write(dp->grf, reg, val);
if (ret) {
- DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
+ DRM_DEV_ERROR(dev, "Could not write to GRF: %d\n", ret);
return ret;
}
@@ -91,24 +91,25 @@ static int cdn_dp_grf_write(struct cdn_dp_device *dp,
static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
{
+ struct device *dev = dp->mhdp.dev;
int ret;
unsigned long rate;
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot enable dp pclk %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot enable dp pclk %d\n", ret);
goto err_pclk;
}
ret = clk_prepare_enable(dp->core_clk);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot enable core_clk %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot enable core_clk %d\n", ret);
goto err_core_clk;
}
- ret = pm_runtime_get_sync(dp->dev);
+ ret = pm_runtime_get_sync(dev);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot get pm runtime %d\n", ret);
goto err_pm_runtime_get;
}
@@ -121,18 +122,18 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
rate = clk_get_rate(dp->core_clk);
if (!rate) {
- DRM_DEV_ERROR(dp->dev, "get clk rate failed\n");
+ DRM_DEV_ERROR(dev, "get clk rate failed\n");
ret = -EINVAL;
goto err_set_rate;
}
- cdn_dp_set_fw_clk(dp, rate);
- cdn_dp_clock_reset(dp);
+ cdns_mhdp_set_fw_clk(>mhdp, rate);
+ cdns_mhdp_clock_reset(>mhdp);
return 0;
err_set_rate:
- pm_runtime_put(dp->dev);
+ pm_runtime_put(dev);
err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
@@ -143,7 +144,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
static void cdn_dp_clk_disable(struct cdn_dp_device *dp)
{
- pm_runtime_put_sync(dp->dev);
+ pm_runtime_put_sync(dp->mhdp.dev);
clk_disable_unprepare(dp->pclk);
clk_disable_unprepare(dp->core_clk);
}
@@ -176,7 +177,7 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp,
u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
+ ret = cdns_mhdp_dpcd_read(>mhdp, DP_SINK_COUNT, , 1);
if (ret)
return ret;
@@ -200,12 +201,13 @@ static
[PATCH v7 0/4] drm: add support for Cadence MHDP DPI/DP bridge.
Hello!
This is the series of patches that will add support for the Cadence's DPI/DP
bridge. Please note that this is a preliminary version of the driver and there
will be more patches in the future with updates, fixes and improvements.
Please keep that in mind when looking at FIXME/TODO/XXX comments.
Initially, MHDP driver was developed as a DRM bridge driver and was planed to
be placed in drivers/gpu/drm/bridge/mhdp.c. However, there was already
a driver for Cadence's DP controller developed by RockChip, but that driver
uses the different DRM framework and looks like a part of a bigger system.
Both controllers (including firmware) are quite different internally
(MST/FEC/DSC support, link training done by driver, additional commands, IRQ's
etc.) but they have similar register map, except for Framer/Streamer (which is
noticeably different), so they appear similar.
The following patches contain:
- Moving common code to drivers/gpu/drm/bridge/cdns-mhdp-common.* and
modifying it a bit (mostly new prefixes for functions and data types) so it
can be used by two, higher level, drivers.
- Modifying existing RockChip's DP driver to use the common code after changes
made to it (use the new cdns_mhdp_device structure and new function names).
- Modifying DRM helpers a bit. Some are required for new driver, some are
updates from DP 1.2 to 1.3 or 1.4.
- Adding documentation for device tree bindings.
- Adding preliminary Cadence DPI/DP bridge driver.
Some of the things that will be added later on include (but are not limited
to):
- DSC support
- FEC support
- HDCP support
Changes in v7:
- Overal code cleanup
- Patched memory leak after EDID read
- Fixed SPDX-License-Identifier tags
- Sorted includes
- In patch 4/6:
Cleanup and fix in mhdp_transfer
Replaced byteshifts with {put|get}_unaligned_be{32|24|16} (added 24bit one)
- In patch 5/6:
Removed cdns_mhdp_mst_set_threshold (not needed anymore as HW does that)
Updated cdns_mhdp_mst_set_rate_governing
Replaced request_irq with devm_request_irq
And then merged with 4/6 (as many changes in this patch altered the SST part)
- In patch 6/6:
Fix in checking devm_phy_get result
Updated bindings doc
And then merged with 4/6 (as this should be in the driver in the first place)
Changes in v6:
- Added Reviewed-bys for already reviewed patches
- Dropped patch v5-0003 (that made dp_get_lane_status helper public)
- Added patch with MST support
- Added patch with Cadence SD0801 PHY init
Changes in v5:
- Fixed Kconfig in drm/rockchip again
- Moved cdn-dp-reg.h (cdns-mhdp-common.h) to include/drm/bridge instead of
drivers/gpu/drm/bridge/
- Updated the mhdp_validate_cr function
Changes in v4:
- Fixed Kconfig in drm/rockchip
- Fixed Signed-offs
- dp_link_status() is no longer public since it's used only in drm_dp_helper.c
- Replaced EXTRA_CFLAGS with ccflags-y in drm/rockchip Makefile
Changes in v3:
- Corrected dt-bindings document
- Enabled some clocks at startup (since FW doesn't do that anymore).
- Changed Firmware file name to match the file on Linux Firmware repo.
- Added SST audio support
- Made common functions (in cdns-mhdp-common.*) public.
Changes in v2:
- Added actual description of what the patch contains, what is it for and
what's going on here in general.
- New structure. Now we have one common low level driver + two high level
drivers - one for RockChip with minimum changes and one, more general, for
Cadence.
- Dropped some changes made to DRM helpers.
- Updated the device tree bindings document.
Damian Kos (1):
drm/rockchip: prepare common code for cdns and rk dpi/dp driver
Quentin Schulz (3):
drm/dp: fix link probing for devices supporting DP 1.4+
dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
drm: bridge: add support for Cadence MHDP DPI/DP bridge
.../bindings/display/bridge/cdns,mhdp.txt | 47 +
drivers/gpu/drm/bridge/Kconfig|9 +
drivers/gpu/drm/bridge/Makefile |3 +
drivers/gpu/drm/bridge/cdns-mhdp-common.c | 1103 ++
drivers/gpu/drm/bridge/cdns-mhdp-mst.c| 549 +++
drivers/gpu/drm/bridge/cdns-mhdp.c| 1349 +
drivers/gpu/drm/bridge/cdns-mhdp.h| 209 +++
drivers/gpu/drm/drm_dp_helper.c | 30 +-
drivers/gpu/drm/rockchip/Kconfig |4 +-
drivers/gpu/drm/rockchip/Makefile |2 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 234 +--
drivers/gpu/drm/rockchip/cdn-dp-core.h| 43 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 969
include/drm/bridge/cdns-mhdp-cbs.h| 29 +
.../drm/bridge/cdns-mhdp-common.h | 176 ++-
15 files changed, 3606 insertions(+), 1150 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-common.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-mst.c
create mode
[PATCH] drm/rockchip: fix for mailbox read validation.
This is basically the same fix as in
commit fa68d4f8476b ("drm/rockchip: fix for mailbox read size")
but for cdn_dp_mailbox_validate_receive function.
See patchwork.kernel.org/patch/10671981/ for details.
Signed-off-by: Damian Kos
---
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index 5a485489a1e2..6c8b14fb1d2f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -113,7 +113,7 @@ static int cdp_dp_mailbox_write(struct cdn_dp_device *dp,
u8 val)
static int cdn_dp_mailbox_validate_receive(struct cdn_dp_device *dp,
u8 module_id, u8 opcode,
- u8 req_size)
+ u16 req_size)
{
u32 mbox_size, i;
u8 header[4];
--
2.17.1
[PATCH] drm/rockchip: fix for mailbox read validation.
This is basically the same fix as in
commit fa68d4f8476b ("drm/rockchip: fix for mailbox read size")
but for cdn_dp_mailbox_validate_receive function.
See patchwork.kernel.org/patch/10671981/ for details.
Signed-off-by: Damian Kos
---
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index 5a485489a1e2..6c8b14fb1d2f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -113,7 +113,7 @@ static int cdp_dp_mailbox_write(struct cdn_dp_device *dp,
u8 val)
static int cdn_dp_mailbox_validate_receive(struct cdn_dp_device *dp,
u8 module_id, u8 opcode,
- u8 req_size)
+ u16 req_size)
{
u32 mbox_size, i;
u8 header[4];
--
2.17.1
Re: [PATCH v4 06/10] x86/alternative: use temporary mm for text poking
On Sa, 10. Nov 15:17, Nadav Amit wrote:
> text_poke() can potentially compromise the security as it sets temporary
> PTEs in the fixmap. These PTEs might be used to rewrite the kernel code
> from other cores accidentally or maliciously, if an attacker gains the
> ability to write onto kernel memory.
>
> Moreover, since remote TLBs are not flushed after the temporary PTEs are
> removed, the time-window in which the code is writable is not limited if
> the fixmap PTEs - maliciously or accidentally - are cached in the TLB.
> To address these potential security hazards, we use a temporary mm for
> patching the code.
>
> Finally, text_poke() is also not conservative enough when mapping pages,
> as it always tries to map 2 pages, even when a single one is sufficient.
> So try to be more conservative, and do not map more than needed.
>
> Cc: Andy Lutomirski
> Cc: Kees Cook
> Cc: Peter Zijlstra
> Cc: Dave Hansen
> Cc: Masami Hiramatsu
> Signed-off-by: Nadav Amit
> ---
> arch/x86/include/asm/fixmap.h | 2 -
> arch/x86/kernel/alternative.c | 112 +++---
> 2 files changed, 89 insertions(+), 25 deletions(-)
>
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index 50ba74a34a37..9da8cccdf3fb 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -103,8 +103,6 @@ enum fixed_addresses {
> #ifdef CONFIG_PARAVIRT
> FIX_PARAVIRT_BOOTMAP,
> #endif
Hello Nadav,
with the remove of FIX_TEXT_POKE1 and FIX_TEXT_POKE0 i get the following
build error:
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2321:7: Fehler:
»FIX_TEXT_POKE0« nicht deklariert (erstmalige Verwendung in dieser Funktion);
meinten Sie »FIX_TBOOT_BASE«?
case FIX_TEXT_POKE0:
^~
FIX_TBOOT_BASE
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2321:7: Anmerkung: jeder nicht
deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt,
gemeldet
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2322:7: Fehler:
»FIX_TEXT_POKE1« nicht deklariert (erstmalige Verwendung in dieser Funktion);
meinten Sie »FIX_TBOOT_BASE«?
case FIX_TEXT_POKE1:
^~
FIX_TBOOT_BASE
Best regards
Damian
> - FIX_TEXT_POKE1, /* reserve 2 pages for text_poke() */
> - FIX_TEXT_POKE0, /* first page is last, because allocation is backward */
> #ifdef CONFIG_X86_INTEL_MID
> FIX_LNW_VRTC,
> #endif
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index d3ae5c26e5a0..96607ef285c3 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -683,43 +684,108 @@ __ro_after_init unsigned long poking_addr;
>
> static int __text_poke(void *addr, const void *opcode, size_t len)
> {
> + bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE;
> + temporary_mm_state_t prev;
> + struct page *pages[2] = {NULL};
> unsigned long flags;
> - char *vaddr;
> - struct page *pages[2];
> - int i, r = 0;
> + pte_t pte, *ptep;
> + spinlock_t *ptl;
> + int r = 0;
>
> /*
> - * While boot memory allocator is runnig we cannot use struct
> - * pages as they are not yet initialized.
> + * While boot memory allocator is running we cannot use struct pages as
> + * they are not yet initialized.
>*/
> BUG_ON(!after_bootmem);
>
> if (!core_kernel_text((unsigned long)addr)) {
> pages[0] = vmalloc_to_page(addr);
> - pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
> + if (cross_page_boundary)
> + pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
> } else {
> pages[0] = virt_to_page(addr);
> WARN_ON(!PageReserved(pages[0]));
> - pages[1] = virt_to_page(addr + PAGE_SIZE);
> + if (cross_page_boundary)
> + pages[1] = virt_to_page(addr + PAGE_SIZE);
> }
> - if (!pages[0])
> +
> + if (!pages[0] || (cross_page_boundary && !pages[1]))
> return -EFAULT;
> +
> local_irq_save(flags);
> - set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
> - if (pages[1])
> - set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
> - vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
> - memcpy([(unsigned long)addr & ~PAGE_MASK], opcode, len);
> - clear_fixmap(FIX_TEXT_POKE0);
> - if (pages[1])
> - clear_fixmap(FIX_TEXT_POKE1);
> - local_flush_tlb();
> - sync_core();
>
Re: [PATCH v4 06/10] x86/alternative: use temporary mm for text poking
On Sa, 10. Nov 15:17, Nadav Amit wrote:
> text_poke() can potentially compromise the security as it sets temporary
> PTEs in the fixmap. These PTEs might be used to rewrite the kernel code
> from other cores accidentally or maliciously, if an attacker gains the
> ability to write onto kernel memory.
>
> Moreover, since remote TLBs are not flushed after the temporary PTEs are
> removed, the time-window in which the code is writable is not limited if
> the fixmap PTEs - maliciously or accidentally - are cached in the TLB.
> To address these potential security hazards, we use a temporary mm for
> patching the code.
>
> Finally, text_poke() is also not conservative enough when mapping pages,
> as it always tries to map 2 pages, even when a single one is sufficient.
> So try to be more conservative, and do not map more than needed.
>
> Cc: Andy Lutomirski
> Cc: Kees Cook
> Cc: Peter Zijlstra
> Cc: Dave Hansen
> Cc: Masami Hiramatsu
> Signed-off-by: Nadav Amit
> ---
> arch/x86/include/asm/fixmap.h | 2 -
> arch/x86/kernel/alternative.c | 112 +++---
> 2 files changed, 89 insertions(+), 25 deletions(-)
>
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index 50ba74a34a37..9da8cccdf3fb 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -103,8 +103,6 @@ enum fixed_addresses {
> #ifdef CONFIG_PARAVIRT
> FIX_PARAVIRT_BOOTMAP,
> #endif
Hello Nadav,
with the remove of FIX_TEXT_POKE1 and FIX_TEXT_POKE0 i get the following
build error:
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2321:7: Fehler:
»FIX_TEXT_POKE0« nicht deklariert (erstmalige Verwendung in dieser Funktion);
meinten Sie »FIX_TBOOT_BASE«?
case FIX_TEXT_POKE0:
^~
FIX_TBOOT_BASE
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2321:7: Anmerkung: jeder nicht
deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt,
gemeldet
/home/damian/kernel/linux/arch/x86/xen/mmu_pv.c:2322:7: Fehler:
»FIX_TEXT_POKE1« nicht deklariert (erstmalige Verwendung in dieser Funktion);
meinten Sie »FIX_TBOOT_BASE«?
case FIX_TEXT_POKE1:
^~
FIX_TBOOT_BASE
Best regards
Damian
> - FIX_TEXT_POKE1, /* reserve 2 pages for text_poke() */
> - FIX_TEXT_POKE0, /* first page is last, because allocation is backward */
> #ifdef CONFIG_X86_INTEL_MID
> FIX_LNW_VRTC,
> #endif
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index d3ae5c26e5a0..96607ef285c3 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -683,43 +684,108 @@ __ro_after_init unsigned long poking_addr;
>
> static int __text_poke(void *addr, const void *opcode, size_t len)
> {
> + bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE;
> + temporary_mm_state_t prev;
> + struct page *pages[2] = {NULL};
> unsigned long flags;
> - char *vaddr;
> - struct page *pages[2];
> - int i, r = 0;
> + pte_t pte, *ptep;
> + spinlock_t *ptl;
> + int r = 0;
>
> /*
> - * While boot memory allocator is runnig we cannot use struct
> - * pages as they are not yet initialized.
> + * While boot memory allocator is running we cannot use struct pages as
> + * they are not yet initialized.
>*/
> BUG_ON(!after_bootmem);
>
> if (!core_kernel_text((unsigned long)addr)) {
> pages[0] = vmalloc_to_page(addr);
> - pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
> + if (cross_page_boundary)
> + pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
> } else {
> pages[0] = virt_to_page(addr);
> WARN_ON(!PageReserved(pages[0]));
> - pages[1] = virt_to_page(addr + PAGE_SIZE);
> + if (cross_page_boundary)
> + pages[1] = virt_to_page(addr + PAGE_SIZE);
> }
> - if (!pages[0])
> +
> + if (!pages[0] || (cross_page_boundary && !pages[1]))
> return -EFAULT;
> +
> local_irq_save(flags);
> - set_fixmap(FIX_TEXT_POKE0, page_to_phys(pages[0]));
> - if (pages[1])
> - set_fixmap(FIX_TEXT_POKE1, page_to_phys(pages[1]));
> - vaddr = (char *)fix_to_virt(FIX_TEXT_POKE0);
> - memcpy([(unsigned long)addr & ~PAGE_MASK], opcode, len);
> - clear_fixmap(FIX_TEXT_POKE0);
> - if (pages[1])
> - clear_fixmap(FIX_TEXT_POKE1);
> - local_flush_tlb();
> - sync_core();
>
Re: [tip:locking/core 5/6] /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory
Hello Mark, i got now the error: /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory make[2]: *** [/home/damian/kernel/linux/./Kbuild:86: old-atomics] Fehler 127 make[1]: *** [/home/damian/kernel/linux/Makefile:1112: prepare0] Fehler 2 Best regards Damian On Do, 01. Nov 11:29, Mark Rutland wrote: > On Thu, Nov 01, 2018 at 06:16:22PM +0800, kbuild test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > locking/core > > head: 30bc7baa9de81efc0584b9290ce8040a1130f156 > > commit: 85f8507192fbfb4ad2ac01de879cb50045f4247f [5/6] locking/atomics: > > Check generated headers are up-to-date > > config: i386-tinyconfig (attached as .config) > > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 > > reproduce: > > git checkout 85f8507192fbfb4ad2ac01de879cb50045f4247f > > # save the attached .config to linux build tree > > make ARCH=i386 > > > > All errors (new ones prefixed by >>): > > > > >> /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory > >make[2]: *** [old-atomics] Error 127 > >make[2]: Target '__build' not remade because of errors. > >make[1]: *** [prepare0] Error 2 > >make[1]: Target 'prepare' not remade because of errors. > >make: *** [sub-make] Error 2 > > It looks like we accidentally dropped execute permissions from the > scripts when picking them from the list. Locally I get a slightly > different failure: > > ALLscripts/atomic/check-atomics.sh > scripts/atomic/check-atomics.sh: line 16: > scripts/atomic/gen-atomic-instrumented.sh: Permission denied > warning: include/asm-generic/atomic-instrumented.h is out-of-date. > scripts/atomic/check-atomics.sh: line 16: > scripts/atomic/gen-atomic-long.sh: Permission denied > warning: include/asm-generic/atomic-long.h is out-of-date. > scripts/atomic/check-atomics.sh: line 16: > scripts/atomic/gen-atomic-fallback.sh: Permission denied > warning: include/linux/atomic-fallback.h is out-of-date. > > I've sent a patch [1] to fix this. > > Thanks, > Mark. > > [1] https://lkml.kernel.org/r/20181101112654.55898-1-mark.rutl...@arm.com
Re: [tip:locking/core 5/6] /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory
Hello Mark, i got now the error: /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory make[2]: *** [/home/damian/kernel/linux/./Kbuild:86: old-atomics] Fehler 127 make[1]: *** [/home/damian/kernel/linux/Makefile:1112: prepare0] Fehler 2 Best regards Damian On Do, 01. Nov 11:29, Mark Rutland wrote: > On Thu, Nov 01, 2018 at 06:16:22PM +0800, kbuild test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > locking/core > > head: 30bc7baa9de81efc0584b9290ce8040a1130f156 > > commit: 85f8507192fbfb4ad2ac01de879cb50045f4247f [5/6] locking/atomics: > > Check generated headers are up-to-date > > config: i386-tinyconfig (attached as .config) > > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 > > reproduce: > > git checkout 85f8507192fbfb4ad2ac01de879cb50045f4247f > > # save the attached .config to linux build tree > > make ARCH=i386 > > > > All errors (new ones prefixed by >>): > > > > >> /bin/bash: scripts/atomic/check-atomics.sh: No such file or directory > >make[2]: *** [old-atomics] Error 127 > >make[2]: Target '__build' not remade because of errors. > >make[1]: *** [prepare0] Error 2 > >make[1]: Target 'prepare' not remade because of errors. > >make: *** [sub-make] Error 2 > > It looks like we accidentally dropped execute permissions from the > scripts when picking them from the list. Locally I get a slightly > different failure: > > ALLscripts/atomic/check-atomics.sh > scripts/atomic/check-atomics.sh: line 16: > scripts/atomic/gen-atomic-instrumented.sh: Permission denied > warning: include/asm-generic/atomic-instrumented.h is out-of-date. > scripts/atomic/check-atomics.sh: line 16: > scripts/atomic/gen-atomic-long.sh: Permission denied > warning: include/asm-generic/atomic-long.h is out-of-date. > scripts/atomic/check-atomics.sh: line 16: > scripts/atomic/gen-atomic-fallback.sh: Permission denied > warning: include/linux/atomic-fallback.h is out-of-date. > > I've sent a patch [1] to fix this. > > Thanks, > Mark. > > [1] https://lkml.kernel.org/r/20181101112654.55898-1-mark.rutl...@arm.com
Re: linux-next: Tree for Oct 29
On Mon, 29. Oct 20:41, Stephen Rothwell wrote: > Hi Damian, > > On Mon, 29 Oct 2018 07:33:19 +0100 Damian Tometzki > wrote: > > > > on the site isnt available the new linux-next ? > > Only the old one. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > > It seems to be there now (at least for me). Maybe just mirroring delays? > > -- > Cheers, > Stephen Rothwell Hello Stephen, i tried it from diffrent localtion and different systems the same sitation. My last tag what i see is: linux-next-next-20181019.tar.gz Best regards Damian
Re: linux-next: Tree for Oct 29
On Mon, 29. Oct 20:41, Stephen Rothwell wrote: > Hi Damian, > > On Mon, 29 Oct 2018 07:33:19 +0100 Damian Tometzki > wrote: > > > > on the site isnt available the new linux-next ? > > Only the old one. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > > It seems to be there now (at least for me). Maybe just mirroring delays? > > -- > Cheers, > Stephen Rothwell Hello Stephen, i tried it from diffrent localtion and different systems the same sitation. My last tag what i see is: linux-next-next-20181019.tar.gz Best regards Damian
Re: linux-next: Tree for Oct 29
On Mo, 29. Okt 17:02, Stephen Rothwell wrote: > Hi all, > Hello Stephen, on the site isnt available the new linux-next ? Only the old one. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > Changes since 20181019: > > Linus' tree gained 2 build failures for which I reverted a commit and > added a fix patch. > > The arm-soc tree gained conflicts against Linus' tree. > > The vfs tree gained conflicts against the ceph and nfsd trees. > > The pm tree gained conflicts against Linus' and the i2c trees. > > The drivers-x86 tree gained a conflict against Linus' tree. > > Non-merge commits (relative to Linus' tree): 4593 > 4462 files changed, 276395 insertions(+), 77168 deletions(-) > > > > I have created today's linux-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you > are tracking the linux-next tree using git, you should not use "git pull" > to do so as that will try to merge the new linux-next release with the > old one. You should use "git fetch" and checkout or reset to the new > master. > > You can see which trees have been included by looking in the Next/Trees > file in the source. There are also quilt-import.log and merge.log > files in the Next directory. Between each merge, the tree was built > with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a > multi_v7_defconfig for arm and a native build of tools/perf. After > the final fixups (if any), I do an x86_64 modules_install followed by > builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), > ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc > and sparc64 defconfig. And finally, a simple boot test of the powerpc > pseries_le_defconfig kernel in qemu (with and without kvm enabled). > > Below is a summary of the state of the merge. > > I am currently merging 291 trees (counting Linus' and 66 trees of bug > fix patches pending for the current merge release). > > Stats about the size of the tree over time can be seen at > http://neuling.org/linux-next-size.html . > > Status of my local build tests will be at > http://kisskb.ellerman.id.au/linux-next . If maintainers want to give > advice about cross compilers/configs that work, we are always open to add > more builds. > > Thanks to Randy Dunlap for doing many randconfig builds. And to Paul > Gortmaker for triage and bug fixes. > > -- > Cheers, > Stephen Rothwell > > $ git checkout master > $ git reset --hard stable > Merging origin/master (746bb4ed6d62 Merge tag 'vla-v4.20-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux) > Merging fixes/master (eb81bfb224ce Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) > Applying: Revert "bridge: do not add port to router list when receives query > with source 0.0.0.0" > Applying: drivers: net: include linux/ip.h for iphdr > Merging kbuild-current/fixes (5318321d367c samples: disable CONFIG_SAMPLES > for UML) > Merging arc-current/for-curr (56d02dd9e794 ARC: IOC: panic if kernel was > started with previously enabled IOC) > Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() > offset check) > Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject > stand-alone CHAIN events for PMUv3) > Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and > m68k_pgtable_cachemode) > Merging powerpc-fixes/fixes (ac1788cc7da4 powerpc/numa: Skip onlining a > offline node in kdump path) > Merging sparc/master (345671ea0f92 Merge branch 'akpm' (patches from Andrew)) > Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) > Merging net/master (ece23711dd95 net: Properly unlink GRO packets on > overflow.) > Merging bpf/master (d8fd9e106fbc bpf: fix wrong helper enablement in cgroup > local storage) > Merging ipsec/master (6788fac82001 Merge > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) > Merging netfilter/master (5a8de47b3c25 netfilter: bridge: define INT_MIN & > INT_MAX in userspace) > Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic > updates of non-anonymous set) > Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD > queue size) > Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error > paths for netlink) > Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 > vulnerability) > Merging sound-current/for-linus (aedef16a63d5 ALSA: dice: fix to wait for > releases of all ALSA character devices) > Merging sound-asoc-fixes/for-linus (eafb621d62c7 Merge branch 'asoc-4.19' > into asoc-linus) > Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) > Merging regulator-fixes/for-linus (84df9525b0c2 Linux 4.19) > Merging spi-fixes/for-linus (599eb81f4118 Merge branch 'spi-4.19' into >
Re: linux-next: Tree for Oct 29
On Mo, 29. Okt 17:02, Stephen Rothwell wrote: > Hi all, > Hello Stephen, on the site isnt available the new linux-next ? Only the old one. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > Changes since 20181019: > > Linus' tree gained 2 build failures for which I reverted a commit and > added a fix patch. > > The arm-soc tree gained conflicts against Linus' tree. > > The vfs tree gained conflicts against the ceph and nfsd trees. > > The pm tree gained conflicts against Linus' and the i2c trees. > > The drivers-x86 tree gained a conflict against Linus' tree. > > Non-merge commits (relative to Linus' tree): 4593 > 4462 files changed, 276395 insertions(+), 77168 deletions(-) > > > > I have created today's linux-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you > are tracking the linux-next tree using git, you should not use "git pull" > to do so as that will try to merge the new linux-next release with the > old one. You should use "git fetch" and checkout or reset to the new > master. > > You can see which trees have been included by looking in the Next/Trees > file in the source. There are also quilt-import.log and merge.log > files in the Next directory. Between each merge, the tree was built > with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a > multi_v7_defconfig for arm and a native build of tools/perf. After > the final fixups (if any), I do an x86_64 modules_install followed by > builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), > ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc > and sparc64 defconfig. And finally, a simple boot test of the powerpc > pseries_le_defconfig kernel in qemu (with and without kvm enabled). > > Below is a summary of the state of the merge. > > I am currently merging 291 trees (counting Linus' and 66 trees of bug > fix patches pending for the current merge release). > > Stats about the size of the tree over time can be seen at > http://neuling.org/linux-next-size.html . > > Status of my local build tests will be at > http://kisskb.ellerman.id.au/linux-next . If maintainers want to give > advice about cross compilers/configs that work, we are always open to add > more builds. > > Thanks to Randy Dunlap for doing many randconfig builds. And to Paul > Gortmaker for triage and bug fixes. > > -- > Cheers, > Stephen Rothwell > > $ git checkout master > $ git reset --hard stable > Merging origin/master (746bb4ed6d62 Merge tag 'vla-v4.20-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux) > Merging fixes/master (eb81bfb224ce Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) > Applying: Revert "bridge: do not add port to router list when receives query > with source 0.0.0.0" > Applying: drivers: net: include linux/ip.h for iphdr > Merging kbuild-current/fixes (5318321d367c samples: disable CONFIG_SAMPLES > for UML) > Merging arc-current/for-curr (56d02dd9e794 ARC: IOC: panic if kernel was > started with previously enabled IOC) > Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() > offset check) > Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject > stand-alone CHAIN events for PMUv3) > Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and > m68k_pgtable_cachemode) > Merging powerpc-fixes/fixes (ac1788cc7da4 powerpc/numa: Skip onlining a > offline node in kdump path) > Merging sparc/master (345671ea0f92 Merge branch 'akpm' (patches from Andrew)) > Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) > Merging net/master (ece23711dd95 net: Properly unlink GRO packets on > overflow.) > Merging bpf/master (d8fd9e106fbc bpf: fix wrong helper enablement in cgroup > local storage) > Merging ipsec/master (6788fac82001 Merge > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) > Merging netfilter/master (5a8de47b3c25 netfilter: bridge: define INT_MIN & > INT_MAX in userspace) > Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic > updates of non-anonymous set) > Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD > queue size) > Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error > paths for netlink) > Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 > vulnerability) > Merging sound-current/for-linus (aedef16a63d5 ALSA: dice: fix to wait for > releases of all ALSA character devices) > Merging sound-asoc-fixes/for-linus (eafb621d62c7 Merge branch 'asoc-4.19' > into asoc-linus) > Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) > Merging regulator-fixes/for-linus (84df9525b0c2 Linux 4.19) > Merging spi-fixes/for-linus (599eb81f4118 Merge branch 'spi-4.19' into >
Kernel Build error with gcc 9
Hello all, i know GCC 9 is currently in deployment progress. But i tried to build a kernel 4.19RC8 with gcc 9 and i got the following error message: Kernel: arch/x86/boot/bzImage is ready (#1) ERROR: "__popcountdi2" [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined! ERROR: "__popcountdi2" [drivers/net/ethernet/broadcom/bnx2x/bnx2x.ko] undefined! /home/damian/kernel/linux/scripts/Makefile.modpost:92: die Regel für Ziel „__modpost“ scheiterte make[2]: *** [__modpost] Fehler 1 with gcc 8 it works fine. Any suggestion what could be the cause ? Best regards Damian
Kernel Build error with gcc 9
Hello all, i know GCC 9 is currently in deployment progress. But i tried to build a kernel 4.19RC8 with gcc 9 and i got the following error message: Kernel: arch/x86/boot/bzImage is ready (#1) ERROR: "__popcountdi2" [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined! ERROR: "__popcountdi2" [drivers/net/ethernet/broadcom/bnx2x/bnx2x.ko] undefined! /home/damian/kernel/linux/scripts/Makefile.modpost:92: die Regel für Ziel „__modpost“ scheiterte make[2]: *** [__modpost] Fehler 1 with gcc 8 it works fine. Any suggestion what could be the cause ? Best regards Damian
[PATCH v5 2/5] drm/dp: fix link probing for devices supporting DP 1.4+
From: Quentin Schulz
DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
"true capabilities" of DPRX device.
Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
might falsely return lower capabilities to "avoid interoperability
issues with some of the existing DP Source devices that malfunction
when they discover the higher capabilities within those three
registers.".
Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was reserved
and read 0 so it's safe to check against it even if DP revision is
<1.4
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
---
drivers/gpu/drm/drm_dp_helper.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8c6b9fd89f8a..735ebde5c2f0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -370,10 +370,38 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
{
u8 values[3];
int err;
+ unsigned int addr;
memset(link, 0, sizeof(*link));
- err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+ /*
+* DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
+* DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
+* DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
+* DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
+* DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
+* "true capabilities" of DPRX device.
+*
+* Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
+* might falsely return lower capabilities to "avoid interoperability
+* issues with some of the existing DP Source devices that malfunction
+* when they discover the higher capabilities within those three
+* registers.".
+*
+* Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was
reserved
+* and read 0 so it's safe to check against it even if DP revision is
+* <1.4
+*/
+ err = drm_dp_dpcd_readb(aux, DP_TRAINING_AUX_RD_INTERVAL, values);
+ if (err < 0)
+ return err;
+
+ if (values[0] & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)
+ addr = DP_DP13_DPCD_REV;
+ else
+ addr = DP_DPCD_REV;
+
+ err = drm_dp_dpcd_read(aux, addr, values, sizeof(values));
if (err < 0)
return err;
--
2.17.1
[PATCH v5 2/5] drm/dp: fix link probing for devices supporting DP 1.4+
From: Quentin Schulz
DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
"true capabilities" of DPRX device.
Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
might falsely return lower capabilities to "avoid interoperability
issues with some of the existing DP Source devices that malfunction
when they discover the higher capabilities within those three
registers.".
Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was reserved
and read 0 so it's safe to check against it even if DP revision is
<1.4
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
---
drivers/gpu/drm/drm_dp_helper.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8c6b9fd89f8a..735ebde5c2f0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -370,10 +370,38 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
{
u8 values[3];
int err;
+ unsigned int addr;
memset(link, 0, sizeof(*link));
- err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+ /*
+* DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
+* DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
+* DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
+* DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
+* DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
+* "true capabilities" of DPRX device.
+*
+* Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
+* might falsely return lower capabilities to "avoid interoperability
+* issues with some of the existing DP Source devices that malfunction
+* when they discover the higher capabilities within those three
+* registers.".
+*
+* Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was
reserved
+* and read 0 so it's safe to check against it even if DP revision is
+* <1.4
+*/
+ err = drm_dp_dpcd_readb(aux, DP_TRAINING_AUX_RD_INTERVAL, values);
+ if (err < 0)
+ return err;
+
+ if (values[0] & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)
+ addr = DP_DP13_DPCD_REV;
+ else
+ addr = DP_DPCD_REV;
+
+ err = drm_dp_dpcd_read(aux, addr, values, sizeof(values));
if (err < 0)
return err;
--
2.17.1
RE: [PATCH v3 1/5] drm/rockchip: prepare common code for cdns and rk dpi/dp driver
Thank you, Andrzej! I was a bit afraid that our patches are a bit too messy and thus ignored Anyway, this patch (1/5) should be the last one that will cause such chaos in the DRM area. Regards, Damian -Original Message- From: Andrzej Hajda Sent: Thursday, September 13, 2018 12:01 To: Damian Kos ; David Airlie ; Rob Herring ; Mark Rutland ; Archit Taneja ; Laurent Pinchart ; Gustavo Padovan ; Maarten Lankhorst ; Sean Paul ; Sandy Huang ; Heiko Stübner ; Quentin Schulz ; dri-de...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-rockc...@lists.infradead.org Cc: Przemyslaw Gaj ; Lukasz Tyrala ; Scott Telford ; Artur Jedrysek ; Piotr Sroka Subject: Re: [PATCH v3 1/5] drm/rockchip: prepare common code for cdns and rk dpi/dp driver EXTERNAL MAIL Hi Damian, Quite late but. On 28.08.2018 12:24, Damian Kos wrote: > - Extracted common fields from cdn_dp_device to a new cdns_mhdp_device > structure which will be used by two separate drivers later on. > - Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format, > video_info) from cdn-dp-core.c to cdn-dp-reg.h. > - Changed prefixes from cdn_dp to cdns_mhdp > cdn -> cdns to match the other Cadence's drivers > dp -> mhdp to distinguish it from a "just a DP" as the IP underneath > this registers map can be a HDMI (which is internally different, > but the interface for commands, events is pretty much the same). > - Modified cdn-dp-core.c to use the new driver structure and new function > names. > > Signed-off-by: Damian Kos Many changes, hard to review. Anyway: Reviewed-by: Andrzej Hajda -- Regards Andrzej
RE: [PATCH v3 1/5] drm/rockchip: prepare common code for cdns and rk dpi/dp driver
Thank you, Andrzej! I was a bit afraid that our patches are a bit too messy and thus ignored Anyway, this patch (1/5) should be the last one that will cause such chaos in the DRM area. Regards, Damian -Original Message- From: Andrzej Hajda Sent: Thursday, September 13, 2018 12:01 To: Damian Kos ; David Airlie ; Rob Herring ; Mark Rutland ; Archit Taneja ; Laurent Pinchart ; Gustavo Padovan ; Maarten Lankhorst ; Sean Paul ; Sandy Huang ; Heiko Stübner ; Quentin Schulz ; dri-de...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-rockc...@lists.infradead.org Cc: Przemyslaw Gaj ; Lukasz Tyrala ; Scott Telford ; Artur Jedrysek ; Piotr Sroka Subject: Re: [PATCH v3 1/5] drm/rockchip: prepare common code for cdns and rk dpi/dp driver EXTERNAL MAIL Hi Damian, Quite late but. On 28.08.2018 12:24, Damian Kos wrote: > - Extracted common fields from cdn_dp_device to a new cdns_mhdp_device > structure which will be used by two separate drivers later on. > - Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format, > video_info) from cdn-dp-core.c to cdn-dp-reg.h. > - Changed prefixes from cdn_dp to cdns_mhdp > cdn -> cdns to match the other Cadence's drivers > dp -> mhdp to distinguish it from a "just a DP" as the IP underneath > this registers map can be a HDMI (which is internally different, > but the interface for commands, events is pretty much the same). > - Modified cdn-dp-core.c to use the new driver structure and new function > names. > > Signed-off-by: Damian Kos Many changes, hard to review. Anyway: Reviewed-by: Andrzej Hajda -- Regards Andrzej
[PATCH 11/12] drm/rockchip: added implementation for a few FW commands.
Added support for a register read, register write and register field write
commands.
Added support for adjust link training command.
Updated cdn_dp_get_event function, so it reads all SW event registers.
Added definitions mostly for Framer and Streamer.
Signed-off-by: Damian Kos
---
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 167 -
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 143 +++-
2 files changed, 305 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..b061cfc 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -410,7 +410,10 @@ int cdn_dp_event_config(struct cdn_dp_device *dp)
u32 cdn_dp_get_event(struct cdn_dp_device *dp)
{
- return readl(dp->regs + SW_EVENTS0);
+ return readl(dp->regs + SW_EVENTS0)
+ | (readl(dp->regs + SW_EVENTS1) << 8)
+ | (readl(dp->regs + SW_EVENTS2) << 16)
+ | (readl(dp->regs + SW_EVENTS3) << 24);
}
int cdn_dp_get_hpd_status(struct cdn_dp_device *dp)
@@ -981,3 +984,165 @@ int cdn_dp_audio_config(struct cdn_dp_device *dp, struct
audio_info *audio)
DRM_DEV_ERROR(dp->dev, "audio config failed: %d\n", ret);
return ret;
}
+
+int cdn_dp_register_read(struct cdn_dp_device *dp, u32 addr, u32 *value)
+{
+ u8 msg[4], resp[8];
+ int ret;
+
+ if (addr == 0) {
+ ret = -EINVAL;
+ goto err_register_read;
+ }
+
+ msg[0] = (u8)(addr >> 24);
+ msg[1] = (u8)(addr >> 16);
+ msg[2] = (u8)(addr >> 8);
+ msg[3] = (u8)addr;
+
+ ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_GENERAL,
+ GENERAL_REGISTER_READ,
+ sizeof(msg), msg);
+ if (ret)
+ goto err_register_read;
+
+ ret = cdn_dp_mailbox_validate_receive(dp, MB_MODULE_ID_GENERAL,
+ GENERAL_REGISTER_READ,
+ sizeof(resp));
+ if (ret)
+ goto err_register_read;
+
+ ret = cdn_dp_mailbox_read_receive(dp, resp, sizeof(resp));
+ if (ret)
+ goto err_register_read;
+
+ /* Returned address value should be the same as requested */
+ if (memcmp(msg, resp, sizeof(msg))) {
+ ret = -EINVAL;
+ goto err_register_read;
+ }
+
+ *value = (resp[4] << 24) | (resp[5] << 16) | (resp[6] << 8) | resp[7];
+
+err_register_read:
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev, "Failed to read register.\n");
+ *value = 0;
+ }
+
+ return ret;
+}
+
+int cdn_dp_register_write(struct cdn_dp_device *dp, u32 addr, u32 value)
+{
+ u8 msg[8];
+ int ret;
+
+ if (addr == 0)
+ return -EINVAL;
+
+ msg[0] = (u8)(addr >> 24);
+ msg[1] = (u8)(addr >> 16);
+ msg[2] = (u8)(addr >> 8);
+ msg[3] = (u8)addr;
+ msg[4] = (u8)(value >> 24);
+ msg[5] = (u8)(value >> 16);
+ msg[6] = (u8)(value >> 8);
+ msg[7] = (u8)value;
+
+ ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_GENERAL,
+ GENERAL_REGISTER_WRITE,
+ sizeof(msg), msg);
+ if (ret)
+ DRM_DEV_ERROR(dp->dev, "Failed to write register.\n");
+
+ return ret;
+}
+
+int cdn_dp_register_write_field(struct cdn_dp_device *dp, u32 addr,
+ u8 index, u8 nbits, u32 value)
+{
+ u8 msg[10];
+ int ret;
+
+ if (addr == 0)
+ return -EINVAL;
+
+ msg[0] = (u8)(addr >> 24);
+ msg[1] = (u8)(addr >> 16);
+ msg[2] = (u8)(addr >> 8);
+ msg[3] = (u8)addr;
+ msg[4] = index;
+ msg[5] = nbits;
+ msg[6] = (u8)(value >> 24);
+ msg[7] = (u8)(value >> 16);
+ msg[8] = (u8)(value >> 8);
+ msg[9] = (u8)value;
+
+ ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_GENERAL,
+ GENERAL_REGISTER_WRITE_FIELD,
+ sizeof(msg), msg);
+ if (ret)
+ DRM_DEV_ERROR(dp->dev, "Failed to write register field.\n");
+
+ return ret;
+}
+/* rep should be a pointer already allocated with .regs of size 6 */
+int cdn_dp_adjust_lt(struct cdn_dp_device *dp, u8 nlanes,
+u16 udelay, u8 *lanes_data,
+u8 *dpcd)
+{
+ u8 payload[10];
+ u8 hdr[5]; /* For DPCD read response header */
+ u32 addr;
+ u8 const nregs = 6; /* Registers 0x202-0x207 */
+ int ret;
+
+ if (nlanes != 4 && nlanes != 2 && nlanes != 1) {
+ D
[PATCH 11/12] drm/rockchip: added implementation for a few FW commands.
Added support for a register read, register write and register field write
commands.
Added support for adjust link training command.
Updated cdn_dp_get_event function, so it reads all SW event registers.
Added definitions mostly for Framer and Streamer.
Signed-off-by: Damian Kos
---
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 167 -
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 143 +++-
2 files changed, 305 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..b061cfc 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -410,7 +410,10 @@ int cdn_dp_event_config(struct cdn_dp_device *dp)
u32 cdn_dp_get_event(struct cdn_dp_device *dp)
{
- return readl(dp->regs + SW_EVENTS0);
+ return readl(dp->regs + SW_EVENTS0)
+ | (readl(dp->regs + SW_EVENTS1) << 8)
+ | (readl(dp->regs + SW_EVENTS2) << 16)
+ | (readl(dp->regs + SW_EVENTS3) << 24);
}
int cdn_dp_get_hpd_status(struct cdn_dp_device *dp)
@@ -981,3 +984,165 @@ int cdn_dp_audio_config(struct cdn_dp_device *dp, struct
audio_info *audio)
DRM_DEV_ERROR(dp->dev, "audio config failed: %d\n", ret);
return ret;
}
+
+int cdn_dp_register_read(struct cdn_dp_device *dp, u32 addr, u32 *value)
+{
+ u8 msg[4], resp[8];
+ int ret;
+
+ if (addr == 0) {
+ ret = -EINVAL;
+ goto err_register_read;
+ }
+
+ msg[0] = (u8)(addr >> 24);
+ msg[1] = (u8)(addr >> 16);
+ msg[2] = (u8)(addr >> 8);
+ msg[3] = (u8)addr;
+
+ ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_GENERAL,
+ GENERAL_REGISTER_READ,
+ sizeof(msg), msg);
+ if (ret)
+ goto err_register_read;
+
+ ret = cdn_dp_mailbox_validate_receive(dp, MB_MODULE_ID_GENERAL,
+ GENERAL_REGISTER_READ,
+ sizeof(resp));
+ if (ret)
+ goto err_register_read;
+
+ ret = cdn_dp_mailbox_read_receive(dp, resp, sizeof(resp));
+ if (ret)
+ goto err_register_read;
+
+ /* Returned address value should be the same as requested */
+ if (memcmp(msg, resp, sizeof(msg))) {
+ ret = -EINVAL;
+ goto err_register_read;
+ }
+
+ *value = (resp[4] << 24) | (resp[5] << 16) | (resp[6] << 8) | resp[7];
+
+err_register_read:
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev, "Failed to read register.\n");
+ *value = 0;
+ }
+
+ return ret;
+}
+
+int cdn_dp_register_write(struct cdn_dp_device *dp, u32 addr, u32 value)
+{
+ u8 msg[8];
+ int ret;
+
+ if (addr == 0)
+ return -EINVAL;
+
+ msg[0] = (u8)(addr >> 24);
+ msg[1] = (u8)(addr >> 16);
+ msg[2] = (u8)(addr >> 8);
+ msg[3] = (u8)addr;
+ msg[4] = (u8)(value >> 24);
+ msg[5] = (u8)(value >> 16);
+ msg[6] = (u8)(value >> 8);
+ msg[7] = (u8)value;
+
+ ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_GENERAL,
+ GENERAL_REGISTER_WRITE,
+ sizeof(msg), msg);
+ if (ret)
+ DRM_DEV_ERROR(dp->dev, "Failed to write register.\n");
+
+ return ret;
+}
+
+int cdn_dp_register_write_field(struct cdn_dp_device *dp, u32 addr,
+ u8 index, u8 nbits, u32 value)
+{
+ u8 msg[10];
+ int ret;
+
+ if (addr == 0)
+ return -EINVAL;
+
+ msg[0] = (u8)(addr >> 24);
+ msg[1] = (u8)(addr >> 16);
+ msg[2] = (u8)(addr >> 8);
+ msg[3] = (u8)addr;
+ msg[4] = index;
+ msg[5] = nbits;
+ msg[6] = (u8)(value >> 24);
+ msg[7] = (u8)(value >> 16);
+ msg[8] = (u8)(value >> 8);
+ msg[9] = (u8)value;
+
+ ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_GENERAL,
+ GENERAL_REGISTER_WRITE_FIELD,
+ sizeof(msg), msg);
+ if (ret)
+ DRM_DEV_ERROR(dp->dev, "Failed to write register field.\n");
+
+ return ret;
+}
+/* rep should be a pointer already allocated with .regs of size 6 */
+int cdn_dp_adjust_lt(struct cdn_dp_device *dp, u8 nlanes,
+u16 udelay, u8 *lanes_data,
+u8 *dpcd)
+{
+ u8 payload[10];
+ u8 hdr[5]; /* For DPCD read response header */
+ u32 addr;
+ u8 const nregs = 6; /* Registers 0x202-0x207 */
+ int ret;
+
+ if (nlanes != 4 && nlanes != 2 && nlanes != 1) {
+ D
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On Wed, 16. May 18:05, Baoquan He wrote:
> Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to
> handle conflict between KASLR and huge pages, will be used in the next patch.
>
> Function parse_gb_huge_pages() is used to parse kernel command-line to get
> how many 1GB huge pages have been specified. A static global variable
> 'max_gb_huge_pages' is added to store the number.
>
> And process_gb_huge_page() is used to skip as many 1GB huge pages as possible
> from the passed in memory region according to the specified number.
>
> Signed-off-by: Baoquan He <b...@redhat.com>
> ---
> arch/x86/boot/compressed/kaslr.c | 71
>
> 1 file changed, 71 insertions(+)
>
> diff --git a/arch/x86/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index a0a50b91ecef..13bd879cdc5d 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -215,6 +215,32 @@ static void mem_avoid_memmap(char *str)
> memmap_too_large = true;
> }
>
> +/* Store the number of 1GB huge pages which user specified.*/
> +static unsigned long max_gb_huge_pages;
> +
> +static int parse_gb_huge_pages(char *param, char* val)
> +{
> + char *p;
> + u64 mem_size;
> + static bool gbpage_sz = false;
> +
> + if (!strcmp(param, "hugepagesz")) {
> + p = val;
> + mem_size = memparse(p, );
> + if (mem_size == PUD_SIZE) {
> + if (gbpage_sz)
> + warn("Repeadly set hugeTLB page size of 1G!\n");
> + gbpage_sz = true;
> + } else
> + gbpage_sz = false;
> + } else if (!strcmp(param, "hugepages") && gbpage_sz) {
> + p = val;
> + max_gb_huge_pages = simple_strtoull(p, , 0);
> + debug_putaddr(max_gb_huge_pages);
> + }
> +}
Hello,
the return value is missing for the function or not ?
regards
Damian
> +
> +
> static int handle_mem_memmap(void)
> {
> char *args = (char *)get_cmd_line_ptr();
> @@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
> unsigned long image_size)
> }
> }
>
> +/* Skip as many 1GB huge pages as possible in the passed region. */
> +static void process_gb_huge_page(struct mem_vector *region, unsigned long
> image_size)
> +{
> + int i = 0;
> + unsigned long addr, size;
> + struct mem_vector tmp;
> +
> + if (!max_gb_huge_pages) {
> + store_slot_info(region, image_size);
> + return;
> + }
> +
> + addr = ALIGN(region->start, PUD_SIZE);
> + /* If Did we raise the address above the passed in memory entry? */
> + if (addr < region->start + region->size)
> + size = region->size - (addr - region->start);
> +
> + /* Check how many 1GB huge pages can be filtered out*/
> + while (size > PUD_SIZE && max_gb_huge_pages) {
> + size -= PUD_SIZE;
> + max_gb_huge_pages--;
> + i++;
> + }
> +
> + if (!i) {
> + store_slot_info(region, image_size);
> + return;
> + }
> +
> + /* Process the remaining regions after filtering out. */
> +
> + if (addr >= region->start + image_size) {
> + tmp.start = region->start;
> + tmp.size = addr - region->start;
> + store_slot_info(, image_size);
> + }
> +
> + size = region->size - (addr - region->start) - i * PUD_SIZE;
> +if (size >= image_size) {
> + tmp.start = addr + i*PUD_SIZE;
> + tmp.size = size;
> + store_slot_info(, image_size);
> +}
> +}
> +
> static unsigned long slots_fetch_random(void)
> {
> unsigned long slot;
> --
> 2.13.6
>
Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling
On Wed, 16. May 18:05, Baoquan He wrote:
> Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to
> handle conflict between KASLR and huge pages, will be used in the next patch.
>
> Function parse_gb_huge_pages() is used to parse kernel command-line to get
> how many 1GB huge pages have been specified. A static global variable
> 'max_gb_huge_pages' is added to store the number.
>
> And process_gb_huge_page() is used to skip as many 1GB huge pages as possible
> from the passed in memory region according to the specified number.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/boot/compressed/kaslr.c | 71
>
> 1 file changed, 71 insertions(+)
>
> diff --git a/arch/x86/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index a0a50b91ecef..13bd879cdc5d 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -215,6 +215,32 @@ static void mem_avoid_memmap(char *str)
> memmap_too_large = true;
> }
>
> +/* Store the number of 1GB huge pages which user specified.*/
> +static unsigned long max_gb_huge_pages;
> +
> +static int parse_gb_huge_pages(char *param, char* val)
> +{
> + char *p;
> + u64 mem_size;
> + static bool gbpage_sz = false;
> +
> + if (!strcmp(param, "hugepagesz")) {
> + p = val;
> + mem_size = memparse(p, );
> + if (mem_size == PUD_SIZE) {
> + if (gbpage_sz)
> + warn("Repeadly set hugeTLB page size of 1G!\n");
> + gbpage_sz = true;
> + } else
> + gbpage_sz = false;
> + } else if (!strcmp(param, "hugepages") && gbpage_sz) {
> + p = val;
> + max_gb_huge_pages = simple_strtoull(p, , 0);
> + debug_putaddr(max_gb_huge_pages);
> + }
> +}
Hello,
the return value is missing for the function or not ?
regards
Damian
> +
> +
> static int handle_mem_memmap(void)
> {
> char *args = (char *)get_cmd_line_ptr();
> @@ -466,6 +492,51 @@ static void store_slot_info(struct mem_vector *region,
> unsigned long image_size)
> }
> }
>
> +/* Skip as many 1GB huge pages as possible in the passed region. */
> +static void process_gb_huge_page(struct mem_vector *region, unsigned long
> image_size)
> +{
> + int i = 0;
> + unsigned long addr, size;
> + struct mem_vector tmp;
> +
> + if (!max_gb_huge_pages) {
> + store_slot_info(region, image_size);
> + return;
> + }
> +
> + addr = ALIGN(region->start, PUD_SIZE);
> + /* If Did we raise the address above the passed in memory entry? */
> + if (addr < region->start + region->size)
> + size = region->size - (addr - region->start);
> +
> + /* Check how many 1GB huge pages can be filtered out*/
> + while (size > PUD_SIZE && max_gb_huge_pages) {
> + size -= PUD_SIZE;
> + max_gb_huge_pages--;
> + i++;
> + }
> +
> + if (!i) {
> + store_slot_info(region, image_size);
> + return;
> + }
> +
> + /* Process the remaining regions after filtering out. */
> +
> + if (addr >= region->start + image_size) {
> + tmp.start = region->start;
> + tmp.size = addr - region->start;
> + store_slot_info(, image_size);
> + }
> +
> + size = region->size - (addr - region->start) - i * PUD_SIZE;
> +if (size >= image_size) {
> + tmp.start = addr + i*PUD_SIZE;
> + tmp.size = size;
> + store_slot_info(, image_size);
> +}
> +}
> +
> static unsigned long slots_fetch_random(void)
> {
> unsigned long slot;
> --
> 2.13.6
>
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
On Wed, 09. May 22:18, damian wrote:
> On Wed, 09. May 09:36, Hans de Goede wrote:
> > Hi,
> >
> > On 08-05-18 21:41, damian wrote:
> > >On Tue, 08. May 13:42, Hans de Goede wrote:
> > >>Hi Damian,
> > >>
> > >>On 02-05-18 22:46, damian wrote:
> > >>>Hello Greg,
> > >>>
> > >>>it is PATCH 3 virt: vbox: Use __get_free_pages insteas of kmalloc for
> > >>>DMA32 memory.
> > >>
> > >>Thank you for the bug report, I've tried to reproduce this problem
> > >>but for me everything works fine.
> > >>
> > >>Does your virtual-machine have more then 4G of RAM configured for its
> > >>use? If yes then what is likely happening is that you also have
> > >>the out-of-tree version of the vboxguest modules installed and prior
> > >>to the commit in question the out of tree version of the driver is
> > >>loading, because before that commit the vboxguest driver in the
> > >>mainline kernel fails to load on machines with more then 4G.
> > >>
> > >>Or alternatively before the commit in question you may not have
> > >>any version of the vboxguest driver loaded.
> > >>
> > >>Using the upstream version of the driver should not make a noticeable
> > >>difference, but before the vboxguest driver became a part of the
> > >>mainline kernel the virtualbox upstream developers have done a
> > >>cleanup / redesign of the userspace API of the vboxguest driver,
> > >>so the vboxguest driver will only work with recent
> > >>virtualbox-guest-additions
> > >>and since you are using Ubuntu 16.04 chances are that you are
> > >>using that with Ubuntu's quite old bundled virtualbox-guest-additions
> > >>which will not work with the new driver and may be causing this
> > >>issue.
> > >>
> > >>Can you try upgrading your virtualbox-guest-additions to 5.2.10
> > >>please?
> > >>
> > >>Also if the above does not help, a couple of follow up
> > >>questions to help this pin down further:
> > >>
> > >>1) Are you using vbox's 3d pass through functionality
> > >>2) Which desktop-environment are you using?
> > >>
> > >>Regards,
> > >>
> > >>Hans
> > >
> > >Hi Hans,
> > >
> > >i will check my configutation and will come back
> > >At the moment i dont use use the virtualbox-guest-additions, i use the
> > >driver from the staging area.
> >
> > Ah I see, you may still have the Ubuntu pkg for them installed though,
> > which may be an old version which actually starts to try and do stuff
> > now that there is a vboxguest driver in mainline too, but that old
> > version does not support the new, stable API as merged into the
> > mainline.
> >
> > So if you don't care about the add-ons instead of upgrading yopu
> > can also remove the Ubuntu pkg for them.
> >
> > Regards,
> >
> > Hans
>
> Hello Hans,
>
> the reason why i dont use the virtual-guest-additions from virtualbox is the
> following with kernel 4.14rc4:
>
> there are changes in the kernel and this need time to fix in virtualbox.
>
>
> CC [M]
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbva_base.o
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c: In
> Funktion »vbox_ttm_tt_create«:
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:219:22:
> Fehler: Übergabe des Arguments 2 von »ttm_tt_init« von inkompatiblem
> Zeigertyp [-Werror=incompatible-pointer-types]
> if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
> ^~~~
> In file included from
> /home/damian/kernel/linux/include/drm/ttm/ttm_bo_driver.h:45,
> from
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_drv.h:69,
> from
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:31:
> /home/damian/kernel/linux/include/drm/ttm/ttm_tt.h:161:63: Anmerkung: »struct
> ttm_buffer_object *« erwartet, aber Argument hat Typ »struct ttm_bo_device *«
> int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
> ~~^~
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:219:6:
> Fehler: zu viele Argumente für Funktion »ttm_tt_init«
> if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
> ^~~
> In file included from
> /home/damian/kernel/linux/include/drm/ttm/ttm_bo_driver.h:45,
> from
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_drv.h:69,
> from
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:31:
> /home/damian/kernel/linux/include/drm/ttm/ttm_tt.h:161:5: Anmerkung: hier
> deklariert
> int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
> ^~~
>
> Best regards
> Damian
>
Sorry I mean Kernel 4.17rc4 :-)
Damian
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
On Wed, 09. May 22:18, damian wrote:
> On Wed, 09. May 09:36, Hans de Goede wrote:
> > Hi,
> >
> > On 08-05-18 21:41, damian wrote:
> > >On Tue, 08. May 13:42, Hans de Goede wrote:
> > >>Hi Damian,
> > >>
> > >>On 02-05-18 22:46, damian wrote:
> > >>>Hello Greg,
> > >>>
> > >>>it is PATCH 3 virt: vbox: Use __get_free_pages insteas of kmalloc for
> > >>>DMA32 memory.
> > >>
> > >>Thank you for the bug report, I've tried to reproduce this problem
> > >>but for me everything works fine.
> > >>
> > >>Does your virtual-machine have more then 4G of RAM configured for its
> > >>use? If yes then what is likely happening is that you also have
> > >>the out-of-tree version of the vboxguest modules installed and prior
> > >>to the commit in question the out of tree version of the driver is
> > >>loading, because before that commit the vboxguest driver in the
> > >>mainline kernel fails to load on machines with more then 4G.
> > >>
> > >>Or alternatively before the commit in question you may not have
> > >>any version of the vboxguest driver loaded.
> > >>
> > >>Using the upstream version of the driver should not make a noticeable
> > >>difference, but before the vboxguest driver became a part of the
> > >>mainline kernel the virtualbox upstream developers have done a
> > >>cleanup / redesign of the userspace API of the vboxguest driver,
> > >>so the vboxguest driver will only work with recent
> > >>virtualbox-guest-additions
> > >>and since you are using Ubuntu 16.04 chances are that you are
> > >>using that with Ubuntu's quite old bundled virtualbox-guest-additions
> > >>which will not work with the new driver and may be causing this
> > >>issue.
> > >>
> > >>Can you try upgrading your virtualbox-guest-additions to 5.2.10
> > >>please?
> > >>
> > >>Also if the above does not help, a couple of follow up
> > >>questions to help this pin down further:
> > >>
> > >>1) Are you using vbox's 3d pass through functionality
> > >>2) Which desktop-environment are you using?
> > >>
> > >>Regards,
> > >>
> > >>Hans
> > >
> > >Hi Hans,
> > >
> > >i will check my configutation and will come back
> > >At the moment i dont use use the virtualbox-guest-additions, i use the
> > >driver from the staging area.
> >
> > Ah I see, you may still have the Ubuntu pkg for them installed though,
> > which may be an old version which actually starts to try and do stuff
> > now that there is a vboxguest driver in mainline too, but that old
> > version does not support the new, stable API as merged into the
> > mainline.
> >
> > So if you don't care about the add-ons instead of upgrading yopu
> > can also remove the Ubuntu pkg for them.
> >
> > Regards,
> >
> > Hans
>
> Hello Hans,
>
> the reason why i dont use the virtual-guest-additions from virtualbox is the
> following with kernel 4.14rc4:
>
> there are changes in the kernel and this need time to fix in virtualbox.
>
>
> CC [M]
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbva_base.o
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c: In
> Funktion »vbox_ttm_tt_create«:
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:219:22:
> Fehler: Übergabe des Arguments 2 von »ttm_tt_init« von inkompatiblem
> Zeigertyp [-Werror=incompatible-pointer-types]
> if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
> ^~~~
> In file included from
> /home/damian/kernel/linux/include/drm/ttm/ttm_bo_driver.h:45,
> from
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_drv.h:69,
> from
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:31:
> /home/damian/kernel/linux/include/drm/ttm/ttm_tt.h:161:63: Anmerkung: »struct
> ttm_buffer_object *« erwartet, aber Argument hat Typ »struct ttm_bo_device *«
> int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
> ~~^~
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:219:6:
> Fehler: zu viele Argumente für Funktion »ttm_tt_init«
> if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
> ^~~
> In file included from
> /home/damian/kernel/linux/include/drm/ttm/ttm_bo_driver.h:45,
> from
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_drv.h:69,
> from
> /opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:31:
> /home/damian/kernel/linux/include/drm/ttm/ttm_tt.h:161:5: Anmerkung: hier
> deklariert
> int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
> ^~~
>
> Best regards
> Damian
>
Sorry I mean Kernel 4.17rc4 :-)
Damian
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
On Wed, 09. May 09:36, Hans de Goede wrote:
> Hi,
>
> On 08-05-18 21:41, damian wrote:
> >On Tue, 08. May 13:42, Hans de Goede wrote:
> >>Hi Damian,
> >>
> >>On 02-05-18 22:46, damian wrote:
> >>>Hello Greg,
> >>>
> >>>it is PATCH 3 virt: vbox: Use __get_free_pages insteas of kmalloc for
> >>>DMA32 memory.
> >>
> >>Thank you for the bug report, I've tried to reproduce this problem
> >>but for me everything works fine.
> >>
> >>Does your virtual-machine have more then 4G of RAM configured for its
> >>use? If yes then what is likely happening is that you also have
> >>the out-of-tree version of the vboxguest modules installed and prior
> >>to the commit in question the out of tree version of the driver is
> >>loading, because before that commit the vboxguest driver in the
> >>mainline kernel fails to load on machines with more then 4G.
> >>
> >>Or alternatively before the commit in question you may not have
> >>any version of the vboxguest driver loaded.
> >>
> >>Using the upstream version of the driver should not make a noticeable
> >>difference, but before the vboxguest driver became a part of the
> >>mainline kernel the virtualbox upstream developers have done a
> >>cleanup / redesign of the userspace API of the vboxguest driver,
> >>so the vboxguest driver will only work with recent
> >>virtualbox-guest-additions
> >>and since you are using Ubuntu 16.04 chances are that you are
> >>using that with Ubuntu's quite old bundled virtualbox-guest-additions
> >>which will not work with the new driver and may be causing this
> >>issue.
> >>
> >>Can you try upgrading your virtualbox-guest-additions to 5.2.10
> >>please?
> >>
> >>Also if the above does not help, a couple of follow up
> >>questions to help this pin down further:
> >>
> >>1) Are you using vbox's 3d pass through functionality
> >>2) Which desktop-environment are you using?
> >>
> >>Regards,
> >>
> >>Hans
> >
> >Hi Hans,
> >
> >i will check my configutation and will come back
> >At the moment i dont use use the virtualbox-guest-additions, i use the
> >driver from the staging area.
>
> Ah I see, you may still have the Ubuntu pkg for them installed though,
> which may be an old version which actually starts to try and do stuff
> now that there is a vboxguest driver in mainline too, but that old
> version does not support the new, stable API as merged into the
> mainline.
>
> So if you don't care about the add-ons instead of upgrading yopu
> can also remove the Ubuntu pkg for them.
>
> Regards,
>
> Hans
Hello Hans,
the reason why i dont use the virtual-guest-additions from virtualbox is the
following with kernel 4.14rc4:
there are changes in the kernel and this need time to fix in virtualbox.
CC [M]
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbva_base.o
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c: In
Funktion »vbox_ttm_tt_create«:
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:219:22:
Fehler: Übergabe des Arguments 2 von »ttm_tt_init« von inkompatiblem Zeigertyp
[-Werror=incompatible-pointer-types]
if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
^~~~
In file included from
/home/damian/kernel/linux/include/drm/ttm/ttm_bo_driver.h:45,
from
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_drv.h:69,
from
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:31:
/home/damian/kernel/linux/include/drm/ttm/ttm_tt.h:161:63: Anmerkung: »struct
ttm_buffer_object *« erwartet, aber Argument hat Typ »struct ttm_bo_device *«
int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
~~^~
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:219:6:
Fehler: zu viele Argumente für Funktion »ttm_tt_init«
if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
^~~
In file included from
/home/damian/kernel/linux/include/drm/ttm/ttm_bo_driver.h:45,
from
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_drv.h:69,
from
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:31:
/home/damian/kernel/linux/include/drm/ttm/ttm_tt.h:161:5: Anmerkung: hier
deklariert
int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
^~~
Best regards
Damian
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
On Wed, 09. May 09:36, Hans de Goede wrote:
> Hi,
>
> On 08-05-18 21:41, damian wrote:
> >On Tue, 08. May 13:42, Hans de Goede wrote:
> >>Hi Damian,
> >>
> >>On 02-05-18 22:46, damian wrote:
> >>>Hello Greg,
> >>>
> >>>it is PATCH 3 virt: vbox: Use __get_free_pages insteas of kmalloc for
> >>>DMA32 memory.
> >>
> >>Thank you for the bug report, I've tried to reproduce this problem
> >>but for me everything works fine.
> >>
> >>Does your virtual-machine have more then 4G of RAM configured for its
> >>use? If yes then what is likely happening is that you also have
> >>the out-of-tree version of the vboxguest modules installed and prior
> >>to the commit in question the out of tree version of the driver is
> >>loading, because before that commit the vboxguest driver in the
> >>mainline kernel fails to load on machines with more then 4G.
> >>
> >>Or alternatively before the commit in question you may not have
> >>any version of the vboxguest driver loaded.
> >>
> >>Using the upstream version of the driver should not make a noticeable
> >>difference, but before the vboxguest driver became a part of the
> >>mainline kernel the virtualbox upstream developers have done a
> >>cleanup / redesign of the userspace API of the vboxguest driver,
> >>so the vboxguest driver will only work with recent
> >>virtualbox-guest-additions
> >>and since you are using Ubuntu 16.04 chances are that you are
> >>using that with Ubuntu's quite old bundled virtualbox-guest-additions
> >>which will not work with the new driver and may be causing this
> >>issue.
> >>
> >>Can you try upgrading your virtualbox-guest-additions to 5.2.10
> >>please?
> >>
> >>Also if the above does not help, a couple of follow up
> >>questions to help this pin down further:
> >>
> >>1) Are you using vbox's 3d pass through functionality
> >>2) Which desktop-environment are you using?
> >>
> >>Regards,
> >>
> >>Hans
> >
> >Hi Hans,
> >
> >i will check my configutation and will come back
> >At the moment i dont use use the virtualbox-guest-additions, i use the
> >driver from the staging area.
>
> Ah I see, you may still have the Ubuntu pkg for them installed though,
> which may be an old version which actually starts to try and do stuff
> now that there is a vboxguest driver in mainline too, but that old
> version does not support the new, stable API as merged into the
> mainline.
>
> So if you don't care about the add-ons instead of upgrading yopu
> can also remove the Ubuntu pkg for them.
>
> Regards,
>
> Hans
Hello Hans,
the reason why i dont use the virtual-guest-additions from virtualbox is the
following with kernel 4.14rc4:
there are changes in the kernel and this need time to fix in virtualbox.
CC [M]
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbva_base.o
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c: In
Funktion »vbox_ttm_tt_create«:
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:219:22:
Fehler: Übergabe des Arguments 2 von »ttm_tt_init« von inkompatiblem Zeigertyp
[-Werror=incompatible-pointer-types]
if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
^~~~
In file included from
/home/damian/kernel/linux/include/drm/ttm/ttm_bo_driver.h:45,
from
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_drv.h:69,
from
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:31:
/home/damian/kernel/linux/include/drm/ttm/ttm_tt.h:161:63: Anmerkung: »struct
ttm_buffer_object *« erwartet, aber Argument hat Typ »struct ttm_bo_device *«
int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
~~^~
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:219:6:
Fehler: zu viele Argumente für Funktion »ttm_tt_init«
if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
^~~
In file included from
/home/damian/kernel/linux/include/drm/ttm/ttm_bo_driver.h:45,
from
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_drv.h:69,
from
/opt/VBoxGuestAdditions-5.2.97/src/vboxguest-5.2.97/vboxvideo/vbox_ttm.c:31:
/home/damian/kernel/linux/include/drm/ttm/ttm_tt.h:161:5: Anmerkung: hier
deklariert
int ttm_tt_init(struct ttm_tt *ttm, struct ttm_buffer_object *bo,
^~~
Best regards
Damian
Re: Kernel build with gcc 8 a lot of warnings
On Wed, 09. May 10:23, Josh Poimboeuf wrote: > On Wed, May 09, 2018 at 09:35:04AM +0200, damian wrote: > > Hi Josh, > > > > i tested the patch on my maschine it works fine. > > > > Best regards > > Damian > > Thanks. 0-day found a few more issues. The latest patches are at: > > git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux objtool-gcc8 > > Waiting for 0-day to run them again, then I'll be submitting them > shortly after. > > -- > Josh Hi Josh, my test was successfull. regards Damian
Re: Kernel build with gcc 8 a lot of warnings
On Wed, 09. May 10:23, Josh Poimboeuf wrote: > On Wed, May 09, 2018 at 09:35:04AM +0200, damian wrote: > > Hi Josh, > > > > i tested the patch on my maschine it works fine. > > > > Best regards > > Damian > > Thanks. 0-day found a few more issues. The latest patches are at: > > git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux objtool-gcc8 > > Waiting for 0-day to run them again, then I'll be submitting them > shortly after. > > -- > Josh Hi Josh, my test was successfull. regards Damian
Re: Kernel build with gcc 8 a lot of warnings
Hi Josh,
i tested the patch on my maschine it works fine.
Best regards
Damian
On Tue, 08. May 22:46, Josh Poimboeuf wrote:
> On Tue, May 08, 2018 at 09:32:41AM -0500, Josh Poimboeuf wrote:
> > On Tue, May 08, 2018 at 04:25:15PM +0200, Greg KH wrote:
> > > Much nicer, thanks for the patch, seems to build things "quieter" now.
> > > For the other warnings, they are "safe" to ignore, right? It's just
> > > objtool checking to see if all is ok, but the result should be fine no
> > > matter what, right?
> >
> > Yeah, from what I can tell, there's nothing catastrophic in the rest of
> > the warnings. Worst case, the ORC unwinder might get confused in a few
> > places.
>
> FWIW, here's the latest version of the patch. This fixes all the
> warnings on my config at least. I'll be sending it to -tip soon if it
> survives 0-day testing.
>
> From: Josh Poimboeuf <jpoim...@redhat.com>
> Subject: [PATCH] objtool: Detect GCC 8 cold subfunctions
>
> GCC 8 moves a lot of unlikely code out of line to "cold" subfunctions in
> .text.unlikely. Properly detect the new subfunctions and treat them as
> extensions of the original functions.
>
> This fixes a bunch of warnings like:
>
> kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x33:
> sibling call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x290:
> sibling call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool:
> cgroup_apply_control_enable()+0x25b: sibling call from callable instruction
> with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x325:
> sibling call from callable instruction with modified stack frame
>
> Reported-by: Arnd Bergmann <a...@arndb.de>
> Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>
> ---
> tools/objtool/check.c | 104 +-
> tools/objtool/elf.c | 42 -
> tools/objtool/elf.h | 2 +
> 3 files changed, 104 insertions(+), 44 deletions(-)
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 264522d4e4af..ee72958d3464 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -59,6 +59,31 @@ static struct instruction *next_insn_same_sec(struct
> objtool_file *file,
> return next;
> }
>
> +static struct instruction *next_insn_same_func(struct objtool_file *file,
> +struct instruction *insn)
> +{
> + struct instruction *next = list_next_entry(insn, list);
> + struct symbol *func = insn->func;
> +
> + if (!func)
> + return NULL;
> +
> + if (>list != >insn_list && next->func == func)
> + return next;
> +
> + /* Check if we're already in the subfunction: */
> + if (func == func->cfunc)
> + return NULL;
> +
> + /* Move to the subfunction: */
> + return find_insn(file, func->cfunc->sec, func->cfunc->offset);
> +}
> +
> +#define func_for_each_insn_all(file, func, insn) \
> + for (insn = find_insn(file, func->sec, func->offset); \
> + insn; \
> + insn = next_insn_same_func(file, insn))
> +
> #define func_for_each_insn(file, func, insn) \
> for (insn = find_insn(file, func->sec, func->offset); \
>insn && >list != >insn_list && \
> @@ -149,10 +174,14 @@ static int __dead_end_function(struct objtool_file
> *file, struct symbol *func,
> if (!strcmp(func->name, global_noreturns[i]))
> return 1;
>
> - if (!func->sec)
> + if (!func->len)
> return 0;
>
> - func_for_each_insn(file, func, insn) {
> + insn = find_insn(file, func->sec, func->offset);
> + if (!insn->func)
> + return 0;
> +
> + func_for_each_insn_all(file, func, insn) {
> empty = false;
>
> if (insn->type == INSN_RETURN)
> @@ -167,28 +196,17 @@ static int __dead_end_function(struct objtool_file
> *file, struct symbol *func,
>* case, the function's dead-end status depends on whether the target
>* of the sibling call returns.
>*/
> - func_for_each_insn(file, func, insn) {
> - if (insn->sec != func->sec ||
> - insn->of
Re: Kernel build with gcc 8 a lot of warnings
Hi Josh,
i tested the patch on my maschine it works fine.
Best regards
Damian
On Tue, 08. May 22:46, Josh Poimboeuf wrote:
> On Tue, May 08, 2018 at 09:32:41AM -0500, Josh Poimboeuf wrote:
> > On Tue, May 08, 2018 at 04:25:15PM +0200, Greg KH wrote:
> > > Much nicer, thanks for the patch, seems to build things "quieter" now.
> > > For the other warnings, they are "safe" to ignore, right? It's just
> > > objtool checking to see if all is ok, but the result should be fine no
> > > matter what, right?
> >
> > Yeah, from what I can tell, there's nothing catastrophic in the rest of
> > the warnings. Worst case, the ORC unwinder might get confused in a few
> > places.
>
> FWIW, here's the latest version of the patch. This fixes all the
> warnings on my config at least. I'll be sending it to -tip soon if it
> survives 0-day testing.
>
> From: Josh Poimboeuf
> Subject: [PATCH] objtool: Detect GCC 8 cold subfunctions
>
> GCC 8 moves a lot of unlikely code out of line to "cold" subfunctions in
> .text.unlikely. Properly detect the new subfunctions and treat them as
> extensions of the original functions.
>
> This fixes a bunch of warnings like:
>
> kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x33:
> sibling call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x290:
> sibling call from callable instruction with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool:
> cgroup_apply_control_enable()+0x25b: sibling call from callable instruction
> with modified stack frame
> kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x325:
> sibling call from callable instruction with modified stack frame
>
> Reported-by: Arnd Bergmann
> Signed-off-by: Josh Poimboeuf
> ---
> tools/objtool/check.c | 104 +-
> tools/objtool/elf.c | 42 -
> tools/objtool/elf.h | 2 +
> 3 files changed, 104 insertions(+), 44 deletions(-)
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 264522d4e4af..ee72958d3464 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -59,6 +59,31 @@ static struct instruction *next_insn_same_sec(struct
> objtool_file *file,
> return next;
> }
>
> +static struct instruction *next_insn_same_func(struct objtool_file *file,
> +struct instruction *insn)
> +{
> + struct instruction *next = list_next_entry(insn, list);
> + struct symbol *func = insn->func;
> +
> + if (!func)
> + return NULL;
> +
> + if (>list != >insn_list && next->func == func)
> + return next;
> +
> + /* Check if we're already in the subfunction: */
> + if (func == func->cfunc)
> + return NULL;
> +
> + /* Move to the subfunction: */
> + return find_insn(file, func->cfunc->sec, func->cfunc->offset);
> +}
> +
> +#define func_for_each_insn_all(file, func, insn) \
> + for (insn = find_insn(file, func->sec, func->offset); \
> + insn; \
> + insn = next_insn_same_func(file, insn))
> +
> #define func_for_each_insn(file, func, insn) \
> for (insn = find_insn(file, func->sec, func->offset); \
>insn && >list != >insn_list && \
> @@ -149,10 +174,14 @@ static int __dead_end_function(struct objtool_file
> *file, struct symbol *func,
> if (!strcmp(func->name, global_noreturns[i]))
> return 1;
>
> - if (!func->sec)
> + if (!func->len)
> return 0;
>
> - func_for_each_insn(file, func, insn) {
> + insn = find_insn(file, func->sec, func->offset);
> + if (!insn->func)
> + return 0;
> +
> + func_for_each_insn_all(file, func, insn) {
> empty = false;
>
> if (insn->type == INSN_RETURN)
> @@ -167,28 +196,17 @@ static int __dead_end_function(struct objtool_file
> *file, struct symbol *func,
>* case, the function's dead-end status depends on whether the target
>* of the sibling call returns.
>*/
> - func_for_each_insn(file, func, insn) {
> - if (insn->sec != func->sec ||
> - insn->offset >= func->offset + func->len)
> - break;
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
On Tue, 08. May 13:42, Hans de Goede wrote: > Hi Damian, > > On 02-05-18 22:46, damian wrote: > >Hello Greg, > > > >it is PATCH 3 virt: vbox: Use __get_free_pages insteas of kmalloc for DMA32 > >memory. > > Thank you for the bug report, I've tried to reproduce this problem > but for me everything works fine. > > Does your virtual-machine have more then 4G of RAM configured for its > use? If yes then what is likely happening is that you also have > the out-of-tree version of the vboxguest modules installed and prior > to the commit in question the out of tree version of the driver is > loading, because before that commit the vboxguest driver in the > mainline kernel fails to load on machines with more then 4G. > > Or alternatively before the commit in question you may not have > any version of the vboxguest driver loaded. > > Using the upstream version of the driver should not make a noticeable > difference, but before the vboxguest driver became a part of the > mainline kernel the virtualbox upstream developers have done a > cleanup / redesign of the userspace API of the vboxguest driver, > so the vboxguest driver will only work with recent virtualbox-guest-additions > and since you are using Ubuntu 16.04 chances are that you are > using that with Ubuntu's quite old bundled virtualbox-guest-additions > which will not work with the new driver and may be causing this > issue. > > Can you try upgrading your virtualbox-guest-additions to 5.2.10 > please? > > Also if the above does not help, a couple of follow up > questions to help this pin down further: > > 1) Are you using vbox's 3d pass through functionality > 2) Which desktop-environment are you using? > > Regards, > > Hans Hi Hans, i will check my configutation and will come back At the moment i dont use use the virtualbox-guest-additions, i use the driver from the staging area. because i had after every new kernel release problms with this driver. regards Damian
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
On Tue, 08. May 13:42, Hans de Goede wrote: > Hi Damian, > > On 02-05-18 22:46, damian wrote: > >Hello Greg, > > > >it is PATCH 3 virt: vbox: Use __get_free_pages insteas of kmalloc for DMA32 > >memory. > > Thank you for the bug report, I've tried to reproduce this problem > but for me everything works fine. > > Does your virtual-machine have more then 4G of RAM configured for its > use? If yes then what is likely happening is that you also have > the out-of-tree version of the vboxguest modules installed and prior > to the commit in question the out of tree version of the driver is > loading, because before that commit the vboxguest driver in the > mainline kernel fails to load on machines with more then 4G. > > Or alternatively before the commit in question you may not have > any version of the vboxguest driver loaded. > > Using the upstream version of the driver should not make a noticeable > difference, but before the vboxguest driver became a part of the > mainline kernel the virtualbox upstream developers have done a > cleanup / redesign of the userspace API of the vboxguest driver, > so the vboxguest driver will only work with recent virtualbox-guest-additions > and since you are using Ubuntu 16.04 chances are that you are > using that with Ubuntu's quite old bundled virtualbox-guest-additions > which will not work with the new driver and may be causing this > issue. > > Can you try upgrading your virtualbox-guest-additions to 5.2.10 > please? > > Also if the above does not help, a couple of follow up > questions to help this pin down further: > > 1) Are you using vbox's 3d pass through functionality > 2) Which desktop-environment are you using? > > Regards, > > Hans Hi Hans, i will check my configutation and will come back At the moment i dont use use the virtualbox-guest-additions, i use the driver from the staging area. because i had after every new kernel release problms with this driver. regards Damian
Re: Kernel build with gcc 8 a lot of warnings
On Sun, 06. May 23:54, Josh Poimboeuf wrote: > On Sat, May 05, 2018 at 09:21:12PM +0200, damian wrote: > > Helllo together, > > > > Hello everybody, > > > > is something special to note when kernel build with gcc 8? I receive > > various warnings from the objtool: > > With GCC 7 works all fine. > > > > kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x40: > > sibling call from callable instruction with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x2a3: > > sibling call from callable instruction with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: > > cgroup_apply_control_enable()+0x20b: sibling call from callable instruction > > with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x296: > > sibling call from callable instruction with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable()+0x10: > > sibling call from callable instruction with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: > > parse_cgroup_root_flags.cold.45()+0xa: call without frame pointer save/setup > > kernel/cgroup/cgroup.o: warning: objtool: > > cgroup_addrm_files.cold.46()+0x17: call without frame pointer save/setup > > kernel/cgroup/cgroup.o: warning: objtool: > > cgroup_apply_control_enable.cold.47()+0x24: call without frame pointer > > save/setup > > kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems.cold.48()+0x10: > > call without frame pointer save/setup > > kernel/cgroup/cgroup.o: warning: objtool: > > cgroup_sk_alloc_disable.cold.49()+0x7: call without frame pointer save/setup > > CC kernel/cgroup/stat.o > > CC [M] arch/x86/kvm/../../../virt/kvm/kvm_main.o > > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic()+0x10: > > sibling call from callable instruction with modified stack frame > > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu()+0x2c: sibling > > call from callable instruction with modified stack frame > > arch/x86/kernel/acpi/boot.o: warning: objtool: > > acpi_register_lapic.cold.6()+0x7: call without frame pointer save/setup > > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu.cold.7()+0x7: > > call without frame pointer save/setup > > Thanks, this is a known issue with GCC 8 that I haven't gotten a chance > to fix yet. They're related to the fact that GCC 8 is splitting out > 'unlikely' code into 'cold' subfunctions in .text.unlikely. > > I've got some old patches that fix it. Now that GCC 8 is out, I'll need > get the patches dusted off and cleaned up for merging. > > -- > Josh Hello Josh, if you need any additional information, please feel free and contact me. Best regards Damian
Re: Kernel build with gcc 8 a lot of warnings
On Sun, 06. May 23:54, Josh Poimboeuf wrote: > On Sat, May 05, 2018 at 09:21:12PM +0200, damian wrote: > > Helllo together, > > > > Hello everybody, > > > > is something special to note when kernel build with gcc 8? I receive > > various warnings from the objtool: > > With GCC 7 works all fine. > > > > kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x40: > > sibling call from callable instruction with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x2a3: > > sibling call from callable instruction with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: > > cgroup_apply_control_enable()+0x20b: sibling call from callable instruction > > with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x296: > > sibling call from callable instruction with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable()+0x10: > > sibling call from callable instruction with modified stack frame > > kernel/cgroup/cgroup.o: warning: objtool: > > parse_cgroup_root_flags.cold.45()+0xa: call without frame pointer save/setup > > kernel/cgroup/cgroup.o: warning: objtool: > > cgroup_addrm_files.cold.46()+0x17: call without frame pointer save/setup > > kernel/cgroup/cgroup.o: warning: objtool: > > cgroup_apply_control_enable.cold.47()+0x24: call without frame pointer > > save/setup > > kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems.cold.48()+0x10: > > call without frame pointer save/setup > > kernel/cgroup/cgroup.o: warning: objtool: > > cgroup_sk_alloc_disable.cold.49()+0x7: call without frame pointer save/setup > > CC kernel/cgroup/stat.o > > CC [M] arch/x86/kvm/../../../virt/kvm/kvm_main.o > > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic()+0x10: > > sibling call from callable instruction with modified stack frame > > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu()+0x2c: sibling > > call from callable instruction with modified stack frame > > arch/x86/kernel/acpi/boot.o: warning: objtool: > > acpi_register_lapic.cold.6()+0x7: call without frame pointer save/setup > > arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu.cold.7()+0x7: > > call without frame pointer save/setup > > Thanks, this is a known issue with GCC 8 that I haven't gotten a chance > to fix yet. They're related to the fact that GCC 8 is splitting out > 'unlikely' code into 'cold' subfunctions in .text.unlikely. > > I've got some old patches that fix it. Now that GCC 8 is out, I'll need > get the patches dusted off and cleaned up for merging. > > -- > Josh Hello Josh, if you need any additional information, please feel free and contact me. Best regards Damian
Kernel build with gcc 8 a lot of warnings
Helllo together, Hello everybody, is something special to note when kernel build with gcc 8? I receive various warnings from the objtool: With GCC 7 works all fine. kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x40: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x2a3: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: cgroup_apply_control_enable()+0x20b: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x296: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable()+0x10: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags.cold.45()+0xa: call without frame pointer save/setup kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files.cold.46()+0x17: call without frame pointer save/setup kernel/cgroup/cgroup.o: warning: objtool: cgroup_apply_control_enable.cold.47()+0x24: call without frame pointer save/setup kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems.cold.48()+0x10: call without frame pointer save/setup kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable.cold.49()+0x7: call without frame pointer save/setup CC kernel/cgroup/stat.o CC [M] arch/x86/kvm/../../../virt/kvm/kvm_main.o arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic()+0x10: sibling call from callable instruction with modified stack frame arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu()+0x2c: sibling call from callable instruction with modified stack frame arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic.cold.6()+0x7: call without frame pointer save/setup arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu.cold.7()+0x7: call without frame pointer save/setup Best regards Damian
Kernel build with gcc 8 a lot of warnings
Helllo together, Hello everybody, is something special to note when kernel build with gcc 8? I receive various warnings from the objtool: With GCC 7 works all fine. kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x40: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x2a3: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: cgroup_apply_control_enable()+0x20b: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x296: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable()+0x10: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags.cold.45()+0xa: call without frame pointer save/setup kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files.cold.46()+0x17: call without frame pointer save/setup kernel/cgroup/cgroup.o: warning: objtool: cgroup_apply_control_enable.cold.47()+0x24: call without frame pointer save/setup kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems.cold.48()+0x10: call without frame pointer save/setup kernel/cgroup/cgroup.o: warning: objtool: cgroup_sk_alloc_disable.cold.49()+0x7: call without frame pointer save/setup CC kernel/cgroup/stat.o CC [M] arch/x86/kvm/../../../virt/kvm/kvm_main.o arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic()+0x10: sibling call from callable instruction with modified stack frame arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu()+0x2c: sibling call from callable instruction with modified stack frame arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_register_lapic.cold.6()+0x7: call without frame pointer save/setup arch/x86/kernel/acpi/boot.o: warning: objtool: acpi_map_cpu.cold.7()+0x7: call without frame pointer save/setup Best regards Damian
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
Hello together, after commit "Merge tag 'char-misc-4.17-rc3' d8a332730e757129e70675679f2b2a03f1ecf65e my virtualbox with Ubuntu 16.04 no longer works correctly. The focus on a window for example "terminal window" only works very delayed. Or a move of the window with the mouse isnt possible. I reverted the commit 'd8a332730e757129e70675679f2b2a03f1ecf65e' and now works all normal. Best regards Damian
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
Hello together, after commit "Merge tag 'char-misc-4.17-rc3' d8a332730e757129e70675679f2b2a03f1ecf65e my virtualbox with Ubuntu 16.04 no longer works correctly. The focus on a window for example "terminal window" only works very delayed. Or a move of the window with the mouse isnt possible. I reverted the commit 'd8a332730e757129e70675679f2b2a03f1ecf65e' and now works all normal. Best regards Damian
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
Hello Greg, it is PATCH 3 virt: vbox: Use __get_free_pages insteas of kmalloc for DMA32 memory. Best regards Damian
Re: Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
Hello Greg, it is PATCH 3 virt: vbox: Use __get_free_pages insteas of kmalloc for DMA32 memory. Best regards Damian
Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
Hello together, after commit "Merge tag 'char-misc-4.17-rc3' d8a332730e757129e70675679f2b2a03f1ecf65e my virtualbox with Ubuntu 16.04 no longer works correctly. The focus on a window for example "terminal window" only works very delayed. Or a move of the window with the mouse isnt possible. I reverted the commit 'd8a332730e757129e70675679f2b2a03f1ecf65e' and now works all normal. Best regards Damian
Bug in vboxguest: After commit Merge tag 'char-misc-4.17-rc3'
Hello together, after commit "Merge tag 'char-misc-4.17-rc3' d8a332730e757129e70675679f2b2a03f1ecf65e my virtualbox with Ubuntu 16.04 no longer works correctly. The focus on a window for example "terminal window" only works very delayed. Or a move of the window with the mouse isnt possible. I reverted the commit 'd8a332730e757129e70675679f2b2a03f1ecf65e' and now works all normal. Best regards Damian
Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
On Wed, 13. Dec 12:07, Paul Menzel wrote: > Dear Damian, > > > On 12/13/17 12:00, Damian Tometzki wrote: > > >Hexdump was already installed in the System. > > > >I commented out this step. > Please try to reproduce it from a clean environment (`git clean -dfx`, save > your .config before), and then please give more details. After cleaning the environment with 'git clean -dfx' the build was successfully. Thanks for you help > > > Kind regards, > > Paul
Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
On Wed, 13. Dec 12:07, Paul Menzel wrote: > Dear Damian, > > > On 12/13/17 12:00, Damian Tometzki wrote: > > >Hexdump was already installed in the System. > > > >I commented out this step. > Please try to reproduce it from a clean environment (`git clean -dfx`, save > your .config before), and then please give more details. After cleaning the environment with 'git clean -dfx' the build was successfully. Thanks for you help > > > Kind regards, > > Paul
Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
Hello Paul, with the cleanup the Build was succesfully. Thanks für you help. VG Damian Tometzki Itelligence AG +41 79 304 2745 > Am 13.12.2017 um 12:07 schrieb Paul Menzel > <pmenzel+linux-wirel...@molgen.mpg.de>: > > Dear Damian, > > >> On 12/13/17 12:00, Damian Tometzki wrote: >> >> Hexdump was already installed in the System. >> I commented out this step. > Please try to reproduce it from a clean environment (`git clean -dfx`, save > your .config before), and then please give more details. > > > Kind regards, > > Paul
Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
Hello Paul, with the cleanup the Build was succesfully. Thanks für you help. VG Damian Tometzki Itelligence AG +41 79 304 2745 > Am 13.12.2017 um 12:07 schrieb Paul Menzel > : > > Dear Damian, > > >> On 12/13/17 12:00, Damian Tometzki wrote: >> >> Hexdump was already installed in the System. >> I commented out this step. > Please try to reproduce it from a clean environment (`git clean -dfx`, save > your .config before), and then please give more details. > > > Kind regards, > > Paul
Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
Hello Paul, Hexdump was already installed in the System. I commented out this step. VG Damian Tometzki Itelligence AG +41 79 304 2745 > Am 13.12.2017 um 10:16 schrieb Paul Menzel > <pmenzel+linux-wirel...@molgen.mpg.de>: > > Dear Damian, > > >> On 12/13/17 08:53, Damian Tometzki wrote: >> >> I got. the same Build error. > > So first you didn’t have hexdump installed, and then after installing it you > got it? Removing the generated file fixed the build? > > > Kind regards, > > Paul
Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
Hello Paul, Hexdump was already installed in the System. I commented out this step. VG Damian Tometzki Itelligence AG +41 79 304 2745 > Am 13.12.2017 um 10:16 schrieb Paul Menzel > : > > Dear Damian, > > >> On 12/13/17 08:53, Damian Tometzki wrote: >> >> I got. the same Build error. > > So first you didn’t have hexdump installed, and then after installing it you > got it? Removing the generated file fixed the build? > > > Kind regards, > > Paul
Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
Hello Johannes,
I got. the same Build error.
VG Damian Tometzki
> Am 05.12.2017 um 11:03 schrieb Johannes Berg <johan...@sipsolutions.net>:
>
>> On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote:
>>
>>
>> ```
>> $ git describe
>> v4.15-rc2-79-gfd6d2e506ce6
>> $ git log --oneline -1
>> fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
>> $ time ARCH=i386 make deb-pkg -j50
>> […]
>> net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
>> const u8 shipped_regdb_certs[] = {
>> ^
>> […]
>> $ more net/wireless/shipped-certs.c
>> #include "reg.h"
>> const u8 shipped_regdb_certs[] = {
>> ```
>
> Ah, here we go - you probably don't have "hexdump" installed on this
> system?
>
> I thought about doing hexdump in posix shell/awk/sed/whatever
> instead... maybe I should do that.
>
> johannes
Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
Hello Johannes,
I got. the same Build error.
VG Damian Tometzki
> Am 05.12.2017 um 11:03 schrieb Johannes Berg :
>
>> On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote:
>>
>>
>> ```
>> $ git describe
>> v4.15-rc2-79-gfd6d2e506ce6
>> $ git log --oneline -1
>> fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
>> $ time ARCH=i386 make deb-pkg -j50
>> […]
>> net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
>> const u8 shipped_regdb_certs[] = {
>> ^
>> […]
>> $ more net/wireless/shipped-certs.c
>> #include "reg.h"
>> const u8 shipped_regdb_certs[] = {
>> ```
>
> Ah, here we go - you probably don't have "hexdump" installed on this
> system?
>
> I thought about doing hexdump in posix shell/awk/sed/whatever
> instead... maybe I should do that.
>
> johannes
Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Hello all, i'am new in the community. For me the intention of the document is clear but is very spongy written. It leaves a lot of interpretations and unclear to me. Who is the community and who is we ? The names in the document ? In my opinion, the list is incomplete or is that the community ? And what are with all the other people's where contribute to the community. Many of the people's in the document work in a company which also has the interest in further development. Nevertheless, I will also try to make my contribution as a private person and in my free time after work. Even if the entry is not made easy if one is not working with the well-known company. -Damian- signature.asc Description: PGP signature
Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Hello all, i'am new in the community. For me the intention of the document is clear but is very spongy written. It leaves a lot of interpretations and unclear to me. Who is the community and who is we ? The names in the document ? In my opinion, the list is incomplete or is that the community ? And what are with all the other people's where contribute to the community. Many of the people's in the document work in a company which also has the interest in further development. Nevertheless, I will also try to make my contribution as a private person and in my free time after work. Even if the entry is not made easy if one is not working with the well-known company. -Damian- signature.asc Description: PGP signature
Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Hello all, i'am new in the community. For me the intention of the document is clear but is very spongy written. It leaves a lot of interpretations and unclear to me. Who is the community and who is we ? The names in the document ? In my opinion, the list is incomplete or is that the community ? And what are with all the other people's where contribute to the community. Many of the people's in the document work in a company which also has the interest in further development. Nevertheless, I will also try to make my contribution as a private person and in my free time after work. Even if the entry is not made easy if one is not working with the well-known company. -Damian-
Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Hello all, i'am new in the community. For me the intention of the document is clear but is very spongy written. It leaves a lot of interpretations and unclear to me. Who is the community and who is we ? The names in the document ? In my opinion, the list is incomplete or is that the community ? And what are with all the other people's where contribute to the community. Many of the people's in the document work in a company which also has the interest in further development. Nevertheless, I will also try to make my contribution as a private person and in my free time after work. Even if the entry is not made easy if one is not working with the well-known company. -Damian-
Re: [PATCH for linux-next] mm/page-writeback.c: make changes of dirty_writeback_centisecs take effect immediately
On Sat, 14. Oct 16:38, Yafang Shao wrote: > This patch is the followup of the prvious patch: > [writeback: schedule periodic writeback with sysctl]. > > There's another issue to fix. > For example, > - When the tunable was set to one hour and is reset to one second, the > new setting will not take effect for up to one hour. > > Kicking the flusher threads immediately fixes it. > > Cc: Jens Axboe <ax...@kernel.dk> > Cc: Jan Kara <j...@suse.cz> > Cc: Andrew Morton <a...@linux-foundation.org> > Signed-off-by: Yafang Shao <laoar.s...@gmail.com> > --- > mm/page-writeback.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > index 3969e69..768fe4e 100644 > --- a/mm/page-writeback.c > +++ b/mm/page-writeback.c > @@ -1978,7 +1978,16 @@ int dirty_writeback_centisecs_handler(struct ctl_table > *table, int write, > int ret; > > ret = proc_dointvec(table, write, buffer, length, ppos); > - if (!ret && !old_interval && dirty_writeback_interval) > + > + /* > + * Writing 0 to dirty_writeback_interval will disable periodic writeback > + * and a different non-zero value will wakeup the writeback threads. > + * wb_wakeup_delayed() would be more appropriate, but it's a pain to > + * iterate over all bdis and wbs. > + * The reason we do this is to make the change take effect immediately. > + */ > + if (!ret && write && dirty_writeback_interval && > + dirty_writeback_interval != old_interval) > wakeup_flusher_threads(WB_REASON_PERIODIC); Is that call right ? The call need two arguments ? --> wakeup_flusher_threads(0,WB_REASON_PERIODIC); best regards Damian > > return ret; > -- > 1.8.3.1 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org
Re: [PATCH for linux-next] mm/page-writeback.c: make changes of dirty_writeback_centisecs take effect immediately
On Sat, 14. Oct 16:38, Yafang Shao wrote: > This patch is the followup of the prvious patch: > [writeback: schedule periodic writeback with sysctl]. > > There's another issue to fix. > For example, > - When the tunable was set to one hour and is reset to one second, the > new setting will not take effect for up to one hour. > > Kicking the flusher threads immediately fixes it. > > Cc: Jens Axboe > Cc: Jan Kara > Cc: Andrew Morton > Signed-off-by: Yafang Shao > --- > mm/page-writeback.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > index 3969e69..768fe4e 100644 > --- a/mm/page-writeback.c > +++ b/mm/page-writeback.c > @@ -1978,7 +1978,16 @@ int dirty_writeback_centisecs_handler(struct ctl_table > *table, int write, > int ret; > > ret = proc_dointvec(table, write, buffer, length, ppos); > - if (!ret && !old_interval && dirty_writeback_interval) > + > + /* > + * Writing 0 to dirty_writeback_interval will disable periodic writeback > + * and a different non-zero value will wakeup the writeback threads. > + * wb_wakeup_delayed() would be more appropriate, but it's a pain to > + * iterate over all bdis and wbs. > + * The reason we do this is to make the change take effect immediately. > + */ > + if (!ret && write && dirty_writeback_interval && > + dirty_writeback_interval != old_interval) > wakeup_flusher_threads(WB_REASON_PERIODIC); Is that call right ? The call need two arguments ? --> wakeup_flusher_threads(0,WB_REASON_PERIODIC); best regards Damian > > return ret; > -- > 1.8.3.1 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org
Re: How to verify linux-next
Am Sonntag, den 01.10.2017, 21:58 +0530 schrieb Pintu Kumar: > On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o <ty...@mit.edu> > wrote: > > > > On Sat, Sep 30, 2017 at 09:28:09AM +0530, Pintu Kumar wrote: > > > > > > I need to submit a patch to mainline which should be verified > > > against > > > linux-next tree with latest API. > > If you want to verify a patch that you intend to submit upstream, > > my > > suggestion is to *not* use linux-next, but rather use the latest > > tagged -rc from Linus's tree. So for example, you might want to > > use > > v4.14-rc2 as your base, and then apply your patch on top of v4.14- > > rc2. > > And then test v4.14-rc2. That way you don't need to worry about > > debugging problems that might be caused by code in other people's > > development trees. > > > > If you know which subsystem tree your commit is going to be sent > > to, > > you might use as your base the current development branch of that > > subsystem tree. But in general, it's fine to use something like > > v4.14-rc2; if the subsystem maintainer you plan to be submitting > > your > > patch has other preference, he or she will let you know, or take > > care > > of rebasing your patch onto his subsystme tree. > > > > > > > > My patch is related to some test utility based on client/server > > > model. > > > So, I need 2 terminal, one for server and one for client. > > That implies you're running the commands to run the test by > > hand. In > > the ideal world, tests should be automated, even those that are > > using > > client/server so that tests can be run unattended, over and over > > again. > > > > For example, here's an example of test involving a client and a > > server > > in xfstests: > > > > https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/g > > eneric/131 > > > > See? No terminal required, and certainly not two terminals! > > > > Remember, it's important not just to run one test, because the risk > > is > > that fixing one bug might cause a test regression somewhere > > else. So > > when I "validate" a kernel, I'm running thousands of tests, just to > > test the ext4 file system. For each bug that we fix, we try to add > > a > > new automated test, so we can be sure that some future change > > doesn't > > cause a bug to reappear. And if you're running hundreds or > > thousands > > of tests, you certainly aren't going to be wanting to manually set > > up > > each test by using putty to login to the VM using ssh! > > > > > > > > 1) How to resolve linux-next build error with ubuntu virtual box > > > 5.1.28 > > Virtual box is not relevant. What is relevant is the kernel config > > file you are using, and what compiler version / distro are you > > using > > to build the kernel. And as I said, you're better off using > > something > > like v4.14-rc2 instead of linux-next. > > > Ok thank you so much for your reply. > Now I am able to boot with v4.14-rc2. But now I am facing another > problem. > Now, I am not able to connect to internet from virtual box. > When I switch back to the default 4.10 the internet works normally. > I think the dlclient stopped working. > I am getting continuous logs related to apparmor like this: > apparmor="DENIED" comm=dhclient > apparmor="DENIED" comm=cups-browsed > > With 4.10, I tried installing apparmor-utils and then reboot with > 4.14-rc2, but it did not help. > Any suggestions on this? Hello, i resolved the issue with: sudo /etc/init.d/apparmor stop Damian > > > > > > - Ted
Re: How to verify linux-next
Am Sonntag, den 01.10.2017, 21:58 +0530 schrieb Pintu Kumar: > On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o > wrote: > > > > On Sat, Sep 30, 2017 at 09:28:09AM +0530, Pintu Kumar wrote: > > > > > > I need to submit a patch to mainline which should be verified > > > against > > > linux-next tree with latest API. > > If you want to verify a patch that you intend to submit upstream, > > my > > suggestion is to *not* use linux-next, but rather use the latest > > tagged -rc from Linus's tree. So for example, you might want to > > use > > v4.14-rc2 as your base, and then apply your patch on top of v4.14- > > rc2. > > And then test v4.14-rc2. That way you don't need to worry about > > debugging problems that might be caused by code in other people's > > development trees. > > > > If you know which subsystem tree your commit is going to be sent > > to, > > you might use as your base the current development branch of that > > subsystem tree. But in general, it's fine to use something like > > v4.14-rc2; if the subsystem maintainer you plan to be submitting > > your > > patch has other preference, he or she will let you know, or take > > care > > of rebasing your patch onto his subsystme tree. > > > > > > > > My patch is related to some test utility based on client/server > > > model. > > > So, I need 2 terminal, one for server and one for client. > > That implies you're running the commands to run the test by > > hand. In > > the ideal world, tests should be automated, even those that are > > using > > client/server so that tests can be run unattended, over and over > > again. > > > > For example, here's an example of test involving a client and a > > server > > in xfstests: > > > > https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/g > > eneric/131 > > > > See? No terminal required, and certainly not two terminals! > > > > Remember, it's important not just to run one test, because the risk > > is > > that fixing one bug might cause a test regression somewhere > > else. So > > when I "validate" a kernel, I'm running thousands of tests, just to > > test the ext4 file system. For each bug that we fix, we try to add > > a > > new automated test, so we can be sure that some future change > > doesn't > > cause a bug to reappear. And if you're running hundreds or > > thousands > > of tests, you certainly aren't going to be wanting to manually set > > up > > each test by using putty to login to the VM using ssh! > > > > > > > > 1) How to resolve linux-next build error with ubuntu virtual box > > > 5.1.28 > > Virtual box is not relevant. What is relevant is the kernel config > > file you are using, and what compiler version / distro are you > > using > > to build the kernel. And as I said, you're better off using > > something > > like v4.14-rc2 instead of linux-next. > > > Ok thank you so much for your reply. > Now I am able to boot with v4.14-rc2. But now I am facing another > problem. > Now, I am not able to connect to internet from virtual box. > When I switch back to the default 4.10 the internet works normally. > I think the dlclient stopped working. > I am getting continuous logs related to apparmor like this: > apparmor="DENIED" comm=dhclient > apparmor="DENIED" comm=cups-browsed > > With 4.10, I tried installing apparmor-utils and then reboot with > 4.14-rc2, but it did not help. > Any suggestions on this? Hello, i resolved the issue with: sudo /etc/init.d/apparmor stop Damian > > > > > > - Ted
Re: [PATCH v16 0/5] Virtio-balloon Enhancement
Hello, where i can found the patch in git.kernel.org ? Am Samstag, den 30.09.2017, 12:05 +0800 schrieb Wei Wang: > This patch series enhances the existing virtio-balloon with the > following > new features: > 1) fast ballooning: transfer ballooned pages between the guest and > host in > chunks using sgs, instead of one array each time; and > 2) free page block reporting: a new virtqueue to report guest free > pages > to the host. > > The second feature can be used to accelerate live migration of VMs. > Here > are some details: > > Live migration needs to transfer the VM's memory from the source > machine > to the destination round by round. For the 1st round, all the VM's > memory > is transferred. From the 2nd round, only the pieces of memory that > were > written by the guest (after the 1st round) are transferred. One > method > that is popularly used by the hypervisor to track which part of > memory is > written is to write-protect all the guest memory. > > The second feature enables the optimization of the 1st round memory > transfer - the hypervisor can skip the transfer of guest free pages > in the > 1st round. It is not concerned that the memory pages are used after > they > are given to the hypervisor as a hint of the free pages, because they > will > be tracked by the hypervisor and transferred in the next round if > they are > used and written. > > Change Log: > v15->v16: > 1) mm: stop reporting the free pfn range if the callback returns > false; > 2) mm: move some implementaion of walk_free_mem_block into a function > to > make the code layout looks better; > 3) xbitmap: added some optimizations suggested by Matthew, please > refer to > the ChangLog in the xbitmap patch for details. > 4) xbitmap: added a test suite > 5) virtio-balloon: bail out with a warning when virtqueue_add_inbuf > returns > an error > 6) virtio-balloon: some small code re-arrangement, e.g. detachinf > used buf > from the vq before adding a new buf > > v14->v15: > 1) mm: make the report callback return a bool value - returning 1 to > stop > walking through the free page list. > 2) virtio-balloon: batching sgs of balloon pages till the vq is full > 3) virtio-balloon: create a new workqueue, rather than using the > default > system_wq, to queue the free page reporting work item. > 4) virtio-balloon: add a ctrl_vq to be a central control plane which > will > handle all the future control related commands between the host and > guest. > Add free page report as the first feature controlled under ctrl_vq, > and > the free_page_vq is a data plane vq dedicated to the transmission of > free > page blocks. > > v13->v14: > 1) xbitmap: move the code from lib/radix-tree.c to lib/xbitmap.c. > 2) xbitmap: consolidate the implementation of xb_bit_set/clear/test > into > one xb_bit_ops. > 3) xbitmap: add documents for the exported APIs. > 4) mm: rewrite the function to walk through free page blocks. > 5) virtio-balloon: when reporting a free page blcok to the device, if > the > vq is full (less likey to happen in practice), just skip reporting > this > block, instead of busywaiting till an entry gets released. > 6) virtio-balloon: fail the probe function if adding the signal buf > in > init_vqs fails. > > v12->v13: > 1) mm: use a callback function to handle the the free page blocks > from the > report function. This avoids exposing the zone internal to a kernel > module. > 2) virtio-balloon: send balloon pages or a free page block using a > single > sg each time. This has the benefits of simpler implementation with no > new > APIs. > 3) virtio-balloon: the free_page_vq is used to report free pages only > (no > multiple usages interleaving) > 4) virtio-balloon: Balloon pages and free page blocks are sent via > input > sgs, and the completion signal to the host is sent via an output sg. > > v11->v12: > 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned > pages. > 2) virtio-ring: enable the driver to build up a desc chain using > vring > desc. > 3) virtio-ring: Add locking to the existing START_USE() and END_USE() > macro to lock/unlock the vq when a vq operation starts/ends. > 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async() > 5) virtio-balloon: describe chunks of ballooned pages and free pages > blocks directly using one or more chains of desc from the vq. > > v10->v11: > 1) virtio_balloon: use vring_desc to describe a chunk; > 2) virtio_ring: support to add an indirect desc table to virtqueue; > 3) virtio_balloon: use cmdq to report guest memory statistics. > > v9->v10: > 1) mm: put report_unused_page_block() under CONFIG_VIRTIO_BALLOON; > 2) virtio-balloon: add virtballoon_validate(); > 3) virtio-balloon: msg format change; > 4) virtio-balloon: move miscq handling to a task on > system_freezable_wq; > 5) virtio-balloon: code cleanup. > > v8->v9: > 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and > VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous >
Re: [PATCH v16 0/5] Virtio-balloon Enhancement
Hello, where i can found the patch in git.kernel.org ? Am Samstag, den 30.09.2017, 12:05 +0800 schrieb Wei Wang: > This patch series enhances the existing virtio-balloon with the > following > new features: > 1) fast ballooning: transfer ballooned pages between the guest and > host in > chunks using sgs, instead of one array each time; and > 2) free page block reporting: a new virtqueue to report guest free > pages > to the host. > > The second feature can be used to accelerate live migration of VMs. > Here > are some details: > > Live migration needs to transfer the VM's memory from the source > machine > to the destination round by round. For the 1st round, all the VM's > memory > is transferred. From the 2nd round, only the pieces of memory that > were > written by the guest (after the 1st round) are transferred. One > method > that is popularly used by the hypervisor to track which part of > memory is > written is to write-protect all the guest memory. > > The second feature enables the optimization of the 1st round memory > transfer - the hypervisor can skip the transfer of guest free pages > in the > 1st round. It is not concerned that the memory pages are used after > they > are given to the hypervisor as a hint of the free pages, because they > will > be tracked by the hypervisor and transferred in the next round if > they are > used and written. > > Change Log: > v15->v16: > 1) mm: stop reporting the free pfn range if the callback returns > false; > 2) mm: move some implementaion of walk_free_mem_block into a function > to > make the code layout looks better; > 3) xbitmap: added some optimizations suggested by Matthew, please > refer to > the ChangLog in the xbitmap patch for details. > 4) xbitmap: added a test suite > 5) virtio-balloon: bail out with a warning when virtqueue_add_inbuf > returns > an error > 6) virtio-balloon: some small code re-arrangement, e.g. detachinf > used buf > from the vq before adding a new buf > > v14->v15: > 1) mm: make the report callback return a bool value - returning 1 to > stop > walking through the free page list. > 2) virtio-balloon: batching sgs of balloon pages till the vq is full > 3) virtio-balloon: create a new workqueue, rather than using the > default > system_wq, to queue the free page reporting work item. > 4) virtio-balloon: add a ctrl_vq to be a central control plane which > will > handle all the future control related commands between the host and > guest. > Add free page report as the first feature controlled under ctrl_vq, > and > the free_page_vq is a data plane vq dedicated to the transmission of > free > page blocks. > > v13->v14: > 1) xbitmap: move the code from lib/radix-tree.c to lib/xbitmap.c. > 2) xbitmap: consolidate the implementation of xb_bit_set/clear/test > into > one xb_bit_ops. > 3) xbitmap: add documents for the exported APIs. > 4) mm: rewrite the function to walk through free page blocks. > 5) virtio-balloon: when reporting a free page blcok to the device, if > the > vq is full (less likey to happen in practice), just skip reporting > this > block, instead of busywaiting till an entry gets released. > 6) virtio-balloon: fail the probe function if adding the signal buf > in > init_vqs fails. > > v12->v13: > 1) mm: use a callback function to handle the the free page blocks > from the > report function. This avoids exposing the zone internal to a kernel > module. > 2) virtio-balloon: send balloon pages or a free page block using a > single > sg each time. This has the benefits of simpler implementation with no > new > APIs. > 3) virtio-balloon: the free_page_vq is used to report free pages only > (no > multiple usages interleaving) > 4) virtio-balloon: Balloon pages and free page blocks are sent via > input > sgs, and the completion signal to the host is sent via an output sg. > > v11->v12: > 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned > pages. > 2) virtio-ring: enable the driver to build up a desc chain using > vring > desc. > 3) virtio-ring: Add locking to the existing START_USE() and END_USE() > macro to lock/unlock the vq when a vq operation starts/ends. > 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async() > 5) virtio-balloon: describe chunks of ballooned pages and free pages > blocks directly using one or more chains of desc from the vq. > > v10->v11: > 1) virtio_balloon: use vring_desc to describe a chunk; > 2) virtio_ring: support to add an indirect desc table to virtqueue; > 3) virtio_balloon: use cmdq to report guest memory statistics. > > v9->v10: > 1) mm: put report_unused_page_block() under CONFIG_VIRTIO_BALLOON; > 2) virtio-balloon: add virtballoon_validate(); > 3) virtio-balloon: msg format change; > 4) virtio-balloon: move miscq handling to a task on > system_freezable_wq; > 5) virtio-balloon: code cleanup. > > v8->v9: > 1) Split the two new features, VIRTIO_BALLOON_F_BALLOON_CHUNKS and > VIRTIO_BALLOON_F_MISC_VQ, which were mixed together in the previous >
Re: [PATCH v16 0/5] Virtio-balloon Enhancement
Hello, where i can found the patch in git.kernel.org ? Best regards Damian Am Samstag, den 30.09.2017, 12:05 +0800 schrieb Wei Wang: > This patch series enhances the existing virtio-balloon with the > following > new features: > 1) fast ballooning: transfer ballooned pages between the guest and > host in > chunks using sgs, instead of one array each time; and > 2) free page block reporting: a new virtqueue to report guest free > pages > to the host. > > The second feature can be used to accelerate live migration of VMs. > Here > are some details: > > Live migration needs to transfer the VM's memory from the source > machine > to the destination round by round. For the 1st round, all the VM's > memory > is transferred. From the 2nd round, only the pieces of memory that > were > written by the guest (after the 1st round) are transferred. One > method > that is popularly used by the hypervisor to track which part of > memory is > written is to write-protect all the guest memory. > > The second feature enables the optimization of the 1st round memory > transfer - the hypervisor can skip the transfer of guest free pages > in the > 1st round. It is not concerned that the memory pages are used after > they > are given to the hypervisor as a hint of the free pages, because they > will > be tracked by the hypervisor and transferred in the next round if > they are > used and written. > > Change Log: > v15->v16: > 1) mm: stop reporting the free pfn range if the callback returns > false; > 2) mm: move some implementaion of walk_free_mem_block into a function > to > make the code layout looks better; > 3) xbitmap: added some optimizations suggested by Matthew, please > refer to > the ChangLog in the xbitmap patch for details. > 4) xbitmap: added a test suite > 5) virtio-balloon: bail out with a warning when virtqueue_add_inbuf > returns > an error > 6) virtio-balloon: some small code re-arrangement, e.g. detachinf > used buf > from the vq before adding a new buf > > v14->v15: > 1) mm: make the report callback return a bool value - returning 1 to > stop > walking through the free page list. > 2) virtio-balloon: batching sgs of balloon pages till the vq is full > 3) virtio-balloon: create a new workqueue, rather than using the > default > system_wq, to queue the free page reporting work item. > 4) virtio-balloon: add a ctrl_vq to be a central control plane which > will > handle all the future control related commands between the host and > guest. > Add free page report as the first feature controlled under ctrl_vq, > and > the free_page_vq is a data plane vq dedicated to the transmission of > free > page blocks. > > v13->v14: > 1) xbitmap: move the code from lib/radix-tree.c to lib/xbitmap.c. > 2) xbitmap: consolidate the implementation of xb_bit_set/clear/test > into > one xb_bit_ops. > 3) xbitmap: add documents for the exported APIs. > 4) mm: rewrite the function to walk through free page blocks. > 5) virtio-balloon: when reporting a free page blcok to the device, if > the > vq is full (less likey to happen in practice), just skip reporting > this > block, instead of busywaiting till an entry gets released. > 6) virtio-balloon: fail the probe function if adding the signal buf > in > init_vqs fails. > > v12->v13: > 1) mm: use a callback function to handle the the free page blocks > from the > report function. This avoids exposing the zone internal to a kernel > module. > 2) virtio-balloon: send balloon pages or a free page block using a > single > sg each time. This has the benefits of simpler implementation with no > new > APIs. > 3) virtio-balloon: the free_page_vq is used to report free pages only > (no > multiple usages interleaving) > 4) virtio-balloon: Balloon pages and free page blocks are sent via > input > sgs, and the completion signal to the host is sent via an output sg. > > v11->v12: > 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned > pages. > 2) virtio-ring: enable the driver to build up a desc chain using > vring > desc. > 3) virtio-ring: Add locking to the existing START_USE() and END_USE() > macro to lock/unlock the vq when a vq operation starts/ends. > 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async() > 5) virtio-balloon: describe chunks of ballooned pages and free pages > blocks directly using one or more chains of desc from the vq. > > v10->v11: > 1) virtio_balloon: use vring_desc to describe a chunk; > 2) virtio_ring: support to add an indirect desc table to virtqueue; > 3) virtio_balloon: use cmdq to report guest memory statistics. > > v9->v10: > 1) mm:
Re: [PATCH v16 0/5] Virtio-balloon Enhancement
Hello, where i can found the patch in git.kernel.org ? Best regards Damian Am Samstag, den 30.09.2017, 12:05 +0800 schrieb Wei Wang: > This patch series enhances the existing virtio-balloon with the > following > new features: > 1) fast ballooning: transfer ballooned pages between the guest and > host in > chunks using sgs, instead of one array each time; and > 2) free page block reporting: a new virtqueue to report guest free > pages > to the host. > > The second feature can be used to accelerate live migration of VMs. > Here > are some details: > > Live migration needs to transfer the VM's memory from the source > machine > to the destination round by round. For the 1st round, all the VM's > memory > is transferred. From the 2nd round, only the pieces of memory that > were > written by the guest (after the 1st round) are transferred. One > method > that is popularly used by the hypervisor to track which part of > memory is > written is to write-protect all the guest memory. > > The second feature enables the optimization of the 1st round memory > transfer - the hypervisor can skip the transfer of guest free pages > in the > 1st round. It is not concerned that the memory pages are used after > they > are given to the hypervisor as a hint of the free pages, because they > will > be tracked by the hypervisor and transferred in the next round if > they are > used and written. > > Change Log: > v15->v16: > 1) mm: stop reporting the free pfn range if the callback returns > false; > 2) mm: move some implementaion of walk_free_mem_block into a function > to > make the code layout looks better; > 3) xbitmap: added some optimizations suggested by Matthew, please > refer to > the ChangLog in the xbitmap patch for details. > 4) xbitmap: added a test suite > 5) virtio-balloon: bail out with a warning when virtqueue_add_inbuf > returns > an error > 6) virtio-balloon: some small code re-arrangement, e.g. detachinf > used buf > from the vq before adding a new buf > > v14->v15: > 1) mm: make the report callback return a bool value - returning 1 to > stop > walking through the free page list. > 2) virtio-balloon: batching sgs of balloon pages till the vq is full > 3) virtio-balloon: create a new workqueue, rather than using the > default > system_wq, to queue the free page reporting work item. > 4) virtio-balloon: add a ctrl_vq to be a central control plane which > will > handle all the future control related commands between the host and > guest. > Add free page report as the first feature controlled under ctrl_vq, > and > the free_page_vq is a data plane vq dedicated to the transmission of > free > page blocks. > > v13->v14: > 1) xbitmap: move the code from lib/radix-tree.c to lib/xbitmap.c. > 2) xbitmap: consolidate the implementation of xb_bit_set/clear/test > into > one xb_bit_ops. > 3) xbitmap: add documents for the exported APIs. > 4) mm: rewrite the function to walk through free page blocks. > 5) virtio-balloon: when reporting a free page blcok to the device, if > the > vq is full (less likey to happen in practice), just skip reporting > this > block, instead of busywaiting till an entry gets released. > 6) virtio-balloon: fail the probe function if adding the signal buf > in > init_vqs fails. > > v12->v13: > 1) mm: use a callback function to handle the the free page blocks > from the > report function. This avoids exposing the zone internal to a kernel > module. > 2) virtio-balloon: send balloon pages or a free page block using a > single > sg each time. This has the benefits of simpler implementation with no > new > APIs. > 3) virtio-balloon: the free_page_vq is used to report free pages only > (no > multiple usages interleaving) > 4) virtio-balloon: Balloon pages and free page blocks are sent via > input > sgs, and the completion signal to the host is sent via an output sg. > > v11->v12: > 1) xbitmap: use the xbitmap from Matthew Wilcox to record ballooned > pages. > 2) virtio-ring: enable the driver to build up a desc chain using > vring > desc. > 3) virtio-ring: Add locking to the existing START_USE() and END_USE() > macro to lock/unlock the vq when a vq operation starts/ends. > 4) virtio-ring: add virtqueue_kick_sync() and virtqueue_kick_async() > 5) virtio-balloon: describe chunks of ballooned pages and free pages > blocks directly using one or more chains of desc from the vq. > > v10->v11: > 1) virtio_balloon: use vring_desc to describe a chunk; > 2) virtio_ring: support to add an indirect desc table to virtqueue; > 3) virtio_balloon: use cmdq to report guest memory statistics. > > v9->v10: > 1) mm:
Re: How to verify linux-next
Hello, i can tell you ubuntu 16.04 works under virtualbox 5.1.28 with the current linux-next kernel My maschine: Host: Windows 10 Guest: Ubuntu 16.04 Am Freitag, den 29.09.2017, 08:41 -0400 schrieb valdis.kletni...@vt.edu: > On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said: > > > > > I have a general question. > > How do we normally verify linux-next tree? > The same exact way you "verify" any other Linux kernel, for whatever > definition of "verify" you plan to use. > > > > > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the linux-next > > kernel is not booting. > Does an Ubuntu kernel boot correctly under VirtualBox? If not, fix > that issue first. Also, "is not booting" isn't detailed enough for > anybody > to make even a guess as to what's wrong. > > Also, note that 5.1.28 is out.
Re: How to verify linux-next
Hello, i can tell you ubuntu 16.04 works under virtualbox 5.1.28 with the current linux-next kernel My maschine: Host: Windows 10 Guest: Ubuntu 16.04 Am Freitag, den 29.09.2017, 08:41 -0400 schrieb valdis.kletni...@vt.edu: > On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said: > > > > > I have a general question. > > How do we normally verify linux-next tree? > The same exact way you "verify" any other Linux kernel, for whatever > definition of "verify" you plan to use. > > > > > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the linux-next > > kernel is not booting. > Does an Ubuntu kernel boot correctly under VirtualBox? If not, fix > that issue first. Also, "is not booting" isn't detailed enough for > anybody > to make even a guess as to what's wrong. > > Also, note that 5.1.28 is out.
Re: How to verify linux-next
Hello, Ubuntu 16.04 with current linux-next Kernel workson virtualbox 5.1.28 Host: Windows 10 Guest: Ubuntu 16.04 Best regards Damian Am Freitag, den 29.09.2017, 08:41 -0400 schrieb valdis.kletni...@vt.edu: > On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said: > > > > > I have a general question. > > How do we normally verify linux-next tree? > The same exact way you "verify" any other Linux kernel, for whatever > definition of "verify" you plan to use. > > > > > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the linux-next > > kernel is not booting. > Does an Ubuntu kernel boot correctly under VirtualBox? If not, fix > that issue first. Also, "is not booting" isn't detailed enough for > anybody > to make even a guess as to what's wrong. > > Also, note that 5.1.28 is out.
Re: How to verify linux-next
Hello, Ubuntu 16.04 with current linux-next Kernel workson virtualbox 5.1.28 Host: Windows 10 Guest: Ubuntu 16.04 Best regards Damian Am Freitag, den 29.09.2017, 08:41 -0400 schrieb valdis.kletni...@vt.edu: > On Fri, 29 Sep 2017 16:08:07 +0530, Pintu Kumar said: > > > > > I have a general question. > > How do we normally verify linux-next tree? > The same exact way you "verify" any other Linux kernel, for whatever > definition of "verify" you plan to use. > > > > > 1) For Oracle virtual box 5.1.26 with ubuntu-32 bit, the linux-next > > kernel is not booting. > Does an Ubuntu kernel boot correctly under VirtualBox? If not, fix > that issue first. Also, "is not booting" isn't detailed enough for > anybody > to make even a guess as to what's wrong. > > Also, note that 5.1.28 is out.
Re: [PATCH v3 1/1] eventfd: implementation of EFD_MASK flag
Hello, > diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h > index ff0b981..87de343 100644 > --- a/include/linux/eventfd.h > +++ b/include/linux/eventfd.h > > -/* > - * CAREFUL: Check include/uapi/asm-generic/fcntl.h when defining > - * new flags, since they might collide with O_* ones. We want > - * to re-use O_* flags that couldn't possibly have a meaning > - * from eventfd, in order to leave a free define-space for > - * shared O_* flags. > - */ > -#define EFD_SEMAPHORE (1 << 0) > -#define EFD_CLOEXEC O_CLOEXEC > -#define EFD_NONBLOCK O_NONBLOCK > - > -#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK) > -#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE) > - > struct file; > > #ifdef CONFIG_EVENTFD > diff --git a/include/uapi/linux/eventfd.h b/include/uapi/linux/eventfd.h > new file mode 100644 > index 000..097dcad > --- /dev/null > +++ b/include/uapi/linux/eventfd.h > @@ -0,0 +1,33 @@ > + > +/* > + * CAREFUL: Check include/asm-generic/fcntl.h when defining > + * new flags, since they might collide with O_* ones. We want > + * to re-use O_* flags that couldn't possibly have a meaning > + * from eventfd, in order to leave a free define-space for > + * shared O_* flags. > + */ > + > +/* Provide semaphore-like semantics for reads from the eventfd. */ > +#define EFD_SEMAPHORE (1 << 0) > +/* Provide event mask semantics for the eventfd. */ > +#define EFD_MASK (1 << 1) > +/* Set the close-on-exec (FD_CLOEXEC) flag on the eventfd. */ > +#define EFD_CLOEXEC O_CLOEXEC > +/* Create the eventfd in non-blocking mode. */ > +#define EFD_NONBLOCK O_NONBLOCK > +#endif /* _UAPI_LINUX_EVENTFD_H */ > Since the latest version of this patch adds only the EFD_MASK definition to the eventfd header, I was wondering if it was really necessary/recommended to move the definitions from linux/eventfd.h to linux/uapi/eventfd.h. From my understanding, the EFD_SEMAPHORE (and now EFD_MASK) define(s) are provided to user space from the libc headers only. Any advice would be greatly appreciated. Thank you, Damian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] eventfd: implementation of EFD_MASK flag
Hello, > diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h > index ff0b981..87de343 100644 > --- a/include/linux/eventfd.h > +++ b/include/linux/eventfd.h > > -/* > - * CAREFUL: Check include/uapi/asm-generic/fcntl.h when defining > - * new flags, since they might collide with O_* ones. We want > - * to re-use O_* flags that couldn't possibly have a meaning > - * from eventfd, in order to leave a free define-space for > - * shared O_* flags. > - */ > -#define EFD_SEMAPHORE (1 << 0) > -#define EFD_CLOEXEC O_CLOEXEC > -#define EFD_NONBLOCK O_NONBLOCK > - > -#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK) > -#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE) > - > struct file; > > #ifdef CONFIG_EVENTFD > diff --git a/include/uapi/linux/eventfd.h b/include/uapi/linux/eventfd.h > new file mode 100644 > index 000..097dcad > --- /dev/null > +++ b/include/uapi/linux/eventfd.h > @@ -0,0 +1,33 @@ > + > +/* > + * CAREFUL: Check include/asm-generic/fcntl.h when defining > + * new flags, since they might collide with O_* ones. We want > + * to re-use O_* flags that couldn't possibly have a meaning > + * from eventfd, in order to leave a free define-space for > + * shared O_* flags. > + */ > + > +/* Provide semaphore-like semantics for reads from the eventfd. */ > +#define EFD_SEMAPHORE (1 << 0) > +/* Provide event mask semantics for the eventfd. */ > +#define EFD_MASK (1 << 1) > +/* Set the close-on-exec (FD_CLOEXEC) flag on the eventfd. */ > +#define EFD_CLOEXEC O_CLOEXEC > +/* Create the eventfd in non-blocking mode. */ > +#define EFD_NONBLOCK O_NONBLOCK > +#endif /* _UAPI_LINUX_EVENTFD_H */ > Since the latest version of this patch adds only the EFD_MASK definition to the eventfd header, I was wondering if it was really necessary/recommended to move the definitions from linux/eventfd.h to linux/uapi/eventfd.h. From my understanding, the EFD_SEMAPHORE (and now EFD_MASK) define(s) are provided to user space from the libc headers only. Any advice would be greatly appreciated. Thank you, Damian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/1] eventfd: implementation of EFD_MASK flag
From: Martin Sustrik
When implementing network protocols in user space, one has to implement
fake file descriptors to represent the sockets for the protocol.
Polling on such fake file descriptors is a problem (poll/select/epoll
accept only true file descriptors) and forces protocol implementers to use
various workarounds resulting in complex, non-standard and convoluted APIs.
More generally, ability to create full-blown file descriptors for
userspace-to-userspace signalling is missing. While eventfd(2) goes half
the way towards this goal it has follwoing shorcomings:
I. There's no way to signal POLLPRI, POLLHUP etc.
II. There's no way to signal arbitrary combination of POLL* flags. Most
notably, simultaneous !POLLIN and !POLLOUT, which is a perfectly valid
combination for a network protocol (rx buffer is empty and tx buffer is
full), cannot be signaled using eventfd.
This patch implements new EFD_MASK flag which solves the above problems.
The semantics of EFD_MASK are as follows:
eventfd(2):
If eventfd is created with EFD_MASK flag set, it is initialised in such a
way as to signal no events on the file descriptor when it is polled on.
The 'initval' argument is ignored.
write(2):
User is allowed to write only buffers containing a 32-bit value
representing any combination of event flags as defined by the poll(2)
function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.). Specified events
will be signaled when polling (select, poll, epoll) on the eventfd is
done later on.
read(2):
read is not supported and will fail with EINVAL.
select(2), poll(2) and similar:
When polling on the eventfd marked by EFD_MASK flag, all the events
specified in last written event flags shall be signaled.
Signed-off-by: Martin Sustrik
[dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3]
Signed-off-by: Damian Hobson-Garcia
---
fs/eventfd.c | 102 ++-
include/linux/eventfd.h | 16 +--
include/uapi/linux/eventfd.h | 33 ++
3 files changed, 126 insertions(+), 25 deletions(-)
create mode 100644 include/uapi/linux/eventfd.h
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 8d0c0df..1310779 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -2,6 +2,7 @@
* fs/eventfd.c
*
* Copyright (C) 2007 Davide Libenzi
+ * Copyright (C) 2013 Martin Sustrik
*
*/
@@ -22,18 +23,31 @@
#include
#include
+#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
+#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | EFD_MASK)
+#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP)
+
struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
- /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
- __u64 count;
+ union {
+ /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the
+* "count" value to userspace, and will reset "count" to zero.
+* The kernel side eventfd_signal() also, adds to the "count"
+* counter and issue a wakeup.
+*/
+ __u64 count;
+
+ /*
+* When using eventfd in EFD_MASK mode this stracture stores the
+* current events to be signaled on the eventfd (events member)
+* along with opaque user-defined data (data member).
+*/
+ __u32 events;
+ };
unsigned int flags;
};
@@ -134,6 +148,14 @@ static unsigned int eventfd_poll(struct file *file,
poll_table *wait)
return events;
}
+static unsigned int eventfd_mask_poll(struct file *file, poll_table *wait)
+{
+ struct eventfd_ctx *ctx = file->private_data;
+
+ poll_wait(file, >wqh, wait);
+ return ctx->events;
+}
+
static void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt)
{
*cnt = (ctx->flags & EFD_SEMAPHORE) ? 1 : ctx->count;
@@ -239,6 +261,14 @@ static ssize_t eventfd_read(struct file *file, char __user
*buf, size_t count,
return put_user(cnt, (__u64 __user *) buf) ? -EFAULT : sizeof(cnt);
}
+static ssize_t eventfd_mask_read(struct file *file, char __user *buf,
+ size_t count,
+ loff_t *ppos)
+{
+ return -EINVAL;
+}
+
+
static ssize_t eventfd_write(st
[PATCH v3 0/1] Generalize poll events from eventfd
Using eventfd user space can generate POLLIN/POLLOUT events but some applications may want to generate POLLPRI/POLLERR events as well. This patch submission aims to generalize the events generated by an eventfd. This is a resubmission of a patch from Feb 2013[1]. The original discussion trailed off without any conclusion, but the original author has recently confirmed[2] that this functionality is still useful, so I volunteered to rebase and resubmit the patch for discussion. [1] https://lkml.org/lkml/2013/2/18/147 [2] https://lkml.org/lkml/2015/7/9/153 Changes in v3 - * replace efd_mask structure with scalar 'events' variable. Changes in v2 - * rebased on Linux v4.3-rc1 * Move file operation implementations for EFD_MASK to a seperate structure * Remove 'data' element from efd_mask structure * read() is no longer supported when EFD_MASK is set (fails with EINVAL) * eventfd_ctx_fileget() now returns EINVAL when EFD_MASK is set, eliminating the possibility of triggering the orginal BUG_ON() macros which have now been removed. Thank you, Damian Martin Sustrik (1): eventfd: implementation of EFD_MASK flag fs/eventfd.c | 91 ++-- include/linux/eventfd.h | 16 +--- include/uapi/linux/eventfd.h | 40 +++ 3 files changed, 121 insertions(+), 26 deletions(-) create mode 100644 include/uapi/linux/eventfd.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/1] Generalize poll events from eventfd
Using eventfd user space can generate POLLIN/POLLOUT events but some applications may want to generate POLLPRI/POLLERR events as well. This patch submission aims to generalize the events generated by an eventfd. This is a resubmission of a patch from Feb 2013[1]. The original discussion trailed off without any conclusion, but the original author has recently confirmed[2] that this functionality is still useful, so I volunteered to rebase and resubmit the patch for discussion. [1] https://lkml.org/lkml/2013/2/18/147 [2] https://lkml.org/lkml/2015/7/9/153 Changes in v3 - * replace efd_mask structure with scalar 'events' variable. Changes in v2 - * rebased on Linux v4.3-rc1 * Move file operation implementations for EFD_MASK to a seperate structure * Remove 'data' element from efd_mask structure * read() is no longer supported when EFD_MASK is set (fails with EINVAL) * eventfd_ctx_fileget() now returns EINVAL when EFD_MASK is set, eliminating the possibility of triggering the orginal BUG_ON() macros which have now been removed. Thank you, Damian Martin Sustrik (1): eventfd: implementation of EFD_MASK flag fs/eventfd.c | 91 ++-- include/linux/eventfd.h | 16 +--- include/uapi/linux/eventfd.h | 40 +++ 3 files changed, 121 insertions(+), 26 deletions(-) create mode 100644 include/uapi/linux/eventfd.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/1] eventfd: implementation of EFD_MASK flag
From: Martin Sustrik <sust...@250bpm.com>
When implementing network protocols in user space, one has to implement
fake file descriptors to represent the sockets for the protocol.
Polling on such fake file descriptors is a problem (poll/select/epoll
accept only true file descriptors) and forces protocol implementers to use
various workarounds resulting in complex, non-standard and convoluted APIs.
More generally, ability to create full-blown file descriptors for
userspace-to-userspace signalling is missing. While eventfd(2) goes half
the way towards this goal it has follwoing shorcomings:
I. There's no way to signal POLLPRI, POLLHUP etc.
II. There's no way to signal arbitrary combination of POLL* flags. Most
notably, simultaneous !POLLIN and !POLLOUT, which is a perfectly valid
combination for a network protocol (rx buffer is empty and tx buffer is
full), cannot be signaled using eventfd.
This patch implements new EFD_MASK flag which solves the above problems.
The semantics of EFD_MASK are as follows:
eventfd(2):
If eventfd is created with EFD_MASK flag set, it is initialised in such a
way as to signal no events on the file descriptor when it is polled on.
The 'initval' argument is ignored.
write(2):
User is allowed to write only buffers containing a 32-bit value
representing any combination of event flags as defined by the poll(2)
function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.). Specified events
will be signaled when polling (select, poll, epoll) on the eventfd is
done later on.
read(2):
read is not supported and will fail with EINVAL.
select(2), poll(2) and similar:
When polling on the eventfd marked by EFD_MASK flag, all the events
specified in last written event flags shall be signaled.
Signed-off-by: Martin Sustrik <sust...@250bpm.com>
[dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3]
Signed-off-by: Damian Hobson-Garcia <dhobs...@igel.co.jp>
---
fs/eventfd.c | 102 ++-
include/linux/eventfd.h | 16 +--
include/uapi/linux/eventfd.h | 33 ++
3 files changed, 126 insertions(+), 25 deletions(-)
create mode 100644 include/uapi/linux/eventfd.h
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 8d0c0df..1310779 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -2,6 +2,7 @@
* fs/eventfd.c
*
* Copyright (C) 2007 Davide Libenzi <davi...@xmailserver.org>
+ * Copyright (C) 2013 Martin Sustrik <sust...@250bpm.com>
*
*/
@@ -22,18 +23,31 @@
#include
#include
+#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
+#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | EFD_MASK)
+#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP)
+
struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
- /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
- __u64 count;
+ union {
+ /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the
+* "count" value to userspace, and will reset "count" to zero.
+* The kernel side eventfd_signal() also, adds to the "count"
+* counter and issue a wakeup.
+*/
+ __u64 count;
+
+ /*
+* When using eventfd in EFD_MASK mode this stracture stores the
+* current events to be signaled on the eventfd (events member)
+* along with opaque user-defined data (data member).
+*/
+ __u32 events;
+ };
unsigned int flags;
};
@@ -134,6 +148,14 @@ static unsigned int eventfd_poll(struct file *file,
poll_table *wait)
return events;
}
+static unsigned int eventfd_mask_poll(struct file *file, poll_table *wait)
+{
+ struct eventfd_ctx *ctx = file->private_data;
+
+ poll_wait(file, >wqh, wait);
+ return ctx->events;
+}
+
static void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt)
{
*cnt = (ctx->flags & EFD_SEMAPHORE) ? 1 : ctx->count;
@@ -239,6 +261,14 @@ static ssize_t eventfd_read(struct file *file, char __user
*buf, size_t count,
return put_user(cnt, (__u64 __user *) buf) ? -EFAULT : sizeof(cnt);
}
+static ssize_t eventfd_mask_read(struct file *file, char __user *buf,
+
Re: [PATCH v2 1/1] eventfd: implementation of EFD_MASK flag
Hi Martin,
On 2015-09-16 3:51 PM, Martin Sustrik wrote:
> On 2015-09-16 08:27, Damian Hobson-Garcia wrote:
>>
>> Additionally, to provide a way to associate user-space state with eventfd
>> object, it allows to attach user-space data to the file descriptor.
>
> The above paragraph is a leftover from the past. The functionality no
> longer exist.
>
Oops, I forgot to delete that part. I'll get rid of it.
>>
>> The semantics of EFD_MASK are as follows:
>>
>> eventfd(2):
>>
>> If eventfd is created with EFD_MASK flag set, it is initialised in such a
>> way as to signal no events on the file descriptor when it is polled on.
>> The 'initval' argument is ignored.
>>
>> write(2):
>>
>> User is allowed to write only buffers containing the following structure:
>>
>> struct efd_mask {
>> uint32_t events;
>> };
>
> Is it worth having a struct here? Why not just uint32_t?
As it stands right now, no, the struct doesn't really add anything.
uint32_t should be just fine.
>
> Martin
Damian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] eventfd: implementation of EFD_MASK flag
From: Martin Sustrik
When implementing network protocols in user space, one has to implement
fake file descriptors to represent the sockets for the protocol.
Polling on such fake file descriptors is a problem (poll/select/epoll
accept only true file descriptors) and forces protocol implementers to use
various workarounds resulting in complex, non-standard and convoluted APIs.
More generally, ability to create full-blown file descriptors for
userspace-to-userspace signalling is missing. While eventfd(2) goes half
the way towards this goal it has follwoing shorcomings:
I. There's no way to signal POLLPRI, POLLHUP etc.
II. There's no way to signal arbitrary combination of POLL* flags. Most
notably, simultaneous !POLLIN and !POLLOUT, which is a perfectly valid
combination for a network protocol (rx buffer is empty and tx buffer is
full), cannot be signaled using eventfd.
This patch implements new EFD_MASK flag which solves the above problems.
Additionally, to provide a way to associate user-space state with eventfd
object, it allows to attach user-space data to the file descriptor.
The semantics of EFD_MASK are as follows:
eventfd(2):
If eventfd is created with EFD_MASK flag set, it is initialised in such a
way as to signal no events on the file descriptor when it is polled on.
The 'initval' argument is ignored.
write(2):
User is allowed to write only buffers containing the following structure:
struct efd_mask {
uint32_t events;
};
The value of 'events' should be any combination of event flags as defined
by poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified
events will be signaled when polling (select, poll, epoll) on the eventfd
is done later on.
read(2):
read is not supported and will fail with EINVAL.
select(2), poll(2) and similar:
When polling on the eventfd marked by EFD_MASK flag, all the events
specified in last written 'events' field shall be signaled.
Signed-off-by: Martin Sustrik
[dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3]
Signed-off-by: Damian Hobson-Garcia
---
fs/eventfd.c | 102 ++-
include/linux/eventfd.h | 16 +--
include/uapi/linux/eventfd.h | 39 +
3 files changed, 132 insertions(+), 25 deletions(-)
create mode 100644 include/uapi/linux/eventfd.h
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 8d0c0df..1a6a066 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -2,6 +2,7 @@
* fs/eventfd.c
*
* Copyright (C) 2007 Davide Libenzi
+ * Copyright (C) 2013 Martin Sustrik
*
*/
@@ -22,18 +23,31 @@
#include
#include
+#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
+#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | EFD_MASK)
+#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP)
+
struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
- /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
- __u64 count;
+ union {
+ /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the
+* "count" value to userspace, and will reset "count" to zero.
+* The kernel side eventfd_signal() also, adds to the "count"
+* counter and issue a wakeup.
+*/
+ __u64 count;
+
+ /*
+* When using eventfd in EFD_MASK mode this stracture stores the
+* current events to be signaled on the eventfd (events member)
+* along with opaque user-defined data (data member).
+*/
+ struct efd_mask mask;
+ };
unsigned int flags;
};
@@ -134,6 +148,14 @@ static unsigned int eventfd_poll(struct file *file,
poll_table *wait)
return events;
}
+static unsigned int eventfd_mask_poll(struct file *file, poll_table *wait)
+{
+ struct eventfd_ctx *ctx = file->private_data;
+
+ poll_wait(file, >wqh, wait);
+ return ctx->mask.events;
+}
+
static void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt)
{
*cnt = (ctx->flags & EFD_SEMAPHORE) ? 1 : ctx->count;
@@ -239,6 +261,14 @@ static ssize_t eventfd_read(struct file *file, char __user
*buf, size_t count,
return put_user(cnt, (__u64 __user *) buf) ? -EFAULT : sizeof(cnt
[PATCH v2 0/1] Generalize poll events from eventfd
Using eventfd user space can generate POLLIN/POLLOUT events but some applications may want to generate POLLPRI/POLLERR events as well. This patch submission aims to generalize the events generated by an eventfd. This is a resubmission of a patch from Feb 2013[1]. The original discussion trailed off without any conclusion, but the original author has recently confirmed[2] that this functionality is still useful, so I volunteered to rebase and resubmit the patch for discussion. [1] https://lkml.org/lkml/2013/2/18/147 [2] https://lkml.org/lkml/2015/7/9/153 Changes in v2 - * rebased on Linux v4.3-rc1 * Move file operation implementations for EFD_MASK to a seperate structure * Remove 'data' element from efd_mask structure * read() is no longer supported when EFD_MASK is set (fails with EINVAL) * eventfd_ctx_fileget() now returns EINVAL when EFD_MASK is set, eliminating the possibility of triggering the orginal BUG_ON() macros which have now been removed. Thank you, Damian Martin Sustrik (1): eventfd: implementation of EFD_MASK flag fs/eventfd.c | 91 ++-- include/linux/eventfd.h | 16 +--- include/uapi/linux/eventfd.h | 40 +++ 3 files changed, 121 insertions(+), 26 deletions(-) create mode 100644 include/uapi/linux/eventfd.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] eventfd: implementation of EFD_MASK flag
From: Martin Sustrik <sust...@250bpm.com>
When implementing network protocols in user space, one has to implement
fake file descriptors to represent the sockets for the protocol.
Polling on such fake file descriptors is a problem (poll/select/epoll
accept only true file descriptors) and forces protocol implementers to use
various workarounds resulting in complex, non-standard and convoluted APIs.
More generally, ability to create full-blown file descriptors for
userspace-to-userspace signalling is missing. While eventfd(2) goes half
the way towards this goal it has follwoing shorcomings:
I. There's no way to signal POLLPRI, POLLHUP etc.
II. There's no way to signal arbitrary combination of POLL* flags. Most
notably, simultaneous !POLLIN and !POLLOUT, which is a perfectly valid
combination for a network protocol (rx buffer is empty and tx buffer is
full), cannot be signaled using eventfd.
This patch implements new EFD_MASK flag which solves the above problems.
Additionally, to provide a way to associate user-space state with eventfd
object, it allows to attach user-space data to the file descriptor.
The semantics of EFD_MASK are as follows:
eventfd(2):
If eventfd is created with EFD_MASK flag set, it is initialised in such a
way as to signal no events on the file descriptor when it is polled on.
The 'initval' argument is ignored.
write(2):
User is allowed to write only buffers containing the following structure:
struct efd_mask {
uint32_t events;
};
The value of 'events' should be any combination of event flags as defined
by poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified
events will be signaled when polling (select, poll, epoll) on the eventfd
is done later on.
read(2):
read is not supported and will fail with EINVAL.
select(2), poll(2) and similar:
When polling on the eventfd marked by EFD_MASK flag, all the events
specified in last written 'events' field shall be signaled.
Signed-off-by: Martin Sustrik <sust...@250bpm.com>
[dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3]
Signed-off-by: Damian Hobson-Garcia <dhobs...@igel.co.jp>
---
fs/eventfd.c | 102 ++-
include/linux/eventfd.h | 16 +--
include/uapi/linux/eventfd.h | 39 +
3 files changed, 132 insertions(+), 25 deletions(-)
create mode 100644 include/uapi/linux/eventfd.h
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 8d0c0df..1a6a066 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -2,6 +2,7 @@
* fs/eventfd.c
*
* Copyright (C) 2007 Davide Libenzi <davi...@xmailserver.org>
+ * Copyright (C) 2013 Martin Sustrik <sust...@250bpm.com>
*
*/
@@ -22,18 +23,31 @@
#include
#include
+#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
+#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | EFD_MASK)
+#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP)
+
struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
- /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
- __u64 count;
+ union {
+ /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the
+* "count" value to userspace, and will reset "count" to zero.
+* The kernel side eventfd_signal() also, adds to the "count"
+* counter and issue a wakeup.
+*/
+ __u64 count;
+
+ /*
+* When using eventfd in EFD_MASK mode this stracture stores the
+* current events to be signaled on the eventfd (events member)
+* along with opaque user-defined data (data member).
+*/
+ struct efd_mask mask;
+ };
unsigned int flags;
};
@@ -134,6 +148,14 @@ static unsigned int eventfd_poll(struct file *file,
poll_table *wait)
return events;
}
+static unsigned int eventfd_mask_poll(struct file *file, poll_table *wait)
+{
+ struct eventfd_ctx *ctx = file->private_data;
+
+ poll_wait(file, >wqh, wait);
+ return ctx->mask.events;
+}
+
static void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt)
{
*cnt = (ctx->flags & EFD_SEMAPHORE) ? 1 : ctx->count;
@@ -239,6 +261,14 @@ stat
[PATCH v2 0/1] Generalize poll events from eventfd
Using eventfd user space can generate POLLIN/POLLOUT events but some applications may want to generate POLLPRI/POLLERR events as well. This patch submission aims to generalize the events generated by an eventfd. This is a resubmission of a patch from Feb 2013[1]. The original discussion trailed off without any conclusion, but the original author has recently confirmed[2] that this functionality is still useful, so I volunteered to rebase and resubmit the patch for discussion. [1] https://lkml.org/lkml/2013/2/18/147 [2] https://lkml.org/lkml/2015/7/9/153 Changes in v2 - * rebased on Linux v4.3-rc1 * Move file operation implementations for EFD_MASK to a seperate structure * Remove 'data' element from efd_mask structure * read() is no longer supported when EFD_MASK is set (fails with EINVAL) * eventfd_ctx_fileget() now returns EINVAL when EFD_MASK is set, eliminating the possibility of triggering the orginal BUG_ON() macros which have now been removed. Thank you, Damian Martin Sustrik (1): eventfd: implementation of EFD_MASK flag fs/eventfd.c | 91 ++-- include/linux/eventfd.h | 16 +--- include/uapi/linux/eventfd.h | 40 +++ 3 files changed, 121 insertions(+), 26 deletions(-) create mode 100644 include/uapi/linux/eventfd.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] eventfd: implementation of EFD_MASK flag
Hi Martin,
On 2015-09-16 3:51 PM, Martin Sustrik wrote:
> On 2015-09-16 08:27, Damian Hobson-Garcia wrote:
>>
>> Additionally, to provide a way to associate user-space state with eventfd
>> object, it allows to attach user-space data to the file descriptor.
>
> The above paragraph is a leftover from the past. The functionality no
> longer exist.
>
Oops, I forgot to delete that part. I'll get rid of it.
>>
>> The semantics of EFD_MASK are as follows:
>>
>> eventfd(2):
>>
>> If eventfd is created with EFD_MASK flag set, it is initialised in such a
>> way as to signal no events on the file descriptor when it is polled on.
>> The 'initval' argument is ignored.
>>
>> write(2):
>>
>> User is allowed to write only buffers containing the following structure:
>>
>> struct efd_mask {
>> uint32_t events;
>> };
>
> Is it worth having a struct here? Why not just uint32_t?
As it stands right now, no, the struct doesn't really add anything.
uint32_t should be just fine.
>
> Martin
Damian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eventfd: implementation of EFD_MASK flag
On 2015-08-11 6:16 AM, Martin Sustrik wrote:
> On 2015-08-10 10:57, Damian Hobson-Garcia wrote:
>> Hi Martin,
>>
>> Thanks for your comments.
>>
>> On 2015-08-10 3:39 PM, Martin Sustrik wrote:
>>> On 2015-08-10 08:23, Damian Hobson-Garcia wrote:
>>>> Replying to my own post, but I had the following comments/questions.
>>>> Martin, if you have any response to my comments I would be very
>>>> happy to
>>>> hear them.
>>>>
>>>> On 2015-08-10 2:51 PM, Damian Hobson-Garcia wrote:
>>>>> From: Martin Sustrik
>>>>>
>>>> [snip]
>>>>>
>>>>> write(2):
>>>>>
>>>>> User is allowed to write only buffers containing the following
>>>>> structure:
>>>>>
>>>>> struct efd_mask {
>>>>> __u32 events;
>>>>> __u64 data;
>>>>> };
>>>>>
>>>>> The value of 'events' should be any combination of event flags as
>>>>> defined by
>>>>> poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified
>>>>> events will
>>>>> be signaled when polling (select, poll, epoll) on the eventfd is done
>>>>> later on.
>>>>> 'data' is opaque data that are not interpreted by eventfd object.
>>>>>
>>>> I'm not fully clear on the purpose that the 'data' member serves. Does
>>>> this opaque handle need to be tied together with this event
>>>> synchronization construct?
>>>
>>> It's a convenience thing. Imagine you are implementing your own file
>>> descriptor type in user space. You create an EFD_MASK socket and a
>>> structure that will hold any state that you need for the socket (tx/rx
>>> buffers and such).
>>>
>>> Now you have two things to pass around. If you want to pass the fd to a
>>> function, it must have two parameters (fd and pointer to the structure).
>>>
>>> To fix it you can put the fd into the structure. That way there's only
>>> one thing to pass around (the structure).
>>>
>>> The problem with that approach is when you have generic code that deals
>>> with file descriptors. For example, a simple poller which accepts a list
>>> of (fd, callback) pairs and invokes the callback when one of the fds
>>> signals POLLIN. You can't send a pointer to a structure to such
>>> function. All you can send is the fd, but then, when the callback is
>>> invoked, fd is all you have. You have no idea where your state is.
>>>
>>> 'data' member allows you to put the pointer to the state to the socket
>>> itself. Thus, if you have a fd, you can always find out where the
>>> associated data is by reading the mask structure from the fd.
>>>
>>
>> Ok, I see what you're saying. I guess that keeping track of the mapping
>> between the fd and the struct in user space could be non-trivial if
>> there are a large number of active fds that are polling very frequently.
>> Wouldn't it be sufficient to just use epoll() in this case though? It
>> already seems to support this kind of thing.
>
> My use case was like this:
>
> int s = mysocket();
> ...
> // myrecv() can get the pointer to the structure
> // without user having to pass it as an argument
> myrecv(s, buf, sizeof(buf));
>
> However, same behaviour can be accomplished by simply keeping
> a static array of pointers in the user space.
>
> So let's cut this part out of the patch.
>
Ok, I'll drop the 'data' member. I could add some padding to the
efd_mask structure so that it is the same size as the 64-bit data size
used when EFD_MASK is not set.
>>
>>>>
>>>> [snip]
>>>>
>>>>> @@ -55,6 +69,9 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx,
>>>>> __u64 n)
>>>>> {
>>>>> +/* This function should never be used with eventfd in the mask
>>>>> mode. */
>>>>> +BUG_ON(ctx->flags & EFD_MASK);
>>>>> +
>>>> ...
>>>>> @@ -158,6 +180,9 @@ int eventfd_ctx_remove_wait_queue(struct
>>>>> eventfd_ctx *ctx, wait_queue_t *wait,
>>>>> {
>>>>> +/* This function should never be used with eventfd in the mask
>>>>> mode. */
>>>>> +BUG_ON(ctx->flags & EFD_MASK);
>>>>> +
>>>> ...
>>>>> @@ -188,6 +213,9 @@ ssize_t eventfd_ctx_read(struct eventfd_ctx *
Re: [PATCH] eventfd: implementation of EFD_MASK flag
On 2015-08-11 6:16 AM, Martin Sustrik wrote:
On 2015-08-10 10:57, Damian Hobson-Garcia wrote:
Hi Martin,
Thanks for your comments.
On 2015-08-10 3:39 PM, Martin Sustrik wrote:
On 2015-08-10 08:23, Damian Hobson-Garcia wrote:
Replying to my own post, but I had the following comments/questions.
Martin, if you have any response to my comments I would be very
happy to
hear them.
On 2015-08-10 2:51 PM, Damian Hobson-Garcia wrote:
From: Martin Sustrik sust...@250bpm.com
[snip]
write(2):
User is allowed to write only buffers containing the following
structure:
struct efd_mask {
__u32 events;
__u64 data;
};
The value of 'events' should be any combination of event flags as
defined by
poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified
events will
be signaled when polling (select, poll, epoll) on the eventfd is done
later on.
'data' is opaque data that are not interpreted by eventfd object.
I'm not fully clear on the purpose that the 'data' member serves. Does
this opaque handle need to be tied together with this event
synchronization construct?
It's a convenience thing. Imagine you are implementing your own file
descriptor type in user space. You create an EFD_MASK socket and a
structure that will hold any state that you need for the socket (tx/rx
buffers and such).
Now you have two things to pass around. If you want to pass the fd to a
function, it must have two parameters (fd and pointer to the structure).
To fix it you can put the fd into the structure. That way there's only
one thing to pass around (the structure).
The problem with that approach is when you have generic code that deals
with file descriptors. For example, a simple poller which accepts a list
of (fd, callback) pairs and invokes the callback when one of the fds
signals POLLIN. You can't send a pointer to a structure to such
function. All you can send is the fd, but then, when the callback is
invoked, fd is all you have. You have no idea where your state is.
'data' member allows you to put the pointer to the state to the socket
itself. Thus, if you have a fd, you can always find out where the
associated data is by reading the mask structure from the fd.
Ok, I see what you're saying. I guess that keeping track of the mapping
between the fd and the struct in user space could be non-trivial if
there are a large number of active fds that are polling very frequently.
Wouldn't it be sufficient to just use epoll() in this case though? It
already seems to support this kind of thing.
My use case was like this:
int s = mysocket();
...
// myrecv() can get the pointer to the structure
// without user having to pass it as an argument
myrecv(s, buf, sizeof(buf));
However, same behaviour can be accomplished by simply keeping
a static array of pointers in the user space.
So let's cut this part out of the patch.
Ok, I'll drop the 'data' member. I could add some padding to the
efd_mask structure so that it is the same size as the 64-bit data size
used when EFD_MASK is not set.
[snip]
@@ -55,6 +69,9 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx,
__u64 n)
{
+/* This function should never be used with eventfd in the mask
mode. */
+BUG_ON(ctx-flags EFD_MASK);
+
...
@@ -158,6 +180,9 @@ int eventfd_ctx_remove_wait_queue(struct
eventfd_ctx *ctx, wait_queue_t *wait,
{
+/* This function should never be used with eventfd in the mask
mode. */
+BUG_ON(ctx-flags EFD_MASK);
+
...
@@ -188,6 +213,9 @@ ssize_t eventfd_ctx_read(struct eventfd_ctx *ctx,
int no_wait, __u64 *cnt)
+/* This function should never be used with eventfd in the mask
mode. */
+BUG_ON(ctx-flags EFD_MASK);
+
If eventfd_ctx_fileget() returns EINVAL when EFD_MASK is set, I don't
think that there will be a way to call these functions in the mask
mode,
so it should be possible to get rid of the BUG_ON checks.
Sure. Feel free to do so.
[snip]
@@ -230,6 +258,19 @@ static ssize_t eventfd_read(struct file *file,
char __user *buf, size_t count,
ssize_t res;
__u64 cnt;
+if (ctx-flags EFD_MASK) {
+struct efd_mask mask;
+
+if (count sizeof(mask))
+return -EINVAL;
+spin_lock_irq(ctx-wqh.lock);
+mask = ctx-mask;
+spin_unlock_irq(ctx-wqh.lock);
+if (copy_to_user(buf, mask, sizeof(mask)))
+return -EFAULT;
+return sizeof(mask);
+}
+
For the other eventfd modes, reading the value will update the internal
state of the eventfd (either clearing or decrementing the counter).
Should something similar be done here? I'm thinking of a case where a
process is polling on this fd in a loop. Clearing the efd_mask data on
read should provide an easy way for the polling process to know if
it is
seeing new poll events.
No. In this case reading the value has no effect on the state of the fd.
How it should work is rather:
// fd is in POLLIN
Re: [PATCH] eventfd: implementation of EFD_MASK flag
Hi Martin,
Thanks for your comments.
On 2015-08-10 3:39 PM, Martin Sustrik wrote:
> On 2015-08-10 08:23, Damian Hobson-Garcia wrote:
>> Replying to my own post, but I had the following comments/questions.
>> Martin, if you have any response to my comments I would be very happy to
>> hear them.
>>
>> On 2015-08-10 2:51 PM, Damian Hobson-Garcia wrote:
>>> From: Martin Sustrik
>>>
>> [snip]
>>>
>>> write(2):
>>>
>>> User is allowed to write only buffers containing the following
>>> structure:
>>>
>>> struct efd_mask {
>>> __u32 events;
>>> __u64 data;
>>> };
>>>
>>> The value of 'events' should be any combination of event flags as
>>> defined by
>>> poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified
>>> events will
>>> be signaled when polling (select, poll, epoll) on the eventfd is done
>>> later on.
>>> 'data' is opaque data that are not interpreted by eventfd object.
>>>
>> I'm not fully clear on the purpose that the 'data' member serves. Does
>> this opaque handle need to be tied together with this event
>> synchronization construct?
>
> It's a convenience thing. Imagine you are implementing your own file
> descriptor type in user space. You create an EFD_MASK socket and a
> structure that will hold any state that you need for the socket (tx/rx
> buffers and such).
>
> Now you have two things to pass around. If you want to pass the fd to a
> function, it must have two parameters (fd and pointer to the structure).
>
> To fix it you can put the fd into the structure. That way there's only
> one thing to pass around (the structure).
>
> The problem with that approach is when you have generic code that deals
> with file descriptors. For example, a simple poller which accepts a list
> of (fd, callback) pairs and invokes the callback when one of the fds
> signals POLLIN. You can't send a pointer to a structure to such
> function. All you can send is the fd, but then, when the callback is
> invoked, fd is all you have. You have no idea where your state is.
>
> 'data' member allows you to put the pointer to the state to the socket
> itself. Thus, if you have a fd, you can always find out where the
> associated data is by reading the mask structure from the fd.
>
Ok, I see what you're saying. I guess that keeping track of the mapping
between the fd and the struct in user space could be non-trivial if
there are a large number of active fds that are polling very frequently.
Wouldn't it be sufficient to just use epoll() in this case though? It
already seems to support this kind of thing.
>>
>> [snip]
>>
>>> @@ -55,6 +69,9 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
>>> {
>>> +/* This function should never be used with eventfd in the mask
>>> mode. */
>>> +BUG_ON(ctx->flags & EFD_MASK);
>>> +
>> ...
>>> @@ -158,6 +180,9 @@ int eventfd_ctx_remove_wait_queue(struct
>>> eventfd_ctx *ctx, wait_queue_t *wait,
>>> {
>>> +/* This function should never be used with eventfd in the mask
>>> mode. */
>>> +BUG_ON(ctx->flags & EFD_MASK);
>>> +
>> ...
>>> @@ -188,6 +213,9 @@ ssize_t eventfd_ctx_read(struct eventfd_ctx *ctx,
>>> int no_wait, __u64 *cnt)
>>> +/* This function should never be used with eventfd in the mask
>>> mode. */
>>> +BUG_ON(ctx->flags & EFD_MASK);
>>> +
>>
>> If eventfd_ctx_fileget() returns EINVAL when EFD_MASK is set, I don't
>> think that there will be a way to call these functions in the mask mode,
>> so it should be possible to get rid of the BUG_ON checks.
>
> Sure. Feel free to do so.
>
>>
>> [snip]
>>> @@ -230,6 +258,19 @@ static ssize_t eventfd_read(struct file *file,
>>> char __user *buf, size_t count,
>>> ssize_t res;
>>> __u64 cnt;
>>>
>>> +if (ctx->flags & EFD_MASK) {
>>> +struct efd_mask mask;
>>> +
>>> +if (count < sizeof(mask))
>>> +return -EINVAL;
>>> +spin_lock_irq(>wqh.lock);
>>> +mask = ctx->mask;
>>> +spin_unlock_irq(>wqh.lock);
>>> +if (copy_to_user(buf, , sizeof(mask)))
>>> +return -EFAULT;
>>> +return sizeof(mask);
>>> +}
>>> +
>>
>> For the other eventfd modes, reading the value will update the internal
>> state of the eventfd (either clearing or d
Re: [PATCH] eventfd: implementation of EFD_MASK flag
Replying to my own post, but I had the following comments/questions.
Martin, if you have any response to my comments I would be very happy to
hear them.
On 2015-08-10 2:51 PM, Damian Hobson-Garcia wrote:
> From: Martin Sustrik
>
[snip]
>
> write(2):
>
> User is allowed to write only buffers containing the following structure:
>
> struct efd_mask {
> __u32 events;
> __u64 data;
> };
>
> The value of 'events' should be any combination of event flags as defined by
> poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified events
> will
> be signaled when polling (select, poll, epoll) on the eventfd is done later
> on.
> 'data' is opaque data that are not interpreted by eventfd object.
>
I'm not fully clear on the purpose that the 'data' member serves. Does
this opaque handle need to be tied together with this event
synchronization construct?
[snip]
> @@ -55,6 +69,9 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
> {
> + /* This function should never be used with eventfd in the mask mode. */
> + BUG_ON(ctx->flags & EFD_MASK);
> +
...
> @@ -158,6 +180,9 @@ int eventfd_ctx_remove_wait_queue(struct eventfd_ctx
> *ctx, wait_queue_t *wait,
> {
> + /* This function should never be used with eventfd in the mask mode. */
> + BUG_ON(ctx->flags & EFD_MASK);
> +
...
> @@ -188,6 +213,9 @@ ssize_t eventfd_ctx_read(struct eventfd_ctx *ctx, int
> no_wait, __u64 *cnt)
> + /* This function should never be used with eventfd in the mask mode. */
> + BUG_ON(ctx->flags & EFD_MASK);
> +
If eventfd_ctx_fileget() returns EINVAL when EFD_MASK is set, I don't
think that there will be a way to call these functions in the mask mode,
so it should be possible to get rid of the BUG_ON checks.
[snip]
> @@ -230,6 +258,19 @@ static ssize_t eventfd_read(struct file *file, char
> __user *buf, size_t count,
> ssize_t res;
> __u64 cnt;
>
> + if (ctx->flags & EFD_MASK) {
> + struct efd_mask mask;
> +
> + if (count < sizeof(mask))
> + return -EINVAL;
> + spin_lock_irq(>wqh.lock);
> + mask = ctx->mask;
> + spin_unlock_irq(>wqh.lock);
> + if (copy_to_user(buf, , sizeof(mask)))
> + return -EFAULT;
> + return sizeof(mask);
> + }
> +
For the other eventfd modes, reading the value will update the internal
state of the eventfd (either clearing or decrementing the counter).
Should something similar be done here? I'm thinking of a case where a
process is polling on this fd in a loop. Clearing the efd_mask data on
read should provide an easy way for the polling process to know if it is
seeing new poll events.
> @@ -292,8 +351,13 @@ static void eventfd_show_fdinfo(struct seq_file *m,
> struct file *f)
> struct eventfd_ctx *ctx = f->private_data;
>
> spin_lock_irq(>wqh.lock);
> - seq_printf(m, "eventfd-count: %16llx\n",
> -(unsigned long long)ctx->count);
> + if (ctx->flags & EFD_MASK) {
> + seq_printf(m, "eventfd-mask: %x\n",
> + (unsigned)ctx->mask.events);
> + } else {
> + seq_printf(m, "eventfd-count: %16llx\n",
> + (unsigned long long)ctx->count);
> + }
> spin_unlock_irq(>wqh.lock);
> }
I think that putting the EFD_MASK functionality into a different fops
structure might be useful for reducing the number of if statements.
Thank you,
Damian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eventfd: implementation of EFD_MASK flag
Hi Martin,
Thanks for your comments.
On 2015-08-10 3:39 PM, Martin Sustrik wrote:
On 2015-08-10 08:23, Damian Hobson-Garcia wrote:
Replying to my own post, but I had the following comments/questions.
Martin, if you have any response to my comments I would be very happy to
hear them.
On 2015-08-10 2:51 PM, Damian Hobson-Garcia wrote:
From: Martin Sustrik sust...@250bpm.com
[snip]
write(2):
User is allowed to write only buffers containing the following
structure:
struct efd_mask {
__u32 events;
__u64 data;
};
The value of 'events' should be any combination of event flags as
defined by
poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified
events will
be signaled when polling (select, poll, epoll) on the eventfd is done
later on.
'data' is opaque data that are not interpreted by eventfd object.
I'm not fully clear on the purpose that the 'data' member serves. Does
this opaque handle need to be tied together with this event
synchronization construct?
It's a convenience thing. Imagine you are implementing your own file
descriptor type in user space. You create an EFD_MASK socket and a
structure that will hold any state that you need for the socket (tx/rx
buffers and such).
Now you have two things to pass around. If you want to pass the fd to a
function, it must have two parameters (fd and pointer to the structure).
To fix it you can put the fd into the structure. That way there's only
one thing to pass around (the structure).
The problem with that approach is when you have generic code that deals
with file descriptors. For example, a simple poller which accepts a list
of (fd, callback) pairs and invokes the callback when one of the fds
signals POLLIN. You can't send a pointer to a structure to such
function. All you can send is the fd, but then, when the callback is
invoked, fd is all you have. You have no idea where your state is.
'data' member allows you to put the pointer to the state to the socket
itself. Thus, if you have a fd, you can always find out where the
associated data is by reading the mask structure from the fd.
Ok, I see what you're saying. I guess that keeping track of the mapping
between the fd and the struct in user space could be non-trivial if
there are a large number of active fds that are polling very frequently.
Wouldn't it be sufficient to just use epoll() in this case though? It
already seems to support this kind of thing.
[snip]
@@ -55,6 +69,9 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
{
+/* This function should never be used with eventfd in the mask
mode. */
+BUG_ON(ctx-flags EFD_MASK);
+
...
@@ -158,6 +180,9 @@ int eventfd_ctx_remove_wait_queue(struct
eventfd_ctx *ctx, wait_queue_t *wait,
{
+/* This function should never be used with eventfd in the mask
mode. */
+BUG_ON(ctx-flags EFD_MASK);
+
...
@@ -188,6 +213,9 @@ ssize_t eventfd_ctx_read(struct eventfd_ctx *ctx,
int no_wait, __u64 *cnt)
+/* This function should never be used with eventfd in the mask
mode. */
+BUG_ON(ctx-flags EFD_MASK);
+
If eventfd_ctx_fileget() returns EINVAL when EFD_MASK is set, I don't
think that there will be a way to call these functions in the mask mode,
so it should be possible to get rid of the BUG_ON checks.
Sure. Feel free to do so.
[snip]
@@ -230,6 +258,19 @@ static ssize_t eventfd_read(struct file *file,
char __user *buf, size_t count,
ssize_t res;
__u64 cnt;
+if (ctx-flags EFD_MASK) {
+struct efd_mask mask;
+
+if (count sizeof(mask))
+return -EINVAL;
+spin_lock_irq(ctx-wqh.lock);
+mask = ctx-mask;
+spin_unlock_irq(ctx-wqh.lock);
+if (copy_to_user(buf, mask, sizeof(mask)))
+return -EFAULT;
+return sizeof(mask);
+}
+
For the other eventfd modes, reading the value will update the internal
state of the eventfd (either clearing or decrementing the counter).
Should something similar be done here? I'm thinking of a case where a
process is polling on this fd in a loop. Clearing the efd_mask data on
read should provide an easy way for the polling process to know if it is
seeing new poll events.
No. In this case reading the value has no effect on the state of the fd.
How it should work is rather:
// fd is in POLLIN state
poll(fd);
// function exits with POLLIN but fd remains in POLLIN state
my_recv(fd, buf, size);
// my_recv function have found out that there's no more data to recv and
switched off the POLLIN flag
poll(fd); // we block here waiting for more data to arrive from the network
How exactly doe the receiver switch off the POLLIN flag? Does the
receiver also write to the eventfd? or do you mean that it just doesn't
set POLLIN in the events mask? It seems cleaner to have the sender only
write the eventfd and the receiver only read it. Your example would be
exactly the same, except that my_recv(fd
Re: [PATCH] eventfd: implementation of EFD_MASK flag
Replying to my own post, but I had the following comments/questions.
Martin, if you have any response to my comments I would be very happy to
hear them.
On 2015-08-10 2:51 PM, Damian Hobson-Garcia wrote:
From: Martin Sustrik sust...@250bpm.com
[snip]
write(2):
User is allowed to write only buffers containing the following structure:
struct efd_mask {
__u32 events;
__u64 data;
};
The value of 'events' should be any combination of event flags as defined by
poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified events
will
be signaled when polling (select, poll, epoll) on the eventfd is done later
on.
'data' is opaque data that are not interpreted by eventfd object.
I'm not fully clear on the purpose that the 'data' member serves. Does
this opaque handle need to be tied together with this event
synchronization construct?
[snip]
@@ -55,6 +69,9 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
{
+ /* This function should never be used with eventfd in the mask mode. */
+ BUG_ON(ctx-flags EFD_MASK);
+
...
@@ -158,6 +180,9 @@ int eventfd_ctx_remove_wait_queue(struct eventfd_ctx
*ctx, wait_queue_t *wait,
{
+ /* This function should never be used with eventfd in the mask mode. */
+ BUG_ON(ctx-flags EFD_MASK);
+
...
@@ -188,6 +213,9 @@ ssize_t eventfd_ctx_read(struct eventfd_ctx *ctx, int
no_wait, __u64 *cnt)
+ /* This function should never be used with eventfd in the mask mode. */
+ BUG_ON(ctx-flags EFD_MASK);
+
If eventfd_ctx_fileget() returns EINVAL when EFD_MASK is set, I don't
think that there will be a way to call these functions in the mask mode,
so it should be possible to get rid of the BUG_ON checks.
[snip]
@@ -230,6 +258,19 @@ static ssize_t eventfd_read(struct file *file, char
__user *buf, size_t count,
ssize_t res;
__u64 cnt;
+ if (ctx-flags EFD_MASK) {
+ struct efd_mask mask;
+
+ if (count sizeof(mask))
+ return -EINVAL;
+ spin_lock_irq(ctx-wqh.lock);
+ mask = ctx-mask;
+ spin_unlock_irq(ctx-wqh.lock);
+ if (copy_to_user(buf, mask, sizeof(mask)))
+ return -EFAULT;
+ return sizeof(mask);
+ }
+
For the other eventfd modes, reading the value will update the internal
state of the eventfd (either clearing or decrementing the counter).
Should something similar be done here? I'm thinking of a case where a
process is polling on this fd in a loop. Clearing the efd_mask data on
read should provide an easy way for the polling process to know if it is
seeing new poll events.
@@ -292,8 +351,13 @@ static void eventfd_show_fdinfo(struct seq_file *m,
struct file *f)
struct eventfd_ctx *ctx = f-private_data;
spin_lock_irq(ctx-wqh.lock);
- seq_printf(m, eventfd-count: %16llx\n,
-(unsigned long long)ctx-count);
+ if (ctx-flags EFD_MASK) {
+ seq_printf(m, eventfd-mask: %x\n,
+ (unsigned)ctx-mask.events);
+ } else {
+ seq_printf(m, eventfd-count: %16llx\n,
+ (unsigned long long)ctx-count);
+ }
spin_unlock_irq(ctx-wqh.lock);
}
I think that putting the EFD_MASK functionality into a different fops
structure might be useful for reducing the number of if statements.
Thank you,
Damian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] eventfd: implementation of EFD_MASK flag
From: Martin Sustrik
When implementing network protocols in user space, one has to implement
fake file descriptors to represent the sockets for the protocol.
Polling on such fake file descriptors is a problem (poll/select/epoll accept
only true file descriptors) and forces protocol implementers to use various
workarounds resulting in complex, non-standard and convoluted APIs.
More generally, ability to create full-blown file descriptors for
userspace-to-userspace signalling is missing. While eventfd(2) goes half the way
towards this goal it has follwoing shorcomings:
I. There's no way to signal POLLPRI, POLLHUP etc.
II. There's no way to signal arbitrary combination of POLL* flags. Most notably,
simultaneous !POLLIN and !POLLOUT, which is a perfectly valid combination
for a network protocol (rx buffer is empty and tx buffer is full), cannot be
signaled using eventfd.
This patch implements new EFD_MASK flag which solves the above problems.
Additionally, to provide a way to associate user-space state with eventfd
object, it allows to attach user-space data to the file descriptor.
The semantics of EFD_MASK are as follows:
eventfd(2):
If eventfd is created with EFD_MASK flag set, it is initialised in such a way
as to signal no events on the file descriptor when it is polled on. 'initval'
argument is ignored.
write(2):
User is allowed to write only buffers containing the following structure:
struct efd_mask {
__u32 events;
__u64 data;
};
The value of 'events' should be any combination of event flags as defined by
poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified events will
be signaled when polling (select, poll, epoll) on the eventfd is done later on.
'data' is opaque data that are not interpreted by eventfd object.
read(2):
User is allowed to read an efd_mask structure from the eventfd marked by
EFD_MASK. Returned value shall be the last one written to the eventfd.
select(2), poll(2) and similar:
When polling on the eventfd marked by EFD_MASK flag, all the events specified
in last written 'events' field shall be signaled.
Signed-off-by: Martin Sustrik
---
fs/eventfd.c | 93 ++--
include/linux/eventfd.h | 16 +---
include/uapi/linux/eventfd.h | 40 +++
3 files changed, 123 insertions(+), 26 deletions(-)
create mode 100644 include/uapi/linux/eventfd.h
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 8d0c0df..11fb92a 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -2,6 +2,7 @@
* fs/eventfd.c
*
* Copyright (C) 2007 Davide Libenzi
+ * Copyright (C) 2013 Martin Sustrik
*
*/
@@ -22,18 +23,31 @@
#include
#include
+#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
+#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | EFD_MASK)
+#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP)
+
struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
- /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
- __u64 count;
+ union {
+ /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the
+* "count" value to userspace, and will reset "count" to zero.
+* The kernel side eventfd_signal() also, adds to the "count"
+* counter and issue a wakeup.
+*/
+ __u64 count;
+
+ /*
+* When using eventfd in EFD_MASK mode this stracture stores the
+* current events to be signaled on the eventfd (events member)
+* along with opaque user-defined data (data member).
+*/
+ struct efd_mask mask;
+ };
unsigned int flags;
};
@@ -55,6 +69,9 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
{
unsigned long flags;
+ /* This function should never be used with eventfd in the mask mode. */
+ BUG_ON(ctx->flags & EFD_MASK);
+
spin_lock_irqsave(>wqh.lock, flags);
if (ULLONG_MAX - ctx->count < n)
n = ULLONG_MAX - ctx->count;
@@ -124,6 +141,11 @@ static unsigned int eventfd_poll(struct file *file,
poll_table *wait)
smp_rmb();
count = ctx->count;
+ if (ctx->flags & EFD_MASK) {
+ events = ctx->mask.events;
+ return events;
+ }
+
if (count > 0)
events |= POLLIN;
if
[RFC/PATCH] Generalize poll events from eventfd
Hello all,
eventfd is very useful for generating POLLIN/POLLOUT poll events from user
space but some applications may want to generate POLLPRI/POLLERR events as well.
This patch submission aims to generalize the events generated by an
eventfd. This is a resubmission of a patch from Feb 2013[1]. The original
discussion trailed off without any conclusion, but the original author
has recently confirmed[2] that this functionality is still useful, so I
volunteered to rebase and resubmit the patch for discussion.
I have rebased this patch onto v4.2-rc5 and modified the original patch to
not add an indentation level to the implementations of eventfd_{read,write,
poll}. I hope these changes will make it easier to review. The description of
the efd_mask structure was also updated.
I have a few comments and questions, but I will add those separately as a
reply for open discussion.
[1] https://lkml.org/lkml/2013/2/18/147
[2] https://lkml.org/lkml/2015/7/9/153
Thank you,
Damian
Martin Sustrik (1):
eventfd: implementation of EFD_MASK flag
fs/eventfd.c | 91 ++--
include/linux/eventfd.h | 16 +---
include/uapi/linux/eventfd.h | 40 +++
3 files changed, 121 insertions(+), 26 deletions(-)
create mode 100644 include/uapi/linux/eventfd.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
