[PATCH 2/5] lib/digsig: digsig_verify_rsa(): return -EINVAL if modulo length is zero

Currently, if digsig_verify_rsa() detects that the modulo's length is zero, i.e. mlen == 0, it returns -ENOMEM which doesn't really fit here. Make digsig_verify_rsa() return -EINVAL upon mlen == 0. Signed-off-by: Nicolai Stange --- lib/digsig.c | 8 +--- 1 file

[PATCH 2/5] lib/digsig: digsig_verify_rsa(): return -EINVAL if modulo length is zero

Currently, if digsig_verify_rsa() detects that the modulo's length is zero, i.e. mlen == 0, it returns -ENOMEM which doesn't really fit here. Make digsig_verify_rsa() return -EINVAL upon mlen == 0. Signed-off-by: Nicolai Stange --- lib/digsig.c | 8 +--- 1 file changed, 5 insertions(+), 3

[PATCH 5/5] lib/mpi: refactor mpi_read_from_buffer() in terms of mpi_read_raw_data()

mpi_read_from_buffer() and mpi_read_raw_data() do basically the same thing except that the former extracts the number of payload bits from the first two bytes of the input buffer. Besides that, the data copying logic is exactly the same. Replace the open coded buffer to MPI instance conversion

[PATCH 5/5] lib/mpi: refactor mpi_read_from_buffer() in terms of mpi_read_raw_data()

mpi_read_from_buffer() and mpi_read_raw_data() do basically the same thing except that the former extracts the number of payload bits from the first two bytes of the input buffer. Besides that, the data copying logic is exactly the same. Replace the open coded buffer to MPI instance conversion

[PATCH 4/5] lib/mpi: mpi_read_from_buffer(): sanitize short buffer printk

The first two bytes of the input buffer encode its expected length and mpi_read_from_buffer() prints a console message if the given buffer is too short. However, there are some oddities with how this message is printed: - It is printed at the default loglevel. This is different from the one

[PATCH 4/5] lib/mpi: mpi_read_from_buffer(): sanitize short buffer printk

The first two bytes of the input buffer encode its expected length and mpi_read_from_buffer() prints a console message if the given buffer is too short. However, there are some oddities with how this message is printed: - It is printed at the default loglevel. This is different from the one

[PATCH 3/5] lib/mpi: mpi_read_from_buffer(): return -EINVAL upon too short buffer

Currently, if the input buffer is shorter than the expected length as indicated by its first two bytes, an MPI instance of this expected length will be allocated and filled with as much data as is available. The rest will remain uninitialized. Instead of leaving this condition undetected, an

[PATCH 0/5] refactor mpi_read_from_buffer()

mpi_read_from_buffer() and mpi_read_raw_data() do almost the same and share a fair amount of common code. This patchset attempts to rewrite mpi_read_from_buffer() in order to implement it in terms of mpi_read_raw_data(). The patches 1 and 3, i.e. "lib/mpi: mpi_read_from_buffer(): return error

[PATCH 3/5] lib/mpi: mpi_read_from_buffer(): return -EINVAL upon too short buffer

Currently, if the input buffer is shorter than the expected length as indicated by its first two bytes, an MPI instance of this expected length will be allocated and filled with as much data as is available. The rest will remain uninitialized. Instead of leaving this condition undetected, an

[PATCH 0/5] refactor mpi_read_from_buffer()

mpi_read_from_buffer() and mpi_read_raw_data() do almost the same and share a fair amount of common code. This patchset attempts to rewrite mpi_read_from_buffer() in order to implement it in terms of mpi_read_raw_data(). The patches 1 and 3, i.e. "lib/mpi: mpi_read_from_buffer(): return error

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 1:10 PM, Al Viro wrote: > > How about the things like followups to earlier merges? Small and obvious follow-ups are fine. What I really hated about this ceph pull request was that it was multiple thousand lines of changes, with no previous work or

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 1:10 PM, Al Viro wrote: > > How about the things like followups to earlier merges? Small and obvious follow-ups are fine. What I really hated about this ceph pull request was that it was multiple thousand lines of changes, with no previous work or warning, and effectively

Re: [RFC 1/5] usb: chipidea: Add support for Tegra20/30/114/124

On 05/26/2016 09:40 AM, Thierry Reding wrote: From: Thierry Reding All of these Tegra SoC generations have a ChipIdea UDC IP block that can be used for device mode communication with a host. Implement rudimentary support that doesn't allow switching between host and device

Re: [RFC 1/5] usb: chipidea: Add support for Tegra20/30/114/124

On 05/26/2016 09:40 AM, Thierry Reding wrote: From: Thierry Reding All of these Tegra SoC generations have a ChipIdea UDC IP block that can be used for device mode communication with a host. Implement rudimentary support that doesn't allow switching between host and device modes. Are you

Re: [PATCH v2 0/6] of: overlays: New target methods

On 5/16/2016 1:18 PM, Pantelis Antoniou wrote: > This patchset implements two new target methods. > > A target index method which allows selecting different > targets according to an argument using an extended API and > a target root method that fences the target only > to a specific given root.

Re: [PATCH v2 0/6] of: overlays: New target methods

On 5/16/2016 1:18 PM, Pantelis Antoniou wrote: > This patchset implements two new target methods. > > A target index method which allows selecting different > targets according to an argument using an extended API and > a target root method that fences the target only > to a specific given root.

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 11:31 AM, Linus Torvalds wrote: > > Pulled and then immediately unpulled again. .. and having thought it over, I ended up re-pulling again, so now it's going through my build test. Consider this discussion a strong encouragement to *not* do

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 11:31 AM, Linus Torvalds wrote: > > Pulled and then immediately unpulled again. .. and having thought it over, I ended up re-pulling again, so now it's going through my build test. Consider this discussion a strong encouragement to *not* do this in the future - sending

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On 5/26/2016 10:19 AM, Peter Zijlstra wrote: --- a/arch/tile/lib/spinlock_32.c +++ b/arch/tile/lib/spinlock_32.c @@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock if (next == curr) return; + smp_rmb(); + /* Wait until the current locker has released

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

On 5/26/2016 10:19 AM, Peter Zijlstra wrote: --- a/arch/tile/lib/spinlock_32.c +++ b/arch/tile/lib/spinlock_32.c @@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock if (next == curr) return; + smp_rmb(); + /* Wait until the current locker has released

Re: [PATCH 16/23] arm64: ilp32: introduce binfmt_ilp32.c

On Thu, May 26, 2016 at 09:49:42PM +0800, Zhangjian (Bamvor) wrote: > Hi, yury > > The coredump is usable in our platform. It miss the following definition: > +#define compat_elf_greg_telf_greg_t > +#define compat_elf_gregset_t elf_gregset_t > > And it leads to the wrong register save in

Re: [PATCH 16/23] arm64: ilp32: introduce binfmt_ilp32.c

On Thu, May 26, 2016 at 09:49:42PM +0800, Zhangjian (Bamvor) wrote: > Hi, yury > > The coredump is usable in our platform. It miss the following definition: > +#define compat_elf_greg_telf_greg_t > +#define compat_elf_gregset_t elf_gregset_t > > And it leads to the wrong register save in

[PATCH] pwm: don't allow duty cycle higher than period

It doesn't make sense to allow the duty cycle to be larger than the period. I can see this behavior by, e.g.: # echo 1 > /sys/class/pwm/pwmchip0/export # cat /sys/class/pwm/pwmchip0/pwm1/period 100 # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle [... driver may or may not reject

[PATCH] pwm: don't allow duty cycle higher than period

It doesn't make sense to allow the duty cycle to be larger than the period. I can see this behavior by, e.g.: # echo 1 > /sys/class/pwm/pwmchip0/export # cat /sys/class/pwm/pwmchip0/pwm1/period 100 # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle [... driver may or may not reject

[PATCH] seccomp: plug syscall-dodging ptrace hole

One problem with seccomp was that ptrace could be used to change a syscall after seccomp filtering had completed. This was a well documented limitation, and it was recommended to block ptrace when defining a filter to avoid this problem. This can be quite a limitation for containers or other

[PATCH] seccomp: plug syscall-dodging ptrace hole

One problem with seccomp was that ptrace could be used to change a syscall after seccomp filtering had completed. This was a well documented limitation, and it was recommended to block ptrace when defining a filter to avoid this problem. This can be quite a limitation for containers or other

OFERTA Y PERSONAL préstamo de negocios

Hola Am Dr. Eric, legítimo y confiable prestamista préstamo de Skye de Servicios Financieros. Ofrecemos préstamos en una forma clara y comprensible y condiciones en la tasa de interés del 3%. De $ 5,000.00 a $ 450,000,000.00USD y Euros Solo. Nos ofrecen préstamos de negocios, préstamos

OFERTA Y PERSONAL préstamo de negocios

Hola Am Dr. Eric, legítimo y confiable prestamista préstamo de Skye de Servicios Financieros. Ofrecemos préstamos en una forma clara y comprensible y condiciones en la tasa de interés del 3%. De $ 5,000.00 a $ 450,000,000.00USD y Euros Solo. Nos ofrecen préstamos de negocios, préstamos

Re: [PATCH] devicetree - document using aliases to set spi bus number.

On 05/26/2016 08:47 PM, Mark Brown wrote: > On Thu, May 26, 2016 at 12:58:22PM +0200, Christer Weinigel wrote: > >> One of the main drivers behind devicetree was that Linus got fed >> up with the churn for all platform device changes in arch/arm. >> I faintly recall him writing that he would be

Re: [PATCH] devicetree - document using aliases to set spi bus number.

On 05/26/2016 08:47 PM, Mark Brown wrote: > On Thu, May 26, 2016 at 12:58:22PM +0200, Christer Weinigel wrote: > >> One of the main drivers behind devicetree was that Linus got fed >> up with the churn for all platform device changes in arch/arm. >> I faintly recall him writing that he would be

Re: [Regression?] iptables broken on 32bit with pre-4.7-rc

On Thu, May 26, 2016 at 2:51 AM, Florian Westphal wrote: > John Stultz wrote: >> In updating a 32bit arm device from 4.6 to Linus' current HEAD, I >> noticed I was having some trouble with networking, and realized that >> /proc/net/ip_tables_names was

Re: [Regression?] iptables broken on 32bit with pre-4.7-rc

On Thu, May 26, 2016 at 2:51 AM, Florian Westphal wrote: > John Stultz wrote: >> In updating a 32bit arm device from 4.6 to Linus' current HEAD, I >> noticed I was having some trouble with networking, and realized that >> /proc/net/ip_tables_names was suddenly empty. >> >> Digging through the

Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

On Thu, May 26, 2016 at 3:30 AM, Felipe Balbi wrote: > > Hi, > > Leo Li writes: On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set to be able to do DMA allocations, so use the of_dma_configure() helper to

Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

On Thu, May 26, 2016 at 3:30 AM, Felipe Balbi wrote: > > Hi, > > Leo Li writes: On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set to be able to do DMA allocations, so use the of_dma_configure() helper to populate the dma properties and assign an appropriate

[GIT PULL] kbuild misc changes for v4.7-rc1

Hi Linus, this is the non-critical part of kbuild: - Coccinelle fixes, one semantic patch less in this round [Vaishali Thakkar, Wolfram Sang, Kees Cook] - rpm-pkg support for (open)SUSE's update-bootloader [Jiří Kosian] - rpm-pkg restored support for $RPMOPTS [Srinivas Pandruvada] - deb-pkg

[GIT PULL] kbuild misc changes for v4.7-rc1

Hi Linus, this is the non-critical part of kbuild: - Coccinelle fixes, one semantic patch less in this round [Vaishali Thakkar, Wolfram Sang, Kees Cook] - rpm-pkg support for (open)SUSE's update-bootloader [Jiří Kosian] - rpm-pkg restored support for $RPMOPTS [Srinivas Pandruvada] - deb-pkg

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

Hi Lorenzo, On Thu, May 26, 2016 at 5:34 AM, Lorenzo Pieralisi wrote: > Hi Duc, > > On Wed, May 25, 2016 at 04:13:35PM -0700, Duc Dang wrote: >> On Thu, Feb 25, 2016 at 9:38 AM, Lorenzo Pieralisi >> wrote: >> > On Wed, Feb 24, 2016 at

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

Hi Lorenzo, On Thu, May 26, 2016 at 5:34 AM, Lorenzo Pieralisi wrote: > Hi Duc, > > On Wed, May 25, 2016 at 04:13:35PM -0700, Duc Dang wrote: >> On Thu, Feb 25, 2016 at 9:38 AM, Lorenzo Pieralisi >> wrote: >> > On Wed, Feb 24, 2016 at 02:28:10PM -0800, Duc Dang wrote: >> >> On Wed, Feb 24, 2016

Re: [PATCH percpu/for-4.7-fixes 1/2] percpu: fix synchronization between chunk->map_extend_work and chunk destruction

On 26.5.2016 21:21, Tejun Heo wrote: > Hello, > > On Thu, May 26, 2016 at 11:19:06AM +0200, Vlastimil Babka wrote: >>> if (is_atomic) { >>> margin = 3; >>> >>> if (chunk->map_alloc < >>> - chunk->map_used + PCPU_ATOMIC_MAP_MARGIN_LOW && >>> -

Re: [PATCH percpu/for-4.7-fixes 1/2] percpu: fix synchronization between chunk->map_extend_work and chunk destruction

On 26.5.2016 21:21, Tejun Heo wrote: > Hello, > > On Thu, May 26, 2016 at 11:19:06AM +0200, Vlastimil Babka wrote: >>> if (is_atomic) { >>> margin = 3; >>> >>> if (chunk->map_alloc < >>> - chunk->map_used + PCPU_ATOMIC_MAP_MARGIN_LOW && >>> -

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wed, May 25, 2016 at 02:28:21PM -0700, David Miller wrote: > From: Arnd Bergmann > Date: Wed, 25 May 2016 23:01:06 +0200 > > > On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: > >> From: Arnd Bergmann > >> Date: Wed, 25 May 2016 22:47:33 +0200 > >>

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wed, May 25, 2016 at 02:28:21PM -0700, David Miller wrote: > From: Arnd Bergmann > Date: Wed, 25 May 2016 23:01:06 +0200 > > > On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote: > >> From: Arnd Bergmann > >> Date: Wed, 25 May 2016 22:47:33 +0200 > >> > >> > If we use the normal

Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

On Thu, May 26, 2016 at 10:39:31PM +0200, Radim Krčmář wrote: > 2016-05-26 10:32+0300, km...@yandex-team.ru: > > From: Dmitry Bilunov > > > > Intel CPUs having Turbo Boost feature implement an MSR to provide a > > control interface via rdmsr/wrmsr instructions. One could

Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

On Thu, May 26, 2016 at 10:39:31PM +0200, Radim Krčmář wrote: > 2016-05-26 10:32+0300, km...@yandex-team.ru: > > From: Dmitry Bilunov > > > > Intel CPUs having Turbo Boost feature implement an MSR to provide a > > control interface via rdmsr/wrmsr instructions. One could detect the > > presence

[GIT PULL] kconfig updates for v4.7-rc1

Hi Linus, Please pull these kconfig fixes for v4.7-rc1: - Fix for behavior of tristate choice items and fix for documentation of existing kconfig behavior [Dirk Gouders] - More helpful "unexpected data" kconfig warning [Paul Bolle] Thanks, Michal The following changes since commit

[GIT PULL] kconfig updates for v4.7-rc1

Hi Linus, Please pull these kconfig fixes for v4.7-rc1: - Fix for behavior of tristate choice items and fix for documentation of existing kconfig behavior [Dirk Gouders] - More helpful "unexpected data" kconfig warning [Paul Bolle] Thanks, Michal The following changes since commit

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On Thu, 26 May 2016 12:26:27 +0200 Paolo Bonzini wrote: > > > On 25/05/2016 04:47, Wanpeng Li wrote: > > From: Wanpeng Li > > > > If an emulated lapic timer will fire soon(in the scope of 10us the > > base of dynamic halt-polling, lower-end of

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

On Thu, 26 May 2016 12:26:27 +0200 Paolo Bonzini wrote: > > > On 25/05/2016 04:47, Wanpeng Li wrote: > > From: Wanpeng Li > > > > If an emulated lapic timer will fire soon(in the scope of 10us the > > base of dynamic halt-polling, lower-end of message passing workload > > latency TCP_RR's

Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

2016-05-26 10:32+0300, km...@yandex-team.ru: > From: Dmitry Bilunov > > Intel CPUs having Turbo Boost feature implement an MSR to provide a > control interface via rdmsr/wrmsr instructions. One could detect the > presence of this feature by issuing one of these instructions

Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

2016-05-26 10:32+0300, km...@yandex-team.ru: > From: Dmitry Bilunov > > Intel CPUs having Turbo Boost feature implement an MSR to provide a > control interface via rdmsr/wrmsr instructions. One could detect the > presence of this feature by issuing one of these instructions and > handling the

Re: [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers

On 5/26/2016 12:48 AM, Bjorn Andersson wrote: > On Tue 24 May 12:54 PDT 2016, Neil Leeder wrote: > >> >> >> On 5/24/2016 07:23 AM, Mark Rutland wrote: >>> On Mon, May 23, 2016 at 02:22:59PM -0400, Neil Leeder wrote: On 5/23/2016 01:25 PM, Mark Rutland wrote: > On Fri, May 20, 2016

Re: [PATCH] soc: qcom: provide mechanism for drivers to access L2 registers

On 5/26/2016 12:48 AM, Bjorn Andersson wrote: > On Tue 24 May 12:54 PDT 2016, Neil Leeder wrote: > >> >> >> On 5/24/2016 07:23 AM, Mark Rutland wrote: >>> On Mon, May 23, 2016 at 02:22:59PM -0400, Neil Leeder wrote: On 5/23/2016 01:25 PM, Mark Rutland wrote: > On Fri, May 20, 2016

[PATCH v1 1/2] mm: Reorganize SLAB freelist randomization

chosen because they provide a bit more entropy early on boot and better performance when specific arch instructions are not available. Signed-off-by: Thomas Garnier <thgar...@google.com> Reviewed-by: Kees Cook <keesc...@chromium.org> --- Based on next-20160526 --- include/linux/sla

[PATCH v1 1/2] mm: Reorganize SLAB freelist randomization

chosen because they provide a bit more entropy early on boot and better performance when specific arch instructions are not available. Signed-off-by: Thomas Garnier Reviewed-by: Kees Cook --- Based on next-20160526 --- include/linux/slab_def.h | 2 +- mm/slab.c| 80

[PATCH v1 2/2] mm: SLUB Freelist randomization

Context Switches 189140 (2282.15) Sleeps 99008.6 (768.091) After: Average Optimal load -j 12 Run (std deviation): Elapsed Time 102.47 (0.562732) User Time 1045.3 (1.34263) System Time 88.311 (0.342554) Percent CPU 1105.8 (6.49444) Context Switches 189081 (2355.78) Sleeps 99231.5 (800.358)

[PATCH v1 2/2] mm: SLUB Freelist randomization

Context Switches 189140 (2282.15) Sleeps 99008.6 (768.091) After: Average Optimal load -j 12 Run (std deviation): Elapsed Time 102.47 (0.562732) User Time 1045.3 (1.34263) System Time 88.311 (0.342554) Percent CPU 1105.8 (6.49444) Context Switches 189081 (2355.78) Sleeps 99231.5 (800.358) Signed-

[PATCH v1 0/2] mm: SLUB Freelist randomization

This is PATCH v1 for the SLUB Freelist randomization. The patch is now based on the Linux master branch (as the based SLAB patch was merged). Changes since RFC v2: - Redone slab_test testing to decide best entropy approach on new page creation. - Moved to use get_random_int as best approach

[PATCH v1 0/2] mm: SLUB Freelist randomization

This is PATCH v1 for the SLUB Freelist randomization. The patch is now based on the Linux master branch (as the based SLAB patch was merged). Changes since RFC v2: - Redone slab_test testing to decide best entropy approach on new page creation. - Moved to use get_random_int as best approach

[GIT PULL] kbuild updates for v4.7-rc1

Hi Linus, please pull these kbuild changes for v4.7-rc1: - New option CONFIG_TRIM_UNUSED_KSYMS which does a two-pass build and unexports symbols which are not used in the current config [Nicolas Pitre] - Several kbuild rule cleanups [Masahiro Yamada] - Warning option adjustments for gcov etc

[GIT PULL] kbuild updates for v4.7-rc1

Hi Linus, please pull these kbuild changes for v4.7-rc1: - New option CONFIG_TRIM_UNUSED_KSYMS which does a two-pass build and unexports symbols which are not used in the current config [Nicolas Pitre] - Several kbuild rule cleanups [Masahiro Yamada] - Warning option adjustments for gcov etc

Re: [PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()

On Fri, May 27, 2016 at 01:07:33AM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > create_workqueue has been replaced with alloc_workqueue with max_active > as 0 since there is no need for throttling the number of active work items. > >

Re: [PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()

On Fri, May 27, 2016 at 01:07:33AM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > create_workqueue has been replaced with alloc_workqueue with max_active > as 0 since there is no need for throttling the number of active work items. > >

Re: [PATCH v7 00/10] Add error checking to spi-nor read and write

Hello, On 18 May 2016 at 03:24, Brian Norris wrote: > On Mon, May 16, 2016 at 09:47:20PM +0200, Michal Suchanek wrote: >> Hello, >> >> On 6 May 2016 at 02:31, Brian Norris wrote: >> > Hi, >> > >> > I'm picking up Michal's patch set,

Re: [PATCH v7 00/10] Add error checking to spi-nor read and write

Hello, On 18 May 2016 at 03:24, Brian Norris wrote: > On Mon, May 16, 2016 at 09:47:20PM +0200, Michal Suchanek wrote: >> Hello, >> >> On 6 May 2016 at 02:31, Brian Norris wrote: >> > Hi, >> > >> > I'm picking up Michal's patch set, since he dropped it on the floor, and >> > it's >> > useful

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 12:54:27PM -0700, Linus Torvalds wrote: > Having entirely new pull requests show up that haven't even been on my > radar because they weren't in linux-next is annoying. How about the things like followups to earlier merges? I've got in #for-linus update

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 12:54:27PM -0700, Linus Torvalds wrote: > Having entirely new pull requests show up that haven't even been on my > radar because they weren't in linux-next is annoying. How about the things like followups to earlier merges? I've got in #for-linus update

[PATCH] mutex: Report recursive ww_mutex locking early

Recursive locking for ww_mutexes was originally conceived as an exception. However, it is heavily used by the DRM atomic modesetting code. Currently, the recursive deadlock is checked after we have queued up for a busy-spin and as we never release the lock, we spin until kicked, whereupon the

[PATCH] mutex: Report recursive ww_mutex locking early

Recursive locking for ww_mutexes was originally conceived as an exception. However, it is heavily used by the DRM atomic modesetting code. Currently, the recursive deadlock is checked after we have queued up for a busy-spin and as we never release the lock, we spin until kicked, whereupon the

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 12:02 PM, Sage Weil wrote: > > The branch was assembled in its current form yesterday and is included in > today's -next: So that's what I *don't* want, and it's not the point of "next". The next branch is about the *next* merge window. If it was about

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, May 26, 2016 at 12:02 PM, Sage Weil wrote: > > The branch was assembled in its current form yesterday and is included in > today's -next: So that's what I *don't* want, and it's not the point of "next". The next branch is about the *next* merge window. If it was about the current one,

Re: [PATCH 01/23] all: syscall wrappers: add documentation

From: Catalin Marinas Date: Thu, 26 May 2016 15:20:58 +0100 > We can solve (a) by adding more __SC_WRAP annotations in the generic > unistd.h. ... I really think it's much more robust to clear the tops of the registers by default. Then you won't be auditing constantly

Re: [PATCH 01/23] all: syscall wrappers: add documentation

From: Catalin Marinas Date: Thu, 26 May 2016 15:20:58 +0100 > We can solve (a) by adding more __SC_WRAP annotations in the generic > unistd.h. ... I really think it's much more robust to clear the tops of the registers by default. Then you won't be auditing constantly and adding more and more

[PATCH cgroup/for-4.7-fixes] cgroup: set css->id to -1 during init

Hello, A follow-up patch. Will queue in cgroup/for-4.7-fixes. Thanks. -- 8< -- If percpu_ref initialization fails during css_create(), the free path can end up trying to free css->id of zero. As ID 0 is unused, it doesn't cause a critical breakage but it does trigger a warning message.

[PATCH cgroup/for-4.7-fixes] cgroup: set css->id to -1 during init

Hello, A follow-up patch. Will queue in cgroup/for-4.7-fixes. Thanks. -- 8< -- If percpu_ref initialization fails during css_create(), the free path can end up trying to free css->id of zero. As ID 0 is unused, it doesn't cause a critical breakage but it does trigger a warning message.

[PATCH 2/2][v4] i2c: qup: support SMBus block read

From: Naveen Kaje I2C QUP driver relies on SMBus emulation support from the framework. To handle SMBus block reads, the driver should check I2C_M_RECV_LEN flag and should read the first byte received as the message length. The driver configures the QUP hardware to read one

[PATCH 2/2][v4] i2c: qup: support SMBus block read

From: Naveen Kaje I2C QUP driver relies on SMBus emulation support from the framework. To handle SMBus block reads, the driver should check I2C_M_RECV_LEN flag and should read the first byte received as the message length. The driver configures the QUP hardware to read one byte. Once the

[PATCH 1/2][v3] i2c: qup: add ACPI support

From: Naveen Kaje Add support to get the device parameters from ACPI. Assume that the clocks are managed by firmware. Signed-off-by: Naveen Kaje Signed-off-by: Austin Christ --- drivers/i2c/busses/i2c-qup.c | 60

[PATCH 1/2][v3] i2c: qup: add ACPI support

From: Naveen Kaje Add support to get the device parameters from ACPI. Assume that the clocks are managed by firmware. Signed-off-by: Naveen Kaje Signed-off-by: Austin Christ --- drivers/i2c/busses/i2c-qup.c | 60 1 file changed, 44 insertions(+),

[PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()

alloc_workqueue replaces deprecated create_workqueue(). create_workqueue has been replaced with alloc_workqueue with max_active as 0 since there is no need for throttling the number of active work items. WQ_MEM_RECLAIM has not been set to because kfd_process_wq will not be used in memory reclaim

[PATCH v2] gpu: drm: amd: amdkfd: Remove create_workqueue()

alloc_workqueue replaces deprecated create_workqueue(). create_workqueue has been replaced with alloc_workqueue with max_active as 0 since there is no need for throttling the number of active work items. WQ_MEM_RECLAIM has not been set to because kfd_process_wq will not be used in memory reclaim

Re: [PATCH resend v2] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data

On Tue, Apr 12, 2016 at 12:42:11AM +0300, Cyrill Gorcunov wrote: ... > I think so. At least this gives some kind of consistensy while we're > fetching data. Something close to peeking data from pipes/sockets. > > > In that case, I think just write trylocking the termios rwsem should > > prevent

Re: [PATCH resend v2] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data

On Tue, Apr 12, 2016 at 12:42:11AM +0300, Cyrill Gorcunov wrote: ... > I think so. At least this gives some kind of consistensy while we're > fetching data. Something close to peeking data from pipes/sockets. > > > In that case, I think just write trylocking the termios rwsem should > > prevent

[PATCH] fbtft: limit transfer length by spi device limit

Some SPI controllers can transfer only small piece of data at a time. Since SPI core gained a function to get the maximum transfer length use it. Signed-off-by: Michal Suchanek --- Tested on sunxi spi with DMA enabled and disabled. Makes a visible speed difference and

[PATCH] fbtft: limit transfer length by spi device limit

Some SPI controllers can transfer only small piece of data at a time. Since SPI core gained a function to get the maximum transfer length use it. Signed-off-by: Michal Suchanek --- Tested on sunxi spi with DMA enabled and disabled. Makes a visible speed difference and display works in either

[PATCH] usb: select NOP_USB_XCEIV by drivers that require it

Hello, I was updating my config by make oldconfig for a while and noticed that my USB OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV over time. Looking through defconfigs some have it included and some which seem in need of it don't. Since the dependency is not

[PATCH] usb: select NOP_USB_XCEIV by drivers that require it

Hello, I was updating my config by make oldconfig for a while and noticed that my USB OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV over time. Looking through defconfigs some have it included and some which seem in need of it don't. Since the dependency is not

Re: [PATCH v2] net: alx: use custom skb allocator

From: Feng Tang Date: Thu, 26 May 2016 16:41:55 +0800 > Maybe the driver maintainer from Atheros could take a look, as they > can reach all the real HWs :) Don't hold your breath.

Re: [PATCH v2] net: alx: use custom skb allocator

From: Feng Tang Date: Thu, 26 May 2016 16:41:55 +0800 > Maybe the driver maintainer from Atheros could take a look, as they > can reach all the real HWs :) Don't hold your breath.

Re: [PATCH v12 07/10] arm64: kprobes instruction simulation support

On 05/18/2016 09:52 PM, Huang Shijie wrote: On Wed, Apr 27, 2016 at 02:53:02PM -0400, David Long wrote: From: Sandeepa Prabhu Kprobes needs simulation of instructions that cannot be stepped from a different memory location, e.g.: those instructions that uses

Re: [PATCH v12 07/10] arm64: kprobes instruction simulation support

On 05/18/2016 09:52 PM, Huang Shijie wrote: On Wed, Apr 27, 2016 at 02:53:02PM -0400, David Long wrote: From: Sandeepa Prabhu Kprobes needs simulation of instructions that cannot be stepped from a different memory location, e.g.: those instructions that uses PC-relative addressing. In

Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

On 05/17/2016 11:29 PM, Masami Hiramatsu wrote: On Tue, 17 May 2016 16:58:09 +0800 Huang Shijie wrote: On Wed, Apr 27, 2016 at 02:53:00PM -0400, David Long wrote: + +/* + * Interrupts need to be disabled before single-step mode is set, and not + * reenabled until after

Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

On 05/17/2016 11:29 PM, Masami Hiramatsu wrote: On Tue, 17 May 2016 16:58:09 +0800 Huang Shijie wrote: On Wed, Apr 27, 2016 at 02:53:00PM -0400, David Long wrote: + +/* + * Interrupts need to be disabled before single-step mode is set, and not + * reenabled until after single-step mode ends.

Re: [PATCH percpu/for-4.7-fixes 1/2] percpu: fix synchronization between chunk->map_extend_work and chunk destruction

Hello, On Thu, May 26, 2016 at 11:19:06AM +0200, Vlastimil Babka wrote: > > if (is_atomic) { > > margin = 3; > > > > if (chunk->map_alloc < > > - chunk->map_used + PCPU_ATOMIC_MAP_MARGIN_LOW && > > - pcpu_async_enabled) > > -

Re: [PATCH percpu/for-4.7-fixes 1/2] percpu: fix synchronization between chunk->map_extend_work and chunk destruction

Hello, On Thu, May 26, 2016 at 11:19:06AM +0200, Vlastimil Babka wrote: > > if (is_atomic) { > > margin = 3; > > > > if (chunk->map_alloc < > > - chunk->map_used + PCPU_ATOMIC_MAP_MARGIN_LOW && > > - pcpu_async_enabled) > > -

[PATCH] cgroup: remove redundant cleanup in css_create

Hello, Nice catch. I added more details to the changelog, tagged it for -stable and applied it to cgroup/for-4.7-fixes. Thanks! -- 8< -- >From b00c52dae6d9ee8d0f2407118ef6544ae5524781 Mon Sep 17 00:00:00 2001 From: Wenwei Tao Date: Fri, 13 May 2016 22:59:20 +0800

[PATCH] cgroup: remove redundant cleanup in css_create

Hello, Nice catch. I added more details to the changelog, tagged it for -stable and applied it to cgroup/for-4.7-fixes. Thanks! -- 8< -- >From b00c52dae6d9ee8d0f2407118ef6544ae5524781 Mon Sep 17 00:00:00 2001 From: Wenwei Tao Date: Fri, 13 May 2016 22:59:20 +0800 When create css

[PATCH] arm64: kasan: instrument user memory access API

The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef ("x86/kasan: instrument user memory access API") added KASAN instrument to x86 user memory access API, so added such instrument to ARM64 too. Tested by test_kasan module. Signed-off-by: Yang Shi ---

[PATCH] arm64: kasan: instrument user memory access API

The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef ("x86/kasan: instrument user memory access API") added KASAN instrument to x86 user memory access API, so added such instrument to ARM64 too. Tested by test_kasan module. Signed-off-by: Yang Shi --- arch/arm64/include/asm/uaccess.h |

Re: [GIT PULL] Ceph updates for 4.7-rc1

On Thu, 26 May 2016, Linus Torvalds wrote: > On Thu, May 26, 2016 at 11:18 AM, Sage Weil wrote: > > > > Please pull the following Ceph updates from > > Why was that branch rebased yesterday? > > What has been in next, if anything? > > And if something has been in next, why

[2/2] pci: Add PCIe driver for Rockchip Soc

> RK3399 has a PCIe controller which can be used as Root Complex. > This driver supports a PCIe controller as Root Complex mode. 1 general feedback I have is that there are a lot of magic constants. I'd appreciate if they could be converted into macros for easy readability. > > Signed-off-by:

<    1   2   3   4   5   6   7   8   9   >