Re: [PATCH v2 6/7] pstore: Add support to store timestamp counter in ftrace records

On Thu, Nov 10, 2016 at 4:21 PM, Joel Fernandes wrote: > On Thu, Nov 10, 2016 at 4:15 PM, Kees Cook wrote: >> On Thu, Oct 20, 2016 at 12:34 AM, Joel Fernandes wrote: >>> In preparation for merging the per CPU buffers into one buffer

Re: [PATCH v2 6/7] pstore: Add support to store timestamp counter in ftrace records

On Thu, Nov 10, 2016 at 4:21 PM, Joel Fernandes wrote: > On Thu, Nov 10, 2016 at 4:15 PM, Kees Cook wrote: >> On Thu, Oct 20, 2016 at 12:34 AM, Joel Fernandes wrote: >>> In preparation for merging the per CPU buffers into one buffer when we >>> retrieve >>> the pstore ftrace data, we store the

Re: [PATCH v2 5/7] ramoops: Split ftrace buffer space into per-CPU zones

On Thu, Nov 10, 2016 at 4:16 PM, Joel Fernandes wrote: > On Thu, Nov 10, 2016 at 4:13 PM, Kees Cook wrote: >> On Thu, Oct 20, 2016 at 12:34 AM, Joel Fernandes wrote: >>> If FTRACE_PER_CPU flag is passed to ramoops pdata, split the

Re: [PATCH v2 5/7] ramoops: Split ftrace buffer space into per-CPU zones

On Thu, Nov 10, 2016 at 4:16 PM, Joel Fernandes wrote: > On Thu, Nov 10, 2016 at 4:13 PM, Kees Cook wrote: >> On Thu, Oct 20, 2016 at 12:34 AM, Joel Fernandes wrote: >>> If FTRACE_PER_CPU flag is passed to ramoops pdata, split the space into >>> multiple zones depending on the number of CPUs.

Re: [PATCH v2 2/7] pstore: locking: dont lock unless caller asks to

On Thu, Nov 10, 2016 at 4:10 PM, Kees Cook wrote: > On Thu, Oct 20, 2016 at 12:34 AM, Joel Fernandes wrote: >> In preparation of not locking at all for certain buffers depending on if >> there's contention, make locking optional depending if caller

Re: [PATCH v2 2/7] pstore: locking: dont lock unless caller asks to

On Thu, Nov 10, 2016 at 4:10 PM, Kees Cook wrote: > On Thu, Oct 20, 2016 at 12:34 AM, Joel Fernandes wrote: >> In preparation of not locking at all for certain buffers depending on if >> there's contention, make locking optional depending if caller requested it. >> >> Signed-off-by: Joel

Re: [PATCH v2 3/4] printk/btrfs: Handle more message headers

On Fri 2016-11-11 12:41:34, Steven Rostedt wrote: > On Wed, 9 Nov 2016 13:41:30 +0100 > Petr Mladek wrote: > > > The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for > > printing continuation lines") allows to define more message headers > > for a single

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

On Fri, Nov 11, 2016 at 03:53:53PM +, Gabriele Paoloni wrote: > Hi Liviu Hi Gabriele, > > > -Original Message- > > From: liviu.du...@arm.com [mailto:liviu.du...@arm.com] > > Sent: 11 November 2016 14:46 > > To: Gabriele Paoloni > > Cc: Arnd Bergmann;

Re: [PATCH v2 3/4] printk/btrfs: Handle more message headers

On Fri 2016-11-11 12:41:34, Steven Rostedt wrote: > On Wed, 9 Nov 2016 13:41:30 +0100 > Petr Mladek wrote: > > > The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for > > printing continuation lines") allows to define more message headers > > for a single message. The motivation

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

On Fri, Nov 11, 2016 at 03:53:53PM +, Gabriele Paoloni wrote: > Hi Liviu Hi Gabriele, > > > -Original Message- > > From: liviu.du...@arm.com [mailto:liviu.du...@arm.com] > > Sent: 11 November 2016 14:46 > > To: Gabriele Paoloni > > Cc: Arnd Bergmann;

Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

On 10/27/2016 10:26 AM, Eric Dumazet wrote: > On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote: >> We recently encountered a bug where a few customers using ibmveth on the >> same LPAR hit an issue where a TCP session hung when large receive was >> enabled. Closer analysis revealed that the

Re: [PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

On 10/27/2016 10:26 AM, Eric Dumazet wrote: > On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote: >> We recently encountered a bug where a few customers using ibmveth on the >> same LPAR hit an issue where a TCP session hung when large receive was >> enabled. Closer analysis revealed that the

Re: [PATCH v2 2/4] printk/kdb: Handle more message headers

On Fri 2016-11-11 12:35:13, Steven Rostedt wrote: > On Wed, 9 Nov 2016 13:41:29 +0100 > Petr Mladek wrote: > > > diff --git a/include/linux/printk.h b/include/linux/printk.h > > index eac1af8502bb..a0859e169bc3 100644 > > --- a/include/linux/printk.h > > +++

Re: [PATCH v2 2/4] printk/kdb: Handle more message headers

On Fri 2016-11-11 12:35:13, Steven Rostedt wrote: > On Wed, 9 Nov 2016 13:41:29 +0100 > Petr Mladek wrote: > > > diff --git a/include/linux/printk.h b/include/linux/printk.h > > index eac1af8502bb..a0859e169bc3 100644 > > --- a/include/linux/printk.h > > +++ b/include/linux/printk.h > > @@

[PATCH v2 3/4] sparc64: Send break twice from console to return to boot prom

Now we can also jump to boot prom from sunhv console by sending break twice on console for both running and panicked kernel cases. Signed-off-by: Vijay Kumar --- drivers/tty/serial/sunhv.c |6 +- kernel/panic.c |3 ++- 2 files changed, 7

[PATCH v2 3/4] sparc64: Send break twice from console to return to boot prom

Now we can also jump to boot prom from sunhv console by sending break twice on console for both running and panicked kernel cases. Signed-off-by: Vijay Kumar --- drivers/tty/serial/sunhv.c |6 +- kernel/panic.c |3 ++- 2 files changed, 7 insertions(+), 2 deletions(-)

[PATCH v2 1/4] sparc64: Set cpu state to offline when stopped

CPU needs to be marked offline before stopping it. When not marked offline, the xcall receives HV_EWOULDBLOCK and so assumes that not all CPUs received the message, and retries. After 1 retries, it finally fails with fatal mondo timeout. Signed-off-by: Vijay Kumar

[PATCH v2 0/4] sparc64: Jump to boot prom from console on panic

Currently Stop-A (L1A) does not make the kernel switch to OBP on panic. This patchset addresses this issue. Also, now we can cause a jump to OBP by sending 'break' twice from sunhv console. On bare metal, one can send a break by typing Esc + 'B' + Sysrq (or whatever). On LDOM, press Ctrl + ] in

[PATCH v2 1/4] sparc64: Set cpu state to offline when stopped

CPU needs to be marked offline before stopping it. When not marked offline, the xcall receives HV_EWOULDBLOCK and so assumes that not all CPUs received the message, and retries. After 1 retries, it finally fails with fatal mondo timeout. Signed-off-by: Vijay Kumar ---

[PATCH v2 0/4] sparc64: Jump to boot prom from console on panic

Currently Stop-A (L1A) does not make the kernel switch to OBP on panic. This patchset addresses this issue. Also, now we can cause a jump to OBP by sending 'break' twice from sunhv console. On bare metal, one can send a break by typing Esc + 'B' + Sysrq (or whatever). On LDOM, press Ctrl + ] in

[PATCH v2 4/4] Documentation/sparc: Steps for sending break on sunhv console

Documented the steps for sending break on sunhv console. Signed-off-by: Vijay Kumar --- Documentation/sparc/console.txt |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/Documentation/sparc/console.txt b/Documentation/sparc/console.txt

[PATCH v2 4/4] Documentation/sparc: Steps for sending break on sunhv console

Documented the steps for sending break on sunhv console. Signed-off-by: Vijay Kumar --- Documentation/sparc/console.txt |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/Documentation/sparc/console.txt b/Documentation/sparc/console.txt new file mode 100644 index

[PATCH v2 2/4] sparc64: Migrate hvcons irq to panicked cpu

On panic, all other CPUs are stopped except the one which had hit panic. To keep console alive, we need to migrate hvcons irq to panicked CPU. Signed-off-by: Vijay Kumar --- arch/sparc/include/asm/setup.h |1 + arch/sparc/kernel/smp_64.c |6 +-

[PATCH v2 2/4] sparc64: Migrate hvcons irq to panicked cpu

On panic, all other CPUs are stopped except the one which had hit panic. To keep console alive, we need to migrate hvcons irq to panicked CPU. Signed-off-by: Vijay Kumar --- arch/sparc/include/asm/setup.h |1 + arch/sparc/kernel/smp_64.c |6 +- drivers/tty/serial/sunhv.c |

Re: [PATCH v2 1/4] printk/NMI: Handle continuous lines and missing newline

On Fri 2016-11-11 12:28:51, Steven Rostedt wrote: > On Wed, 9 Nov 2016 13:41:28 +0100 > Petr Mladek wrote: > > > > /* > > @@ -135,8 +170,8 @@ static void __printk_nmi_flush(struct irq_work *work) > > __RAW_SPIN_LOCK_INITIALIZER(read_lock); > > struct

Re: [PATCH v2 1/4] printk/NMI: Handle continuous lines and missing newline

On Fri 2016-11-11 12:28:51, Steven Rostedt wrote: > On Wed, 9 Nov 2016 13:41:28 +0100 > Petr Mladek wrote: > > > > /* > > @@ -135,8 +170,8 @@ static void __printk_nmi_flush(struct irq_work *work) > > __RAW_SPIN_LOCK_INITIALIZER(read_lock); > > struct nmi_seq_buf *s =

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

On 11/10/2016 08:08 PM, Ricardo Neri wrote: > Thanks for the suggestions. Perhaps I can include these metrics in my > V2. On th other hand, Dave Hansen gave a good argument on potential > conflicts when, of instance running on an AMD CPU. UMIP is enabled by > setting a bit in CR4. If that bit is

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

On 11/10/2016 08:08 PM, Ricardo Neri wrote: > Thanks for the suggestions. Perhaps I can include these metrics in my > V2. On th other hand, Dave Hansen gave a good argument on potential > conflicts when, of instance running on an AMD CPU. UMIP is enabled by > setting a bit in CR4. If that bit is

Re: [git pull] vfs.git

On Fri, Nov 11, 2016 at 6:25 PM, Linus Torvalds wrote: > On Thu, Nov 10, 2016 at 10:05 PM, Al Viro wrote: >> Christoph's and Jan's aio fixes, fixup for generic_file_splice_read >> (removal of pointless detritus that actually breaks

Re: [git pull] vfs.git

On Fri, Nov 11, 2016 at 6:25 PM, Linus Torvalds wrote: > On Thu, Nov 10, 2016 at 10:05 PM, Al Viro wrote: >> Christoph's and Jan's aio fixes, fixup for generic_file_splice_read >> (removal of pointless detritus that actually breaks it when used for gfs2 >> ->splice_read()) and fixup for

[RESEND PATCH] fs: jfs: Replace CURRENT_TIME_SEC by current_time()

jfs uses nanosecond granularity for filesystem timestamps. Only this assignment is not using nanosecond granularity. Use current_time() to get the right granularity. Signed-off-by: Deepa Dinamani Acked-by: Dave Kleikamp Reviewed-by: Arnd

[RESEND PATCH] fs: jfs: Replace CURRENT_TIME_SEC by current_time()

jfs uses nanosecond granularity for filesystem timestamps. Only this assignment is not using nanosecond granularity. Use current_time() to get the right granularity. Signed-off-by: Deepa Dinamani Acked-by: Dave Kleikamp Reviewed-by: Arnd Bergmann --- fs/jfs/ioctl.c | 2 +- 1 file changed, 1

Re: [PATCH v2 4/4] printk/sound: Handle more message headers

On Wed, 9 Nov 2016 13:41:31 +0100 Petr Mladek wrote: > The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for > printing continuation lines") allows to define more message headers > for a single message. The motivation is that continuous lines might > get mixed.

Re: [PATCH v2 4/4] printk/sound: Handle more message headers

On Wed, 9 Nov 2016 13:41:31 +0100 Petr Mladek wrote: > The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for > printing continuation lines") allows to define more message headers > for a single message. The motivation is that continuous lines might > get mixed. Therefore it make

DRBD: ASSERT in drbd_actlog.c:259

Hello, when I execute mkfs.ext4 -J device=UUID=625d871f-c278-4acb-916d-774dc78dbd8a -v -b 4096 -E stride=$((512/4)),stripe_width=$((512/4*3)),lazy_itable_init=0 -O inline_data,mmp -L dyn -m .01 /dev/test/big the command hangs and the kernel (4.4.30) complains: block drbd1: ASSERT(

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

There was a memorable place in the Orangefs code where the original programmer did that (pick something appropriate from errno.h) and put in a comment about how it was a more reasonable return code... When Al Viro saw it, he said it was: ... stupid. Expected error value is not EOPNOTSUPP;

DRBD: ASSERT in drbd_actlog.c:259

Hello, when I execute mkfs.ext4 -J device=UUID=625d871f-c278-4acb-916d-774dc78dbd8a -v -b 4096 -E stride=$((512/4)),stripe_width=$((512/4*3)),lazy_itable_init=0 -O inline_data,mmp -L dyn -m .01 /dev/test/big the command hangs and the kernel (4.4.30) complains: block drbd1: ASSERT(

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

There was a memorable place in the Orangefs code where the original programmer did that (pick something appropriate from errno.h) and put in a comment about how it was a more reasonable return code... When Al Viro saw it, he said it was: ... stupid. Expected error value is not EOPNOTSUPP;

[PATCH] leds: uleds: make max_brightness configurable

This adds support for configuring max_brightness when setting up a userspace LED device. It also requires changing the brightness value returned from a single byte to an integer. Since the uleds driver has not made it into the mainline kernel yet, this is not breaking userspace. Signed-off-by:

Re: [PATCH v2 2/4] printk/kdb: Handle more message headers

On Wed, 9 Nov 2016 13:41:29 +0100 Petr Mladek wrote: > diff --git a/include/linux/printk.h b/include/linux/printk.h > index eac1af8502bb..a0859e169bc3 100644 > --- a/include/linux/printk.h > +++ b/include/linux/printk.h > @@ -31,6 +31,14 @@ static inline const char

Re: [PATCH v2 2/4] printk/kdb: Handle more message headers

On Wed, 9 Nov 2016 13:41:29 +0100 Petr Mladek wrote: > diff --git a/include/linux/printk.h b/include/linux/printk.h > index eac1af8502bb..a0859e169bc3 100644 > --- a/include/linux/printk.h > +++ b/include/linux/printk.h > @@ -31,6 +31,14 @@ static inline const char *printk_skip_level(const char

[PATCH] leds: uleds: make max_brightness configurable

This adds support for configuring max_brightness when setting up a userspace LED device. It also requires changing the brightness value returned from a single byte to an integer. Since the uleds driver has not made it into the mainline kernel yet, this is not breaking userspace. Signed-off-by:

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On 11/11/16 16:27, Joerg Roedel wrote: > On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote: >> In the original of_iommu_configure design, the thought was that an ops >> structure could be IOMMU-instance-specific (hence the later-removed >> "priv" member), so I suppose right now it is

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On 11/11/16 16:27, Joerg Roedel wrote: > On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote: >> In the original of_iommu_configure design, the thought was that an ops >> structure could be IOMMU-instance-specific (hence the later-removed >> "priv" member), so I suppose right now it is

Re: [PATCH v2 3/4] printk/btrfs: Handle more message headers

On Wed, 9 Nov 2016 13:41:30 +0100 Petr Mladek wrote: > The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for > printing continuation lines") allows to define more message headers > for a single message. The motivation is that continuous lines might > get mixed.

Re: [PATCH v2 3/4] printk/btrfs: Handle more message headers

On Wed, 9 Nov 2016 13:41:30 +0100 Petr Mladek wrote: > The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for > printing continuation lines") allows to define more message headers > for a single message. The motivation is that continuous lines might > get mixed. Therefore it make

Re: [PATCH 0/4] sparc64: Jump to boot prom from console on panic

You still have to post the complete series along with this cover letter, rather than just the cover letter by itself. Please don't try to take short-cuts.

Re: [PATCH 0/4] sparc64: Jump to boot prom from console on panic

You still have to post the complete series along with this cover letter, rather than just the cover letter by itself. Please don't try to take short-cuts.

Re: [PATCH 0/2] bnx2: Hard reset bnx2 chip at probe stage

On Fri, Nov 11, 2016 at 6:02 AM, Baoquan He wrote: > On 11/11/16 at 09:46pm, Baoquan He wrote: >> Hi bnx2 experts, >> >> In commit 3e1be7a ("bnx2: Reset device during driver initialization"), >> firmware requesting code was moved from open stage to probe stage. >> The reason is

Re: [PATCH 0/2] bnx2: Hard reset bnx2 chip at probe stage

On Fri, Nov 11, 2016 at 6:02 AM, Baoquan He wrote: > On 11/11/16 at 09:46pm, Baoquan He wrote: >> Hi bnx2 experts, >> >> In commit 3e1be7a ("bnx2: Reset device during driver initialization"), >> firmware requesting code was moved from open stage to probe stage. >> The reason is in kdump kernel

[PATCH] ARM64: dts: bcm2837-rpi-3-b: remove incorrect pwr LED

From: Andrea Merello We are incorrectly defining the pwr LED, attaching it to a gpio line that is wired to the Wi-Fi SDIO module (which fails due to this). The actual power LED is connected to the GPIO expander, which we don't expose currently. Thanks-to: Eric Anholt

[PATCH] ARM64: dts: bcm2837-rpi-3-b: remove incorrect pwr LED

From: Andrea Merello We are incorrectly defining the pwr LED, attaching it to a gpio line that is wired to the Wi-Fi SDIO module (which fails due to this). The actual power LED is connected to the GPIO expander, which we don't expose currently. Thanks-to: Eric Anholt [for clarifying we can't

Re: [PATCH v8 3/3] drm/fence: add out-fences support

Spotted one more thing on a cleanup path... On Fri, Nov 11, 2016 at 11:15:59PM +0900, Gustavo Padovan wrote: From: Gustavo Padovan Support DRM out-fences by creating a sync_file with a fence for each CRTC that sets the OUT_FENCE_PTR property. We use the

Re: [PATCH v8 3/3] drm/fence: add out-fences support

Spotted one more thing on a cleanup path... On Fri, Nov 11, 2016 at 11:15:59PM +0900, Gustavo Padovan wrote: From: Gustavo Padovan Support DRM out-fences by creating a sync_file with a fence for each CRTC that sets the OUT_FENCE_PTR property. We use the out_fence pointer received in the

Re: [PATCH 3/3] thermal/intel_powerclamp: Convert to CPU hotplug state

On Fri 2016-11-11 11:07:13, Petr Mladek wrote: > I am going to do some more tests and will send a fix. It should > be enough to remove the KTW_FREEZABLE flag from the > kthread_create_worker_on_cpu() call. Please, find below an updated patch that fixes the suspend with kidle_inject kthreads

Re: [PATCH 3/3] thermal/intel_powerclamp: Convert to CPU hotplug state

On Fri 2016-11-11 11:07:13, Petr Mladek wrote: > I am going to do some more tests and will send a fix. It should > be enough to remove the KTW_FREEZABLE flag from the > kthread_create_worker_on_cpu() call. Please, find below an updated patch that fixes the suspend with kidle_inject kthreads

Re: [PATCH v2 1/4] printk/NMI: Handle continuous lines and missing newline

On Wed, 9 Nov 2016 13:41:28 +0100 Petr Mladek wrote: > /* > @@ -135,8 +170,8 @@ static void __printk_nmi_flush(struct irq_work *work) > __RAW_SPIN_LOCK_INITIALIZER(read_lock); > struct nmi_seq_buf *s = container_of(work, struct nmi_seq_buf, work); >

Re: [PATCH v2 1/4] printk/NMI: Handle continuous lines and missing newline

On Wed, 9 Nov 2016 13:41:28 +0100 Petr Mladek wrote: > /* > @@ -135,8 +170,8 @@ static void __printk_nmi_flush(struct irq_work *work) > __RAW_SPIN_LOCK_INITIALIZER(read_lock); > struct nmi_seq_buf *s = container_of(work, struct nmi_seq_buf, work); > unsigned long

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Mike Marshall wrote: > On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath wrote: >> On Nov 11 2016, Miklos Szeredi wrote: >>> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath wrote: On Nov 11 2016,

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

On Nov 11 2016, Mike Marshall wrote: > On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath wrote: >> On Nov 11 2016, Miklos Szeredi wrote: >>> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath wrote: On Nov 11 2016, Miklos Szeredi wrote: > On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath

Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

On 11/03/2016 08:28 PM, Bjorn Andersson wrote: On Wed 02 Nov 15:55 PDT 2016, Stephen Boyd wrote: On 11/02, Bjorn Andersson wrote: On Thu 27 Oct 18:54 PDT 2016, Stephen Boyd wrote: On 10/19, Georgi Djakov wrote: Add a driver for the A53 Clock Controller. It is a hardware block that

Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

On 11/03/2016 08:28 PM, Bjorn Andersson wrote: On Wed 02 Nov 15:55 PDT 2016, Stephen Boyd wrote: On 11/02, Bjorn Andersson wrote: On Thu 27 Oct 18:54 PDT 2016, Stephen Boyd wrote: On 10/19, Georgi Djakov wrote: Add a driver for the A53 Clock Controller. It is a hardware block that

Re: [git pull] vfs.git

On Thu, Nov 10, 2016 at 10:05 PM, Al Viro wrote: > Christoph's and Jan's aio fixes, fixup for generic_file_splice_read > (removal of pointless detritus that actually breaks it when used for gfs2 > ->splice_read()) and fixup for generic_file_read_iter() interaction

Re: [git pull] vfs.git

On Thu, Nov 10, 2016 at 10:05 PM, Al Viro wrote: > Christoph's and Jan's aio fixes, fixup for generic_file_splice_read > (removal of pointless detritus that actually breaks it when used for gfs2 > ->splice_read()) and fixup for generic_file_read_iter() interaction with > ITER_PIPE

Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks

On Fri, Nov 11, 2016 at 1:41 AM, Thomas Gleixner wrote: > On Fri, 11 Nov 2016, Peter Zijlstra wrote: >> Well, its very hard to suggest alternatives, because there simply isn't >> anything of content here. This patch just adds locks, and the next few >> patches don't describe

Re: [PATCH v3 05/46] perf/x86/intel/cmt: add per-package locks

On Fri, Nov 11, 2016 at 1:41 AM, Thomas Gleixner wrote: > On Fri, 11 Nov 2016, Peter Zijlstra wrote: >> Well, its very hard to suggest alternatives, because there simply isn't >> anything of content here. This patch just adds locks, and the next few >> patches don't describe much either. >> >>

Re: [PATCH] x86/preempt: do not clear PREEMPT_NEED_RESCHED on preempt count reset

On Mon, Nov 07, 2016 at 02:01:00PM +0100, Martin Schwidefsky wrote: > The per-cpu preempt count of x86 contains two values, the actual preempt > count and the inverted PREEMPT_NEED_RESCHED bit. If a corrupted preempt > count is detected the preempt_count_set function is used to reset the > preempt

Re: [PATCH] x86/preempt: do not clear PREEMPT_NEED_RESCHED on preempt count reset

On Mon, Nov 07, 2016 at 02:01:00PM +0100, Martin Schwidefsky wrote: > The per-cpu preempt count of x86 contains two values, the actual preempt > count and the inverted PREEMPT_NEED_RESCHED bit. If a corrupted preempt > count is detected the preempt_count_set function is used to reset the > preempt

wl1251 & mac address & calibration data

Hi! I will open discussion about mac address and calibration data for wl1251 wireless chip again... Problem: Mac address & calibration data for wl1251 chip on Nokia N900 are stored on second nand partition (mtd1) in special proprietary format which is used only for Nokia N900 (probably on N8x0

Re: [PATCH v8 3/3] drm/fence: add out-fences support

On Fri, Nov 11, 2016 at 12:11 PM, Daniel Vetter wrote: > On Fri, Nov 11, 2016 at 11:48:09AM -0500, Sean Paul wrote: >> On Fri, Nov 11, 2016 at 9:15 AM, Gustavo Padovan wrote: >> > +static void complete_crtc_signaling(struct drm_device *dev, >> > +

Re: Kbuild: CC= handling broken for tools/

On Fri, Nov 11, 2016 at 06:08:24PM +0100, Jiri Slaby wrote: > On 11/11/2016, 04:30 PM, Josh Poimboeuf wrote: > > Does it work if you use KCFLAGS instead of EXTRA_CFLAGS? > > Yes, the kernel builds with the flags now. > > But objtool is unexpectedly still built by a different compiler. > > I

Re: [PATCH v8 3/3] drm/fence: add out-fences support

On Fri, Nov 11, 2016 at 12:11 PM, Daniel Vetter wrote: > On Fri, Nov 11, 2016 at 11:48:09AM -0500, Sean Paul wrote: >> On Fri, Nov 11, 2016 at 9:15 AM, Gustavo Padovan wrote: >> > +static void complete_crtc_signaling(struct drm_device *dev, >> > +struct

Re: Kbuild: CC= handling broken for tools/

On Fri, Nov 11, 2016 at 06:08:24PM +0100, Jiri Slaby wrote: > On 11/11/2016, 04:30 PM, Josh Poimboeuf wrote: > > Does it work if you use KCFLAGS instead of EXTRA_CFLAGS? > > Yes, the kernel builds with the flags now. > > But objtool is unexpectedly still built by a different compiler. > > I

wl1251 & mac address & calibration data

Hi! I will open discussion about mac address and calibration data for wl1251 wireless chip again... Problem: Mac address & calibration data for wl1251 chip on Nokia N900 are stored on second nand partition (mtd1) in special proprietary format which is used only for Nokia N900 (probably on N8x0

Re: [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines

Stephen Warren writes: > On 10/27/2016 10:52 AM, Eric Anholt wrote: >> From: Linus Walleij >> >> The idea is to give useful names to GPIO lines that an implementer >> will be using from userspace, e.g. for maker type projects. These are >>

Re: [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines

Stephen Warren writes: > On 10/27/2016 10:52 AM, Eric Anholt wrote: >> From: Linus Walleij >> >> The idea is to give useful names to GPIO lines that an implementer >> will be using from userspace, e.g. for maker type projects. These are >> user-visible using tools/gpio/lsgpio.c > >>

Re: [PATCH] drm/atomic: fix memory leak when fetching format name

On Friday, 2016-11-11 16:26:22 +, Colin King wrote: > From: Colin Ian King > > drm_get_format_name allocates memory that is not currently free'd > when printing the state. Fix this by kfree'ing the memory after > use. You are correct, but there are more cases of

Re: [PATCH] drm/atomic: fix memory leak when fetching format name

On Friday, 2016-11-11 16:26:22 +, Colin King wrote: > From: Colin Ian King > > drm_get_format_name allocates memory that is not currently free'd > when printing the state. Fix this by kfree'ing the memory after > use. You are correct, but there are more cases of this, and another fix has

Re: Kbuild: CC= handling broken for tools/

On 11/11/2016, 04:30 PM, Josh Poimboeuf wrote: > Does it work if you use KCFLAGS instead of EXTRA_CFLAGS? Yes, the kernel builds with the flags now. But objtool is unexpectedly still built by a different compiler. I would also prefer the flags (like the warning above) to be passed even when

Re: Kbuild: CC= handling broken for tools/

On 11/11/2016, 04:30 PM, Josh Poimboeuf wrote: > Does it work if you use KCFLAGS instead of EXTRA_CFLAGS? Yes, the kernel builds with the flags now. But objtool is unexpectedly still built by a different compiler. I would also prefer the flags (like the warning above) to be passed even when

Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized

On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote: > > Please merge these directly if you are happy with the result. I will take this. I do see two warnings, but they both seem to be valid and recent, though, so I have no issues with the spurious cases. Warning #1:

Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized

On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote: > > Please merge these directly if you are happy with the result. I will take this. I do see two warnings, but they both seem to be valid and recent, though, so I have no issues with the spurious cases. Warning #1:

Re: [PATCH v8 3/3] drm/fence: add out-fences support

On Fri, Nov 11, 2016 at 11:48:09AM -0500, Sean Paul wrote: > On Fri, Nov 11, 2016 at 9:15 AM, Gustavo Padovan wrote: > > +static void complete_crtc_signaling(struct drm_device *dev, > > +struct drm_atomic_state *state, > > +

Re: [PATCH v8 3/3] drm/fence: add out-fences support

On Fri, Nov 11, 2016 at 11:48:09AM -0500, Sean Paul wrote: > On Fri, Nov 11, 2016 at 9:15 AM, Gustavo Padovan wrote: > > +static void complete_crtc_signaling(struct drm_device *dev, > > +struct drm_atomic_state *state, > > +

Re: Formal description of system call interface

On Sun, Nov 6, 2016 at 2:39 PM, Dmitry Vyukov wrote: > Hello, > > This is notes from the discussion we had at Linux Plumbers this week > regarding providing a formal description of system calls (user API). > > The idea come up in the context of syzkaller, syscall fuzzer, which

Re: Formal description of system call interface

On Sun, Nov 6, 2016 at 2:39 PM, Dmitry Vyukov wrote: > Hello, > > This is notes from the discussion we had at Linux Plumbers this week > regarding providing a formal description of system calls (user API). > > The idea come up in the context of syzkaller, syscall fuzzer, which > has descriptions

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

Hi, Liviu, On 11/11/2016 10:45 PM, liviu.du...@arm.com wrote: > On Fri, Nov 11, 2016 at 01:39:35PM +, Gabriele Paoloni wrote: >> Hi Arnd >> >>> -Original Message- >>> From: Arnd Bergmann [mailto:a...@arndb.de] >>> Sent: 10 November 2016 16:07 >>> To: Gabriele Paoloni >>> Cc:

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

Hi, Liviu, On 11/11/2016 10:45 PM, liviu.du...@arm.com wrote: > On Fri, Nov 11, 2016 at 01:39:35PM +, Gabriele Paoloni wrote: >> Hi Arnd >> >>> -Original Message- >>> From: Arnd Bergmann [mailto:a...@arndb.de] >>> Sent: 10 November 2016 16:07 >>> To: Gabriele Paoloni >>> Cc:

Re: PM regression with LED changes in next-20161109

On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: * Pavel Machek [161110 09:29]: Hi! Looks like commit 883d32ce3385 ("leds: core:

Re: PM regression with LED changes in next-20161109

On 11/11/2016 01:01 PM, Pavel Machek wrote: On Thu 2016-11-10 22:34:07, Jacek Anaszewski wrote: Hi, On 11/10/2016 09:29 PM, Pavel Machek wrote: On Thu 2016-11-10 10:55:37, Tony Lindgren wrote: * Pavel Machek [161110 09:29]: Hi! Looks like commit 883d32ce3385 ("leds: core: Add support for

Re: task isolation discussion at Linux Plumbers

On Wed, Nov 9, 2016 at 8:52 PM, Paul E. McKenney wrote: > On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote: >> On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney >> wrote: >> >> Are you planning on changing rcu_nmi_enter()? It

Re: task isolation discussion at Linux Plumbers

On Wed, Nov 9, 2016 at 8:52 PM, Paul E. McKenney wrote: > On Wed, Nov 09, 2016 at 05:44:02PM -0800, Andy Lutomirski wrote: >> On Wed, Nov 9, 2016 at 9:38 AM, Paul E. McKenney >> wrote: >> >> Are you planning on changing rcu_nmi_enter()? It would make it easier >> to figure out how they interact

Re: sched/autogroup: race if !sysctl_sched_autogroup_enabled ?

On 11/10, Oleg Nesterov wrote: > > And the 3rd case which I didn't think about yesterday. And now I really hope > it can explain the vmcore we have. > > If sysctl_sched_autogroup_enabled was enabled and then disabled, it is > possible that the "autogrouped" process runs with ag->kref.refcount ==

Re: sched/autogroup: race if !sysctl_sched_autogroup_enabled ?

On 11/10, Oleg Nesterov wrote: > > And the 3rd case which I didn't think about yesterday. And now I really hope > it can explain the vmcore we have. > > If sysctl_sched_autogroup_enabled was enabled and then disabled, it is > possible that the "autogrouped" process runs with ag->kref.refcount ==

Re: [PATCH] Kernel: Improvement in code readability when memdup_user_nul() fails.

Sachin Shukla writes: > From: "Sachin Shukla" > > There is no need to call kfree() if memdup_user_nul() fails, as no memory > was allocated and the error in the error-valued pointer should be > returned. Nacked-by: "Eric W. Biederman"

Re: [PATCH] Kernel: Improvement in code readability when memdup_user_nul() fails.

Sachin Shukla writes: > From: "Sachin Shukla" > > There is no need to call kfree() if memdup_user_nul() fails, as no memory > was allocated and the error in the error-valued pointer should be > returned. Nacked-by: "Eric W. Biederman" This is stupid, unnecesary gratituous change that makes

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

I try to choose error codes from the appropriate man page when vfs calls into Orangefs with whatever_operations.action... there's probably better ways, like reading the vfs code and seeing what it expects ... -Mike On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath wrote: > On

Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

I try to choose error codes from the appropriate man page when vfs calls into Orangefs with whatever_operations.action... there's probably better ways, like reading the vfs code and seeing what it expects ... -Mike On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath wrote: > On Nov 11 2016, Miklos

Re: [PATCH] PM / wakeirq: report wakeup events in dedicated wake-IRQs

* Brian Norris [161110 13:30]: > On Thu, Nov 10, 2016 at 01:49:11PM -0700, Tony Lindgren wrote: > > * Brian Norris [161110 11:49]: > > > On Thu, Nov 10, 2016 at 10:13:55AM -0800, Dmitry Torokhov wrote: > > > > On Thu, Nov 10, 2016 at 10:07 AM,

Re: [PATCH v8 3/3] drm/fence: add out-fences support

On Fri, Nov 11, 2016 at 9:15 AM, Gustavo Padovan wrote: > From: Gustavo Padovan > > Support DRM out-fences by creating a sync_file with a fence for each CRTC > that sets the OUT_FENCE_PTR property. > > We use the out_fence pointer received in

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