Re: [PATCH v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.

On 11/29/2017 02:56 PM, Andrew Lunn wrote: On Tue, Nov 28, 2017 at 04:55:39PM -0800, David Daney wrote: +static int bgx_probe(struct platform_device *pdev) +{ + struct mac_platform_data platform_data; + const __be32 *reg; + u32 port; + u64 addr; + struct

Re: [PATCH v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.

On 11/29/2017 02:56 PM, Andrew Lunn wrote: On Tue, Nov 28, 2017 at 04:55:39PM -0800, David Daney wrote: +static int bgx_probe(struct platform_device *pdev) +{ + struct mac_platform_data platform_data; + const __be32 *reg; + u32 port; + u64 addr; + struct

[PATCH v2] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

The Kryo CPUs are also affected by the Falkor 1003 errata, so we need to do the same workaround on Kryo CPUs. The MIDR is slightly more complicated here, where the PART number is not always the same when looking at all the bits from 15 to 4. Drop the lower 8 bits and just look at the top 4 to see

[PATCH v2] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

The Kryo CPUs are also affected by the Falkor 1003 errata, so we need to do the same workaround on Kryo CPUs. The MIDR is slightly more complicated here, where the PART number is not always the same when looking at all the bits from 15 to 4. Drop the lower 8 bits and just look at the top 4 to see

Re: Unlock-lock questions and the Linux Kernel Memory Model

On Wed, Nov 29, 2017 at 02:18:48PM -0800, Daniel Lustig wrote: > On 11/29/2017 12:42 PM, Paul E. McKenney wrote: > > On Wed, Nov 29, 2017 at 02:53:06PM -0500, Alan Stern wrote: > >> On Wed, 29 Nov 2017, Peter Zijlstra wrote: > >> > >>> On Wed, Nov 29, 2017 at 11:04:53AM -0800, Daniel Lustig wrote:

Re: Unlock-lock questions and the Linux Kernel Memory Model

On Wed, Nov 29, 2017 at 02:18:48PM -0800, Daniel Lustig wrote: > On 11/29/2017 12:42 PM, Paul E. McKenney wrote: > > On Wed, Nov 29, 2017 at 02:53:06PM -0500, Alan Stern wrote: > >> On Wed, 29 Nov 2017, Peter Zijlstra wrote: > >> > >>> On Wed, Nov 29, 2017 at 11:04:53AM -0800, Daniel Lustig wrote:

[PATCH] PCI: Tone down resource mmap warning

From: Bjorn Helgaas When a process tries to mmap more space than is available in a PCI BAR, we emit a warning and a backtrace. The mmap fails anyway, so the backtrace is mainly for debugging. It seems like overkill now, so reduce this to a dev_info() and remove the

[PATCH] PCI: Tone down resource mmap warning

From: Bjorn Helgaas When a process tries to mmap more space than is available in a PCI BAR, we emit a warning and a backtrace. The mmap fails anyway, so the backtrace is mainly for debugging. It seems like overkill now, so reduce this to a dev_info() and remove the backtrace. This was added

Re: [PATCH v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.

On Tue, Nov 28, 2017 at 04:55:39PM -0800, David Daney wrote: > +static int bgx_probe(struct platform_device *pdev) > +{ > + struct mac_platform_data platform_data; > + const __be32 *reg; > + u32 port; > + u64 addr; > + struct device_node *child; > + struct platform_device

Re: [PATCH v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.

On Tue, Nov 28, 2017 at 04:55:39PM -0800, David Daney wrote: > +static int bgx_probe(struct platform_device *pdev) > +{ > + struct mac_platform_data platform_data; > + const __be32 *reg; > + u32 port; > + u64 addr; > + struct device_node *child; > + struct platform_device

Re: proc: fix /proc/*/map_files lookup

On Mon, 27 Nov 2017 21:29:25 -0800 Andrei Vagin wrote: > On Tue, Nov 21, 2017 at 12:27:06AM +0300, Alexey Dobriyan wrote: > > Current code does: > > > > if (sscanf(dentry->d_name.name, "%lx-%lx", start, end) != 2) > > > > However sscanf() is broken garbage. > > > >

Re: proc: fix /proc/*/map_files lookup

On Mon, 27 Nov 2017 21:29:25 -0800 Andrei Vagin wrote: > On Tue, Nov 21, 2017 at 12:27:06AM +0300, Alexey Dobriyan wrote: > > Current code does: > > > > if (sscanf(dentry->d_name.name, "%lx-%lx", start, end) != 2) > > > > However sscanf() is broken garbage. > > > > It silently accepts

Re: [patch v12 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

Thanks for working on the driver, Oleksandr. I gave this a try on a board with Aspeed 2520. One question below: On Tue, Nov 14, 2017 at 8:11 AM, Oleksandr Shamray wrote: > Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller. > > Driver implements

Re: [patch v12 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

Thanks for working on the driver, Oleksandr. I gave this a try on a board with Aspeed 2520. One question below: On Tue, Nov 14, 2017 at 8:11 AM, Oleksandr Shamray wrote: > Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller. > > Driver implements the following jtag ops: > -

Save and Restore Generic Interrupt Controller for System Sleep on ARM

There was some work in ARM Trusted Firmware to support saving and restoring the Generic Interrupt Controller (GICv3) before and after sleep, but it seems that the plan is to have this all in the kernel now. The point of doing this is to save power during sleep. On an RK3399 system, we save about

Save and Restore Generic Interrupt Controller for System Sleep on ARM

There was some work in ARM Trusted Firmware to support saving and restoring the Generic Interrupt Controller (GICv3) before and after sleep, but it seems that the plan is to have this all in the kernel now. The point of doing this is to save power during sleep. On an RK3399 system, we save about

Re: [RFC 0/2] of: Add whitelist

On 11/29/17 04:20, Frank Rowand wrote: > On 11/27/17 15:58, Alan Tull wrote: >> Here's a proposal for a whitelist to lock down the dynamic device tree. >> >> For an overlay to be accepted, all of its targets are required to be >> on a target node whitelist. >> >> Currently the only way I have to

Re: [RFC 0/2] of: Add whitelist

On 11/29/17 04:20, Frank Rowand wrote: > On 11/27/17 15:58, Alan Tull wrote: >> Here's a proposal for a whitelist to lock down the dynamic device tree. >> >> For an overlay to be accepted, all of its targets are required to be >> on a target node whitelist. >> >> Currently the only way I have to

Re: [PATCH v5] HID: hid-multitouch: support fine-grain orientation reporting

On 10/12/2017 08:21 AM, Wei-Ning Huang wrote: From: Wei-Ning Huang The current hid-multitouch driver only allow the report of two orientations, vertical and horizontal. We use the Azimuth orientation usage 0x3F under the Digitizer usage page to report orientation if the

Re: [PATCH v5] HID: hid-multitouch: support fine-grain orientation reporting

On 10/12/2017 08:21 AM, Wei-Ning Huang wrote: From: Wei-Ning Huang The current hid-multitouch driver only allow the report of two orientations, vertical and horizontal. We use the Azimuth orientation usage 0x3F under the Digitizer usage page to report orientation if the device supports it.

Re: [PATCH] KVM: x86: inject exceptions produced by x86_decode_insn

On 29/11/2017 19:42, Eduardo Habkost wrote: > The reproducer (not a full test case) is quite simple, see patch below. Great, thanks. I assume that the patch doesn't fix it?!? Paolo > Now, I've noticed something interesting when running the > reproducer: > > If the test_fetch_failure() call

Re: [PATCH] KVM: x86: inject exceptions produced by x86_decode_insn

On 29/11/2017 19:42, Eduardo Habkost wrote: > The reproducer (not a full test case) is quite simple, see patch below. Great, thanks. I assume that the patch doesn't fix it?!? Paolo > Now, I've noticed something interesting when running the > reproducer: > > If the test_fetch_failure() call

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

On Wed, Nov 29, 2017 at 2:28 PM, Kees Cook wrote: > > In the future, maybe we could have a knob: unhashed, hashed (default), > or zeroed. I haven't actually seen a case for that yet. Let's see if there are actually any debug issues at all, and how big they are before

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

On Wed, Nov 29, 2017 at 2:28 PM, Kees Cook wrote: > > In the future, maybe we could have a knob: unhashed, hashed (default), > or zeroed. I haven't actually seen a case for that yet. Let's see if there are actually any debug issues at all, and how big they are before worrying about it.

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 7:58 AM, David Miller wrote: > > We're talking about making sure that loading "ppp.ko" really gets > ppp.ko rather than some_other_module.ko renamed to ppp.ko via some > other mechanism. > > Both modules have legitimate signatures so the kernel will

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 7:58 AM, David Miller wrote: > > We're talking about making sure that loading "ppp.ko" really gets > ppp.ko rather than some_other_module.ko renamed to ppp.ko via some > other mechanism. > > Both modules have legitimate signatures so the kernel will happily > load both.

Re: [PATCH] KVM: VMX: Cache IA32_DEBUGCTL in memory

On Wed, Nov 29, 2017 at 11:26:30PM +0100, Paolo Bonzini wrote: > On 29/11/2017 19:20, Andi Kleen wrote: > > But I haven't looked too closely, but I suspect you'll clobber global > > kernel debugger state this way. > > I checked all callers of update_debugctlmsr, and couldn't find any that > could

Re: [PATCH] KVM: VMX: Cache IA32_DEBUGCTL in memory

On Wed, Nov 29, 2017 at 11:26:30PM +0100, Paolo Bonzini wrote: > On 29/11/2017 19:20, Andi Kleen wrote: > > But I haven't looked too closely, but I suspect you'll clobber global > > kernel debugger state this way. > > I checked all callers of update_debugctlmsr, and couldn't find any that > could

Re: [PATCH v5] HID: hid-multitouch: support fine-grain orientation reporting

On Wed, Nov 29, 2017 at 11:33:58PM +0100, Henrik Rydberg wrote: > On 10/12/2017 08:21 AM, Wei-Ning Huang wrote: > > From: Wei-Ning Huang > > > > The current hid-multitouch driver only allow the report of two > > orientations, vertical and horizontal. We use the Azimuth

Re: [PATCH v5] HID: hid-multitouch: support fine-grain orientation reporting

On Wed, Nov 29, 2017 at 11:33:58PM +0100, Henrik Rydberg wrote: > On 10/12/2017 08:21 AM, Wei-Ning Huang wrote: > > From: Wei-Ning Huang > > > > The current hid-multitouch driver only allow the report of two > > orientations, vertical and horizontal. We use the Azimuth orientation > > usage 0x3F

Re: [lkp-robot] [torture] b151f93a71: INFO:rcu_preempt_detected_stalls_on_CPUs/tasks

On Wed, Nov 29, 2017 at 02:07:03PM -0800, Paul E. McKenney wrote: > On Wed, Nov 29, 2017 at 11:08:19AM -0800, Paul E. McKenney wrote: > > On Tue, Nov 28, 2017 at 01:08:10PM -0800, Paul E. McKenney wrote: > > > On Tue, Nov 28, 2017 at 12:46:19PM -0800, Paul E. McKenney wrote: > > > > On Tue, Nov

Re: [lkp-robot] [torture] b151f93a71: INFO:rcu_preempt_detected_stalls_on_CPUs/tasks

On Wed, Nov 29, 2017 at 02:07:03PM -0800, Paul E. McKenney wrote: > On Wed, Nov 29, 2017 at 11:08:19AM -0800, Paul E. McKenney wrote: > > On Tue, Nov 28, 2017 at 01:08:10PM -0800, Paul E. McKenney wrote: > > > On Tue, Nov 28, 2017 at 12:46:19PM -0800, Paul E. McKenney wrote: > > > > On Tue, Nov

RE: [PATCH V11 4/5] vsprintf: add printk specifier %px

> -Original Message- > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees > Cook > Sent: Wednesday, November 29, 2017 2:28 PM > To: David Laight > Cc: Linus Torvalds ; Tobin C. Harding > ;

RE: [PATCH V11 4/5] vsprintf: add printk specifier %px

> -Original Message- > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees > Cook > Sent: Wednesday, November 29, 2017 2:28 PM > To: David Laight > Cc: Linus Torvalds ; Tobin C. Harding > ; kernel-harden...@lists.openwall.com; Jason A. Donenfeld > ; Theodore Ts'o ;

[PATCH 1/2] iio: accel: bmc150: Move struct definitions into the header

The I2C driver needs to access the bmc150_accel_data struct defined in bcm150-accel-core.c, so move it and the structs it requires into the header file. Signed-off-by: Jeremy Cline --- drivers/iio/accel/bmc150-accel-core.c | 43

[PATCH 1/2] iio: accel: bmc150: Move struct definitions into the header

The I2C driver needs to access the bmc150_accel_data struct defined in bcm150-accel-core.c, so move it and the structs it requires into the header file. Signed-off-by: Jeremy Cline --- drivers/iio/accel/bmc150-accel-core.c | 43 drivers/iio/accel/bmc150-accel.h

Re: 'perf test BPF' failing, libbpf regression wrt "basic API for BPF obj name"

On Wed, Nov 29, 2017 at 06:15:43PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 29, 2017 at 01:07:34PM -0800, Martin KaFai Lau escreveu: > > On Tue, Nov 28, 2017 at 04:05:19PM -0300, Arnaldo Carvalho de Melo wrote: > > > > > > [root@jouet ~]# perf test -v bpf > > > 39: BPF filter

Re: 'perf test BPF' failing, libbpf regression wrt "basic API for BPF obj name"

On Wed, Nov 29, 2017 at 06:15:43PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 29, 2017 at 01:07:34PM -0800, Martin KaFai Lau escreveu: > > On Tue, Nov 28, 2017 at 04:05:19PM -0300, Arnaldo Carvalho de Melo wrote: > > > > > > [root@jouet ~]# perf test -v bpf > > > 39: BPF filter

[PATCH 2/2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI device. Check for a companion device and handle a second i2c_client if it is present. Signed-off-by: Jeremy Cline --- drivers/iio/accel/bmc150-accel-i2c.c | 33 -

[PATCH 0/2] iio: accel: bmc150: Check for a second i2c resource

Hey folks, Some BOSC0200 ACPI devices, like the one in the Yoga 11e, have two i2c accelerometers listed under a single ACPI device. This checks to see if there is an ACPI companion and if so handles a second i2c client. Jeremy Cline (2): iio: accel: bmc150: Move struct definitions into the

[PATCH 0/2] iio: accel: bmc150: Check for a second i2c resource

Hey folks, Some BOSC0200 ACPI devices, like the one in the Yoga 11e, have two i2c accelerometers listed under a single ACPI device. This checks to see if there is an ACPI companion and if so handles a second i2c client. Jeremy Cline (2): iio: accel: bmc150: Move struct definitions into the

[PATCH 2/2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200

Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI device. Check for a companion device and handle a second i2c_client if it is present. Signed-off-by: Jeremy Cline --- drivers/iio/accel/bmc150-accel-i2c.c | 33 -

Re: [PATCHv2 0/4] x86: 5-level related changes into decompression code

On Wed, Nov 29, 2017 at 01:33:28PM -0800, H. Peter Anvin wrote: > You can't dump a message about *anything* if the bootloader bypasses the > checks that happen before we leave the firmware behind. This is what > this is about. For BIOS or EFI boot that go through the proper stub > functions we

Re: [PATCHv2 0/4] x86: 5-level related changes into decompression code

On Wed, Nov 29, 2017 at 01:33:28PM -0800, H. Peter Anvin wrote: > You can't dump a message about *anything* if the bootloader bypasses the > checks that happen before we leave the firmware behind. This is what > this is about. For BIOS or EFI boot that go through the proper stub > functions we

Re: [GIT PULL] Btrfs fixes for 4.15-rc2

On Wed, Nov 29, 2017 at 11:28 AM, David Sterba wrote: > > With signed tag: for-4.15-rc2-tag > > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.15-rc2 Oh, please actually ask me to pull the signed tag (exact same pull-request, just point git request-pull

Re: [GIT PULL] Btrfs fixes for 4.15-rc2

On Wed, Nov 29, 2017 at 11:28 AM, David Sterba wrote: > > With signed tag: for-4.15-rc2-tag > > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-4.15-rc2 Oh, please actually ask me to pull the signed tag (exact same pull-request, just point git request-pull at the tag),

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

On Wed, Nov 29, 2017 at 2:07 AM, David Laight wrote: > From: Linus Torvalds >> Sent: 29 November 2017 02:29 >> >> On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding wrote: >> > >> >Let's add specifier %px as a >> > clear, opt-in, way to print a pointer

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

On Wed, Nov 29, 2017 at 2:07 AM, David Laight wrote: > From: Linus Torvalds >> Sent: 29 November 2017 02:29 >> >> On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding wrote: >> > >> >Let's add specifier %px as a >> > clear, opt-in, way to print a pointer and maintain some level of >> >

Re: [PATCH] KVM: VMX: Cache IA32_DEBUGCTL in memory

On 29/11/2017 19:20, Andi Kleen wrote: > But I haven't looked too closely, but I suspect you'll clobber global > kernel debugger state this way. I checked all callers of update_debugctlmsr, and couldn't find any that could run asynchronously while KVM is caching the value. For example

Re: [PATCH] KVM: VMX: Cache IA32_DEBUGCTL in memory

On 29/11/2017 19:20, Andi Kleen wrote: > But I haven't looked too closely, but I suspect you'll clobber global > kernel debugger state this way. I checked all callers of update_debugctlmsr, and couldn't find any that could run asynchronously while KVM is caching the value. For example

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Wed, Nov 29, 2017 at 6:42 AM, Michal Hocko wrote: > The first patch introduced MAP_FIXED_SAFE which enforces the given > address but unlike MAP_FIXED it fails with ENOMEM if the given range > conflicts with an existing one. The flag is introduced as a completely I still

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Wed, Nov 29, 2017 at 6:42 AM, Michal Hocko wrote: > The first patch introduced MAP_FIXED_SAFE which enforces the given > address but unlike MAP_FIXED it fails with ENOMEM if the given range > conflicts with an existing one. The flag is introduced as a completely I still think this name should

[PATCH] usbip: fix usbip attach to find a port that matches the requested speed

usbip attach fails to find a free port when the device on the first port is a USB_SPEED_SUPER device and non-super speed device is being attached. It keeps checking the first port and returns without a match getting stuck in a loop. Fix it check to find the first port with matching speed.

[PATCH] usbip: fix usbip attach to find a port that matches the requested speed

usbip attach fails to find a free port when the device on the first port is a USB_SPEED_SUPER device and non-super speed device is being attached. It keeps checking the first port and returns without a match getting stuck in a loop. Fix it check to find the first port with matching speed.

Re: [PATCH 0/4] lockd refcount conversions

Thanks, applying all four for 4.16.--b. On Wed, Nov 29, 2017 at 01:15:42PM +0200, Elena Reshetova wrote: > This series, for lockd component, replaces atomic_t reference > counters with the new refcount_t type and API (see include/linux/refcount.h). > By doing this we prevent intentional or

Re: [PATCH 0/4] lockd refcount conversions

Thanks, applying all four for 4.16.--b. On Wed, Nov 29, 2017 at 01:15:42PM +0200, Elena Reshetova wrote: > This series, for lockd component, replaces atomic_t reference > counters with the new refcount_t type and API (see include/linux/refcount.h). > By doing this we prevent intentional or

Re: Unlock-lock questions and the Linux Kernel Memory Model

On 11/29/2017 12:42 PM, Paul E. McKenney wrote: > On Wed, Nov 29, 2017 at 02:53:06PM -0500, Alan Stern wrote: >> On Wed, 29 Nov 2017, Peter Zijlstra wrote: >> >>> On Wed, Nov 29, 2017 at 11:04:53AM -0800, Daniel Lustig wrote: >>> While we're here, let me ask about another test which isn't

Re: Unlock-lock questions and the Linux Kernel Memory Model

On 11/29/2017 12:42 PM, Paul E. McKenney wrote: > On Wed, Nov 29, 2017 at 02:53:06PM -0500, Alan Stern wrote: >> On Wed, 29 Nov 2017, Peter Zijlstra wrote: >> >>> On Wed, Nov 29, 2017 at 11:04:53AM -0800, Daniel Lustig wrote: >>> While we're here, let me ask about another test which isn't

Re: [RFC PATCH] ipc, mqueue: lazy call kern_mount_data in new namespaces

On Wed, 29 Nov 2017 11:33:28 +0100 Giuseppe Scrivano wrote: > Andrew Morton writes: > > > OK, but this simply moves the expense so it happens later on. Why is > > that better? > > the optimization is for new IPC namespaces that don't use

Re: [RFC PATCH] ipc, mqueue: lazy call kern_mount_data in new namespaces

On Wed, 29 Nov 2017 11:33:28 +0100 Giuseppe Scrivano wrote: > Andrew Morton writes: > > > OK, but this simply moves the expense so it happens later on. Why is > > that better? > > the optimization is for new IPC namespaces that don't use mq_open. In > this case there won't be any

Re: [PATCH v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.

On Wed, Nov 29, 2017 at 10:11:38PM +0300, Dan Carpenter wrote: > On Wed, Nov 29, 2017 at 09:37:15PM +0530, Souptick Joarder wrote: > > >> +static int bgx_port_sgmii_set_link_speed(struct bgx_port_priv *priv, > > >> struct port_status status) > > >> +{ > > >> + u64 data; > > >> +

Re: [PATCH v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.

On Wed, Nov 29, 2017 at 10:11:38PM +0300, Dan Carpenter wrote: > On Wed, Nov 29, 2017 at 09:37:15PM +0530, Souptick Joarder wrote: > > >> +static int bgx_port_sgmii_set_link_speed(struct bgx_port_priv *priv, > > >> struct port_status status) > > >> +{ > > >> + u64 data; > > >> +

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Wed, Nov 29, 2017 at 7:13 AM, Rasmus Villemoes wrote: > On 2017-11-29 15:42, Michal Hocko wrote: >> >> The first patch introduced MAP_FIXED_SAFE which enforces the given >> address but unlike MAP_FIXED it fails with ENOMEM if the given range >> conflicts with an

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Wed, Nov 29, 2017 at 7:13 AM, Rasmus Villemoes wrote: > On 2017-11-29 15:42, Michal Hocko wrote: >> >> The first patch introduced MAP_FIXED_SAFE which enforces the given >> address but unlike MAP_FIXED it fails with ENOMEM if the given range >> conflicts with an existing one. > >

Re: [PATCH V3 3/4] dmaengine: qcom_hidma: add support for the new revision

+linux-acpi On 11/29/2017 8:58 AM, Vinod Koul wrote: >> +cap = (enum hidma_cap) acpi_device_get_match_data(dev); > should this not reside in core? How about a device_get_match_data() which > returns the data for folks based on node being acpi/of Sure, I'm preparing a device function

Re: [PATCH V3 3/4] dmaengine: qcom_hidma: add support for the new revision

+linux-acpi On 11/29/2017 8:58 AM, Vinod Koul wrote: >> +cap = (enum hidma_cap) acpi_device_get_match_data(dev); > should this not reside in core? How about a device_get_match_data() which > returns the data for folks based on node being acpi/of Sure, I'm preparing a device function

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 1:17 PM, Kees Cook wrote: > > So, what we have now is that the permission verification already > happens at and around the existing request_module() calls. Usually, yes. I liked the "request_module_cap()" interface partly because that made the

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 1:17 PM, Kees Cook wrote: > > So, what we have now is that the permission verification already > happens at and around the existing request_module() calls. Usually, yes. I liked the "request_module_cap()" interface partly because that made the net/core/dev_ioctl.c ones

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Wed, Nov 29, 2017 at 6:42 AM, Michal Hocko wrote: > Except we won't export expose the new semantic to the userspace at all. I'm confused: the changes in patch 1 are explicitly adding MAP_FIXED_SAFE to the uapi. If it's not supposed to be exposed, shouldn't it go somewhere

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Wed, Nov 29, 2017 at 6:42 AM, Michal Hocko wrote: > Except we won't export expose the new semantic to the userspace at all. I'm confused: the changes in patch 1 are explicitly adding MAP_FIXED_SAFE to the uapi. If it's not supposed to be exposed, shouldn't it go somewhere else? -Kees --

Re: [PATCH] rtc: add mxc driver for i.MX53

Hi, A really quick review: On 28/11/2017 at 08:39:27 +0100, linux-kernel-...@beckhoff.com wrote: > From: Patrick Bruenn > > Neither rtc-imxdi nor rtc-mxc are compatible with i.MX53. > Add a modernized version of mxc_v2 from here: >

Re: [PATCH] rtc: add mxc driver for i.MX53

Hi, A really quick review: On 28/11/2017 at 08:39:27 +0100, linux-kernel-...@beckhoff.com wrote: > From: Patrick Bruenn > > Neither rtc-imxdi nor rtc-mxc are compatible with i.MX53. > Add a modernized version of mxc_v2 from here: >

Re: [PATCH v2 6/6] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative

Hi Alexander, > Hello Lukasz, > > some nitpicking below... > > On 21/11/17 15:32, Lukasz Majewski wrote: > > The BK3 board is a derivative of the ts72xx reference design. > > > > Signed-off-by: Lukasz Majewski > > --- > > Changes for v2: > > - Place bk3 support code to the

Re: [PATCH v2 6/6] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative

Hi Alexander, > Hello Lukasz, > > some nitpicking below... > > On 21/11/17 15:32, Lukasz Majewski wrote: > > The BK3 board is a derivative of the ts72xx reference design. > > > > Signed-off-by: Lukasz Majewski > > --- > > Changes for v2: > > - Place bk3 support code to the ts72xx.c file > >

Re: [lkp-robot] [torture] b151f93a71: INFO:rcu_preempt_detected_stalls_on_CPUs/tasks

On Wed, Nov 29, 2017 at 11:08:19AM -0800, Paul E. McKenney wrote: > On Tue, Nov 28, 2017 at 01:08:10PM -0800, Paul E. McKenney wrote: > > On Tue, Nov 28, 2017 at 12:46:19PM -0800, Paul E. McKenney wrote: > > > On Tue, Nov 28, 2017 at 09:35:54AM -0800, Paul E. McKenney wrote: > > > > On Tue, Nov

Re: [lkp-robot] [torture] b151f93a71: INFO:rcu_preempt_detected_stalls_on_CPUs/tasks

On Wed, Nov 29, 2017 at 11:08:19AM -0800, Paul E. McKenney wrote: > On Tue, Nov 28, 2017 at 01:08:10PM -0800, Paul E. McKenney wrote: > > On Tue, Nov 28, 2017 at 12:46:19PM -0800, Paul E. McKenney wrote: > > > On Tue, Nov 28, 2017 at 09:35:54AM -0800, Paul E. McKenney wrote: > > > > On Tue, Nov

Re: [08/24] x86/mm/kaiser: Map the dynamically-allocated LDTs

On Mon, Nov 27, 2017 at 11:49:07AM +0100, Ingo Molnar wrote: > From: Dave Hansen > > Normally, a process has a NULL mm->context.ldt. But, there is a > syscall for a process to set a new one. If a process does that, > the LDT be mapped into the user page tables,

Re: [08/24] x86/mm/kaiser: Map the dynamically-allocated LDTs

On Mon, Nov 27, 2017 at 11:49:07AM +0100, Ingo Molnar wrote: > From: Dave Hansen > > Normally, a process has a NULL mm->context.ldt. But, there is a > syscall for a process to set a new one. If a process does that, > the LDT be mapped into the user page tables, just like the > default copy. >

Re: [PATCH 08/17] drm/sun4i: Add support for DE2 VI planes

Hi, Dne torek, 28. november 2017 ob 22:00:01 CET je Maxime Ripard napisal(a): > Hi, > > On Mon, Nov 27, 2017 at 09:57:41PM +0100, Jernej Skrabec wrote: > > This commit adds basic support for VI planes. They are meant for video > > overlay and because of that they support YUV formats too.

Re: [PATCH 08/17] drm/sun4i: Add support for DE2 VI planes

Hi, Dne torek, 28. november 2017 ob 22:00:01 CET je Maxime Ripard napisal(a): > Hi, > > On Mon, Nov 27, 2017 at 09:57:41PM +0100, Jernej Skrabec wrote: > > This commit adds basic support for VI planes. They are meant for video > > overlay and because of that they support YUV formats too.

Re: Sending 802.1Q packets using AF_PACKET socket on filtered bridge forwards with wrong MAC addresses

I narrowed the search to a memmove() called from skb_reorder_vlan_header() in net/core/skbuff.c. > memmove(skb->data - ETH_HLEN, skb->data - skb->mac_len - VLAN_HLEN, >2 * ETH_ALEN); Calling skb_reset_mac_len() after skb_reset_mac_header() before calling br_allowed_ingress() in

Re: Sending 802.1Q packets using AF_PACKET socket on filtered bridge forwards with wrong MAC addresses

I narrowed the search to a memmove() called from skb_reorder_vlan_header() in net/core/skbuff.c. > memmove(skb->data - ETH_HLEN, skb->data - skb->mac_len - VLAN_HLEN, >2 * ETH_ALEN); Calling skb_reset_mac_len() after skb_reset_mac_header() before calling br_allowed_ingress() in

Re: [PATCH v3 01/16] iommu: introduce bind_pasid_table API function

On Fri, 24 Nov 2017 12:04:08 + Jean-Philippe Brucker wrote: > On 17/11/17 18:54, Jacob Pan wrote: > > Virtual IOMMU was proposed to support Shared Virtual Memory (SVM) > > use in the guest: > > https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg05311.html

Re: [PATCH v3 01/16] iommu: introduce bind_pasid_table API function

On Fri, 24 Nov 2017 12:04:08 + Jean-Philippe Brucker wrote: > On 17/11/17 18:54, Jacob Pan wrote: > > Virtual IOMMU was proposed to support Shared Virtual Memory (SVM) > > use in the guest: > > https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg05311.html > > > > As part of the

Re: [linux-sunxi] [PATCH 11/17] drm/sun4i: Wire in DE2 scaler support

Hi Julian, Dne sreda, 29. november 2017 ob 22:48:34 CET je Julian Calaby napisal(a): > Hi Jernej, > > On Tue, Nov 28, 2017 at 7:57 AM, Jernej Skrabec wrote: > > Calculate scaling parameters and call appropriate scaler set up > > function. > > > > Signed-off-by: Jernej

Re: [linux-sunxi] [PATCH 11/17] drm/sun4i: Wire in DE2 scaler support

Hi Julian, Dne sreda, 29. november 2017 ob 22:48:34 CET je Julian Calaby napisal(a): > Hi Jernej, > > On Tue, Nov 28, 2017 at 7:57 AM, Jernej Skrabec wrote: > > Calculate scaling parameters and call appropriate scaler set up > > function. > > > > Signed-off-by: Jernej Skrabec > > --- > > >

Re: [PATCH] x86/entry/64: Fix native_load_gs_index() SWAPGS handling with IRQ state tracing enabled

On Wed, Nov 29, 2017 at 1:41 PM, Andy Lutomirski wrote: > On Wed, Nov 29, 2017 at 1:25 PM, Andy Lutomirski wrote: >> >> >>> On Nov 29, 2017, at 12:58 PM, Linus Torvalds >>> wrote: >>> On Wed, Nov 29, 2017 at 10:12 AM,

Re: [PATCH] x86/entry/64: Fix native_load_gs_index() SWAPGS handling with IRQ state tracing enabled

On Wed, Nov 29, 2017 at 1:41 PM, Andy Lutomirski wrote: > On Wed, Nov 29, 2017 at 1:25 PM, Andy Lutomirski wrote: >> >> >>> On Nov 29, 2017, at 12:58 PM, Linus Torvalds >>> wrote: >>> On Wed, Nov 29, 2017 at 10:12 AM, Andy Lutomirski wrote: Jarkko, can you try the attached

Re: [PATCH v3 08/16] iommu: introduce device fault data

On Fri, 24 Nov 2017 12:03:33 + Jean-Philippe Brucker wrote: > > + * @rid: requestor ID > > This comment can be removed will do, thanks.

Re: [PATCH v3 08/16] iommu: introduce device fault data

On Fri, 24 Nov 2017 12:03:33 + Jean-Philippe Brucker wrote: > > + * @rid: requestor ID > > This comment can be removed will do, thanks.

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

On Wed, 29 Nov 2017 09:17:34 -0500 Waiman Long wrote: > The list_lru_del() function removes the given item from the LRU list. > The operation looks simple, but it involves writing into the cachelines > of the two neighboring list entries in order to get the deletion done. >

Re: [PATCH v4 2/2] leds: lm3692x: Introduce LM3692x dual string driver

Hi Dan, Thanks for the update. On 11/28/2017 09:40 PM, Dan Murphy wrote: > Introducing the LM3692x Dual-String white LED driver. > > Data sheet is located > http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf > > Signed-off-by: Dan Murphy > --- > v4 - Converted to devm led class

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

On Wed, 29 Nov 2017 09:17:34 -0500 Waiman Long wrote: > The list_lru_del() function removes the given item from the LRU list. > The operation looks simple, but it involves writing into the cachelines > of the two neighboring list entries in order to get the deletion done. > That can take a while

Re: [PATCH v4 2/2] leds: lm3692x: Introduce LM3692x dual string driver

Hi Dan, Thanks for the update. On 11/28/2017 09:40 PM, Dan Murphy wrote: > Introducing the LM3692x Dual-String white LED driver. > > Data sheet is located > http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf > > Signed-off-by: Dan Murphy > --- > v4 - Converted to devm led class register, changed

[PATCH v2 4/5] kasan: support LLVM-style asan parameters

Use cc-option to figure out whether the compiler's sanitizer uses LLVM-style parameters ("-mllvm -asan-foo=bar") or GCC-style parameters ("--param asan-foo=bar"). Signed-off-by: Greg Hackmann Signed-off-by: Paul Lawrence ---

[PATCH v2 2/5] kasan: Add tests for alloca poisonong

Signed-off-by: Greg Hackmann Signed-off-by: Paul Lawrence lib/test_kasan.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/lib/test_kasan.c b/lib/test_kasan.c index ef1a3ac1397e..2724f86c4cef 100644 ---

[PATCH v2 4/5] kasan: support LLVM-style asan parameters

Use cc-option to figure out whether the compiler's sanitizer uses LLVM-style parameters ("-mllvm -asan-foo=bar") or GCC-style parameters ("--param asan-foo=bar"). Signed-off-by: Greg Hackmann Signed-off-by: Paul Lawrence --- scripts/Makefile.kasan | 39 +++

[PATCH v2 2/5] kasan: Add tests for alloca poisonong

Signed-off-by: Greg Hackmann Signed-off-by: Paul Lawrence lib/test_kasan.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/lib/test_kasan.c b/lib/test_kasan.c index ef1a3ac1397e..2724f86c4cef 100644 --- a/lib/test_kasan.c +++ b/lib/test_kasan.c @@ -472,6 +472,26 @@

[PATCH v2 3/5] kasan: added functions for unpoisoning stack variables

From: Alexander Potapenko As a code-size optimization, LLVM builds since r279383 may bulk-manipulate the shadow region when (un)poisoning large memory blocks. This requires new callbacks that simply do an uninstrumented memset(). This fixes linking the Clang-built kernel

[PATCH v2 5/5] kasan: add compiler support for clang

For now we can hard-code ASAN ABI level 5, since historical clang builds can't build the kernel anyway. We also need to emulate gcc's __SANITIZE_ADDRESS__ flag, or memset() calls won't be instrumented. Signed-off-by: Greg Hackmann Signed-off-by: Paul Lawrence

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