All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v6 1/2] mm: Add MREMAP_DONTUNMAP to mremap().
From: Kirill A. Shutemov @ 2020-02-20 11:57 UTC (permalink / raw)
  To: Brian Geffon
  Cc: Andrew Morton, Michael S . Tsirkin, Arnd Bergmann, linux-kernel,
	linux-mm, linux-api, Andy Lutomirski, Will Deacon,
	Andrea Arcangeli, Sonny Rao, Minchan Kim, Joel Fernandes, Yu Zhao,
	Jesse Barnes, Florian Weimer
In-Reply-To: <20200218173221.237674-1-bgeffon@google.com>

On Tue, Feb 18, 2020 at 09:32:20AM -0800, Brian Geffon wrote:
> When remapping an anonymous, private mapping, if MREMAP_DONTUNMAP is
> set, the source mapping will not be removed. The remap operation
> will be performed as it would have been normally by moving over the
> page tables to the new mapping. The old vma will have any locked
> flags cleared, have no pagetables, and any userfaultfds that were
> watching that range will continue watching it.
> 
> For a mapping that is shared or not anonymous, MREMAP_DONTUNMAP will cause
> the mremap() call to fail. Because MREMAP_DONTUNMAP always results in moving
> a VMA you MUST use the MREMAP_MAYMOVE flag. The final result is two
> equally sized VMAs where the destination contains the PTEs of the source.
> 
> We hope to use this in Chrome OS where with userfaultfd we could write
> an anonymous mapping to disk without having to STOP the process or worry
> about VMA permission changes.
> 
> This feature also has a use case in Android, Lokesh Gidra has said
> that "As part of using userfaultfd for GC, We'll have to move the physical
> pages of the java heap to a separate location. For this purpose mremap
> will be used. Without the MREMAP_DONTUNMAP flag, when I mremap the java
> heap, its virtual mapping will be removed as well. Therefore, we'll
> require performing mmap immediately after. This is not only time consuming
> but also opens a time window where a native thread may call mmap and
> reserve the java heap's address range for its own usage. This flag
> solves the problem."
> 
>   v5 -> v6:
>     - Code cleanup suggested by Kirill.
> 
>   v4 -> v5:
>     - Correct commit message to more accurately reflect the behavior.
>     - Clear VM_LOCKED and VM_LOCKEDONFAULT on the old vma.
>            
> Signed-off-by: Brian Geffon <bgeffon@google.com>
> ---
>  include/uapi/linux/mman.h |   5 +-
>  mm/mremap.c               | 103 ++++++++++++++++++++++++++++++--------
>  2 files changed, 85 insertions(+), 23 deletions(-)
> 
> diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
> index fc1a64c3447b..923cc162609c 100644
> --- a/include/uapi/linux/mman.h
> +++ b/include/uapi/linux/mman.h
> @@ -5,8 +5,9 @@
>  #include <asm/mman.h>
>  #include <asm-generic/hugetlb_encode.h>
>  
> -#define MREMAP_MAYMOVE	1
> -#define MREMAP_FIXED	2
> +#define MREMAP_MAYMOVE		1
> +#define MREMAP_FIXED		2
> +#define MREMAP_DONTUNMAP	4
>  
>  #define OVERCOMMIT_GUESS		0
>  #define OVERCOMMIT_ALWAYS		1
> diff --git a/mm/mremap.c b/mm/mremap.c
> index 1fc8a29fbe3f..fa27103502c5 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -318,8 +318,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
>  static unsigned long move_vma(struct vm_area_struct *vma,
>  		unsigned long old_addr, unsigned long old_len,
>  		unsigned long new_len, unsigned long new_addr,
> -		bool *locked, struct vm_userfaultfd_ctx *uf,
> -		struct list_head *uf_unmap)
> +		bool *locked, unsigned long flags,
> +		struct vm_userfaultfd_ctx *uf, struct list_head *uf_unmap)
>  {
>  	struct mm_struct *mm = vma->vm_mm;
>  	struct vm_area_struct *new_vma;
> @@ -408,11 +408,46 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>  	if (unlikely(vma->vm_flags & VM_PFNMAP))
>  		untrack_pfn_moved(vma);
>  
> +	if (unlikely(!err && (flags & MREMAP_DONTUNMAP))) {
> +		if (vm_flags & VM_ACCOUNT) {
> +			/* Always put back VM_ACCOUNT since we won't unmap */
> +			vma->vm_flags |= VM_ACCOUNT;
> +
> +			vm_acct_memory(vma_pages(new_vma));
> +		}
> +
> +		/*
> +		 * locked_vm accounting: if the mapping remained the same size
> +		 * it will have just moved and we don't need to touch locked_vm
> +		 * because we skip the do_unmap. If the mapping shrunk before
> +		 * being moved then the do_unmap on that portion will have
> +		 * adjusted vm_locked. Only if the mapping grows do we need to
> +		 * do something special; the reason is locked_vm only accounts
> +		 * for old_len, but we're now adding new_len - old_len locked
> +		 * bytes to the new mapping.
> +		 */
> +		if (vm_flags & VM_LOCKED && new_len > old_len) {
> +			mm->locked_vm += (new_len - old_len) >> PAGE_SHIFT;
> +			*locked = true;
> +		}
> +
> +		/* We always clear VM_LOCKED[ONFAULT] on the old vma */
> +		vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
> +
> +		goto out;
> +	}
> +
>  	if (do_munmap(mm, old_addr, old_len, uf_unmap) < 0) {
>  		/* OOM: unable to split vma, just get accounts right */
>  		vm_unacct_memory(excess >> PAGE_SHIFT);
>  		excess = 0;
>  	}
> +
> +	if (vm_flags & VM_LOCKED) {
> +		mm->locked_vm += new_len >> PAGE_SHIFT;
> +		*locked = true;
> +	}
> +out:
>  	mm->hiwater_vm = hiwater_vm;
>  
>  	/* Restore VM_ACCOUNT if one or two pieces of vma left */
> @@ -422,16 +457,12 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>  			vma->vm_next->vm_flags |= VM_ACCOUNT;
>  	}
>  
> -	if (vm_flags & VM_LOCKED) {
> -		mm->locked_vm += new_len >> PAGE_SHIFT;
> -		*locked = true;
> -	}
> -
>  	return new_addr;
>  }
>  
>  static struct vm_area_struct *vma_to_resize(unsigned long addr,
> -	unsigned long old_len, unsigned long new_len, unsigned long *p)
> +	unsigned long old_len, unsigned long new_len, unsigned long flags,
> +	unsigned long *p)
>  {
>  	struct mm_struct *mm = current->mm;
>  	struct vm_area_struct *vma = find_vma(mm, addr);
> @@ -453,6 +484,10 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
>  		return ERR_PTR(-EINVAL);
>  	}
>  
> +	if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) ||
> +			vma->vm_flags & VM_SHARED))
> +		return ERR_PTR(-EINVAL);
> +
>  	if (is_vm_hugetlb_page(vma))
>  		return ERR_PTR(-EINVAL);
>  
> @@ -497,7 +532,7 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
>  
>  static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
>  		unsigned long new_addr, unsigned long new_len, bool *locked,
> -		struct vm_userfaultfd_ctx *uf,
> +		unsigned long flags, struct vm_userfaultfd_ctx *uf,
>  		struct list_head *uf_unmap_early,
>  		struct list_head *uf_unmap)
>  {
> @@ -505,7 +540,7 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
>  	struct vm_area_struct *vma;
>  	unsigned long ret = -EINVAL;
>  	unsigned long charged = 0;
> -	unsigned long map_flags;
> +	unsigned long map_flags = 0;
>  
>  	if (offset_in_page(new_addr))
>  		goto out;
> @@ -534,9 +569,11 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
>  	if ((mm->map_count + 2) >= sysctl_max_map_count - 3)
>  		return -ENOMEM;
>  
> -	ret = do_munmap(mm, new_addr, new_len, uf_unmap_early);
> -	if (ret)
> -		goto out;
> +	if (flags & MREMAP_FIXED) {
> +		ret = do_munmap(mm, new_addr, new_len, uf_unmap_early);
> +		if (ret)
> +			goto out;
> +	}
>  
>  	if (old_len >= new_len) {
>  		ret = do_munmap(mm, addr+new_len, old_len - new_len, uf_unmap);
> @@ -545,13 +582,26 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
>  		old_len = new_len;
>  	}
>  
> -	vma = vma_to_resize(addr, old_len, new_len, &charged);
> +	vma = vma_to_resize(addr, old_len, new_len, flags, &charged);
>  	if (IS_ERR(vma)) {
>  		ret = PTR_ERR(vma);
>  		goto out;
>  	}
>  
> -	map_flags = MAP_FIXED;
> +	/*
> +	 * MREMAP_DONTUNMAP expands by new_len - (new_len - old_len), we will
> +	 * check that we can expand by new_len and vma_to_resize will handle
> +	 * the vma growing which is (new_len - old_len).
> +	 */

< Sorry for delay. >

I have hard time understanding the case when new_len != old_len.

Correct me if I'm wrong, but looks like that you change the size of old
mapping to be the new_len and then create a new of the same new_len.

This doesn't look right to me.

In my opinion, MREMAP_DONTUNMAP has to leave the old mapping intact. And
create the new mapping adjusted to the new_len.

Other option is to force new_len == old_len if MREMAP_DONTUNMAP is
specified. It would simplify the implementation. And I don't see why
anybody would really want anything else.

> +	if (flags & MREMAP_DONTUNMAP &&
> +		!may_expand_vm(mm, vma->vm_flags, new_len >> PAGE_SHIFT)) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	if (flags & MREMAP_FIXED)
> +		map_flags |= MAP_FIXED;
> +
>  	if (vma->vm_flags & VM_MAYSHARE)
>  		map_flags |= MAP_SHARED;
>  
> @@ -561,10 +611,16 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len,
>  	if (offset_in_page(ret))
>  		goto out1;
>  
> -	ret = move_vma(vma, addr, old_len, new_len, new_addr, locked, uf,
> +	/* We got a new mapping */
> +	if (!(flags & MREMAP_FIXED))
> +		new_addr = ret;
> +
> +	ret = move_vma(vma, addr, old_len, new_len, new_addr, locked, flags, uf,
>  		       uf_unmap);
> +
>  	if (!(offset_in_page(ret)))
>  		goto out;

Not related to the effort directly, but do we really use offset_in_page()
as a substitute for IS_ERR() here. That's disgusting.

> +
>  out1:
>  	vm_unacct_memory(charged);
>  
> @@ -609,12 +665,16 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
>  	addr = untagged_addr(addr);
>  	new_addr = untagged_addr(new_addr);
>  
> -	if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
> +	if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE | MREMAP_DONTUNMAP))
>  		return ret;
>  
>  	if (flags & MREMAP_FIXED && !(flags & MREMAP_MAYMOVE))
>  		return ret;
>  
> +	/* MREMAP_DONTUNMAP is always a move */
> +	if (flags & MREMAP_DONTUNMAP && !(flags & MREMAP_MAYMOVE))
> +		return ret;
> +
>  	if (offset_in_page(addr))
>  		return ret;
>  
> @@ -632,9 +692,10 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
>  	if (down_write_killable(&current->mm->mmap_sem))
>  		return -EINTR;
>  
> -	if (flags & MREMAP_FIXED) {
> +	if (flags & (MREMAP_FIXED | MREMAP_DONTUNMAP)) {
>  		ret = mremap_to(addr, old_len, new_addr, new_len,
> -				&locked, &uf, &uf_unmap_early, &uf_unmap);
> +				&locked, flags, &uf, &uf_unmap_early,
> +				&uf_unmap);
>  		goto out;
>  	}
>  
> @@ -662,7 +723,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
>  	/*
>  	 * Ok, we need to grow..
>  	 */
> -	vma = vma_to_resize(addr, old_len, new_len, &charged);
> +	vma = vma_to_resize(addr, old_len, new_len, flags, &charged);
>  	if (IS_ERR(vma)) {
>  		ret = PTR_ERR(vma);
>  		goto out;
> @@ -712,7 +773,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
>  		}
>  
>  		ret = move_vma(vma, addr, old_len, new_len, new_addr,
> -			       &locked, &uf, &uf_unmap);
> +			       &locked, flags, &uf, &uf_unmap);
>  	}
>  out:
>  	if (offset_in_page(ret)) {
> -- 
> 2.25.0.265.gbab2e86ba0-goog
> 

-- 
 Kirill A. Shutemov

^ permalink raw reply

* Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()
From: Andy Shevchenko @ 2020-02-20 11:57 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Sascha Hauer, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Jacek Anaszewski, Pavel Machek,
	Jiri Slaby, Linux LED Subsystem, Dan Murphy
In-Reply-To: <CAHp75Vd3KN81qxOWJQ7v=GimSLtVymur_iPsf91pka1STc1nfA@mail.gmail.com>

On Thu, Feb 20, 2020 at 1:46 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Feb 20, 2020 at 12:57 PM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Thu, Feb 20, 2020 at 12:22:36PM +0200, Andy Shevchenko wrote:

...

> > Also I don't understand yet, what you want me to do.
>
> I have issues with kstrto() not playing with simple numbers (boolean

s/simple/simple and single/

> is a special case, but still a number at the end).
> I also don't feel good with too narrow usage of the newly introduced helper
>
> > Assume I'd be
> > willing to use simple_strtoul, I'd still want to have a function that
> > gives me a dev_t from a given string. Should I put this directly in my
> > led-trigger driver?
>
> I see the following possibilities:

(above doesn't imply the necessity of simple_strto*() use)

> a) put it inside the caller and forget about generic helper
> b) do a generic helper, but 1/ in string_*() namespace, 2/ with a
> delimiter parameter and 3/ possibility to take negative numbers
>
> In b) case, add to the commit message how many potential _existing_
> users may be converted to this.
> Also it would be good to have two versions strict (only \n at the end
> is allowed) and non-strict (based on the amount of users for each
> group).

And don't forget to extend lib/test_string.c accordingly.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* Re: [PATCH v1 0/2] perf report: Support annotation of code without symbols
From: Jiri Olsa @ 2020-02-20 11:56 UTC (permalink / raw)
  To: Jin Yao
  Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
	kan.liang, yao.jin
In-Reply-To: <20200220005902.8952-1-yao.jin@linux.intel.com>

On Thu, Feb 20, 2020 at 08:59:00AM +0800, Jin Yao wrote:
> For perf report on stripped binaries it is currently impossible to do
> annotation. The annotation state is all tied to symbols, but there are
> either no symbols, or symbols are not covering all the code.
> 
> We should support the annotation functionality even without symbols.
> 
> The first patch uses al_addr to print because it's easy to dump
> the instructions from this address in binary for branch mode.
> 
> The second patch supports the annotation on stripped binary.
> 
> Jin Yao (2):
>   perf util: Print al_addr when symbol is not found
>   perf annotate: Support interactive annotation of code without symbols

looks good, but I'm getting crash when annotating unresolved kernel address:

jirka


Samples: 14  of event 'cycles:u', Event count (approx.): 1822321
Overhead  Command  Shared Object     Symbol
  26.86%  ls       libc-2.30.so      [.] __strcoll_l                                                                                                                                                               ▒
  17.03%  ls       ls                [.] 0x0000000000008968                                                                                                                                                        ▒
  13.10%  ls       [unknown]         [k] 0xffffffff81c00ae7                                                                                                                                                        ▒
  13.02%  ls       ld-2.30.so        [.] _dl_cache_libcmp                                                                                                                                                          ▒
  12.84%  ls       libc-2.30.so      [.] _int_malloc                                                                                                                                                               ▒
  11.94%  ls       libc-2.30.so      [.] __memcpy_chk                                                                                                                                                              ▒
   5.21%  ls       ld-2.30.so        [.] __GI___tunables_init                                                                                                                                                      ▒
                                                                                                                                                                                                                   ▒
                                                                                                                                                                                                                   Program received signal SIGSEGV, Segmentation fault.                                                                                                                                                                ▒
                                                   add_annotate_opt (browser=0xec34a0, act=0x7fffffffabf0, optstr=0x7fffffffab70, ms=0xdbdb60, addr=18446744071591430887) at ui/browsers/hists.c:2500              ▒
2500            if (ms->map->dso->annotate_warned)                                                                                                                                                                 ▒
Missing separate debuginfos, use: dnf debuginfo-install brotli-1.0.7-6.fc31.x86_64 bzip2-libs-1.0.8-1.fc31.x86_64 cyrus-sasl-lib-2.1.27-2.fc31.x86_64 elfutils-debuginfod-client-0.178-7.fc31.x86_64 elfutils-libelf-0.178-7.fc31.x86_64 elfutils-libs-0.178-7.fc31.x86_64 glib2-2.62.5-1.fc31.x86_64 keyutils-libs-1.6-3.fc31.x86_64 krb5-libs-1.17-46.fc31.x86_64 libbabeltrace-1.5.7-2.fc31.x86_64 libcap-2.26-6.fc31.x86_64 libcom_err-1.45.5-1.fc31.x86_64 libcurl-7.66.0-1.fc31.x86_64 libgcc-9.2.1-1.fc31.x86_64 libidn2-2.3.0-1.fc31.x86_64 libnghttp2-1.40.0-1.fc31.x86_64 libpsl-0.21.0-2.fc31.x86_64 libselinux-2.9-5.fc31.x86_64 libssh-0.9.3-1.fc31.x86_64 libunwind-1.3.1-5.fc31.x86_64 libuuid-2.34-4.fc31.x86_64 libxcrypt-4.4.14-1.fc31.x86_64 libzstd-1.4.4-1.fc31.x86_64 openldap-2.4.47-3.fc31.x86_64 openssl-libs-1.1.1d-2.fc31.x86_64 pcre-8.43-3.fc31.x86_64 pcre2-10.34-6.fc31.x86_64 perl-libs-5.30.1-449.fc31.x86_64 popt-1.16-18.fc31.x86_64 python2-libs-2.7.17-1.fc31.x86_64 slang-2.3.2-6.fc31.x86_64 xz-libs-5.2.4-6.fc31.x86_64 zlib-1.2.11-20.fc31.x86_64         ▒
(gdb) bt                                                                                                                                                                                                           ▒
#0  add_annotate_opt (browser=0xec34a0, act=0x7fffffffabf0, optstr=0x7fffffffab70, ms=0xdbdb60, addr=18446744071591430887) at ui/browsers/hists.c:2500                                                             ▒
#1  0x000000000061caf9 in perf_evsel__hists_browse (evsel=0xc58860, nr_events=1, helpline=0xef69f0 "Tip: Show current config key-value pairs: perf config --list", left_exits=false, hbt=0x0, min_pcnt=0,          ▒
    env=0xc5c7b0, warn_lost_event=true, annotation_opts=0x7fffffffb518) at ui/browsers/hists.c:3265                                                                                                                ▒
#2  0x000000000061dbc2 in perf_evlist__tui_browse_hists (evlist=0xc55ed0, help=0xef69f0 "Tip: Show current config key-value pairs: perf config --list", hbt=0x0, min_pcnt=0, env=0xc5c7b0, warn_lost_event=true,   ▒
    annotation_opts=0x7fffffffb518) at ui/browsers/hists.c:3569                                                                                                                                                    ▒
#3  0x00000000004511e4 in report__browse_hists (rep=0x7fffffffb380) at builtin-report.c:630                                                                                                                        ▒
#4  0x00000000004521db in __cmd_report (rep=0x7fffffffb380) at builtin-report.c:975                                                                                                                                ▒
#5  0x000000000045444a in cmd_report (argc=0, argv=0x7fffffffd820) at builtin-report.c:1540                                                                                                                        ▒
#6  0x00000000004e384a in run_builtin (p=0xa5b370 <commands+240>, argc=1, argv=0x7fffffffd820) at perf.c:312                                                                                                       ▒
#7  0x00000000004e3ab7 in handle_internal_command (argc=1, argv=0x7fffffffd820) at perf.c:364                                                                                                                      ▒
#8  0x00000000004e3bfe in run_argv (argcp=0x7fffffffd67c, argv=0x7fffffffd670) at perf.c:408                                                                                                                       ▒
#9  0x00000000004e3fca in main (argc=1, argv=0x7fffffffd820) at perf.c:538                                                                                                                                         ▒
(gdb)                                                                                                                                                                                                              ▒





^ permalink raw reply

* [PATCH v3 2/5] powerpc: Add current_stack_pointer as a register global
From: Michael Ellerman @ 2020-02-20 11:51 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <20200220115141.2707-1-mpe@ellerman.id.au>

From: Christophe Leroy <christophe.leroy@c-s.fr>

current_stack_frame() doesn't return the stack pointer, but the
caller's stack frame. See commit bfe9a2cfe91a ("powerpc: Reimplement
__get_SP() as a function not a define") and commit
acf620ecf56c ("powerpc: Rename __get_SP() to current_stack_pointer()")
for details.

In some cases this is overkill or incorrect, as it doesn't return the
current value of r1.

So add a current_stack_pointer register global to get the value of r1
directly.

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
[mpe: Split out of other patch, tweak change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/435e0030e942507766cbef5bc95f906262d2ccf2.1579849665.git.christophe.leroy@c-s.fr
---
 arch/powerpc/include/asm/reg.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 1b1ffdba6097..da5cab038e25 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1450,6 +1450,8 @@ static inline void mtsrin(u32 val, u32 idx)
 
 extern unsigned long current_stack_frame(void);
 
+register unsigned long current_stack_pointer asm("r1");
+
 extern unsigned long scom970_read(unsigned int address);
 extern void scom970_write(unsigned int address, unsigned long value);
 
-- 
2.21.1

v3: Split out, and use current_stack_pointer not get_sp()

^ permalink raw reply related

* Re: [PATCH] gstreamer: Fix reproducibility issue around libcap
From: Martin Hundebøll @ 2020-02-20 11:56 UTC (permalink / raw)
  To: Richard Purdie, openembedded-core
In-Reply-To: <20200219152355.123718-1-richard.purdie@linuxfoundation.org>

Hi,

On 19/02/2020 16.23, Richard Purdie wrote:
> Add an option to avoid builds depending on the presence of setcap
> from the host system.
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>   .../gstreamer/gstreamer1.0/capfix.patch       | 37 +++++++++++++++++++
>   .../gstreamer/gstreamer1.0_1.16.1.bb          |  2 +
>   2 files changed, 39 insertions(+)
>   create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
> 
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
> new file mode 100644
> index 00000000000..7ca3d5ad4a6
> --- /dev/null
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0/capfix.patch
> @@ -0,0 +1,37 @@
> +Currently gstreamer configuration depends on whether setcap is found on the host
> +system. Turn this into a configure option to make builds deterinistic.
> +
> +RP 2020/2/19
> +Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> +Upstream-Status: Pending
> +
> +Index: gstreamer-1.16.1/libs/gst/helpers/meson.build
> +===================================================================
> +--- gstreamer-1.16.1.orig/libs/gst/helpers/meson.build
> ++++ gstreamer-1.16.1/libs/gst/helpers/meson.build
> +@@ -73,7 +73,12 @@ if have_ptp
> +     endif
> +   endif
> +
> +-  setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', required : false)
> ++  setcap_feature = get_option('setcap')
> ++  if setcap_feature.disabled()
> ++    setcap = find_program('dontexist', required : false)
> ++  else
> ++    setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', required : false)
> ++  endif

I think this can be simplified by using get_option() directly for the 
"required" argument:

setcap = find_program('setcap', '/usr/sbin/setcap', '/sbin/setcap', 
required : get_option('setcap'))

// Martin
> +
> +   # user/group to change to in gst-ptp-helper
> +   ptp_helper_setuid_user = get_option('ptp-helper-setuid-user')
> +Index: gstreamer-1.16.1/meson_options.txt
> +===================================================================
> +--- gstreamer-1.16.1.orig/meson_options.txt
> ++++ gstreamer-1.16.1/meson_options.txt
> +@@ -26,6 +26,7 @@ option('libunwind', type : 'feature', va
> + option('libdw', type : 'feature', value : 'auto', description : 'Use libdw to generate better backtraces from libunwind')
> + option('dbghelp', type : 'feature', value : 'auto', description : 'Use dbghelp to generate backtraces')
> + option('bash-completion', type : 'feature', value : 'auto', description : 'Install bash completion files')
> ++option('setcap', type : 'feature', value : 'auto', description : 'Use setcap')
> +
> + # Common feature options
> + option('examples', type : 'feature', value : 'auto', yield : true)
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
> index 6b8a5a0eb01..68f5ca649fe 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.16.1.bb
> @@ -21,6 +21,7 @@ SRC_URI = " \
>       file://0002-meson-build-gir-even-when-cross-compiling-if-introsp.patch \
>       file://0003-meson-Add-valgrind-feature.patch \
>       file://0004-meson-Add-option-for-installed-tests.patch \
> +    file://capfix.patch \
>   "
>   SRC_URI[md5sum] = "c505fb818b36988daaa846e9e63eabe8"
>   SRC_URI[sha256sum] = "02211c3447c4daa55919c5c0f43a82a6fbb51740d57fc3af0639d46f1cf4377d"
> @@ -39,6 +40,7 @@ PACKAGECONFIG[unwind] = "-Dlibunwind=enabled,-Dlibunwind=disabled,libunwind"
>   PACKAGECONFIG[dw] = "-Dlibdw=enabled,-Dlibdw=disabled,elfutils"
>   PACKAGECONFIG[bash-completion] = "-Dbash-completion=enabled,-Dbash-completion=disabled,bash-completion"
>   PACKAGECONFIG[tools] = "-Dtools=enabled,-Dtools=disabled"
> +PACKAGECONFIG[setcap] = "-Dsetcap=enabled,-Dsetcap=disabled,libcap"
>   
>   # TODO: put this in a gettext.bbclass patch
>   def gettext_oemeson(d):
> 


^ permalink raw reply

* Re: [yocto] how to reuse generated library in a nativesdk recipe #sdk #systemd
From: Martin Jansa @ 2020-02-20 11:55 UTC (permalink / raw)
  To: Mikko.Rapeli; +Cc: j.armandohernandez.j, yocto
In-Reply-To: <20200220081404.GF104502@korppu>

[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]

On Thu, Feb 20, 2020 at 08:14:04AM +0000, Mikko.Rapeli@bmw.de wrote:
> On Wed, Feb 19, 2020 at 10:57:41PM +0100, Martin Jansa wrote:
> > > DEPENDS_class-target += "systemd"
> > 
> > You surely meant
> > DEPENDS_append_class-target = " systemd"
> > here
> 
> Yes, quite likely. Tough reason why += doesn't work is a mystery to me :)
> 
> I hack things until "bitbake -e" shows the right things for the recipes.

I agree it's a bit confusing at first (I was doing the same long time
ago, before bitbake -e was even showing the history of evaluation), but
everybody who uses bitbake often should learn this simple difference:

FOO_append_override = " bar"
  is "conditional" append, so it will append "bar" only when "override" is
being used

FOO_override += "bar"
  always appends to "FOO_override" and then it overrides whole "FOO" variable

There are other more subtle differences like "+=" adds leading space,
_append doesn't and _append is processed later (which is important when
appending to variable set with ?=), but the above difference is a must
to know.

Also
FOO_append += "bar"
is just silly way how to add leading space to the value, one should
always use
FOO_append = " bar"
when appending to space separated list (like DEPENDS).

Cheers,

> -Mikko
> 
> > On Wed, Feb 19, 2020 at 10:48 PM Mikko Rapeli <mikko.rapeli@bmw.de> wrote:
> > 
> > > Hi,
> > >
> > > On Wed, Feb 19, 2020 at 01:37:19AM -0800, Armando Hernandez wrote:
> > > > Hello,
> > > >
> > > > I have a recipe that builds a library. The recipe specifies an
> > > additional package "${PN}-systemd" along with other systemd related
> > > variables and finally it instructs that the package should be built with
> > > "-DWITH_SYSTEMD=ON" being passed to cmake. So far so good. But, I extended
> > > this recipe to nativesdk because I need this library on it. When trying to
> > > build the corresponding nativesdk package, the build fails at the
> > > configuration step (i.e. "do_configure") claiming it cannot find the
> > > package systemd.
> > > >
> > > > Is there a way I can install the -already-generated libraries into my
> > > SDK (potentially via the corresponding nativesdk recipe) without having to
> > > rebuild the package? Or do I need to somehow include such systemd package
> > > in my sdk (which I don't think I need at all)?
> > > >
> > > > Any hints and pointers as to were to look at are very well appreciated.
> > > > Thanks.
> > >
> > > Make the systemd dependency for target only, e.g. DEPENDS_class-target +=
> > > "systemd"
> > > etc.
> > >
> > > There may be relevant use cases to build some of systemd components or
> > > tools
> > > to native or nativesdk targets too. In that case add BBCLASSEXTEND +=
> > > "nativesdk" etc
> > > in a bbappend to systemd.
> > >
> > > Hope this helps,
> > >
> > > -Mikko
> > >

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

^ permalink raw reply

* Re: Questions about logic_pio
From: Jiaxun Yang @ 2020-02-20 11:55 UTC (permalink / raw)
  To: John Garry
  Cc: Wei Xu, bhelgaas, andyshevchenko, Arnd Bergmann, linux-kernel,
	Linux Mips
In-Reply-To: <e3ddd7de-54b2-bdba-2233-6ace40072430@huawei.com>




 ---- 在 星期四, 2020-02-20 18:52:38 John Garry <john.garry@huawei.com> 撰写 ----
Also Cc MIPS list to check other's opinions.

Hi John.

Thanks for your kind explanation, however, I think this way is
violating how I/O ports supposed to work, at least in MIPS world.

 > >>
 > >> After dig into logic pio logic, I found that logic pio is trying to "allocate" an io_start
 > >> for MMIO ranges, the allocation starts from 0x0. And later the io_start is used to calculate
 > >> cpu_address.  In my opinion, for direct MMIO access, logic_pio address should always
 > >> equal to hw address,
 > 
 > I'm not sure what you mean by simply the hw address.
 > 

I meant  hw_start should always equal to io_start.


MIPS have their own wrapped inl/outl functions, doing the samething with
PCI_IOBASE enabled one. I was just trying to use PCI_IOBASE instead.

Originally, the I/O ports layout seems like this:

00000020-00000021 : pic1
00000060-0000006f : i8042
00000070-00000077 : rtc0
000000a0-000000a1 : pic2
00000170-00000177 : pata_atiixp
000001f0-000001f7 : pata_atiixp
00000376-00000376 : pata_atiixp
000003f6-000003f6 : pata_atiixp
00000800-000008ff : acpi
00001000-00001008 : piix4_smbus
00004000-0003ffff : pci io space
  00004000-00004fff : PCI Bus 0000:01
    00004000-000040ff : 0000:01:05.0
  00005000-00005fff : PCI Bus 0000:03
    00005000-0000501f : 0000:03:00.0

But with PCI_IOBASE defined, I got this:

host bridge /bus@10000000/pci@10000000 ranges:
      MEM 0x0040000000..0x007fffffff -> 0x0040000000
       IO 0x0000004000..0x0000007fff -> 0x0000004000
resource collision: [io  0x0000-0x3fff] conflicts with pic1 [io  0x0020-0x0021]

Because io_start was allocated to 0x0 by Logic PIO.

There are a lot of devices that have fixed ioports thanks to x86's legacy.
For example, in my hardware, ioports for RTC, PIC, I8042 are unmoveable,
and they can't be managed by logic pio subsystem.
Also, the PCI Hostbridge got implied by DeviceTree that it's I/O range
started from 0x4000 in bus side, but then, Logic PIO remapped to PCI_IOBASE + 0x0.
The real address should be PCI_IOBASE + 0x4000,
hardware never got correctly informed about that. And there is still no way to
transform to correct address as it's inside the MMIO_LIMIT.

So the question comes to why we're allocating io_start for MMIO PCI_IOBASE
rather than just check the range provided doesn't overlap each other or exceed
the MMIO_LIMIT.

Thanks.

--
Jiaxun Yang

^ permalink raw reply

* [PATCH v3 1/5] powerpc: Rename current_stack_pointer() to current_stack_frame()
From: Michael Ellerman @ 2020-02-20 11:51 UTC (permalink / raw)
  To: linuxppc-dev

current_stack_pointer(), which was called __get_SP(), used to just
return the value in r1.

But that caused problems in some cases, so it was turned into a
function in commit bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a
function not a define").

Because it's a function in a separate compilation unit to all its
callers, it has the effect of causing a stack frame to be created, and
then returns the address of that frame. This is good in some cases
like those described in the above commit, but in other cases it's
overkill, we just need to know what stack page we're on.

On some other arches current_stack_pointer is just a register global
giving the stack pointer, and we'd like to do that too. So rename our
current_stack_pointer() to current_stack_frame() to make that
possible.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/include/asm/perf_event.h | 2 +-
 arch/powerpc/include/asm/reg.h        | 2 +-
 arch/powerpc/kernel/irq.c             | 4 ++--
 arch/powerpc/kernel/misc.S            | 4 ++--
 arch/powerpc/kernel/process.c         | 2 +-
 arch/powerpc/kernel/stacktrace.c      | 6 +++---
 6 files changed, 10 insertions(+), 10 deletions(-)

v3: New.

diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
index 7426d7a90e1e..eed3954082fa 100644
--- a/arch/powerpc/include/asm/perf_event.h
+++ b/arch/powerpc/include/asm/perf_event.h
@@ -32,7 +32,7 @@
 	do {							\
 		(regs)->result = 0;				\
 		(regs)->nip = __ip;				\
-		(regs)->gpr[1] = current_stack_pointer();	\
+		(regs)->gpr[1] = current_stack_frame();		\
 		asm volatile("mfmsr %0" : "=r" ((regs)->msr));	\
 	} while (0)
 
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 1aa46dff0957..1b1ffdba6097 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1448,7 +1448,7 @@ static inline void mtsrin(u32 val, u32 idx)
 
 #define proc_trap()	asm volatile("trap")
 
-extern unsigned long current_stack_pointer(void);
+extern unsigned long current_stack_frame(void);
 
 extern unsigned long scom970_read(unsigned int address);
 extern void scom970_write(unsigned int address, unsigned long value);
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 5c9b11878555..02118c18434d 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -602,7 +602,7 @@ static inline void check_stack_overflow(void)
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
 	long sp;
 
-	sp = current_stack_pointer() & (THREAD_SIZE-1);
+	sp = current_stack_frame() & (THREAD_SIZE-1);
 
 	/* check for stack overflow: is there less than 2KB free? */
 	if (unlikely(sp < 2048)) {
@@ -647,7 +647,7 @@ void do_IRQ(struct pt_regs *regs)
 	void *cursp, *irqsp, *sirqsp;
 
 	/* Switch to the irq stack to handle this */
-	cursp = (void *)(current_stack_pointer() & ~(THREAD_SIZE - 1));
+	cursp = (void *)(current_stack_frame() & ~(THREAD_SIZE - 1));
 	irqsp = hardirq_ctx[raw_smp_processor_id()];
 	sirqsp = softirq_ctx[raw_smp_processor_id()];
 
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 974f65f79a8e..65f9f731c229 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -110,7 +110,7 @@ _GLOBAL(longjmp)
 	li	r3, 1
 	blr
 
-_GLOBAL(current_stack_pointer)
+_GLOBAL(current_stack_frame)
 	PPC_LL	r3,0(r1)
 	blr
-EXPORT_SYMBOL(current_stack_pointer)
+EXPORT_SYMBOL(current_stack_frame)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e730b8e522b0..110db94cdf3c 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2051,7 +2051,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 	sp = (unsigned long) stack;
 	if (sp == 0) {
 		if (tsk == current)
-			sp = current_stack_pointer();
+			sp = current_stack_frame();
 		else
 			sp = tsk->thread.ksp;
 	}
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index e2a46cfed5fd..c477b8585a29 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -57,7 +57,7 @@ void save_stack_trace(struct stack_trace *trace)
 {
 	unsigned long sp;
 
-	sp = current_stack_pointer();
+	sp = current_stack_frame();
 
 	save_context_stack(trace, sp, current, 1);
 }
@@ -71,7 +71,7 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
 		return;
 
 	if (tsk == current)
-		sp = current_stack_pointer();
+		sp = current_stack_frame();
 	else
 		sp = tsk->thread.ksp;
 
@@ -131,7 +131,7 @@ static int __save_stack_trace_tsk_reliable(struct task_struct *tsk,
 	}
 
 	if (tsk == current)
-		sp = current_stack_pointer();
+		sp = current_stack_frame();
 	else
 		sp = tsk->thread.ksp;
 
-- 
2.21.1


^ permalink raw reply related

* Re: [PATCH v3,1/8] arm64: dts: mt8183: add thermal zone node
From: Daniel Lezcano @ 2020-02-20 11:52 UTC (permalink / raw)
  To: Michael Kao
  Cc: Mark Rutland, devicetree, srv_heupstream, linux-pm, linux-kernel,
	Eduardo Valentin, Rob Herring, linux-mediatek, hsinyi,
	Matthias Brugger, Zhang Rui, linux-arm-kernel
In-Reply-To: <1581391046.31005.12.camel@mtksdccf07>

On 11/02/2020 04:17, Michael Kao wrote:
> On Thu, 2020-01-09 at 12:31 +0100, Daniel Lezcano wrote:
>> On 03/01/2020 07:44, Michael Kao wrote:
>>> From: "michael.kao" <michael.kao@mediatek.com>
>>>
>>> Add thermal zone node to Mediatek MT8183 dts file.
>>>
>>> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
>>> ---
>>>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 85 ++++++++++++++++++++++++
>>>  1 file changed, 85 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> index 10b32471bc7b..a2793cf3d994 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> @@ -570,6 +570,88 @@
>>>  			status = "disabled";
>>>  		};
>>>  
>>> +		thermal: thermal@1100b000 {
>>> +			#thermal-sensor-cells = <1>;
>>> +			compatible = "mediatek,mt8183-thermal";
>>> +			reg = <0 0x1100b000 0 0x1000>;
>>> +			interrupts = <0 76 IRQ_TYPE_LEVEL_LOW>;
>>
>> What is this interrupt for?
> 
> The interrupts pin is designed in our SoC. But it is not used in our
> upstream thermal code now. There is also add the settings but not use
> for mt8173.dtsi. To align the thermal dtsi format, I follow the past
> experience to add the interrupt settings of this project first.

Assuming the interrupt can be set by the driver to fire when a specified
temperature is set, I suggest to change your driver to handle it so you
can get rid of the polling waking up the SoC every second.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply

* Re: [PATCH v3,1/8] arm64: dts: mt8183: add thermal zone node
From: Daniel Lezcano @ 2020-02-20 11:52 UTC (permalink / raw)
  To: Michael Kao
  Cc: Mark Rutland, devicetree, srv_heupstream, linux-pm, linux-kernel,
	Eduardo Valentin, Rob Herring, linux-mediatek, hsinyi,
	Matthias Brugger, Zhang Rui, linux-arm-kernel
In-Reply-To: <1581391046.31005.12.camel@mtksdccf07>

On 11/02/2020 04:17, Michael Kao wrote:
> On Thu, 2020-01-09 at 12:31 +0100, Daniel Lezcano wrote:
>> On 03/01/2020 07:44, Michael Kao wrote:
>>> From: "michael.kao" <michael.kao@mediatek.com>
>>>
>>> Add thermal zone node to Mediatek MT8183 dts file.
>>>
>>> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
>>> ---
>>>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 85 ++++++++++++++++++++++++
>>>  1 file changed, 85 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> index 10b32471bc7b..a2793cf3d994 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> @@ -570,6 +570,88 @@
>>>  			status = "disabled";
>>>  		};
>>>  
>>> +		thermal: thermal@1100b000 {
>>> +			#thermal-sensor-cells = <1>;
>>> +			compatible = "mediatek,mt8183-thermal";
>>> +			reg = <0 0x1100b000 0 0x1000>;
>>> +			interrupts = <0 76 IRQ_TYPE_LEVEL_LOW>;
>>
>> What is this interrupt for?
> 
> The interrupts pin is designed in our SoC. But it is not used in our
> upstream thermal code now. There is also add the settings but not use
> for mt8173.dtsi. To align the thermal dtsi format, I follow the past
> experience to add the interrupt settings of this project first.

Assuming the interrupt can be set by the driver to fire when a specified
temperature is set, I suggest to change your driver to handle it so you
can get rid of the polling waking up the SoC every second.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v3,1/8] arm64: dts: mt8183: add thermal zone node
From: Daniel Lezcano @ 2020-02-20 11:52 UTC (permalink / raw)
  To: Michael Kao
  Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
	Matthias Brugger, hsinyi, linux-pm, srv_heupstream, devicetree,
	linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <1581391046.31005.12.camel@mtksdccf07>

On 11/02/2020 04:17, Michael Kao wrote:
> On Thu, 2020-01-09 at 12:31 +0100, Daniel Lezcano wrote:
>> On 03/01/2020 07:44, Michael Kao wrote:
>>> From: "michael.kao" <michael.kao@mediatek.com>
>>>
>>> Add thermal zone node to Mediatek MT8183 dts file.
>>>
>>> Signed-off-by: Michael Kao <michael.kao@mediatek.com>
>>> ---
>>>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 85 ++++++++++++++++++++++++
>>>  1 file changed, 85 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> index 10b32471bc7b..a2793cf3d994 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> @@ -570,6 +570,88 @@
>>>  			status = "disabled";
>>>  		};
>>>  
>>> +		thermal: thermal@1100b000 {
>>> +			#thermal-sensor-cells = <1>;
>>> +			compatible = "mediatek,mt8183-thermal";
>>> +			reg = <0 0x1100b000 0 0x1000>;
>>> +			interrupts = <0 76 IRQ_TYPE_LEVEL_LOW>;
>>
>> What is this interrupt for?
> 
> The interrupts pin is designed in our SoC. But it is not used in our
> upstream thermal code now. There is also add the settings but not use
> for mt8173.dtsi. To align the thermal dtsi format, I follow the past
> experience to add the interrupt settings of this project first.

Assuming the interrupt can be set by the driver to fire when a specified
temperature is set, I suggest to change your driver to handle it so you
can get rid of the polling waking up the SoC every second.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


^ permalink raw reply

* Re: [dpdk-dev] [PATCH] crypto/nitrox: fix coverity defects
From: Thomas Monjalon @ 2020-02-20 11:51 UTC (permalink / raw)
  To: Nagadheeraj Rottela, Akhil Goyal; +Cc: dev, jsrikanth@marvell.com
In-Reply-To: <VE1PR04MB66394AC008E0F17DB28A8FB1E6130@VE1PR04MB6639.eurprd04.prod.outlook.com>

20/02/2020 12:07, Akhil Goyal:
> > 
> > Address the defects reported by coverity: Unintended sign extension
> > and Out-of-bounds access.
> > 
> > Coverity issue: 349899, 349905, 349911, 349921, 349923, 349926
> > 
> > Fixes: 32e4930d5a3b ("crypto/nitrox: add hardware queue management")
> > Fixes: 9fdef0cc2385 ("crypto/nitrox: create symmetric cryptodev")
> > 
> > Signed-off-by: Nagadheeraj Rottela <rnagadheeraj@marvell.com>
> > ---
> Thomas,
> 
> Can you take this directly on master.

No sorry, I can't because there is no review and test.

And I think we should not have general patches for Coverity defects.
Instead we must do one patch per issue. Here two:
	- sign of constants
	- out-of-bound access
In each patch, we must have a description of the consequence of the issue.

Thanks



^ permalink raw reply

* [PATCH V2] arm64: dts: ipq6018: Add a few device nodes
From: Sivaprakash Murugesan @ 2020-02-20 11:50 UTC (permalink / raw)
  To: agross, bjorn.andersson, robh+dt, mark.rutland, linux-arm-msm,
	devicetree, linux-kernel
  Cc: sivaprak

add i2c, spi, crypto, rng, watchdog, peripheral nodes, also add
support for wcss Q6 remoteproc driver and enable hw mutex, smem,
mailbox, smp2p and rpmsg drivers

Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org>
---
[V2] * Addressed review comments from Stephen
This patch depends on Sricharan's ipq6018 dts patch
https://patchwork.kernel.org/patch/11340681/
 arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts |  34 ++++
 arch/arm64/boot/dts/qcom/ipq6018.dtsi        | 226 +++++++++++++++++++++++++++
 2 files changed, 260 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
index 897b4b2..b31117a 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
+++ b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
@@ -28,3 +28,37 @@
 	pinctrl-names = "default";
 	status = "ok";
 };
+
+&i2c_1 {
+	pinctrl-0 = <&i2c_1_pins>;
+	pinctrl-names = "default";
+	status = "ok";
+};
+
+&spi_0 {
+	cs-select = <0>;
+	status = "ok";
+
+	m25p80@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0>;
+		compatible = "n25q128a11";
+		spi-max-frequency = <50000000>;
+	};
+};
+
+&tlmm {
+	i2c_1_pins: i2c-1-pins {
+		pins = "gpio42", "gpio43";
+		function = "blsp2_i2c";
+		drive-strength = <8>;
+	};
+
+	spi_0_pins: spi-0-pins {
+		pins = "gpio38", "gpio39", "gpio40", "gpio41";
+		function = "blsp0_spi";
+		drive-strength = <8>;
+		bias-pull-down;
+	};
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 0fb44e5..1aa8d85 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -7,6 +7,7 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-ipq6018.h>
+#include <dt-bindings/reset/qcom,gcc-ipq6018.h>
 
 / {
 	#address-cells = <2>;
@@ -69,6 +70,18 @@
 		};
 	};
 
+	firmware {
+		scm {
+			compatible = "qcom,scm";
+		};
+	};
+
+	tcsr_mutex: hwlock {
+		compatible = "qcom,tcsr-mutex";
+		syscon = <&tcsr_mutex_regs 0 0x80>;
+		#hwlock-cells = <1>;
+	};
+
 	pmuv8: pmu {
 		compatible = "arm,cortex-a53-pmu";
 		interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4) |
@@ -89,6 +102,22 @@
 			reg = <0x0 0x48500000 0x0 0x00200000>;
 			no-map;
 		};
+
+		smem_region: memory@4aa00000 {
+			reg = <0x0 0x4aa00000 0x0 0x00100000>;
+			no-map;
+		};
+
+		q6_region: memory@4ab00000 {
+			reg = <0x0 0x4ab00000 0x0 0x02800000>;
+			no-map;
+		};
+	};
+
+	smem {
+		compatible = "qcom,smem";
+		memory-region = <&smem_region>;
+		hwlocks = <&tcsr_mutex 0>;
 	};
 
 	soc: soc {
@@ -98,6 +127,36 @@
 		dma-ranges;
 		compatible = "simple-bus";
 
+		prng: qrng@e1000 {
+			compatible = "qcom,prng-ee";
+			reg = <0xe3000 0x1000>;
+			clocks = <&gcc GCC_PRNG_AHB_CLK>;
+			clock-names = "core";
+		};
+
+		cryptobam: dma@704000 {
+			compatible = "qcom,bam-v1.7.0";
+			reg = <0x00704000 0x20000>;
+			interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gcc GCC_CRYPTO_AHB_CLK>;
+			clock-names = "bam_clk";
+			#dma-cells = <1>;
+			qcom,ee = <1>;
+			qcom,controlled-remotely = <1>;
+			qcom,config-pipe-trust-reg = <0>;
+		};
+
+		crypto: crypto@73a000 {
+			compatible = "qcom,crypto-v5.1";
+			reg = <0x0073a000 0x6000>;
+			clocks = <&gcc GCC_CRYPTO_AHB_CLK>,
+				<&gcc GCC_CRYPTO_AXI_CLK>,
+				<&gcc GCC_CRYPTO_CLK>;
+			clock-names = "iface", "bus", "core";
+			dmas = <&cryptobam 2>, <&cryptobam 3>;
+			dma-names = "rx", "tx";
+		};
+
 		tlmm: pinctrl@1000000 {
 			compatible = "qcom,ipq6018-pinctrl";
 			reg = <0x01000000 0x300000>;
@@ -125,6 +184,26 @@
 			#reset-cells = <1>;
 		};
 
+		tcsr_mutex_regs: syscon@1905000 {
+			compatible = "syscon";
+			reg = <0x01905000 0x8000>;
+		};
+
+		tcsr_q6: syscon@1945000 {
+			compatible = "syscon";
+			reg = <0x01945000 0xe000>;
+		};
+
+		blsp_dma: dma@7884000 {
+			compatible = "qcom,bam-v1.7.0";
+			reg = <0x07884000 0x2b000>;
+			interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gcc GCC_BLSP1_AHB_CLK>;
+			clock-names = "bam_clk";
+			#dma-cells = <1>;
+			qcom,ee = <0>;
+		};
+
 		blsp1_uart3: serial@78b1000 {
 			compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
 			reg = <0x078b1000 0x200>;
@@ -135,6 +214,66 @@
 			status = "disabled";
 		};
 
+		spi_0: spi@78b5000 {
+			compatible = "qcom,spi-qup-v2.2.1";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x078b5000 0x600>;
+			interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+			spi-max-frequency = <50000000>;
+			clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>,
+				<&gcc GCC_BLSP1_AHB_CLK>;
+			clock-names = "core", "iface";
+			dmas = <&blsp_dma 12>, <&blsp_dma 13>;
+			dma-names = "tx", "rx";
+			status = "disabled";
+		};
+
+		spi_1: spi@78b6000 {
+			compatible = "qcom,spi-qup-v2.2.1";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x078b6000 0x600>;
+			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+			spi-max-frequency = <50000000>;
+			clocks = <&gcc GCC_BLSP1_QUP2_SPI_APPS_CLK>,
+				<&gcc GCC_BLSP1_AHB_CLK>;
+			clock-names = "core", "iface";
+			dmas = <&blsp_dma 14>, <&blsp_dma 15>;
+			dma-names = "tx", "rx";
+			status = "disabled";
+		};
+
+		i2c_0: i2c@78b6000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x078b6000 0x600>;
+			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+				<&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+			clock-names = "iface", "core";
+			clock-frequency  = <400000>;
+			dmas = <&blsp_dma 15>, <&blsp_dma 14>;
+			dma-names = "rx", "tx";
+			status = "disabled";
+		};
+
+		i2c_1: i2c@78b7000 { /* BLSP1 QUP2 */
+			compatible = "qcom,i2c-qup-v2.2.1";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x078b7000 0x600>;
+			interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+				<&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
+			clock-names = "iface", "core";
+			clock-frequency  = <400000>;
+			dmas = <&blsp_dma 17>, <&blsp_dma 16>;
+			dma-names = "rx", "tx";
+			status = "disabled";
+		};
+
 		intc: interrupt-controller@b000000 {
 			compatible = "qcom,msm-qgic2";
 			interrupt-controller;
@@ -146,6 +285,21 @@
 			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		watchdog@b017000 {
+			compatible = "qcom,kpss-wdt";
+			interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+			reg = <0x0b017000 0x40>;
+			clocks = <&sleep_clk>;
+			timeout-sec = <10>;
+		};
+
+		apcs_glb: mailbox@b111000 {
+			compatible = "qcom,ipq8074-apcs-apps-global";
+			reg = <0x0b111000 0xc>;
+
+			#mbox-cells = <1>;
+		};
+
 		timer {
 			compatible = "arm,armv8-timer";
 			interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
@@ -213,5 +367,77 @@
 			};
 		};
 
+		q6v5_wcss: remoteproc@cd00000 {
+			compatible = "qcom,ipq8074-wcss-pil";
+			reg = <0x0cd00000 0x4040>,
+				<0x004ab000 0x20>;
+			reg-names = "qdsp6",
+				    "rmb";
+			interrupts-extended = <&intc GIC_SPI 325 IRQ_TYPE_EDGE_RISING>,
+					      <&wcss_smp2p_in 0 0>,
+					      <&wcss_smp2p_in 1 0>,
+					      <&wcss_smp2p_in 2 0>,
+					      <&wcss_smp2p_in 3 0>;
+			interrupt-names = "wdog",
+					  "fatal",
+					  "ready",
+					  "handover",
+					  "stop-ack";
+
+			resets = <&gcc GCC_WCSSAON_RESET>,
+				 <&gcc GCC_WCSS_BCR>,
+				 <&gcc GCC_WCSS_Q6_BCR>;
+
+			reset-names = "wcss_aon_reset",
+				      "wcss_reset",
+				      "wcss_q6_reset";
+
+			clocks = <&gcc GCC_PRNG_AHB_CLK>;
+			clock-names = "prng";
+
+			qcom,halt-regs = <&tcsr_q6 0xa000 0xd000 0x0>;
+
+			qcom,smem-states = <&wcss_smp2p_out 0>,
+					   <&wcss_smp2p_out 1>;
+			qcom,smem-state-names = "shutdown",
+						"stop";
+
+			memory-region = <&q6_region>;
+
+			glink-edge {
+				interrupts = <GIC_SPI 321 IRQ_TYPE_EDGE_RISING>;
+				qcom,remote-pid = <1>;
+				mboxes = <&apcs_glb 8>;
+
+				qrtr_requests {
+					qcom,glink-channels = "IPCRTR";
+				};
+			};
+		};
+
+	};
+
+	wcss: wcss-smp2p {
+		compatible = "qcom,smp2p";
+		qcom,smem = <435>, <428>;
+
+		interrupt-parent = <&intc>;
+		interrupts = <GIC_SPI 322 IRQ_TYPE_EDGE_RISING>;
+
+		mboxes = <&apcs_glb 9>;
+
+		qcom,local-pid = <0>;
+		qcom,remote-pid = <1>;
+
+		wcss_smp2p_out: master-kernel {
+			qcom,entry-name = "master-kernel";
+			#qcom,smem-state-cells = <1>;
+		};
+
+		wcss_smp2p_in: slave-kernel {
+			qcom,entry-name = "slave-kernel";
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
 	};
 };
-- 
2.7.4


^ permalink raw reply related

* RE: Race condition in overlayed qcow2?
From: Pavel Dovgalyuk @ 2020-02-20 11:48 UTC (permalink / raw)
  To: 'Vladimir Sementsov-Ogievskiy'; +Cc: kwolf, qemu-devel, mreitz
In-Reply-To: <ea13d572-4840-3e88-bc7f-d7c4351cc345@virtuozzo.com>

> From: Vladimir Sementsov-Ogievskiy [mailto:vsementsov@virtuozzo.com]
> 20.02.2020 13:00, Pavel Dovgalyuk wrote:
> >> From: Vladimir Sementsov-Ogievskiy [mailto:vsementsov@virtuozzo.com]
> >> 20.02.2020 11:31, dovgaluk wrote:
> >>> Vladimir Sementsov-Ogievskiy писал 2020-02-19 19:07:
> >>>> 19.02.2020 17:32, dovgaluk wrote:
> >>>>> I encountered a problem with record/replay of QEMU execution and figured out the
> >> following, when
> >>>>> QEMU is started with one virtual disk connected to the qcow2 image with applied
> 'snapshot'
> >> option.
> >>>>>
> >>>>> The patch d710cf575ad5fb3ab329204620de45bfe50caa53 "block/qcow2: introduce parallel
> >> subrequest handling in read and write"
> >>>>> introduces some kind of race condition, which causes difference in the data read from
> the
> >> disk.
> >>>>>
> >>>>> I detected this by adding the following code, which logs IO operation checksum. And this
> >> checksum may be different in different runs of the same recorded execution.
> >>>>>
> >>>>> logging in blk_aio_complete function:
> >>>>>           qemu_log("%"PRId64": blk_aio_complete\n", replay_get_current_icount());
> >>>>>           QEMUIOVector *qiov = acb->rwco.iobuf;
> >>>>>           if (qiov && qiov->iov) {
> >>>>>               size_t i, j;
> >>>>>               uint64_t sum = 0;
> >>>>>               int count = 0;
> >>>>>               for (i = 0 ; i < qiov->niov ; ++i) {
> >>>>>                   for (j = 0 ; j < qiov->iov[i].iov_len ; ++j) {
> >>>>>                       sum += ((uint8_t*)qiov->iov[i].iov_base)[j];
> >>>>>                       ++count;
> >>>>>                   }
> >>>>>               }
> >>>>>               qemu_log("--- iobuf offset %"PRIx64" len %x sum: %"PRIx64"\n", acb-
> >>> rwco.offset, count, sum);
> >>>>>           }
> >>>>>
> >>>>> I tried to get rid of aio task by patching qcow2_co_preadv_part:
> >>>>> ret = qcow2_co_preadv_task(bs, ret, cluster_offset, offset, cur_bytes, qiov,
> qiov_offset);
> >>>>>
> >>>>> That change fixed a bug, but I have no idea what to debug next to figure out the exact
> >> reason of the failure.
> >>>>>
> >>>>> Do you have any ideas or hints?
> >>>>>
> >>>>
> >>>> Hi!
> >>>>
> >>>> Hmm, do mean that read from the disk may return wrong data? It would
> >>>> be very bad of course :(
> >>>> Could you provide a reproducer, so that I can look at it and debug?
> >>>
> >>> It is just a winxp-32 image. I record the execution and replay it with the following
> command
> >> lines:
> >>>
> >>> qemu-system-i386 -icount shift=7,rr=record,rrfile=replay.bin -m 512M -drive
> >> file=xp.qcow2,if=none,id=device-34-file,snapshot -drive
> driver=blkreplay,if=none,image=device-
> >> 34-file,id=device-34-driver -device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -
> net
> >> none
> >>>
> >>> qemu-system-i386 -icount shift=7,rr=replay,rrfile=replay.bin -m 512M -drive
> >> file=xp.qcow2,if=none,id=device-34-file,snapshot -drive
> driver=blkreplay,if=none,image=device-
> >> 34-file,id=device-34-driver -device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -
> net
> >> none
> >>>
> >>> Replay stalls at some moment due to the non-determinism of the execution (probably caused
> by
> >> the wrong data read).
> >>
> >> Hmm.. I tried it  (with x86_64 qemu and centos image). I waited for some time for a first
> >> command, than Ctrl+C it. After it replay.bin was 4M. Than started the second command. It
> >> works, not failing, not finishing. Is it bad? What is expected behavior and what is wrong?
> >
> > The second command should finish. There is no replay introspection yet (in master), but you
> can
> > stop qemu with gdb and inspect replay_state.current_icount field. It should increase with
> every
> > virtual CPU instruction execution. If that counter has stopped, it means that replay hangs.
> 
> It hangs for me even with QCOW2_MAX_WORKERS = 1..


There could be some other bugs in record/replay.
To be sure try winxp on i386.

Pavel Dovgalyuk



^ permalink raw reply

* Re: [Xen-devel] [PATCH 5/5] libxl/PCI: align reserved device memory boundary for HAP guests
From: Wei Liu @ 2020-02-20 11:48 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
	Wei Liu
In-Reply-To: <3d9584c2-9c7f-f3e5-283c-c80bb9bebd73@suse.com>

On Thu, Feb 20, 2020 at 12:45:54PM +0100, Jan Beulich wrote:
> On 20.02.2020 12:43, Wei Liu wrote:
> > On Tue, Feb 18, 2020 at 04:47:49PM +0100, Jan Beulich wrote:
> >> As the code comment says, this will allow use of a 2Mb super page
> >> mapping at the end of "low" memory.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>
> >> --- a/tools/libxl/libxl_dm.c
> >> +++ b/tools/libxl/libxl_dm.c
> >> @@ -563,6 +563,13 @@ int libxl__domain_device_construct_rdm(l
> >>          /* Just check if RDM > our memory boundary. */
> >>          if (rdm_start > rdm_mem_boundary) {
> >>              /*
> >> +             * For HAP guests round down to a 2Mb boundary to allow use
> >> +             * of large page mappings.
> >> +             */
> >> +            if (libxl_defbool_val(d_config->c_info.hap)
> >> +                && rdm_start > 0x200000)
> > 
> > Please use MB(2) here.
> 
> Will do, but then what about the ~0x1fffff on the next line? Should
> this become ~(MB(2) - 1)?

Yes that would be good too.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply

* [PATCH] cmd: Add unlz4 command
From: Yusuke Ashiduka @ 2020-02-20 11:48 UTC (permalink / raw)
  To: u-boot

This command is a new command called "unlz4" that decompresses from memory
into memory.
Used with the CONFIG_CMD_UNLZ4 optionenabled.

Signed-off-by: Yusuke Ashiduka <ashiduka@fujitsu.com>
---
 cmd/Kconfig  |  7 +++++++
 cmd/Makefile |  1 +
 cmd/unlz4.c  | 45 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 53 insertions(+)
 create mode 100644 cmd/unlz4.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6403bc45a5..3607edd2d2 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -769,6 +769,13 @@ config CMD_LZMADEC
 	  Support decompressing an LZMA (Lempel-Ziv-Markov chain algorithm)
 	  image from memory.
 
+config CMD_UNLZ4
+	bool "unlz4"
+	default y if CMD_BOOTI
+	select LZ4
+	help
+	  Support decompressing an LZ4 image from memory region.
+
 config CMD_UNZIP
 	bool "unzip"
 	default y if CMD_BOOTI
diff --git a/cmd/Makefile b/cmd/Makefile
index f1dd513a4b..6692ed96c6 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -144,6 +144,7 @@ obj-$(CONFIG_CMD_TSI148) += tsi148.o
 obj-$(CONFIG_CMD_UBI) += ubi.o
 obj-$(CONFIG_CMD_UBIFS) += ubifs.o
 obj-$(CONFIG_CMD_UNIVERSE) += universe.o
+obj-$(CONFIG_CMD_UNLZ4) += unlz4.o
 obj-$(CONFIG_CMD_UNZIP) += unzip.o
 obj-$(CONFIG_CMD_VIRTIO) += virtio.o
 obj-$(CONFIG_CMD_WDT) += wdt.o
diff --git a/cmd/unlz4.c b/cmd/unlz4.c
new file mode 100644
index 0000000000..4d3af53fea
--- /dev/null
+++ b/cmd/unlz4.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020
+ * FUJITSU COMPUTERTECHNOLOGIES LIMITED. All rights reserved.
+ */
+
+#include <common.h>
+#include <command.h>
+#include <env.h>
+#include <lz4.h>
+
+static int do_unlz4(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+	unsigned long src, dst;
+	size_t src_len = ~0UL, dst_len = ~0UL;
+	int ret;
+
+	switch (argc) {
+	case 4:
+		src = simple_strtoul(argv[1], NULL, 16);
+		dst = simple_strtoul(argv[2], NULL, 16);
+		dst_len = simple_strtoul(argv[3], NULL, 16);
+		break;
+	default:
+		return CMD_RET_USAGE;
+	}
+
+	ret = ulz4fn((void *)src, src_len, (void *)dst, &dst_len);
+	if (ret) {
+		printf("Uncompressed err :%d\n", ret);
+		return 1;
+	}
+
+	printf("Uncompressed size: %ld = 0x%lX\n", dst_len, dst_len);
+	env_set_hex("filesize", dst_len);
+
+	return 0;
+}
+
+U_BOOT_CMD(unlz4, 4, 1, do_unlz4,
+	   "lz4 uncompress a memory region",
+	   "srcaddr dstaddr dstsize\n"
+	   "NOTE: Specify the destination size that is sufficiently larger\n"
+	   " than the source size.\n"
+);
-- 
2.17.1

^ permalink raw reply related

* Re: [PATCH v2 1/8] x86/fpu/xstate: Define new macros for supervisor and user xstates
From: Borislav Petkov @ 2020-02-20 11:47 UTC (permalink / raw)
  To: Yu-cheng Yu
  Cc: linux-kernel, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	Dave Hansen, Tony Luck, Andy Lutomirski, Rik van Riel,
	Ravi V. Shankar, Sebastian Andrzej Siewior, Fenghua Yu,
	Peter Zijlstra
In-Reply-To: <20200121201843.12047-2-yu-cheng.yu@intel.com>

On Tue, Jan 21, 2020 at 12:18:36PM -0800, Yu-cheng Yu wrote:
> From: Fenghua Yu <fenghua.yu@intel.com>
> 
> XCNTXT_MASK is 'all supported xfeatures' before introducing supervisor
> xstates.  Rename it to SUPPORTED_XFEATURES_MASK_USER to make clear that
> these are user xstates.
> 
> XFEATURE_MASK_SUPERVISOR is replaced with the following:
> - SUPPORTED_XFEATURES_MASK_SUPERVISOR: Currently nothing.  ENQCMD and
>   Control-flow Enforcement Technology (CET) will be introduced in separate
>   series.
> - UNSUPPORTED_XFEATURES_MASK_SUPERVISOR: Currently only Processor Trace.
> - ALL_XFEATURES_MASK_SUPERVISOR: the combination of above.
> 
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> ---
>  arch/x86/include/asm/fpu/xstate.h | 36 ++++++++++++++++++++-----------
>  arch/x86/kernel/fpu/init.c        |  3 ++-
>  arch/x86/kernel/fpu/xstate.c      | 26 +++++++++++-----------
>  3 files changed, 38 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/x86/include/asm/fpu/xstate.h b/arch/x86/include/asm/fpu/xstate.h
> index c6136d79f8c0..014c386deaa3 100644
> --- a/arch/x86/include/asm/fpu/xstate.h
> +++ b/arch/x86/include/asm/fpu/xstate.h
> @@ -21,19 +21,29 @@
>  #define XSAVE_YMM_SIZE	    256
>  #define XSAVE_YMM_OFFSET    (XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET)
>  
> -/* Supervisor features */
> -#define XFEATURE_MASK_SUPERVISOR (XFEATURE_MASK_PT)
> -
> -/* All currently supported features */
> -#define XCNTXT_MASK		(XFEATURE_MASK_FP | \
> -				 XFEATURE_MASK_SSE | \
> -				 XFEATURE_MASK_YMM | \
> -				 XFEATURE_MASK_OPMASK | \
> -				 XFEATURE_MASK_ZMM_Hi256 | \
> -				 XFEATURE_MASK_Hi16_ZMM	 | \
> -				 XFEATURE_MASK_PKRU | \
> -				 XFEATURE_MASK_BNDREGS | \
> -				 XFEATURE_MASK_BNDCSR)
> +/* All currently supported user features */
> +#define SUPPORTED_XFEATURES_MASK_USER (XFEATURE_MASK_FP | \
> +				       XFEATURE_MASK_SSE | \
> +				       XFEATURE_MASK_YMM | \
> +				       XFEATURE_MASK_OPMASK | \
> +				       XFEATURE_MASK_ZMM_Hi256 | \
> +				       XFEATURE_MASK_Hi16_ZMM	 | \
> +				       XFEATURE_MASK_PKRU | \
> +				       XFEATURE_MASK_BNDREGS | \
> +				       XFEATURE_MASK_BNDCSR)
> +
> +/* All currently supported supervisor features */
> +#define SUPPORTED_XFEATURES_MASK_SUPERVISOR (0)
> +
> +/*
> + * Unsupported supervisor features. When a supervisor feature in this mask is
> + * supported in the future, move it to the supported supervisor feature mask.
> + */
> +#define UNSUPPORTED_XFEATURES_MASK_SUPERVISOR (XFEATURE_MASK_PT)
> +
> +/* All supervisor states including supported and unsupported states. */
> +#define ALL_XFEATURES_MASK_SUPERVISOR (SUPPORTED_XFEATURES_MASK_SUPERVISOR | \
> +				       UNSUPPORTED_XFEATURES_MASK_SUPERVISOR)

So frankly having the namespace prepended in those macros makes it more
readable to me: you know that those masks all belong together if you had
this:

XFEATURE_MASK_SUPERVISOR
XFEATURE_MASK_SUPERVISOR_SUPPORTED
XFEATURE_MASK_SUPERVISOR_UNSUPPORTED
XFEATURE_MASK_SUPERVISOR_ALL
XFEATURE_MASK_USER_SUPPORTED

Now they all begin with different words: "ALL", "UNSUPPORTED",
"SUPPORTED", ... and makes you go and look up the mask to make sure it
is the correct type of mask used.

Even more so if the single feature masks also start with
"XFEATURE_MASK_" so it is only logical to have them all start with
XFEATURE_MASK_ IMO.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply

* [Virtio-fs] [PATCH v3 2/2] virtiofs: Fix xattr operations
From: Misono Tomohiro @ 2020-02-20 11:47 UTC (permalink / raw)
  To: virtio-fs; +Cc: vgoyal
In-Reply-To: <20200220114704.11592-1-misono.tomohiro@jp.fujitsu.com>

Current virtiofsd has problems about xattr operations and
they does not work properly for directory/symlink/special file.

The fundamental cause is that virtiofsd uses openat() + f...xattr()
systemcalls for xattr operation but we should not open symlink/special
file in the daemon. Therefore the function is restricted.

Fix this problem by:
 1. during setup of each thread, call unshare(CLONE_FS)
 2. in xattr operations (i.e. lo_getxattr), if inode is not a regular
    file or directory, use fchdir(proc_loot_fd) + ...xattr() +
    fchdir(root.fd) instead of openat() + f...xattr()

    (Note: for a regular file/directory openat() + f...xattr()
     is still used for performance reason)

With this patch, xfstests generic/062 passes on virtiofs.
This fix is suggested by Miklos Szeredi and Stefan Hajnoczi.

Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
---
 tools/virtiofsd/fuse_virtio.c    | 13 +++++
 tools/virtiofsd/passthrough_ll.c | 99 +++++++++++++++++---------------
 tools/virtiofsd/seccomp.c        |  6 ++
 3 files changed, 71 insertions(+), 47 deletions(-)

diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
index 655b9a1413..21c5d76d58 100644
--- a/tools/virtiofsd/fuse_virtio.c
+++ b/tools/virtiofsd/fuse_virtio.c
@@ -463,6 +463,8 @@ err:
     return ret;
 }
 
+static __thread bool clone_fs_called;
+
 /* Process one FVRequest in a thread pool */
 static void fv_queue_worker(gpointer data, gpointer user_data)
 {
@@ -478,6 +480,17 @@ static void fv_queue_worker(gpointer data, gpointer user_data)
 
     assert(se->bufsize > sizeof(struct fuse_in_header));
 
+    if (!clone_fs_called) {
+        int ret;
+
+        /* unshare FS for xattr operation */
+        ret = unshare(CLONE_FS);
+        /* should not fail */
+        assert(ret == 0);
+
+        clone_fs_called = true;
+    }
+
     /*
      * An element contains one request and the space to send our response
      * They're spread over multiple descriptors in a scatter/gather set
diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 33cff8c2c8..7d648af916 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -130,7 +130,7 @@ struct lo_inode {
     pthread_mutex_t plock_mutex;
     GHashTable *posix_locks; /* protected by lo_inode->plock_mutex */
 
-    bool is_symlink;
+    mode_t filetype;
 };
 
 struct lo_cred {
@@ -734,7 +734,7 @@ static int utimensat_empty(struct lo_data *lo, struct lo_inode *inode,
     struct lo_inode *parent;
     char path[PATH_MAX];
 
-    if (inode->is_symlink) {
+    if (S_ISLNK(inode->filetype)) {
         res = utimensat(inode->fd, "", tv, AT_EMPTY_PATH);
         if (res == -1 && errno == EINVAL) {
             /* Sorry, no race free way to set times on symlink. */
@@ -1037,7 +1037,8 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t parent, const char *name,
             goto out_err;
         }
 
-        inode->is_symlink = S_ISLNK(e->attr.st_mode);
+        /* cache only filetype */
+        inode->filetype = (e->attr.st_mode & S_IFMT);
 
         /*
          * One for the caller and one for nlookup (released in
@@ -1264,7 +1265,7 @@ static int linkat_empty_nofollow(struct lo_data *lo, struct lo_inode *inode,
     struct lo_inode *parent;
     char path[PATH_MAX];
 
-    if (inode->is_symlink) {
+    if (S_ISLNK(inode->filetype)) {
         res = linkat(inode->fd, "", dfd, name, AT_EMPTY_PATH);
         if (res == -1 && (errno == ENOENT || errno == EINVAL)) {
             /* Sorry, no race free way to hard-link a symlink. */
@@ -2378,12 +2379,6 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
     fuse_log(FUSE_LOG_DEBUG, "lo_getxattr(ino=%" PRIu64 ", name=%s size=%zd)\n",
              ino, name, size);
 
-    if (inode->is_symlink) {
-        /* Sorry, no race free way to getxattr on symlink. */
-        saverr = EPERM;
-        goto out;
-    }
-
     if (size) {
         value = malloc(size);
         if (!value) {
@@ -2392,12 +2387,19 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
     }
 
     sprintf(procname, "%i", inode->fd);
-    fd = openat(lo->proc_self_fd, procname, O_RDONLY);
-    if (fd < 0) {
-        goto out_err;
+    if (S_ISREG(inode->filetype) || S_ISDIR(inode->filetype)) {
+        fd = openat(lo->proc_self_fd, procname, O_RDONLY);
+        if (fd < 0) {
+            goto out_err;
+        }
+        ret = fgetxattr(fd, name, value, size);
+    } else {
+        /* fchdir should not fail here */
+        assert(fchdir(lo->proc_self_fd) == 0);
+        ret = getxattr(procname, name, value, size);
+        assert(fchdir(lo->root.fd) == 0);
     }
 
-    ret = fgetxattr(fd, name, value, size);
     if (ret == -1) {
         goto out_err;
     }
@@ -2451,12 +2453,6 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
     fuse_log(FUSE_LOG_DEBUG, "lo_listxattr(ino=%" PRIu64 ", size=%zd)\n", ino,
              size);
 
-    if (inode->is_symlink) {
-        /* Sorry, no race free way to listxattr on symlink. */
-        saverr = EPERM;
-        goto out;
-    }
-
     if (size) {
         value = malloc(size);
         if (!value) {
@@ -2465,12 +2461,19 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
     }
 
     sprintf(procname, "%i", inode->fd);
-    fd = openat(lo->proc_self_fd, procname, O_RDONLY);
-    if (fd < 0) {
-        goto out_err;
+    if (S_ISREG(inode->filetype) || S_ISDIR(inode->filetype)) {
+        fd = openat(lo->proc_self_fd, procname, O_RDONLY);
+        if (fd < 0) {
+            goto out_err;
+        }
+        ret = flistxattr(fd, value, size);
+    } else {
+        /* fchdir should not fail here */
+        assert(fchdir(lo->proc_self_fd) == 0);
+        ret = listxattr(procname, value, size);
+        assert(fchdir(lo->root.fd) == 0);
     }
 
-    ret = flistxattr(fd, value, size);
     if (ret == -1) {
         goto out_err;
     }
@@ -2524,20 +2527,21 @@ static void lo_setxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
     fuse_log(FUSE_LOG_DEBUG, "lo_setxattr(ino=%" PRIu64
              ", name=%s value=%s size=%zd)\n", ino, name, value, size);
 
-    if (inode->is_symlink) {
-        /* Sorry, no race free way to setxattr on symlink. */
-        saverr = EPERM;
-        goto out;
-    }
-
     sprintf(procname, "%i", inode->fd);
-    fd = openat(lo->proc_self_fd, procname, O_RDWR);
-    if (fd < 0) {
-        saverr = errno;
-        goto out;
+    if (S_ISREG(inode->filetype) || S_ISDIR(inode->filetype)) {
+        fd = openat(lo->proc_self_fd, procname, O_RDONLY);
+        if (fd < 0) {
+            saverr = errno;
+            goto out;
+        }
+        ret = fsetxattr(fd, name, value, size, flags);
+    } else {
+        /* fchdir should not fail here */
+        assert(fchdir(lo->proc_self_fd) == 0);
+        ret = setxattr(procname, name, value, size, flags);
+        assert(fchdir(lo->root.fd) == 0);
     }
 
-    ret = fsetxattr(fd, name, value, size, flags);
     saverr = ret == -1 ? errno : 0;
 
     if (!saverr) {
@@ -2575,20 +2579,21 @@ static void lo_removexattr(fuse_req_t req, fuse_ino_t ino, const char *name)
     fuse_log(FUSE_LOG_DEBUG, "lo_removexattr(ino=%" PRIu64 ", name=%s)\n", ino,
              name);
 
-    if (inode->is_symlink) {
-        /* Sorry, no race free way to setxattr on symlink. */
-        saverr = EPERM;
-        goto out;
-    }
-
     sprintf(procname, "%i", inode->fd);
-    fd = openat(lo->proc_self_fd, procname, O_RDWR);
-    if (fd < 0) {
-        saverr = errno;
-        goto out;
+    if (S_ISREG(inode->filetype) || S_ISDIR(inode->filetype)) {
+        fd = openat(lo->proc_self_fd, procname, O_RDONLY);
+        if (fd < 0) {
+            saverr = errno;
+            goto out;
+        }
+        ret = fremovexattr(fd, name);
+    } else {
+        /* fchdir should not fail here */
+        assert(fchdir(lo->proc_self_fd) == 0);
+        ret = removexattr(procname, name);
+        assert(fchdir(lo->root.fd) == 0);
     }
 
-    ret = fremovexattr(fd, name);
     saverr = ret == -1 ? errno : 0;
 
     if (!saverr) {
@@ -3185,7 +3190,7 @@ static void setup_root(struct lo_data *lo, struct lo_inode *root)
         exit(1);
     }
 
-    root->is_symlink = false;
+    root->filetype = S_IFDIR;
     root->fd = fd;
     root->key.ino = stat.st_ino;
     root->key.dev = stat.st_dev;
diff --git a/tools/virtiofsd/seccomp.c b/tools/virtiofsd/seccomp.c
index 2d9d4a7ec0..bd9e7b083c 100644
--- a/tools/virtiofsd/seccomp.c
+++ b/tools/virtiofsd/seccomp.c
@@ -41,6 +41,7 @@ static const int syscall_whitelist[] = {
     SCMP_SYS(exit),
     SCMP_SYS(exit_group),
     SCMP_SYS(fallocate),
+    SCMP_SYS(fchdir),
     SCMP_SYS(fchmodat),
     SCMP_SYS(fchownat),
     SCMP_SYS(fcntl),
@@ -62,7 +63,9 @@ static const int syscall_whitelist[] = {
     SCMP_SYS(getpid),
     SCMP_SYS(gettid),
     SCMP_SYS(gettimeofday),
+    SCMP_SYS(getxattr),
     SCMP_SYS(linkat),
+    SCMP_SYS(listxattr),
     SCMP_SYS(lseek),
     SCMP_SYS(madvise),
     SCMP_SYS(mkdirat),
@@ -85,6 +88,7 @@ static const int syscall_whitelist[] = {
     SCMP_SYS(recvmsg),
     SCMP_SYS(renameat),
     SCMP_SYS(renameat2),
+    SCMP_SYS(removexattr),
     SCMP_SYS(rt_sigaction),
     SCMP_SYS(rt_sigprocmask),
     SCMP_SYS(rt_sigreturn),
@@ -98,10 +102,12 @@ static const int syscall_whitelist[] = {
     SCMP_SYS(setresuid32),
 #endif
     SCMP_SYS(set_robust_list),
+    SCMP_SYS(setxattr),
     SCMP_SYS(symlinkat),
     SCMP_SYS(time), /* Rarely needed, except on static builds */
     SCMP_SYS(tgkill),
     SCMP_SYS(unlinkat),
+    SCMP_SYS(unshare),
     SCMP_SYS(utimensat),
     SCMP_SYS(write),
     SCMP_SYS(writev),
-- 
2.21.1



^ permalink raw reply related

* [Virtio-fs] [PATCH v3 1/2] virtiofs: passthrough_ll: cleanup getxattr/listxattr
From: Misono Tomohiro @ 2020-02-20 11:47 UTC (permalink / raw)
  To: virtio-fs; +Cc: vgoyal
In-Reply-To: <20200220114704.11592-1-misono.tomohiro@jp.fujitsu.com>

This is a cleanup patch to simplify the following xattr fix and
there is no functional changes.

- Move memory allocation to head of the function
- Unify fgetxattr/flistxattr call for both size == 0 and
  size != 0 case
- Remove redundant lo_inode_put call in error path
  (Note: second call is ignored now since @inode is already NULL)

Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
---
 tools/virtiofsd/passthrough_ll.c | 62 ++++++++++++++------------------
 1 file changed, 26 insertions(+), 36 deletions(-)

diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 9772823066..33cff8c2c8 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -2370,8 +2370,8 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
         return;
     }
 
-    saverr = ENOSYS;
     if (!lo_data(req)->xattr) {
+        saverr = ENOSYS;
         goto out;
     }
 
@@ -2384,34 +2384,30 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
         goto out;
     }
 
+    if (size) {
+        value = malloc(size);
+        if (!value) {
+            goto out_err;
+        }
+    }
+
     sprintf(procname, "%i", inode->fd);
     fd = openat(lo->proc_self_fd, procname, O_RDONLY);
     if (fd < 0) {
         goto out_err;
     }
 
+    ret = fgetxattr(fd, name, value, size);
+    if (ret == -1) {
+        goto out_err;
+    }
     if (size) {
-        value = malloc(size);
-        if (!value) {
-            goto out_err;
-        }
-
-        ret = fgetxattr(fd, name, value, size);
-        if (ret == -1) {
-            goto out_err;
-        }
-        saverr = 0;
         if (ret == 0) {
+            saverr = 0;
             goto out;
         }
-
         fuse_reply_buf(req, value, ret);
     } else {
-        ret = fgetxattr(fd, name, NULL, 0);
-        if (ret == -1) {
-            goto out_err;
-        }
-
         fuse_reply_xattr(req, ret);
     }
 out_free:
@@ -2427,7 +2423,6 @@ out_free:
 out_err:
     saverr = errno;
 out:
-    lo_inode_put(lo, &inode);
     fuse_reply_err(req, saverr);
     goto out_free;
 }
@@ -2448,8 +2443,8 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
         return;
     }
 
-    saverr = ENOSYS;
     if (!lo_data(req)->xattr) {
+        saverr = ENOSYS;
         goto out;
     }
 
@@ -2462,34 +2457,30 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
         goto out;
     }
 
+    if (size) {
+        value = malloc(size);
+        if (!value) {
+            goto out_err;
+        }
+    }
+
     sprintf(procname, "%i", inode->fd);
     fd = openat(lo->proc_self_fd, procname, O_RDONLY);
     if (fd < 0) {
         goto out_err;
     }
 
+    ret = flistxattr(fd, value, size);
+    if (ret == -1) {
+        goto out_err;
+    }
     if (size) {
-        value = malloc(size);
-        if (!value) {
-            goto out_err;
-        }
-
-        ret = flistxattr(fd, value, size);
-        if (ret == -1) {
-            goto out_err;
-        }
-        saverr = 0;
         if (ret == 0) {
+            saverr = 0;
             goto out;
         }
-
         fuse_reply_buf(req, value, ret);
     } else {
-        ret = flistxattr(fd, NULL, 0);
-        if (ret == -1) {
-            goto out_err;
-        }
-
         fuse_reply_xattr(req, ret);
     }
 out_free:
@@ -2505,7 +2496,6 @@ out_free:
 out_err:
     saverr = errno;
 out:
-    lo_inode_put(lo, &inode);
     fuse_reply_err(req, saverr);
     goto out_free;
 }
-- 
2.21.1



^ permalink raw reply related

* [Virtio-fs] [PATCH v3 0/2] Fix xattr operation
From: Misono Tomohiro @ 2020-02-20 11:47 UTC (permalink / raw)
  To: virtio-fs; +Cc: vgoyal

This fixes the xattr operation for directory and special files
(which can be tested by xfstests generic/062 with -o xattr option).

The overall logic is switched back to the same as v1 in favor of performance
(i.e. keep original implementation for regular files/directories)
but I add a cleanup patch to improve readability as requested by Vivek.

Known issue is that if xattr enabled, seek sanity tests (generic/285,
436) will fail. However, I understand this is not a very serious bug
like data corruption so leave it for now.

One question; I remove error handling of fchdir() in v3 since
I believe fchdir to proc_self_fd/root.fd cannot fail in the situation
but should I add error handling?

change v2 -> v3:
 - rebased to current dev branch
 - add cleanup path (first one) to simplify main patch (second patch)
 - restore the logic of v1 in favor of performance
   (as a result seek sanity test failure is not fixed by this series) 
 - remove error handling of fchdir
 - drop ACL fix included in v2 for now to focus xattr
 
v2 patch: https://www.redhat.com/archives/virtio-fs/2020-January/msg00131.html

Thanks!

Misono Tomohiro (2):
  virtiofs: passthrough_ll: cleanup getxattr/listxattr
  virtiofs: Fix xattr operations

 tools/virtiofsd/fuse_virtio.c    |  13 +++
 tools/virtiofsd/passthrough_ll.c | 141 +++++++++++++++----------------
 tools/virtiofsd/seccomp.c        |   6 ++
 3 files changed, 87 insertions(+), 73 deletions(-)

-- 
2.21.1



^ permalink raw reply

* Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()
From: Andy Shevchenko @ 2020-02-20 11:46 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Sascha Hauer, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
	Linux Kernel Mailing List, Jacek Anaszewski, Pavel Machek,
	Jiri Slaby, Linux LED Subsystem, Dan Murphy
In-Reply-To: <20200220105718.eoevd3kb63zzrotu@pengutronix.de>

On Thu, Feb 20, 2020 at 12:57 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> On Thu, Feb 20, 2020 at 12:22:36PM +0200, Andy Shevchenko wrote:
> > On Thu, Feb 20, 2020 at 9:49 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > > On Wed, Feb 19, 2020 at 09:50:54PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Feb 13, 2020 at 11:27 AM Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> > > > >
> > > > > This function is in the same spirit as the other kstrto* functions and
> > > > > uses the same calling convention. It expects the input string to be in
> > > > > the format %u:%u and implements stricter parsing than sscanf as it
> > > > > returns an error on trailing data (other than the usual \n).
> >
> > ...
> >
> > > > On top of that, why kstrtodev_t is so important? How many users are
> > > > already in the kernel to get an advantage out of it?
> > >
> > > Does it need to be important? It matches the other kstrto* functions and
> > > so it seemed more natural to me to put it near the other functions. I'm
> > > not aware of other potential users and surprised you seem to suggest
> > > this as a requirement.
> >
> > Yes it does. The kstrtox() are quite generic, what you are proposing
> > is rather one particular case with blurry understanding how many users
> > will be out of it.
>
> In my understanding one user is a hard requirement.

Yes. But looking at the LOCs you introduce to entire kernel in such
generic area (I wouldn't tell you anything if, for instance, you
introduced a support for hypothetical S2P bus with one host controller
driver) like lib/.

> > If you had told "look, we have 1234 users which may benefit out of
> > it", I would have given no comment against.
>
> Sure, having >1000 potential users would be a good argument pro this
> function. But having only one isn't a good contra IMHO.

For lib/ is a good argument in my opinion.

> > > > What to do with all other possible variants ("%d:%d", "%dx%d" and its
> > > > %u variant, etc)?
> > >
> > > I don't see how %d:%d is relevant, major and minor cannot be negative
> > > can they? I never saw 'x' as separator between major and minor. I
> > > considered shortly parsing %u, but given that (I think) this is an
> > > internal representation only I chose to not make it more visible than it
> > > already is.
> >
> > See above, if we are going to make it generic, perhaps better to cover
> > more possible users, right?
> > Otherwise your change provokes pile of (replaced)
> > kstrto_resolution() /* %ux:%u */
> > kstrto_range() /* %d:%d */
> > kstrto_you_name_it()
>
> Given there are respective types that this can be stored to, I don't
> object more functions of this type and don't see a good reason to not
> add such a function. And in my eyes I prefer to have such a function in
> a visible place (i.e. where all the other kstrto* functions are) to
> prevent code duplication.

You can easily satisfy above by adding a function parameter 'char
*delim', right?

> Also I don't understand yet, what you want me to do.

I have issues with kstrto() not playing with simple numbers (boolean
is a special case, but still a number at the end).
I also don't feel good with too narrow usage of the newly introduced helper

> Assume I'd be
> willing to use simple_strtoul, I'd still want to have a function that
> gives me a dev_t from a given string. Should I put this directly in my
> led-trigger driver?

I see the following possibilities:
a) put it inside the caller and forget about generic helper
b) do a generic helper, but 1/ in string_*() namespace, 2/ with a
delimiter parameter and 3/ possibility to take negative numbers

In b) case, add to the commit message how many potential _existing_
users may be converted to this.
Also it would be good to have two versions strict (only \n at the end
is allowed) and non-strict (based on the amount of users for each
group).

> > > And given that I was asked for strict
> > > parsing (i.e. not accepting 2:4:something) I'd say using simple_strto*
> > > is a step backwards. Also simple_strtoul() has "This function is obsolete.
> > > Please use kstrtoul instead." in its docstring which seems to apply to
> > > the other simple_strto*() functions, too.
> >
> > I specifically fixed a doc string to approve its use in the precisely
> > cases you have here.
>
> Can you please be a bit more constructive here and point to the change
> you talk about? I didn't find a commit in next.

https://elixir.bootlin.com/linux/v5.6-rc2/source/include/linux/kernel.h#L446

Note, there is no more word 'obsolete' there.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* Re: [Xen-devel] [PATCH 0/5] libxl/PCI: reserved device memory adjustments
From: Wei Liu @ 2020-02-20 11:45 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
	Wei Liu
In-Reply-To: <b5d94bd8-9a39-c88b-4c3c-f89e655f3abf@suse.com>

On Tue, Feb 18, 2020 at 04:44:11PM +0100, Jan Beulich wrote:
> While playing with this, I've noticed a number of issues,
> some actual bugs, some merely cosmetic (at least at this point
> in time. This is the collection of adjustments made, with bug
> fixes first.

I will leave committing this series to you because your patches don't
seem to work with git-am.

In any case, please allow some time for Anthony and Ian to comment on
this series.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply

* Re: [Xen-devel] [PATCH 5/5] libxl/PCI: align reserved device memory boundary for HAP guests
From: Jan Beulich @ 2020-02-20 11:45 UTC (permalink / raw)
  To: Wei Liu; +Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson
In-Reply-To: <20200220114331.m6yolb4hoyfvfmsa@debian>

On 20.02.2020 12:43, Wei Liu wrote:
> On Tue, Feb 18, 2020 at 04:47:49PM +0100, Jan Beulich wrote:
>> As the code comment says, this will allow use of a 2Mb super page
>> mapping at the end of "low" memory.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -563,6 +563,13 @@ int libxl__domain_device_construct_rdm(l
>>          /* Just check if RDM > our memory boundary. */
>>          if (rdm_start > rdm_mem_boundary) {
>>              /*
>> +             * For HAP guests round down to a 2Mb boundary to allow use
>> +             * of large page mappings.
>> +             */
>> +            if (libxl_defbool_val(d_config->c_info.hap)
>> +                && rdm_start > 0x200000)
> 
> Please use MB(2) here.

Will do, but then what about the ~0x1fffff on the next line? Should
this become ~(MB(2) - 1)?

> With this fixed:
> 
> Acked-by: Wei Liu <wl@xen.org>

Thanks.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply

* [PATCH] image.h: use uint32_t instead of u32 in android_image_get_dtb*
From: Sam Protsenko @ 2020-02-20 11:45 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20200217102353.11174-1-erosca@de.adit-jv.com>

Hi Eugeniu,

On Mon, Feb 17, 2020 at 12:24 PM Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
>
> Replace 'u32' by 'uint32_t' in image.h, since the former may lead to
> build failures in U-Boot tooling (see [1]).
>
> Avoid using 'uint', since it is not a fixed-width type [2], potentially
> leading to a dangerous mismatch between the prototypes and definitions
> of the android_image_get_dtb* functions.
>
> This should be the quickest way to overcome the tooling build failure,
> with more future-proof solutions being proposed by Yamada-san in [1].
>
> [1] https://patchwork.ozlabs.org/patch/1238245/
> [2] Excerpt from https://en.cppreference.com/w/cpp/language/types
>  -----------8<------------
>  Type specifier    Width in bits by data model
>                    LP32  ILP32  LLP64  LP64
>  unsigned int      16    32     32     32
>  -----------8<------------
>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Sam Protsenko <joe.skb7@gmail.com>
> Fixes: 7f2531502c74c0 ("image: android: Add routine to get dtbo params")
> Fixes: c3bfad825a71ea ("image: android: Add functions for handling dtb field")
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---

Reviewed-by: Sam Protsenko <joe.skb7@gmail.com>

>  include/image.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/image.h b/include/image.h
> index b316d167d8d7..1341fbed62ba 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1425,9 +1425,9 @@ int android_image_get_ramdisk(const struct andr_img_hdr *hdr,
>                               ulong *rd_data, ulong *rd_len);
>  int android_image_get_second(const struct andr_img_hdr *hdr,
>                               ulong *second_data, ulong *second_len);
> -bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, u32 *size);
> -bool android_image_get_dtb_by_index(ulong hdr_addr, u32 index, ulong *addr,
> -                                   u32 *size);
> +bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, uint32_t *size);
> +bool android_image_get_dtb_by_index(ulong hdr_addr, uint32_t index, ulong *addr,
> +                                   uint32_t *size);
>  ulong android_image_get_end(const struct andr_img_hdr *hdr);
>  ulong android_image_get_kload(const struct andr_img_hdr *hdr);
>  ulong android_image_get_kcomp(const struct andr_img_hdr *hdr);
> --
> 2.25.0
>

^ permalink raw reply

* Re: [Xen-devel] [PATCH 3/5] libxl/PCI: make "rdm=" parsing comply with documentation
From: Wei Liu @ 2020-02-20 11:44 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
	Wei Liu
In-Reply-To: <7c8de367-4833-c603-fcdd-89c1e6ceda3a@suse.com>

On Tue, Feb 18, 2020 at 04:47:04PM +0100, Jan Beulich wrote:
> Documentation says "<RDM_RESERVATION_STRING> is a comma separated list
> of <KEY=VALUE> settings, from the following list". There's no mention
> of a specific order, yet so far the parsing logic did accept only
> strategy, then policy (and neither of the two omitted). Make "state"
> move
> - back to STATE_TYPE when finding a comma after having parsed the
>   <VALUE> part of a setting,
> - to STATE_TERMINAL otherwise.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Wei Liu <wl@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.