[PULL REQUEST] i2c-mux for 4.16-rc1

Hi Wolfram, A couple of patches this time. Just some more compatibles for the pca954x driver and an error handling tweak for the reg driver. Please pull! Cheers, Peter The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215: Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)

[PULL REQUEST] i2c-mux for 4.16-rc1

Hi Wolfram, A couple of patches this time. Just some more compatibles for the pca954x driver and an error handling tweak for the reg driver. Please pull! Cheers, Peter The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215: Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)

Re: [PATCH v2 1/2] kbuild: Require a 'make clean' if we detect gcc changed underneath us

Hi Douglas, 2017-12-23 7:14 GMT+09:00 Douglas Anderson : > Several people reported that the commit 3298b690b21c ("kbuild: Add a > cache for generated variables") caused them problems when they updated > gcc versions. Specifically the reports all looked something similar >

Re: [PATCH v2 1/2] kbuild: Require a 'make clean' if we detect gcc changed underneath us

Hi Douglas, 2017-12-23 7:14 GMT+09:00 Douglas Anderson : > Several people reported that the commit 3298b690b21c ("kbuild: Add a > cache for generated variables") caused them problems when they updated > gcc versions. Specifically the reports all looked something similar > to this: > >> In file

Re: `pci_apply_final_quirks()` taking half a second

Am 29.12.2017 um 17:14 schrieb Alan Stern: On Thu, 28 Dec 2017, Bjorn Helgaas wrote: On Tue, Dec 26, 2017 at 04:55:20PM +0100, Paul Menzel wrote: Am 08.04.2017 um 17:41 schrieb Bjorn Helgaas: On Fri, Apr 07, 2017 at 11:07:15PM +0200, Paul Menzel wrote: Measuring where time is spent

Re: `pci_apply_final_quirks()` taking half a second

Am 29.12.2017 um 17:14 schrieb Alan Stern: On Thu, 28 Dec 2017, Bjorn Helgaas wrote: On Tue, Dec 26, 2017 at 04:55:20PM +0100, Paul Menzel wrote: Am 08.04.2017 um 17:41 schrieb Bjorn Helgaas: On Fri, Apr 07, 2017 at 11:07:15PM +0200, Paul Menzel wrote: Measuring where time is spent

[PATCH] [RFC] mm: page_alloc: skip over regions of invalid pfns on UMA

As a result of bisecting the v4.10..v4.11 commit range, it was determined that commits [1] and [2] are both responsible of a ~170ms early startup improvement on Rcar-H3-ES20 arm64 platform. Since Rcar Gen3 family is not NUMA, we don't define CONFIG_NUMA in the rcar3 defconfig, but this is how the

[PATCH] [RFC] mm: page_alloc: skip over regions of invalid pfns on UMA

As a result of bisecting the v4.10..v4.11 commit range, it was determined that commits [1] and [2] are both responsible of a ~170ms early startup improvement on Rcar-H3-ES20 arm64 platform. Since Rcar Gen3 family is not NUMA, we don't define CONFIG_NUMA in the rcar3 defconfig, but this is how the

[GIT] Sparc

Please pull to get this sparc64 bug fix. Thank you! The following changes since commit 5f520fc318764df800789edd202b5e3b55130613: Merge tag 'trace-v4.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2017-12-27 13:06:57 -0800) are available in the git repository

[GIT] Sparc

Please pull to get this sparc64 bug fix. Thank you! The following changes since commit 5f520fc318764df800789edd202b5e3b55130613: Merge tag 'trace-v4.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2017-12-27 13:06:57 -0800) are available in the git repository

Re: [PATCH net] ethtool: do not print warning for applications using legacy API

Signed-off-by: David Decotigny On Fri, Dec 29, 2017 at 10:02 AM, Stephen Hemminger wrote: > From: Stephen Hemminger > > In kernel log ths message appears on every boot: > "warning: `NetworkChangeNo' uses legacy

Re: [PATCH net] ethtool: do not print warning for applications using legacy API

Signed-off-by: David Decotigny On Fri, Dec 29, 2017 at 10:02 AM, Stephen Hemminger wrote: > From: Stephen Hemminger > > In kernel log ths message appears on every boot: > "warning: `NetworkChangeNo' uses legacy ethtool link settings API, > link modes are only partially reported" > > When

Re: [PATCH 2/2] clk: qcom: Configure the RCGs to a safe source as needed

Hi Amit, Thank you for the patch! Yet something to improve: [auto build test ERROR on clk/clk-next] [also build test ERROR on v4.15-rc5 next-20171222] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 2/2] clk: qcom: Configure the RCGs to a safe source as needed

Hi Amit, Thank you for the patch! Yet something to improve: [auto build test ERROR on clk/clk-next] [also build test ERROR on v4.15-rc5 next-20171222] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v3 net-next 2/5] net: tracepoint: replace tcp_set_state tracepoint with inet_sock_set_state tracepoint

On Sun, Dec 31, 2017 at 6:33 AM, Brendan Gregg wrote: > On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote: >> As sk_state is a common field for struct sock, so the state >> transition tracepoint should not be a TCP specific feature. >> Currently

Re: [PATCH v3 net-next 2/5] net: tracepoint: replace tcp_set_state tracepoint with inet_sock_set_state tracepoint

On Sun, Dec 31, 2017 at 6:33 AM, Brendan Gregg wrote: > On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote: >> As sk_state is a common field for struct sock, so the state >> transition tracepoint should not be a TCP specific feature. >> Currently it traces all AF_INET state transition, so I

Re: general protection fault in skb_segment

On Sat, Dec 30, 2017 at 10:52:20PM -0200, Marcelo Ricardo Leitner wrote: > On Sat, Dec 30, 2017 at 08:42:41AM +0100, Willem de Bruijn wrote: [...] > > Somewhat tangential, but any PF_PACKET socket can set this > > magic gso_size value in its virtio_net_hdr, so if it is assumed to > > be an SCTP

Re: general protection fault in skb_segment

On Sat, Dec 30, 2017 at 10:52:20PM -0200, Marcelo Ricardo Leitner wrote: > On Sat, Dec 30, 2017 at 08:42:41AM +0100, Willem de Bruijn wrote: [...] > > Somewhat tangential, but any PF_PACKET socket can set this > > magic gso_size value in its virtio_net_hdr, so if it is assumed to > > be an SCTP

Re: [patch 0/3] x86/pti: Fix various fallout

> On Dec 30, 2017, at 2:06 PM, Linus Torvalds > wrote: > >> On Sat, Dec 30, 2017 at 1:35 PM, Ingo Molnar wrote: >> >> Linus, I suspect -rc6 is imminent, and it would be nice to at least have the >> LDT >> error path fix in. I'll send you

Re: [patch 0/3] x86/pti: Fix various fallout

> On Dec 30, 2017, at 2:06 PM, Linus Torvalds > wrote: > >> On Sat, Dec 30, 2017 at 1:35 PM, Ingo Molnar wrote: >> >> Linus, I suspect -rc6 is imminent, and it would be nice to at least have the >> LDT >> error path fix in. I'll send you these fixes tomorrow, but feel free to pick >> it

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hello, On (12/29/17 22:59), Tetsuo Handa wrote: [..] > Just an idea: Do we really need to use a semaphore for console_sem? > > Is it possible to replace it with a spinlock? Then, I feel that we can write > to consoles from non-process context (i.e. soft or hard IRQ context), with > write only

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hello, On (12/29/17 22:59), Tetsuo Handa wrote: [..] > Just an idea: Do we really need to use a semaphore for console_sem? > > Is it possible to replace it with a spinlock? Then, I feel that we can write > to consoles from non-process context (i.e. soft or hard IRQ context), with > write only

Re: [PATCH v2] ksm: replace jhash2 with faster hash

Hi, I was send v5, with minor changes, but performance numbers are valid. 2017-12-31 3:07 GMT+03:00 sioh Lee : > hello > > First, thanks for organizing all the experiments. > > and i'm sending you the results of experiments > > Test platform: openstack cloud platform (NEWTON

Re: [PATCH v2] ksm: replace jhash2 with faster hash

Hi, I was send v5, with minor changes, but performance numbers are valid. 2017-12-31 3:07 GMT+03:00 sioh Lee : > hello > > First, thanks for organizing all the experiments. > > and i'm sending you the results of experiments > > Test platform: openstack cloud platform (NEWTON version) > Experiment

Re: [PATCH v2 1/3] irqchip/renesas-intc-irqpin: Use WAKEUP_PATH driver PM flag

On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote: > From: Geert Uytterhoeven > > Since commit 705bc96c2c15313c ("irqchip: renesas-intc-irqpin: Add minimal > runtime PM support"), when an IRQ is used for wakeup, the INTC block's > module clock

Re: [PATCH v2 1/3] irqchip/renesas-intc-irqpin: Use WAKEUP_PATH driver PM flag

On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote: > From: Geert Uytterhoeven > > Since commit 705bc96c2c15313c ("irqchip: renesas-intc-irqpin: Add minimal > runtime PM support"), when an IRQ is used for wakeup, the INTC block's > module clock (if exists) is manually kept running during system

Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag

On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote: > From: Geert Uytterhoeven > > Changes in v2: [By Ulf Hansson] > - I have picked up the series from Geert [1] and converted it into use > the WAKEUP_PATH driver PM flag. This

Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag

On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote: > From: Geert Uytterhoeven > > Changes in v2: [By Ulf Hansson] > - I have picked up the series from Geert [1] and converted it into use > the WAKEUP_PATH driver PM flag. This includes some minor changes to > each >

Re: general protection fault in skb_segment

On Sat, Dec 30, 2017 at 08:42:41AM +0100, Willem de Bruijn wrote: > > syzkaller hit the following crash on > > 37759fa6d0fa9e4d6036d19ac12f555bfc0aeafd > > git://git.cmpxchg.org/linux-mmots.git/master > > compiler: gcc (GCC) 7.1.1 20170620 > > .config is attached > > Raw console output is

Re: general protection fault in skb_segment

On Sat, Dec 30, 2017 at 08:42:41AM +0100, Willem de Bruijn wrote: > > syzkaller hit the following crash on > > 37759fa6d0fa9e4d6036d19ac12f555bfc0aeafd > > git://git.cmpxchg.org/linux-mmots.git/master > > compiler: gcc (GCC) 7.1.1 20170620 > > .config is attached > > Raw console output is

Re: [PATCH v2] ksm: replace jhash2 with faster hash

hello First, thanks for organizing all the experiments. and i'm sending you the results of experiments Test platform: openstack cloud platform (NEWTON version) Experiment node: openstack based cloud compute node (CPU: xeon E5-2620 v3, memory 64gb) VM: (2 VCPU, RAM 4GB, DISK 20GB) * 4 Linux

Re: [PATCH v2] ksm: replace jhash2 with faster hash

hello First, thanks for organizing all the experiments. and i'm sending you the results of experiments Test platform: openstack cloud platform (NEWTON version) Experiment node: openstack based cloud compute node (CPU: xeon E5-2620 v3, memory 64gb) VM: (2 VCPU, RAM 4GB, DISK 20GB) * 4 Linux

Re: [PATCH V5 2/2] ksm: replace jhash2 with faster hash

JFYI performance on more fast/modern CPU: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz [ 172.651044] ksm: crc32c hash() 22633 MB/s [ 172.776060] ksm: xxhash hash() 10920 MB/s [ 172.776066] ksm: choice crc32c as hash function

Re: [PATCH V5 2/2] ksm: replace jhash2 with faster hash

JFYI performance on more fast/modern CPU: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz [ 172.651044] ksm: crc32c hash() 22633 MB/s [ 172.776060] ksm: xxhash hash() 10920 MB/s [ 172.776066] ksm: choice crc32c as hash function

[PATCH V5 2/2] ksm: replace jhash2 with faster hash

1. Pickup, Sioh Lee crc32 patch, after some long conversation 2. Merge with my work on xxhash 3. Add autoselect code to choice fastest hash helper. Base idea are same, replace jhash2 with something faster. Perf numbers: Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz ksm: crc32c hash() 12081 MB/s

[PATCH V5 1/2] xxHash: create arch dependent 32/64-bit xxhash()

xxh32() - fast on both 32/64-bit platforms xxh64() - fast only on 64-bit platform Create xxhash() which will pickup fastest version on compile time. As result depends on cpu word size, the main proporse of that - in memory hashing. Changes: v2: - Create that patch v3 -> v5: -

[PATCH V5 2/2] ksm: replace jhash2 with faster hash

1. Pickup, Sioh Lee crc32 patch, after some long conversation 2. Merge with my work on xxhash 3. Add autoselect code to choice fastest hash helper. Base idea are same, replace jhash2 with something faster. Perf numbers: Intel(R) Xeon(R) CPU E5-2420 v2 @ 2.20GHz ksm: crc32c hash() 12081 MB/s

[PATCH V5 1/2] xxHash: create arch dependent 32/64-bit xxhash()

xxh32() - fast on both 32/64-bit platforms xxh64() - fast only on 64-bit platform Create xxhash() which will pickup fastest version on compile time. As result depends on cpu word size, the main proporse of that - in memory hashing. Changes: v2: - Create that patch v3 -> v5: -

Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang wrote: > When PCH works under eSPI mode, the PMC (Power Management Controller) in > PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in > dead loop if no SUS_ACK assert. This is the basic requirement for

Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang wrote: > When PCH works under eSPI mode, the PMC (Power Management Controller) in > PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in > dead loop if no SUS_ACK assert. This is the basic requirement for the BMC > works as eSPI

Re: About the try to remove cross-release feature entirely by Ingo

On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote: > On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote: > > > > I'm not sure I agree with this part. What if we add a new TCP lock class > > for connections which are used for filesystems/network block devices/...? > > Yes,

Re: About the try to remove cross-release feature entirely by Ingo

On Sat, Dec 30, 2017 at 05:40:28PM -0500, Theodore Ts'o wrote: > On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote: > > > > I'm not sure I agree with this part. What if we add a new TCP lock class > > for connections which are used for filesystems/network block devices/...? > > Yes,

Re: Review of KPTI patchset

On Sat, 30 Dec 2017, Thomas Gleixner wrote: > On Sat, 30 Dec 2017, Mathieu Desnoyers wrote: > The only asymetry is in the error path of write_ldt() which can leak a half > allocated page table. But, that's a nasty one because if there is an > existing LDT mapped, then the pagetable cannot be

Re: Review of KPTI patchset

On Sat, 30 Dec 2017, Thomas Gleixner wrote: > On Sat, 30 Dec 2017, Mathieu Desnoyers wrote: > The only asymetry is in the error path of write_ldt() which can leak a half > allocated page table. But, that's a nasty one because if there is an > existing LDT mapped, then the pagetable cannot be

Re: About the try to remove cross-release feature entirely by Ingo

On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote: > > I'm not sure I agree with this part. What if we add a new TCP lock class > for connections which are used for filesystems/network block devices/...? > Yes, it'll be up to each user to set the lockdep classification correctly, >

Re: About the try to remove cross-release feature entirely by Ingo

On Sat, Dec 30, 2017 at 12:44:17PM -0800, Matthew Wilcox wrote: > > I'm not sure I agree with this part. What if we add a new TCP lock class > for connections which are used for filesystems/network block devices/...? > Yes, it'll be up to each user to set the lockdep classification correctly, >

Re: [PATCH v3 net-next 2/5] net: tracepoint: replace tcp_set_state tracepoint with inet_sock_set_state tracepoint

On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote: > As sk_state is a common field for struct sock, so the state > transition tracepoint should not be a TCP specific feature. > Currently it traces all AF_INET state transition, so I rename this > tracepoint to

Re: [PATCH v3 net-next 2/5] net: tracepoint: replace tcp_set_state tracepoint with inet_sock_set_state tracepoint

On Tue, Dec 19, 2017 at 7:12 PM, Yafang Shao wrote: > As sk_state is a common field for struct sock, so the state > transition tracepoint should not be a TCP specific feature. > Currently it traces all AF_INET state transition, so I rename this > tracepoint to inet_sock_set_state tracepoint with

[GIT PULL] SCSI fixes for 4.15-rc5

Two simple fixes, both of which cause I/O hangs.  The storvsc one is from the hyper-v which can hang under certain hot add/remove conditions and the other is generally, where removing a target and a device in close proximity can result in the release method being executed twice (and subsequent

[GIT PULL] SCSI fixes for 4.15-rc5

Two simple fixes, both of which cause I/O hangs.  The storvsc one is from the hyper-v which can hang under certain hot add/remove conditions and the other is generally, where removing a target and a device in close proximity can result in the release method being executed twice (and subsequent

Re: 4.14.9 doesn't boot (regression)

On Sun, Dec 31, 2017 at 01:03:25AM +0300, Alexander Tsoy wrote: > > Turns out my previous code to print iret frames was a bit ... > > misguided, to put it nicely. Not sure what I was smoking. > > > > Hopefully the below patch should fix it (in place of the previous > > patch). Would you mind

Re: 4.14.9 doesn't boot (regression)

On Sun, Dec 31, 2017 at 01:03:25AM +0300, Alexander Tsoy wrote: > > Turns out my previous code to print iret frames was a bit ... > > misguided, to put it nicely. Not sure what I was smoking. > > > > Hopefully the below patch should fix it (in place of the previous > > patch). Would you mind

Re: [patch 0/3] x86/pti: Fix various fallout

On Sat, Dec 30, 2017 at 1:35 PM, Ingo Molnar wrote: > > Linus, I suspect -rc6 is imminent, and it would be nice to at least have the > LDT > error path fix in. I'll send you these fixes tomorrow, but feel free to pick > it up > from email if you wanted to release -rc6 today.

Re: [patch 0/3] x86/pti: Fix various fallout

On Sat, Dec 30, 2017 at 1:35 PM, Ingo Molnar wrote: > > Linus, I suspect -rc6 is imminent, and it would be nice to at least have the > LDT > error path fix in. I'll send you these fixes tomorrow, but feel free to pick > it up > from email if you wanted to release -rc6 today. I'll do rc6

Re: 4.14.9 doesn't boot (regression)

В Sat, 30 Dec 2017 11:57:46 -0600 Josh Poimboeuf пишет: > On Sat, Dec 30, 2017 at 11:09:46AM -0600, Josh Poimboeuf wrote: > > On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote: > > > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > > > > On Fri, Dec

Re: 4.14.9 doesn't boot (regression)

В Sat, 30 Dec 2017 11:57:46 -0600 Josh Poimboeuf пишет: > On Sat, Dec 30, 2017 at 11:09:46AM -0600, Josh Poimboeuf wrote: > > On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote: > > > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > > > > On Fri, Dec 29, 2017 at 05:10:35PM

Re: Review of KPTI patchset

On Sat, 30 Dec 2017, Mathieu Desnoyers wrote: > - On Dec 30, 2017, at 2:58 PM, Thomas Gleixner t...@linutronix.de wrote: > > /* > > * Called on fork from arch_dup_mmap(). Just copy the current LDT state, > > * the new task is not running, so nothing can be installed. > > */ > > int

Re: Review of KPTI patchset

On Sat, 30 Dec 2017, Mathieu Desnoyers wrote: > - On Dec 30, 2017, at 2:58 PM, Thomas Gleixner t...@linutronix.de wrote: > > /* > > * Called on fork from arch_dup_mmap(). Just copy the current LDT state, > > * the new task is not running, so nothing can be installed. > > */ > > int

Re: [kernel-hardening] [PATCH 0/5] RFC: Public key encryption of dmesg by the kernel

On Sat, Dec 30, 2017 at 6:57 PM, Dan Aloni wrote: > From: Dan Aloni > > Hi All, > > There has been a lot of progress in recent times regarding the removal > of sensitive information from dmesg (pointers, etc.), so I figured - why > not encrypt it all?

Re: [kernel-hardening] [PATCH 0/5] RFC: Public key encryption of dmesg by the kernel

On Sat, Dec 30, 2017 at 6:57 PM, Dan Aloni wrote: > From: Dan Aloni > > Hi All, > > There has been a lot of progress in recent times regarding the removal > of sensitive information from dmesg (pointers, etc.), so I figured - why > not encrypt it all? However, I have not found any existing

uaccess.h: implement unsafe_copy_{to,from}_user()?

Commit 5b24a7a2aa2040c8c50c3b71122901d01661ff78 introduced the unsafe_get_user and unsafe_put_user replacement functions for batched calls to put_user and get_user. I'm trying to make the kernel smaller and reduce stac/clac overhead on x86 by substituting the new functions for such batched

uaccess.h: implement unsafe_copy_{to,from}_user()?

Commit 5b24a7a2aa2040c8c50c3b71122901d01661ff78 introduced the unsafe_get_user and unsafe_put_user replacement functions for batched calls to put_user and get_user. I'm trying to make the kernel smaller and reduce stac/clac overhead on x86 by substituting the new functions for such batched

Re: [patch 0/3] x86/pti: Fix various fallout

* Thomas Gleixner wrote: > The small series fixes the recent fallout of the x86/pti merge: > > - Remove the stale local_flush_tlb() invocations from the CPU hotplug code > > - Remove the stale preempt_disable/enable() pair from __native_flush_tlb() > > - Fix a

Re: [patch 0/3] x86/pti: Fix various fallout

* Thomas Gleixner wrote: > The small series fixes the recent fallout of the x86/pti merge: > > - Remove the stale local_flush_tlb() invocations from the CPU hotplug code > > - Remove the stale preempt_disable/enable() pair from __native_flush_tlb() > > - Fix a bogus free in the

Re: [patch 1/3] x86/ldt: Free the right LDT memory in write_ldt() error path

* Thomas Gleixner wrote: > The error path in write_ldt() frees the already installed LDT memory > instead of the newly allocated which cannot be installed. s/newly allocated /newly allocated one > > Fixes: f55f0501cbf6 ("x86/pti: Put the LDT in its own PGD if PTI is on")

Re: [patch 1/3] x86/ldt: Free the right LDT memory in write_ldt() error path

* Thomas Gleixner wrote: > The error path in write_ldt() frees the already installed LDT memory > instead of the newly allocated which cannot be installed. s/newly allocated /newly allocated one > > Fixes: f55f0501cbf6 ("x86/pti: Put the LDT in its own PGD if PTI is on") > Reported-by:

Re: [patch 2/3] x86/smpboot: Remove stale tlb flush invocations

* Thomas Gleixner wrote: > smpboot_setup_warm_reset_vector() and smpboot_restore_warm_reset_vector() > invoke local_flush_tlb() for no obvious reason. > > Digging in history revealed that the original code in the 2.1 aera added > those because the code manipulated a

Re: [patch 3/3] x86/mm: Remove preempt_disable/enable() from __native_flush_tlb()

The cleanup looks good to me, just a few speling nits: * Thomas Gleixner wrote: > The preempt_disable/enable() pair in __native_flush_tlb() was added in > commit 5cf0791da5c1 ("x86/mm: Disable preemption during CR3 read+write") to > protect the UP variant of

Re: [patch 2/3] x86/smpboot: Remove stale tlb flush invocations

* Thomas Gleixner wrote: > smpboot_setup_warm_reset_vector() and smpboot_restore_warm_reset_vector() > invoke local_flush_tlb() for no obvious reason. > > Digging in history revealed that the original code in the 2.1 aera added > those because the code manipulated a swapper_pg_dir pagetable

Re: [patch 3/3] x86/mm: Remove preempt_disable/enable() from __native_flush_tlb()

The cleanup looks good to me, just a few speling nits: * Thomas Gleixner wrote: > The preempt_disable/enable() pair in __native_flush_tlb() was added in > commit 5cf0791da5c1 ("x86/mm: Disable preemption during CR3 read+write") to > protect the UP variant of flush_tlb_mm_range(). > > That

[PATCH] wan/fsl_ucc_hdlc: Delete an error message for a failed memory allocation in ucc_hdlc_probe()

From: Markus Elfring Date: Sat, 30 Dec 2017 22:25:44 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] wan/fsl_ucc_hdlc: Delete an error message for a failed memory allocation in ucc_hdlc_probe()

From: Markus Elfring Date: Sat, 30 Dec 2017 22:25:44 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/wan/fsl_ucc_hdlc.c | 1 - 1 file changed, 1 deletion(-)

Re: [PATCH v2] ksm: replace jhash2 with faster hash

*FACEPALM*, Sorry, just forgot about numbering of old jhash2 -> xxhash conversion Also pickup patch for xxhash - arch dependent xxhash() function that will use fastest algo for current arch. So next will be v5, as that must be v4. Thanks. 2017-12-29 12:52 GMT+03:00 Timofey Titovets

Re: [PATCH v2] ksm: replace jhash2 with faster hash

*FACEPALM*, Sorry, just forgot about numbering of old jhash2 -> xxhash conversion Also pickup patch for xxhash - arch dependent xxhash() function that will use fastest algo for current arch. So next will be v5, as that must be v4. Thanks. 2017-12-29 12:52 GMT+03:00 Timofey Titovets : > Pickup,

[patch 1/3] x86/ldt: Free the right LDT memory in write_ldt() error path

The error path in write_ldt() frees the already installed LDT memory instead of the newly allocated which cannot be installed. Fixes: f55f0501cbf6 ("x86/pti: Put the LDT in its own PGD if PTI is on") Reported-by: Mathieu Desnoyers Signed-off-by: Thomas Gleixner

[patch 1/3] x86/ldt: Free the right LDT memory in write_ldt() error path

The error path in write_ldt() frees the already installed LDT memory instead of the newly allocated which cannot be installed. Fixes: f55f0501cbf6 ("x86/pti: Put the LDT in its own PGD if PTI is on") Reported-by: Mathieu Desnoyers Signed-off-by: Thomas Gleixner --- arch/x86/kernel/ldt.c |2

[patch 3/3] x86/mm: Remove preempt_disable/enable() from __native_flush_tlb()

The preempt_disable/enable() pair in __native_flush_tlb() was added in commit 5cf0791da5c1 ("x86/mm: Disable preemption during CR3 read+write") to protect the UP variant of flush_tlb_mm_range(). That preempt_disable/enable() pair should have been added to the UP variant of flush_tlb_mm_range()

[patch 3/3] x86/mm: Remove preempt_disable/enable() from __native_flush_tlb()

The preempt_disable/enable() pair in __native_flush_tlb() was added in commit 5cf0791da5c1 ("x86/mm: Disable preemption during CR3 read+write") to protect the UP variant of flush_tlb_mm_range(). That preempt_disable/enable() pair should have been added to the UP variant of flush_tlb_mm_range()

[patch 2/3] x86/smpboot: Remove stale tlb flush invocations

smpboot_setup_warm_reset_vector() and smpboot_restore_warm_reset_vector() invoke local_flush_tlb() for no obvious reason. Digging in history revealed that the original code in the 2.1 aera added those because the code manipulated a swapper_pg_dir pagetable entry. The pagetable manipulation was

[patch 2/3] x86/smpboot: Remove stale tlb flush invocations

smpboot_setup_warm_reset_vector() and smpboot_restore_warm_reset_vector() invoke local_flush_tlb() for no obvious reason. Digging in history revealed that the original code in the 2.1 aera added those because the code manipulated a swapper_pg_dir pagetable entry. The pagetable manipulation was

[patch 0/3] x86/pti: Fix various fallout

The small series fixes the recent fallout of the x86/pti merge: - Remove the stale local_flush_tlb() invocations from the CPU hotplug code - Remove the stale preempt_disable/enable() pair from __native_flush_tlb() - Fix a bogus free in the write_ldt() error path Thanks, tglx

[patch 0/3] x86/pti: Fix various fallout

The small series fixes the recent fallout of the x86/pti merge: - Remove the stale local_flush_tlb() invocations from the CPU hotplug code - Remove the stale preempt_disable/enable() pair from __native_flush_tlb() - Fix a bogus free in the write_ldt() error path Thanks, tglx

[tip:core/urgent] objtool: Fix seg fault with clang-compiled objects

Commit-ID: ce90aaf5cde4ce057b297bb6c955caf16ef00ee6 Gitweb: https://git.kernel.org/tip/ce90aaf5cde4ce057b297bb6c955caf16ef00ee6 Author: Simon Ser AuthorDate: Sat, 30 Dec 2017 14:43:32 -0600 Committer: Ingo Molnar CommitDate: Sat, 30 Dec 2017

[tip:core/urgent] objtool: Fix seg fault with clang-compiled objects

Commit-ID: ce90aaf5cde4ce057b297bb6c955caf16ef00ee6 Gitweb: https://git.kernel.org/tip/ce90aaf5cde4ce057b297bb6c955caf16ef00ee6 Author: Simon Ser AuthorDate: Sat, 30 Dec 2017 14:43:32 -0600 Committer: Ingo Molnar CommitDate: Sat, 30 Dec 2017 22:04:17 +0100 objtool: Fix seg fault with

[tip:core/urgent] objtool: Fix seg fault caused by missing parameter

Commit-ID: d89e426499cf36b96161bd32970d6783f1fbcb0e Gitweb: https://git.kernel.org/tip/d89e426499cf36b96161bd32970d6783f1fbcb0e Author: Simon Ser AuthorDate: Sat, 30 Dec 2017 14:43:31 -0600 Committer: Ingo Molnar CommitDate: Sat, 30 Dec 2017

[tip:core/urgent] objtool: Fix seg fault caused by missing parameter

Commit-ID: d89e426499cf36b96161bd32970d6783f1fbcb0e Gitweb: https://git.kernel.org/tip/d89e426499cf36b96161bd32970d6783f1fbcb0e Author: Simon Ser AuthorDate: Sat, 30 Dec 2017 14:43:31 -0600 Committer: Ingo Molnar CommitDate: Sat, 30 Dec 2017 22:04:17 +0100 objtool: Fix seg fault

[PATCH 2/2] at76c50x-usb: Improve size determinations in at76_usbdfu_download()

From: Markus Elfring Date: Sat, 30 Dec 2017 21:56:56 +0100 Replace the specification of two data types by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/2] at76c50x-usb: Improve size determinations in at76_usbdfu_download()

From: Markus Elfring Date: Sat, 30 Dec 2017 21:56:56 +0100 Replace the specification of two data types by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 1/2] at76c50x-usb: Delete an error message for a failed memory allocation in at76_submit_rx_urb()

From: Markus Elfring Date: Sat, 30 Dec 2017 21:50:12 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] at76c50x-usb: Delete an error message for a failed memory allocation in at76_submit_rx_urb()

From: Markus Elfring Date: Sat, 30 Dec 2017 21:50:12 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/wireless/atmel/at76c50x-usb.c | 2 -- 1 file changed, 2

[PATCH 0/2] at76c50x-usb: Adjustments for two function implementations

From: Markus Elfring Date: Sat, 30 Dec 2017 22:01:23 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in at76_submit_rx_urb() Improve size

[PATCH 0/2] at76c50x-usb: Adjustments for two function implementations

From: Markus Elfring Date: Sat, 30 Dec 2017 22:01:23 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in at76_submit_rx_urb() Improve size determinations in

[PATCH 00/11] drm/sun4i: Add A83T HDMI support

This patch series implements support for A83T DW HDMI and PHY. It is based upon Maxime Ripard's "drm/sun4i: Add A83t LVDS support" patch series which can be found here: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/550035.html While exactly this combination of HDMI

[PATCH 00/11] drm/sun4i: Add A83T HDMI support

This patch series implements support for A83T DW HDMI and PHY. It is based upon Maxime Ripard's "drm/sun4i: Add A83t LVDS support" patch series which can be found here: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/550035.html While exactly this combination of HDMI

[PATCH 02/11] clk: sunxi-ng: a83t: Add M divider to TCON1 clock

TCON1 also has M divider, contrary to TCON0. Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU") Signed-off-by: Jernej Skrabec --- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 05/11] drm/bridge/synopsys: dw-hdmi: Add deinit callback

Some SoCs, like Allwinner A83T, have to do additional cleanup when HDMI driver unloads. When using DW HDMI through DRM bridge API, there is no place to store driver's private data so it can be accessed in unbind function. Because of that, add deinit function which is called at the very end, so

[PATCH 02/11] clk: sunxi-ng: a83t: Add M divider to TCON1 clock

TCON1 also has M divider, contrary to TCON0. Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU") Signed-off-by: Jernej Skrabec --- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c

[PATCH 05/11] drm/bridge/synopsys: dw-hdmi: Add deinit callback

Some SoCs, like Allwinner A83T, have to do additional cleanup when HDMI driver unloads. When using DW HDMI through DRM bridge API, there is no place to store driver's private data so it can be accessed in unbind function. Because of that, add deinit function which is called at the very end, so

[PATCH 03/11] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

Allwinner SoCs have dw hdmi controller v1.32a which exhibits same magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it. Tests show that one iteration is enough. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +--- 1

[PATCH 03/11] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

Allwinner SoCs have dw hdmi controller v1.32a which exhibits same magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it. Tests show that one iteration is enough. Signed-off-by: Jernej Skrabec --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +--- 1 file changed, 5

  1   2   3   4   5   >