Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

Sergey Senozhatsky wrote: > printk() is expected to work under different conditions and in different > scenarios, including corner cases of OOM when all of the workers are busy > (e.g. allocating memory). Thus by default printk() uses its own dedicated > workqueue with WQ_MEM_RECLAIM bit set. It

Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

Sergey Senozhatsky wrote: > printk() is expected to work under different conditions and in different > scenarios, including corner cases of OOM when all of the workers are busy > (e.g. allocating memory). Thus by default printk() uses its own dedicated > workqueue with WQ_MEM_RECLAIM bit set. It

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

Hi Guenter, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error with binutils 2.24 and earlier

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

Hi Guenter, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error with binutils 2.24 and earlier

arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'

Hi Alex, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation of a VDSO date: 4 months ago config:

arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'

Hi Alex, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation of a VDSO date: 4 months ago config:

Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

On (03/05/16 19:55), Sergey Senozhatsky wrote: [..] > +static int __init init_printk_workqueue(void) > +{ > + if (printk_sync) > + return 0; > + > + printk_wq = alloc_workqueue("printk_wq", WQ_MEM_RECLAIM, 0); > + /* > + * Fallback to one of system-wide workqueues if

Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

On (03/05/16 19:55), Sergey Senozhatsky wrote: [..] > +static int __init init_printk_workqueue(void) > +{ > + if (printk_sync) > + return 0; > + > + printk_wq = alloc_workqueue("printk_wq", WQ_MEM_RECLAIM, 0); > + /* > + * Fallback to one of system-wide workqueues if

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

On Sat, 5 Mar 2016, Nicolas Pitre wrote: > On Sat, 5 Mar 2016, Michal Marek wrote: > > > I reproduced the SIGBUS after a few iterations, and it crashes in > > parse_dep_file(). I'm now testing this > > > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > > index

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

On Sat, 5 Mar 2016, Nicolas Pitre wrote: > On Sat, 5 Mar 2016, Michal Marek wrote: > > > I reproduced the SIGBUS after a few iterations, and it crashes in > > parse_dep_file(). I'm now testing this > > > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > > index

[PATCH v2 01/10] selftests/x86: In syscall_nt, test NT|TF as well

Setting TF prevents fastpath returns in most cases, which causes the test to fail on 32-bit kernels because 32-bit kernels do not, in fact, handle NT correctly on SYSENTER entries. The next patch will fix 32-bit kernels. Signed-off-by: Andy Lutomirski ---

[PATCH v2 04/10] x86/entry/32: Restore FLAGS on SYSEXIT

We weren't restoring FLAGS at all on SYSEXIT. Apparently no one cared. With this patch applied, native kernels should always honor task_pt_regs()->flags, which opens the door for some sys_iopl cleanups. I'll do those as a separate series, though, since getting it right will involve tweaking

[PATCH v2 01/10] selftests/x86: In syscall_nt, test NT|TF as well

Setting TF prevents fastpath returns in most cases, which causes the test to fail on 32-bit kernels because 32-bit kernels do not, in fact, handle NT correctly on SYSENTER entries. The next patch will fix 32-bit kernels. Signed-off-by: Andy Lutomirski ---

[PATCH v2 04/10] x86/entry/32: Restore FLAGS on SYSEXIT

We weren't restoring FLAGS at all on SYSEXIT. Apparently no one cared. With this patch applied, native kernels should always honor task_pt_regs()->flags, which opens the door for some sys_iopl cleanups. I'll do those as a separate series, though, since getting it right will involve tweaking

[PATCH v2 08/10] x86/entry: Only allocate space for SYSENTER_stack if needed

The SYSENTER stack is only used on 32-bit kernels. Remove it in 64-bit kernels. (We may end up using it down the road on 64-bit kernels. If so, we'll re-enable it for CONFIG_IA32_EMULATION.) Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 2 ++ 1 file

[PATCH v2 08/10] x86/entry: Only allocate space for SYSENTER_stack if needed

The SYSENTER stack is only used on 32-bit kernels. Remove it in 64-bit kernels. (We may end up using it down the road on 64-bit kernels. If so, we'll re-enable it for CONFIG_IA32_EMULATION.) Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 2 ++ 1 file changed, 2

[PATCH v2 09/10] x86/entry/32: Simplify and fix up the SYSENTER stack #DB/NMI fixup

Right after SYSENTER, we can get a #DB or NMI. On x86_32, there's no IST, so the exception handler is invoked on the temporary SYSENTER stack. Because the SYSENTER stack is very small, we have a fixup to switch off the stack quickly when this happens. The old fixup had several issues: 1. It

[PATCH v2 10/10] x86/entry/32: Add and check a stack canary for the SYSENTER stack

Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 3 ++- arch/x86/kernel/process.c| 3 +++ arch/x86/kernel/traps.c | 8 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/processor.h

[PATCH v2 09/10] x86/entry/32: Simplify and fix up the SYSENTER stack #DB/NMI fixup

Right after SYSENTER, we can get a #DB or NMI. On x86_32, there's no IST, so the exception handler is invoked on the temporary SYSENTER stack. Because the SYSENTER stack is very small, we have a fixup to switch off the stack quickly when this happens. The old fixup had several issues: 1. It

[PATCH v2 10/10] x86/entry/32: Add and check a stack canary for the SYSENTER stack

Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 3 ++- arch/x86/kernel/process.c| 3 +++ arch/x86/kernel/traps.c | 8 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h

[PATCH v2 05/10] x86/traps: Clear TIF_BLOCKSTEP on all debug exceptions

The SDM says that debug exceptions clear BTF, and we need to keep TIF_BLOCKSTEP in sync with BTF. Clear it unconditionally and improve the comment. I suspect that the fact that kmemcheck could cause TIF_BLOCKSTEP not to be cleared was just an oversight. Signed-off-by: Andy Lutomirski

[PATCH v2 07/10] x86/entry: Vastly simplify SYSENTER TF handling

Due to a blatant design error, SYSENTER doesn't clear TF. As a result, if a user does SYSENTER with TF set, we will single-step through the kernel until something clears TF. There is absolutely nothing we can do to prevent this short of turning off SYSENTER [1]. Simplify the handling

[PATCH v2 06/10] x86/traps: Clear DR6 early in do_debug and improve the comment

Leaving any bits set in DR6 on return from a debug exception is asking for trouble. Prevent it by writing zero right away and clarify the comment. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/traps.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-)

[PATCH v2 03/10] x86/entry/32: Filter NT and speed up AC filtering in SYSENTER

This makes the 32-bit code work just like the 64-bit code. It should speed up syscalls on 32-bit kernels on Skylake by something like 20 cycles (by analogy to the 64-bit compat case). It also cleans up NT just like we do for the 64-bit case. Signed-off-by: Andy Lutomirski ---

[PATCH v2 05/10] x86/traps: Clear TIF_BLOCKSTEP on all debug exceptions

The SDM says that debug exceptions clear BTF, and we need to keep TIF_BLOCKSTEP in sync with BTF. Clear it unconditionally and improve the comment. I suspect that the fact that kmemcheck could cause TIF_BLOCKSTEP not to be cleared was just an oversight. Signed-off-by: Andy Lutomirski ---

[PATCH v2 07/10] x86/entry: Vastly simplify SYSENTER TF handling

Due to a blatant design error, SYSENTER doesn't clear TF. As a result, if a user does SYSENTER with TF set, we will single-step through the kernel until something clears TF. There is absolutely nothing we can do to prevent this short of turning off SYSENTER [1]. Simplify the handling

[PATCH v2 06/10] x86/traps: Clear DR6 early in do_debug and improve the comment

Leaving any bits set in DR6 on return from a debug exception is asking for trouble. Prevent it by writing zero right away and clarify the comment. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/traps.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git

[PATCH v2 03/10] x86/entry/32: Filter NT and speed up AC filtering in SYSENTER

This makes the 32-bit code work just like the 64-bit code. It should speed up syscalls on 32-bit kernels on Skylake by something like 20 cycles (by analogy to the 64-bit compat case). It also cleans up NT just like we do for the 64-bit case. Signed-off-by: Andy Lutomirski ---

[PATCH 00/10] x86: Various SYSENTER/SYSEXIT/#DB fixes and cleanups

hpa asked me to get rid of the ASM_CLAC at the beginning of the SYSENTER path. Little did he know... This series makes the observed behavior of SYSENTER wrt flags the same for all sane flags and kernel bitnesses. That is, SYSENTER preserves flags now unless you do a syscall that explicitly

[PATCH v2 02/10] x86/entry/compat: In SYSENTER, sink AC clearing below the existing FLAGS test

CLAC is slow, and the SYSENTER code already has an unlikely path that runs if unusual flags are set. Drop the CLAC and instead rely on the unlikely path to clear AC. This seems to save ~24 cycles on my Skylake laptop. (Hey, Intel, make this faster please!) Signed-off-by: Andy Lutomirski

[PATCH 00/10] x86: Various SYSENTER/SYSEXIT/#DB fixes and cleanups

hpa asked me to get rid of the ASM_CLAC at the beginning of the SYSENTER path. Little did he know... This series makes the observed behavior of SYSENTER wrt flags the same for all sane flags and kernel bitnesses. That is, SYSENTER preserves flags now unless you do a syscall that explicitly

[PATCH v2 02/10] x86/entry/compat: In SYSENTER, sink AC clearing below the existing FLAGS test

CLAC is slow, and the SYSENTER code already has an unlikely path that runs if unusual flags are set. Drop the CLAC and instead rely on the unlikely path to clear AC. This seems to save ~24 cycles on my Skylake laptop. (Hey, Intel, make this faster please!) Signed-off-by: Andy Lutomirski ---

Re: multipath: I/O hanging forever

On Fri, Mar 04, 2016 at 10:30:44AM -0700, Andrea Righi wrote: > On Sun, Feb 28, 2016 at 08:46:16PM -0700, Andrea Righi wrote: > > On Sun, Feb 28, 2016 at 06:53:33PM -0700, Andrea Righi wrote: > > ... > > > I'm using 4.5.0-rc5+, from Linus' git. I'll try to do a git bisect > > > later, I'm pretty

Re: multipath: I/O hanging forever

On Fri, Mar 04, 2016 at 10:30:44AM -0700, Andrea Righi wrote: > On Sun, Feb 28, 2016 at 08:46:16PM -0700, Andrea Righi wrote: > > On Sun, Feb 28, 2016 at 06:53:33PM -0700, Andrea Righi wrote: > > ... > > > I'm using 4.5.0-rc5+, from Linus' git. I'll try to do a git bisect > > > later, I'm pretty

[PATCH v2] sched/cputime: steal_account_process_tick() should return jiffies

The callers of steal_account_process_tick() expect it to return whether a jiffy should be considered stolen or not. Currently the return value of steal_account_process_tick() is in units of cputime, which vary between either jiffies or nsecs depending on CONFIG_VIRT_CPU_ACCOUNTING_GEN. If

[PATCH v2] sched/cputime: steal_account_process_tick() should return jiffies

The callers of steal_account_process_tick() expect it to return whether a jiffy should be considered stolen or not. Currently the return value of steal_account_process_tick() is in units of cputime, which vary between either jiffies or nsecs depending on CONFIG_VIRT_CPU_ACCOUNTING_GEN. If

[RESEND PATCH v2 1/2] dt/bindings: Add bindings for PIC32 SPI peripheral

Signed-off-by: Purna Chandra Mandal --- Changes in v2: - fix indentation - add space after comma - moved 'cs-gpios' section under 'required' properties. .../bindings/spi/microchip,spi-pic32.txt | 34 ++ 1 file changed, 34

[RESEND PATCH v2 1/2] dt/bindings: Add bindings for PIC32 SPI peripheral

Signed-off-by: Purna Chandra Mandal --- Changes in v2: - fix indentation - add space after comma - moved 'cs-gpios' section under 'required' properties. .../bindings/spi/microchip,spi-pic32.txt | 34 ++ 1 file changed, 34 insertions(+) create mode 100644

[PATCH] target: Drop incorrect ABORT_TASK put for completed commands

From: Nicholas Bellinger This patch fixes a recent ABORT_TASK regression associated with commit febe562c, where a left-over target_put_sess_cmd() would still be called when __target_check_io_state() detected a command has already been completed, and explicit ABORT must be

[PATCH] target: Drop incorrect ABORT_TASK put for completed commands

From: Nicholas Bellinger This patch fixes a recent ABORT_TASK regression associated with commit febe562c, where a left-over target_put_sess_cmd() would still be called when __target_check_io_state() detected a command has already been completed, and explicit ABORT must be avoided. Note commit

Re: [PATCH] steal_account_process_tick() should return jiffies

On 03/05/2016 07:19 AM, Frederic Weisbecker wrote: On Sat, Mar 05, 2016 at 11:27:01AM +0100, Thomas Gleixner wrote: Chris, On Fri, 4 Mar 2016, Chris Friesen wrote: First of all the subject line should contain a subsystem prefix, i.e. "sched/cputime:" The callers of

Re: [PATCH] steal_account_process_tick() should return jiffies

On 03/05/2016 07:19 AM, Frederic Weisbecker wrote: On Sat, Mar 05, 2016 at 11:27:01AM +0100, Thomas Gleixner wrote: Chris, On Fri, 4 Mar 2016, Chris Friesen wrote: First of all the subject line should contain a subsystem prefix, i.e. "sched/cputime:" The callers of

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

From: Khalid Aziz Date: Wed, 2 Mar 2016 13:39:37 -0700 > In this > first implementation I am enabling ADI for hugepages only > since these pages are locked in memory and hence avoid the > issue of saving and restoring tags. This makes the feature

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

From: Khalid Aziz Date: Wed, 2 Mar 2016 13:39:37 -0700 > In this > first implementation I am enabling ADI for hugepages only > since these pages are locked in memory and hence avoid the > issue of saving and restoring tags. This makes the feature almost entire useless.

include/linux/kprobes.h:361:2: error: invalid use of undefined type 'struct kprobe_ctlblk'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: b2c0b2cbb282f0cf42518ffacbe197e6f2884168 nmi: create generic NMI backtrace implementation date: 8 months ago config: mn10300-allmodconfig (attached as

include/linux/kprobes.h:361:2: error: invalid use of undefined type 'struct kprobe_ctlblk'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: b2c0b2cbb282f0cf42518ffacbe197e6f2884168 nmi: create generic NMI backtrace implementation date: 8 months ago config: mn10300-allmodconfig (attached as

drivers/vhost/vhost.c:718:3: error: call to '__compiletime_assert_718' declared with attribute error: BUILD_BUG_ON failed: __alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE

Hi Michael, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: 5d9a07b0de512b77bf28d2401e5fe3351f00a240 vhost: relax used address alignment date: 1 year, 2 months ago

drivers/vhost/vhost.c:718:3: error: call to '__compiletime_assert_718' declared with attribute error: BUILD_BUG_ON failed: __alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE

Hi Michael, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: 5d9a07b0de512b77bf28d2401e5fe3351f00a240 vhost: relax used address alignment date: 1 year, 2 months ago

Re: [PATCH 09/13] efi/arm64: Check for h/w support before booting a >4 KB granule kernel

On 17 February 2016 at 13:36, Matt Fleming wrote: > From: Ard Biesheuvel > > A kernel built with support for a page size that is not supported by the > hardware it runs on cannot boot to a state where it can inform the user > about it. > > If

Re: [PATCH 09/13] efi/arm64: Check for h/w support before booting a >4 KB granule kernel

On 17 February 2016 at 13:36, Matt Fleming wrote: > From: Ard Biesheuvel > > A kernel built with support for a page size that is not supported by the > hardware it runs on cannot boot to a state where it can inform the user > about it. > > If we happen to be booting via UEFI, we can fail

[PATCH v2] serial: mvebu-uart: fix platform_no_drv_owner.cocci warnings

No need to set .owner here. The core will do it. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: Wilson Ding Signed-off-by: Fengguang Wu Signed-off-by: Julia Lawall --- v2: No change to patch, correct

[PATCH v2] serial: mvebu-uart: fix platform_no_drv_owner.cocci warnings

No need to set .owner here. The core will do it. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: Wilson Ding Signed-off-by: Fengguang Wu Signed-off-by: Julia Lawall --- v2: No change to patch, correct misspelled email mvebu-uart.c |1 - 1 file changed, 1

Linux 4.1.19

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm announcing the release of the 4.1.19 kernel. All users of the 4.1 kernel series must upgrade. The updated 4.1.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.1.y and can be

Linux 4.1.19

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm announcing the release of the 4.1.19 kernel. All users of the 4.1 kernel series must upgrade. The updated 4.1.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.1.y and can be

Linux 3.18.28

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm announcing the release of the 3.18.28 kernel. All users of the 3.18 kernel series must upgrade. The updated 3.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y and can be

Linux 3.18.28

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm announcing the release of the 3.18.28 kernel. All users of the 3.18 kernel series must upgrade. The updated 3.18.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y and can be

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

On Sat, Mar 05, 2016 at 11:53:35PM +, Felipe Ferreri Tonello wrote: > Hi Greg, > > On March 5, 2016 7:39:13 PM GMT+00:00, Greg KH wrote: > >On Sat, Mar 05, 2016 at 11:28:45AM -0500, Michal Nazarewicz wrote: > >> >> On Wed, Mar 02 2016, Felipe F. Tonello wrote: > >> >>> @@

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

On Sat, Mar 05, 2016 at 11:53:35PM +, Felipe Ferreri Tonello wrote: > Hi Greg, > > On March 5, 2016 7:39:13 PM GMT+00:00, Greg KH wrote: > >On Sat, Mar 05, 2016 at 11:28:45AM -0500, Michal Nazarewicz wrote: > >> >> On Wed, Mar 02 2016, Felipe F. Tonello wrote: > >> >>> @@ -16,7 +16,7 @@ >

Re: [PATCH] mailbox: sti: fix check of error code returned by devm_ioremap_resource()

On Sun, 06 Mar 2016, Vladimir Zapolskiy wrote: > The change fixes potential oops while accessing iomem on invalid > address, if devm_ioremap_resource() fails due to some reason. > > The devm_ioremap_resource() function returns ERR_PTR() and never > returns NULL, which makes useless a following

Re: [PATCH] serial: 8250_ingenic: Remove global variable

On Sun, Mar 06, 2016 at 12:55:55AM +0100, Paul Cercueil wrote: > Signed-off-by: Paul Cercueil > --- > drivers/tty/serial/8250/8250_ingenic.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) I can't take patches without a changelog entry :(

Re: [PATCH] mailbox: sti: fix check of error code returned by devm_ioremap_resource()

On Sun, 06 Mar 2016, Vladimir Zapolskiy wrote: > The change fixes potential oops while accessing iomem on invalid > address, if devm_ioremap_resource() fails due to some reason. > > The devm_ioremap_resource() function returns ERR_PTR() and never > returns NULL, which makes useless a following

Re: [PATCH] serial: 8250_ingenic: Remove global variable

On Sun, Mar 06, 2016 at 12:55:55AM +0100, Paul Cercueil wrote: > Signed-off-by: Paul Cercueil > --- > drivers/tty/serial/8250/8250_ingenic.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) I can't take patches without a changelog entry :(

Re: soft lockup when passing vvar address to write(2)

On Mar 5, 2016 1:04 AM, "Ingo Molnar" wrote: > > > * Thomas Gleixner wrote: > > > On Fri, 4 Mar 2016, Andy Lutomirski wrote: > > > Thomas, I still think we should consider just deleting the HPET vclock > > > code and accept the syscall overhead on systems

Re: soft lockup when passing vvar address to write(2)

On Mar 5, 2016 1:04 AM, "Ingo Molnar" wrote: > > > * Thomas Gleixner wrote: > > > On Fri, 4 Mar 2016, Andy Lutomirski wrote: > > > Thomas, I still think we should consider just deleting the HPET vclock > > > code and accept the syscall overhead on systems that are stuck using > > > HPET. If

Re: Applied "regulator: max8973: add support for junction thermal warning" to the regulator tree

On Sat, Mar 05, 2016 at 09:25:49PM +0900, Mark Brown wrote: > The patch > >regulator: max8973: add support for junction thermal warning > > has been applied to the regulator tree at > >git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > > All being well this means

Re: Applied "regulator: max8973: add support for junction thermal warning" to the regulator tree

On Sat, Mar 05, 2016 at 09:25:49PM +0900, Mark Brown wrote: > The patch > >regulator: max8973: add support for junction thermal warning > > has been applied to the regulator tree at > >git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > > All being well this means

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

On Sat, 5 Mar 2016, Michal Marek wrote: > On Fri, Mar 04, 2016 at 11:53:53PM +0100, Michal Marek wrote: > > Dne 4.3.2016 v 23:51 Michal Marek napsal(a): > > > Dne 4.3.2016 v 06:40 Nicolas Pitre napsal(a): > > >> +cmd_and_fixdep = > > >>

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

On Sat, 5 Mar 2016, Michal Marek wrote: > On Fri, Mar 04, 2016 at 11:53:53PM +0100, Michal Marek wrote: > > Dne 4.3.2016 v 23:51 Michal Marek napsal(a): > > > Dne 4.3.2016 v 06:40 Nicolas Pitre napsal(a): > > >> +cmd_and_fixdep = > > >>

Re: Kernel docs: muddying the waters a bit

Em Fri, 04 Mar 2016 15:09:09 +0100 Johannes Stezenbach escreveu: > On Fri, Mar 04, 2016 at 09:59:50AM -0300, Mauro Carvalho Chehab wrote: > > > > 3) I tried to use a .. cssclass, as Johannes suggested, but > > I was not able to include the CSS file. I suspect that this is > >

Re: Kernel docs: muddying the waters a bit

Em Fri, 04 Mar 2016 15:09:09 +0100 Johannes Stezenbach escreveu: > On Fri, Mar 04, 2016 at 09:59:50AM -0300, Mauro Carvalho Chehab wrote: > > > > 3) I tried to use a .. cssclass, as Johannes suggested, but > > I was not able to include the CSS file. I suspect that this is > > easy to fix, but I

Re: [PATCH v2 2/2] spi: spi-pic32: Add PIC32 SPI master driver

On Sat, Mar 05, 2016 at 08:45:22PM +0530, Purna Chandra Mandal wrote: > Sorry Mark. > I have missed adding you in CC. Please find it from: > https://lkml.org/lkml/2016/3/4/401 No, I can't review or apply patches from a web link - please resend. signature.asc Description: PGP signature

Re: [PATCH v2 2/2] spi: spi-pic32: Add PIC32 SPI master driver

On Sat, Mar 05, 2016 at 08:45:22PM +0530, Purna Chandra Mandal wrote: > Sorry Mark. > I have missed adding you in CC. Please find it from: > https://lkml.org/lkml/2016/3/4/401 No, I can't review or apply patches from a web link - please resend. signature.asc Description: PGP signature

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Sat, Mar 5, 2016 at 5:49 PM, Peter Zijlstra wrote: > On Sat, Mar 05, 2016 at 12:18:54AM +0100, Rafael J. Wysocki wrote: > >> >>> Even if there are platforms which may change the CPU frequency behind >> >>> cpufreq's back, breaking the transition notifiers, I'm worried

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

On Sat, Mar 5, 2016 at 5:49 PM, Peter Zijlstra wrote: > On Sat, Mar 05, 2016 at 12:18:54AM +0100, Rafael J. Wysocki wrote: > >> >>> Even if there are platforms which may change the CPU frequency behind >> >>> cpufreq's back, breaking the transition notifiers, I'm worried about the >> >>> addition

Re: SCSI sr driver: parallel writes to optical serialized which hurts performance (sr_mutex)

Johan de Jong wrote: > Hi Wakko, > > If I remember correctly I did see you commenting on discussions on > either the Otto Meta patch, or another that proposed to remove the > mutex entirely. I was unaware of any others. I received the last set of patches from Tim more than a year ago. I wasn't

Re: SCSI sr driver: parallel writes to optical serialized which hurts performance (sr_mutex)

Johan de Jong wrote: > Hi Wakko, > > If I remember correctly I did see you commenting on discussions on > either the Otto Meta patch, or another that proposed to remove the > mutex entirely. I was unaware of any others. I received the last set of patches from Tim more than a year ago. I wasn't

[GIT PULL] Ceph fixes for -rc7

Hi Linus, Please pull the following Ceph patch from git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus This is a final commit we missed to align the protocol compatibility with the feature bits. It decodes a few extra fields in two different messages and reports

[GIT PULL] Ceph fixes for -rc7

Hi Linus, Please pull the following Ceph patch from git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus This is a final commit we missed to align the protocol compatibility with the feature bits. It decodes a few extra fields in two different messages and reports

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hi, On Sat, Mar 5, 2016 at 12:41 PM, Michael Niewoehner wrote: > Hi Douglas, > Hi John, > > Am 05.03.2016 um 01:33 schrieb Doug Anderson : > >> Michael, >> >> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner >> wrote: >

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

Hi, On Sat, Mar 5, 2016 at 12:41 PM, Michael Niewoehner wrote: > Hi Douglas, > Hi John, > > Am 05.03.2016 um 01:33 schrieb Doug Anderson : > >> Michael, >> >> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner >> wrote: > From testing and trying to make sense of the documentation, it

[PATCH 2/3] crypto: af_alg - add AEAD operation type

We need to allow the user to set the authentication type. This adds a new operation that sets IPSec or TLS authentication mode. Signed-off-by: Tadeusz Struk --- crypto/af_alg.c |6 ++ include/crypto/if_alg.h |1 + include/uapi/linux/if_alg.h

[PATCH 3/3] crypto: algif_aead - modify algif aead interface to work with encauth

Updates to algif_aead to allow it to work with the new TLS authentication mode. This patch is generated on top of the algif_aead async patch: https://patchwork.kernel.org/patch/8182971/ Signed-off-by: Tadeusz Struk --- crypto/algif_aead.c | 93

[PATCH 1/3] crypto: authenc - add TLS type encryption

This patch adds a new authentication mode for TLS type encryption. During encrypt it generates auth data + padding and then the plaintext || authdata || padding is encrypted. This requires the user to provide extra space for the cipher text. The required space can be calculated as outlen = assoc

[PATCH 2/3] crypto: af_alg - add AEAD operation type

We need to allow the user to set the authentication type. This adds a new operation that sets IPSec or TLS authentication mode. Signed-off-by: Tadeusz Struk --- crypto/af_alg.c |6 ++ include/crypto/if_alg.h |1 + include/uapi/linux/if_alg.h |4 3 files

[PATCH 3/3] crypto: algif_aead - modify algif aead interface to work with encauth

Updates to algif_aead to allow it to work with the new TLS authentication mode. This patch is generated on top of the algif_aead async patch: https://patchwork.kernel.org/patch/8182971/ Signed-off-by: Tadeusz Struk --- crypto/algif_aead.c | 93

[PATCH 1/3] crypto: authenc - add TLS type encryption

This patch adds a new authentication mode for TLS type encryption. During encrypt it generates auth data + padding and then the plaintext || authdata || padding is encrypted. This requires the user to provide extra space for the cipher text. The required space can be calculated as outlen = assoc

[PATCH 0/3] crypto: af_alg - add TLS type encryption

Hi, The following series adds TLS type authentication. To do this a new template, encauth, is introduced. It is derived from the existing authenc template and modified to work in "first auth then encrypt" mode. The algif interface is also changed to work with the new authentication type. ---

[PATCH 0/3] crypto: af_alg - add TLS type encryption

Hi, The following series adds TLS type authentication. To do this a new template, encauth, is introduced. It is derived from the existing authenc template and modified to work in "first auth then encrypt" mode. The algif interface is also changed to work with the new authentication type. ---

[PATCH] mailbox: sti: fix check of error code returned by devm_ioremap_resource()

The change fixes potential oops while accessing iomem on invalid address, if devm_ioremap_resource() fails due to some reason. The devm_ioremap_resource() function returns ERR_PTR() and never returns NULL, which makes useless a following check for NULL. Signed-off-by: Vladimir Zapolskiy

[PATCH] mailbox: sti: fix check of error code returned by devm_ioremap_resource()

The change fixes potential oops while accessing iomem on invalid address, if devm_ioremap_resource() fails due to some reason. The devm_ioremap_resource() function returns ERR_PTR() and never returns NULL, which makes useless a following check for NULL. Signed-off-by: Vladimir Zapolskiy Fixes:

vgacon.c:undefined reference to `screen_info'

Hi Chen, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: f69405ce6c0fc9f4a039011007371b31f80b470d openrisc: include: asm: Kbuild: add default "vga.h"

vgacon.c:undefined reference to `screen_info'

Hi Chen, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: f69405ce6c0fc9f4a039011007371b31f80b470d openrisc: include: asm: Kbuild: add default "vga.h"

drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap'

Hi Rob, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: 0166dc11be911213e0b1b764488c671be4c48cf3 of: make CONFIG_OF user selectable date: 9 months ago config:

drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap'

Hi Rob, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 67944024c1cdd897e49a09b0d6af3ea38d1388ca commit: 0166dc11be911213e0b1b764488c671be4c48cf3 of: make CONFIG_OF user selectable date: 9 months ago config:

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Sun, Mar 06, 2016 at 09:38:11AM +1100, Dave Chinner wrote: > On Sat, Mar 05, 2016 at 02:24:12AM +0300, Kirill A. Shutemov wrote: > > On Sat, Mar 05, 2016 at 10:05:48AM +1100, Dave Chinner wrote: > > > On Fri, Mar 04, 2016 at 11:38:47AM -0800, Hugh Dickins wrote: > > > > On Fri, 4 Mar 2016, Dave

Re: THP-enabled filesystem vs. FALLOC_FL_PUNCH_HOLE

On Sun, Mar 06, 2016 at 09:38:11AM +1100, Dave Chinner wrote: > On Sat, Mar 05, 2016 at 02:24:12AM +0300, Kirill A. Shutemov wrote: > > On Sat, Mar 05, 2016 at 10:05:48AM +1100, Dave Chinner wrote: > > > On Fri, Mar 04, 2016 at 11:38:47AM -0800, Hugh Dickins wrote: > > > > On Fri, 4 Mar 2016, Dave

/bin/bash: line 0: [: -ge: unary operator expected

Hi Huacai, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: a7c9b603cf2371edacb054abc35597e810c1e5fd commit: 5188129b8c9f58ba089bfd3809a163a8c087c797 MIPS: Loongson-3: Improve -march option and move it to Platform

/bin/bash: line 0: [: -ge: unary operator expected

Hi Huacai, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: a7c9b603cf2371edacb054abc35597e810c1e5fd commit: 5188129b8c9f58ba089bfd3809a163a8c087c797 MIPS: Loongson-3: Improve -march option and move it to Platform

RE: [PATCH RESEND] net:fec:Fix error checking in the function fec_enet_init

From: Nicholas Krause Sent: Saturday, March 05, 2016 4:00 AM > To: da...@davemloft.net > Cc: b38...@freescale.com; and...@lunn.ch; fabio.este...@freescale.com; > l.st...@pengutronix.de; rmk+ker...@arm.linux.org.uk; trem...@gmail.com; > johan...@sipsolutions.net;

RE: [PATCH RESEND] net:fec:Fix error checking in the function fec_enet_init

From: Nicholas Krause Sent: Saturday, March 05, 2016 4:00 AM > To: da...@davemloft.net > Cc: b38...@freescale.com; and...@lunn.ch; fabio.este...@freescale.com; > l.st...@pengutronix.de; rmk+ker...@arm.linux.org.uk; trem...@gmail.com; > johan...@sipsolutions.net; u.kleine-koe...@pengutronix.de; >

  1   2   3   4   5   >