[for-next][PATCH 16/33] ftrace: Convert the rest of the function trigger over to the mapping functions

From: "Steven Rostedt (VMware)" As the data pointer for individual ips will soon be removed and no longer passed to the callback function probe handlers, convert the rest of the function trigger counters over to the new ftrace_func_mapper helper functions. Signed-off-by:

[for-next][PATCH 16/33] ftrace: Convert the rest of the function trigger over to the mapping functions

From: "Steven Rostedt (VMware)" As the data pointer for individual ips will soon be removed and no longer passed to the callback function probe handlers, convert the rest of the function trigger counters over to the new ftrace_func_mapper helper functions. Signed-off-by: Steven Rostedt (VMware)

[for-next][PATCH 10/33] ftrace: Move the probe function into the tracing directory

From: "Steven Rostedt (VMware)" As nothing outside the tracing directory uses the function probes mechanism, I'm moving the prototypes out of the include/linux/ftrace.h and into the local kernel/trace/trace.h header. I plan on making them hook to the trace_array structure

[for-next][PATCH 10/33] ftrace: Move the probe function into the tracing directory

From: "Steven Rostedt (VMware)" As nothing outside the tracing directory uses the function probes mechanism, I'm moving the prototypes out of the include/linux/ftrace.h and into the local kernel/trace/trace.h header. I plan on making them hook to the trace_array structure which is local to

[for-next][PATCH 12/33] ftrace: Remove unused "flags" field from struct ftrace_func_probe

From: "Steven Rostedt (VMware)" Nothing uses "flags" in the ftrace_func_probe descriptor. Remove it. Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/ftrace.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/trace/ftrace.c

[for-next][PATCH 12/33] ftrace: Remove unused "flags" field from struct ftrace_func_probe

From: "Steven Rostedt (VMware)" Nothing uses "flags" in the ftrace_func_probe descriptor. Remove it. Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/ftrace.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index

[for-next][PATCH 28/33] ftrace: Dynamically create the probe ftrace_ops for the trace_array

From: "Steven Rostedt (VMware)" In order to eventually have each trace_array instance have its own unique set of function probes (triggers), the trace array needs to hold the ops and the filters for the probes. This is the first step to accomplish this. Instead of having

[for-next][PATCH 28/33] ftrace: Dynamically create the probe ftrace_ops for the trace_array

From: "Steven Rostedt (VMware)" In order to eventually have each trace_array instance have its own unique set of function probes (triggers), the trace array needs to hold the ops and the filters for the probes. This is the first step to accomplish this. Instead of having the private data of the

[for-next][PATCH 04/33] ftrace: Add function-fork trace option

From: Namhyung Kim The function-fork option is same as event-fork that it tracks task fork/exit and set the pid filter properly. This can be useful if user wants to trace selected tasks including their children only. Link:

[for-next][PATCH 31/33] tracing/ftrace: Enable snapshot function trigger to work with instances

From: "Steven Rostedt (VMware)" Modify the snapshot probe trigger to work with instances. This way the snapshot function trigger will only affect the instance that it is added to in the set_ftrace_filter file. Signed-off-by: Steven Rostedt (VMware) ---

[for-next][PATCH 17/33] ftrace: Remove unused unregister_ftrace_function_probe() function

From: "Steven Rostedt (VMware)" Nothing calls unregister_ftrace_function_probe(). Remove it as well as the flag PROBE_TEST_DATA, as this function was the only one to set it. Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/ftrace.c | 18

[for-next][PATCH 04/33] ftrace: Add function-fork trace option

From: Namhyung Kim The function-fork option is same as event-fork that it tracks task fork/exit and set the pid filter properly. This can be useful if user wants to trace selected tasks including their children only. Link: http://lkml.kernel.org/r/20170417024430.21194-3-namhy...@kernel.org

[for-next][PATCH 31/33] tracing/ftrace: Enable snapshot function trigger to work with instances

From: "Steven Rostedt (VMware)" Modify the snapshot probe trigger to work with instances. This way the snapshot function trigger will only affect the instance that it is added to in the set_ftrace_filter file. Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/trace.c | 44

[for-next][PATCH 17/33] ftrace: Remove unused unregister_ftrace_function_probe() function

From: "Steven Rostedt (VMware)" Nothing calls unregister_ftrace_function_probe(). Remove it as well as the flag PROBE_TEST_DATA, as this function was the only one to set it. Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/ftrace.c | 18 +++--- kernel/trace/trace.h | 3

[for-next][PATCH 03/33] tracing: Have the trace_event benchmark thread call cond_resched_rcu_qs()

From: "Steven Rostedt (VMware)" The trace_event benchmark thread runs in kernel space in an infinite loop while also calling cond_resched() in case anything else wants to schedule in. Unfortunately, on a PREEMPT kernel, that makes it a nop, in which case, this will never

[for-next][PATCH 03/33] tracing: Have the trace_event benchmark thread call cond_resched_rcu_qs()

From: "Steven Rostedt (VMware)" The trace_event benchmark thread runs in kernel space in an infinite loop while also calling cond_resched() in case anything else wants to schedule in. Unfortunately, on a PREEMPT kernel, that makes it a nop, in which case, this will never voluntarily schedule.

[for-next][PATCH 00/33] tracing: More updates for 4.12

The biggest change is the rewrite of the function probe trigger code. I need to make a few enhancements on that code and it was basically created with a hack on top of an hack, and I didn't want to add more hacks. Instead, I gutted it and rewrote it in a way that the patch series is still

[for-next][PATCH 00/33] tracing: More updates for 4.12

The biggest change is the rewrite of the function probe trigger code. I need to make a few enhancements on that code and it was basically created with a hack on top of an hack, and I didn't want to add more hacks. Instead, I gutted it and rewrote it in a way that the patch series is still

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

On Fri, Apr 21, 2017 at 2:27 PM, James Bottomley wrote: > On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote: >> On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers >> wrote: >> > > > Of course, having extra checks behind a debug option is

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

On Fri, Apr 21, 2017 at 2:27 PM, James Bottomley wrote: > On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote: >> On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers >> wrote: >> > > > Of course, having extra checks behind a debug option is fine. >> > > > But they should not be part of the base

Re: [PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}() helpers

On Friday, April 21, 2017 05:46:45 PM Andy Shevchenko wrote: > Recently introduced helpers take pointers to uuid_{be|le} instead of > reference. > > Using them makes code less ugly. > > Cc: "Rafael J. Wysocki" > Signed-off-by: Andy Shevchenko

Re: [PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}() helpers

On Friday, April 21, 2017 05:46:45 PM Andy Shevchenko wrote: > Recently introduced helpers take pointers to uuid_{be|le} instead of > reference. > > Using them makes code less ugly. > > Cc: "Rafael J. Wysocki" > Signed-off-by: Andy Shevchenko > --- > drivers/acpi/acpi_extlog.c | 2 +- >

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote: > On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers > wrote: > > > > Of course, having extra checks behind a debug option is fine. > > > > But they should not be part of the base feature; the base > > > > feature should

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote: > On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers > wrote: > > > > Of course, having extra checks behind a debug option is fine. > > > > But they should not be part of the base feature; the base > > > > feature should just be mitigation of

[PATCH] macsec: avoid heap overflow in skb_to_sgvec

While this may appear as a humdrum one line change, it's actually quite important. An sk_buff stores data in three places: 1. A linear chunk of allocated memory in skb->data. This is the easiest one to work with, but it precludes using scatterdata since the memory must be linear. 2. The

[PATCH] macsec: avoid heap overflow in skb_to_sgvec

While this may appear as a humdrum one line change, it's actually quite important. An sk_buff stores data in three places: 1. A linear chunk of allocated memory in skb->data. This is the easiest one to work with, but it precludes using scatterdata since the memory must be linear. 2. The

Re: [PATCH v3] fpga manager: Add Altera CvP driver

On 4/20/2017 12:29 PM, matthew.gerl...@linux.intel.com wrote: On Thu, 20 Apr 2017, Anatolij Gustschin wrote: Add FPGA manager driver for loading Arria/Cyclone/Stratix FPGAs via CvP. Signed-off-by: Anatolij Gustschin --- Hi Anatolij, Since you say the driver works with

Re: [PATCH v3] fpga manager: Add Altera CvP driver

On 4/20/2017 12:29 PM, matthew.gerl...@linux.intel.com wrote: On Thu, 20 Apr 2017, Anatolij Gustschin wrote: Add FPGA manager driver for loading Arria/Cyclone/Stratix FPGAs via CvP. Signed-off-by: Anatolij Gustschin --- Hi Anatolij, Since you say the driver works with Arria-10, I

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Fri, Apr 21, 2017 at 1:55 PM, Arnd Bergmann wrote: > On Thu, Apr 20, 2017 at 9:52 PM, Kees Cook wrote: >> On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann wrote: >>> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook wrote:

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Fri, Apr 21, 2017 at 1:55 PM, Arnd Bergmann wrote: > On Thu, Apr 20, 2017 at 9:52 PM, Kees Cook wrote: >> On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann wrote: >>> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook wrote: >> The original gcc-4.3 release was in early 2008. If we decide to still

Re: linux-next: manual merge of the pm tree with the arm-soc tree

On 4/21/17 2:31 AM, Arnd Bergmann wrote: On Fri, Apr 21, 2017 at 8:39 AM, santosh.shilim...@oracle.com wrote: On 4/20/17 10:53 PM, Arnd Bergmann wrote: On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell wrote: Hi all, Today's

Re: linux-next: manual merge of the pm tree with the arm-soc tree

On 4/21/17 2:31 AM, Arnd Bergmann wrote: On Fri, Apr 21, 2017 at 8:39 AM, santosh.shilim...@oracle.com wrote: On 4/20/17 10:53 PM, Arnd Bergmann wrote: On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the pm tree got a conflict in:

[PATCH] platform/x86: INT33FE: add I2C dependency

When I2C is disabled, we get a link error: drivers/platform/built-in.o: In function `cht_int33fe_remove': intel_cht_int33fe.c:(.text+0x8ba): undefined reference to `i2c_unregister_device' drivers/platform/built-in.o: In function `cht_int33fe_probe': intel_cht_int33fe.c:(.text+0x9ec): undefined

[PATCH] platform/x86: INT33FE: add I2C dependency

When I2C is disabled, we get a link error: drivers/platform/built-in.o: In function `cht_int33fe_remove': intel_cht_int33fe.c:(.text+0x8ba): undefined reference to `i2c_unregister_device' drivers/platform/built-in.o: In function `cht_int33fe_probe': intel_cht_int33fe.c:(.text+0x9ec): undefined

[PATCH] staging: rtl8723bs: rework debug configuration handling

I ran into this warning during randconfig testing: drivers/staging/rtl8723bs/os_dep/rtw_proc.c: In function 'rtw_adapter_proc_deinit': drivers/staging/rtl8723bs/os_dep/rtw_proc.c:738:25: error: unused variable 'drv_proc' [-Werror=unused-variable] drivers/staging/rtl8723bs/os_dep/rtw_proc.c: In

[PATCH] staging: rtl8723bs: rework debug configuration handling

I ran into this warning during randconfig testing: drivers/staging/rtl8723bs/os_dep/rtw_proc.c: In function 'rtw_adapter_proc_deinit': drivers/staging/rtl8723bs/os_dep/rtw_proc.c:738:25: error: unused variable 'drv_proc' [-Werror=unused-variable] drivers/staging/rtl8723bs/os_dep/rtw_proc.c: In

Re: [RFC PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__

On Sat, 2017-04-22 at 04:03 +0900, Masahiro Yamada wrote: > Kbuild works in objtree, not in srctree. So, __FILE__ is prefixed > with $(srctree)/ for out-of-tree build. > > It would be nice to see the same log regardless > in-tree, or out-of-tree build. > > 1/2 adds a new macro KBUILD_FILE.

Re: [RFC PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__

On Sat, 2017-04-22 at 04:03 +0900, Masahiro Yamada wrote: > Kbuild works in objtree, not in srctree. So, __FILE__ is prefixed > with $(srctree)/ for out-of-tree build. > > It would be nice to see the same log regardless > in-tree, or out-of-tree build. > > 1/2 adds a new macro KBUILD_FILE.

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Thu, Apr 20, 2017 at 9:52 PM, Kees Cook wrote: > On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann wrote: >> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook wrote: > The original gcc-4.3 release was in early 2008. If we decide to still

Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

On Thu, Apr 20, 2017 at 9:52 PM, Kees Cook wrote: > On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann wrote: >> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook wrote: > The original gcc-4.3 release was in early 2008. If we decide to still > support that, we probably want the first 10 quirks in

[GIT PULL] 4.11 nfsd bugfix

Please pull git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.11-2 Fix a 4.11 regression that triggers a BUG() on an attempt to use an unsupported NFSv4 compound op. (Apologies for what's probably a last-minute fix. I was hoping to have a few more ready to roll up with it, but they'll

[GIT PULL] 4.11 nfsd bugfix

Please pull git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.11-2 Fix a 4.11 regression that triggers a BUG() on an attempt to use an unsupported NFSv4 compound op. (Apologies for what's probably a last-minute fix. I was hoping to have a few more ready to roll up with it, but they'll

Re: Heads-up: two regressions in v4.11-rc series

On Fri, Apr 21, 2017 at 10:52:29AM -0700, Linus Torvalds wrote: > On Thu, Apr 20, 2017 at 7:30 AM, Mel Gorman > wrote: > >> The end result was a revert, and this is waiting in AKPMs quilt queue: > >> > >>

Re: Heads-up: two regressions in v4.11-rc series

On Fri, Apr 21, 2017 at 10:52:29AM -0700, Linus Torvalds wrote: > On Thu, Apr 20, 2017 at 7:30 AM, Mel Gorman > wrote: > >> The end result was a revert, and this is waiting in AKPMs quilt queue: > >> > >>

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers wrote: > Hi Elena, > > On Fri, Apr 21, 2017 at 10:55:29AM +, Reshetova, Elena wrote: >> > >> > At the very least, what is there now could probably be made about twice as >> > fast >> > by removing the checks that don't

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers wrote: > Hi Elena, > > On Fri, Apr 21, 2017 at 10:55:29AM +, Reshetova, Elena wrote: >> > >> > At the very least, what is there now could probably be made about twice as >> > fast >> > by removing the checks that don't actually help mitigate

Re: [PATCH v1 1/1] srcu-cbmc: Use /usr/bin/awk instead of /bin/awk

On Sat, Apr 22, 2017 at 10:17:11AM -0700, priyalee.kushw...@intel.com wrote: > From: Priyalee Kushwaha > > Most OS distribution have awk in /usr/bin not in /bin > Without this patch, kernel-devsrc fails to build as > runtime dependency for srcu-cbmc script /bin/awk

Re: [PATCH v1 1/1] srcu-cbmc: Use /usr/bin/awk instead of /bin/awk

On Sat, Apr 22, 2017 at 10:17:11AM -0700, priyalee.kushw...@intel.com wrote: > From: Priyalee Kushwaha > > Most OS distribution have awk in /usr/bin not in /bin > Without this patch, kernel-devsrc fails to build as > runtime dependency for srcu-cbmc script /bin/awk is > not found. Adding Lance

Re: [PATCH v2 03/16] fpga: mgr: API change to replace fpga load functions with single function

On Thu, Apr 20, 2017 at 9:09 AM, Alan Tull wrote: > @@ -382,7 +377,13 @@ static int fpga_region_notify_pre_apply(struct > fpga_region *region, > if (of_property_read_bool(nd->overlay, "encrypted-fpga-config")) > info->flags |=

Re: [PATCH v2 03/16] fpga: mgr: API change to replace fpga load functions with single function

On Thu, Apr 20, 2017 at 9:09 AM, Alan Tull wrote: > @@ -382,7 +377,13 @@ static int fpga_region_notify_pre_apply(struct > fpga_region *region, > if (of_property_read_bool(nd->overlay, "encrypted-fpga-config")) > info->flags |= FPGA_MGR_ENCRYPTED_BITSTREAM; > > -

Re: [PATCH net] ip6mr: fix notification device destruction

From: Nikolay Aleksandrov Date: Fri, 21 Apr 2017 22:56:26 +0300 > On 21/04/17 22:50, Nikolay Aleksandrov wrote: >> On 21/04/17 22:36, David Miller wrote: >>> From: Nikolay Aleksandrov >>> Date: Fri, 21 Apr 2017 21:30:42 +0300 >>> On

Re: [PATCH net] ip6mr: fix notification device destruction

From: Nikolay Aleksandrov Date: Fri, 21 Apr 2017 22:56:26 +0300 > On 21/04/17 22:50, Nikolay Aleksandrov wrote: >> On 21/04/17 22:36, David Miller wrote: >>> From: Nikolay Aleksandrov >>> Date: Fri, 21 Apr 2017 21:30:42 +0300 >>> On 21/04/17 20:42, Nikolay Aleksandrov wrote: > Andrey

[GIT] Networking

1) Don't race in IPSEC dumps, from Yuejie Shi. 2) Verify lengths properly in IPSEC reqeusts, from Herbert Xu. 3) Fix out of bounds access in ipv6 segment routing code, from David Lebrun. 4) Don't write into the header of cloned SKBs in smsc95xx driver, from James Hughes. 5) Several

Re: [PATCH net] ip6mr: fix notification device destruction

On 21/04/17 22:50, Nikolay Aleksandrov wrote: > On 21/04/17 22:36, David Miller wrote: >> From: Nikolay Aleksandrov >> Date: Fri, 21 Apr 2017 21:30:42 +0300 >> >>> On 21/04/17 20:42, Nikolay Aleksandrov wrote: Andrey Konovalov reported a BUG caused by the ip6mr

Re: [PATCH net] ip6mr: fix notification device destruction

From: Nikolay Aleksandrov Date: Fri, 21 Apr 2017 22:50:35 +0300 > On 21/04/17 22:36, David Miller wrote: >> From: Nikolay Aleksandrov >> Date: Fri, 21 Apr 2017 21:30:42 +0300 >> >>> On 21/04/17 20:42, Nikolay Aleksandrov wrote:

[GIT] Networking

1) Don't race in IPSEC dumps, from Yuejie Shi. 2) Verify lengths properly in IPSEC reqeusts, from Herbert Xu. 3) Fix out of bounds access in ipv6 segment routing code, from David Lebrun. 4) Don't write into the header of cloned SKBs in smsc95xx driver, from James Hughes. 5) Several

Re: [PATCH net] ip6mr: fix notification device destruction

On 21/04/17 22:50, Nikolay Aleksandrov wrote: > On 21/04/17 22:36, David Miller wrote: >> From: Nikolay Aleksandrov >> Date: Fri, 21 Apr 2017 21:30:42 +0300 >> >>> On 21/04/17 20:42, Nikolay Aleksandrov wrote: Andrey Konovalov reported a BUG caused by the ip6mr code which is caused

Re: [PATCH net] ip6mr: fix notification device destruction

From: Nikolay Aleksandrov Date: Fri, 21 Apr 2017 22:50:35 +0300 > On 21/04/17 22:36, David Miller wrote: >> From: Nikolay Aleksandrov >> Date: Fri, 21 Apr 2017 21:30:42 +0300 >> >>> On 21/04/17 20:42, Nikolay Aleksandrov wrote: Andrey Konovalov reported a BUG caused by the ip6mr code

Re: IB/mlx: Fine-tuning for several function implementations

On Fri, 2017-04-21 at 21:21 +0200, SF Markus Elfring wrote: > > I don't think this patch series falls in either category > > I find that my update suggestion touches some aspects for the desired > source code quality, doesn't it? No. Bart.

Re: IB/mlx: Fine-tuning for several function implementations

On Fri, 2017-04-21 at 21:21 +0200, SF Markus Elfring wrote: > > I don't think this patch series falls in either category > > I find that my update suggestion touches some aspects for the desired > source code quality, doesn't it? No. Bart.

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

Hi Elena, On Fri, Apr 21, 2017 at 10:55:29AM +, Reshetova, Elena wrote: > > > > At the very least, what is there now could probably be made about twice as > > fast > > by removing the checks that don't actually help mitigate refcount overflow > > bugs, > > specifically all the checks in

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

Hi Elena, On Fri, Apr 21, 2017 at 10:55:29AM +, Reshetova, Elena wrote: > > > > At the very least, what is there now could probably be made about twice as > > fast > > by removing the checks that don't actually help mitigate refcount overflow > > bugs, > > specifically all the checks in

Re: [PATCH v3] kbuild: Add support to generate LLVM bitcode files

Hi Masahiro, El Fri, Apr 21, 2017 at 02:02:46PM +0900 Masahiro Yamada ha dit: > 2017-04-05 2:27 GMT+09:00 Matthias Kaehlcke : > > From: Vinícius Tinti > > > > Add rules to kbuild in order to generate LLVM bitcode files with the .ll > > extension when

Re: [PATCH v3] kbuild: Add support to generate LLVM bitcode files

Hi Masahiro, El Fri, Apr 21, 2017 at 02:02:46PM +0900 Masahiro Yamada ha dit: > 2017-04-05 2:27 GMT+09:00 Matthias Kaehlcke : > > From: Vinícius Tinti > > > > Add rules to kbuild in order to generate LLVM bitcode files with the .ll > > extension when using clang. > > > First, I'd like to be

Re: [RFC-b PATCH] kbuild: redefine __FILE__ as relative path from $(srctree) if possible

Dne 21.4.2017 v 21:36 Masahiro Yamada napsal(a): > Since Kbuild runs in the objtree, __FILE__ can be a very long path > depending of $(srctree). > > Commit 9da0763bdd82 ("kbuild: Use relative path when building in a > subdir of the source tree") made the situation better for cases > where objtree

Re: [RFC-b PATCH] kbuild: redefine __FILE__ as relative path from $(srctree) if possible

Dne 21.4.2017 v 21:36 Masahiro Yamada napsal(a): > Since Kbuild runs in the objtree, __FILE__ can be a very long path > depending of $(srctree). > > Commit 9da0763bdd82 ("kbuild: Use relative path when building in a > subdir of the source tree") made the situation better for cases > where objtree

Re: [PATCH net] ip6mr: fix notification device destruction

On 21/04/17 22:36, David Miller wrote: > From: Nikolay Aleksandrov > Date: Fri, 21 Apr 2017 21:30:42 +0300 > >> On 21/04/17 20:42, Nikolay Aleksandrov wrote: >>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused >>> because we call

Re: [PATCH net] ip6mr: fix notification device destruction

On 21/04/17 22:36, David Miller wrote: > From: Nikolay Aleksandrov > Date: Fri, 21 Apr 2017 21:30:42 +0300 > >> On 21/04/17 20:42, Nikolay Aleksandrov wrote: >>> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused >>> because we call unregister_netdevice_many for a device

Re: [PATCH v4 1/4] KEYS: Insert incompressible bytes to reserve space in bzImage

On Thu, 20 Apr 2017, Mehmet Kayaalp wrote: > > On Apr 20, 2017, at 7:13 PM, Henrique de Moraes Holschuh > > wrote: > > On Thu, 20 Apr 2017, Mehmet Kayaalp wrote: > >> Include a random filled binary in vmlinux at the space reserved with > >> CONFIG_SYSTEM_EXTRA_CERTIFICATE. This

Re: [PATCH v4 1/4] KEYS: Insert incompressible bytes to reserve space in bzImage

On Thu, 20 Apr 2017, Mehmet Kayaalp wrote: > > On Apr 20, 2017, at 7:13 PM, Henrique de Moraes Holschuh > > wrote: > > On Thu, 20 Apr 2017, Mehmet Kayaalp wrote: > >> Include a random filled binary in vmlinux at the space reserved with > >> CONFIG_SYSTEM_EXTRA_CERTIFICATE. This results in an

Re: net: cleanup_net is slow

Florian Westphal wrote: > Indeed. Setting net.netfilter.nf_conntrack_default_on=0 cuts time > cleanup time by 2/3 ... > > nf unregister is way too happy to issue synchronize_net(), I'll work on > a fix. I'll test this patch as a start. Maybe we can also leverage exit_batch

Re: net: cleanup_net is slow

Florian Westphal wrote: > Indeed. Setting net.netfilter.nf_conntrack_default_on=0 cuts time > cleanup time by 2/3 ... > > nf unregister is way too happy to issue synchronize_net(), I'll work on > a fix. I'll test this patch as a start. Maybe we can also leverage exit_batch more on netfilter

Re: net: cleanup_net is slow

On Fri, Apr 21, 2017 at 7:57 PM, Eric Dumazet wrote: > On Fri, Apr 21, 2017 at 10:50 AM, Andrey Konovalov > wrote: >> Hi! >> >> We're investigating some approaches to improve isolation of syzkaller >> programs. One of the ideas is run each program in

Re: net: cleanup_net is slow

On Fri, Apr 21, 2017 at 7:57 PM, Eric Dumazet wrote: > On Fri, Apr 21, 2017 at 10:50 AM, Andrey Konovalov > wrote: >> Hi! >> >> We're investigating some approaches to improve isolation of syzkaller >> programs. One of the ideas is run each program in it's own user/net >> namespace. However,

Re: [PATCH] mtip32xx: Uninitialized variable in mtip_no_dev_cleanup()

On 04/21/2017 01:37 PM, Dan Carpenter wrote: > We set "cmd->state = -ENODEV;" but "cmd" hasn't been initialized yet. > It's weird that GCC doesn't catch this. That is weird... > diff --git a/drivers/block/mtip32xx/mtip32xx.c > b/drivers/block/mtip32xx/mtip32xx.c > index

Re: [PATCH] mtip32xx: Uninitialized variable in mtip_no_dev_cleanup()

On 04/21/2017 01:37 PM, Dan Carpenter wrote: > We set "cmd->state = -ENODEV;" but "cmd" hasn't been initialized yet. > It's weird that GCC doesn't catch this. That is weird... > diff --git a/drivers/block/mtip32xx/mtip32xx.c > b/drivers/block/mtip32xx/mtip32xx.c > index

Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type

On Wed, Apr 19, 2017 at 11:38 PM, Jérémy Lefaure wrote: > When building object-list.o, gcc 6 raises a warning on the sprintf call > in fscache_objlist_show: > > CC fs/fscache/object-list.o > fs/fscache/object-list.c: In function ‘fscache_objlist_show’: >

Re: [PATCH] FS-Cache: print hexadecimal value for special cookies type

On Wed, Apr 19, 2017 at 11:38 PM, Jérémy Lefaure wrote: > When building object-list.o, gcc 6 raises a warning on the sprintf call > in fscache_objlist_show: > > CC fs/fscache/object-list.o > fs/fscache/object-list.c: In function ‘fscache_objlist_show’: > fs/fscache/object-list.c:265:19:

Re: [RFC PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__

Hi Yamada-san, On Fri, Apr 21, 2017 at 9:03 PM, Masahiro Yamada wrote: > Kbuild works in objtree, not in srctree. So, __FILE__ is prefixed > with $(srctree)/ for out-of-tree build. > > It would be nice to see the same log regardless > in-tree, or out-of-tree

Re: [RFC PATCH 0/2] kbuild: use relative path from $(srctree) instead of __FILE__

Hi Yamada-san, On Fri, Apr 21, 2017 at 9:03 PM, Masahiro Yamada wrote: > Kbuild works in objtree, not in srctree. So, __FILE__ is prefixed > with $(srctree)/ for out-of-tree build. > > It would be nice to see the same log regardless > in-tree, or out-of-tree build. > > 1/2 adds a new macro

[RFC-b PATCH] kbuild: redefine __FILE__ as relative path from $(srctree) if possible

Since Kbuild runs in the objtree, __FILE__ can be a very long path depending of $(srctree). Commit 9da0763bdd82 ("kbuild: Use relative path when building in a subdir of the source tree") made the situation better for cases where objtree is a child of srctree. ($(srctree) is "..") For other

[PATCH] mtip32xx: Uninitialized variable in mtip_no_dev_cleanup()

We set "cmd->state = -ENODEV;" but "cmd" hasn't been initialized yet. It's weird that GCC doesn't catch this. Fixes: 4dda4735c581 ("mtip32xx: add a status field to struct mtip_cmd") Signed-off-by: Dan Carpenter --- Not tested, please review carefully. diff --git

[RFC-b PATCH] kbuild: redefine __FILE__ as relative path from $(srctree) if possible

Since Kbuild runs in the objtree, __FILE__ can be a very long path depending of $(srctree). Commit 9da0763bdd82 ("kbuild: Use relative path when building in a subdir of the source tree") made the situation better for cases where objtree is a child of srctree. ($(srctree) is "..") For other

[PATCH] mtip32xx: Uninitialized variable in mtip_no_dev_cleanup()

We set "cmd->state = -ENODEV;" but "cmd" hasn't been initialized yet. It's weird that GCC doesn't catch this. Fixes: 4dda4735c581 ("mtip32xx: add a status field to struct mtip_cmd") Signed-off-by: Dan Carpenter --- Not tested, please review carefully. diff --git

Re: net/core: BUG in unregister_netdevice_many

From: Cong Wang Date: Fri, 21 Apr 2017 11:55:04 -0700 > On Fri, Apr 21, 2017 at 10:25 AM, Linus Torvalds > wrote: >> On Fri, Apr 21, 2017 at 5:48 AM, Andrey Konovalov >> wrote: >>> >>> I've got the following error

Re: net/core: BUG in unregister_netdevice_many

From: Cong Wang Date: Fri, 21 Apr 2017 11:55:04 -0700 > On Fri, Apr 21, 2017 at 10:25 AM, Linus Torvalds > wrote: >> On Fri, Apr 21, 2017 at 5:48 AM, Andrey Konovalov >> wrote: >>> >>> I've got the following error report while fuzzing the kernel with syzkaller. >>> >>> [ cut here

Re: net/core: BUG in unregister_netdevice_many

From: Linus Torvalds Date: Fri, 21 Apr 2017 10:42:48 -0700 > Over to Eric and networking people. This oops is user-triggerable, and > leaves the machine in a bad state (the original BUG_ON() and the new > GP fault both happen while holding the RTNL, so networking

Re: net/core: BUG in unregister_netdevice_many

From: Linus Torvalds Date: Fri, 21 Apr 2017 10:42:48 -0700 > Over to Eric and networking people. This oops is user-triggerable, and > leaves the machine in a bad state (the original BUG_ON() and the new > GP fault both happen while holding the RTNL, so networking is not > healthy afterwards. I

Re: [PATCH net] ip6mr: fix notification device destruction

From: Nikolay Aleksandrov Date: Fri, 21 Apr 2017 21:30:42 +0300 > On 21/04/17 20:42, Nikolay Aleksandrov wrote: >> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused >> because we call unregister_netdevice_many for a device that is already >>

Re: [PATCH net] ip6mr: fix notification device destruction

From: Nikolay Aleksandrov Date: Fri, 21 Apr 2017 21:30:42 +0300 > On 21/04/17 20:42, Nikolay Aleksandrov wrote: >> Andrey Konovalov reported a BUG caused by the ip6mr code which is caused >> because we call unregister_netdevice_many for a device that is already >> being destroyed. In IPv4's ipmr

Re: hwmon: (adt7475) set start bit in probe

On Sat, Apr 22, 2017 at 07:08:09AM +1200, Chris Packham wrote: > The ADT7475 and ADT7476 have the STRT bit cleared by default[1]. Before any > monitoring activities the STRT bit needs to be set. Logically this needs > to happen before any of the sensors are read so the probe() function > seems the

Re: hwmon: (adt7475) set start bit in probe

On Sat, Apr 22, 2017 at 07:08:09AM +1200, Chris Packham wrote: > The ADT7475 and ADT7476 have the STRT bit cleared by default[1]. Before any > monitoring activities the STRT bit needs to be set. Logically this needs > to happen before any of the sensors are read so the probe() function > seems the

Re: [PATCH net-next] net: dsa: LAN9303: add I2C dependency

From: Arnd Bergmann Date: Fri, 21 Apr 2017 18:22:40 +0200 > With CONFIG_I2C=m and NET_DSA_SMSC_LAN9303=y, we run into a link error: > > drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_read': > regmap-i2c.c:(.text.regmap_smbus_byte_reg_read+0x18): undefined

Re: [PATCH net-next] net: dsa: LAN9303: add I2C dependency

From: Arnd Bergmann Date: Fri, 21 Apr 2017 18:22:40 +0200 > With CONFIG_I2C=m and NET_DSA_SMSC_LAN9303=y, we run into a link error: > > drivers/base/regmap/regmap-i2c.o: In function `regmap_smbus_byte_reg_read': > regmap-i2c.c:(.text.regmap_smbus_byte_reg_read+0x18): undefined reference to >

Re: [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support

Hi, On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI > controller. > > That HDMI controller is able to do audio and CEC, but those have been left > out for now. > > Signed-off-by:

Re: [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support

Hi, On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI > controller. > > That HDMI controller is able to do audio and CEC, but those have been left > out for now. > > Signed-off-by: Maxime Ripard > --- >

Re: [PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC

On Fri, Apr 21, 2017 at 04:12:43PM +0200, Jiri Slaby wrote: > Do not use a custom macro FUNC for starts of the global functions, use > ENTRY instead. > > And while at it, annotate also ends of the functions by ENDPROC. > > Signed-off-by: Jiri Slaby > Cc: "David S. Miller"

Re: [PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC

On Fri, Apr 21, 2017 at 04:12:43PM +0200, Jiri Slaby wrote: > Do not use a custom macro FUNC for starts of the global functions, use > ENTRY instead. > > And while at it, annotate also ends of the functions by ENDPROC. > > Signed-off-by: Jiri Slaby > Cc: "David S. Miller" > Cc: Alexey

Re: [tip:x86/mm] x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation

On Fri, Apr 21, 2017 at 7:16 AM, Kirill A. Shutemov wrote: > On Thu, Apr 20, 2017 at 02:46:51PM -0700, Dan Williams wrote: >> On Sat, Mar 18, 2017 at 2:52 AM, tip-bot for Kirill A. Shutemov >> wrote: >> > Commit-ID:

Re: [tip:x86/mm] x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation

On Fri, Apr 21, 2017 at 7:16 AM, Kirill A. Shutemov wrote: > On Thu, Apr 20, 2017 at 02:46:51PM -0700, Dan Williams wrote: >> On Sat, Mar 18, 2017 at 2:52 AM, tip-bot for Kirill A. Shutemov >> wrote: >> > Commit-ID: 2947ba054a4dabbd82848728d765346886050029 >> > Gitweb: >> >

<    1   2   3   4   5   6   7   8   9   10   >