Re: [PATCH] char: tmp: fix potential null pointer dereference

Hi Jarkko, Please, see my comments below Quoting Jarkko Sakkinen : On Tue, May 30, 2017 at 04:51:23PM -0500, Gustavo A. R. Silva wrote: NULL check at line 147: if (chip) {, implies chip might be NULL. Function dev_get_drvdata() dereference pointer chip. Move pointer priv assignment inside

[PATCH 2/2] Support perf script -F brstackoff,dso

The idea here is to make AutoFDO easier in cloud environment with ASLR. It's easiest to show how this is useful by example. I built a small test akin to "while(1) { do_nothing(); }" where the do_nothing function is loaded from a dso. I sampled the execution with perf record -b. Using the

Re: [PATCH v2 2/2] tcp: md5: extend the tcp_md5sig struct to specify a key address prefix

On Sat, Jun 10, 2017 at 06:58:11PM -0400, David Miller wrote: > From: Ivan Delalande > Date: Fri, 9 Jun 2017 19:14:49 -0700 > > > Add a flag field and address prefix length at the end of the tcp_md5sig > > structure so users can configure an address prefix length along with a

Re: [PATCH v2 2/2] tcp: md5: extend the tcp_md5sig struct to specify a key address prefix

On Sat, Jun 10, 2017 at 06:58:11PM -0400, David Miller wrote: > From: Ivan Delalande > Date: Fri, 9 Jun 2017 19:14:49 -0700 > > > Add a flag field and address prefix length at the end of the tcp_md5sig > > structure so users can configure an address prefix length along with a > > key. Make sure

Re: [PATCH v2] arm: eBPF JIT compiler

From: Alexander Alemayhu Date: Tue, 13 Jun 2017 00:45:45 +0200 > On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote: >> >> Nope. It looks like a latest addition to testing. Can you please tell >> me how to test with it? >> > cd tools/testing/selftests/bpf/ >

Re: [PATCH v2] arm: eBPF JIT compiler

From: Alexander Alemayhu Date: Tue, 13 Jun 2017 00:45:45 +0200 > On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote: >> >> Nope. It looks like a latest addition to testing. Can you please tell >> me how to test with it? >> > cd tools/testing/selftests/bpf/ > make > sudo ./test_progs

Re: [PATCH v2] arm: eBPF JIT compiler

On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote: > > Nope. It looks like a latest addition to testing. Can you please tell > me how to test with it? > cd tools/testing/selftests/bpf/ make sudo ./test_progs -- Mit freundlichen Grüßen Alexander Alemayhu

Re: [PATCH v2] arm: eBPF JIT compiler

On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote: > > Nope. It looks like a latest addition to testing. Can you please tell > me how to test with it? > cd tools/testing/selftests/bpf/ make sudo ./test_progs -- Mit freundlichen Grüßen Alexander Alemayhu

[tip:irq/urgent] genirq: Release resources in __setup_irq() error path

Commit-ID: fa07ab72cbb0d843429e61bf179308aed6cbe0dd Gitweb: http://git.kernel.org/tip/fa07ab72cbb0d843429e61bf179308aed6cbe0dd Author: Heiner Kallweit AuthorDate: Sun, 11 Jun 2017 00:38:36 +0200 Committer: Thomas Gleixner CommitDate: Tue, 13

[tip:irq/urgent] genirq: Release resources in __setup_irq() error path

Commit-ID: fa07ab72cbb0d843429e61bf179308aed6cbe0dd Gitweb: http://git.kernel.org/tip/fa07ab72cbb0d843429e61bf179308aed6cbe0dd Author: Heiner Kallweit AuthorDate: Sun, 11 Jun 2017 00:38:36 +0200 Committer: Thomas Gleixner CommitDate: Tue, 13 Jun 2017 00:40:39 +0200 genirq: Release

Re: [PATCH v9 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

On Wed, 7 Jun 2017, Anju T Sudhakar wrote: > On Tuesday 06 June 2017 03:39 PM, Thomas Gleixner wrote: > > On Mon, 5 Jun 2017, Anju T Sudhakar wrote: > > > +static void cleanup_all_core_imc_memory(struct imc_pmu *pmu_ptr) > > > +{ > > > + struct imc_mem_info *ptr = pmu_ptr->mem_info; > > > + > > >

Re: [PATCH v9 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

On Wed, 7 Jun 2017, Anju T Sudhakar wrote: > On Tuesday 06 June 2017 03:39 PM, Thomas Gleixner wrote: > > On Mon, 5 Jun 2017, Anju T Sudhakar wrote: > > > +static void cleanup_all_core_imc_memory(struct imc_pmu *pmu_ptr) > > > +{ > > > + struct imc_mem_info *ptr = pmu_ptr->mem_info; > > > + > > >

Re: [PATCH 3/4] mfd: tps65217: remove duplicated interrupt resources.

On 06/12/2017 04:24 PM, Enric Balletbo i Serra wrote: > I don't think it makes sense to have the interrupt resources for charger > and power button in two different places, the driver and the DT binding. > That's confusing so remove the ones from the mfd driver in favour of > having the

Re: [PATCH 3/4] mfd: tps65217: remove duplicated interrupt resources.

On 06/12/2017 04:24 PM, Enric Balletbo i Serra wrote: > I don't think it makes sense to have the interrupt resources for charger > and power button in two different places, the driver and the DT binding. > That's confusing so remove the ones from the mfd driver in favour of > having the

Re: [4.4.70 REGRESSION] Nouveau hangs up at boot

On 06/10/2017 06:25 AM, Takashi Iwai wrote: > Hi, > > we've received a bug report about 4.4.70 kernel showing the hang up at > boot. And, this turned out to be a regression in nouveau driver: > https://bugzilla.suse.com/show_bug.cgi?id=1043467 > > I provided a test kernel reverting the last

Re: [4.4.70 REGRESSION] Nouveau hangs up at boot

On 06/10/2017 06:25 AM, Takashi Iwai wrote: > Hi, > > we've received a bug report about 4.4.70 kernel showing the hang up at > boot. And, this turned out to be a regression in nouveau driver: > https://bugzilla.suse.com/show_bug.cgi?id=1043467 > > I provided a test kernel reverting the last

[PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

Sysfs "badblocks" information may be updated during run-time that: - MCE, SCI, and sysfs "scrub" may add new bad blocks - Writes and ioctl() may clear bad blocks Add support to send sysfs notifications to sysfs "badblocks" file under region and pmem directories when their badblocks information

[PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

Sysfs "badblocks" information may be updated during run-time that: - MCE, SCI, and sysfs "scrub" may add new bad blocks - Writes and ioctl() may clear bad blocks Add support to send sysfs notifications to sysfs "badblocks" file under region and pmem directories when their badblocks information

Re: [PATCH v3] mmc: dw_mmc-k3: add sd support for hi3660

Hi, On 06/12/2017 11:27 PM, Jaehoon Chung wrote: > Hi Li, > > On 2017년 06월 12일 16:46, liwei wrote: >> Add sd card support for hi3660 soc >> >> Major changes in v3: >> - solve review comments from Heiner Kallweit. >>*use the GENMASK and FIELD_PREP macros replace the bit shift operation. >>

Re: [PATCH v3] mmc: dw_mmc-k3: add sd support for hi3660

Hi, On 06/12/2017 11:27 PM, Jaehoon Chung wrote: > Hi Li, > > On 2017년 06월 12일 16:46, liwei wrote: >> Add sd card support for hi3660 soc >> >> Major changes in v3: >> - solve review comments from Heiner Kallweit. >>*use the GENMASK and FIELD_PREP macros replace the bit shift operation. >>

Re: nfc: nci: fix potential NULL pointer dereference

On Mon, Jun 12, 2017 at 05:02:23PM -0500, Gustavo A. R. Silva wrote: > NULL check at line 76: if (conn_info) {, implies that pointer conn_info > might be NULL, but this pointer is being previously dereferenced, > which might cause a NULL pointer dereference. > > Add NULL check before

Re: nfc: nci: fix potential NULL pointer dereference

On Mon, Jun 12, 2017 at 05:02:23PM -0500, Gustavo A. R. Silva wrote: > NULL check at line 76: if (conn_info) {, implies that pointer conn_info > might be NULL, but this pointer is being previously dereferenced, > which might cause a NULL pointer dereference. > > Add NULL check before

Re: [RFC PATCH 1/7 v1]powerpc: Free up four PTE bits to accommodate memory keys

On Mon, Jun 12, 2017 at 12:27:44PM +0530, Aneesh Kumar K.V wrote: > Ram Pai writes: > > > Rearrange PTE bits to free up bits 3, 4, 5 and 6 for > > memory keys. Bit 3, 4, 5, 6 and 57 shall be used for memory > > keys. > > > > The patch does the following change to

Re: [RFC PATCH 1/7 v1]powerpc: Free up four PTE bits to accommodate memory keys

On Mon, Jun 12, 2017 at 12:27:44PM +0530, Aneesh Kumar K.V wrote: > Ram Pai writes: > > > Rearrange PTE bits to free up bits 3, 4, 5 and 6 for > > memory keys. Bit 3, 4, 5, 6 and 57 shall be used for memory > > keys. > > > > The patch does the following change to the 64K PTE format >

Re: [PATCH v2 5/8] PM / sleep: Print timing information if debug is enabled

On Mon, 2017-06-12 at 22:51 +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Avoid printing the device suspend/resume timing information if > CONFIG_PM_DEBUG is not set to reduce the log noise level. > > Signed-off-by: Rafael J. Wysocki

Re: [PATCH v2 5/8] PM / sleep: Print timing information if debug is enabled

On Mon, 2017-06-12 at 22:51 +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Avoid printing the device suspend/resume timing information if > CONFIG_PM_DEBUG is not set to reduce the log noise level. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/base/power/main.c |4

Re: WMI and Kernel:User interface

On Monday 12 June 2017 19:02:49 Darren Hart wrote: > On Sat, Jun 10, 2017 at 12:36:40PM +0200, Pali Rohár wrote: > > On Saturday 10 June 2017 02:46:41 Darren Hart wrote: > > > On Fri, Jun 09, 2017 at 08:41:51AM +0200, Greg Kroah-Hartman > > > wrote: > > > > On Sat, Jun 03, 2017 at 12:50:58PM

Re: [PATCH] audit: style fix

On Sun, Jun 11, 2017 at 10:33 PM, Derek Robson wrote: > Fixed checkpatch.pl warnings of "function definition argument FOO > should also have an identifier name" > > Signed-off-by: Derek Robson > --- > kernel/audit.h | 28 ++-- > 1

Re: WMI and Kernel:User interface

On Monday 12 June 2017 19:02:49 Darren Hart wrote: > On Sat, Jun 10, 2017 at 12:36:40PM +0200, Pali Rohár wrote: > > On Saturday 10 June 2017 02:46:41 Darren Hart wrote: > > > On Fri, Jun 09, 2017 at 08:41:51AM +0200, Greg Kroah-Hartman > > > wrote: > > > > On Sat, Jun 03, 2017 at 12:50:58PM

Re: [PATCH] audit: style fix

On Sun, Jun 11, 2017 at 10:33 PM, Derek Robson wrote: > Fixed checkpatch.pl warnings of "function definition argument FOO > should also have an identifier name" > > Signed-off-by: Derek Robson > --- > kernel/audit.h | 28 ++-- > 1 file changed, 14 insertions(+), 14

Re: [tip:timers/core] posix-timers: Zero out oldval itimerspec

On Tue, Jun 13, 2017 at 12:01:17AM +0200, Thomas Gleixner wrote: > On Mon, 12 Jun 2017, Andrei Vagin wrote: > > > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c > > > index b53a0b5..88517dc 100644 > > > --- a/kernel/time/posix-timers.c > > > +++ b/kernel/time/posix-timers.c >

Re: [tip:timers/core] posix-timers: Zero out oldval itimerspec

On Tue, Jun 13, 2017 at 12:01:17AM +0200, Thomas Gleixner wrote: > On Mon, 12 Jun 2017, Andrei Vagin wrote: > > > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c > > > index b53a0b5..88517dc 100644 > > > --- a/kernel/time/posix-timers.c > > > +++ b/kernel/time/posix-timers.c >

[PATCH v3 1/3] arch: Define CPU_BIG_ENDIAN for all fixed big endian archs

While working on enabling queued rwlock on SPARC, found this following code in include/asm-generic/qrwlock.h which uses CONFIG_CPU_BIG_ENDIAN to clear a byte. static inline u8 *__qrwlock_write_byte(struct qrwlock *lock) { return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN); }

[PATCH v3 1/3] arch: Define CPU_BIG_ENDIAN for all fixed big endian archs

While working on enabling queued rwlock on SPARC, found this following code in include/asm-generic/qrwlock.h which uses CONFIG_CPU_BIG_ENDIAN to clear a byte. static inline u8 *__qrwlock_write_byte(struct qrwlock *lock) { return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN); }

[PATCH v3 0/3] Define CPU_BIG_ENDIAN or warn for inconsistencies

Found this problem while enabling queued rwlock on SPARC. The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the specific byte in qrwlock structure. Without this parameter, we clear the wrong byte. Here is the code in include/asm-generic/qrwlock.h static inline u8 *__qrwlock_write_byte(struct

[PATCH v3 2/3] arch/microblaze: Add choice for endianness and update Makefile

microblaze architectures can be configured for either little or big endian formats. Add a choice option for the user to select the correct endian format(default to big endian). Also update the Makefile so toolchain can compile for the format it is configured for. Signed-off-by: Babu Moger

[PATCH v3 3/3] include: warn for inconsistent endian config definition

We have seen some generic code use config parameter CONFIG_CPU_BIG_ENDIAN to decide the endianness. Here are the few examples. include/asm-generic/qrwlock.h drivers/of/base.c drivers/of/fdt.c drivers/tty/serial/earlycon.c drivers/tty/serial/serial_core.c Display warning if CPU_BIG_ENDIAN is not

[PATCH v3 0/3] Define CPU_BIG_ENDIAN or warn for inconsistencies

Found this problem while enabling queued rwlock on SPARC. The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the specific byte in qrwlock structure. Without this parameter, we clear the wrong byte. Here is the code in include/asm-generic/qrwlock.h static inline u8 *__qrwlock_write_byte(struct

[PATCH v3 2/3] arch/microblaze: Add choice for endianness and update Makefile

microblaze architectures can be configured for either little or big endian formats. Add a choice option for the user to select the correct endian format(default to big endian). Also update the Makefile so toolchain can compile for the format it is configured for. Signed-off-by: Babu Moger

[PATCH v3 3/3] include: warn for inconsistent endian config definition

We have seen some generic code use config parameter CONFIG_CPU_BIG_ENDIAN to decide the endianness. Here are the few examples. include/asm-generic/qrwlock.h drivers/of/base.c drivers/of/fdt.c drivers/tty/serial/earlycon.c drivers/tty/serial/serial_core.c Display warning if CPU_BIG_ENDIAN is not

Re: [RESEND x3][PATCH v4] arm64: dts: hi6220: Add k3-dma and i2s/hdmi audio support

On Mon, Jun 12, 2017 at 01:52:46PM -0700, John Stultz wrote: > + sound { > + compatible = "simple-audio-card"; > + simple-audio-card,name = "hikey-hdmi"; Now the graph card has been merged it's probably a good idea to be using that, it's generally a better idea for

Re: [RESEND x3][PATCH v4] arm64: dts: hi6220: Add k3-dma and i2s/hdmi audio support

On Mon, Jun 12, 2017 at 01:52:46PM -0700, John Stultz wrote: > + sound { > + compatible = "simple-audio-card"; > + simple-audio-card,name = "hikey-hdmi"; Now the graph card has been merged it's probably a good idea to be using that, it's generally a better idea for

[RELEASE] LTTng modules 2.10.0-rc2, 2.9.3, 2.8.6

The LTTng modules provide Linux kernel tracing capability to the LTTng tracer toolset. Those versions are bugfixes in the currently maintained stable branches of lttng-modules. They mainly contain: - Fix for the "PID tracker" feature, which should track pgid, which corresponds to the notion of

[RELEASE] LTTng modules 2.10.0-rc2, 2.9.3, 2.8.6

The LTTng modules provide Linux kernel tracing capability to the LTTng tracer toolset. Those versions are bugfixes in the currently maintained stable branches of lttng-modules. They mainly contain: - Fix for the "PID tracker" feature, which should track pgid, which corresponds to the notion of

Re: [PATCH v3 06/18] xen/pvcalls: handle commands from the frontend

> + > static void pvcalls_back_work(struct work_struct *work) > { > + struct pvcalls_fedata *priv = container_of(work, > + struct pvcalls_fedata, register_work); > + int notify, notify_all = 0, more = 1; > + struct xen_pvcalls_request req; > + struct xenbus_device

Re: [PATCH 4.11 000/150] 4.11.5-stable review

On Mon, Jun 12, 2017 at 05:23:27PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.11.5 release. > There are 150 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH v3 06/18] xen/pvcalls: handle commands from the frontend

> + > static void pvcalls_back_work(struct work_struct *work) > { > + struct pvcalls_fedata *priv = container_of(work, > + struct pvcalls_fedata, register_work); > + int notify, notify_all = 0, more = 1; > + struct xen_pvcalls_request req; > + struct xenbus_device

Re: [PATCH 4.11 000/150] 4.11.5-stable review

On Mon, Jun 12, 2017 at 05:23:27PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.11.5 release. > There are 150 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

[PATCH] nfc: nci: fix potential NULL pointer dereference

NULL check at line 76: if (conn_info) {, implies that pointer conn_info might be NULL, but this pointer is being previously dereferenced, which might cause a NULL pointer dereference. Add NULL check before dereferencing pointer conn_info in order to avoid a potential NULL pointer dereference.

[PATCH] nfc: nci: fix potential NULL pointer dereference

NULL check at line 76: if (conn_info) {, implies that pointer conn_info might be NULL, but this pointer is being previously dereferenced, which might cause a NULL pointer dereference. Add NULL check before dereferencing pointer conn_info in order to avoid a potential NULL pointer dereference.

Re: [tip:timers/core] posix-timers: Zero out oldval itimerspec

On Mon, 12 Jun 2017, Andrei Vagin wrote: > > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c > > index b53a0b5..88517dc 100644 > > --- a/kernel/time/posix-timers.c > > +++ b/kernel/time/posix-timers.c > > @@ -828,6 +828,8 @@ SYSCALL_DEFINE4(timer_settime, timer_t, timer_id,

Re: [tip:timers/core] posix-timers: Zero out oldval itimerspec

On Mon, 12 Jun 2017, Andrei Vagin wrote: > > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c > > index b53a0b5..88517dc 100644 > > --- a/kernel/time/posix-timers.c > > +++ b/kernel/time/posix-timers.c > > @@ -828,6 +828,8 @@ SYSCALL_DEFINE4(timer_settime, timer_t, timer_id,

Re: [PATCH] PCI: Add Intel XXV710 to broken INTx masking quirk

On Wed, Jun 07, 2017 at 01:00:48PM -0600, Alex Williamson wrote: > Just like the other XL710 and X710 variants, the XXV710 device IDs > appear to have the same hardware bug, the status register doesn't > report pending interrupts resulting in "irq xx: nobody cared..." > errors from the spurious

Re: [PATCH] PCI: Add Intel XXV710 to broken INTx masking quirk

On Wed, Jun 07, 2017 at 01:00:48PM -0600, Alex Williamson wrote: > Just like the other XL710 and X710 variants, the XXV710 device IDs > appear to have the same hardware bug, the status register doesn't > report pending interrupts resulting in "irq xx: nobody cared..." > errors from the spurious

Re: [PATCH tip/core/rcu 07/13] rcu: Add smp_mb__after_atomic() to sync_exp_work_done()

On Mon, Jun 12, 2017 at 04:51:43PM +0200, Dmitry Vyukov wrote: > On Sat, Jun 10, 2017 at 12:56 AM, Paul E. McKenney > wrote: > >> > > > +/** > >> > > > + * spin_is_locked - Conditionally interpose after prior critical > >> > > > sections > >> > > > + * @lock: the

Re: [PATCH tip/core/rcu 07/13] rcu: Add smp_mb__after_atomic() to sync_exp_work_done()

On Mon, Jun 12, 2017 at 04:51:43PM +0200, Dmitry Vyukov wrote: > On Sat, Jun 10, 2017 at 12:56 AM, Paul E. McKenney > wrote: > >> > > > +/** > >> > > > + * spin_is_locked - Conditionally interpose after prior critical > >> > > > sections > >> > > > + * @lock: the spinlock whose critical sections

Re: [PATCH 4.9 000/119] 4.9.32-stable review

On Mon, Jun 12, 2017 at 05:24:22PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.32 release. > There are 119 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.9 000/119] 4.9.32-stable review

On Mon, Jun 12, 2017 at 05:24:22PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.32 release. > There are 119 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.4 00/90] 4.4.72-stable review

On Mon, Jun 12, 2017 at 05:25:06PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.72 release. > There are 90 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.4 00/90] 4.4.72-stable review

On Mon, Jun 12, 2017 at 05:25:06PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.72 release. > There are 90 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 3.18 00/45] 3.18.57-stable review

On Mon, Jun 12, 2017 at 05:26:10PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.57 release. > There are 45 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 3.18 00/45] 3.18.57-stable review

On Mon, Jun 12, 2017 at 05:26:10PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.57 release. > There are 45 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [RFC PATCH] fs: ext4: don't trap kswapd and allocating tasks on ext4 inode IO

On Mon, Jun 12, 2017 at 05:19:34PM +0200, Jan Kara wrote: > On Mon 12-06-17 10:37:27, Johannes Weiner wrote: > > However, with or without a reproducer, it seems to make sense to not > > serialize evict() on commits when we don't have to from a correctness > > point of view. Would you be opposed to

Re: [RFC PATCH] fs: ext4: don't trap kswapd and allocating tasks on ext4 inode IO

On Mon, Jun 12, 2017 at 05:19:34PM +0200, Jan Kara wrote: > On Mon 12-06-17 10:37:27, Johannes Weiner wrote: > > However, with or without a reproducer, it seems to make sense to not > > serialize evict() on commits when we don't have to from a correctness > > point of view. Would you be opposed to

Re: [PATCH v3] PCI: Workaround wrong flags completions for IDT switch

On Fri, Jun 09, 2017 at 04:16:17PM -0700, Yinghai Lu wrote: > From: James Puthukattukaran > > The IDT switch incorrectly flags an ACS source violation on a read config > request to an end point device on the completion (IDT 89H32H8G3-YC, > errata #36) even

Re: [PATCH v3] PCI: Workaround wrong flags completions for IDT switch

On Fri, Jun 09, 2017 at 04:16:17PM -0700, Yinghai Lu wrote: > From: James Puthukattukaran > > The IDT switch incorrectly flags an ACS source violation on a read config > request to an end point device on the completion (IDT 89H32H8G3-YC, > errata #36) even though the PCI Express spec states that

[GIT PULL rcu/next] RCU commits for 4.13

Hello, Ingo, This pull request is unusual in being a single linear set of commits, as opposed to my usual topic branches. This is due to the many large-footprint changes, which means that reasonable topic branches result in large numbers of merge conflicts. In addition, some commits depend on

[GIT PULL rcu/next] RCU commits for 4.13

Hello, Ingo, This pull request is unusual in being a single linear set of commits, as opposed to my usual topic branches. This is due to the many large-footprint changes, which means that reasonable topic branches result in large numbers of merge conflicts. In addition, some commits depend on

[PATCH 0/4] Xtensa fixes for v4.12-rc6

-xtensa.git tags/xtensa-20170612 for you to fetch changes up to e5c86679d5e864947a52fb31e45a425dea3e7fa9: xtensa: don't use linux IRQ #0 (2017-06-05 16:53:10 -0700) Xtensa fixes for v4.12-rc6 - don't use linux IRQ #0 in legacy irq domains

[PATCH 0/4] Xtensa fixes for v4.12-rc6

-xtensa.git tags/xtensa-20170612 for you to fetch changes up to e5c86679d5e864947a52fb31e45a425dea3e7fa9: xtensa: don't use linux IRQ #0 (2017-06-05 16:53:10 -0700) Xtensa fixes for v4.12-rc6 - don't use linux IRQ #0 in legacy irq domains

Re: [PATCH v4 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong wrote: > From: Casey Leedom > > cxgb4 Ethernet driver now queries PCIe configuration space to determine > if it can send TLPs to it with the Relaxed Ordering Attribute set. > > Signed-off-by: Casey Leedom

Re: [PATCH v4 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong wrote: > From: Casey Leedom > > cxgb4 Ethernet driver now queries PCIe configuration space to determine > if it can send TLPs to it with the Relaxed Ordering Attribute set. > > Signed-off-by: Casey Leedom > Signed-off-by: Ding Tianhong Casey,

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

On 6/12/2017 3:58 PM, Max Filippov wrote: On Mon, Jun 12, 2017 at 1:51 PM, Arnd Bergmann wrote: That way, we don't have to guess what the toolchain does, but rather tell it to do whatever is configured, like we do for most other architectures. Unfortunately we can't do the

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

On 6/12/2017 3:58 PM, Max Filippov wrote: On Mon, Jun 12, 2017 at 1:51 PM, Arnd Bergmann wrote: That way, we don't have to guess what the toolchain does, but rather tell it to do whatever is configured, like we do for most other architectures. Unfortunately we can't do the same thing on

Re: [PATCH 03/11] Creation of "usb_device_auth" LSM hook

On 6/12/2017 9:56 AM, Salvatore Mesoraca wrote: > Creation of a new LSM hook that can be used to authorize or deauthorize > new USB devices via the usb authorization interface. > The same hook can also prevent the authorization of a USB device via > "/sys/bus/usb/devices/DEVICE/authorized". >

Re: [PATCH 03/11] Creation of "usb_device_auth" LSM hook

On 6/12/2017 9:56 AM, Salvatore Mesoraca wrote: > Creation of a new LSM hook that can be used to authorize or deauthorize > new USB devices via the usb authorization interface. > The same hook can also prevent the authorization of a USB device via > "/sys/bus/usb/devices/DEVICE/authorized". >

Re: [PATCH 05/11] Creation of "check_vmflags" LSM hook

On 6/12/2017 9:56 AM, Salvatore Mesoraca wrote: > Creation of a new LSM hook to check if a given configuration of vmflags, > for a new memory allocation request, should be allowed or not. > It's placed in "do_mmap", "do_brk_flags" and "__install_special_mapping". > > Signed-off-by: Salvatore

Re: [PATCH 05/11] Creation of "check_vmflags" LSM hook

On 6/12/2017 9:56 AM, Salvatore Mesoraca wrote: > Creation of a new LSM hook to check if a given configuration of vmflags, > for a new memory allocation request, should be allowed or not. > It's placed in "do_mmap", "do_brk_flags" and "__install_special_mapping". > > Signed-off-by: Salvatore

Re: [PATCH v3 05/18] xen/pvcalls: connect to a frontend

On 06/02/2017 03:31 PM, Stefano Stabellini wrote: > Introduce a per-frontend data structure named pvcalls_fedata. It > contains pointers to the command ring, its event channel, a list of > active sockets and a tree of passive sockets (passing sockets need to be > looked up from the id on listen,

Re: [PATCH v3 05/18] xen/pvcalls: connect to a frontend

On 06/02/2017 03:31 PM, Stefano Stabellini wrote: > Introduce a per-frontend data structure named pvcalls_fedata. It > contains pointers to the command ring, its event channel, a list of > active sockets and a tree of passive sockets (passing sockets need to be > looked up from the id on listen,

Re: [PATCH v4 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong wrote: > The PCIe Device Control Register use the bit 4 to indicate that > whether the device is permitted to enable relaxed ordering or not. > But relaxed ordering is not safe for some platform which could only > use strong

Re: [PATCH v4 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong wrote: > The PCIe Device Control Register use the bit 4 to indicate that > whether the device is permitted to enable relaxed ordering or not. > But relaxed ordering is not safe for some platform which could only > use strong write ordering, so

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

Hello, Peter. On Mon, Jun 12, 2017 at 02:31:50PM +0200, Peter Zijlstra wrote: > Please don't rush this; also, I might not be around much the coming > weeks due to taking some leave 'soon' (kid #3 is imminent). Congrats. As for this going forward, how can we possibly be slower? > And I really

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

Hello, Peter. On Mon, Jun 12, 2017 at 02:31:50PM +0200, Peter Zijlstra wrote: > Please don't rush this; also, I might not be around much the coming > weeks due to taking some leave 'soon' (kid #3 is imminent). Congrats. As for this going forward, how can we possibly be slower? > And I really

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

On 6/12/2017 3:51 PM, Arnd Bergmann wrote: On Mon, Jun 12, 2017 at 10:30 PM, Babu Moger wrote: Looks like microblaze can be configured to either little or big endian formats. How about adding a choice statement to address this. Here is my proposed patch. Hi Babu,

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

On 6/12/2017 3:51 PM, Arnd Bergmann wrote: On Mon, Jun 12, 2017 at 10:30 PM, Babu Moger wrote: Looks like microblaze can be configured to either little or big endian formats. How about adding a choice statement to address this. Here is my proposed patch. Hi Babu, This part looks fine, but

Re: PC speaker

On 06/12/17 12:13, R.F. Burns wrote: > Is it possible to write a kernel module which, when loaded, will blow > the PC speaker? > deja vu all over again. Same author. http://marc.info/?l=linux-kernel=118165248822375=2 are you a bot? -- ~Randy

Re: PC speaker

On 06/12/17 12:13, R.F. Burns wrote: > Is it possible to write a kernel module which, when loaded, will blow > the PC speaker? > deja vu all over again. Same author. http://marc.info/?l=linux-kernel=118165248822375=2 are you a bot? -- ~Randy

[PATCH 3/4] mfd: tps65217: remove duplicated interrupt resources.

I don't think it makes sense to have the interrupt resources for charger and power button in two different places, the driver and the DT binding. That's confusing so remove the ones from the mfd driver in favour of having the interrupt resources only described in the DT. Having the resources in DT

[PATCH 3/4] mfd: tps65217: remove duplicated interrupt resources.

I don't think it makes sense to have the interrupt resources for charger and power button in two different places, the driver and the DT binding. That's confusing so remove the ones from the mfd driver in favour of having the interrupt resources only described in the DT. Having the resources in DT

[PATCH 1/4] ARM: dts: tps65217: Add charger interrupts to the common tps65217.dtsi file

The interrupt specifiers for USB and AC charger input are static data that comes from the datasheet, there is no reason to need to define these values on every board so seem reasonable put this information into the common tps65217 file. Signed-off-by: Enric Balletbo i Serra

[PATCH 1/4] ARM: dts: tps65217: Add charger interrupts to the common tps65217.dtsi file

The interrupt specifiers for USB and AC charger input are static data that comes from the datasheet, there is no reason to need to define these values on every board so seem reasonable put this information into the common tps65217 file. Signed-off-by: Enric Balletbo i Serra ---

Re: [PATCH] DocBook: w1: Update W1 file locations and names in DocBook

Hi Andrew, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc5] [cannot apply to next-20170609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] DocBook: w1: Update W1 file locations and names in DocBook

Hi Andrew, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc5] [cannot apply to next-20170609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 4/4] power: supply: tps65217: able to disable the charger block.

The TPS65217 charger is enabled by default, but by default the DT binding sets the charger as disabled, so currently all the devices that include the tps65217 binding have the charger enabled. This patch adds a check in the probe function of the tps65217 charger and disables it if the device

[PATCH 4/4] power: supply: tps65217: able to disable the charger block.

The TPS65217 charger is enabled by default, but by default the DT binding sets the charger as disabled, so currently all the devices that include the tps65217 binding have the charger enabled. This patch adds a check in the probe function of the tps65217 charger and disables it if the device

[PATCH 2/4] ARM: dts: tps65217: Add power button interrupt to the common tps65217.dtsi file

The interrupt for power button is static data that comes from the datasheet, there is no reason to need to define this value on every board so seams reasonable put this information into the common tps65217 file. Signed-off-by: Enric Balletbo i Serra ---

[PATCH 2/4] ARM: dts: tps65217: Add power button interrupt to the common tps65217.dtsi file

The interrupt for power button is static data that comes from the datasheet, there is no reason to need to define this value on every board so seams reasonable put this information into the common tps65217 file. Signed-off-by: Enric Balletbo i Serra --- arch/arm/boot/dts/am335x-bone-common.dtsi

Re: [PATCH v3 04/18] xen/pvcalls: xenbus state handling

On 06/02/2017 03:31 PM, Stefano Stabellini wrote: > Introduce the code to handle xenbus state changes. > > Implement the probe function for the pvcalls backend. Write the > supported versions, max-page-order and function-calls nodes to xenstore, > as required by the protocol. > > Introduce stub

Re: [PATCH v3 04/18] xen/pvcalls: xenbus state handling

On 06/02/2017 03:31 PM, Stefano Stabellini wrote: > Introduce the code to handle xenbus state changes. > > Implement the probe function for the pvcalls backend. Write the > supported versions, max-page-order and function-calls nodes to xenstore, > as required by the protocol. > > Introduce stub

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