Re: [PATCH v9 11/17] platform/x86: dell-smbios-smm: test for WSMT

On Tue, Oct 17, 2017 at 09:22:58PM +0200, Pali Rohár wrote: > On Tuesday 17 October 2017 13:21:55 Mario Limonciello wrote: > > +/* When enabled this indicates that SMM won't work */ > > +static int test_wsmt_enabled(void) > > +{ > > + struct calling_interface_token *token; > > + > > + /* if

Re: [PATCH v9 11/17] platform/x86: dell-smbios-smm: test for WSMT

On Tue, Oct 17, 2017 at 09:22:58PM +0200, Pali Rohár wrote: > On Tuesday 17 October 2017 13:21:55 Mario Limonciello wrote: > > +/* When enabled this indicates that SMM won't work */ > > +static int test_wsmt_enabled(void) > > +{ > > + struct calling_interface_token *token; > > + > > + /* if

Re: [PATCH v2] dell-laptop: Fix keyboard led max_brightness property for Dell Latitude E6410

On Wed, Oct 18, 2017 at 9:06 PM, Pali Rohár wrote: > This machine reports number of keyboard backlight led levels, instead of > value of the last led level index. Therefore max_brightness properly needs > to be subtracted by 1 to match led max_brightness API. > >

Re: [PATCH v2] dell-laptop: Fix keyboard led max_brightness property for Dell Latitude E6410

On Wed, Oct 18, 2017 at 9:06 PM, Pali Rohár wrote: > This machine reports number of keyboard backlight led levels, instead of > value of the last led level index. Therefore max_brightness properly needs > to be subtracted by 1 to match led max_brightness API. > > Signed-off-by: Pali Rohár >

Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory

On 10/17/17 3:39 PM, David Rientjes wrote: On Wed, 18 Oct 2017, Yang Shi wrote: Yes, this should catch occurrences of "huge unreclaimable slabs", right? Yes, it sounds so. Although single "huge" unreclaimable slab might not result in excessive slabs use in a whole, but this would help to

Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory

On 10/17/17 3:39 PM, David Rientjes wrote: On Wed, 18 Oct 2017, Yang Shi wrote: Yes, this should catch occurrences of "huge unreclaimable slabs", right? Yes, it sounds so. Although single "huge" unreclaimable slab might not result in excessive slabs use in a whole, but this would help to

SystemTap 3.2 release

The SystemTap team announces release 3.2! Highlights include an early experimental eBPF (extended Berkeley Packet Filter) backend, new regex engine that supports extraction of matched expressions, new probe aliases for accepting input from stdin, improved translator diagnostics, support

SystemTap 3.2 release

The SystemTap team announces release 3.2! Highlights include an early experimental eBPF (extended Berkeley Packet Filter) backend, new regex engine that supports extraction of matched expressions, new probe aliases for accepting input from stdin, improved translator diagnostics, support

Re: [PATCH v6 4/5] clocksource: stm32: add clocksource support

On Wed, 18 Oct 2017, Benjamin Gaignard wrote: > Rework driver code to be able to implement clocksource and clockevent > on the same hardware block. > Before this patch only the counter of the hardware block was used to > generate clock events. Now counter will be used to provide a 32 bits > clock

Re: [PATCH v6 4/5] clocksource: stm32: add clocksource support

On Wed, 18 Oct 2017, Benjamin Gaignard wrote: > Rework driver code to be able to implement clocksource and clockevent > on the same hardware block. > Before this patch only the counter of the hardware block was used to > generate clock events. Now counter will be used to provide a 32 bits > clock

driver mmap()'ed vma in process coredump

I have a process which does mmap into a kernel driver to map DMA packet memory into user space. When the process crashes want this memory to be part of coredump for post crash analysis. As well documented VM_IO flag for this vma prevents it. Is always_dump_vma() calling vma->vm_ops "name"

driver mmap()'ed vma in process coredump

I have a process which does mmap into a kernel driver to map DMA packet memory into user space. When the process crashes want this memory to be part of coredump for post crash analysis. As well documented VM_IO flag for this vma prevents it. Is always_dump_vma() calling vma->vm_ops "name"

[PATCH v6 2/6] perf report: cache failed lookups of inlined frames

When no inlined frames could be found for a given address, we did not store this information anywhere. That means we potentially do the costly inliner lookup repeatedly for cases where we know it can never succeed. This patch makes dso__parse_addr_inlines always return a valid inline_node. It

[PATCH v6 2/6] perf report: cache failed lookups of inlined frames

When no inlined frames could be found for a given address, we did not store this information anywhere. That means we potentially do the costly inliner lookup repeatedly for cases where we know it can never succeed. This patch makes dso__parse_addr_inlines always return a valid inline_node. It

[PATCH v6 5/6] perf util: enable handling of inlined frames by default

Now that we have caches in place to speed up the process of finding inlined frames and srcline information repeatedly, we can enable this useful option by default. Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Namhyung Kim Cc: Peter

[PATCH v6 5/6] perf util: enable handling of inlined frames by default

Now that we have caches in place to speed up the process of finding inlined frames and srcline information repeatedly, we can enable this useful option by default. Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Yao Jin Cc: Ingo Molnar Suggested-by: Ingo

[PATCH v6 4/6] perf report: use srcline from callchain for hist entries

This also removes the symbol name from the srcline column, more on this below. This ensures we use the correct srcline, which could originate from a potentially inlined function. The hist entries used to query for the srcline based purely on the IP, which leads to wrong results for inlined

[PATCH v6 4/6] perf report: use srcline from callchain for hist entries

This also removes the symbol name from the srcline column, more on this below. This ensures we use the correct srcline, which could originate from a potentially inlined function. The hist entries used to query for the srcline based purely on the IP, which leads to wrong results for inlined

[PATCH v6 1/6] perf report: properly handle branch count in match_chain

Some of the code paths I introduced before returned too early without running the code to handle a node's branch count. By refactoring match_chain to only have one exit point, this can be remedied. Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Namhyung Kim

[PATCH v6 6/6] perf util: use correct IP mapping to find srcline for hist entry

When inline frame resolution is disabled, a bogus srcline is obtained for hist entries: ~ $ perf report -s sym,srcline --no-inline --stdio -g none 95.21% 0.00% [.] __libc_start_main

[PATCH v6 1/6] perf report: properly handle branch count in match_chain

Some of the code paths I introduced before returned too early without running the code to handle a node's branch count. By refactoring match_chain to only have one exit point, this can be remedied. Cc: Arnaldo Carvalho de Melo Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Yao Jin

[PATCH v6 6/6] perf util: use correct IP mapping to find srcline for hist entry

When inline frame resolution is disabled, a bogus srcline is obtained for hist entries: ~ $ perf report -s sym,srcline --no-inline --stdio -g none 95.21% 0.00% [.] __libc_start_main

[PATCH v6 0/6] generate full callchain cursor entries for inlined frames

This series of patches completely reworks the way inline frames are handled. Instead of querying for the inline nodes on-demand in the individual tools, we now create proper callchain nodes for inlined frames. The advantages this approach brings are numerous: - less duplicated code in the

[PATCH v6 0/6] generate full callchain cursor entries for inlined frames

This series of patches completely reworks the way inline frames are handled. Instead of querying for the inline nodes on-demand in the individual tools, we now create proper callchain nodes for inlined frames. The advantages this approach brings are numerous: - less duplicated code in the

[PATCH v6 3/6] perf report: cache srclines for callchain nodes

On one hand this ensures that the memory is properly freed when the DSO gets freed. On the other hand this significantly speeds up the processing of the callchain nodes when lots of srclines are requested. For one of my data files e.g.: Before: Performance counter stats for 'perf report -s

[PATCH v6 3/6] perf report: cache srclines for callchain nodes

On one hand this ensures that the memory is properly freed when the DSO gets freed. On the other hand this significantly speeds up the processing of the callchain nodes when lots of srclines are requested. For one of my data files e.g.: Before: Performance counter stats for 'perf report -s

Re: [PATCH v6] eeprom: at24: Add OF device ID table

On Tue, Oct 17, 2017 at 11:40 PM, Wolfram Sang wrote: > Hi, > >> + { >> + .compatible = "atmel,spd", >> + .data = (void *)AT24_DEVICE_MAGIC(2048 / 8, >> + AT24_FLAG_READONLY | AT24_FLAG_IRUGO) >> + }, > > checkpatch

Re: [PATCH v6] eeprom: at24: Add OF device ID table

On Tue, Oct 17, 2017 at 11:40 PM, Wolfram Sang wrote: > Hi, > >> + { >> + .compatible = "atmel,spd", >> + .data = (void *)AT24_DEVICE_MAGIC(2048 / 8, >> + AT24_FLAG_READONLY | AT24_FLAG_IRUGO) >> + }, > > checkpatch reported this one as

Re: [PATCH v7 02/10] arm: dts: sunxi: Restore EMAC changes

On Wed, Oct 18, 2017 at 06:44:50PM +0200, Andrew Lunn wrote: > On Wed, Oct 18, 2017 at 01:44:50PM +0200, Corentin Labbe wrote: > > The original dwmac-sun8i DT bindings have some issue on how to handle > > integrated PHY and was reverted in last RC of 4.13. > > But now we have a solution so we need

Re: [PATCH v7 02/10] arm: dts: sunxi: Restore EMAC changes

On Wed, Oct 18, 2017 at 06:44:50PM +0200, Andrew Lunn wrote: > On Wed, Oct 18, 2017 at 01:44:50PM +0200, Corentin Labbe wrote: > > The original dwmac-sun8i DT bindings have some issue on how to handle > > integrated PHY and was reverted in last RC of 4.13. > > But now we have a solution so we need

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On Wed, 2017-10-18 at 18:57 +0100, Ard Biesheuvel wrote: > On 18 October 2017 at 17:29, Eric Dumazet wrote: > > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: > >> Even though calling dql_completed() with a count that exceeds the > >> queued count is a serious

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

On Wed, 2017-10-18 at 18:57 +0100, Ard Biesheuvel wrote: > On 18 October 2017 at 17:29, Eric Dumazet wrote: > > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: > >> Even though calling dql_completed() with a count that exceeds the > >> queued count is a serious error, it still does not

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou wrote: > On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote: >> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote: >> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou wrote: > On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote: >> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote: >> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand >> > wrote: >> >> On 10/17/17 14:46, Rob Herring wrote: >> >>> On Tue, Oct

[GIT PULL] xfs: fixes for 4.14-rc6

Hi Linus, Here's a fourth round of fixes for bugs and other build problems. --D The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9: Linux 4.14-rc5 (2017-10-15 21:01:12 -0400) are available in the git repository at:

[GIT PULL] xfs: fixes for 4.14-rc6

Hi Linus, Here's a fourth round of fixes for bugs and other build problems. --D The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9: Linux 4.14-rc5 (2017-10-15 21:01:12 -0400) are available in the git repository at:

Re: [PATCH v6 3/5] clocksource: stm32: only use 32 bits timers

On Wed, 18 Oct 2017, Benjamin Gaignard wrote: > 16 bits hardware are not enough accure to be used. That should probably read: 16 bit counters are not accurate enough to be used. Right? > Do no allow them to be probed by tested max counter value. I really do not understand why you want to

Re: [PATCH v6 3/5] clocksource: stm32: only use 32 bits timers

On Wed, 18 Oct 2017, Benjamin Gaignard wrote: > 16 bits hardware are not enough accure to be used. That should probably read: 16 bit counters are not accurate enough to be used. Right? > Do no allow them to be probed by tested max counter value. I really do not understand why you want to

[PATCH-tip v7 02/15] locking/rwsem: Implement a new locking scheme

The current way of using various reader, writer and waiting biases in the rwsem code are confusing and hard to understand. I have to reread the rwsem count guide in the rwsem-xadd.c file from time to time to remind myself how this whole thing works. It also makes the rwsem code harder to be

[PATCH-tip v7 02/15] locking/rwsem: Implement a new locking scheme

The current way of using various reader, writer and waiting biases in the rwsem code are confusing and hard to understand. I have to reread the rwsem count guide in the rwsem-xadd.c file from time to time to remind myself how this whole thing works. It also makes the rwsem code harder to be

[PATCH-tip v7 00/15] locking/rwsem: Rework rwsem-xadd & enable new rwsem features

v6->v7: - Remove reader lock stealing patch and add other patches to improve fairness to writers. - Remove rwsem_wake() optimization, but eliminate duplicated wakeup call to the same waiting writer. - Enable waiting writer to optimisticially spin on the lock. - Reader wakeup will now

[PATCH-tip v7 00/15] locking/rwsem: Rework rwsem-xadd & enable new rwsem features

v6->v7: - Remove reader lock stealing patch and add other patches to improve fairness to writers. - Remove rwsem_wake() optimization, but eliminate duplicated wakeup call to the same waiting writer. - Enable waiting writer to optimisticially spin on the lock. - Reader wakeup will now

[PATCH-tip v7 04/15] locking/rwsem: Remove kernel/locking/rwsem.h

The content of kernel/locking/rwsem.h is now specific to rwsem-xadd. So we can just move the its content into rwsem-xadd.h and remove it. Signed-off-by: Waiman Long --- kernel/locking/percpu-rwsem.c | 4 ++- kernel/locking/rwsem-xadd.c | 2 +- kernel/locking/rwsem-xadd.h

[PATCH-tip v7 04/15] locking/rwsem: Remove kernel/locking/rwsem.h

The content of kernel/locking/rwsem.h is now specific to rwsem-xadd. So we can just move the its content into rwsem-xadd.h and remove it. Signed-off-by: Waiman Long --- kernel/locking/percpu-rwsem.c | 4 ++- kernel/locking/rwsem-xadd.c | 2 +- kernel/locking/rwsem-xadd.h | 66

[PATCH-tip v7 01/15] locking/rwsem: relocate rwsem_down_read_failed()

The rwsem_down_read_failed*() functions were relocted from above the optimistic spinning section to below that section. This enables them to use functions in that section in future patches. There is no code change. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c |

[PATCH-tip v7 01/15] locking/rwsem: relocate rwsem_down_read_failed()

The rwsem_down_read_failed*() functions were relocted from above the optimistic spinning section to below that section. This enables them to use functions in that section in future patches. There is no code change. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c | 150

[PATCH-tip v7 09/15] locking/rwsem: Make rwsem_spin_on_owner() return a tri-state value

This patch modifies rwsem_spin_on_owner() to return a tri-state value to better reflect the state of lock holder which enables us to make a better decision of what to do next. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c | 14 +- 1 file changed, 9

[PATCH-tip v7 09/15] locking/rwsem: Make rwsem_spin_on_owner() return a tri-state value

This patch modifies rwsem_spin_on_owner() to return a tri-state value to better reflect the state of lock holder which enables us to make a better decision of what to do next. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c | 14 +- 1 file changed, 9 insertions(+), 5

[PATCH-tip v7 05/15] locking/rwsem: Move rwsem internal function declarations to rwsem-xadd.h

We don't need to expose rwsem internal functions which are not supposed to be called directly from other kernel code. Signed-off-by: Waiman Long --- include/linux/rwsem.h | 7 --- kernel/locking/rwsem-xadd.h | 7 +++ 2 files changed, 7 insertions(+), 7

[PATCH-tip v7 08/15] locking/rwsem: Enable readers spinning on writer

This patch enables readers to optimistically spin on a rwsem when it is owned by a writer instead of going to sleep directly. The rwsem_can_spin_on_owner() function is extracted out of rwsem_optimistic_spin() and is called directly by rwsem_down_read_failed() and rwsem_down_write_failed(). This

[PATCH-tip v7 05/15] locking/rwsem: Move rwsem internal function declarations to rwsem-xadd.h

We don't need to expose rwsem internal functions which are not supposed to be called directly from other kernel code. Signed-off-by: Waiman Long --- include/linux/rwsem.h | 7 --- kernel/locking/rwsem-xadd.h | 7 +++ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH-tip v7 08/15] locking/rwsem: Enable readers spinning on writer

This patch enables readers to optimistically spin on a rwsem when it is owned by a writer instead of going to sleep directly. The rwsem_can_spin_on_owner() function is extracted out of rwsem_optimistic_spin() and is called directly by rwsem_down_read_failed() and rwsem_down_write_failed(). This

[PATCH-tip v7 11/15] locking/rwsem: Remove rwsem_wake spinlock optimization

The rwsem_wake spinlock optimization was originally put there to reduce lock contention in the wait_lock. However, the usefulness of this optimization has been reduced because of the followings: 1) The use of wake_q recently in the wakeup path has greatly reduce the wait_lock hold time. 2)

[PATCH-tip v7 11/15] locking/rwsem: Remove rwsem_wake spinlock optimization

The rwsem_wake spinlock optimization was originally put there to reduce lock contention in the wait_lock. However, the usefulness of this optimization has been reduced because of the followings: 1) The use of wake_q recently in the wakeup path has greatly reduce the wait_lock hold time. 2)

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou wrote: > On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote: >> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote: >> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand

Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name

On Wed, Oct 18, 2017 at 10:53 AM, Pantelis Antoniou wrote: > On Wed, 2017-10-18 at 10:44 -0500, Rob Herring wrote: >> On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull wrote: >> > On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand >> > wrote: >> >> On 10/17/17 14:46, Rob Herring wrote: >> >>> On Tue, Oct

[PATCH-tip v7 13/15] locking/rwsem: Improve fairness to writers

When the spin disable bit in the owner field is set, writers will stop spinning. However, an incoming stream of readers will be able to go to the front of the OSQ and acquire the lock continuously without ever releasing the read lock. This can lead to writer starvation. Two changes are made to

[PATCH-tip v7 10/15] locking/rwsem: Enable count-based spinning on reader

When the rwsem is owned by reader, writers stop optimistic spinning simply because there is no easy way to figure out if all the readers are actively running or not. However, there are scenarios where the readers are unlikely to sleep and optimistic spinning can help performance. This patch

[PATCH-tip v7 13/15] locking/rwsem: Improve fairness to writers

When the spin disable bit in the owner field is set, writers will stop spinning. However, an incoming stream of readers will be able to go to the front of the OSQ and acquire the lock continuously without ever releasing the read lock. This can lead to writer starvation. Two changes are made to

[PATCH-tip v7 10/15] locking/rwsem: Enable count-based spinning on reader

When the rwsem is owned by reader, writers stop optimistic spinning simply because there is no easy way to figure out if all the readers are actively running or not. However, there are scenarios where the readers are unlikely to sleep and optimistic spinning can help performance. This patch

Re: [PATCH v6 2/5] clocksource: stm32: convert driver to timer_of

On Wed, 18 Oct 2017, Benjamin Gaignard wrote: > Convert driver to use timer_of helpers. This allow to remove > custom proprietary structure. > > Increase min delta value because if it is too small it could > generate too much interrupts and the system will not be able > to catch them all. This

Re: [PATCH v6 2/5] clocksource: stm32: convert driver to timer_of

On Wed, 18 Oct 2017, Benjamin Gaignard wrote: > Convert driver to use timer_of helpers. This allow to remove > custom proprietary structure. > > Increase min delta value because if it is too small it could > generate too much interrupts and the system will not be able > to catch them all. This

[PATCH-tip v7 12/15] locking/rwsem: Eliminate redundant writer wakeup calls

When tasks with short lock hold time acquire a rwsem consecutively, it is possible that they all try to wake up the same waiting task at unlock time. Beside the first wakeup, the rests are a waste of precious CPU cycles. This patch limits the actual wakeup call to only one. To simplify

[PATCH-tip v7 12/15] locking/rwsem: Eliminate redundant writer wakeup calls

When tasks with short lock hold time acquire a rwsem consecutively, it is possible that they all try to wake up the same waiting task at unlock time. Beside the first wakeup, the rests are a waste of precious CPU cycles. This patch limits the actual wakeup call to only one. To simplify

[PATCH-tip v7 14/15] locking/rwsem: Make waiting writer to optimistically spin for the lock

When waiting writers set the handoff bit, they went back to sleep. This introduced a waiting period during which the rwsem could not be acquired, but the designated waiter was not ready to acquire it. To help eliminating this waiting period, the writer that set the handoff bit will then

[PATCH-tip v7 14/15] locking/rwsem: Make waiting writer to optimistically spin for the lock

When waiting writers set the handoff bit, they went back to sleep. This introduced a waiting period during which the rwsem could not be acquired, but the designated waiter was not ready to acquire it. To help eliminating this waiting period, the writer that set the handoff bit will then

[PATCH-tip v7 03/15] locking/rwsem: Move owner setting code from rwsem.c to rwsem-xadd.h

The setting of owner field is specific to rwsem-xadd, it is not needed for rwsem-spinlock. This patch moves all the owner setting code to the fast paths directly within rwsem-add.h file. The rwsem_set_reader_owned() is now only called by the first reader. So there is no need to do a read to check

[PATCH-tip v7 03/15] locking/rwsem: Move owner setting code from rwsem.c to rwsem-xadd.h

The setting of owner field is specific to rwsem-xadd, it is not needed for rwsem-spinlock. This patch moves all the owner setting code to the fast paths directly within rwsem-add.h file. The rwsem_set_reader_owned() is now only called by the first reader. So there is no need to do a read to check

[PATCH-tip v7 07/15] locking/rwsem: Implement lock handoff to prevent lock starvation

Because of writer lock stealing, it is possible that a constant stream of incoming writers will cause a waiting writer or reader to wait indefinitely leading to lock starvation. The mutex code has a lock handoff mechanism to prevent lock starvation. This patch implements a similar lock handoff

[PATCH-tip v7 07/15] locking/rwsem: Implement lock handoff to prevent lock starvation

Because of writer lock stealing, it is possible that a constant stream of incoming writers will cause a waiting writer or reader to wait indefinitely leading to lock starvation. The mutex code has a lock handoff mechanism to prevent lock starvation. This patch implements a similar lock handoff

[PATCH-tip v7 15/15] locking/rwsem: Wake up all readers in wait queue

When the front of the wait queue is a reader, other readers immediately following the first reader will also be woken up at the same time. Assuming that the lock hold times of the other readers still in the queue will be about the same as the readers that are being woken up, there is really not

[PATCH-tip v7 15/15] locking/rwsem: Wake up all readers in wait queue

When the front of the wait queue is a reader, other readers immediately following the first reader will also be woken up at the same time. Assuming that the lock hold times of the other readers still in the queue will be about the same as the readers that are being woken up, there is really not

[PATCH-tip v7 06/15] locking/rwsem: Remove arch specific rwsem files

As the generic rwsem-xadd code is using the appropriate acquire and release versions of the atomic operations, the arch specific rwsem.h files will not that much faster than the generic code. So we can remove those arch specific rwsem.h and stop building asm/rwsem.h to reduce maintenance effort.

[PATCH-tip v7 06/15] locking/rwsem: Remove arch specific rwsem files

As the generic rwsem-xadd code is using the appropriate acquire and release versions of the atomic operations, the arch specific rwsem.h files will not that much faster than the generic code. So we can remove those arch specific rwsem.h and stop building asm/rwsem.h to reduce maintenance effort.

Re: char-TPM: Adjustments for ten function implementations

On Wed, 18 Oct 2017 02:18:46 -0700 Joe Perches wrote: > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote: > > > The printk removals do change the objects. > > > > > > The value of that type of change is only for resource limited > > > systems. > > > > I imagine

Re: char-TPM: Adjustments for ten function implementations

On Wed, 18 Oct 2017 02:18:46 -0700 Joe Perches wrote: > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote: > > > The printk removals do change the objects. > > > > > > The value of that type of change is only for resource limited > > > systems. > > > > I imagine that such small code

Re: Allow automatic kernel taint on unsigned module load to be disabled

Hi Jessica, It seems that there's distribution interest in this - any feedback?

Re: Allow automatic kernel taint on unsigned module load to be disabled

Hi Jessica, It seems that there's distribution interest in this - any feedback?

Re: [PATCH] PCI/AER: update AER status string print to match other AER logs

On 10/18/2017 6:14 AM, David Laight wrote: From: Tyler Baicar [mailto:tbai...@codeaurora.org] Sent: 17 October 2017 18:14 On 10/17/2017 12:00 PM, David Laight wrote: From: Tyler Baicar Sent: 17 October 2017 16:42 Currently the AER driver uses cper_print_bits() to print the AER status string.

Re: [PATCH] PCI/AER: update AER status string print to match other AER logs

On 10/18/2017 6:14 AM, David Laight wrote: From: Tyler Baicar [mailto:tbai...@codeaurora.org] Sent: 17 October 2017 18:14 On 10/17/2017 12:00 PM, David Laight wrote: From: Tyler Baicar Sent: 17 October 2017 16:42 Currently the AER driver uses cper_print_bits() to print the AER status string.

Re: PROBLEM: Kernel BUG in mfgpt_tick (cs5535-clockevt.c) on ALIX 2c3 - null call

On Mon, 16 Oct 2017, David Kozub wrote: > On Mon, 16 Oct 2017, Thomas Gleixner wrote: > > --- a/drivers/clocksource/cs5535-clockevt.c > > +++ b/drivers/clocksource/cs5535-clockevt.c > > @@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id) > > /* Turn off the clock (and

Re: PROBLEM: Kernel BUG in mfgpt_tick (cs5535-clockevt.c) on ALIX 2c3 - null call

On Mon, 16 Oct 2017, David Kozub wrote: > On Mon, 16 Oct 2017, Thomas Gleixner wrote: > > --- a/drivers/clocksource/cs5535-clockevt.c > > +++ b/drivers/clocksource/cs5535-clockevt.c > > @@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id) > > /* Turn off the clock (and

[PATCH v2] dev/dax: fix uninitialized variable build warning

Fix this build warning: warning: 'phys' may be used uninitialized in this function [-Wuninitialized] As reported here: https://lkml.org/lkml/2017/10/16/152 http://kisskb.ellerman.id.au/kisskb/buildresult/13181373/log/ Signed-off-by: Ross Zwisler ---

[PATCH v2] dev/dax: fix uninitialized variable build warning

Fix this build warning: warning: 'phys' may be used uninitialized in this function [-Wuninitialized] As reported here: https://lkml.org/lkml/2017/10/16/152 http://kisskb.ellerman.id.au/kisskb/buildresult/13181373/log/ Signed-off-by: Ross Zwisler --- drivers/dax/device.c | 3 ++- 1 file

Re: char/tpm: Delete an error message for a failed memory allocation in tpm_…()

>> Why did you not reply directly with this request for the update steps >> with the subject “Delete an error message for a failed memory allocation >> in tpm_…()”? >> >> https://patchwork.kernel.org/patch/10009405/ >> https://patchwork.kernel.org/patch/10009415/ >> >> I find that there can be

Re: char/tpm: Delete an error message for a failed memory allocation in tpm_…()

>> Why did you not reply directly with this request for the update steps >> with the subject “Delete an error message for a failed memory allocation >> in tpm_…()”? >> >> https://patchwork.kernel.org/patch/10009405/ >> https://patchwork.kernel.org/patch/10009415/ >> >> I find that there can be

[tip:x86/fpu] x86/cpuid: Prevent out of bound access in do_clear_cpu_cap()

Commit-ID: 57b8b1a1856adaa849d02d547411a553a531022b Gitweb: https://git.kernel.org/tip/57b8b1a1856adaa849d02d547411a553a531022b Author: Thomas Gleixner AuthorDate: Wed, 18 Oct 2017 19:39:35 +0200 Committer: Thomas Gleixner CommitDate: Wed, 18 Oct

[tip:x86/fpu] x86/cpuid: Prevent out of bound access in do_clear_cpu_cap()

Commit-ID: 57b8b1a1856adaa849d02d547411a553a531022b Gitweb: https://git.kernel.org/tip/57b8b1a1856adaa849d02d547411a553a531022b Author: Thomas Gleixner AuthorDate: Wed, 18 Oct 2017 19:39:35 +0200 Committer: Thomas Gleixner CommitDate: Wed, 18 Oct 2017 20:03:34 +0200 x86/cpuid: Prevent

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 18, 2017, at 12:41 PM, Ben Maurer bmau...@fb.com wrote: >> The layout of struct rseq_cs is as follows: > >> start_ip >> Instruction pointer address of the first instruction of the >> sequence of consecutive assembly instructions. > >> post_commit_ip >> Instruction pointer address

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

- On Oct 18, 2017, at 12:41 PM, Ben Maurer bmau...@fb.com wrote: >> The layout of struct rseq_cs is as follows: > >> start_ip >> Instruction pointer address of the first instruction of the >> sequence of consecutive assembly instructions. > >> post_commit_ip >> Instruction pointer address

[PATCH v2] dell-laptop: Fix keyboard led max_brightness property for Dell Latitude E6410

This machine reports number of keyboard backlight led levels, instead of value of the last led level index. Therefore max_brightness properly needs to be subtracted by 1 to match led max_brightness API. Signed-off-by: Pali Rohár Reported-by: Gabriel M. Elder

[PATCH v2] dell-laptop: Fix keyboard led max_brightness property for Dell Latitude E6410

This machine reports number of keyboard backlight led levels, instead of value of the last led level index. Therefore max_brightness properly needs to be subtracted by 1 to match led max_brightness API. Signed-off-by: Pali Rohár Reported-by: Gabriel M. Elder Link:

Re: [alsa-devel] [PATCH] SoC: intel: byt: Introduce new custom IN2 map

On 10/18/17 11:49 AM, Carlo Caione wrote: From: Carlo Caione Introduce a new custom dapm routes map to quirk platforms with the internal mic connected to IN2P. LGTM. If we start getting more quirks for this codec, we should think of adding a module parameters to select

Re: [alsa-devel] [PATCH] SoC: intel: byt: Introduce new custom IN2 map

On 10/18/17 11:49 AM, Carlo Caione wrote: From: Carlo Caione Introduce a new custom dapm routes map to quirk platforms with the internal mic connected to IN2P. LGTM. If we start getting more quirks for this codec, we should think of adding a module parameters to select them from the command

Re: [PATCH] dell-laptop: Fix keyboard led max_brightness property for Dell Latitude E6410

On Monday 16 October 2017 14:48:37 Darren Hart wrote: > On Sun, Oct 15, 2017 at 06:03:14PM +0200, Pali Rohár wrote: > > This machine reports number of keyboard backlight led levels, instead of > > value of the last led level index. Therefore max_brightness properly needs > > to be subtracted by 1

Re: [PATCH] dell-laptop: Fix keyboard led max_brightness property for Dell Latitude E6410

On Monday 16 October 2017 14:48:37 Darren Hart wrote: > On Sun, Oct 15, 2017 at 06:03:14PM +0200, Pali Rohár wrote: > > This machine reports number of keyboard backlight led levels, instead of > > value of the last led level index. Therefore max_brightness properly needs > > to be subtracted by 1

Re: char/tpm: Improve a size determination in nine functions

On Wed, 2017-10-18 at 19:48 +0200, SF Markus Elfring wrote: > > For 1/4 and 2/4: explain why the message can be omitted. > > That's all. > > I assume that there might be also some communication challenges > involved. > > > > 3/4: definitive NAK, too much noise compared to value. > > I tried

Re: char/tpm: Improve a size determination in nine functions

On Wed, 2017-10-18 at 19:48 +0200, SF Markus Elfring wrote: > > For 1/4 and 2/4: explain why the message can be omitted. > > That's all. > > I assume that there might be also some communication challenges > involved. > > > > 3/4: definitive NAK, too much noise compared to value. > > I tried

RE: [PATCH v1 RFC 7/7] Modify tag_ksz.c so that tail tag code can be used by other KSZ switch drivers

> > +#define KSZ9477_INGRESS_TAG_LEN2 > > +#define KSZ9477_PTP_TAG_LEN4 > > +#define KSZ9477_PTP_TAG_INDICATION 0x80 > > + > > +#define KSZ9477_TAIL_TAG_OVERRIDE BIT(9) > > +#define KSZ9477_TAIL_TAG_LOOKUPBIT(10) > > + > > +static int ksz9477_get_tag(u8

RE: [PATCH v1 RFC 7/7] Modify tag_ksz.c so that tail tag code can be used by other KSZ switch drivers

> > +#define KSZ9477_INGRESS_TAG_LEN2 > > +#define KSZ9477_PTP_TAG_LEN4 > > +#define KSZ9477_PTP_TAG_INDICATION 0x80 > > + > > +#define KSZ9477_TAIL_TAG_OVERRIDE BIT(9) > > +#define KSZ9477_TAIL_TAG_LOOKUPBIT(10) > > + > > +static int ksz9477_get_tag(u8

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