From: Daniel Wagner
Since the -Wincompatible-pointer-types is reported as error, alpha
doesn't build anymore. Let's fix it in a minimal way.
fs/binfmt_em86.c:73:35: error: passing argument 2 of ‘copy_strings_kernel’ from
incompatible pointer type [-Werror=incompatible-pointer-types]
> All errors (new ones prefixed by >>):
>
>fs/binfmt_em86.c: In function 'load_em86':
>>> fs/binfmt_em86.c:73:35: error: passing argument 2 of 'copy_strings_kernel'
>>> from incompatible pointer type [-Werror=incompatible-pointer-types]
> retval = copy_strings_kernel(1, &i_arg, bprm);
>
> Hmmm, Ok. I've been running the lockperf test and kernel builds all
> day on a filesystem that is identical in shape and size to yours
> (i.e. xfs_info output is the same) but I haven't reproduced it yet.
I don't know if that is important: I run the lockperf test and after
they have finished I d
> posix03 and posix04 just emit error messages:
>
> posix04 -n 40 -l 100
> posix04: invalid option -- 'l'
> posix04: Usage: posix04 [-i iterations] [-n nr_children] [-s]
> .
I screwed that this up. I have patched my version of lockperf to make
all test using the same options names. Though fo
> via my test script:
Looks like my email client did not agree with my formatting of the script.
https://www.monom.org/data/lglock/run-tests.sh
>> Anything in the log before this?
>
> Just the usual stuff, as I remember. Sorry, I haven't copied the whole log.
Just triggered it again. My steps for it are:
- run all lockperf test
git://git.samba.org/jlayton/lockperf.git
via my test script:
#!/bin/sh
On 06/01/2016 09:10 AM, Dave Chinner wrote:
> On Wed, Jun 01, 2016 at 07:52:31AM +0200, Daniel Wagner wrote:
>> I got the error message below while compiling a kernel
>> on that system. I can't really say if I did something
>> which made the file system unhappy before
Hi,
I got the error message below while compiling a kernel
on that system. I can't really say if I did something
which made the file system unhappy before the crash.
[Jun 1 07:41] XFS (sde1): Internal error xfs_trans_cancel at line 984 of file
fs/xfs/xfs_trans.c. Caller xfs_rename+0x453/0x960
[Sorry for the late response. I was a few days on holiday]
On 05/16/2016 10:38 PM, Luiz Capitulino wrote:
> On Thu, 12 May 2016 16:08:34 +0200
> Daniel Wagner wrote:
>
>> In short, I haven't figured out yet why the kernel builds get slightly
>> slower.
>
>
On 04/28/2016 02:57 PM, Daniel Wagner wrote:
> As one can see above in the swait_stat output, the fork() path is
> using completion. A histogram of a fork bomp (1000 forks) benchmark
> shows a slight performance drop by 4%.
>
> [wagi@handman completion-test-5 (master)]$ cat fork
From: Daniel Wagner
Instead proving its own arch_local_irq_save() and arch_irqs_disabled()
version use the generic version from asm-generic/irqflags.h.
A nice side effect is that um gets a few additional arch_ functions
as well.
One problem though is the include for the signals. I could
On 04/28/2016 02:57 PM, Daniel Wagner wrote:
> Only one complete_all() user could been identified so far, which happens
> to be drivers/base/power/main.c. Several waiters appear when suspend
> to disk or mem is executed.
BTW, this is what I get when doing a 'echo "disk" &g
From: Daniel Wagner
Completions have no long lasting callbacks and therefore do not need
the complex waitqueue variant. Use simple waitqueues which reduces
the contention on the waitqueue lock.
This was a carry forward from v3.10-rt, with some RT specific chunks,
dropped, and updated to align
From: Daniel Wagner
complete_all() should only be called once, doing it twice is a clear bug.
8565adbc8214 ("drivers/misc/ti-st: fix read fw version cmd") added the
additional complete_all() call. Since we call complete_all() when
leaving the function we can drop the complete_all() c
On 03/29/2016 09:22 AM, Jan Kiszka wrote:
> No problem. At least we now know another frequent user.
Let's say sometimes :)
> BTW, Kieran and some other people at Linaro started to think about how
> to auto-test for such regressions - probably the only reliable way to
> catch them.
Good idea. I a
On 03/28/2016 08:57 PM, Steven Rostedt wrote:
> On Wed, 9 Mar 2016 13:24:23 +0100
> Sebastian Andrzej Siewior wrote:
>
>> * Josh Cartwright | 2016-03-08 12:26:56 [-0600]:
>>
>>> Is it really just about latency? Does this deferral not lead to an
>>> inversion in the case where the single woken ta
Hi Namhyung,
On 03/29/2016 05:17 PM, Namhyung Kim wrote:
> On Tue, Mar 29, 2016 at 12:01:40PM +0200, Daniel Wagner wrote:
>> cat /sys/kernel/debug/tracing/events/test/latency_complete/hist
>> # event histogram
>> #
>> # trigger info:
>> hist:keys=latency.log2:val
On 03/30/2016 05:21 PM, Peter Zijlstra wrote:
> On Wed, Mar 30, 2016 at 05:17:29PM +0200, Sebastian Andrzej Siewior wrote:
>> On 03/30/2016 05:07 PM, Peter Zijlstra wrote:
>>> On Wed, Mar 30, 2016 at 04:53:05PM +0200, Daniel Wagner wrote:
>>>> From: Daniel Wagner
From: Daniel Wagner
Hi,
To avoid a size increase of struct completion, I spitted the done
field into two half.
add/remove: 3/0 grow/shrink: 3/10 up/down: 242/-236 (6)
function old new delta
swake_up_all_locked- 181
From: Daniel Wagner
Completions have no long lasting callbacks and therefore do not need
the complex waitqueue variant. Use simple waitqueues which reduces
the contention on the waitqueue lock.
This was a carry forward from v3.10-rt, with some RT specific chunks,
dropped, and updated to align
Hi,
On 03/03/2016 07:55 PM, Tom Zanussi wrote:
> When using '.log2' modifier, the output looks like:
>
> # echo 'hist:key=bytes_req.log2' > kmalloc/trigger
> # cat kmalloc/hist
>
> { bytes_req: ~ 2^12 } hitcount: 1
> { bytes_req: ~ 2^11 } hitcount: 1
> { bytes_req: ~
On 03/29/2016 08:59 AM, Jan Kiszka wrote:
> On 2016-03-29 08:41, Daniel Wagner wrote:
>> for module in module_list():
>> gdb.write("{address} {name:<19} {size:>8} {ref}".format(
>> -address
From: Daniel Wagner
The module_core symbols is not available due to
7523e4dc5057 ("module: use a structure to encapsulate layout.")
The base address of the module is now stored inside
struct module_layout.
Signed-off-by: Daniel Wagner
Cc: Jiri Kosina
Cc: Rusty Russell
---
Obvio
From: Daniel Wagner
The module_core symbols is not available due to
7523e4dc5057 ("module: use a structure to encapsulate layout.")
The base address of the module is now stored inside
struct module_layout.
Signed-off-by: Daniel Wagner
Cc: Jiri Kosina
Cc: Rusty Russell
---
s
Hi,
On 03/16/2016 12:58 AM, Stephen Rothwell wrote:
> After merging the kbuild tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/gma500/mdfld_dsi_output.c:407:39: error: initialization from
> incompatible pointer type [-Werror=incompatible-pointer-types
On 03/08/2016 06:52 PM, Sebastian Andrzej Siewior wrote:
> However I don't think if your DEFER flag solution is all that bad. I
> have also the block-mq in -RT using swait and they perform wakes with
> irqs-off. Not in -RT but mainline. So me might need something to make it
> work properly. But if
From: Daniel Wagner
Hi,
As Peter correctly pointed out in [1] a simple conversion from
wait to swait in completion.c wont work. I played a bit around and
came up with this rather ugly idea.
So in case complete_all() is called in hard irq context we just wake
up one waiter and let that one call
From: Daniel Wagner
Completions have no long lasting callbacks and therefore do not need
the complex waitqueue variant. Use simple waitqueues which reduces
the contention on the waitqueue lock.
This was a carry forward from v3.10-rt, with some RT specific chunks,
dropped, and updated to align
>
> this path set switches bpf hash map to use pre-allocation by default
> and introduces BPF_F_NO_PREALLOC flag to keep old behavior for cases
> where full map pre-allocation is too memory expensive.
>
> Some time back Daniel Wagner reported crashes when bpf hash map is
>
From: Daniel Wagner
With the introduction of the simple wait API we have two very
similar APIs in the kernel. For example wake_up() and swake_up()
is only one character away. Although the compiler will warn
happily the wrong usage it keeps on going an even links the kernel.
Thomas and Peter
On 03/05/2016 02:54 PM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>> as we have this in Makefile:
>>
>> # enforce correct pointer usage
>> KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types)
>
> Sorry, never mind - this is a recent commit that is not upstream.
>
> So
Commit-ID: 065bb78c5b09df54d1c32e03227deb777ddff57b
Gitweb: http://git.kernel.org/tip/065bb78c5b09df54d1c32e03227deb777ddff57b
Author: Daniel Wagner
AuthorDate: Fri, 19 Feb 2016 09:46:40 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 25 Feb 2016 11:27:16 +0100
rcu: Do not call
Commit-ID: ef50c046338948df9f23fb5ef853efda0274c7b3
Gitweb: http://git.kernel.org/tip/ef50c046338948df9f23fb5ef853efda0274c7b3
Author: Daniel Wagner
AuthorDate: Fri, 19 Feb 2016 09:46:38 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 25 Feb 2016 11:27:16 +0100
kbuild: Add option to
allbacks.
With the removal of custom callbacks, we can use a raw lock for
queue list manipulations, hence allowing the simple wait support
to be used in -rt.
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Originally-by: Thomas Gleixner
Cc: Paul Gortmaker
[Patch is from PeterZ
From: Daniel Wagner
rcu_nocb_gp_cleanup() is called while holding rnp->lock. Currently,
this is okay because the wake_up_all() in rcu_nocb_gp_cleanup() will
not enable the IRQs. lockdep is happy.
By switching over using swait this is not true anymore. swake_up_all()
enables the IRQs wh
From: Daniel Wagner
With the introduction of the simple wait API we have two very
similar APIs in the kernel. For example wake_up() and swake_up()
is only one character away. Although the compiler will warn
happily the wrong usage it keeps on going an even links the kernel.
Thomas and Peter
the swait implementation found in the -rt
tree. Daniel ported it to mainline's version and gathered the
benchmark numbers for tscdeadline_latency test.]
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Cc: Marcelo Tosatti
Cc: Paolo Bonzini
---
arch/arm/kvm/arm.c
From: Daniel Wagner
Hi,
This version of the series got some compile time. I tried
to weed out the incompatible-pointer-types warning in mainline.
In the last verison I included two patches to fix those warnings.
In the meantime these patches are either already in mainline
or on the way. I found
rd of work from v3.10-rt; the original conversion
was by Thomas on an earlier -rt version, and Sebastian extended it to
additional post-3.10 added RCU waiters; here I've added a commit log and
unified the RCU changes into one, and uprev'd it to match mainline RCU.
Signed-off-by: Danie
compatible-pointer-types]
.dpms = /*drm_helper_connector_dpms*/mdfld_dsi_connector_dpms,
^
Signed-off-by: Daniel Wagner
---
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/
On 02/07/2016 05:39 AM, Paul Gortmaker wrote:
>> I used the cross compiler version 5.2.1 shipped by Fedora 23
>> and run allyesconfig/allmodconfig for ARM, ARM64, MIPS64, PPC64
>> (swait-v7 and 4.5-rc2). No new errors popped up.
>
> SOunds good ; guess my gut feeling about this causing more fallou
tval = copy_strings_kernel(1, &i_name, bprm);
While at it, check the remove_arg_zero return value too.
fs/binfmt_em86.c:68:2: warning: ignoring return value of ‘remove_arg_zero’,
declared with attribute warn_unused_result [-Wunused-result]
remove_arg_zero(bprm);
^
Signed-off-by: Daniel Wagner
The static clang and also gcc knows this attributes and they
are used to do thread safety analysis.
Signed-off-by: Daniel Wagner
Link: http://clang.llvm.org/docs/ThreadSafetyAnalysis.html
---
allocate.c | 1 +
allocate.h | 1 +
parse.c| 64
Add the function context attributes and the context instruction
to the model.
Signed-off-by: Daniel Wagner
---
ast-inspect.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/ast-inspect.c b/ast-inspect.c
index 24d4a4a..4502575 100644
--- a/ast
1)
validation/caps.c:70:8: warning: leaks lock 'global_lock'
frame: ep 0x7f0af437e100 wtf_lock
frame: ep 0x7f0af437e1f0 bad4 (call wtf_lock, global_lock)
Signed-off-by: Daniel Wagner
---
Makefile |3 +-
lib.c |2 +
lib.h
Signed-off-by: Daniel Wagner
---
linearize.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linearize.c b/linearize.c
index c6ada1e..da3a190 100644
--- a/linearize.c
+++ b/linearize.c
@@ -441,7 +441,7 @@ const char *show_instruction(struct instruction *insn
merged.
cheers,
daniel
Daniel Wagner (5):
parse: Add comment to struct statement
inspect: Show context information
linearize: Add context symbol name when showing context instructions
parse: Add acquire, release, requires and guarded_by attributes
test-locks: Add lock tester
Makefile
All the other members of the union got a nice comment
what they represent. Let's fix for context as well.
Signed-off-by: Daniel Wagner
---
parse.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse.h b/parse.h
index 0c34ec2..195f0fd 100644
--- a/parse.h
+++ b/pa
On 02/16/2016 02:14 PM, Tomi Valkeinen wrote:
>
> On 09/02/16 11:18, Daniel Wagner wrote:
>> As the function name already indicates that get_opt_bool() parses
>> for a bool. It is not a surprise that compiler is complaining
>> about it when -Werror=incompatib
Hi Maciej,
The missing typeof(*(hdr)) is back in this version. I wonder why
I didn't see the warning by gcc with v4.
cheers,
daniel
Daniel Wagner (2):
crash_dump: Add vmcore_elf32_check_arch
mips: Differentiate between 32 and 64 bit ELF header
arch/mips/include/asm/elf.h
use it also in binfm_elf?32.c as well.
Signed-off-by: Daniel Wagner
Suggested-by: Maciej W. Rozycki
Reviewed-by: Maciej W. Rozycki
Reported-by: Fengguang Wu
---
arch/mips/include/asm/elf.h | 13 +
arch/mips/kernel/binfmt_elfn32.c | 4 ++--
arch/mips/kernel/binfmt_elfo32.c |
archs to overwrite it.
Signed-off-by: Daniel Wagner
Suggested-by: Maciej W. Rozycki
Reviewed-by: Maciej W. Rozycki
---
fs/proc/vmcore.c | 2 +-
include/linux/crash_dump.h | 8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
On 02/11/2016 01:04 PM, Maciej W. Rozycki wrote:
> On Thu, 11 Feb 2016, Ralf Baechle wrote:
>> Thanks, applied.
>>
>> I'm getting a less spectacular warning from gcc 5.2:
>>
>> CC fs/proc/vmcore.o
>> fs/proc/vmcore.c: In function ‘parse_crash_elf64_headers’:
>> fs/proc/vmcore.c:939:47: warni
tval = copy_strings_kernel(1, &i_name, bprm);
While at it, check the remove_arg_zero return value too.
fs/binfmt_em86.c:68:2: warning: ignoring return value of ‘remove_arg_zero’,
declared with attribute warn_unused_result [-Wunused-result]
remove_arg_zero(bprm);
^
Signed-off-by: Daniel Wagner
archs to overwrite it.
Signed-off-by: Daniel Wagner
Suggested-by: Maciej W. Rozycki
Reviewed-by: Maciej W. Rozycki
---
fs/proc/vmcore.c | 2 +-
include/linux/crash_dump.h | 8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
Hi Maciej,
I did test compile a few different configurations and with and without
mrproper upfront. All looks fine now. Let's see what still goes wrong :)
cheers,
daniel
Daniel Wagner (2):
crash_dump: Add vmcore_elf32_check_arch
mips: Differentiate between 32 and 64 bit ELF header
use it also in binfm_elf?32.c as well.
Signed-off-by: Daniel Wagner
Suggested-by: Maciej W. Rozycki
Reviewed-by: Maciej W. Rozycki
Reported-by: Fengguang Wu
---
arch/mips/include/asm/elf.h | 9 +++--
arch/mips/kernel/binfmt_elfn32.c | 2 +-
arch/mips/kernel/binfmt_elfo32.c | 2 +-
On 02/09/2016 03:51 PM, Maciej W. Rozycki wrote:
> On Tue, 9 Feb 2016, Daniel Wagner wrote:
>
>>> Can you try `make mrproper' (stash away your .config) and see if the
>>> problem goes away?
>>
>> Indeed, 'make mrproper' did the trick. I am s
On 02/09/2016 08:44 PM, Maciej W. Rozycki wrote:
> On Tue, 9 Feb 2016, Daniel Wagner wrote:
>
>>> FWIW I think all the MIPS ABI flags stuff also needs to go outside the
>>> conditional, because it's ABI agnostic. I'll make the right change myself
>>
On 02/09/2016 01:32 PM, Maciej W. Rozycki wrote:
> FWIW I think all the MIPS ABI flags stuff also needs to go outside the
> conditional, because it's ABI agnostic. I'll make the right change myself
> on top of your fixes. It'll remove a little bit of code duplication,
> which is always welcom
On 02/09/2016 12:46 PM, Maciej W. Rozycki wrote:
> On Tue, 9 Feb 2016, Daniel Wagner wrote:
>
>> Also I looked at the cpp output and saw that there was no uapi/asm/auxvec.h
>> included instead it pulls arch/mips/include/generated/uapi/asm/auxvec.h
>
> Hmm, did you upda
:353:39: error: passing argument 3 of
‘get_opt_bool’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
if (get_opt_bool(this_opt, "accel", &accel))
Signed-off-by: Daniel Wagner
Reported-by: Fengguang Wu
---
[resend because Maik's emial address bounced las
> https://github.com/0day-ci/linux/commits/Daniel-Wagner/Differentiate-between-32-and-64-bit-ELF-header/20160208-234759
> config: mips-fuloong2e_defconfig (attached as .config)
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain
Good Morning,
On 02/08/2016 06:19 PM, Maciej W. Rozycki wrote:
> On Mon, 8 Feb 2016, Daniel Wagner wrote:
>
>> The generic auxvec.h is used instead the arch specific version.
>> This happens when cross compiling the kernel.
>>
>> mips64-linux-gnu-gcc (GCC) 5.2.1 2
use it also in binfm_elf?32.c as well.
Signed-off-by: Daniel Wagner
Suggested-by: Maciej W. Rozycki
Reported-by: Fengguang Wu
---
arch/mips/include/asm/elf.h | 9 +++--
arch/mips/kernel/binfmt_elfn32.c | 2 +-
arch/mips/kernel/binfmt_elfo32.c | 2 +-
3 files changed, 9 insertions(+), 4 de
:222:26: note: in definition of macro
‘NEW_AUX_ENT’
elf_info[ei_index++] = id; \
^
arch/mips/kernel/../../../fs/binfmt_elf.c:233:2: note: in expansion of macro
‘ARCH_DLINFO’
ARCH_DLINFO;
^
Signed-off-by: Daniel Wagner
---
arch/mips/include/asm/auxvec.h | 1 +
1
.
cheers,
daniel
Daniel Wagner (3):
mips: Use arch specific auxvec.h instead of generic-asm version
crash_dump: Add vmcore_elf32_check_arch
mips: Differentiate between 32 and 64 bit ELF header
arch/mips/include/asm/auxvec.h | 1 +
arch/mips/include/asm/elf.h | 9 +++--
arch/mips
archs to overwrite it.
Signed-off-by: Daniel Wagner
Suggested-by: Maciej W. Rozycki
---
fs/proc/vmcore.c | 2 +-
include/linux/crash_dump.h | 8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 4e61388..c8ed209 100644
---
On 02/01/2016 07:49 AM, Daniel Wagner wrote:
> On 01/29/2016 07:55 PM, Paul Gortmaker wrote:
>> [Re: [PATCH tip v6 2/5] kbuild: Add option to turn incompatible pointer
>> check into error] On 29/01/2016 (Fri 13:17) Daniel Wagner wrote:
>>
>>> On 01/28/2016
On 02/01/2016 01:52 AM, Maciej W. Rozycki wrote:
> On Fri, 29 Jan 2016, Daniel Wagner wrote:
>
>> Depending on the configuration either the 32 or 64 bit version of
>> elf_check_arch() is defined. parse_crash_elf32_headers() does
>> some basic verification of the ELF h
On 01/29/2016 07:55 PM, Paul Gortmaker wrote:
> [Re: [PATCH tip v6 2/5] kbuild: Add option to turn incompatible pointer check
> into error] On 29/01/2016 (Fri 13:17) Daniel Wagner wrote:
>
>> On 01/28/2016 03:44 PM, Daniel Wagner wrote:
>>> +# enforce correct pointer
:353:39: error: passing argument 3 of
‘get_opt_bool’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
if (get_opt_bool(this_opt, "accel", &accel))
Signed-off-by: Daniel Wagner
Reported-by: Fengguang Wu
---
drivers/video/fbdev/intelfb/intelfbdrv.c | 2 +-
1 f
allbacks.
With the removal of custom callbacks, we can use a raw lock for
queue list manipulations, hence allowing the simple wait support
to be used in -rt.
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Originally-by: Thomas Gleixner
Cc: Paul Gortmaker
[Patch is from PeterZ
^
fs/proc/vmcore.c:1015:4: note: in expansion of macro
'vmcore_elf64_check_arch'
!vmcore_elf64_check_arch(&ehdr) ||
^
Since the MIPS ELF header for 32 bit and 64 bit differ we need
to check accordingly.
Signed-off-by: Daniel Wagner
Reported-by: Fengg
v1: https://lwn.net/Articles/656942/
v0: https://lwn.net/Articles/653586/
Daniel Wagner (4):
video: Use bool instead int pointer for get_opt_bool() argument
MIPS: Differentiate between 32 and 64 bit ELF header
kbuild: Add option to turn incompatible pointer check into error
rcu: Do
ate_on_node+0x260/0x260
[] ret_from_fork+0x3f/0x70
[] ? kthread_create_on_node+0x260/0x260
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Cc: "Paul E. McKenney"
Cc: Thomas Gleixner
---
kernel/rcu/tree.c| 4 +++-
kernel/rcu/tree.h| 3 +
the swait implementation found in the -rt
tree. Daniel ported it to mainline's version and gathered the
benchmark numbers for tscdeadline_latency test.]
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Cc: Marcelo Tosatti
Cc: Paolo Bonzini
---
arch/arm/kvm/arm.c
rd of work from v3.10-rt; the original conversion
was by Thomas on an earlier -rt version, and Sebastian extended it to
additional post-3.10 added RCU waiters; here I've added a commit log and
unified the RCU changes into one, and uprev'd it to match mainline RCU.
Signed-off-by: Danie
is to turn the pointer type check into an error which
catches wrong type uses. Obviously not only the swait/wait ones. That
isn't a bad thing either.
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Cc: Thomas Gleixner
---
Makefile | 3 +++
1 file changed, 3 insertions(+)
dif
^
fs/proc/vmcore.c:1015:4: note: in expansion of macro
'vmcore_elf64_check_arch'
!vmcore_elf64_check_arch(&ehdr) ||
^
Since the MIPS ELF header for 32 bit and 64 bit differ we need
to check accordingly.
Signed-off-by: Daniel Wagner
Reported-by: Fe
:353:39: error: passing argument 3 of
‘get_opt_bool’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
if (get_opt_bool(this_opt, "accel", &accel))
Signed-off-by: Daniel Wagner
Reported-by: Fengguang Wu
---
Hi,
In the 'simple wait queue support'
On 01/28/2016 03:44 PM, Daniel Wagner wrote:
> +# enforce correct pointer usage
> +KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types)
> +
As it turns out there are a few fallouts by that one. I'll send fixes
for it.
I missed one to fixup for ARM. I'll send an update.
ate_on_node+0x260/0x260
[] ret_from_fork+0x3f/0x70
[] ? kthread_create_on_node+0x260/0x260
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Cc: "Paul E. McKenney"
Cc: Thomas Gleixner
---
kernel/rcu/tree.c| 4 +++-
kernel/rcu/tree.h| 3 +
rd of work from v3.10-rt; the original conversion
was by Thomas on an earlier -rt version, and Sebastian extended it to
additional post-3.10 added RCU waiters; here I've added a commit log and
unified the RCU changes into one, and uprev'd it to match mainline RCU.
Signed-off-by: Danie
the swait implementation found in the -rt
tree. Daniel ported it to mainline's version and gathered the
benchmark numbers for tscdeadline_latency test.]
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Cc: Marcelo Tosatti
Cc: Paolo Bonzini
---
arch/arm/kvm/arm.c
allbacks.
With the removal of custom callbacks, we can use a raw lock for
queue list manipulations, hence allowing the simple wait support
to be used in -rt.
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Originally-by: Thomas Gleixner
Cc: Paul Gortmaker
[Patch is from PeterZ
656942/
v0: https://lwn.net/Articles/653586/
Daniel Wagner (2):
kbuild: Add option to turn incompatible pointer check into error
rcu: Do not call rcu_nocb_gp_cleanup() while holding rnp->lock
Marcelo Tosatti (1):
KVM: use simple waitqueue for vcpu->wq
Paul Gortmaker (1):
rcu: use si
is to turn the pointer type check into an error which
catches wrong type uses. Obviously not only the swait/wait ones. That
isn't a bad thing either.
Signed-off-by: Daniel Wagner
Acked-by: Peter Zijlstra (Intel)
Cc: Thomas Gleixner
---
Makefile | 3 +++
1 file changed, 3 insertions(+)
dif
On 12/18/2015 02:50 PM, pi3orama wrote:
>> Could it be that $(srcdir) somehow is not correct? I exchanged
>>
>>feature_dir := $(srctree)/tools/build/feature
>> to
>>feature_dir := /home/wagi/src/linux/tools/build/feature
>>
>
> Can you remember the patch set I skipped?
>
> http://lkml.ker
On 12/18/2015 12:03 PM, Wangnan (F) wrote:
> That's good. This is not a magic.
That is what you say! :)
> I guess something in your top makefile
> causes this feature check failure. I sent a patch on feature checker to
> you.
> It will appear as [1] soon. Could you please apply it and try again?
On 12/18/2015 04:04 AM, Wangnan (F) wrote:
> On 2015/12/17 21:46, Daniel Wagner wrote:
>> On 12/17/2015 11:09 AM, Wangnan (F) wrote:
>>> On 2015/12/17 16:29, Daniel Wagner wrote:
>>>> On 12/17/2015 08:03 AM, Daniel Wagner wrote:
>>>> Patch number 2 d
On 12/17/2015 11:09 AM, Wangnan (F) wrote:
> On 2015/12/17 16:29, Daniel Wagner wrote:
>> On 12/17/2015 08:03 AM, Daniel Wagner wrote:
>> Patch number 2 didn't apply cleanly.
>
> Because I have another patch in my local tree which also modifis bpf
> Makefile:
On 12/17/2015 08:03 AM, Daniel Wagner wrote:
> On 12/17/2015 07:51 AM, Wangnan (F) wrote:
>> On 2015/12/17 14:38, Daniel Wagner wrote:
>>> On 12/17/2015 06:23 AM, Wang Nan wrote:
>>>> Since we already have libbpf in tools/lib, we don't need to maintain
>
On 12/17/2015 07:51 AM, Wangnan (F) wrote:
> On 2015/12/17 14:38, Daniel Wagner wrote:
>> On 12/17/2015 06:23 AM, Wang Nan wrote:
>>> Since we already have libbpf in tools/lib, we don't need to maintain
>>> another bpf loader and operations library in
Hi,
On 12/17/2015 06:23 AM, Wang Nan wrote:
> Since we already have libbpf in tools/lib, we don't need to maintain
> another bpf loader and operations library in samples/bpf.
>
> In patchset:
>
> Patch 1/10 - 7/10 improves libbpf, add missing features to support
> samples,
>
> Patch 8/10 add
tates
mean. Thanks Paul for providing them.
Signed-off-by: Daniel Wagner
Reviewed-by: "Paul E. McKenney"
Cc: Thomas Gleixner
Cc: Peter Zijlstra
---
v3:
- initialize cpu_hotplug_state correctly. Bug found by l...@intel.com
arch/x86/xen/smp.c | 4 +--
include/linux/cpu.h | 3 +-
k
Hi Tejun,
On 12/01/2015 05:44 PM, Tejun Heo wrote:
> On Tue, Dec 01, 2015 at 08:02:23AM +0100, Daniel Wagner wrote:
>> I was not able to verify if these two patches are fixing it. I don't see
>> the call trace on mainline only when using cgroup/review-xt_cgroup2
>>
Hi Tejun,
On 11/30/2015 11:44 PM, Tejun Heo wrote:
> WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97
> pids_cancel.constprop.6+0x31/0x40()
> Modules linked in:
> CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #29
> ...
> 81f65382 88007c043b90 81551ffc 0
Hi Paul,
On 11/30/2015 06:38 PM, Paul E. McKenney wrote:
On Mon, Nov 30, 2015 at 04:26:03PM +0100, Daniel Wagner wrote:
On 11/30/2015 02:38 PM, Daniel Wagner wrote:
With the introduction of the simple wait API we have two very
similar APIs in the kernel. For example wake_up() and swake_up
401 - 500 of 735 matches
Mail list logo
