Re: [PATCH v5 0/7] /dev/random - a new approach

On 2016-06-21 12:28, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-21 03:32, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos: Hi Nikos, On Mon, Jun 20, 2016 at 5:43 PM, Stephan

Re: [PATCH v5 0/7] /dev/random - a new approach

On 2016-06-21 12:28, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-21 03:32, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos: Hi Nikos, On Mon, Jun 20, 2016 at 5:43 PM, Stephan

Re: kvm: GPF in kvm_irq_map_gsi

On Tue, May 31, 2016 at 11:56 AM, Paolo Bonzini wrote: > > > On 15/02/2016 14:30, Dmitry Vyukov wrote: >> *(uint32_t*)0x2000a6b9 = (uint32_t)0x3e; >> *(uint16_t*)0x2000a6bd = (uint16_t)0x8; >> *(uint8_t*)0x2000a6bf = (uint8_t)0x8d4; >> *(uint8_t*)0x2000a6c0 =

Re: kvm: GPF in kvm_irq_map_gsi

On Tue, May 31, 2016 at 11:56 AM, Paolo Bonzini wrote: > > > On 15/02/2016 14:30, Dmitry Vyukov wrote: >> *(uint32_t*)0x2000a6b9 = (uint32_t)0x3e; >> *(uint16_t*)0x2000a6bd = (uint16_t)0x8; >> *(uint8_t*)0x2000a6bf = (uint8_t)0x8d4; >> *(uint8_t*)0x2000a6c0 =

Re: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, 2016-06-21 at 11:12 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 10:27 AM, Andy Lutomirski > wrote: > > FWIW, it may be a while before this can be enabled in distro > > kernels. > > There are some code paths (*cough* crypto users *cough*) that think > > that

Re: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, 2016-06-21 at 11:12 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 10:27 AM, Andy Lutomirski > wrote: > > FWIW, it may be a while before this can be enabled in distro > > kernels. > > There are some code paths (*cough* crypto users *cough*) that think > > that calling sg_init_one with

Re: [PATCH cgroup/for-4.8] cgroup: allow NULL return from ss->css_alloc()

On Tue, Jun 21, 2016 at 01:06:24PM -0400, Tejun Heo wrote: > cgroup core expected css_alloc to return an ERR_PTR value on failure > and caused NULL deref if it returned NULL. It's an easy mistake to > make from an alloc function and there's no ambiguity in what's being > indicated. Update

Re: [PATCH cgroup/for-4.8] cgroup: allow NULL return from ss->css_alloc()

On Tue, Jun 21, 2016 at 01:06:24PM -0400, Tejun Heo wrote: > cgroup core expected css_alloc to return an ERR_PTR value on failure > and caused NULL deref if it returned NULL. It's an easy mistake to > make from an alloc function and there's no ambiguity in what's being > indicated. Update

Re: [PATCH] memcg: css_alloc should return an ERR_PTR value on error

On Tue, Jun 21, 2016 at 12:57:40PM -0400, Tejun Heo wrote: > mem_cgroup_css_alloc() was returning NULL on failure while cgroup core > expected it to return an ERR_PTR value leading to the following NULL > deref after a css allocation failure. Fix it by return > ERR_PTR(-ENOMEM) instead. I'll

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 10:27 AM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 10:16 AM, Linus Torvalds > wrote: >> On Tue, Jun 21, 2016 at 9:45 AM, Andy Lutomirski wrote: >>> >>> So I'm leaning toward fewer cache

Re: [PATCH] memcg: css_alloc should return an ERR_PTR value on error

On Tue, Jun 21, 2016 at 12:57:40PM -0400, Tejun Heo wrote: > mem_cgroup_css_alloc() was returning NULL on failure while cgroup core > expected it to return an ERR_PTR value leading to the following NULL > deref after a css allocation failure. Fix it by return > ERR_PTR(-ENOMEM) instead. I'll

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 10:27 AM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 10:16 AM, Linus Torvalds > wrote: >> On Tue, Jun 21, 2016 at 9:45 AM, Andy Lutomirski wrote: >>> >>> So I'm leaning toward fewer cache entries per cpu, maybe just one. >>> I'm all for making it a bit faster, but

Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

On Tue, Jun 21, 2016 at 11:05 AM, Stephan Mueller wrote: > As part of the Y2038 development, __getnstimeofday is not supposed to be > used any more. It is now replaced with ktime_get_raw_ns. Albeit > ktime_get_raw_ns is monotonic compared to __getnstimeofday, this >

Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

On Tue, Jun 21, 2016 at 11:05 AM, Stephan Mueller wrote: > As part of the Y2038 development, __getnstimeofday is not supposed to be > used any more. It is now replaced with ktime_get_raw_ns. Albeit > ktime_get_raw_ns is monotonic compared to __getnstimeofday, this > difference is irrelevant as

Re: [PATCH] coresight: always use stashed trace id value in etm4_trace_id

On 21 June 2016 at 11:32, Sudeep Holla wrote: > > > On 21/06/16 18:05, Mathieu Poirier wrote: >> >> On 20 June 2016 at 08:25, Sudeep Holla wrote: >>> >>> etm4_trace_id is not guaranteed to be executed on the CPU whose ETM is >>> being accessed. This

[PATCH] pci: Add support for unbinding the generic PCI host controller

Particularly useful when working in virtual environments where the controller may come and go, but possibly not only there. Signed-off-by: Jan Kiszka --- drivers/pci/ecam.h | 1 + drivers/pci/host/pci-host-common.c | 13 +

Re: [PATCH] coresight: always use stashed trace id value in etm4_trace_id

On 21 June 2016 at 11:32, Sudeep Holla wrote: > > > On 21/06/16 18:05, Mathieu Poirier wrote: >> >> On 20 June 2016 at 08:25, Sudeep Holla wrote: >>> >>> etm4_trace_id is not guaranteed to be executed on the CPU whose ETM is >>> being accessed. This leads to exception similar to below one if the

[PATCH] pci: Add support for unbinding the generic PCI host controller

Particularly useful when working in virtual environments where the controller may come and go, but possibly not only there. Signed-off-by: Jan Kiszka --- drivers/pci/ecam.h | 1 + drivers/pci/host/pci-host-common.c | 13 + drivers/pci/host/pci-host-generic.c | 1

Re: [PATCH v2] power_supply: fix return value of get_property

On 6/16/2016 11:40 AM, Rhyland Klein wrote: > On 6/16/2016 4:43 AM, Krzysztof Kozlowski wrote: >> On 06/16/2016 12:13 AM, Rhyland Klein wrote: >>> power_supply_get_property() should ideally return -EAGAIN if it is >>> called while the power_supply is being registered. There was no way >>>

Re: [PATCH v2] power_supply: fix return value of get_property

On 6/16/2016 11:40 AM, Rhyland Klein wrote: > On 6/16/2016 4:43 AM, Krzysztof Kozlowski wrote: >> On 06/16/2016 12:13 AM, Rhyland Klein wrote: >>> power_supply_get_property() should ideally return -EAGAIN if it is >>> called while the power_supply is being registered. There was no way >>>

Re: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

On Tue, Jun 21, 2016 at 11:01 AM, wrote: >> -Original Message- >> From: Peter Jones [mailto:pjo...@redhat.com] >> Sent: Tuesday, June 21, 2016 10:19 AM >> To: Rafael J. Wysocki >> Cc: ACPI Devel Maling List ;

Re: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

On Tue, Jun 21, 2016 at 11:01 AM, wrote: >> -Original Message- >> From: Peter Jones [mailto:pjo...@redhat.com] >> Sent: Tuesday, June 21, 2016 10:19 AM >> To: Rafael J. Wysocki >> Cc: ACPI Devel Maling List ; Limonciello, Mario >> ; Linux Kernel Mailing List > ker...@vger.kernel.org>;

Re: [PATCH v4] cgroup: Add pids controller event when fork fails because of pid limit

On Tue, Jun 21, 2016 at 10:44:50AM -0700, Kenny Yu wrote: > This patch adds more visibility into the pids controller when the controller > rejects a fork request. Whenever fork fails because the limit on the number of > pids in the cgroup is reached, the controller will log this and also notify >

Re: [PATCH v4] cgroup: Add pids controller event when fork fails because of pid limit

On Tue, Jun 21, 2016 at 10:44:50AM -0700, Kenny Yu wrote: > This patch adds more visibility into the pids controller when the controller > rejects a fork request. Whenever fork fails because the limit on the number of > pids in the cgroup is reached, the controller will log this and also notify >

Re: [PATCH v4] power_supply: power_supply_read_temp only if use_cnt > 0

On 6/9/2016 5:28 PM, Rhyland Klein wrote: > Change power_supply_read_temp() to use power_supply_get_property() > so that it will check the use_cnt and ensure it is > 0. The use_cnt > will be incremented at the end of __power_supply_register, so this > will block to case where get_property can be

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

On Thu, Jun 16, 2016 at 09:33:02AM +0200, Pali Rohár wrote: > On Wednesday 15 June 2016 20:19:58 Darren Hart wrote: > > On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote: > > > First patch describe problem about 0xe045 code. Second and third are just > > > cosmetic and last rework code

Re: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 11:02 AM, Rik van Riel wrote: > On Tue, 2016-06-21 at 10:16 -0700, Kees Cook wrote: >> On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: >> > >> > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: >> > > >> > > >> > > On

Re: [PATCH v4] power_supply: power_supply_read_temp only if use_cnt > 0

On 6/9/2016 5:28 PM, Rhyland Klein wrote: > Change power_supply_read_temp() to use power_supply_get_property() > so that it will check the use_cnt and ensure it is > 0. The use_cnt > will be incremented at the end of __power_supply_register, so this > will block to case where get_property can be

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

On Thu, Jun 16, 2016 at 09:33:02AM +0200, Pali Rohár wrote: > On Wednesday 15 June 2016 20:19:58 Darren Hart wrote: > > On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote: > > > First patch describe problem about 0xe045 code. Second and third are just > > > cosmetic and last rework code

Re: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 11:02 AM, Rik van Riel wrote: > On Tue, 2016-06-21 at 10:16 -0700, Kees Cook wrote: >> On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: >> > >> > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: >> > > >> > > >> > > On my laptop, this adds about 1.5µs

[PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

As part of the Y2038 development, __getnstimeofday is not supposed to be used any more. It is now replaced with ktime_get_raw_ns. Albeit ktime_get_raw_ns is monotonic compared to __getnstimeofday, this difference is irrelevant as the Jitter RNG uses the time stamp to measure the execution time of

Re: [PATCH v2 00/11] Switch to using CRITICAL clks for Tegra

On 5/27/2016 4:38 PM, Rhyland Klein wrote: > Switch to defining clks that need to be on as CRITICAL rather than > using the init_tables defined to enable clks. Some of these may be > able to be converted to HAND_OFF clks, when that is supported. > > I added a patch to mark CRITICAL clks in the

[PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

As part of the Y2038 development, __getnstimeofday is not supposed to be used any more. It is now replaced with ktime_get_raw_ns. Albeit ktime_get_raw_ns is monotonic compared to __getnstimeofday, this difference is irrelevant as the Jitter RNG uses the time stamp to measure the execution time of

Re: [PATCH v2 00/11] Switch to using CRITICAL clks for Tegra

On 5/27/2016 4:38 PM, Rhyland Klein wrote: > Switch to defining clks that need to be on as CRITICAL rather than > using the init_tables defined to enable clks. Some of these may be > able to be converted to HAND_OFF clks, when that is supported. > > I added a patch to mark CRITICAL clks in the

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn: Hi Austin, > > >> 2. Quite a few systems have a rather distressingly low lower bound and > >> still get accepted by your algorithm (a number of the S/390 systems, and > >> a handful of the AMD processors in particular). > > > >

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn: Hi Austin, > > >> 2. Quite a few systems have a rather distressingly low lower bound and > >> still get accepted by your algorithm (a number of the S/390 systems, and > >> a handful of the AMD processors in particular). > > > >

[PATCH] regmap-i2c: Use i2c block command only if register value width is 8 bit

Chips with 16-bit registers don't usually work well with I2C block commands. For example, neither the LM75 datasheet nor the TMP102 datasheet mentions block command support, and in fact it does not work for any of those chips. Also, it is not clear how the block command would handle 16-bit SMBus

[PATCH] regmap-i2c: Use i2c block command only if register value width is 8 bit

Chips with 16-bit registers don't usually work well with I2C block commands. For example, neither the LM75 datasheet nor the TMP102 datasheet mentions block command support, and in fact it does not work for any of those chips. Also, it is not clear how the block command would handle 16-bit SMBus

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 13:54:13 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-21 13:23, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: > > > > Hi Austin, > > > >>> You have to trust the host for anything, not just for the entropy in >

RE: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

> -Original Message- > From: Peter Jones [mailto:pjo...@redhat.com] > Sent: Tuesday, June 21, 2016 10:19 AM > To: Rafael J. Wysocki > Cc: ACPI Devel Maling List ; Limonciello, Mario > ; Linux Kernel Mailing List

Re: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, 2016-06-21 at 10:16 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: > > > > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: > > > > > > > > > On my laptop, this adds about 1.5µs of overhead to task creation, > > > which

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 13:54:13 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-21 13:23, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: > > > > Hi Austin, > > > >>> You have to trust the host for anything, not just for the entropy in >

RE: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

> -Original Message- > From: Peter Jones [mailto:pjo...@redhat.com] > Sent: Tuesday, June 21, 2016 10:19 AM > To: Rafael J. Wysocki > Cc: ACPI Devel Maling List ; Limonciello, Mario > ; Linux Kernel Mailing List ker...@vger.kernel.org>; Len Brown ; Rafael J . Wysocki > ; Andy Lutomirski

Re: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, 2016-06-21 at 10:16 -0700, Kees Cook wrote: > On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: > > > > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: > > > > > > > > > On my laptop, this adds about 1.5µs of overhead to task creation, > > > which seems to be mainly

Re: ktime_get_ts64() splat during resume

On Mon, Jun 20, 2016 at 9:35 PM, Logan Gunthorpe wrote: > Hey Rafael, > > This patch appears to be working on my laptop. Thanks. Same for me: resume still works with KASLR in my tests too. -Kees -- Kees Cook Chrome OS & Brillo Security

Re: ktime_get_ts64() splat during resume

On Mon, Jun 20, 2016 at 9:35 PM, Logan Gunthorpe wrote: > Hey Rafael, > > This patch appears to be working on my laptop. Thanks. Same for me: resume still works with KASLR in my tests too. -Kees -- Kees Cook Chrome OS & Brillo Security

RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

Hi Vinod, > -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Tuesday, June 21, 2016 9:11 PM > To: Appana Durga Kedareswara Rao > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk;

RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

Hi Vinod, > -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Tuesday, June 21, 2016 9:11 PM > To: Appana Durga Kedareswara Rao > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 13:23, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: Hi Austin, You have to trust the host for anything, not just for the entropy in timings. This is completely invalid argument unless you can present a method that one guest can

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 13:23, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: Hi Austin, You have to trust the host for anything, not just for the entropy in timings. This is completely invalid argument unless you can present a method that one guest can

Re: [PATCH 1/2] arm64: defconfig: enable SENSORS_ARM_SCPI

On 13/06/16 16:15, Javi Merino wrote: ARM SCPI Sensors were merged for v4.4 and they are defined in the Juno dts. Enable it in the defconfig to get them registered automatically in Juno by default. Applied, thanks. -- Regards, Sudeep

Re: mm, oom_reaper: How to handle race with oom_killer_disable() ?

On Wed 22-06-16 00:32:29, Tetsuo Handa wrote: > Michal Hocko wrote: [...] > > Hmm, what about the following instead. It is rather a workaround than a > > full flaged fix but it seems much more easier and shouldn't introduce > > new issues. > > Yes, I think that will work. But I think below patch

Re: [PATCH 1/2] arm64: defconfig: enable SENSORS_ARM_SCPI

On 13/06/16 16:15, Javi Merino wrote: ARM SCPI Sensors were merged for v4.4 and they are defined in the Juno dts. Enable it in the defconfig to get them registered automatically in Juno by default. Applied, thanks. -- Regards, Sudeep

Re: mm, oom_reaper: How to handle race with oom_killer_disable() ?

On Wed 22-06-16 00:32:29, Tetsuo Handa wrote: > Michal Hocko wrote: [...] > > Hmm, what about the following instead. It is rather a workaround than a > > full flaged fix but it seems much more easier and shouldn't introduce > > new issues. > > Yes, I think that will work. But I think below patch

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:20, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-20 14:32, Stephan Mueller wrote: Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-18 12:31, Stephan Mueller wrote: Am

Re: [PATCH v4 0/5] /dev/random - a new approach

On 2016-06-21 09:20, Stephan Mueller wrote: Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-20 14:32, Stephan Mueller wrote: Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: Hi Austin, On 2016-06-18 12:31, Stephan Mueller wrote: Am

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On 6/20/16 5:18 AM, Richard Cochran wrote: On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote: The ALSA API provides support for 'audio' timestamps (playback/capture rate defined by audio subsystem) and 'system' timestamps (typically linked to TSC/ART) with one option to take

Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On 6/20/16 5:18 AM, Richard Cochran wrote: On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote: The ALSA API provides support for 'audio' timestamps (playback/capture rate defined by audio subsystem) and 'system' timestamps (typically linked to TSC/ART) with one option to take

RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

> On Tue, Jun 21, 2016 at 04:19:38PM +, Punnaiah Choudary Kalluri wrote: > > > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > > > device-tree But as per lars and your suggestion moved it as > runtime > > > config > > > > > parameters. > > > > > > > > > >

RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

> On Tue, Jun 21, 2016 at 04:19:38PM +, Punnaiah Choudary Kalluri wrote: > > > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > > > device-tree But as per lars and your suggestion moved it as > runtime > > > config > > > > > parameters. > > > > > > > > > >

Re: sound: use-after-free in hrtimer_cancel

On Mon, Jun 6, 2016 at 6:39 PM, Takashi Iwai wrote: > On Mon, 06 Jun 2016 18:29:25 +0200, > Dmitry Vyukov wrote: >> >> On Mon, Jun 6, 2016 at 4:11 PM, Takashi Iwai wrote: >> > On Sat, 04 Jun 2016 20:27:50 +0200, >> > Dmitry Vyukov wrote: >> >> >> >> On Sat, Jun 4,

Re: sound: use-after-free in hrtimer_cancel

On Mon, Jun 6, 2016 at 6:39 PM, Takashi Iwai wrote: > On Mon, 06 Jun 2016 18:29:25 +0200, > Dmitry Vyukov wrote: >> >> On Mon, Jun 6, 2016 at 4:11 PM, Takashi Iwai wrote: >> > On Sat, 04 Jun 2016 20:27:50 +0200, >> > Dmitry Vyukov wrote: >> >> >> >> On Sat, Jun 4, 2016 at 8:00 PM, Dmitry Vyukov

Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

net/bluetooth/smp.c (in smp_e) wants to do AES-ECB on a 16-byte stack buffer, which seems eminently reasonable to me. It does it like this: sg_init_one(, data, 16); skcipher_request_set_tfm(req, tfm); skcipher_request_set_callback(req, 0, NULL, NULL);

Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

net/bluetooth/smp.c (in smp_e) wants to do AES-ECB on a 16-byte stack buffer, which seems eminently reasonable to me. It does it like this: sg_init_one(, data, 16); skcipher_request_set_tfm(req, tfm); skcipher_request_set_callback(req, 0, NULL, NULL);

[PATCH v2 16/16] arm64: dts: msm8996: add sdc2 support

This patch adds support to sdc2 sdhci controller, which is used on some of the boards. Signed-off-by: Srinivas Kandagatla --- Hi Andy, Am resending just this one patch, as It does not make sense to resend entire series for such a small change. changes since v1:

[PATCH v2 16/16] arm64: dts: msm8996: add sdc2 support

This patch adds support to sdc2 sdhci controller, which is used on some of the boards. Signed-off-by: Srinivas Kandagatla --- Hi Andy, Am resending just this one patch, as It does not make sense to resend entire series for such a small change. changes since v1: - converted sdhci

Re: [PATCH v3 0/7] coresight: Miscellaneous fixes

On 21 June 2016 at 10:10, Suzuki K Poulose wrote: > This is a collection of cleanups and minor enhancements to the > coresight driver. Applies on v4.7-rc4 > > Changes since V2: > - Removed patches already queued as fixes for 4.7 > - Addressed comments on V2. > > Changes

Re: [PATCH v3 0/7] coresight: Miscellaneous fixes

On 21 June 2016 at 10:10, Suzuki K Poulose wrote: > This is a collection of cleanups and minor enhancements to the > coresight driver. Applies on v4.7-rc4 > > Changes since V2: > - Removed patches already queued as fixes for 4.7 > - Addressed comments on V2. > > Changes since V1: > - Added a

RE: [PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

Hi Vinod, Thanks for the review... > > On Fri, Jun 10, 2016 at 02:42:32PM +0530, Kedareswara rao Appana wrote: > > This patch adds support for AXI DMA multi-channel dma mode > > Multichannel mode enables DMA to connect to multiple masters And > > slaves on the streaming side. > > In

RE: [PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

Hi Vinod, Thanks for the review... > > On Fri, Jun 10, 2016 at 02:42:32PM +0530, Kedareswara rao Appana wrote: > > This patch adds support for AXI DMA multi-channel dma mode > > Multichannel mode enables DMA to connect to multiple masters And > > slaves on the streaming side. > > In

Re: [PATCH V7 1/8] ACPI: I/O Remapping Table (IORT) initial support

Hi Rafael, On Mon, Jun 20, 2016 at 01:02:14PM +0200, Tomasz Nowicki wrote: > IORT shows representation of IO topology for ARM based systems. > It describes how various components are connected together on > parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec. > > Initial support

Re: [PATCH V7 1/8] ACPI: I/O Remapping Table (IORT) initial support

Hi Rafael, On Mon, Jun 20, 2016 at 01:02:14PM +0200, Tomasz Nowicki wrote: > IORT shows representation of IO topology for ARM based systems. > It describes how various components are connected together on > parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec. > > Initial support

Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

On Tue, Jun 21, 2016 at 10:13 AM, Kees Cook wrote: > On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski wrote: >> On Tue, Jun 21, 2016 at 12:30 AM, Jann Horn wrote: >>> On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski

Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support

On Tue, Jun 21, 2016 at 10:13 AM, Kees Cook wrote: > On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski wrote: >> On Tue, Jun 21, 2016 at 12:30 AM, Jann Horn wrote: >>> On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski wrote: If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 07:06:07PM +0200, Peter Zijlstra wrote: > On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote: > > This has been true since gcc 4.x when tilepro support was first added. > > > > In any case if you replace the #include with > > > > #define __NR_FAST_cmpxchg

Re: linux-next: Tree for Jun 21

On Tue, Jun 21, 2016 at 07:06:07PM +0200, Peter Zijlstra wrote: > On Tue, Jun 21, 2016 at 11:26:19AM -0400, Chris Metcalf wrote: > > This has been true since gcc 4.x when tilepro support was first added. > > > > In any case if you replace the #include with > > > > #define __NR_FAST_cmpxchg

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 10:16 AM, Linus Torvalds wrote: > On Tue, Jun 21, 2016 at 9:45 AM, Andy Lutomirski wrote: >> >> So I'm leaning toward fewer cache entries per cpu, maybe just one. >> I'm all for making it a bit faster, but I think we

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Tue, Jun 21, 2016 at 10:16 AM, Linus Torvalds wrote: > On Tue, Jun 21, 2016 at 9:45 AM, Andy Lutomirski wrote: >> >> So I'm leaning toward fewer cache entries per cpu, maybe just one. >> I'm all for making it a bit faster, but I think we should weigh that >> against increasing memory usage

[PATCH v2 3/8] arm64: dts: db820c: add support to LS-I2C0

This patch adds support to LS-I2C0 on LS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 5/8] arm64: dts: db820c: add support to I2C on HS

This patch adds support to i2c bus on High speed connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 18:51:32 schrieb Stephan Mueller: Hi, > > So.. again, I'd avoid using the "fast" accessor unless there is a > > clear need or obvious benefit. Which should be documented. > > So, you suggest ktime_get_raw_ns? If yes, let me test that for one use case. I tested

[PATCH v2 3/8] arm64: dts: db820c: add support to LS-I2C0

This patch adds support to LS-I2C0 on LS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 5/8] arm64: dts: db820c: add support to I2C on HS

This patch adds support to i2c bus on High speed connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 18:51:32 schrieb Stephan Mueller: Hi, > > So.. again, I'd avoid using the "fast" accessor unless there is a > > clear need or obvious benefit. Which should be documented. > > So, you suggest ktime_get_raw_ns? If yes, let me test that for one use case. I tested

[PATCH v2 2/8] arm64: dts: db820c: add support to LS-UART0

This patch adds support to 4 pin UART0 on LS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 6/8] arm64: dts: db820c: add support to LS-SPI0

This patch adds support to SPI on LS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 0/8] arm64: dts: db820c: Add basic board support

This patchset adds basic board support with uart/i2c/spi/sd card for db820c board based on apq8096. I have tested this patchset on top of msm8996 patches at [1]. With this patchset am able to boot the board with sdcard and able to play with i2c devices. Thanks, srini [1]

[PATCH v2 2/8] arm64: dts: db820c: add support to LS-UART0

This patch adds support to 4 pin UART0 on LS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 6/8] arm64: dts: db820c: add support to LS-SPI0

This patch adds support to SPI on LS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 0/8] arm64: dts: db820c: Add basic board support

This patchset adds basic board support with uart/i2c/spi/sd card for db820c board based on apq8096. I have tested this patchset on top of msm8996 patches at [1]. With this patchset am able to boot the board with sdcard and able to play with i2c devices. Thanks, srini [1]

[PATCH v2 1/8] arm64: dts: db820c: add basic board support

This patch adds apq8096 db820c basic support with serial port. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/Makefile| 1 + arch/arm64/boot/dts/qcom/apq8096-db820c.dts | 21 +

Re: [PATCH] coresight: always use stashed trace id value in etm4_trace_id

On 21/06/16 18:05, Mathieu Poirier wrote: On 20 June 2016 at 08:25, Sudeep Holla wrote: etm4_trace_id is not guaranteed to be executed on the CPU whose ETM is being accessed. This leads to exception similar to below one if the CPU whose ETM is being accessed is in

[PATCH v2 1/8] arm64: dts: db820c: add basic board support

This patch adds apq8096 db820c basic support with serial port. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/Makefile| 1 + arch/arm64/boot/dts/qcom/apq8096-db820c.dts | 21 + arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 34

Re: [PATCH] coresight: always use stashed trace id value in etm4_trace_id

On 21/06/16 18:05, Mathieu Poirier wrote: On 20 June 2016 at 08:25, Sudeep Holla wrote: etm4_trace_id is not guaranteed to be executed on the CPU whose ETM is being accessed. This leads to exception similar to below one if the CPU whose ETM is being accessed is in deeper idle states. So it

[PATCH v2 7/8] arm64: dts: db820c: add support to SPI on HS

This patch adds support to SPI on HS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 4/8] arm64: dts: db820c: add support to LS-I2C1

This patch adds support to LS_I2C1 on LS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 7/8] arm64: dts: db820c: add support to SPI on HS

This patch adds support to SPI on HS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

[PATCH v2 4/8] arm64: dts: db820c: add support to LS-I2C1

This patch adds support to LS_I2C1 on LS expansion connector. Signed-off-by: Srinivas Kandagatla --- arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi

Re: cmpxchg and x86 flags output

On 06/21/16 02:06, David Howells wrote: > > However, there's probably not a great deal of difference to be had if the > inline asm codes the appropriate instruction in each case for something like > x86*. The emitted code ought to look the same. The second biggest win for > the intriniscs, I

Re: cmpxchg and x86 flags output

On 06/21/16 02:06, David Howells wrote: > > However, there's probably not a great deal of difference to be had if the > inline asm codes the appropriate instruction in each case for something like > x86*. The emitted code ought to look the same. The second biggest win for > the intriniscs, I

<    4   5   6   7   8   9   10   11   12   13   >