Re: [PATCH v2 1/3] x86/mm: Remove flush_tlb() and flush_tlb_current_task()

On Fri, Apr 21, 2017 at 11:15 AM, Andy Lutomirski wrote: > I was trying to figure out what how flush_tlb_current_task() would > possibly work correctly if current->mm != current->active_mm, but I > realized I could spare myself the effort: it has no callers except > the unused

Re: [PATCH 1/4] scsi: pmcraid: use __iomem pointers for ioctl argument

On Thu, Apr 20, 2017 at 9:24 PM, Al Viro wrote: > On Thu, Apr 20, 2017 at 07:54:45PM +0200, Arnd Bergmann wrote: >> kernelci.org reports a new compile warning for old code in the pmcraid >> driver: >> >> arch/mips/include/asm/uaccess.h:138:21: warning: passing argument 1

Re: [PATCH v2 8/8] platform: x86: intel_bxtwc_tmu: remove first level irq unmask

On Fri, Apr 14, 2017 at 04:26:00PM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Currently in WCOVE PMIC mfd driver, all second level irq chips By currently I believe you mean after the earlier patch

Re: [PATCH v2 1/3] x86/mm: Remove flush_tlb() and flush_tlb_current_task()

On Fri, Apr 21, 2017 at 11:15 AM, Andy Lutomirski wrote: > I was trying to figure out what how flush_tlb_current_task() would > possibly work correctly if current->mm != current->active_mm, but I > realized I could spare myself the effort: it has no callers except > the unused flush_tlb() macro.

Re: [PATCH 1/4] scsi: pmcraid: use __iomem pointers for ioctl argument

On Thu, Apr 20, 2017 at 9:24 PM, Al Viro wrote: > On Thu, Apr 20, 2017 at 07:54:45PM +0200, Arnd Bergmann wrote: >> kernelci.org reports a new compile warning for old code in the pmcraid >> driver: >> >> arch/mips/include/asm/uaccess.h:138:21: warning: passing argument 1 of >> '__access_ok'

Re: [PATCH v2 8/8] platform: x86: intel_bxtwc_tmu: remove first level irq unmask

On Fri, Apr 14, 2017 at 04:26:00PM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: > From: Kuppuswamy Sathyanarayanan > > Currently in WCOVE PMIC mfd driver, all second level irq chips By currently I believe you mean after the earlier patch in this series is applied, correct? This one

Re: [PATCH] Introduce v3 namespaced file capabilities

"Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> >> Serge, >> >> Is there any change of a Signed-off-by on this patch? Otherwise I don't >> think we can merge it. > > For pete's sake! I'm sorry, i seem to remember with just about every >

Re: [PATCH] Introduce v3 namespaced file capabilities

"Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> >> Serge, >> >> Is there any change of a Signed-off-by on this patch? Otherwise I don't >> think we can merge it. > > For pete's sake! I'm sorry, i seem to remember with just about every > other project other

Re: [PATCH] cgroup: define empty cftype structure for !CONFIG_CGROUPS

On 04/21/2017 03:41 PM, Arnd Bergmann wrote: > There is a new forward declaration for two global cftype arrays, but > that fails to build when CONFIG_CGROUPS is disabled: > > In file included from /git/arm-soc/block/bfq-iosched.c:105:0: > block/bfq-iosched.h:820:22: error: array type has

Re: [PATCH] cgroup: define empty cftype structure for !CONFIG_CGROUPS

On 04/21/2017 03:41 PM, Arnd Bergmann wrote: > There is a new forward declaration for two global cftype arrays, but > that fails to build when CONFIG_CGROUPS is disabled: > > In file included from /git/arm-soc/block/bfq-iosched.c:105:0: > block/bfq-iosched.h:820:22: error: array type has

[PATCH] ARM: omap2+: make omap4_get_cpu1_ns_pa_addr declaration usable

When CONFIG_PM is disabled, we get a build error: arch/arm/mach-omap2/omap-smp.c: In function 'omap4_smp_maybe_reset_cpu1': arch/arm/mach-omap2/omap-smp.c:309:20: error: implicit declaration of function 'omap4_get_cpu1_ns_pa_addr'; did you mean 'omap4_get_scu_base'?

[PATCH] ARM: omap2+: make omap4_get_cpu1_ns_pa_addr declaration usable

When CONFIG_PM is disabled, we get a build error: arch/arm/mach-omap2/omap-smp.c: In function 'omap4_smp_maybe_reset_cpu1': arch/arm/mach-omap2/omap-smp.c:309:20: error: implicit declaration of function 'omap4_get_cpu1_ns_pa_addr'; did you mean 'omap4_get_scu_base'?

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/18/2017 02:22 PM, Tom Lendacky wrote: > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > determine if SME is active. > > A new directory will be created: > /sys/kernel/mm/sme/ > > And two entries within the new directory: > /sys/kernel/mm/sme/active >

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/18/2017 02:22 PM, Tom Lendacky wrote: > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > determine if SME is active. > > A new directory will be created: > /sys/kernel/mm/sme/ > > And two entries within the new directory: > /sys/kernel/mm/sme/active >

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

+Dave, On 4/21/2017 2:44 PM, Arnd Bergmann wrote: On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilim...@oracle.com wrote: On 4/21/17 2:31 AM, Arnd Bergmann wrote: [...] arm-soc/next/drivers: ae3874cc931b ARM: keystone: Drop PM domain support for k2g

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

+Dave, On 4/21/2017 2:44 PM, Arnd Bergmann wrote: On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilim...@oracle.com wrote: On 4/21/17 2:31 AM, Arnd Bergmann wrote: [...] arm-soc/next/drivers: ae3874cc931b ARM: keystone: Drop PM domain support for k2g 52835d59fc6c soc: ti: Add

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

Tested 9 distros centos, Debian, Fedora, Gentoo, Opensuse, slackware, Ubuntu, poky showed awk at /usr/bin/awk. Here is another similar patch which has been approved https://patchwork.kernel.org/patch/9650581/ centos-7: lrwxrwxrwx 1 root root 4 Mar 15 19:58 /bin/awk -> gawk lrwxrwxrwx 1 root

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

Tested 9 distros centos, Debian, Fedora, Gentoo, Opensuse, slackware, Ubuntu, poky showed awk at /usr/bin/awk. Here is another similar patch which has been approved https://patchwork.kernel.org/patch/9650581/ centos-7: lrwxrwxrwx 1 root root 4 Mar 15 19:58 /bin/awk -> gawk lrwxrwxrwx 1 root

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

On 04/18/2017 02:17 PM, Tom Lendacky wrote: > @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from, > unsigned long vaddr, > __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x))) > > #ifndef __va > -#define __va(x) ((void *)((unsigned >

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

On 04/18/2017 02:17 PM, Tom Lendacky wrote: > @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from, > unsigned long vaddr, > __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x))) > > #ifndef __va > -#define __va(x) ((void *)((unsigned >

Re: [PATCH] Introduce v3 namespaced file capabilities

Quoting Eric W. Biederman (ebied...@xmission.com): > > Serge, > > Is there any change of a Signed-off-by on this patch? Otherwise I don't > think we can merge it. For pete's sake! I'm sorry, i seem to remember with just about every other project other than this. particular. patch. Does this

Re: [PATCH] Introduce v3 namespaced file capabilities

Quoting Eric W. Biederman (ebied...@xmission.com): > > Serge, > > Is there any change of a Signed-off-by on this patch? Otherwise I don't > think we can merge it. For pete's sake! I'm sorry, i seem to remember with just about every other project other than this. particular. patch. Does this

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

On 4/21/2017 2:31 PM, Rafael J. Wysocki wrote: On Friday, April 21, 2017 02:02:35 PM santosh.shilim...@oracle.com wrote: On 4/21/17 2:31 AM, Arnd Bergmann wrote: On Fri, Apr 21, 2017 at 8:39 AM, santosh.shilim...@oracle.com [...] I still see two conflicting trees in linux-next as of

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

On 4/21/2017 2:31 PM, Rafael J. Wysocki wrote: On Friday, April 21, 2017 02:02:35 PM santosh.shilim...@oracle.com wrote: On 4/21/17 2:31 AM, Arnd Bergmann wrote: On Fri, Apr 21, 2017 at 8:39 AM, santosh.shilim...@oracle.com [...] I still see two conflicting trees in linux-next as of

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

On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilim...@oracle.com wrote: > 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

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

On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilim...@oracle.com wrote: > 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

[PATCH] usb: host: xhci: remove #ifdef around PM functions

The #ifdef is slightly wrong as it doesn't cover the xhci_priv_resume_quirk() function, causing a harmless warning: drivers/usb/host/xhci-plat.c:58:12: error: 'xhci_priv_resume_quirk' defined but not used [-Werror=unused-function] static int xhci_priv_resume_quirk(struct usb_hcd *hcd) A

[PATCH] usb: host: xhci: remove #ifdef around PM functions

The #ifdef is slightly wrong as it doesn't cover the xhci_priv_resume_quirk() function, causing a harmless warning: drivers/usb/host/xhci-plat.c:58:12: error: 'xhci_priv_resume_quirk' defined but not used [-Werror=unused-function] static int xhci_priv_resume_quirk(struct usb_hcd *hcd) A

[for-next][PATCH 07/33] selftests: ftrace: Add a selftest to test event enable/disable func trigger

From: "Steven Rostedt (VMware)" This adds a test to enable and disable trace events via the function triggers. It tests enabling and disabling the sched:sched_switch event via the the event_enable and event_disable function triggers attached to the schedule() kernel

[for-next][PATCH 07/33] selftests: ftrace: Add a selftest to test event enable/disable func trigger

From: "Steven Rostedt (VMware)" This adds a test to enable and disable trace events via the function triggers. It tests enabling and disabling the sched:sched_switch event via the the event_enable and event_disable function triggers attached to the schedule() kernel function. The test does the

[for-next][PATCH 05/33] selftests: ftrace: Add -l/--logdir option

From: Namhyung Kim In my virtual machine setup, running ftracetest failed on creating LOG_DIR on a read-only filesystem. It'd be convenient to provide an option to specify a different directory as log directory. Link:

Re: [PATCH] Introduce v3 namespaced file capabilities

Serge, Is there any change of a Signed-off-by on this patch? Otherwise I don't think we can merge it. Eric "Serge E. Hallyn" writes: > Root in a non-initial user ns cannot be trusted to write a traditional > security.capability xattr. If it were allowed to do so, then any

[for-next][PATCH 05/33] selftests: ftrace: Add -l/--logdir option

From: Namhyung Kim In my virtual machine setup, running ftracetest failed on creating LOG_DIR on a read-only filesystem. It'd be convenient to provide an option to specify a different directory as log directory. Link: http://lkml.kernel.org/r/20170417024430.21194-4-namhy...@kernel.org Cc:

Re: [PATCH] Introduce v3 namespaced file capabilities

Serge, Is there any change of a Signed-off-by on this patch? Otherwise I don't think we can merge it. Eric "Serge E. Hallyn" writes: > Root in a non-initial user ns cannot be trusted to write a traditional > security.capability xattr. If it were allowed to do so, then any > unprivileged

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

On Fri, Apr 21, 2017 at 11:03:13PM +0200, Arnd Bergmann wrote: > 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

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

On Fri, Apr 21, 2017 at 11:03:13PM +0200, Arnd Bergmann wrote: > 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

[for-next][PATCH 02/33] ftrace: Fix indexing of t_hash_start() from t_next()

From: "Steven Rostedt (VMware)" t_hash_start() does not increment *pos, where as t_next() must. But when t_next() does increment *pos, it must still pass in the original *pos to t_hash_start() otherwise it will skip the first instance: # cd /sys/kernel/debug/tracing #

[for-next][PATCH 02/33] ftrace: Fix indexing of t_hash_start() from t_next()

From: "Steven Rostedt (VMware)" t_hash_start() does not increment *pos, where as t_next() must. But when t_next() does increment *pos, it must still pass in the original *pos to t_hash_start() otherwise it will skip the first instance: # cd /sys/kernel/debug/tracing # echo schedule:traceoff >

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

From: "Steven Rostedt (VMware)" As nothing outside the tracing directory uses the function command 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 11/33] ftrace: Move the function commands into the tracing directory

From: "Steven Rostedt (VMware)" As nothing outside the tracing directory uses the function command 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 01/33] ftrace: Fix removing of second function probe

From: "Steven Rostedt (VMware)" When two function probes are added to set_ftrace_filter, and then one of them is removed, the update to the function locations is not performed, and the record keeping of the function states are corrupted, and causes an ftrace_bug() to occur.

[PATCH] cgroup: define empty cftype structure for !CONFIG_CGROUPS

There is a new forward declaration for two global cftype arrays, but that fails to build when CONFIG_CGROUPS is disabled: In file included from /git/arm-soc/block/bfq-iosched.c:105:0: block/bfq-iosched.h:820:22: error: array type has incomplete element type 'struct cftype' extern struct cftype

[for-next][PATCH 01/33] ftrace: Fix removing of second function probe

From: "Steven Rostedt (VMware)" When two function probes are added to set_ftrace_filter, and then one of them is removed, the update to the function locations is not performed, and the record keeping of the function states are corrupted, and causes an ftrace_bug() to occur. This is easily

[PATCH] cgroup: define empty cftype structure for !CONFIG_CGROUPS

There is a new forward declaration for two global cftype arrays, but that fails to build when CONFIG_CGROUPS is disabled: In file included from /git/arm-soc/block/bfq-iosched.c:105:0: block/bfq-iosched.h:820:22: error: array type has incomplete element type 'struct cftype' extern struct cftype

Re: [PATCH] platform/x86: INT33FE: add i2c dependency

On Fri, Apr 21, 2017 at 09:19:10AM +0200, Hans de Goede wrote: > Hi, > > On 20-04-17 14:51, Tobias Regnery wrote: > > With CONFIG_I2C=m and CONFIG_INTEL_CHT_INT33FE=y we see the following link > > errors: > > > > drivers/built-in.o: In function 'cht_int33fe_remove': > >

Re: [PATCH] platform/x86: INT33FE: add i2c dependency

On Fri, Apr 21, 2017 at 09:19:10AM +0200, Hans de Goede wrote: > Hi, > > On 20-04-17 14:51, Tobias Regnery wrote: > > With CONFIG_I2C=m and CONFIG_INTEL_CHT_INT33FE=y we see the following link > > errors: > > > > drivers/built-in.o: In function 'cht_int33fe_remove': > >

[PATCH 1/2] kbuild: clang: Disable 'address-of-packed-member' warning

clang generates plenty of these warnings in different parts of the code, to an extent that the warnings are little more than noise. Disable the 'address-of-packed-member' warning. Signed-off-by: Matthias Kaehlcke --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 1/2] kbuild: clang: Disable 'address-of-packed-member' warning

clang generates plenty of these warnings in different parts of the code, to an extent that the warnings are little more than noise. Disable the 'address-of-packed-member' warning. Signed-off-by: Matthias Kaehlcke --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile

[PATCH 0/2] kbuild: clang: Disable spurious warnings

Disable two clang warnings that generate a lot of noise. Matthias Kaehlcke (2): kbuild: clang: Disable 'address-of-packed-member' warning kbuild: clang: Disable the 'duplicate-decl-specifier' warning Makefile | 2 ++ 1 file changed, 2 insertions(+) -- 2.12.2.816.g281164-goog

[PATCH 2/2] kbuild: clang: Disable the 'duplicate-decl-specifier' warning

clang generates plenty of these warnings in different parts of the code. They are mostly caused by container_of() and other macros which declare a "const *" variable for their internal use which triggers a "duplicate 'const' specifier" warning if the is already const qualified.

[PATCH 0/2] kbuild: clang: Disable spurious warnings

Disable two clang warnings that generate a lot of noise. Matthias Kaehlcke (2): kbuild: clang: Disable 'address-of-packed-member' warning kbuild: clang: Disable the 'duplicate-decl-specifier' warning Makefile | 2 ++ 1 file changed, 2 insertions(+) -- 2.12.2.816.g281164-goog

[PATCH 2/2] kbuild: clang: Disable the 'duplicate-decl-specifier' warning

clang generates plenty of these warnings in different parts of the code. They are mostly caused by container_of() and other macros which declare a "const *" variable for their internal use which triggers a "duplicate 'const' specifier" warning if the is already const qualified.

Re: [PATCH v5 07/32] x86/mm: Add support to enable SME in early boot processing

On 4/21/2017 9:55 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:17:35PM -0500, Tom Lendacky wrote: Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, support is added to encrypt the kernel in place

Re: [PATCH v5 07/32] x86/mm: Add support to enable SME in early boot processing

On 4/21/2017 9:55 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:17:35PM -0500, Tom Lendacky wrote: Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, support is added to encrypt the kernel in place

[for-next][PATCH 13/33] ftrace: Pass probe ops to probe function

From: "Steven Rostedt (VMware)" In preparation to cleaning up the probe function registration code, the "data" parameter will eventually be removed from the probe->func() call. Instead it will receive its own "ops" function, in which it can set up its own data that it needs

[for-next][PATCH 09/33] selftests: ftrace: Add test to test reading of set_ftrace_file

From: "Steven Rostedt (VMware)" The set_ftrace_file lists both functions that are filtered, as well as function probes (triggers) that are attached to a function, like traceon or stacktrace, etc. The reading of this file is not as trivial as most pseudo files are, and

[for-next][PATCH 09/33] selftests: ftrace: Add test to test reading of set_ftrace_file

From: "Steven Rostedt (VMware)" The set_ftrace_file lists both functions that are filtered, as well as function probes (triggers) that are attached to a function, like traceon or stacktrace, etc. The reading of this file is not as trivial as most pseudo files are, and there's been various bugs

[for-next][PATCH 13/33] ftrace: Pass probe ops to probe function

From: "Steven Rostedt (VMware)" In preparation to cleaning up the probe function registration code, the "data" parameter will eventually be removed from the probe->func() call. Instead it will receive its own "ops" function, in which it can set up its own data that it needs to map.

[for-next][PATCH 08/33] selftests: ftrace: Add a test to test function triggers to start and stop tracing

From: "Steven Rostedt (VMware)" This adds a test to test the function tiggers traceon and traceoff to make sure that it starts and stops tracing when a function is hit. The test performs the following: o Enables all events o Writes schedule:traceoff into

[for-next][PATCH 08/33] selftests: ftrace: Add a test to test function triggers to start and stop tracing

From: "Steven Rostedt (VMware)" This adds a test to test the function tiggers traceon and traceoff to make sure that it starts and stops tracing when a function is hit. The test performs the following: o Enables all events o Writes schedule:traceoff into set_ftrace_filter o Makes sure the

[for-next][PATCH 30/33] tracing/ftrace: Allow instances to have their own function probes

From: "Steven Rostedt (VMware)" Pass around the local trace_array that is the descriptor for tracing instances, when enabling and disabling probes. This by default sets the enable/disable of event probe triggers to work with instances. The other probes will need some more

[for-next][PATCH 30/33] tracing/ftrace: Allow instances to have their own function probes

From: "Steven Rostedt (VMware)" Pass around the local trace_array that is the descriptor for tracing instances, when enabling and disabling probes. This by default sets the enable/disable of event probe triggers to work with instances. The other probes will need some more work to get them

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Thu, 2017-04-13 at 13:31 +0200, Borislav Petkov wrote: > On Thu, Apr 13, 2017 at 12:29:25AM +0200, Borislav Petkov wrote: > > On Wed, Apr 12, 2017 at 03:26:19PM -0700, Luck, Tony wrote: > > > We can futz with that and have them specify which chain (or both) > > > that they want to be added to.

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Thu, 2017-04-13 at 13:31 +0200, Borislav Petkov wrote: > On Thu, Apr 13, 2017 at 12:29:25AM +0200, Borislav Petkov wrote: > > On Wed, Apr 12, 2017 at 03:26:19PM -0700, Luck, Tony wrote: > > > We can futz with that and have them specify which chain (or both) > > > that they want to be added to.

[for-next][PATCH 25/33] ftrace: If the hash for a probe fails to update then free what was initialized

From: "Steven Rostedt (VMware)" If the ftrace_hash_move_and_update_ops() fails, and an ops->free() function exists, then it needs to be called on all the ops that were added by this registration. Signed-off-by: Steven Rostedt (VMware) ---

[for-next][PATCH 25/33] ftrace: If the hash for a probe fails to update then free what was initialized

From: "Steven Rostedt (VMware)" If the ftrace_hash_move_and_update_ops() fails, and an ops->free() function exists, then it needs to be called on all the ops that were added by this registration. Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/ftrace.c | 16 +++- 1 file

[for-next][PATCH 06/33] selftests: ftrace: Add a way to reset triggers in the set_ftrace_filter file

From: "Steven Rostedt (VMware)" Just writing into the set_ftrace_filter file does not reset triggers, even though it can reset the function list. Triggers require writing the trigger name with a "!" prepended. It's worse that it requires the number if the trigger has a count

[for-next][PATCH 06/33] selftests: ftrace: Add a way to reset triggers in the set_ftrace_filter file

From: "Steven Rostedt (VMware)" Just writing into the set_ftrace_filter file does not reset triggers, even though it can reset the function list. Triggers require writing the trigger name with a "!" prepended. It's worse that it requires the number if the trigger has a count associated to it.

[for-next][PATCH 22/33] ftrace: Have unregister_ftrace_function_probe_func() return a value

From: "Steven Rostedt (VMware)" Currently unregister_ftrace_function_probe_func() is a void function. It does not give any feedback if an error occurred or no item was found to remove and nothing was done. Change it to return status and success if it removed something. Also

[for-next][PATCH 22/33] ftrace: Have unregister_ftrace_function_probe_func() return a value

From: "Steven Rostedt (VMware)" Currently unregister_ftrace_function_probe_func() is a void function. It does not give any feedback if an error occurred or no item was found to remove and nothing was done. Change it to return status and success if it removed something. Also update the callers

[for-next][PATCH 27/33] tracing: Pass the trace_array into ftrace_probe_ops functions

From: "Steven Rostedt (VMware)" Pass the trace_array associated to a ftrace_probe_ops into the probe_ops func(), init() and free() functions. The trace_array is the descriptor that describes a tracing instance. This will help create the infrastructure that will allow having

[for-next][PATCH 18/33] ftrace: Remove unused unregister_ftrace_function_probe_all() function

From: "Steven Rostedt (VMware)" There are no users of unregister_ftrace_function_probe_all(). The only probe function that is used is unregister_ftrace_function_probe_func(). Rename the internal static function __unregister_ftrace_function_probe() to

[for-next][PATCH 23/33] ftrace: Have each function probe use its own ftrace_ops

From: "Steven Rostedt (VMware)" Have the function probes have their own ftrace_ops, and remove the trace_probe_ops. This simplifies some of the ftrace infrastructure code. Individual entries for each function is still allocated for the use of the output for

[for-next][PATCH 27/33] tracing: Pass the trace_array into ftrace_probe_ops functions

From: "Steven Rostedt (VMware)" Pass the trace_array associated to a ftrace_probe_ops into the probe_ops func(), init() and free() functions. The trace_array is the descriptor that describes a tracing instance. This will help create the infrastructure that will allow having function probes

[for-next][PATCH 18/33] ftrace: Remove unused unregister_ftrace_function_probe_all() function

From: "Steven Rostedt (VMware)" There are no users of unregister_ftrace_function_probe_all(). The only probe function that is used is unregister_ftrace_function_probe_func(). Rename the internal static function __unregister_ftrace_function_probe() to unregister_ftrace_function_probe_func() and

[for-next][PATCH 23/33] ftrace: Have each function probe use its own ftrace_ops

From: "Steven Rostedt (VMware)" Have the function probes have their own ftrace_ops, and remove the trace_probe_ops. This simplifies some of the ftrace infrastructure code. Individual entries for each function is still allocated for the use of the output for set_ftrace_filter, but they will be

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

On Friday, April 21, 2017 02:02:35 PM santosh.shilim...@oracle.com wrote: > > 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

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

On Friday, April 21, 2017 02:02:35 PM santosh.shilim...@oracle.com wrote: > > 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

[for-next][PATCH 14/33] ftrace: Added ftrace_func_mapper for function probe triggers

From: "Steven Rostedt (VMware)" In order to move the ops to the function probes directly, they need a way to map function ips to their own data without depending on the infrastructure of the function probes, as the data field will be going away. New helper functions are

[for-next][PATCH 33/33] tracing/ftrace: Allow for instances to trigger their own stacktrace probes

From: "Steven Rostedt (VMware)" Have the stacktrace function trigger probe trigger stack traces within the instance that they were added to in the set_ftrace_filter. ># cd /sys/kernel/debug/tracing ># mkdir instances/foo ># cd instances/foo ># echo schedule:stacktrace:1

[for-next][PATCH 24/33] ftrace: Have the function probes call their own function

From: "Steven Rostedt (VMware)" Now that the function probes have their own ftrace_ops, there's no reason to continue using the ftrace_func_hash to find which probe to call in the function callback. The ops that is passed in to the function callback is part of the probe_ops

[for-next][PATCH 14/33] ftrace: Added ftrace_func_mapper for function probe triggers

From: "Steven Rostedt (VMware)" In order to move the ops to the function probes directly, they need a way to map function ips to their own data without depending on the infrastructure of the function probes, as the data field will be going away. New helper functions are added that are based on

[for-next][PATCH 33/33] tracing/ftrace: Allow for instances to trigger their own stacktrace probes

From: "Steven Rostedt (VMware)" Have the stacktrace function trigger probe trigger stack traces within the instance that they were added to in the set_ftrace_filter. ># cd /sys/kernel/debug/tracing ># mkdir instances/foo ># cd instances/foo ># echo schedule:stacktrace:1 > set_ftrace_filter

[for-next][PATCH 24/33] ftrace: Have the function probes call their own function

From: "Steven Rostedt (VMware)" Now that the function probes have their own ftrace_ops, there's no reason to continue using the ftrace_func_hash to find which probe to call in the function callback. The ops that is passed in to the function callback is part of the probe_ops to call.

[for-next][PATCH 26/33] tracing: Have the trace_array hold the list of registered func probes

From: "Steven Rostedt (VMware)" Add a link list to the trace_array to hold func probes that are registered. Currently, all function probes are the same for all instances as it was before, that is, only the top level trace_array holds the function probes. But this lays the

[for-next][PATCH 26/33] tracing: Have the trace_array hold the list of registered func probes

From: "Steven Rostedt (VMware)" Add a link list to the trace_array to hold func probes that are registered. Currently, all function probes are the same for all instances as it was before, that is, only the top level trace_array holds the function probes. But this lays the ground work to have

[for-next][PATCH 32/33] tracing/ftrace: Allow for the traceonoff probe be unique to instances

From: "Steven Rostedt (VMware)" Have the traceon/off function probe triggers affect only the instance they are set in. This required making the trace_on/off accessible for other files in the tracing directory. Signed-off-by: Steven Rostedt (VMware) ---

[for-next][PATCH 15/33] tracing: Have the snapshot trigger use the mapping helper 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 snapshot trigger counter over to the new ftrace_func_mapper helper functions. Signed-off-by: Steven Rostedt

[for-next][PATCH 32/33] tracing/ftrace: Allow for the traceonoff probe be unique to instances

From: "Steven Rostedt (VMware)" Have the traceon/off function probe triggers affect only the instance they are set in. This required making the trace_on/off accessible for other files in the tracing directory. Signed-off-by: Steven Rostedt (VMware) --- kernel/trace/trace.c | 4 ++--

[for-next][PATCH 15/33] tracing: Have the snapshot trigger use the mapping helper 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 snapshot trigger counter over to the new ftrace_func_mapper helper functions. Signed-off-by: Steven Rostedt (VMware) ---

[for-next][PATCH 29/33] tracing/ftrace: Add a better way to pass data via the probe functions

From: "Steven Rostedt (VMware)" With the redesign of the registration and execution of the function probes (triggers), data can now be passed from the setup of the probe to the probe callers that are specific to the trace_array it is on. Although, all probes still only

[for-next][PATCH 29/33] tracing/ftrace: Add a better way to pass data via the probe functions

From: "Steven Rostedt (VMware)" With the redesign of the registration and execution of the function probes (triggers), data can now be passed from the setup of the probe to the probe callers that are specific to the trace_array it is on. Although, all probes still only affect the toplevel trace

[for-next][PATCH 19/33] ftrace: Remove printing of data in showing of a function probe

From: "Steven Rostedt (VMware)" None of the probe users uses the data field anymore of the entry. They all have their own print() function. Remove showing the data field in the generic function as the data field will be going away. Signed-off-by: Steven Rostedt (VMware)

[for-next][PATCH 19/33] ftrace: Remove printing of data in showing of a function probe

From: "Steven Rostedt (VMware)" None of the probe users uses the data field anymore of the entry. They all have their own print() function. Remove showing the data field in the generic function as the data field will be going away. Signed-off-by: Steven Rostedt (VMware) ---

[for-next][PATCH 21/33] ftrace: Add helper function ftrace_hash_move_and_update_ops()

From: "Steven Rostedt (VMware)" The processes of updating a ops filter_hash is a bit complex, and requires setting up an old hash to perform the update. This is done exactly the same in two locations for the same reasons. Create a helper function that does it in one place.

[for-next][PATCH 21/33] ftrace: Add helper function ftrace_hash_move_and_update_ops()

From: "Steven Rostedt (VMware)" The processes of updating a ops filter_hash is a bit complex, and requires setting up an old hash to perform the update. This is done exactly the same in two locations for the same reasons. Create a helper function that does it in one place. Signed-off-by: Steven

[for-next][PATCH 20/33] ftrace: Remove data field from ftrace_func_probe structure

From: "Steven Rostedt (VMware)" No users of the function probes uses the data field anymore. Remove it, and change the init function to take a void *data parameter instead of a void **data, because the init will just get the data that the registering function was received,

[for-next][PATCH 20/33] ftrace: Remove data field from ftrace_func_probe structure

From: "Steven Rostedt (VMware)" No users of the function probes uses the data field anymore. Remove it, and change the init function to take a void *data parameter instead of a void **data, because the init will just get the data that the registering function was received, and there's no state

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > My personal opinion is that formats in drm_fourcc.h should be > > independent of the CPU byte order and the function > > drm_mode_legacy_fb_format() and drivers depending on that incorrect > > assumption be fixed instead. > > The problem is this isn't a kernel-internal thing any

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Hi, > > My personal opinion is that formats in drm_fourcc.h should be > > independent of the CPU byte order and the function > > drm_mode_legacy_fb_format() and drivers depending on that incorrect > > assumption be fixed instead. > > The problem is this isn't a kernel-internal thing any

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