* Re: [Qemu-devel] [Qemu-block] [PATCH] Added iopmem device emulation
From: Stefan Hajnoczi @ 2016-11-09 9:58 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: Kevin Wolf, Max Reitz, Michael S. Tsirkin, Marcel Apfelbaum,
qemu-devel, qemu-block, Stephen Bates
In-Reply-To: <b15f8110-78e8-ef79-3ed5-449cf3dd7602@deltatee.com>
[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]
On Tue, Nov 08, 2016 at 09:46:47AM -0700, Logan Gunthorpe wrote:
> On 08/11/16 08:58 AM, Stefan Hajnoczi wrote:
> > My concern with the current implementation is that a PCI MMIO access
> > invokes a synchronous blk_*() call. That can pause vcpu execution while
> > I/O is happening and therefore leads to unresponsive guests. QEMU's
> > monitor interface is also blocked during blk_*() making it impossible to
> > troubleshoot QEMU if it gets stuck due to a slow/hung I/O operation.
> >
> > Device models need to use blk_aio_*() so that control is returned while
> > I/O is running. There are a few legacy devices left that use
> > synchronous I/O but new devices should not use this approach.
>
> That's fair. I wasn't aware of this and I must have copied a legacy
> device. We can certainly make the change in our patch.
>
> > Regarding the hardware design, I think the PCI BAR approach to nvdimm is
> > inefficient for virtualization because each memory load/store requires a
> > guest<->host transition (vmexit + vmenter). A DMA approach (i.e.
> > message passing or descriptor rings) is more efficient because it
> > requires fewer vmexits.
> >
> > On real hardware the performance characteristics are different so it
> > depends what your target market is.
>
> The performance of the virtual device is completely unimportant. This
> isn't something I'd expect anyone to use except to test drivers. On real
> hardware, with real applications, DMA would almost certainly be used --
> but it would be the DMA engine in another device. eg. an IB NIC would
> DMA from the PCI BAR of the iopmem device. This completely bypasses the
> CPU so there would be no load/stores to be concerned about.
Okay, sounds good.
Is there a reason to use the block layer in QEMU? Perhaps it's better
to do the same as the nvdimm device in QEMU and use a memory backend
instead. The memory backend can be MAP_PRIVATE or MAP_SHARED. It can
be anonymous memory or it can be backed by a real file. This gives you
options can avoids using the QEMU block layer in a way it wasn't
designed.
Doing this would forgo QEMU block layer features like image file formats
(qcow2), block jobs (storage migration), etc. But those probably aren't
necessary for this device.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCHv2 32/36] pathspec: allow querying for attributes
From: Duy Nguyen @ 2016-11-09 9:57 UTC (permalink / raw)
To: Stefan Beller; +Cc: Junio C Hamano, Brandon Williams, Git Mailing List
In-Reply-To: <20161028185502.8789-33-sbeller@google.com>
On Sat, Oct 29, 2016 at 1:54 AM, Stefan Beller <sbeller@google.com> wrote:
> The pathspec mechanism is extended via the new
> ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it
> requires paths to not just match the given pattern but also have the
> specified attrs attached for them to be chosen.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/glossary-content.txt | 20 +++++
> dir.c | 35 ++++++++
Pathspec can be processed in a couple more places. The big two are
match_pathspec and tree_entry_interesting, the former traverses a list
while the latter does a tree. You don't have to implement attr
matching in tree_entry_interesting right now because nobody needs it,
probably. But you need to make sure if somebody accidentally calls
tree_entry_interesting with an attr pathspec, then it should
die("BUG"), not silently ignore attr.
The way to do that is GUARD_PATHSPEC macro which makes sure if only
recognized magic is allowed through. This macro guards all pathspec
processing functions. So you can add a new PATHSPEC_ATTR macro (or
some other name) to the "Pathspec magic" group near the beginning of
pathspec.h, set it whenever attr magic is present when you
parse_pathspec(), then lift the GUARD_PATHSPEC restriction in
match_pathspec() only because this function can handle it. Whenever
attr magic is used by any other functions, it will die() the way we
want.
--
Duy
^ permalink raw reply
* Re: [PATCH net v2 2/4] net: ethernet: ti: cpsw: fix device and of_node leaks
From: Johan Hovold @ 2016-11-09 9:58 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Johan Hovold, Florian Fainelli, Mugunthan V N, Yisen Zhuang,
Salil Mehta, David S. Miller, netdev, linux-kernel, linux-omap
In-Reply-To: <0c76f9db-ab5f-bce3-897d-5f325c2b84c4@ti.com>
On Tue, Nov 08, 2016 at 05:19:29PM -0600, Grygorii Strashko wrote:
>
>
> On 11/03/2016 12:40 PM, Johan Hovold wrote:
> > Make sure to drop the references taken by of_get_child_by_name() and
> > bus_find_device() before returning from cpsw_phy_sel().
> >
> > Note that holding a reference to the cpsw-phy-sel device does not
> > prevent the devres-managed private data from going away.
> >
> > Fixes: 5892cd135e16 ("drivers: net: cpsw-phy-sel: Add new driver...")
> > Cc: Mugunthan V N <mugunthanvnm@ti.com>
> > Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> > Cc: linux-omap@vger.kernel.org
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
>
> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Thanks for the review. Note that David has already applied these, though.
Johan
^ permalink raw reply
* Re: [PATCH v10 2/7] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64
From: Borislav Petkov @ 2016-11-09 9:58 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel
In-Reply-To: <20161108183956.4521-3-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:51AM -0800, Kyle Huey wrote:
> In order to introduce new arch_prctls that are not 64 bit only, rename the
> existing 64 bit implementation to do_arch_prctl_64. Also rename the second
do_arch_prctl_64()
> argument to arch_prctl, which will no longer always be an address.
arch_prctl()
so that we know they're functions.
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> Reviewed-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/x86/include/asm/proto.h | 4 +++-
> arch/x86/kernel/process_64.c | 32 +++++++++++++++++---------------
> arch/x86/kernel/ptrace.c | 8 ++++----
> arch/x86/um/syscalls_64.c | 4 ++--
> 4 files changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
> index 9b9b30b..95c3e51 100644
> --- a/arch/x86/include/asm/proto.h
> +++ b/arch/x86/include/asm/proto.h
> @@ -25,11 +25,13 @@ void entry_SYSCALL_compat(void);
> void entry_INT80_compat(void);
> #endif
>
> void x86_configure_nx(void);
> void x86_report_nx(void);
>
> extern int reboot_force;
>
> -long do_arch_prctl(struct task_struct *task, int code, unsigned long addr);
> +#ifdef CONFIG_X86_64
> +long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2);
> +#endif
There's already an #ifdef CONFIG_X86_64 in that file, please move this
one there too.
...
> @@ -863,17 +863,17 @@ long arch_ptrace(struct task_struct *child, long request,
> break;
> #endif
>
> #ifdef CONFIG_X86_64
> /* normal 64bit interface to access TLS data.
> Works just like arch_prctl, except that the arguments
> are reversed. */
> case PTRACE_ARCH_PRCTL:
> - ret = do_arch_prctl(child, data, addr);
> + ret = do_arch_prctl_64(child, data, addr);
> break;
> #endif
>
> default:
> ret = ptrace_request(child, request, addr, data);
> break;
> }
>
> diff --git a/arch/x86/um/syscalls_64.c b/arch/x86/um/syscalls_64.c
> index ab3f7f4..3362c4e 100644
> --- a/arch/x86/um/syscalls_64.c
> +++ b/arch/x86/um/syscalls_64.c
> @@ -68,19 +68,19 @@ long arch_prctl(struct task_struct *task, int code, unsigned long __user *addr)
^^^^^
You missed one here.
Actually I see a couple:
$ git grep -E arch_prctl.*addr
arch/um/include/shared/os.h:306:extern int os_arch_prctl(int pid, int code, unsigned long *addr);
arch/x86/kernel/ptrace.c:871: ret = do_arch_prctl_64(child, data, addr);
arch/x86/um/os-Linux/prctl.c:9:int os_arch_prctl(int pid, int code, unsigned long *addr)
arch/x86/um/ptrace_64.c:272: ret = arch_prctl(child, data, (void __user *) addr);
arch/x86/um/syscalls_64.c:14:long arch_prctl(struct task_struct *task, int code, unsigned long __user *addr)
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: [PATCH v10 2/7] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64
From: Borislav Petkov @ 2016-11-09 9:58 UTC (permalink / raw)
To: Kyle Huey
Cc: Robert O'Callahan, Thomas Gleixner, Andy Lutomirski,
Ingo Molnar, H. Peter Anvin, x86, Paolo Bonzini,
Radim Krčmář, Jeff Dike, Richard Weinberger,
Alexander Viro, Shuah Khan, Dave Hansen, Peter Zijlstra,
Boris Ostrovsky, Len Brown, Rafael J. Wysocki, Dmitry Safonov,
David Matlack, linux-kernel, user-mode-linux-devel,
user-mode-linux-user, linux-fsdevel, linux-kselftest, kvm
In-Reply-To: <20161108183956.4521-3-khuey@kylehuey.com>
On Tue, Nov 08, 2016 at 10:39:51AM -0800, Kyle Huey wrote:
> In order to introduce new arch_prctls that are not 64 bit only, rename the
> existing 64 bit implementation to do_arch_prctl_64. Also rename the second
do_arch_prctl_64()
> argument to arch_prctl, which will no longer always be an address.
arch_prctl()
so that we know they're functions.
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> Reviewed-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/x86/include/asm/proto.h | 4 +++-
> arch/x86/kernel/process_64.c | 32 +++++++++++++++++---------------
> arch/x86/kernel/ptrace.c | 8 ++++----
> arch/x86/um/syscalls_64.c | 4 ++--
> 4 files changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
> index 9b9b30b..95c3e51 100644
> --- a/arch/x86/include/asm/proto.h
> +++ b/arch/x86/include/asm/proto.h
> @@ -25,11 +25,13 @@ void entry_SYSCALL_compat(void);
> void entry_INT80_compat(void);
> #endif
>
> void x86_configure_nx(void);
> void x86_report_nx(void);
>
> extern int reboot_force;
>
> -long do_arch_prctl(struct task_struct *task, int code, unsigned long addr);
> +#ifdef CONFIG_X86_64
> +long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2);
> +#endif
There's already an #ifdef CONFIG_X86_64 in that file, please move this
one there too.
...
> @@ -863,17 +863,17 @@ long arch_ptrace(struct task_struct *child, long request,
> break;
> #endif
>
> #ifdef CONFIG_X86_64
> /* normal 64bit interface to access TLS data.
> Works just like arch_prctl, except that the arguments
> are reversed. */
> case PTRACE_ARCH_PRCTL:
> - ret = do_arch_prctl(child, data, addr);
> + ret = do_arch_prctl_64(child, data, addr);
> break;
> #endif
>
> default:
> ret = ptrace_request(child, request, addr, data);
> break;
> }
>
> diff --git a/arch/x86/um/syscalls_64.c b/arch/x86/um/syscalls_64.c
> index ab3f7f4..3362c4e 100644
> --- a/arch/x86/um/syscalls_64.c
> +++ b/arch/x86/um/syscalls_64.c
> @@ -68,19 +68,19 @@ long arch_prctl(struct task_struct *task, int code, unsigned long __user *addr)
^^^^^
You missed one here.
Actually I see a couple:
$ git grep -E arch_prctl.*addr
arch/um/include/shared/os.h:306:extern int os_arch_prctl(int pid, int code, unsigned long *addr);
arch/x86/kernel/ptrace.c:871: ret = do_arch_prctl_64(child, data, addr);
arch/x86/um/os-Linux/prctl.c:9:int os_arch_prctl(int pid, int code, unsigned long *addr)
arch/x86/um/ptrace_64.c:272: ret = arch_prctl(child, data, (void __user *) addr);
arch/x86/um/syscalls_64.c:14:long arch_prctl(struct task_struct *task, int code, unsigned long __user *addr)
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4
From: Daniel Borkmann @ 2016-11-09 9:57 UTC (permalink / raw)
To: Zhiyi Sun
Cc: bblanco, Tariq Toukan, Yishai Hadas, netdev, linux-rdma,
linux-kernel, alexei.starovoitov
In-Reply-To: <20161109094546.jtmzc4xwtaavzcnt@ubuntu>
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
On 11/09/2016 10:45 AM, Zhiyi Sun wrote:
> On Wed, Nov 09, 2016 at 10:05:31AM +0100, Daniel Borkmann wrote:
>> On 11/09/2016 08:35 AM, Zhiyi Sun wrote:
>>> There are rx_ring_num queues. Each queue will load xdp prog. So
>>> bpf_prog_add() should add rx_ring_num to ref_cnt.
>>>
>>> Signed-off-by: Zhiyi Sun <zhiyisun@gmail.com>
>>
>> Your analysis looks incorrect to me. Please elaborate in more detail why
>> you think current code is buggy ...
>
> Yes, you are correct. My patch is incorrect. It is not a bug.
>
>> Call path is dev_change_xdp_fd(), which does bpf_prog_get_type() on the
>> fd. This already takes a ref and only drops it in case of error. Thus
>> in mlx4_xdp_set(), you only need priv->rx_ring_num - 1 refs for the rest
>> of the rings, so that dropping refs from old_prog makes sure we release
>> it again. Looks correct to me (maybe a comment would have helped there).
>
> I thought mlx4's code is incorrect because in mlx5's driver, function
> mlx5e_xdp_set() calls a pair of bpf_prog_add/put, the number of add and
> put to the refs are same. I didn't notice that one "add" has been called in its
> calller. So, it seems that mlx5's code is incorrect, right?
Yep, I think the two attached patches are needed.
The other thing I noticed in mlx5e_create_rq() is that it calls
bpf_prog_add(rq->xdp_prog, 1) without actually checking for errors.
[-- Attachment #2: 0001-bpf-mlx4-fix-prog-refcount-in-mlx4_en_try_alloc_reso.patch --]
[-- Type: text/x-patch, Size: 3022 bytes --]
>From d2bd6b3cd8636716a06b0ea3b1e041e16f87cce0 Mon Sep 17 00:00:00 2001
Message-Id: <d2bd6b3cd8636716a06b0ea3b1e041e16f87cce0.1478685278.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 9 Nov 2016 10:31:19 +0100
Subject: [PATCH net-next 1/2] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path
Commit 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings
scheme") added a bug in that the prog's reference count is not dropped
in the error path when mlx4_en_try_alloc_resources() is failing.
We previously took bpf_prog_add(prog, priv->rx_ring_num - 1), that we
need to release again. Earlier in the call-path, dev_change_xdp_fd()
itself holds a ref to the prog as well, which is then released though
bpf_prog_put() due to the propagated error.
Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 ++++-
include/linux/bpf.h | 1 +
kernel/bpf/syscall.c | 11 +++++++++++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 0f6225c..4104aec 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2747,8 +2747,11 @@ static int mlx4_xdp_set(struct net_device *dev, struct bpf_prog *prog)
}
err = mlx4_en_try_alloc_resources(priv, tmp, &new_prof);
- if (err)
+ if (err) {
+ if (prog)
+ bpf_prog_add_undo(prog, priv->rx_ring_num - 1);
goto unlock_out;
+ }
if (priv->port_up) {
port_up = 1;
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index edcd96d..4f6a4f1 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -234,6 +234,7 @@ u64 bpf_event_output(struct bpf_map *map, u64 flags, void *meta, u64 meta_size,
struct bpf_prog *bpf_prog_get(u32 ufd);
struct bpf_prog *bpf_prog_get_type(u32 ufd, enum bpf_prog_type type);
struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i);
+void bpf_prog_add_undo(struct bpf_prog *prog, int i);
struct bpf_prog *bpf_prog_inc(struct bpf_prog *prog);
void bpf_prog_put(struct bpf_prog *prog);
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 228f962..a6e4dd8 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -680,6 +680,17 @@ struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i)
}
EXPORT_SYMBOL_GPL(bpf_prog_add);
+void bpf_prog_add_undo(struct bpf_prog *prog, int i)
+{
+ /* Only to be used for undoing previous bpf_prog_add() in some
+ * error path. We still know that another entity in our call
+ * path holds a reference to the program, thus atomic_sub() can
+ * be safely used here!
+ */
+ atomic_sub(i, &prog->aux->refcnt);
+}
+EXPORT_SYMBOL_GPL(bpf_prog_add_undo);
+
struct bpf_prog *bpf_prog_inc(struct bpf_prog *prog)
{
return bpf_prog_add(prog, 1);
--
1.9.3
[-- Attachment #3: 0002-bpf-mlx5-fix-prog-refcount-in-mlx5e_xdp_set.patch --]
[-- Type: text/x-patch, Size: 1474 bytes --]
>From f0789544432bbb89c53c3b8ac6575d48fed97786 Mon Sep 17 00:00:00 2001
Message-Id: <f0789544432bbb89c53c3b8ac6575d48fed97786.1478685278.git.daniel@iogearbox.net>
In-Reply-To: <d2bd6b3cd8636716a06b0ea3b1e041e16f87cce0.1478685278.git.daniel@iogearbox.net>
References: <d2bd6b3cd8636716a06b0ea3b1e041e16f87cce0.1478685278.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 9 Nov 2016 10:51:26 +0100
Subject: [PATCH net-next 2/2] bpf, mlx5: fix prog refcount in mlx5e_xdp_set
dev_change_xdp_fd() already holds a reference, so bpf_prog_add(prog, 1)
is not correct as it takes one reference too much and will thus leak
the prog eventually. Also, bpf_prog_add() can fail and is not checked
for errors here.
Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index ba0c774..63309dd 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3121,8 +3121,6 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
/* exchange programs */
old_prog = xchg(&priv->xdp_prog, prog);
- if (prog)
- bpf_prog_add(prog, 1);
if (old_prog)
bpf_prog_put(old_prog);
--
1.9.3
^ permalink raw reply related
* ILP32 for ARM64: testing with glibc testsuite
From: Yury Norov @ 2016-11-09 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107082359.GA19666@yury-N73SV>
On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote:
> Hi all,
>
> [add libc-alpha mail list]
>
> For libc-alpha: this is the part of LKML submission with latest
> patches for aarch64/ilp32.
> https://www.spinics.net/lists/arm-kernel/msg537846.html
>
> Glibc that I use has also included consolidation patches from Adhemerval
> Zanella and me that are still not in the glibc master. The full series is:
> https://github.com/norov/glibc/tree/ilp32-2.24-dev2
>
> Below is the results of glibc testsuite run for aarch64/lp64
> in different configurations. Column names meaning:
> kvgv: kernel is vanilla, glibc is vanilla;
> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config;
> glibc is vanilla;
> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla;
> kege: kernel patches are applied and enabled, glibc patches are applied.
>
> Only different lines are shown. Full results are in attached archive.
The same, plus ILP32 regressions:
Test kvgv kdgv kegv kege ilp32
conform/ISO/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/ISO11/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/ISO99/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/POSIX/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/POSIX/sys/stat.h/linknamespace PASS PASS PASS FAIL FAIL
conform/UNIX98/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XOPEN2K/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XPG3/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XPG4/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
csu/tst-atomic PASS PASS PASS FAIL PASS
elf/check-localplt PASS PASS PASS FAIL FAIL
iconvdata/mtrace-tst-loading PASS FAIL PASS PASS FAIL
iconvdata/tst-loading PASS FAIL PASS PASS PASS
io/check-installed-headers-c PASS PASS PASS FAIL FAIL
io/check-installed-headers-cxx PASS PASS PASS FAIL FAIL
malloc/tst-malloc-backtrace FAIL PASS PASS PASS PASS
malloc/tst-malloc-thread-exit FAIL PASS PASS PASS PASS
malloc/tst-malloc-usable FAIL PASS PASS PASS PASS
malloc/tst-mallocfork FAIL PASS PASS PASS PASS
malloc/tst-mallocstate FAIL PASS PASS PASS PASS
malloc/tst-mallopt FAIL PASS PASS PASS PASS
malloc/tst-mcheck FAIL PASS PASS PASS PASS
malloc/tst-memalign FAIL PASS PASS PASS PASS
malloc/tst-obstack FAIL PASS PASS PASS PASS
malloc/tst-posix_memalign FAIL PASS PASS PASS PASS
malloc/tst-pvalloc FAIL PASS PASS PASS PASS
malloc/tst-realloc FAIL PASS PASS PASS PASS
malloc/tst-scratch_buffer FAIL PASS PASS PASS PASS
malloc/tst-trim1 FAIL PASS PASS PASS PASS
nptl/tst-eintr4 PASS PASS PASS NA NA
posix/tst-regex2 PASS FAIL FAIL FAIL FAIL
posix/tst-getaddrinfo4 PASS PASS FAIL FAIL PASS
posix/tst-getaddrinfo5 PASS PASS FAIL FAIL PASS
sysvipc/test-sysvmsg NA NA NA FAIL PASS
sysvipc/test-sysvsem NA NA NA FAIL PASS
sysvipc/test-sysvshm NA NA NA FAIL PASS
c++-types-check PASS PASS PASS PASS FAIL
debug/tst-backtrace4 PASS PASS PASS PASS FAIL
elf/check-abi-libc PASS PASS PASS PASS FAIL
elf/tst-tls1 PASS PASS PASS PASS FAIL
elf/tst-tls1-static PASS PASS PASS PASS FAIL
elf/tst-tls2 PASS PASS PASS PASS FAIL
elf/tst-tls2-static PASS PASS PASS PASS FAIL
elf/tst-tls3 PASS PASS PASS PASS FAIL
math/check-abi-libm PASS PASS PASS PASS FAIL
misc/tst-writev PASS PASS PASS PASS NA
nptl/tst-cancel-self-canceltype PASS PASS PASS PASS FAIL
nptl/tst-cancel1 PASS PASS PASS PASS FAIL
nptl/tst-cancel10 PASS PASS PASS PASS FAIL
nptl/tst-cancel11 PASS PASS PASS PASS FAIL
nptl/tst-cancel13 PASS PASS PASS PASS FAIL
nptl/tst-cancel15 PASS PASS PASS PASS FAIL
nptl/tst-cancel16 PASS PASS PASS PASS FAIL
nptl/tst-cancel17 PASS PASS PASS PASS FAIL
nptl/tst-cancel18 PASS PASS PASS PASS FAIL
nptl/tst-cancel2 PASS PASS PASS PASS FAIL
nptl/tst-cancel20 PASS PASS PASS PASS FAIL
nptl/tst-cancel21 PASS PASS PASS PASS FAIL
nptl/tst-cancel24 PASS PASS PASS PASS FAIL
nptl/tst-cancel25 PASS PASS PASS PASS FAIL
nptl/tst-cancel26 PASS PASS PASS PASS FAIL
nptl/tst-cancel27 PASS PASS PASS PASS FAIL
nptl/tst-cancel3 PASS PASS PASS PASS FAIL
nptl/tst-cancel4 PASS PASS PASS PASS FAIL
nptl/tst-cancel5 PASS PASS PASS PASS FAIL
nptl/tst-cancel6 PASS PASS PASS PASS FAIL
nptl/tst-cancel7 PASS PASS PASS PASS FAIL
nptl/tst-cancelx10 PASS PASS PASS PASS FAIL
nptl/tst-cancelx11 PASS PASS PASS PASS FAIL
nptl/tst-cancelx13 PASS PASS PASS PASS FAIL
nptl/tst-cancelx15 PASS PASS PASS PASS FAIL
nptl/tst-cancelx16 PASS PASS PASS PASS FAIL
nptl/tst-cancelx17 PASS PASS PASS PASS FAIL
nptl/tst-cancelx18 PASS PASS PASS PASS FAIL
nptl/tst-cancelx2 PASS PASS PASS PASS FAIL
nptl/tst-cancelx20 PASS PASS PASS PASS FAIL
nptl/tst-cancelx21 PASS PASS PASS PASS FAIL
nptl/tst-cancelx3 PASS PASS PASS PASS FAIL
nptl/tst-cancelx4 PASS PASS PASS PASS FAIL
nptl/tst-cancelx5 PASS PASS PASS PASS FAIL
nptl/tst-cancelx6 PASS PASS PASS PASS FAIL
nptl/tst-cancelx7 PASS PASS PASS PASS FAIL
nptl/tst-cleanup4 PASS PASS PASS PASS FAIL
nptl/tst-cleanupx4 PASS PASS PASS PASS FAIL
nptl/tst-cond-except PASS PASS PASS PASS FAIL
nptl/tst-cond7 PASS PASS PASS PASS FAIL
nptl/tst-cond8 PASS PASS PASS PASS FAIL
nptl/tst-fini1 PASS PASS PASS PASS FAIL
nptl/tst-initializers1 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c11 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c89 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c99 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu11 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu89 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu99 PASS PASS PASS PASS FAIL
nptl/tst-join5 PASS PASS PASS PASS FAIL
nptl/tst-key3 PASS PASS PASS PASS FAIL
nptl/tst-mutex8 PASS PASS PASS PASS FAIL
nptl/tst-mutexpi8 PASS PASS PASS PASS FAIL
nptl/tst-once3 PASS PASS PASS PASS FAIL
nptl/tst-once4 PASS PASS PASS PASS FAIL
nptl/tst-oncex3 PASS PASS PASS PASS FAIL
nptl/tst-oncex4 PASS PASS PASS PASS FAIL
nptl/tst-rwlock15 PASS PASS PASS PASS FAIL
nptl/tst-rwlock8 PASS PASS PASS PASS FAIL
nptl/tst-rwlock9 PASS PASS PASS PASS FAIL
nptl/tst-sem11 PASS PASS PASS PASS FAIL
nptl/tst-sem12 PASS PASS PASS PASS FAIL
posix/bug-regex24 PASS PASS PASS PASS FAIL
rt/tst-mqueue1 PASS PASS PASS PASS FAIL
rt/tst-mqueue2 PASS PASS PASS PASS FAIL
rt/tst-mqueue4 PASS PASS PASS PASS FAIL
rt/tst-mqueue7 PASS PASS PASS PASS FAIL
rt/tst-mqueue8 PASS PASS PASS PASS FAIL
rt/tst-mqueue8x PASS PASS PASS PASS FAIL
stdlib/tst-makecontext3 PASS PASS PASS PASS FAIL
^ permalink raw reply
* Re: ILP32 for ARM64: testing with glibc testsuite
From: Yury Norov @ 2016-11-09 9:56 UTC (permalink / raw)
To: arnd, catalin.marinas, linux-arm-kernel, linux-kernel, linux-doc,
linux-arch, GNU C Library
Cc: schwidefsky, heiko.carstens, pinskia, broonie, joseph,
christoph.muellner, bamvor.zhangjian, szabolcs.nagy, klimov.linux,
Nathan_Lynch, agraf, Prasun.Kapoor, kilobyte, geert,
philipp.tomsich, manuel.montezelo, linyongting, maxim.kuvyrkov,
davem, zhouchengming1, cmetcalf, Adhemerval Zanella, Steve Ellcey
In-Reply-To: <20161107082359.GA19666@yury-N73SV>
On Mon, Nov 07, 2016 at 01:53:59PM +0530, Yury Norov wrote:
> Hi all,
>
> [add libc-alpha mail list]
>
> For libc-alpha: this is the part of LKML submission with latest
> patches for aarch64/ilp32.
> https://www.spinics.net/lists/arm-kernel/msg537846.html
>
> Glibc that I use has also included consolidation patches from Adhemerval
> Zanella and me that are still not in the glibc master. The full series is:
> https://github.com/norov/glibc/tree/ilp32-2.24-dev2
>
> Below is the results of glibc testsuite run for aarch64/lp64
> in different configurations. Column names meaning:
> kvgv: kernel is vanilla, glibc is vanilla;
> kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config;
> glibc is vanilla;
> kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla;
> kege: kernel patches are applied and enabled, glibc patches are applied.
>
> Only different lines are shown. Full results are in attached archive.
The same, plus ILP32 regressions:
Test kvgv kdgv kegv kege ilp32
conform/ISO/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/ISO11/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/ISO99/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/POSIX/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/POSIX/sys/stat.h/linknamespace PASS PASS PASS FAIL FAIL
conform/UNIX98/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XOPEN2K/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XPG3/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
conform/XPG4/stdio.h/linknamespace PASS PASS PASS FAIL FAIL
csu/tst-atomic PASS PASS PASS FAIL PASS
elf/check-localplt PASS PASS PASS FAIL FAIL
iconvdata/mtrace-tst-loading PASS FAIL PASS PASS FAIL
iconvdata/tst-loading PASS FAIL PASS PASS PASS
io/check-installed-headers-c PASS PASS PASS FAIL FAIL
io/check-installed-headers-cxx PASS PASS PASS FAIL FAIL
malloc/tst-malloc-backtrace FAIL PASS PASS PASS PASS
malloc/tst-malloc-thread-exit FAIL PASS PASS PASS PASS
malloc/tst-malloc-usable FAIL PASS PASS PASS PASS
malloc/tst-mallocfork FAIL PASS PASS PASS PASS
malloc/tst-mallocstate FAIL PASS PASS PASS PASS
malloc/tst-mallopt FAIL PASS PASS PASS PASS
malloc/tst-mcheck FAIL PASS PASS PASS PASS
malloc/tst-memalign FAIL PASS PASS PASS PASS
malloc/tst-obstack FAIL PASS PASS PASS PASS
malloc/tst-posix_memalign FAIL PASS PASS PASS PASS
malloc/tst-pvalloc FAIL PASS PASS PASS PASS
malloc/tst-realloc FAIL PASS PASS PASS PASS
malloc/tst-scratch_buffer FAIL PASS PASS PASS PASS
malloc/tst-trim1 FAIL PASS PASS PASS PASS
nptl/tst-eintr4 PASS PASS PASS NA NA
posix/tst-regex2 PASS FAIL FAIL FAIL FAIL
posix/tst-getaddrinfo4 PASS PASS FAIL FAIL PASS
posix/tst-getaddrinfo5 PASS PASS FAIL FAIL PASS
sysvipc/test-sysvmsg NA NA NA FAIL PASS
sysvipc/test-sysvsem NA NA NA FAIL PASS
sysvipc/test-sysvshm NA NA NA FAIL PASS
c++-types-check PASS PASS PASS PASS FAIL
debug/tst-backtrace4 PASS PASS PASS PASS FAIL
elf/check-abi-libc PASS PASS PASS PASS FAIL
elf/tst-tls1 PASS PASS PASS PASS FAIL
elf/tst-tls1-static PASS PASS PASS PASS FAIL
elf/tst-tls2 PASS PASS PASS PASS FAIL
elf/tst-tls2-static PASS PASS PASS PASS FAIL
elf/tst-tls3 PASS PASS PASS PASS FAIL
math/check-abi-libm PASS PASS PASS PASS FAIL
misc/tst-writev PASS PASS PASS PASS NA
nptl/tst-cancel-self-canceltype PASS PASS PASS PASS FAIL
nptl/tst-cancel1 PASS PASS PASS PASS FAIL
nptl/tst-cancel10 PASS PASS PASS PASS FAIL
nptl/tst-cancel11 PASS PASS PASS PASS FAIL
nptl/tst-cancel13 PASS PASS PASS PASS FAIL
nptl/tst-cancel15 PASS PASS PASS PASS FAIL
nptl/tst-cancel16 PASS PASS PASS PASS FAIL
nptl/tst-cancel17 PASS PASS PASS PASS FAIL
nptl/tst-cancel18 PASS PASS PASS PASS FAIL
nptl/tst-cancel2 PASS PASS PASS PASS FAIL
nptl/tst-cancel20 PASS PASS PASS PASS FAIL
nptl/tst-cancel21 PASS PASS PASS PASS FAIL
nptl/tst-cancel24 PASS PASS PASS PASS FAIL
nptl/tst-cancel25 PASS PASS PASS PASS FAIL
nptl/tst-cancel26 PASS PASS PASS PASS FAIL
nptl/tst-cancel27 PASS PASS PASS PASS FAIL
nptl/tst-cancel3 PASS PASS PASS PASS FAIL
nptl/tst-cancel4 PASS PASS PASS PASS FAIL
nptl/tst-cancel5 PASS PASS PASS PASS FAIL
nptl/tst-cancel6 PASS PASS PASS PASS FAIL
nptl/tst-cancel7 PASS PASS PASS PASS FAIL
nptl/tst-cancelx10 PASS PASS PASS PASS FAIL
nptl/tst-cancelx11 PASS PASS PASS PASS FAIL
nptl/tst-cancelx13 PASS PASS PASS PASS FAIL
nptl/tst-cancelx15 PASS PASS PASS PASS FAIL
nptl/tst-cancelx16 PASS PASS PASS PASS FAIL
nptl/tst-cancelx17 PASS PASS PASS PASS FAIL
nptl/tst-cancelx18 PASS PASS PASS PASS FAIL
nptl/tst-cancelx2 PASS PASS PASS PASS FAIL
nptl/tst-cancelx20 PASS PASS PASS PASS FAIL
nptl/tst-cancelx21 PASS PASS PASS PASS FAIL
nptl/tst-cancelx3 PASS PASS PASS PASS FAIL
nptl/tst-cancelx4 PASS PASS PASS PASS FAIL
nptl/tst-cancelx5 PASS PASS PASS PASS FAIL
nptl/tst-cancelx6 PASS PASS PASS PASS FAIL
nptl/tst-cancelx7 PASS PASS PASS PASS FAIL
nptl/tst-cleanup4 PASS PASS PASS PASS FAIL
nptl/tst-cleanupx4 PASS PASS PASS PASS FAIL
nptl/tst-cond-except PASS PASS PASS PASS FAIL
nptl/tst-cond7 PASS PASS PASS PASS FAIL
nptl/tst-cond8 PASS PASS PASS PASS FAIL
nptl/tst-fini1 PASS PASS PASS PASS FAIL
nptl/tst-initializers1 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c11 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c89 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-c99 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu11 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu89 PASS PASS PASS PASS FAIL
nptl/tst-initializers1-gnu99 PASS PASS PASS PASS FAIL
nptl/tst-join5 PASS PASS PASS PASS FAIL
nptl/tst-key3 PASS PASS PASS PASS FAIL
nptl/tst-mutex8 PASS PASS PASS PASS FAIL
nptl/tst-mutexpi8 PASS PASS PASS PASS FAIL
nptl/tst-once3 PASS PASS PASS PASS FAIL
nptl/tst-once4 PASS PASS PASS PASS FAIL
nptl/tst-oncex3 PASS PASS PASS PASS FAIL
nptl/tst-oncex4 PASS PASS PASS PASS FAIL
nptl/tst-rwlock15 PASS PASS PASS PASS FAIL
nptl/tst-rwlock8 PASS PASS PASS PASS FAIL
nptl/tst-rwlock9 PASS PASS PASS PASS FAIL
nptl/tst-sem11 PASS PASS PASS PASS FAIL
nptl/tst-sem12 PASS PASS PASS PASS FAIL
posix/bug-regex24 PASS PASS PASS PASS FAIL
rt/tst-mqueue1 PASS PASS PASS PASS FAIL
rt/tst-mqueue2 PASS PASS PASS PASS FAIL
rt/tst-mqueue4 PASS PASS PASS PASS FAIL
rt/tst-mqueue7 PASS PASS PASS PASS FAIL
rt/tst-mqueue8 PASS PASS PASS PASS FAIL
rt/tst-mqueue8x PASS PASS PASS PASS FAIL
stdlib/tst-makecontext3 PASS PASS PASS PASS FAIL
^ permalink raw reply
* [bug report] genetlink: fix error return code in genl_register_family()
From: Dan Carpenter @ 2016-11-09 9:56 UTC (permalink / raw)
To: kernel-janitors
Hello Wei Yongjun,
The patch 22ca904ad70a: "genetlink: fix error return code in
genl_register_family()" from Nov 1, 2016, leads to the following
static checker warning:
net/netlink/genetlink.c:365 genl_register_family()
warn: unsigned 'family->id' is never less than zero.
net/netlink/genetlink.c
362
363 family->id = idr_alloc(&genl_fam_idr, family,
364 start, end + 1, GFP_KERNEL);
365 if (family->id < 0) {
^^^^^^^^^^^^^^
Doesn't work for unsigned int.
366 err = family->id;
367 goto errout_free;
368 }
369
regards,
dan carpenter
^ permalink raw reply
* [PATCH v2 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109085946.cmd4ltaxpiojq7il@tarshish>
Hi Baruch
Le 09/11/2016 ? 09:59, Baruch Siach a ?crit :
>> @@ -193,6 +204,8 @@ struct pxa_i2c {
>> unsigned char master_code;
>> unsigned long rate;
>> bool highmode_enter;
>> + unsigned long fm_mask;
>> + unsigned long hs_mask;
>
> Do you really need 64bit for that?
>
> baruch
Mhhh, good point. No I think that I can use an unsigned int.
I will fix it.
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 9:55 UTC (permalink / raw)
To: Baruch Siach
Cc: Mark Rutland, Andrew Lunn, Wolfram Sang, Hanna Hawa, Nadav Haklai,
Neta Zur Hershkovits, linux-i2c, Yahuda Yitschak,
linux-arm-kernel, Sebastian Hesselbarth, devicetree, Jason Cooper,
Pawel Moll, Ian Campbell, Omri Itach, Rob Herring,
Gregory Clement, Marcin Wojtas, Igal Liberman, Thomas Petazzoni,
Shadi Ammouri, Kumar Gala
In-Reply-To: <20161109085946.cmd4ltaxpiojq7il@tarshish>
Hi Baruch
Le 09/11/2016 à 09:59, Baruch Siach a écrit :
>> @@ -193,6 +204,8 @@ struct pxa_i2c {
>> unsigned char master_code;
>> unsigned long rate;
>> bool highmode_enter;
>> + unsigned long fm_mask;
>> + unsigned long hs_mask;
>
> Do you really need 64bit for that?
>
> baruch
Mhhh, good point. No I think that I can use an unsigned int.
I will fix it.
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [WireGuard] mips32 crash
From: k @ 2016-11-09 9:56 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
In-Reply-To: <1522436030.20161107130256@vodka.home.kg>
I recompiled kernel with CONFIG_DEBUG_STACKOVERFLOW.
Can confirm that crash is caused by kernel stack overflow.
Wireguard uses different implementations of crypto routines for
different CPUs. Suprisingly MIPS32 uses more stack than X64.
Kernel stack size is only 8kb and it cant be changed.
Also it contains task struct at the stack bottom and it gets
overwritten. I was extremely surprised when I knew about task struct.
Very very stupid decision.
I also understand why only l2tp causes crash. L2tp uses additional
stack space. Without l2tp stack has enough size.
Anyway, look at the crash and take measures.
<7>[ 176.817848] wireguard: Receiving handshake response from peer 1 (:16)
<7>[ 176.838476] wireguard: Keypair 2 created for peer 1
<7>[ 176.844450] wireguard: Sending keepalive packet to peer 1 (:16)
<7>[ 296.851870] wireguard: Sending handshake initiation to peer 1 (:16)
><4>[ 296.972466] do_IRQ: stack overflow: 924
<4>[ 296.976321] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W =
4.4.30 #0
<4>[ 296.983747] Workqueue: wireguard-wg-wgkk packet_process_queued_handsh=
ake_packets [wireguard]
<4>[ 296.992168] Stack : 00000000 800b1108 800b10e4 80430de4 8042bb60 0000=
0006 80461db0 83848344
<4>[ 296.992168] 000d56d1 800aebec 804a0000 8009fbc0 00000000 801f=
3890 00000000 83848344
<4>[ 296.992168] 80430de4 8381dd00 804a0000 8009c1f8 00000000 8384=
837c 00000000 8023df54
<4>[ 296.992168] 804a42b0 83848300 83146c58 80b0b600 80a8c000 7769=
7265 67756172 642d7767
<4>[ 296.992168] 2d77676b 6b000000 00000000 00000000 00000000 0000=
0000 00000000 00000000
<4>[ 296.992168] ...
<4>[ 297.027911] Call Trace:
<4>[ 297.030366] [<800732bc>] show_stack+0x50/0x84
<4>[ 297.034717] [<8006fed0>] do_IRQ+0x3c/0x54
<4>[ 297.038735] [<8006b870>] plat_irq_dispatch+0xd4/0x10c
<4>[ 297.043780] [<80060820>] ret_from_irq+0x0/0x4
<4>[ 297.048141] [<831507a0>] poly1305_generic_blocks+0x80/0x298 [wireguar=
d]
<4>[ 297.054768] [<83150a58>] poly1305_update+0xa0/0x118 [wireguard]
<4>[ 297.060699] [<8315109c>] chacha20poly1305_encrypt_sg+0x1d0/0x2e4 [wir=
eguard]
<4>[ 297.067737]=20
<1>[ 297.069318] CPU 0 Unable to handle kernel paging request at virtual a=
ddress 00000140, epc =3D=3D 8007a0bc, ra =3D=3D 80060824
<4>[ 297.079903] Oops[#1]:
<4>[ 297.082175] CPU: 0 PID: 5 Comm: kworker/0:0H Tainted: G W =
4.4.30 #0
<4>[ 297.089560] task: 8382d4c0 ti: 83842000 task.ti: 83842000
<4>[ 297.094939] $ 0 : 00000000 00000000 00000000 40000140
<4>[ 297.100185] $ 4 : 83844118 00030000 00000140 01000000
<4>[ 297.105433] $ 8 : 1000fc00 1000001e b4dd4aa9 83848580
<4>[ 297.110680] $12 : 83848498 00000000 00000000 00000000
<4>[ 297.115928] $16 : 83844118 00000140 804aac98 00000000
<4>[ 297.121175] $20 : c0000000 ffffffff 000d56d1 12685800
<4>[ 297.126422] $24 : 80a0f000 03ae7800 =20
<4>[ 297.131669] $28 : 83844000 83844048 00000000 80060824
<4>[ 297.136917] Hi : 00000028
<4>[ 297.139791] Lo : 00000000
<4>[ 297.142675] epc : 8007a0bc __do_page_fault+0x5c/0x518
<4>[ 297.147893] ra : 80060824 resume_userspace_check+0x0/0x10
<4>[ 297.153533] Status: 1000fc02 KERNEL EXL=20
<4>[ 297.157466] Cause : c0808008 (ExcCode 02)
<4>[ 297.161465] BadVA : 00000140
<4>[ 297.164332] PrId : 00019374 (MIPS 24Kc)
<4>[ 297.168244] Modules linked in: ath9k ath9k_common pppoe ppp_async l2t=
p_ppp iptable_nat ath9k_hw ath pptp pppox ppp_mppe ppp_generic nf_nat_pptp =
nf_nat_ipv4 nf_nat_amanda nf_conntrack_pptp nf_conntrack_ipv6 nf_conntrack_=
ipv4 nf_conntrack_amanda mac80211 ipt_REJECT ipt_MASQUERADE cfg80211 xt_u32=
xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_q=
uota xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_l=
imit xt_length xt_id xt_hl xt_helper xt_hashlimit xt_ecn xt_dscp xt_conntra=
ck xt_connmark xt_connlimit xt_connbytes xt_comment xt_addrtype xt_TCPMSS x=
t_REDIRECT xt_NFQUEUE xt_NFLOG xt_NETMAP xt_LOG xt_IPMARK xt_HL xt_DSCP xt_=
CT xt_CLASSIFY ts_kmp ts_fsm ts_bm slhc nfnetlink_queue nfnetlink_log nf_re=
ject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_p=
roto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat nf=
_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp=
nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_=
netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_br=
oadcast iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_cci=
tt compat_xtables compat br_netfilter em_cmp sch_teql em_nbyte sch_dsmark s=
ch_pie act_ipt sch_codel sch_gred sch_htb cls_basic sch_prio em_text em_met=
a act_police sch_red sch_tbf sch_sfq sch_fq act_connmark nf_conntrack act_s=
kbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_=
hfsc sch_ingress sg ledtrig_usbport xt_set ip_set_list_set ip_set_hash_neti=
face ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net ip_set_hash_net=
portnet ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_h=
ash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitm=
ap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_REJECT nf_reject_ipv6 nf_lo=
g_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_table=
s ip_gre gre ifb wireguard x_tables l2tp_ip6 l2tp_ip sit l2tp_netlink l2tp_=
core udp_tunnel ip6_udp_tunnel tunnel4 ip_tunnel tun nls_utf8 sha1_generic =
ecb usb_storage ehci_platform ehci_hcd sd_mod scsi_mod rndis_host cdc_ether=
usbnet gpio_button_hotplug ext4 jbd2 mbcache usbcore nls_base usb_common c=
rc16 mii cryptomgr aead crypto_null crc32c_generic crypto_hash
<4>[ 297.370113] Process kworker/0:0H (pid: 5, threadinfo=3D83842000, task=
=3D8382d4c0, tls=3D00000000)
<4>[ 297.378437] Stack : 00000000 00000000 00000000 00000000 00000000 0000=
0000 00000000 00000000
<4>[ 297.378437] 00000000 00000000 00000000 00030001 00000000 0000=
0000 00000000 00000000
<4>[ 297.378437] 00000000 00000000 00000000 00000000 00000000 0000=
0000 00000000 00000000
<4>[ 297.378437] 00000000 00000000 00000000 00000000 00000000 0000=
0000 00000000 00000000
<4>[ 297.378437] 00000000 00000000 00000000 00000000 00000000 0000=
0000 00000000 00000000
<4>[ 297.378437] ...
<4>[ 297.414181] Call Trace:
<4>[ 297.416626] [<8007a0bc>] __do_page_fault+0x5c/0x518
<4>[ 297.421489]=20
<4>[ 297.422969]=20
<4>[ 297.422969] Code: 0062102b 00808021 00c08821 <144000b3> 8e770140 8=
f820000 8c4203a8 1440006e 00000000=20
<4>[ 297.441809] ---[ end trace 664b494d95ff5fb2 ]---
^ permalink raw reply
* Re: [PATCH] MIPS: fix duplicate define
From: James Hogan @ 2016-11-09 9:53 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: Ralf Baechle, Paul Burton, linux-kernel, linux-mips
In-Reply-To: <1478641415-6986-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]
On Tue, Nov 08, 2016 at 09:43:35PM +0000, Sudip Mukherjee wrote:
> The mips build of ip27_defconfig is failing with the error:
> In file included from ../arch/mips/include/asm/mach-ip27/spaces.h:29:0,
> from ../arch/mips/include/asm/page.h:12,
> from ../arch/mips/vdso/vdso.h:26,
> from ../arch/mips/vdso/gettimeofday.c:11:
> ../arch/mips/include/asm/mach-generic/spaces.h:28:0:
> error: "CAC_BASE" redefined [-Werror]
> #define CAC_BASE _AC(0x80000000, UL)
>
> In file included from ../arch/mips/include/asm/page.h:12:0,
> from ../arch/mips/vdso/vdso.h:26,
> from ../arch/mips/vdso/gettimeofday.c:11:
> ../arch/mips/include/asm/mach-ip27/spaces.h:22:0:
> note: this is the location of the previous definition
> #define CAC_BASE 0xa800000000000000
>
> Add a condition to check if CAC_BASE is already defined, and define it
> only if it is not yet defined.
>
> Fixes: 3ffc17d8768b ("MIPS: Adjust MIPS64 CAC_BASE to reflect Config.K0")
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> ---
>
> Build log is at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/174134289
>
> arch/mips/include/asm/mach-generic/spaces.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/mips/include/asm/mach-generic/spaces.h b/arch/mips/include/asm/mach-generic/spaces.h
> index 952b0fd..61b75da 100644
> --- a/arch/mips/include/asm/mach-generic/spaces.h
> +++ b/arch/mips/include/asm/mach-generic/spaces.h
> @@ -23,10 +23,12 @@
>
> #ifdef CONFIG_32BIT
> #ifdef CONFIG_KVM_GUEST
> +#ifndef CAC_BASE
This is wrong. Should it be one line up? Note the else...
> #define CAC_BASE _AC(0x40000000, UL)
> #else
here ^^^
i.e. you appear to be changing
CONFIG_KVM_GUEST:
CAC_BASE=0x40000000
!CONFIG_KVM_GUEST:
CAC_BASE=0x80000000
to:
CONFIG_KVM_GUEST:
!CAC_BASE:
CAC_BASE=0x40000000
CAC_BASE:
CAC_BASE=0x80000000
!CONFIG_KVM_GUEST:
(nothing)
Cheers
James
> #define CAC_BASE _AC(0x80000000, UL)
> #endif
> +#endif
> #ifndef IO_BASE
> #define IO_BASE _AC(0xa0000000, UL)
> #endif
> --
> 1.9.1
>
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] MIPS: fix duplicate define
From: James Hogan @ 2016-11-09 9:53 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: Ralf Baechle, Paul Burton, linux-kernel, linux-mips
In-Reply-To: <1478641415-6986-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]
On Tue, Nov 08, 2016 at 09:43:35PM +0000, Sudip Mukherjee wrote:
> The mips build of ip27_defconfig is failing with the error:
> In file included from ../arch/mips/include/asm/mach-ip27/spaces.h:29:0,
> from ../arch/mips/include/asm/page.h:12,
> from ../arch/mips/vdso/vdso.h:26,
> from ../arch/mips/vdso/gettimeofday.c:11:
> ../arch/mips/include/asm/mach-generic/spaces.h:28:0:
> error: "CAC_BASE" redefined [-Werror]
> #define CAC_BASE _AC(0x80000000, UL)
>
> In file included from ../arch/mips/include/asm/page.h:12:0,
> from ../arch/mips/vdso/vdso.h:26,
> from ../arch/mips/vdso/gettimeofday.c:11:
> ../arch/mips/include/asm/mach-ip27/spaces.h:22:0:
> note: this is the location of the previous definition
> #define CAC_BASE 0xa800000000000000
>
> Add a condition to check if CAC_BASE is already defined, and define it
> only if it is not yet defined.
>
> Fixes: 3ffc17d8768b ("MIPS: Adjust MIPS64 CAC_BASE to reflect Config.K0")
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> ---
>
> Build log is at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/174134289
>
> arch/mips/include/asm/mach-generic/spaces.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/mips/include/asm/mach-generic/spaces.h b/arch/mips/include/asm/mach-generic/spaces.h
> index 952b0fd..61b75da 100644
> --- a/arch/mips/include/asm/mach-generic/spaces.h
> +++ b/arch/mips/include/asm/mach-generic/spaces.h
> @@ -23,10 +23,12 @@
>
> #ifdef CONFIG_32BIT
> #ifdef CONFIG_KVM_GUEST
> +#ifndef CAC_BASE
This is wrong. Should it be one line up? Note the else...
> #define CAC_BASE _AC(0x40000000, UL)
> #else
here ^^^
i.e. you appear to be changing
CONFIG_KVM_GUEST:
CAC_BASE=0x40000000
!CONFIG_KVM_GUEST:
CAC_BASE=0x80000000
to:
CONFIG_KVM_GUEST:
!CAC_BASE:
CAC_BASE=0x40000000
CAC_BASE:
CAC_BASE=0x80000000
!CONFIG_KVM_GUEST:
(nothing)
Cheers
James
> #define CAC_BASE _AC(0x80000000, UL)
> #endif
> +#endif
> #ifndef IO_BASE
> #define IO_BASE _AC(0xa0000000, UL)
> #endif
> --
> 1.9.1
>
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] BdrvDirtyBitmap and bdrv_snapshot_goto
From: Kevin Wolf @ 2016-11-09 9:52 UTC (permalink / raw)
To: Vladimir Sementsov-Ogievskiy
Cc: Max Reitz, qemu-devel, qemu block, Fam Zheng, Denis V. Lunev,
John Snow
In-Reply-To: <a9c32ef6-eee7-4190-e444-3b2e7910b03d@virtuozzo.com>
Am 08.11.2016 um 17:48 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 08.11.2016 15:18, Kevin Wolf wrote:
> >Am 08.11.2016 um 12:08 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >>08.11.2016 14:05, Kevin Wolf wrote:
> >>>Am 07.11.2016 um 17:10 hat Max Reitz geschrieben:
> >>>>On 07.11.2016 16:24, Vladimir Sementsov-Ogievskiy wrote:
> >>>>>Hi all!
> >>>>>
> >>>>>As I can see, in bdrv_snapshot_goto, existing dirty bitmaps are not
> >>>>>handled.. Is it ok? Should not they be filled with ones or something
> >>>>>like this?
> >>>>Filling them with ones makes sense to me. I guess nobody noticed because
> >>>>nobody was crazy enough to use block jobs alongside loadvm...
> >>>What's the use case in which ones make sense?
> >>>
> >>>It rather seems to me that an active dirty bitmap and snapshot switching
> >>>should exclude each other because the bitmap becomes meaningless by the
> >>>switch. And chances are that after switching a snapshot you don't want
> >>>to "incrementally" backup everything, but that you should access a
> >>>different backup.
> >>In other words, dirty bitmaps should be deleted on snapshot switch?
> >>All? Or only named?
> >As Max said, we should probably integrate bitmaps with snapshots. After
> >reloading the old state, the bitmap becomes valid again, so throwing it
> >away in the active state seems only right if we included it in the
> >snapshot and can bring it back.
>
> If we choose this way, it should be firstly done for
> BdrvDirtyBitmap's without any persistance. And it is not as simple
> as just drop dirty bitmaps or fill them with ones. Current behavior
> is definitely wrong: if user create incremental backup after
> snapshot switch this incremental backup will be incorrect. I think
> it should be fixed now simpler way (actually this fix means "for now
> incremental backup is incompatible with snapshot switch"), and in
> future, if we really need this, make them work together.
>
> Also, I think that filling with ones is safer and more native. It
> really describes, what happens (with some overhead of dirty bits).
No, it doesn't. Loading a snapshot really means accessing a different
image, even if that different image is stored in the same file. So if
you load a snapshot and keep using the same bitmap, you're now using a
bitmap that describes a different image, and of course that's wrong.
But writing ones there is just as wrong. You're treating a changed
image the same way as if the same original image had been completely
overwritten. But that's not what happened.
We just need to take care that every bitmap is always used with the
image that it really describes. And if we can't get this right yet
across snapshot loads, we have to forbid using both together.
I suspect we also have a similar problem with removable media. Which
probably means that you can't use removable media and bitmaps together.
> Simple improvement: instead of filling with ones,
> new_dirty_bitmap_state = old_dirty_bitmap_state |
> old_allocated_mask | new_allocated_mask, where allocated mask is
> bitmap with same granularity, showing which ranges are allocated in
> the image.
Optimising an approach that doesn't make sense is a waste of time.
Kevin
^ permalink raw reply
* [Buildroot] [PATCH 1/4] configs: atmel: at91sam9260eknf: update defconfig
From: Alexandre Belloni @ 2016-11-09 9:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109073638.ozgbr5vy6gglznlx@tarshish>
On 09/11/2016 at 09:36:38 +0200, Baruch Siach wrote :
> Hi Ludovic,
>
> On Wed, Nov 09, 2016 at 07:59:45AM +0100, Ludovic Desroches wrote:
> > # Kernel
> > BR2_LINUX_KERNEL=y
> > -BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.9.1"
>
> For the sake of reproducibility you should set this to the version you tested,
> say, 4.8.6. The same goes for other patches in this series.
>
I'm not sure this is actually useful because the amount of testing is
minimal and it just increases the maintenance burden.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
From: Samuel Thibault @ 2016-11-09 9:52 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Peter Maydell, Michal Suchanek, QEMU Developers
In-Reply-To: <20161109104028.099af5f6.cornelia.huck@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 237 bytes --]
Hello,
Cornelia Huck, on Wed 09 Nov 2016 10:40:28 +0100, wrote:
> Still curses=no... log attached.
Oops, sorry, I misplaced my code, and it somehow worked in my case.
Could you give a try at the attached patch instead?
Thanks,
Samuel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1846 bytes --]
commit cc8965eb848f53599895a650a6e062319189be1f
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Tue Nov 8 20:57:27 2016 +0100
Fix cursesw detection
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
- curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+ curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw 2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+ IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+ if test "$curses_found" = yes ; then
+ break
+ fi
done
unset IFS
if test "$curses_found" = "yes" ; then
^ permalink raw reply related
* [Qemu-devel] [PATCH V10] fsdev: add IO throttle support to fsdev devices
From: Pradeep Jagadeesh @ 2016-11-09 9:50 UTC (permalink / raw)
To: Aneesh Kumar K.V, Greg Kurz
Cc: Pradeep Jagadeesh, Alberto Garcia, qemu-devel, Claudio Fontana
Uses throttling APIs to limit I/O bandwidth and number of operations on the
devices which use 9p-local driver.
Signed-off-by: Pradeep Jagadeesh <pradeep.jagadeesh@huawei.com>
---
fsdev/Makefile.objs | 2 +-
fsdev/file-op-9p.h | 3 ++
fsdev/qemu-fsdev-opts.c | 77 ++++++++++++++++++++++++++++-
fsdev/qemu-fsdev-throttle.c | 117 ++++++++++++++++++++++++++++++++++++++++++++
fsdev/qemu-fsdev-throttle.h | 39 +++++++++++++++
hw/9pfs/9p-local.c | 8 +++
hw/9pfs/9p.c | 5 ++
hw/9pfs/cofile.c | 2 +
8 files changed, 251 insertions(+), 2 deletions(-)
create mode 100644 fsdev/qemu-fsdev-throttle.c
create mode 100644 fsdev/qemu-fsdev-throttle.h
This adds the support for the 9p-local driver.
For now this functionality can be enabled only through qemu cli options.
QMP interface and support to other drivers need further extensions.
To make it simple for other drivers, the throttle code has been put in
separate files.
v1 -> v2:
-Fixed FsContext redeclaration issue
-Removed couple of function declarations from 9p-throttle.h
-Fixed some of the .help messages
v2 -> v3:
-Addressed follwing comments by Claudio Fontana
-Removed redundant memset calls in fsdev_throttle_configure_iolimits function
-Checking throttle structure validity before initializing other structures
in fsdev_throttle_configure_iolimits
-Addressed following comments by Greg Kurz
-Moved the code from 9pfs directory to fsdev directory, because the throttling
is for the fsdev devices.Renamed the files and functions to fsdev_ from 9pfs_
-Renamed throttling cli options to throttling.*, as in QMP cli options
-Removed some of the unwanted .h files from qemu-fsdev-throttle.[ch]
-Using throttle_enabled() function to set the thottle enabled flag for fsdev.
v3 -> v4:
-Addressed following comments by Alberto Garcia
-Removed the unwanted locking and other data structures in qemu-fsdev-throttle.[ch]
-Addressed following comments by Greg Kurz
-Removed fsdev_iolimitsenable/disable functions, instead using throttle_enabled function
v4 -> V5:
-Fixed the issue with the larger block size accounting.
(i.e, when the 9pfs mounted using msize=xxx option)
V5 -> V6:
-Addressed the comments by Alberto Garcia
-Removed the fsdev_throttle_timer_cb()
-Simplified the fsdev_throttle_schedule_next_request() as suggested
V6 -> V7:
-Addressed the comments by Alberto Garcia
-changed the fsdev_throttle_schedule_next_request() as suggested
v7 -> v8:
-Addressed comments by Alberto Garcia
-Fixed some indentation issues and split the configure_io_limit function
-Inlined throttle_timer_check code
V8 -> v9:
-Addressed the comments by Greg Kurz
-Inlined the fsdev_throttle_schedule_next_request() code into
fsdev_co_throttle_request ()
V9 -> V10:
-Addressed the comments by Alberto Garcia
-Fixed the indentation issues and minor issues
diff --git a/fsdev/Makefile.objs b/fsdev/Makefile.objs
index 1b120a4..659df6e 100644
--- a/fsdev/Makefile.objs
+++ b/fsdev/Makefile.objs
@@ -5,7 +5,7 @@ common-obj-y = qemu-fsdev.o 9p-marshal.o 9p-iov-marshal.o
else
common-obj-y = qemu-fsdev-dummy.o
endif
-common-obj-y += qemu-fsdev-opts.o
+common-obj-y += qemu-fsdev-opts.o qemu-fsdev-throttle.o
# Toplevel always builds this; targets without virtio will put it in
# common-obj-y
diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index 6db9fea..33fe822 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -17,6 +17,7 @@
#include <dirent.h>
#include <utime.h>
#include <sys/vfs.h>
+#include "qemu-fsdev-throttle.h"
#define SM_LOCAL_MODE_BITS 0600
#define SM_LOCAL_DIR_MODE_BITS 0700
@@ -74,6 +75,7 @@ typedef struct FsDriverEntry {
char *path;
int export_flags;
FileOperations *ops;
+ FsThrottle fst;
} FsDriverEntry;
typedef struct FsContext
@@ -83,6 +85,7 @@ typedef struct FsContext
int export_flags;
struct xattr_operations **xops;
struct extended_ops exops;
+ FsThrottle *fst;
/* fs driver specific data */
void *private;
} FsContext;
diff --git a/fsdev/qemu-fsdev-opts.c b/fsdev/qemu-fsdev-opts.c
index 1dd8c7a..385423f0 100644
--- a/fsdev/qemu-fsdev-opts.c
+++ b/fsdev/qemu-fsdev-opts.c
@@ -37,8 +37,83 @@ static QemuOptsList qemu_fsdev_opts = {
}, {
.name = "sock_fd",
.type = QEMU_OPT_NUMBER,
+ }, {
+ .name = "throttling.iops-total",
+ .type = QEMU_OPT_NUMBER,
+ .help = "limit total I/O operations per second",
+ }, {
+ .name = "throttling.iops-read",
+ .type = QEMU_OPT_NUMBER,
+ .help = "limit read operations per second",
+ }, {
+ .name = "throttling.iops-write",
+ .type = QEMU_OPT_NUMBER,
+ .help = "limit write operations per second",
+ }, {
+ .name = "throttling.bps-total",
+ .type = QEMU_OPT_NUMBER,
+ .help = "limit total bytes per second",
+ }, {
+ .name = "throttling.bps-read",
+ .type = QEMU_OPT_NUMBER,
+ .help = "limit read bytes per second",
+ }, {
+ .name = "throttling.bps-write",
+ .type = QEMU_OPT_NUMBER,
+ .help = "limit write bytes per second",
+ }, {
+ .name = "throttling.iops-total-max",
+ .type = QEMU_OPT_NUMBER,
+ .help = "I/O operations burst",
+ }, {
+ .name = "throttling.iops-read-max",
+ .type = QEMU_OPT_NUMBER,
+ .help = "I/O operations read burst",
+ }, {
+ .name = "throttling.iops-write-max",
+ .type = QEMU_OPT_NUMBER,
+ .help = "I/O operations write burst",
+ }, {
+ .name = "throttling.bps-total-max",
+ .type = QEMU_OPT_NUMBER,
+ .help = "total bytes burst",
+ }, {
+ .name = "throttling.bps-read-max",
+ .type = QEMU_OPT_NUMBER,
+ .help = "total bytes read burst",
+ }, {
+ .name = "throttling.bps-write-max",
+ .type = QEMU_OPT_NUMBER,
+ .help = "total bytes write burst",
+ }, {
+ .name = "throttling.iops-total-max-length",
+ .type = QEMU_OPT_NUMBER,
+ .help = "length of the iops-total-max burst period, in seconds",
+ }, {
+ .name = "throttling.iops-read-max-length",
+ .type = QEMU_OPT_NUMBER,
+ .help = "length of the iops-read-max burst period, in seconds",
+ }, {
+ .name = "throttling.iops-write-max-length",
+ .type = QEMU_OPT_NUMBER,
+ .help = "length of the iops-write-max burst period, in seconds",
+ }, {
+ .name = "throttling.bps-total-max-length",
+ .type = QEMU_OPT_NUMBER,
+ .help = "length of the bps-total-max burst period, in seconds",
+ }, {
+ .name = "throttling.bps-read-max-length",
+ .type = QEMU_OPT_NUMBER,
+ .help = "length of the bps-read-max burst period, in seconds",
+ }, {
+ .name = "throttling.bps-write-max-length",
+ .type = QEMU_OPT_NUMBER,
+ .help = "length of the bps-write-max burst period, in seconds",
+ }, {
+ .name = "throttling.iops-size",
+ .type = QEMU_OPT_NUMBER,
+ .help = "when limiting by iops max size of an I/O in bytes",
},
-
{ /*End of list */ }
},
};
diff --git a/fsdev/qemu-fsdev-throttle.c b/fsdev/qemu-fsdev-throttle.c
new file mode 100644
index 0000000..7f9fb3f
--- /dev/null
+++ b/fsdev/qemu-fsdev-throttle.c
@@ -0,0 +1,117 @@
+/*
+ * Fsdev Throttle
+ *
+ * Copyright (C) 2016 Huawei Technologies Duesseldorf GmbH
+ *
+ * Author: Pradeep Jagadeesh <pradeep.jagadeesh@huawei.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * (at your option) any later version.
+ *
+ * See the COPYING file in the top-level directory for details.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/error-report.h"
+#include "qemu-fsdev-throttle.h"
+#include "qemu/iov.h"
+
+static void fsdev_throttle_read_timer_cb(void *opaque)
+{
+ FsThrottle *fst = opaque;
+ qemu_co_enter_next(&fst->throttled_reqs[false]);
+}
+
+static void fsdev_throttle_write_timer_cb(void *opaque)
+{
+ FsThrottle *fst = opaque;
+ qemu_co_enter_next(&fst->throttled_reqs[true]);
+}
+
+void fsdev_throttle_parse_opts(QemuOpts *opts, FsThrottle *fst, Error **err)
+{
+ fst->cfg.buckets[THROTTLE_BPS_TOTAL].avg =
+ qemu_opt_get_number(opts, "throttling.bps-total", 0);
+ fst->cfg.buckets[THROTTLE_BPS_READ].avg =
+ qemu_opt_get_number(opts, "throttling.bps-read", 0);
+ fst->cfg.buckets[THROTTLE_BPS_WRITE].avg =
+ qemu_opt_get_number(opts, "throttling.bps-write", 0);
+ fst->cfg.buckets[THROTTLE_OPS_TOTAL].avg =
+ qemu_opt_get_number(opts, "throttling.iops-total", 0);
+ fst->cfg.buckets[THROTTLE_OPS_READ].avg =
+ qemu_opt_get_number(opts, "throttling.iops-read", 0);
+ fst->cfg.buckets[THROTTLE_OPS_WRITE].avg =
+ qemu_opt_get_number(opts, "throttling.iops-write", 0);
+
+ fst->cfg.buckets[THROTTLE_BPS_TOTAL].max =
+ qemu_opt_get_number(opts, "throttling.bps-total-max", 0);
+ fst->cfg.buckets[THROTTLE_BPS_READ].max =
+ qemu_opt_get_number(opts, "throttling.bps-read-max", 0);
+ fst->cfg.buckets[THROTTLE_BPS_WRITE].max =
+ qemu_opt_get_number(opts, "throttling.bps-write-max", 0);
+ fst->cfg.buckets[THROTTLE_OPS_TOTAL].max =
+ qemu_opt_get_number(opts, "throttling.iops-total-max", 0);
+ fst->cfg.buckets[THROTTLE_OPS_READ].max =
+ qemu_opt_get_number(opts, "throttling.iops-read-max", 0);
+ fst->cfg.buckets[THROTTLE_OPS_WRITE].max =
+ qemu_opt_get_number(opts, "throttling.iops-write-max", 0);
+
+ fst->cfg.buckets[THROTTLE_BPS_TOTAL].burst_length =
+ qemu_opt_get_number(opts, "throttling.bps-total-max-length", 1);
+ fst->cfg.buckets[THROTTLE_BPS_READ].burst_length =
+ qemu_opt_get_number(opts, "throttling.bps-read-max-length", 1);
+ fst->cfg.buckets[THROTTLE_BPS_WRITE].burst_length =
+ qemu_opt_get_number(opts, "throttling.bps-write-max-length", 1);
+ fst->cfg.buckets[THROTTLE_OPS_TOTAL].burst_length =
+ qemu_opt_get_number(opts, "throttling.iops-total-max-length", 1);
+ fst->cfg.buckets[THROTTLE_OPS_READ].burst_length =
+ qemu_opt_get_number(opts, "throttling.iops-read-max-length", 1);
+ fst->cfg.buckets[THROTTLE_OPS_WRITE].burst_length =
+ qemu_opt_get_number(opts, "throttling.iops-write-max-length", 1);
+ fst->cfg.op_size =
+ qemu_opt_get_number(opts, "throttling.iops-size", 0);
+
+ throttle_is_valid(&fst->cfg, err);
+}
+
+void fsdev_throttle_init(FsThrottle *fst)
+{
+ if (throttle_enabled(&fst->cfg)) {
+ throttle_init(&fst->ts);
+ throttle_timers_init(&fst->tt,
+ qemu_get_aio_context(),
+ QEMU_CLOCK_REALTIME,
+ fsdev_throttle_read_timer_cb,
+ fsdev_throttle_write_timer_cb,
+ fst);
+ throttle_config(&fst->ts, &fst->tt, &fst->cfg);
+ qemu_co_queue_init(&fst->throttled_reqs[0]);
+ qemu_co_queue_init(&fst->throttled_reqs[1]);
+ }
+}
+
+void coroutine_fn fsdev_co_throttle_request(FsThrottle *fst, bool is_write,
+ struct iovec *iov, int iovcnt)
+{
+ if (throttle_enabled(&fst->cfg)) {
+ if (throttle_schedule_timer(&fst->ts, &fst->tt, is_write) ||
+ !qemu_co_queue_empty(&fst->throttled_reqs[is_write])) {
+ qemu_co_queue_wait(&fst->throttled_reqs[is_write]);
+ }
+
+ throttle_account(&fst->ts, is_write, iov_size(iov, iovcnt));
+
+ if (!qemu_co_queue_empty(&fst->throttled_reqs[is_write]) &&
+ !throttle_schedule_timer(&fst->ts, &fst->tt, is_write)) {
+ qemu_co_queue_next(&fst->throttled_reqs[is_write]);
+ }
+ }
+}
+
+void fsdev_throttle_cleanup(FsThrottle *fst)
+{
+ if (throttle_enabled(&fst->cfg)) {
+ throttle_timers_destroy(&fst->tt);
+ }
+}
diff --git a/fsdev/qemu-fsdev-throttle.h b/fsdev/qemu-fsdev-throttle.h
new file mode 100644
index 0000000..e418643
--- /dev/null
+++ b/fsdev/qemu-fsdev-throttle.h
@@ -0,0 +1,39 @@
+/*
+ * Fsdev Throttle
+ *
+ * Copyright (C) 2016 Huawei Technologies Duesseldorf GmbH
+ *
+ * Author: Pradeep Jagadeesh <pradeep.jagadeesh@huawei.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * (at your option) any later version.
+ *
+ * See the COPYING file in the top-level directory for details.
+ *
+ */
+
+#ifndef _FSDEV_THROTTLE_H
+#define _FSDEV_THROTTLE_H
+
+#include "block/aio.h"
+#include "qemu/main-loop.h"
+#include "qemu/coroutine.h"
+#include "qapi/error.h"
+#include "qemu/throttle.h"
+
+typedef struct FsThrottle {
+ ThrottleState ts;
+ ThrottleTimers tt;
+ ThrottleConfig cfg;
+ CoQueue throttled_reqs[2];
+} FsThrottle;
+
+void fsdev_throttle_parse_opts(QemuOpts *, FsThrottle *, Error **);
+
+void fsdev_throttle_init(FsThrottle *);
+
+void coroutine_fn fsdev_co_throttle_request(FsThrottle *, bool ,
+ struct iovec *, int);
+
+void fsdev_throttle_cleanup(FsThrottle *);
+#endif /* _FSDEV_THROTTLE_H */
diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index 845675e..828348d 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -1209,6 +1209,7 @@ static int local_parse_opts(QemuOpts *opts, struct FsDriverEntry *fse)
{
const char *sec_model = qemu_opt_get(opts, "security_model");
const char *path = qemu_opt_get(opts, "path");
+ Error *err = NULL;
if (!sec_model) {
error_report("Security model not specified, local fs needs security model");
@@ -1237,6 +1238,13 @@ static int local_parse_opts(QemuOpts *opts, struct FsDriverEntry *fse)
error_report("fsdev: No path specified");
return -1;
}
+
+ fsdev_throttle_parse_opts(opts, &fse->fst, &err);
+ if (err) {
+ error_reportf_err(err, "Throttle configuration is not valid: ");
+ return -1;
+ }
+
fse->path = g_strdup(path);
return 0;
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index e88cf25..8d46a91 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3506,6 +3506,10 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp)
error_setg(errp, "share path %s is not a directory", fse->path);
goto out;
}
+
+ s->ctx.fst = &fse->fst;
+ fsdev_throttle_init(s->ctx.fst);
+
v9fs_path_free(&path);
rc = 0;
@@ -3520,6 +3524,7 @@ out:
void v9fs_device_unrealize_common(V9fsState *s, Error **errp)
{
+ fsdev_throttle_cleanup(s->ctx.fst);
g_free(s->ctx.fs_root);
g_free(s->tag);
}
diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c
index 120e267..88791bc 100644
--- a/hw/9pfs/cofile.c
+++ b/hw/9pfs/cofile.c
@@ -247,6 +247,7 @@ int coroutine_fn v9fs_co_pwritev(V9fsPDU *pdu, V9fsFidState *fidp,
if (v9fs_request_cancelled(pdu)) {
return -EINTR;
}
+ fsdev_co_throttle_request(s->ctx.fst, true, iov, iovcnt);
v9fs_co_run_in_worker(
{
err = s->ops->pwritev(&s->ctx, &fidp->fs, iov, iovcnt, offset);
@@ -266,6 +267,7 @@ int coroutine_fn v9fs_co_preadv(V9fsPDU *pdu, V9fsFidState *fidp,
if (v9fs_request_cancelled(pdu)) {
return -EINTR;
}
+ fsdev_co_throttle_request(s->ctx.fst, false, iov, iovcnt);
v9fs_co_run_in_worker(
{
err = s->ops->preadv(&s->ctx, &fidp->fs, iov, iovcnt, offset);
--
1.8.3.1
^ permalink raw reply related
* [Buildroot] [PATCH] valgrind: do not use host mpicc
From: Jérôme Pouiller @ 2016-11-09 9:51 UTC (permalink / raw)
To: buildroot
Valgrind may use 'mpicc' (from openmi project) to compile libmpiwrap-*.so.
Without any option, it will detect and use 'mpicc' from host and generate
libmpiwrap-*.so for host:
$ file target/usr/lib/valgrind/libmpiwrap-arm-linux.so
target/usr/lib/valgrind/libmpiwrap-arm-linux.so: ELF 64-bit LSB shared object,
x86-64, version 1 (SYSV), dynamically linked, not stripped
We simply disable openmi support for valgrind.
Signed-off-by: J?r?me Pouiller <jezz@sysmic.org>
---
package/valgrind/valgrind.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/valgrind/valgrind.mk b/package/valgrind/valgrind.mk
index 09f7116..c7ac2a1 100644
--- a/package/valgrind/valgrind.mk
+++ b/package/valgrind/valgrind.mk
@@ -15,6 +15,8 @@ VALGRIND_INSTALL_STAGING = YES
# patch 0004-Fixes-for-musl-libc.patch touching configure.ac
VALGRIND_AUTORECONF = YES
+VALGRIND_CONF_OPTS += --without-mpicc
+
# When Valgrind detects a 32-bit MIPS architecture, it forcibly adds
# -march=mips32 to CFLAGS; when it detects a 64-bit MIPS architecture,
# it forcibly adds -march=mips64. This causes Valgrind to be built
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Gabriel Fernandez @ 2016-11-09 9:51 UTC (permalink / raw)
To: Radosław Pietrzyk
Cc: Mark Rutland, devicetree, Daniel Thompson, Alexandre Torgue,
Arnd Bergmann, Nicolas Pitre, Andrea Merello, linux-kernel,
Michael Turquette, olivier.bideau, Stephen Boyd, Russell King,
amelie.delaunay, Rob Herring, linux-arm-kernel, Maxime Coquelin,
linux-clk, ludovic.barre, kernel
In-Reply-To: <CAFvLkMSUg8=nYY9Zm2Q4ZW=GqUaczK_TA5b5jjb45vYyhoVLZA@mail.gmail.com>
On 11/09/2016 09:10 AM, Radosław Pietrzyk wrote:
> I would expect that VCO clock will force recalculation for all its
> children if I am not mistaken.
Sure
BR
Gabriel.
>
> 2016-11-08 17:19 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>> On 11/08/2016 09:52 AM, Radosław Pietrzyk wrote:
>>> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>>>> Hi Radosław
>>>>
>>>> Many thanks for reviewing.
>>>>
>>>> On 11/07/2016 03:57 PM, Radosław Pietrzyk wrote:
>>>>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>>>>> + const char *parent_name, unsigned long flags,
>>>>>> + void __iomem *reg, u8 shift, u8 width,
>>>>>> + u8 clk_divider_flags, const struct clk_div_table
>>>>>> *table,
>>>>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>>>>> +{
>>>>>> + struct stm32f4_pll_div *pll_div;
>>>>>> + struct clk_hw *hw;
>>>>>> + struct clk_init_data init;
>>>>>> + int ret;
>>>>>> +
>>>>>> + /* allocate the divider */
>>>>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>>>>> + if (!pll_div)
>>>>>> + return ERR_PTR(-ENOMEM);
>>>>>> +
>>>>>> + init.name = name;
>>>>>> + init.ops = &stm32f4_pll_div_ops;
>>>>>> + init.flags = flags;
>>>>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>>>>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>>>>> divider ops.
>>>> I don't want to offer the possibility to change the vco clock through the
>>>> divisor of the pll (only by a boot-loader or by DT).
>>>>
>>>> e.g. if i make a set rate on lcd-tft clock, i don't want to change the
>>>> SAI
>>>> frequencies.
>>>>
>>>> I used same structure for internal divisors of the pll (p, q, r) and for
>>>> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
>>>> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>>>>
>>>> These divisors are similar because we have to switch off the pll before
>>>> changing the rate.
>>>>
>>> But changing pll and lcd dividers only may not be enough for getting
>>> very specific pixelclocks and that might require changing the VCO
>>> frequency itself. The rest of the SAI tree should be recalculated
>>> then.
>> I agree but it seems to be too much complicated to recalculate all PLL
>> divisors if we change the vco clock.
>> You mean to use Clock notifier callback ?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Gabriel Fernandez @ 2016-11-09 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFvLkMSUg8=nYY9Zm2Q4ZW=GqUaczK_TA5b5jjb45vYyhoVLZA@mail.gmail.com>
On 11/09/2016 09:10 AM, Rados?aw Pietrzyk wrote:
> I would expect that VCO clock will force recalculation for all its
> children if I am not mistaken.
Sure
BR
Gabriel.
>
> 2016-11-08 17:19 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>> On 11/08/2016 09:52 AM, Rados?aw Pietrzyk wrote:
>>> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>>>> Hi Rados?aw
>>>>
>>>> Many thanks for reviewing.
>>>>
>>>> On 11/07/2016 03:57 PM, Rados?aw Pietrzyk wrote:
>>>>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>>>>> + const char *parent_name, unsigned long flags,
>>>>>> + void __iomem *reg, u8 shift, u8 width,
>>>>>> + u8 clk_divider_flags, const struct clk_div_table
>>>>>> *table,
>>>>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>>>>> +{
>>>>>> + struct stm32f4_pll_div *pll_div;
>>>>>> + struct clk_hw *hw;
>>>>>> + struct clk_init_data init;
>>>>>> + int ret;
>>>>>> +
>>>>>> + /* allocate the divider */
>>>>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>>>>> + if (!pll_div)
>>>>>> + return ERR_PTR(-ENOMEM);
>>>>>> +
>>>>>> + init.name = name;
>>>>>> + init.ops = &stm32f4_pll_div_ops;
>>>>>> + init.flags = flags;
>>>>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>>>>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>>>>> divider ops.
>>>> I don't want to offer the possibility to change the vco clock through the
>>>> divisor of the pll (only by a boot-loader or by DT).
>>>>
>>>> e.g. if i make a set rate on lcd-tft clock, i don't want to change the
>>>> SAI
>>>> frequencies.
>>>>
>>>> I used same structure for internal divisors of the pll (p, q, r) and for
>>>> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
>>>> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>>>>
>>>> These divisors are similar because we have to switch off the pll before
>>>> changing the rate.
>>>>
>>> But changing pll and lcd dividers only may not be enough for getting
>>> very specific pixelclocks and that might require changing the VCO
>>> frequency itself. The rest of the SAI tree should be recalculated
>>> then.
>> I agree but it seems to be too much complicated to recalculate all PLL
>> divisors if we change the vco clock.
>> You mean to use Clock notifier callback ?
^ permalink raw reply
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Gabriel Fernandez @ 2016-11-09 9:51 UTC (permalink / raw)
To: Radosław Pietrzyk
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, Daniel Thompson, Andrea Merello, devicetree,
amelie.delaunay, kernel, olivier.bideau, linux-kernel, linux-clk,
ludovic.barre, linux-arm-kernel
In-Reply-To: <CAFvLkMSUg8=nYY9Zm2Q4ZW=GqUaczK_TA5b5jjb45vYyhoVLZA@mail.gmail.com>
On 11/09/2016 09:10 AM, Radosław Pietrzyk wrote:
> I would expect that VCO clock will force recalculation for all its
> children if I am not mistaken.
Sure
BR
Gabriel.
>
> 2016-11-08 17:19 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>> On 11/08/2016 09:52 AM, Radosław Pietrzyk wrote:
>>> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
>>>> Hi Radosław
>>>>
>>>> Many thanks for reviewing.
>>>>
>>>> On 11/07/2016 03:57 PM, Radosław Pietrzyk wrote:
>>>>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>>>>> + const char *parent_name, unsigned long flags,
>>>>>> + void __iomem *reg, u8 shift, u8 width,
>>>>>> + u8 clk_divider_flags, const struct clk_div_table
>>>>>> *table,
>>>>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>>>>> +{
>>>>>> + struct stm32f4_pll_div *pll_div;
>>>>>> + struct clk_hw *hw;
>>>>>> + struct clk_init_data init;
>>>>>> + int ret;
>>>>>> +
>>>>>> + /* allocate the divider */
>>>>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>>>>> + if (!pll_div)
>>>>>> + return ERR_PTR(-ENOMEM);
>>>>>> +
>>>>>> + init.name = name;
>>>>>> + init.ops = &stm32f4_pll_div_ops;
>>>>>> + init.flags = flags;
>>>>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>>>>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>>>>> divider ops.
>>>> I don't want to offer the possibility to change the vco clock through the
>>>> divisor of the pll (only by a boot-loader or by DT).
>>>>
>>>> e.g. if i make a set rate on lcd-tft clock, i don't want to change the
>>>> SAI
>>>> frequencies.
>>>>
>>>> I used same structure for internal divisors of the pll (p, q, r) and for
>>>> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
>>>> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>>>>
>>>> These divisors are similar because we have to switch off the pll before
>>>> changing the rate.
>>>>
>>> But changing pll and lcd dividers only may not be enough for getting
>>> very specific pixelclocks and that might require changing the VCO
>>> frequency itself. The rest of the SAI tree should be recalculated
>>> then.
>> I agree but it seems to be too much complicated to recalculate all PLL
>> divisors if we change the vco clock.
>> You mean to use Clock notifier callback ?
^ permalink raw reply
* [PATCH] sparc32: Fix inverted invalid_frame_pointer checks on sigreturns
From: Andreas Larsson @ 2016-11-09 9:43 UTC (permalink / raw)
To: David Miller, sparclinux; +Cc: Sam Ravnborg, linux-kernel, software
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
---
arch/sparc/kernel/signal_32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/kernel/signal_32.c b/arch/sparc/kernel/signal_32.c
index c3c12ef..9c0c8fd 100644
--- a/arch/sparc/kernel/signal_32.c
+++ b/arch/sparc/kernel/signal_32.c
@@ -89,7 +89,7 @@ asmlinkage void do_sigreturn(struct pt_regs *regs)
sf = (struct signal_frame __user *) regs->u_regs[UREG_FP];
/* 1. Make sure we are not getting garbage from the user */
- if (!invalid_frame_pointer(sf, sizeof(*sf)))
+ if (invalid_frame_pointer(sf, sizeof(*sf)))
goto segv_and_exit;
if (get_user(ufp, &sf->info.si_regs.u_regs[UREG_FP]))
@@ -150,7 +150,7 @@ asmlinkage void do_rt_sigreturn(struct pt_regs *regs)
synchronize_user_stack();
sf = (struct rt_signal_frame __user *) regs->u_regs[UREG_FP];
- if (!invalid_frame_pointer(sf, sizeof(*sf)))
+ if (invalid_frame_pointer(sf, sizeof(*sf)))
goto segv;
if (get_user(ufp, &sf->regs.u_regs[UREG_FP]))
--
2.8.0
^ permalink raw reply related
* Re: symbol addresses are wrong when kcore is used
From: Adrian Hunter @ 2016-11-09 9:44 UTC (permalink / raw)
To: David Ahern, Perf Users, Arnaldo Carvalho de Melo, Jiri Olsa,
Namhyung Kim
In-Reply-To: <7ab497c9-7b56-1fa2-2c7d-98f2199df993@gmail.com>
On 08/11/16 18:54, David Ahern wrote:
> Hi guys:
>
> I have been meaning to ask about this for 2 years now: perf script shows the wrong addresses when /proc/kcore is referenced. Here's an example with perf from net-next tree (4.9-rc3):
>
> $ perf record -a -g -e fib6:* -- sleep 5
>
> $ perf script
> vhost-7489 7491 [018] 2314.004488: fib6:fib6_table_lookup: table 255 oif 0 iif 4 src 2100:1::3 dst ff02::1:ff00:64 tos 0 scope 0 flags 0 ==> dev br1 gw ::
> 7fff8155f49e ip6_pol_route+0x80007f00249e ([kernel.kallsyms])
> 7fff8155f77a ip6_pol_route_input+0x80007f00201a ([kernel.kallsyms])
> 7fff81588515 fib6_rule_action+0x80007f0020c5 ([kernel.kallsyms])
> 7fff814c2676 fib_rules_lookup+0x80007f002116 ([kernel.kallsyms])
> 7fff815886b9 fib6_rule_lookup+0x80007f002059 ([kernel.kallsyms])
> 7fff8155c77e ip6_route_input_lookup+0x80007f00204e ([kernel.kallsyms])
> 7fff81560a98 ip6_route_input+0x80007f0020d8 ([kernel.kallsyms])
> 7fff81550a92 ip6_rcv_finish+0x80007f002082 ([kernel.kallsyms])
> 7fff81551344 ipv6_rcv+0x80007f002334 ([kernel.kallsyms])
>
> The 7fff addresses are completely wrong. If I compile perf and disable use of kcore:
>
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index aecff69a510d..0debd7e96aa2 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1285,7 +1285,7 @@ int __dso__load_kallsyms(struct dso *dso, const char *filename,
> int dso__load_kallsyms(struct dso *dso, const char *filename,
> struct map *map)
> {
> - return __dso__load_kallsyms(dso, filename, map, false);
> + return __dso__load_kallsyms(dso, filename, map, true);
> }
>
> static int dso__load_perf_map(struct dso *dso, struct map *map)
>
>
> Then the addresses are correct:
>
> vhost-7489 7491 [018] 2314.004488: fib6:fib6_table_lookup: table 255 oif 0 iif 4 src 2100:1::3 dst ff02::1:ff00:64 tos 0 scope 0 flags 0 ==> dev br1 gw ::
> ffffffff8155d49e ip6_pol_route+0x49e ([kernel.kallsyms])
> ffffffff8155d77a ip6_pol_route_input+0x1a ([kernel.kallsyms])
> ffffffff81586515 fib6_rule_action+0xc5 ([kernel.kallsyms])
> ffffffff814c0676 fib_rules_lookup+0x116 ([kernel.kallsyms])
> ffffffff815866b9 fib6_rule_lookup+0x59 ([kernel.kallsyms])
> ffffffff8155a77e ip6_route_input_lookup+0x4e ([kernel.kallsyms])
> ffffffff8155ea98 ip6_route_input+0xd8 ([kernel.kallsyms])
> ffffffff8154ea92 ip6_rcv_finish+0x82 ([kernel.kallsyms])
> ffffffff8154f344 ipv6_rcv+0x334 ([kernel.kallsyms])
>
>
> Or if I cat kallsyms into a file and pass it to perf it works:
>
> $ cat /proc/kallsyms > /tmp/kallsyms
> $ perf script --kallsyms /tmp/kallsyms
>
> vhost-7489 7491 [018] 2314.004488: fib6:fib6_table_lookup: table 255 oif 0 iif 4 src 2100:1::3 dst ff02::1:ff00:64 tos 0 scope 0 flags 0 ==> dev br1 gw ::
> ffffffff8155d49e ip6_pol_route+0x49e ([kernel.kallsyms])
> ffffffff8155d77a ip6_pol_route_input+0x1a ([kernel.kallsyms])
> ffffffff81586515 fib6_rule_action+0xc5 ([kernel.kallsyms])
> ffffffff814c0676 fib_rules_lookup+0x116 ([kernel.kallsyms])
> ffffffff815866b9 fib6_rule_lookup+0x59 ([kernel.kallsyms])
> ffffffff8155a77e ip6_route_input_lookup+0x4e ([kernel.kallsyms])
> ffffffff8155ea98 ip6_route_input+0xd8 ([kernel.kallsyms])
> ffffffff8154ea92 ip6_rcv_finish+0x82 ([kernel.kallsyms])
> ffffffff8154f344 ipv6_rcv+0x334 ([kernel.kallsyms])
>
> So there is something fundamentally wrong with the use of /proc/kcore.
>
> Adrian: I seem to recall you added support for kcore. Any ideas on why the addresses are wrong?
I took a quick look at the kcore code and it seemed to make sense. Whereas
the problem seems to be related to callchains.
perf works with MMAP events that map memory addresses to file offsets. So a
memory address is passed to thread__find_addr_map() and you get back a file
offset in al.addr.
perf adjusts symbols if necessary so that they are also file offsets. So
perf can use al.addr to find the symbol.
I don't know why, but there seems to be some confusion in the callchain
code. If you look at add_callchain_ip(), it is putting al.addr into the
callchain node. However if you look at sample__fprintf_callchain() it seems
to expect the callchain node to contain a memory address and it maps it again.
Other callchain consumers like fill_callchain_info() also seem to expect the
callchain node to contain a memory address, and also map it again.
Note, in cases where the maps are identity maps (e.g. kallsyms only) then
the problem would be hidden.
At least that is what I think is happening. Maybe someone else can comment.
^ permalink raw reply
* [Buildroot] [PATCH] patchelf: bump version to 0.9
From: Baruch Siach @ 2016-11-09 9:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109094346.5839-1-jezz@sysmic.org>
Hi J?r?me,
On Wed, Nov 09, 2016 at 10:43:46AM +0100, J?r?me Pouiller wrote:
> -PATCHELF_VERSION = 0.8
> -PATCHELF_SITE = http://releases.nixos.org/patchelf/patchelf-0.8
> +PATCHELF_VERSION = 0.9
> +PATCHELF_SITE = http://releases.nixos.org/patchelf/patchelf-0.9
Unrelated to this patch, but SITE should be
http://releases.nixos.org/patchelf/patchelf-$(PATCHELF_VERSION). And while at
it we can also move to .tar.bz2 file to save some space.
> PATCHELF_LICENSE = GPLv3+
> PATCHELF_LICENSE_FILES = COPYING
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.