Re: [PATCH] crypto: x86/twofish-3way - Fix %rbp usage

* Eric Biggers wrote: > There may be a small overhead caused by replacing 'xchg REG, REG' with > the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per > round. But, counterintuitively, when I tested "ctr-twofish-3way" on a > Haswell processor, the new

Re: [PATCH] crypto: x86/twofish-3way - Fix %rbp usage

* Eric Biggers wrote: > There may be a small overhead caused by replacing 'xchg REG, REG' with > the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per > round. But, counterintuitively, when I tested "ctr-twofish-3way" on a > Haswell processor, the new version was actually

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

On 19 December 2017 at 04:56, Masahiro Yamada wrote: > Hi Ulf, > > > 2017-12-15 18:18 GMT+09:00 Ulf Hansson : >> On 24 November 2017 at 17:24, Masahiro Yamada >> wrote: >>> >>> I am working on this IP for

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

On 19 December 2017 at 04:56, Masahiro Yamada wrote: > Hi Ulf, > > > 2017-12-15 18:18 GMT+09:00 Ulf Hansson : >> On 24 November 2017 at 17:24, Masahiro Yamada >> wrote: >>> >>> I am working on this IP for Socionext SoCs. >>> >>> I was hit by several issues, and noticed various >>> clean-up

Re: stack traces and zombie tasks

* Miroslav Benes wrote: > On Sun, 17 Dec 2017, Josh Poimboeuf wrote: > > > On Fri, Dec 15, 2017 at 07:51:45AM -0800, Andy Lutomirski wrote: > > > On Fri, Dec 15, 2017 at 4:54 AM, Miroslav Benes wrote: > > > > Hi, > > > > > > > > commit 1959a60182f4

Re: stack traces and zombie tasks

* Miroslav Benes wrote: > On Sun, 17 Dec 2017, Josh Poimboeuf wrote: > > > On Fri, Dec 15, 2017 at 07:51:45AM -0800, Andy Lutomirski wrote: > > > On Fri, Dec 15, 2017 at 4:54 AM, Miroslav Benes wrote: > > > > Hi, > > > > > > > > commit 1959a60182f4 ("x86/dumpstack: Pin the target stack when

Re: [PATCH v1] media: videobuf2: Add new uAPI for DVB streaming I/O

Dear Satendra, On Tue, Dec 19, 2017 at 4:35 AM, Satendra Singh Thakur wrote: > --- /dev/null > +++ b/drivers/media/dvb-core/dvb_vb2.c > @@ -0,0 +1,422 @@ > +/* > + * dvb-vb2.c - dvb-vb2 > + * > + * Copyright (C) 2015 Samsung Electronics > + * > + * Author:

Re: [PATCH v1] media: videobuf2: Add new uAPI for DVB streaming I/O

Dear Satendra, On Tue, Dec 19, 2017 at 4:35 AM, Satendra Singh Thakur wrote: > --- /dev/null > +++ b/drivers/media/dvb-core/dvb_vb2.c > @@ -0,0 +1,422 @@ > +/* > + * dvb-vb2.c - dvb-vb2 > + * > + * Copyright (C) 2015 Samsung Electronics > + * > + * Author: jh1009.s...@samsung.com > + * > + *

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

* Peter Zijlstra wrote: > On Mon, Dec 18, 2017 at 12:45:13PM -0800, Dave Hansen wrote: > > On 12/18/2017 12:41 PM, Peter Zijlstra wrote: > > >> I also don't think the user_shared area of the fixmap can get *that* > > >> big. Does anybody know offhand what the theoretical

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

* Peter Zijlstra wrote: > On Mon, Dec 18, 2017 at 12:45:13PM -0800, Dave Hansen wrote: > > On 12/18/2017 12:41 PM, Peter Zijlstra wrote: > > >> I also don't think the user_shared area of the fixmap can get *that* > > >> big. Does anybody know offhand what the theoretical limits are there? > >

error: redefinition of ‘shipped_regdb_certs’

Hi Johannes, this is the first time I am seeing this with the current Linus tree. 4.15-rc3 compiled fine. I have checked that you have updated the makefile which generates the file by 715a12334764 ("wireless: don't write C files on failures"). I am getting the following compilation error: CC

error: redefinition of ‘shipped_regdb_certs’

Hi Johannes, this is the first time I am seeing this with the current Linus tree. 4.15-rc3 compiled fine. I have checked that you have updated the makefile which generates the file by 715a12334764 ("wireless: don't write C files on failures"). I am getting the following compilation error: CC

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

Hi Brian, I am sorry for not using the plain text mode in the previous mail. I agree with you on other points. On Tue, Dec 19, 2017 at 1:42 AM, Brian Norris wrote: > Hi! > > (By the way, your mail is HTML and likely will get rejected by many > mailing lists and/or

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

Hi Brian, I am sorry for not using the plain text mode in the previous mail. I agree with you on other points. On Tue, Dec 19, 2017 at 1:42 AM, Brian Norris wrote: > Hi! > > (By the way, your mail is HTML and likely will get rejected by many > mailing lists and/or people reading these mailing

Re: [PATCH 3/4] PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization

On 10 December 2017 at 01:00, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Make the PM core avoid invoking the "late" and "noirq" system-wide > suspend (or analogous) callbacks provided by device drivers directly > for devices with

Re: [PATCH 3/4] PM / core: Direct DPM_FLAG_SMART_SUSPEND optimization

On 10 December 2017 at 01:00, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Make the PM core avoid invoking the "late" and "noirq" system-wide > suspend (or analogous) callbacks provided by device drivers directly > for devices with DPM_FLAG_SMART_SUSPEND set that are in runtime >

Re: [PATCH 4.14 000/178] 4.14.8-stable review

On Mon, Dec 18, 2017 at 01:25:06PM -0700, Shuah Khan wrote: > On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.8 release. > > There are 178 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.14 000/178] 4.14.8-stable review

On Mon, Dec 18, 2017 at 01:25:06PM -0700, Shuah Khan wrote: > On 12/18/2017 08:47 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.8 release. > > There are 178 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.4 000/115] 4.4.107-stable review

On Mon, Dec 18, 2017 at 11:17:30AM -0700, Nathan Chancellor wrote: > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. > > No initial issues noticed in general usage or dmesg. Great, thanks for testing and letting me know. greg k-h

Re: [PATCH 4.4 000/115] 4.4.107-stable review

On Mon, Dec 18, 2017 at 11:17:30AM -0700, Nathan Chancellor wrote: > Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5. > > No initial issues noticed in general usage or dmesg. Great, thanks for testing and letting me know. greg k-h

[PATCH] cgroup: Fix deadlock in cpu hotplug path

Deadlock during cgroup migration from cpu hotplug path when a task T is being moved from source to destination cgroup. kworker/0:0 cpuset_hotplug_workfn() cpuset_hotplug_update_tasks() hotplug_update_tasks_legacy() remove_tasks_in_empty_cpuset() cgroup_transfer_tasks()

[PATCH] cgroup: Fix deadlock in cpu hotplug path

Deadlock during cgroup migration from cpu hotplug path when a task T is being moved from source to destination cgroup. kworker/0:0 cpuset_hotplug_workfn() cpuset_hotplug_update_tasks() hotplug_update_tasks_legacy() remove_tasks_in_empty_cpuset() cgroup_transfer_tasks()

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

Hi Balbir, Sorry was away for few days. On 12/14/2017 05:54 PM, Balbir Singh wrote: > On Tue, Dec 12, 2017 at 11:29 PM, Ravi Bangoria > wrote: >> It may very well happen that branch instructions recorded by >> bhrb entries already get unmapped before they get

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

Hi Balbir, Sorry was away for few days. On 12/14/2017 05:54 PM, Balbir Singh wrote: > On Tue, Dec 12, 2017 at 11:29 PM, Ravi Bangoria > wrote: >> It may very well happen that branch instructions recorded by >> bhrb entries already get unmapped before they get processed by >> the kernel. Hence,

Re: [alsa-devel] [trivial PATCH] treewide: Align function definition open/close braces

On Mon, 18 Dec 2017 01:28:44 +0100, Joe Perches wrote: > > Some functions definitions have either the initial open brace and/or > the closing brace outside of column 1. > > Move those braces to column 1. > > This allows various function analyzers like gnu complexity to work > properly for these

Re: [alsa-devel] [trivial PATCH] treewide: Align function definition open/close braces

On Mon, 18 Dec 2017 01:28:44 +0100, Joe Perches wrote: > > Some functions definitions have either the initial open brace and/or > the closing brace outside of column 1. > > Move those braces to column 1. > > This allows various function analyzers like gnu complexity to work > properly for these

Re: [PATCH v3 07/33] nds32: MMU initialization

Hi, Guo Ren: 2017-12-18 20:22 GMT+08:00 Guo Ren : > On Mon, Dec 18, 2017 at 07:21:30PM +0800, Greentime Hu wrote: >> Hi, Guo Ren: >> >> 2017-12-18 17:08 GMT+08:00 Guo Ren : >> > Hi Greentime, >> > >> > On Fri, Dec 08, 2017 at 05:11:50PM +0800, Greentime Hu

Re: [PATCH v3 07/33] nds32: MMU initialization

Hi, Guo Ren: 2017-12-18 20:22 GMT+08:00 Guo Ren : > On Mon, Dec 18, 2017 at 07:21:30PM +0800, Greentime Hu wrote: >> Hi, Guo Ren: >> >> 2017-12-18 17:08 GMT+08:00 Guo Ren : >> > Hi Greentime, >> > >> > On Fri, Dec 08, 2017 at 05:11:50PM +0800, Greentime Hu wrote: >> > [...] >> >> >> >> diff --git

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

Hi Marc, On Mon Dec 18, 2017 at 03:39:22PM +, Marc Zyngier wrote: > Thanks for putting me in the loop Robin. > > On 18/12/17 14:48, Robin Murphy wrote: > > On 10/12/17 02:35, Linu Cherian wrote: > >> Hi, > >> > >> > >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > >>> This

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

Hi Marc, On Mon Dec 18, 2017 at 03:39:22PM +, Marc Zyngier wrote: > Thanks for putting me in the loop Robin. > > On 18/12/17 14:48, Robin Murphy wrote: > > On 10/12/17 02:35, Linu Cherian wrote: > >> Hi, > >> > >> > >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > >>> This

Re: [PATCH v6] mfd: syscon: Add hardware spinlock support

On 18 December 2017 at 20:44, Arnd Bergmann wrote: > On Mon, Dec 18, 2017 at 7:54 AM, Baolin Wang wrote: >> On 15 December 2017 at 21:13, Arnd Bergmann wrote: >>> On Fri, Dec 15, 2017 at 11:42 AM, Lee Jones wrote: >>>

Re: [PATCH v6] mfd: syscon: Add hardware spinlock support

On 18 December 2017 at 20:44, Arnd Bergmann wrote: > On Mon, Dec 18, 2017 at 7:54 AM, Baolin Wang wrote: >> On 15 December 2017 at 21:13, Arnd Bergmann wrote: >>> On Fri, Dec 15, 2017 at 11:42 AM, Lee Jones wrote: >>> > @@ -87,6 +88,30 @@ static struct syscon *of_syscon_register(struct

[PATCH 3/3] i2c: mediatek: Enable i2c module clock before i2c registers access.

From: Jun Gao Make sure i2c module clock has been enabled before i2c registers access. Signed-off-by: Jun Gao --- drivers/i2c/busses/i2c-mt65xx.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/i2c/busses/i2c-mt65xx.c

[PATCH 3/3] i2c: mediatek: Enable i2c module clock before i2c registers access.

From: Jun Gao Make sure i2c module clock has been enabled before i2c registers access. Signed-off-by: Jun Gao --- drivers/i2c/busses/i2c-mt65xx.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index

[PATCH 0/3] Add i2c dt-binding and compatible for Mediatek MT2712

This patch series based on v4.15-rc1, include MT2712 i2c dt-binding, compatible and i2c module clock enable. Jun Gao (3): dt-bindings: i2c: Add MediaTek MT2712 i2c binding i2c: mediatek: Add i2c compatible for MediaTek MT2712 i2c: mediatek: Enable i2c module clock before i2c registers

[PATCH 1/3] dt-bindings: i2c: Add MediaTek MT2712 i2c binding

From: Jun Gao Add MT2712 i2c binding to binding file. Compare to MT8173 i2c controller, MT2712 has timing adjust registers which can adjust the internal divider of i2c source clock, SCL duty cycle, SCL compare point, start(repeated start) and stop time, SDA change time.

[PATCH 0/3] Add i2c dt-binding and compatible for Mediatek MT2712

This patch series based on v4.15-rc1, include MT2712 i2c dt-binding, compatible and i2c module clock enable. Jun Gao (3): dt-bindings: i2c: Add MediaTek MT2712 i2c binding i2c: mediatek: Add i2c compatible for MediaTek MT2712 i2c: mediatek: Enable i2c module clock before i2c registers

[PATCH 1/3] dt-bindings: i2c: Add MediaTek MT2712 i2c binding

From: Jun Gao Add MT2712 i2c binding to binding file. Compare to MT8173 i2c controller, MT2712 has timing adjust registers which can adjust the internal divider of i2c source clock, SCL duty cycle, SCL compare point, start(repeated start) and stop time, SDA change time. Signed-off-by: Jun Gao

[PATCH 2/3] i2c: mediatek: Add i2c compatible for MediaTek MT2712

From: Jun Gao Add i2c compatible for MT2712. Compare to MT8173 i2c controller, internal divider of i2c source clock need to be configured for MT2712 i2c speed calculation. Signed-off-by: Jun Gao --- drivers/i2c/busses/i2c-mt65xx.c | 31

[PATCH 2/3] i2c: mediatek: Add i2c compatible for MediaTek MT2712

From: Jun Gao Add i2c compatible for MT2712. Compare to MT8173 i2c controller, internal divider of i2c source clock need to be configured for MT2712 i2c speed calculation. Signed-off-by: Jun Gao --- drivers/i2c/busses/i2c-mt65xx.c | 31 +++ 1 file changed, 27

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

On 2017年12月18日 16:50, Paolo Bonzini wrote: > On 18/12/2017 09:30, David Hildenbrand wrote: >> The ugly thing in kvm_irqfd_assign() is that we access irqfd without >> holding a lock. I think that should rather be fixed than working around >> that issue. (e.g. lock() -> lookup again -> verify still

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

On 2017年12月18日 16:50, Paolo Bonzini wrote: > On 18/12/2017 09:30, David Hildenbrand wrote: >> The ugly thing in kvm_irqfd_assign() is that we access irqfd without >> holding a lock. I think that should rather be fixed than working around >> that issue. (e.g. lock() -> lookup again -> verify still

[PATCH v2 1/5] mm: migrate NUMA stats from per-zone to per-node

There is not really any use to get NUMA stats separated by zone, and current per-zone NUMA stats is only consumed in /proc/zoneinfo. For code cleanup purpose, we move NUMA stats from per-zone to per-node and reuse the existed per-cpu infrastructure. Suggested-by: Andi Kleen

[PATCH v2 1/5] mm: migrate NUMA stats from per-zone to per-node

There is not really any use to get NUMA stats separated by zone, and current per-zone NUMA stats is only consumed in /proc/zoneinfo. For code cleanup purpose, we move NUMA stats from per-zone to per-node and reuse the existed per-cpu infrastructure. Suggested-by: Andi Kleen Suggested-by: Michal

[PATCH v2 5/5] mm: Rename zone_statistics() to numa_statistics()

Since the functionality of zone_statistics() updates numa counters, but numa statistics has been separated from zone statistics framework. Thus, the function name makes people confused. So, change the name to numa_statistics() as well as its call sites accordingly. Signed-off-by: Kemi Wang

[PATCH v2 5/5] mm: Rename zone_statistics() to numa_statistics()

Since the functionality of zone_statistics() updates numa counters, but numa statistics has been separated from zone statistics framework. Thus, the function name makes people confused. So, change the name to numa_statistics() as well as its call sites accordingly. Signed-off-by: Kemi Wang ---

[PATCH v2 4/5] mm: use node_page_state_snapshot to avoid deviation

To avoid deviation, this patch uses node_page_state_snapshot instead of node_page_state for node page stats query. e.g. cat /proc/zoneinfo cat /sys/devices/system/node/node*/vmstat cat /sys/devices/system/node/node*/numastat As it is a slow path and would not be read frequently, I would

[PATCH v2 4/5] mm: use node_page_state_snapshot to avoid deviation

To avoid deviation, this patch uses node_page_state_snapshot instead of node_page_state for node page stats query. e.g. cat /proc/zoneinfo cat /sys/devices/system/node/node*/vmstat cat /sys/devices/system/node/node*/numastat As it is a slow path and would not be read frequently, I would

[PATCH v2 2/5] mm: Extends local cpu counter vm_diff_nodestat from s8 to s16

The type s8 used for vm_diff_nodestat[] as local cpu counters has the limitation of global counters update frequency, especially for those monotone increasing type of counters like NUMA counters with more and more cpus/nodes. This patch extends the type of vm_diff_nodestat from s8 to s16 without

[PATCH v2 3/5] mm: enlarge NUMA counters threshold size

We have seen significant overhead in cache bouncing caused by NUMA counters update in multi-threaded page allocation. See 'commit 1d90ca897cb0 ("mm: update NUMA counter threshold size")' for more details. This patch updates NUMA counters to a fixed size of (MAX_S16 - 2) and deals with global

[PATCH v2 2/5] mm: Extends local cpu counter vm_diff_nodestat from s8 to s16

The type s8 used for vm_diff_nodestat[] as local cpu counters has the limitation of global counters update frequency, especially for those monotone increasing type of counters like NUMA counters with more and more cpus/nodes. This patch extends the type of vm_diff_nodestat from s8 to s16 without

[PATCH v2 3/5] mm: enlarge NUMA counters threshold size

We have seen significant overhead in cache bouncing caused by NUMA counters update in multi-threaded page allocation. See 'commit 1d90ca897cb0 ("mm: update NUMA counter threshold size")' for more details. This patch updates NUMA counters to a fixed size of (MAX_S16 - 2) and deals with global

[PATCH v2 0/5] mm: NUMA stats code cleanup and enhancement

The existed implementation of NUMA counters is per logical CPU along with zone->vm_numa_stat[] separated by zone, plus a global numa counter array vm_numa_stat[]. However, unlike the other vmstat counters, NUMA stats don't effect system's decision and are only consumed when reading from /proc and

[PATCH v2 0/5] mm: NUMA stats code cleanup and enhancement

The existed implementation of NUMA counters is per logical CPU along with zone->vm_numa_stat[] separated by zone, plus a global numa counter array vm_numa_stat[]. However, unlike the other vmstat counters, NUMA stats don't effect system's decision and are only consumed when reading from /proc and

Re: [PATCH v10 3/5] bpf: add a bpf_override_function helper

On Mon, 18 Dec 2017 16:09:30 +0100 Daniel Borkmann wrote: > On 12/18/2017 10:51 AM, Masami Hiramatsu wrote: > > On Fri, 15 Dec 2017 14:12:54 -0500 > > Josef Bacik wrote: > >> From: Josef Bacik > >> > >> Error injection is sloppy and

Re: [PATCH v10 3/5] bpf: add a bpf_override_function helper

On Mon, 18 Dec 2017 16:09:30 +0100 Daniel Borkmann wrote: > On 12/18/2017 10:51 AM, Masami Hiramatsu wrote: > > On Fri, 15 Dec 2017 14:12:54 -0500 > > Josef Bacik wrote: > >> From: Josef Bacik > >> > >> Error injection is sloppy and very ad-hoc. BPF could fill this niche > >> perfectly with

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

Hi Robin, On Mon Dec 18, 2017 at 02:48:14PM +, Robin Murphy wrote: > On 10/12/17 02:35, Linu Cherian wrote: > >Hi, > > > > > >On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > >>This adds a driver for the SMMUv3 PMU into the perf framework. > >>It includes an IORT update to

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

Hi Robin, On Mon Dec 18, 2017 at 02:48:14PM +, Robin Murphy wrote: > On 10/12/17 02:35, Linu Cherian wrote: > >Hi, > > > > > >On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote: > >>This adds a driver for the SMMUv3 PMU into the perf framework. > >>It includes an IORT update to

Re: [PATCH v2 2/3] vsprintf: print if symbol not found

On Mon, Dec 18, 2017 at 10:18:27PM -0800, Joe Perches wrote: > On Tue, 2017-12-19 at 14:28 +1100, Tobin C. Harding wrote: > > Depends on: commit 40eee173a35e ("kallsyms: don't leak address when > > symbol not found") > > > > Currently vsprintf for specifiers %p[SsB] relies on the behaviour of > >

Re: [PATCH v2 2/3] vsprintf: print if symbol not found

On Mon, Dec 18, 2017 at 10:18:27PM -0800, Joe Perches wrote: > On Tue, 2017-12-19 at 14:28 +1100, Tobin C. Harding wrote: > > Depends on: commit 40eee173a35e ("kallsyms: don't leak address when > > symbol not found") > > > > Currently vsprintf for specifiers %p[SsB] relies on the behaviour of > >

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

Hi David: Thanks for your review. On 2017年12月18日 16:30, David Hildenbrand wrote: > On 18.12.2017 00:40, Lan Tianyu wrote: >> Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free. >> Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in parallel >> for same

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

Hi David: Thanks for your review. On 2017年12月18日 16:30, David Hildenbrand wrote: > On 18.12.2017 00:40, Lan Tianyu wrote: >> Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free. >> Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in parallel >> for same

Re: [PATCH v10 1/5] add infrastructure for tagging functions as error injectable

On Fri, 15 Dec 2017 14:12:52 -0500 Josef Bacik wrote: > From: Josef Bacik > > Using BPF we can override kprob'ed functions and return arbitrary > values. Obviously this can be a bit unsafe, so make this feature opt-in > for functions. Simply tag a

Re: [PATCH v10 1/5] add infrastructure for tagging functions as error injectable

On Fri, 15 Dec 2017 14:12:52 -0500 Josef Bacik wrote: > From: Josef Bacik > > Using BPF we can override kprob'ed functions and return arbitrary > values. Obviously this can be a bit unsafe, so make this feature opt-in > for functions. Simply tag a function with KPROBE_ERROR_INJECT_SYMBOL in

[PATCH] fs: add kernel-doc entry for function argument

Building kernel docs causes SPHINX to emit warning: No description found for parameter 'rcu' Add kernel-doc description for parameter 'rcu' Signed-off-by: Tobin C. Harding --- Description taken from comments in update_ovl_inode_times() /* * Nothing to do if in

[PATCH] fs: add kernel-doc entry for function argument

Building kernel docs causes SPHINX to emit warning: No description found for parameter 'rcu' Add kernel-doc description for parameter 'rcu' Signed-off-by: Tobin C. Harding --- Description taken from comments in update_ovl_inode_times() /* * Nothing to do if in rcu or if

[PATCH v2] crypto: AF_ALG - limit mask and type

The user space interface allows specifying the type and the mask field used to allocate the cipher. As user space can precisely select the desired cipher by using either the name or the driver name, additional selection options for cipher are not considered necessary and relevant for user space.

[PATCH v2] crypto: AF_ALG - limit mask and type

The user space interface allows specifying the type and the mask field used to allocate the cipher. As user space can precisely select the desired cipher by using either the name or the driver name, additional selection options for cipher are not considered necessary and relevant for user space.

RE: [PATCH 0/3] Use mm_struct and switch_mm() instead of manually

> > Changes in V3: > > 1. When CPUMASK_OFFSTACK is enabled, switch_mm_irqs_off() sets cpumask > > by calling cpumask_set_cpu(). This panics kernel as efi_mm is not > > initialized, therefore initialize efi_mm in efi_alloc_page_tables(). > > Thanks for the v3. > > I confirmed that the issue I saw

RE: [PATCH 0/3] Use mm_struct and switch_mm() instead of manually

> > Changes in V3: > > 1. When CPUMASK_OFFSTACK is enabled, switch_mm_irqs_off() sets cpumask > > by calling cpumask_set_cpu(). This panics kernel as efi_mm is not > > initialized, therefore initialize efi_mm in efi_alloc_page_tables(). > > Thanks for the v3. > > I confirmed that the issue I saw

Re: [PATCH v2 2/3] vsprintf: print if symbol not found

On Tue, 2017-12-19 at 14:28 +1100, Tobin C. Harding wrote: > Depends on: commit 40eee173a35e ("kallsyms: don't leak address when > symbol not found") > > Currently vsprintf for specifiers %p[SsB] relies on the behaviour of > kallsyms (sprint_symbol()) and prints the actual address if a symbol is

Re: [PATCH v2 2/3] vsprintf: print if symbol not found

On Tue, 2017-12-19 at 14:28 +1100, Tobin C. Harding wrote: > Depends on: commit 40eee173a35e ("kallsyms: don't leak address when > symbol not found") > > Currently vsprintf for specifiers %p[SsB] relies on the behaviour of > kallsyms (sprint_symbol()) and prints the actual address if a symbol is

[PATCH] iio: add kernel-doc '@owner'

When building kernel documentation sphinx emits the following warning warning: No description found for parameter 'owner' Add description for struct member 'owner'. Signed-off-by: Tobin C. Harding --- I couldn't work out what DRIVER/INTERN were for so I took a guess.

[PATCH] iio: add kernel-doc '@owner'

When building kernel documentation sphinx emits the following warning warning: No description found for parameter 'owner' Add description for struct member 'owner'. Signed-off-by: Tobin C. Harding --- I couldn't work out what DRIVER/INTERN were for so I took a guess.

Re: [PATCH] USB: serial: option: adding support for YUGA CLM920-NC5

"SZ Lin (林上智)" writes: >> Johan Hovold writes: >> >> >> +static const struct option_blacklist_info yuga_clm920_nc5_blacklist = { >> >> + .reserved = BIT(0) | BIT(1) | BIT(4), }; >> > >> > Do you really need to blacklist the first interface? >> >> Good

Re: [PATCH] USB: serial: option: adding support for YUGA CLM920-NC5

"SZ Lin (林上智)" writes: >> Johan Hovold writes: >> >> >> +static const struct option_blacklist_info yuga_clm920_nc5_blacklist = { >> >> + .reserved = BIT(0) | BIT(1) | BIT(4), }; >> > >> > Do you really need to blacklist the first interface? >> >> Good question. Interface #0 does look a lot

RE: [PATCH] USB: serial: option: adding support for YUGA CLM920-NC5

> -Original Message- > From: Bjørn Mork [mailto:bj...@mork.no] > Sent: Tuesday, December 19, 2017 2:44 AM > To: SZ Lin (林上智) > Cc: Johan Hovold; Taiyi TY Wu (吳泰毅); Greg Kroah-Hartman; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] USB: serial: option:

RE: [PATCH] USB: serial: option: adding support for YUGA CLM920-NC5

> -Original Message- > From: Bjørn Mork [mailto:bj...@mork.no] > Sent: Tuesday, December 19, 2017 2:44 AM > To: SZ Lin (林上智) > Cc: Johan Hovold; Taiyi TY Wu (吳泰毅); Greg Kroah-Hartman; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] USB: serial: option:

net/wireless/certs/*.x509 binary files

This is just an FYI/acknowledgment that net/wireless/certs/*.x509 binary file(s) practically kills use of Linux kernel tarballs. Of course, someone can always enable EXPERT and CFG80211_CERTIFICATION_ONUS and disable the REGDB kconfig symbols to get around this. Oh, and then chmod +x

net/wireless/certs/*.x509 binary files

This is just an FYI/acknowledgment that net/wireless/certs/*.x509 binary file(s) practically kills use of Linux kernel tarballs. Of course, someone can always enable EXPERT and CFG80211_CERTIFICATION_ONUS and disable the REGDB kconfig symbols to get around this. Oh, and then chmod +x

Re: linux-next: Signed-off-by missing for commit in the scsi tree

在 2017/12/19 12:27, Martin K. Petersen 写道: Stephen, 9188808c7760 ("scsi: hisi_sas: fix SAS_QUEUE_FULL problem while running IO") is missing a Signed-off-by from its author. John? Hi Stephen and Martin, John is on vacation. I have checked it and please add a "Signed-off-by: Xiang Chen

Re: linux-next: Signed-off-by missing for commit in the scsi tree

在 2017/12/19 12:27, Martin K. Petersen 写道: Stephen, 9188808c7760 ("scsi: hisi_sas: fix SAS_QUEUE_FULL problem while running IO") is missing a Signed-off-by from its author. John? Hi Stephen and Martin, John is on vacation. I have checked it and please add a "Signed-off-by: Xiang Chen "

[PATCH] iio: fix SPHINX kernel-docs build warning

When building kernel documentation sphinx emits the following warnings No description found for parameter 'iio_dev' Excess function parameter 'indio_dev' description in 'iio_device_register' These warnings are caused by a macro with a different argument identifier to the one listed in the

[PATCH] iio: fix SPHINX kernel-docs build warning

When building kernel documentation sphinx emits the following warnings No description found for parameter 'iio_dev' Excess function parameter 'indio_dev' description in 'iio_device_register' These warnings are caused by a macro with a different argument identifier to the one listed in the

[PATCH V2] USBIP: return correct port ENABLE status

From: Pei Zhang USB system will clear port's ENABLE feature for some USB devices when vdev is already assigned port address. This cause getPortStatus reports to system that this device is not enabled, client OS will failed to use this usb device. The failure devices include

[PATCH V2] USBIP: return correct port ENABLE status

From: Pei Zhang USB system will clear port's ENABLE feature for some USB devices when vdev is already assigned port address. This cause getPortStatus reports to system that this device is not enabled, client OS will failed to use this usb device. The failure devices include a SAMSUNG SSD

Re: r8169 regression: UDP packets dropped intermittantly

Hi again This is a follow up to my earlier message. On Tue, Dec 19, 2017 at 09:02:25AM +1030, Jonathan Woithe wrote: > On Mon, Dec 18, 2017 at 02:38:53PM +0100, Holger Hoffstätte wrote: > > Since I've seen your postings several times now with no comment or > > resolution > > I've decided to try

Re: r8169 regression: UDP packets dropped intermittantly

Hi again This is a follow up to my earlier message. On Tue, Dec 19, 2017 at 09:02:25AM +1030, Jonathan Woithe wrote: > On Mon, Dec 18, 2017 at 02:38:53PM +0100, Holger Hoffstätte wrote: > > Since I've seen your postings several times now with no comment or > > resolution > > I've decided to try

[PATCH V4 02/26] powerpc/PCI: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Use

[PATCH V4 02/26] powerpc/PCI: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Use

[PATCH V4 06/26] edd: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Domain number is not

[PATCH V4 06/26] edd: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Domain number is not

linux-next: Tree for Dec 19

Hi all, Changes since 20171218: The xtensa tree gained a conflict against Linus' tree. The v4l-dvb tree gained a conflict against the vfs tree. The net-next tree gained a conflict against the net tree. The tty tree lost its build failure. Non-merge commits (relative to Linus' tree): 4879

linux-next: Tree for Dec 19

Hi all, Changes since 20171218: The xtensa tree gained a conflict against Linus' tree. The v4l-dvb tree gained a conflict against the vfs tree. The net-next tree gained a conflict against the net tree. The tty tree lost its build failure. Non-merge commits (relative to Linus' tree): 4879

[PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-code the domain

[PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-code the domain

[PATCH V4 15/26] PCI: cpqhp: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-coding the domain

[PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Use the domain

[PATCH V4 15/26] PCI: cpqhp: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Hard-coding the domain

[PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Use the domain

  1   2   3   4   5   6   7   8   9   10   >