[PATCH 0/6] x86, boot: clean up KASLR code

In order to make improvements to KASLR behavior, it has been suggested that the code should be cleaned up a bit first. This is the start of those changes. Since there are no stand-alone bug fixes in the later patches, I will begin here. First with a rename followed by variable name changes and

[PATCH 1/6] x86, KASLR: rename aslr.c to kaslr.c

In order to avoid confusion over what this file provides, rename it to kaslr.c since it is used exclusively for the kernel ASLR, not userspace ASLR. Suggested-by: Ingo Molnar Signed-off-by: Kees Cook --- arch/x86/boot/compressed/Makefile | 2 +-

[PATCH 0/6] x86, boot: clean up KASLR code

In order to make improvements to KASLR behavior, it has been suggested that the code should be cleaned up a bit first. This is the start of those changes. Since there are no stand-alone bug fixes in the later patches, I will begin here. First with a rename followed by variable name changes and

[PATCH 1/6] x86, KASLR: rename aslr.c to kaslr.c

In order to avoid confusion over what this file provides, rename it to kaslr.c since it is used exclusively for the kernel ASLR, not userspace ASLR. Suggested-by: Ingo Molnar Signed-off-by: Kees Cook --- arch/x86/boot/compressed/Makefile | 2 +- arch/x86/boot/compressed/aslr.c | 339

[PATCH 6/6] x86, KASLR: Rename "random" to "random_addr"

The variable "random" is also the name of a libc function. It's better coding style to avoid overloading such things, so rename it to the more accurate "random_addr". Suggested-by: Ingo Molnar Signed-off-by: Kees Cook ---

[PATCH 4/6] x86, boot: Clarify purpose of functions in misc.c

The function "decompress_kernel" now performs many more duties, so this patch renames it to "extract_kernel" and updates callers and comments. Additionally the file header comment for misc.c is improved to actually describe what is contained. Suggested-by: Ingo Molnar

[PATCH 3/6] x86, boot: Rename "real_mode" to "boot_params"

The non-compressed boot code uses the (much more obvious) name "boot_params" for the global pointer to the x86 boot parameters. The compressed kernel loader code, though, was using the legacy name "real_mode". There is no need to have a different name, and changing it improves readability.

Re: [PATCH] macsec: fix crypto Kconfig dependency

From: Herbert Xu Date: Mon, 18 Apr 2016 18:43:36 +0800 > Right, the problem is that nothing within crypto ever selects > CRYPTO since it's also used as a way of hiding the crypto menu > options. As far as I understand it, this won't help. Because selects do not

[PATCH 6/6] x86, KASLR: Rename "random" to "random_addr"

The variable "random" is also the name of a libc function. It's better coding style to avoid overloading such things, so rename it to the more accurate "random_addr". Suggested-by: Ingo Molnar Signed-off-by: Kees Cook --- arch/x86/boot/compressed/kaslr.c | 10 +- 1 file changed, 5

[PATCH 4/6] x86, boot: Clarify purpose of functions in misc.c

The function "decompress_kernel" now performs many more duties, so this patch renames it to "extract_kernel" and updates callers and comments. Additionally the file header comment for misc.c is improved to actually describe what is contained. Suggested-by: Ingo Molnar Signed-off-by: Kees Cook

[PATCH 3/6] x86, boot: Rename "real_mode" to "boot_params"

The non-compressed boot code uses the (much more obvious) name "boot_params" for the global pointer to the x86 boot parameters. The compressed kernel loader code, though, was using the legacy name "real_mode". There is no need to have a different name, and changing it improves readability.

Re: [PATCH] macsec: fix crypto Kconfig dependency

From: Herbert Xu Date: Mon, 18 Apr 2016 18:43:36 +0800 > Right, the problem is that nothing within crypto ever selects > CRYPTO since it's also used as a way of hiding the crypto menu > options. As far as I understand it, this won't help. Because selects do not trigger other selects and

[PATCH 2/6] x86, KASLR: Remove unneeded boot_params argument

From: Yinghai Lu Since the boot_params can be found using the real_mode global variable, there is no need to pass around a pointer to it. This slightly simplifies the choose_kernel_location function and its callers. Signed-off-by: Yinghai Lu [kees:

[PATCH 5/6] x86, KASLR: Clarify purpose of kaslr.c

The name "choose_kernel_location" isn't specific enough, and doesn't describe the primary thing it does: choosing a random location. This patch renames it to "choose_random_location", and clarifies the what routines are contained in the kaslr.c source file. Suggested-by: Ingo Molnar

Re: [PATCH v2] carl9170: Clarify kconfig text

Christian Lamparter writes: > On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote: >> Lauri Kasanen writes: >> >> > --- a/drivers/net/wireless/ath/carl9170/Kconfig >> > +++ b/drivers/net/wireless/ath/carl9170/Kconfig >> > @@ -5,12 +5,10 @@ config

[PATCH 2/6] x86, KASLR: Remove unneeded boot_params argument

From: Yinghai Lu Since the boot_params can be found using the real_mode global variable, there is no need to pass around a pointer to it. This slightly simplifies the choose_kernel_location function and its callers. Signed-off-by: Yinghai Lu [kees: rewrote changelog, tracked file rename]

[PATCH 5/6] x86, KASLR: Clarify purpose of kaslr.c

The name "choose_kernel_location" isn't specific enough, and doesn't describe the primary thing it does: choosing a random location. This patch renames it to "choose_random_location", and clarifies the what routines are contained in the kaslr.c source file. Suggested-by: Ingo Molnar

Re: [PATCH v2] carl9170: Clarify kconfig text

Christian Lamparter writes: > On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote: >> Lauri Kasanen writes: >> >> > --- a/drivers/net/wireless/ath/carl9170/Kconfig >> > +++ b/drivers/net/wireless/ath/carl9170/Kconfig >> > @@ -5,12 +5,10 @@ config CARL9170 >> >select FW_LOADER >> >

Re: [PATCH 1/3] ASoC: jack: Add a jack detect callback via codec

On Mon, Apr 18, 2016 at 4:46 AM, Mark Brown wrote: > On Mon, Apr 18, 2016 at 06:20:00PM +0800, Xing Zheng wrote: >> On 2016年04月18日 18:03, Xing Zheng wrote: > >> sound { >> .. >> simple-audio-card,dai-link@0 { >> format = "i2s"; >>

Re: [PATCH 1/3] ASoC: jack: Add a jack detect callback via codec

On Mon, Apr 18, 2016 at 4:46 AM, Mark Brown wrote: > On Mon, Apr 18, 2016 at 06:20:00PM +0800, Xing Zheng wrote: >> On 2016年04月18日 18:03, Xing Zheng wrote: > >> sound { >> .. >> simple-audio-card,dai-link@0 { >> format = "i2s"; >> cpu { >>

Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device

On Mon, Apr 18, 2016 at 04:08:38PM +0200, Oliver Neukum wrote: > On Mon, 2016-04-18 at 06:57 -0700, Guenter Roeck wrote: > > On 04/18/2016 01:32 AM, Oliver Neukum wrote: > > > On Mon, 2016-04-18 at 03:53 +0100, Alexey Klimov wrote: > > >> This patch creates new driver that supports StreamLabs usb

Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device

On Mon, Apr 18, 2016 at 04:08:38PM +0200, Oliver Neukum wrote: > On Mon, 2016-04-18 at 06:57 -0700, Guenter Roeck wrote: > > On 04/18/2016 01:32 AM, Oliver Neukum wrote: > > > On Mon, 2016-04-18 at 03:53 +0100, Alexey Klimov wrote: > > >> This patch creates new driver that supports StreamLabs usb

Re: [PATCH 3/3] gpio: tegra: Add support for gpio debounce

On 04/18/2016 02:46 AM, Laxman Dewangan wrote: NVIDIA's Tegra210 support the HW debounce in the GPIO controller for all its GPIO pins. Add support for setting debounce timing by implementing the set_debounce callback of gpiochip. diff --git a/drivers/gpio/gpio-tegra.c

Re: [PATCH 3/3] gpio: tegra: Add support for gpio debounce

On 04/18/2016 02:46 AM, Laxman Dewangan wrote: NVIDIA's Tegra210 support the HW debounce in the GPIO controller for all its GPIO pins. Add support for setting debounce timing by implementing the set_debounce callback of gpiochip. diff --git a/drivers/gpio/gpio-tegra.c

Re: [PATCH 3.4 00/92] 3.4.112-rc1 review

On Mon, Apr 18, 2016 at 06:45:38PM +0800, l...@kernel.org wrote: > From: Zefan Li > > This is the start of the stable review cycle for the 3.4.112 release. > There are 92 patches in this series, all will be posted as a response > to this one. If anyone has any issues with

Re: [PATCH 3.4 00/92] 3.4.112-rc1 review

On Mon, Apr 18, 2016 at 06:45:38PM +0800, l...@kernel.org wrote: > From: Zefan Li > > This is the start of the stable review cycle for the 3.4.112 release. > There are 92 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

[PATCH v2 1/5] arm64: cpufeature: Add scope for capability check

Add scope parameter to the arm64_cpu_capabilities::matches(), so that this can be reused for checking the capability on a given CPU vs the system wide. The system uses the default scope associated with the capability for initialising the CPU_HWCAPs and ELF_HWCAPs. Cc: James Morse

[PATCH v2 3/5] irqchip/gic: Restore CPU interface checking

From: Marc Zyngier When introducing the whole CPU feature detection framework, we lost the capability to detect a mismatched GIC configuration (using the GICv2 MMIO interface, but having the system register interface enabled). In order to solve this, use the new

[PATCH v2 2/5] arm64: Allow a capability to be checked on a single CPU

From: Marc Zyngier Now that the capabilities are only available once all the CPUs have booted, we're unable to check for a particular feature in any subsystem that gets initialized before then. In order to support this, introduce a local_cpu_has_cap() function that tests

[PATCH v2 3/5] irqchip/gic: Restore CPU interface checking

From: Marc Zyngier When introducing the whole CPU feature detection framework, we lost the capability to detect a mismatched GIC configuration (using the GICv2 MMIO interface, but having the system register interface enabled). In order to solve this, use the new this_cpu_has_cap() helper. Also

[PATCH v2 2/5] arm64: Allow a capability to be checked on a single CPU

From: Marc Zyngier Now that the capabilities are only available once all the CPUs have booted, we're unable to check for a particular feature in any subsystem that gets initialized before then. In order to support this, introduce a local_cpu_has_cap() function that tests for the presence of a

[PATCH v2 1/5] arm64: cpufeature: Add scope for capability check

Add scope parameter to the arm64_cpu_capabilities::matches(), so that this can be reused for checking the capability on a given CPU vs the system wide. The system uses the default scope associated with the capability for initialising the CPU_HWCAPs and ELF_HWCAPs. Cc: James Morse Cc: Marc

[PATCH v2 5/5] arm64: Fix behavior of maxcpus=N

maxcpu=n sets the number of CPUs activated at boot time to a max of n, but allowing the remaining CPUs to be brought up later if the user decides to do so. However, on arm64 due to various reasons, we disallowed hotplugging CPUs beyond n, by marking them not present. Now that we have checks in

[PATCH v2 4/5] arm64: Verify CPU errata work arounds on hotplugged CPU

CPU Errata work arounds are detected and applied to the kernel code at boot time and the data is then freed up. If a new hotplugged CPU requires a work around which was not applied at boot time, there is nothing we can do but simply fail the booting. Cc: Will Deacon Cc: Mark

[PATCH v2 5/5] arm64: Fix behavior of maxcpus=N

maxcpu=n sets the number of CPUs activated at boot time to a max of n, but allowing the remaining CPUs to be brought up later if the user decides to do so. However, on arm64 due to various reasons, we disallowed hotplugging CPUs beyond n, by marking them not present. Now that we have checks in

[PATCH v2 4/5] arm64: Verify CPU errata work arounds on hotplugged CPU

CPU Errata work arounds are detected and applied to the kernel code at boot time and the data is then freed up. If a new hotplugged CPU requires a work around which was not applied at boot time, there is nothing we can do but simply fail the booting. Cc: Will Deacon Cc: Mark Rutland Cc: Andre

[PATCH v2 0/5] arm64: Fix behavior of maxcpus=n

This series is an attempt at fixing the maxcpus=n behavior on arm64. So far we have disabled hotplugging a CPU > n, when maxcpus=n is in effect, due to following reasons. 1) Possible cpu feature incompatibilities with the new CPU in heterogeneous systems. 2) New CPU requiring an errata work

[PATCH v2 0/5] arm64: Fix behavior of maxcpus=n

This series is an attempt at fixing the maxcpus=n behavior on arm64. So far we have disabled hotplugging a CPU > n, when maxcpus=n is in effect, due to following reasons. 1) Possible cpu feature incompatibilities with the new CPU in heterogeneous systems. 2) New CPU requiring an errata work

Re: [PATCH 4.5 000/124] 4.5.2-stable review

On Mon, Apr 18, 2016 at 11:27:52AM +0900, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.5.2 release. > There are 124 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.5 000/124] 4.5.2-stable review

On 04/17/2016 08:27 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.5.2 release. > There are 124 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.5 000/124] 4.5.2-stable review

On Mon, Apr 18, 2016 at 11:27:52AM +0900, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.5.2 release. > There are 124 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.5 000/124] 4.5.2-stable review

On 04/17/2016 08:27 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.5.2 release. > There are 124 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 000/137] 4.4.8-stable review

On Mon, Apr 18, 2016 at 11:27:42AM +0900, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.8 release. > There are 137 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.4 000/137] 4.4.8-stable review

On 04/17/2016 08:27 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.8 release. > There are 137 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 000/137] 4.4.8-stable review

On Mon, Apr 18, 2016 at 11:27:42AM +0900, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.8 release. > There are 137 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.4 000/137] 4.4.8-stable review

On 04/17/2016 08:27 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.8 release. > There are 137 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.14 00/37] 3.14.67-stable review

On 04/17/2016 08:25 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.67 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.14 00/37] 3.14.67-stable review

On 04/17/2016 08:25 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.67 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.14 00/37] 3.14.67-stable review

On Mon, Apr 18, 2016 at 11:25:32AM +0900, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.67 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 3.14 00/37] 3.14.67-stable review

On Mon, Apr 18, 2016 at 11:25:32AM +0900, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.67 release. > There are 37 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

On Mon, Apr 18, 2016 at 06:01:33PM +0200, Arnd Bergmann wrote: > I seem to have only received patches 3 and 4, both on my personal > address and on lkml. Any idea what happened? > Unless you did not mean to send these patches at all, could you resend > the entire series and put me and the y2038

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

On Mon, Apr 18, 2016 at 06:01:33PM +0200, Arnd Bergmann wrote: > I seem to have only received patches 3 and 4, both on my personal > address and on lkml. Any idea what happened? > Unless you did not mean to send these patches at all, could you resend > the entire series and put me and the y2038

Re: [dm-devel] [PATCH 04/42] fs: have submit_bh users pass in op and flags separately

On Fri, 15 Apr 2016 05:39:24 -0500, mchri...@redhat.com wrote: > From: Mike Christie > > This has submit_bh users pass in the operation and flags separately, > so submit_bh_wbc can setup bio->bi_op and bio-bi_rw on the bio that > is submitted. > > Signed-off-by: Mike

Re: [dm-devel] [PATCH 04/42] fs: have submit_bh users pass in op and flags separately

On Fri, 15 Apr 2016 05:39:24 -0500, mchri...@redhat.com wrote: > From: Mike Christie > > This has submit_bh users pass in the operation and flags separately, > so submit_bh_wbc can setup bio->bi_op and bio-bi_rw on the bio that > is submitted. > > Signed-off-by: Mike Christie > Reviewed-by:

Re: [PATCH 2/3] gpio: tegra: Remove the need of keeping device handle for gpio driver

On 04/18/2016 02:46 AM, Laxman Dewangan wrote: Remove the file static device handle variable as this is just required for prints. The required handle can be stored in tegra_gpio_chip and hence it become redundancy. This seems fine as far as it goes, but if it's worth doing this, please move

Re: [PATCH 2/3] gpio: tegra: Remove the need of keeping device handle for gpio driver

On 04/18/2016 02:46 AM, Laxman Dewangan wrote: Remove the file static device handle variable as this is just required for prints. The required handle can be stored in tegra_gpio_chip and hence it become redundancy. This seems fine as far as it goes, but if it's worth doing this, please move

Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

On Mon, Apr 18, 2016 at 06:50:52PM +0300, Peter Ujfalusi wrote: > On 02/17/2016 09:52 PM, Peter Ujfalusi wrote: > > On the other hand this ABI is backwards compatible since if it is missing it > > will default to the configuration we right now have regarding to sysclk_dir > > and sysclk_id. > >

Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID

On Mon, Apr 18, 2016 at 06:50:52PM +0300, Peter Ujfalusi wrote: > On 02/17/2016 09:52 PM, Peter Ujfalusi wrote: > > On the other hand this ABI is backwards compatible since if it is missing it > > will default to the configuration we right now have regarding to sysclk_dir > > and sysclk_id. > >

Re: [PATCH 1/3] gpio: tegra: Don't open code of_device_get_match_data()

On 04/18/2016 02:46 AM, Laxman Dewangan wrote: Use of_device_get_match_data() for getting matched data instead of implementing this locally. This patch, Reviewed-by: Stephen Warren

Re: [PATCH 1/3] gpio: tegra: Don't open code of_device_get_match_data()

On 04/18/2016 02:46 AM, Laxman Dewangan wrote: Use of_device_get_match_data() for getting matched data instead of implementing this locally. This patch, Reviewed-by: Stephen Warren

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, Apr 18, 2016 at 11:51:41AM -0400, David Woodhouse wrote: > On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote: > > > > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > > > its own operating system's IOMMU code is expected to be broken, and > > > that the

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, Apr 18, 2016 at 11:51:41AM -0400, David Woodhouse wrote: > On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote: > > > > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > > > its own operating system's IOMMU code is expected to be broken, and > > > that the

Re: [PATCH v2] carl9170: Clarify kconfig text

On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote: > Lauri Kasanen writes: > > > The previous text was confusing, leading readers to think this > > driver was a duplicate, and so didn't need to be enabled. > > > > After the removal of the older staging driver, this is the only

Re: [PATCH v2] carl9170: Clarify kconfig text

On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote: > Lauri Kasanen writes: > > > The previous text was confusing, leading readers to think this > > driver was a duplicate, and so didn't need to be enabled. > > > > After the removal of the older staging driver, this is the only > > driver in

Re: [PATCH v3] carl9170: Clarify kconfig text

On Monday, April 18, 2016 07:07:39 PM Lauri Kasanen wrote: > The previous text was confusing, leading readers to think this > driver was a duplicate, and so didn't need to be enabled. > > After the removal of the older staging driver, this is the only > driver in mainline for these devices. > >

Re: [PATCH v3] carl9170: Clarify kconfig text

On Monday, April 18, 2016 07:07:39 PM Lauri Kasanen wrote: > The previous text was confusing, leading readers to think this > driver was a duplicate, and so didn't need to be enabled. > > After the removal of the older staging driver, this is the only > driver in mainline for these devices. > >

Re: [PATCH -tip 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()

On Sun, 17 Apr 2016, Davidlohr Bueso wrote: diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h index 72722334237a..ddcd653c942c 100644 --- a/kernel/locking/qspinlock_stat.h +++ b/kernel/locking/qspinlock_stat.h @@ -225,12 +225,18 @@ static int __init

Re: [PATCH -tip 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()

On Sun, 17 Apr 2016, Davidlohr Bueso wrote: diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h index 72722334237a..ddcd653c942c 100644 --- a/kernel/locking/qspinlock_stat.h +++ b/kernel/locking/qspinlock_stat.h @@ -225,12 +225,18 @@ static int __init

Re: rtc ds3232 call trace in kernel

On 18/04/2016 at 06:15:40 +, Qianyu Gong wrote : > Hi Akinobu, > > I got an rtc call trace when booting 4.6 kernel on our board and I found it > was caused by this patch: > > commit fc1dcb0b39dbb10d3290f2fcd6e154670f699166 > Author: Akinobu Mita > Date: Mon Mar 7

Re: rtc ds3232 call trace in kernel

On 18/04/2016 at 06:15:40 +, Qianyu Gong wrote : > Hi Akinobu, > > I got an rtc call trace when booting 4.6 kernel on our board and I found it > was caused by this patch: > > commit fc1dcb0b39dbb10d3290f2fcd6e154670f699166 > Author: Akinobu Mita > Date: Mon Mar 7 00:27:53 2016 +0900 > >

Re: [PATCH net-next 0/8] allow bpf attach to tracepoints

On Mon, 4 Apr 2016 21:52:46 -0700 Alexei Starovoitov wrote: > Hi Steven, Peter, > > last time we discussed bpf+tracepoints it was a year ago [1] and the reason > we didn't proceed with that approach was that bpf would make arguments > arg1, arg2 to trace_xx(arg1, arg2) call to be

Re: [PATCH net-next 0/8] allow bpf attach to tracepoints

On Mon, 4 Apr 2016 21:52:46 -0700 Alexei Starovoitov wrote: > Hi Steven, Peter, > > last time we discussed bpf+tracepoints it was a year ago [1] and the reason > we didn't proceed with that approach was that bpf would make arguments > arg1, arg2 to trace_xx(arg1, arg2) call to be exposed to bpf

Re: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

On Sun, Apr 17, 2016 at 10:22 PM, K. Y. Srinivasan wrote: > On Hyper-V, the VF/PF communication is a via software mediated path > as opposed to the hardware mailbox. Make the necessary > adjustments to support Hyper-V. > > Signed-off-by: K. Y. Srinivasan >

Re: [Intel-wired-lan] [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

On Sun, Apr 17, 2016 at 10:22 PM, K. Y. Srinivasan wrote: > On Hyper-V, the VF/PF communication is a via software mediated path > as opposed to the hardware mailbox. Make the necessary > adjustments to support Hyper-V. > > Signed-off-by: K. Y. Srinivasan > --- > V2: Addressed most of the

Re: /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_set_encrypt_key does not evaluate to a constant

On 04/17, kbuild test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: b9f5dba225aede4518ab0a7374c2dc38c7c049ce > commit: 5eeb50de42fd3251845d03c556db012267c72b3f uprobes: Change > handle_trampoline() to flush the frames invalidated

Re: /tmp/ccTcF8pg.s: Error: .size expression for aes_p8_set_encrypt_key does not evaluate to a constant

On 04/17, kbuild test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: b9f5dba225aede4518ab0a7374c2dc38c7c049ce > commit: 5eeb50de42fd3251845d03c556db012267c72b3f uprobes: Change > handle_trampoline() to flush the frames invalidated

[PATCH v3] carl9170: Clarify kconfig text

The previous text was confusing, leading readers to think this driver was a duplicate, and so didn't need to be enabled. After the removal of the older staging driver, this is the only driver in mainline for these devices. Signed-off-by: Lauri Kasanen --- v3: Remove all firmware

[PATCH v3] carl9170: Clarify kconfig text

The previous text was confusing, leading readers to think this driver was a duplicate, and so didn't need to be enabled. After the removal of the older staging driver, this is the only driver in mainline for these devices. Signed-off-by: Lauri Kasanen --- v3: Remove all firmware mentions.

Re: [PATCH resend 0/3] mm: allow arch to override lowmem_page_address

On 18 April 2016 at 18:04, Ard Biesheuvel wrote: > These patches allow the arch to define the page_to_virt() conversion that > is used in lowmem_page_address(). This is desirable for arm64, where this > conversion is trivial when CONFIG_SPARSEMEM_VMEMMAP is enabled,

Re: [PATCH resend 0/3] mm: allow arch to override lowmem_page_address

On 18 April 2016 at 18:04, Ard Biesheuvel wrote: > These patches allow the arch to define the page_to_virt() conversion that > is used in lowmem_page_address(). This is desirable for arm64, where this > conversion is trivial when CONFIG_SPARSEMEM_VMEMMAP is enabled, while > breaking it up into

[PATCH resend 2/3] openrisc: drop wrongly typed definition of page_to_virt()

To align with generic code and other architectures that expect the macro page_to_virt to produce an expression whose type is 'void*', drop the arch specific definition, which is never referenced anyway. Signed-off-by: Ard Biesheuvel ---

[PATCH resend 2/3] openrisc: drop wrongly typed definition of page_to_virt()

To align with generic code and other architectures that expect the macro page_to_virt to produce an expression whose type is 'void*', drop the arch specific definition, which is never referenced anyway. Signed-off-by: Ard Biesheuvel --- arch/openrisc/include/asm/page.h | 2 -- 1 file changed, 2

[PATCH resend 3/3] mm: replace open coded page to virt conversion with page_to_virt()

The open coded conversion from struct page address to virtual address in lowmem_page_address() involves an intermediate conversion step to pfn number/physical address. Since the placement of the struct page array relative to the linear mapping may be completely independent from the placement of

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/18/2016 11:59 AM, David Miller wrote: > From: ok...@codeaurora.org > Date: Mon, 18 Apr 2016 01:06:27 -0400 > >> On 2016-04-18 00:00, David Miller wrote: >>> From: Sinan Kaya >>> Date: Sat, 16 Apr 2016 18:23:32 -0400 >>> Current code is assuming that the address

[PATCH resend 3/3] mm: replace open coded page to virt conversion with page_to_virt()

The open coded conversion from struct page address to virtual address in lowmem_page_address() involves an intermediate conversion step to pfn number/physical address. Since the placement of the struct page array relative to the linear mapping may be completely independent from the placement of

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/18/2016 11:59 AM, David Miller wrote: > From: ok...@codeaurora.org > Date: Mon, 18 Apr 2016 01:06:27 -0400 > >> On 2016-04-18 00:00, David Miller wrote: >>> From: Sinan Kaya >>> Date: Sat, 16 Apr 2016 18:23:32 -0400 >>> Current code is assuming that the address returned by

[PATCH] mtd: nand: jz4740: Remove unused local variable

Signed-off-by: Maarten ter Huurne --- drivers/mtd/nand/jz4740_nand.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c index 673ceb2..2f39ee1 100644 --- a/drivers/mtd/nand/jz4740_nand.c +++

[PATCH resend 0/3] mm: allow arch to override lowmem_page_address

These patches allow the arch to define the page_to_virt() conversion that is used in lowmem_page_address(). This is desirable for arm64, where this conversion is trivial when CONFIG_SPARSEMEM_VMEMMAP is enabled, while breaking it up into __va(PFN_PHYS(page_to_pfn(page))), as is done currently in

[PATCH] mtd: nand: jz4740: Remove unused local variable

Signed-off-by: Maarten ter Huurne --- drivers/mtd/nand/jz4740_nand.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c index 673ceb2..2f39ee1 100644 --- a/drivers/mtd/nand/jz4740_nand.c +++ b/drivers/mtd/nand/jz4740_nand.c @@

[PATCH resend 0/3] mm: allow arch to override lowmem_page_address

These patches allow the arch to define the page_to_virt() conversion that is used in lowmem_page_address(). This is desirable for arm64, where this conversion is trivial when CONFIG_SPARSEMEM_VMEMMAP is enabled, while breaking it up into __va(PFN_PHYS(page_to_pfn(page))), as is done currently in

[PATCH resend 1/3] nios2: use correct void* return type for page_to_virt()

To align with other architectures, the expression produced by expanding the macro page_to_virt() should be of type void*, since it returns a virtual address. Fix that, and also fix up an instance where page_to_virt was expected to return 'unsigned long', and drop another instance that was entirely

[PATCH resend 1/3] nios2: use correct void* return type for page_to_virt()

To align with other architectures, the expression produced by expanding the macro page_to_virt() should be of type void*, since it returns a virtual address. Fix that, and also fix up an instance where page_to_virt was expected to return 'unsigned long', and drop another instance that was entirely

Re: [PATCH] macsec: fix crypto Kconfig dependency

From: Herbert Xu Date: Mon, 18 Apr 2016 16:02:02 +0800 > In fact this strikes me as a kbuild bug because CRYPTO_GCM already > selects (indirectly) CRYPTO_ALGAPI so why is this happening at all? Selects don't trigger selects.

Re: [PATCH] macsec: fix crypto Kconfig dependency

From: Herbert Xu Date: Mon, 18 Apr 2016 16:02:02 +0800 > In fact this strikes me as a kbuild bug because CRYPTO_GCM already > selects (indirectly) CRYPTO_ALGAPI so why is this happening at all? Selects don't trigger selects.

Re: [PATCH 16/42] nilfs: set bi_op to REQ_OP

On Fri, 15 Apr 2016 14:15:51 -0500, mchri...@redhat.com wrote: > From: Mike Christie > > This patch has nilfs use bio->bi_op for REQ_OPs and rq_flag_bits > to bio->bi_rw. > > Signed-off-by: Mike Christie > Reviewed-by: Christoph Hellwig >

Re: [PATCH 16/42] nilfs: set bi_op to REQ_OP

On Fri, 15 Apr 2016 14:15:51 -0500, mchri...@redhat.com wrote: > From: Mike Christie > > This patch has nilfs use bio->bi_op for REQ_OPs and rq_flag_bits > to bio->bi_rw. > > Signed-off-by: Mike Christie > Reviewed-by: Christoph Hellwig > Reviewed-by: Hannes Reinecke > --- >

RE: [PATCH 1/1] perf tools: Fix format value calculation

Hi all, There is confusion about the usage of format for me. E.g. The event config is not continuous for uncore. cat /sys/devices/uncore_qpi_0/format/event config:0-7,21 I once thought that the user input should be uncore_qpi_0/event=0x200038,/ So I submitted this patch and previous patch

RE: [PATCH 1/1] perf tools: Fix format value calculation

Hi all, There is confusion about the usage of format for me. E.g. The event config is not continuous for uncore. cat /sys/devices/uncore_qpi_0/format/event config:0-7,21 I once thought that the user input should be uncore_qpi_0/event=0x200038,/ So I submitted this patch and previous patch

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

On Friday 08 April 2016 14:02:11 Baolin Wang wrote: > security_settime() uses a timespec, which is not year 2038 safe > on 32bit systems. Thus this patch introduces the security_settime64() > function with timespec64 type. We also convert the cap_settime() helper > function to use the 64bit types.

Re: [RESEND PATCH v2 3/5] security: Introduce security_settime64()

On Friday 08 April 2016 14:02:11 Baolin Wang wrote: > security_settime() uses a timespec, which is not year 2038 safe > on 32bit systems. Thus this patch introduces the security_settime64() > function with timespec64 type. We also convert the cap_settime() helper > function to use the 64bit types.

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