Re: [PATCH] mm, meminit: Serially initialise deferred memory if trace_buf_size is specified

Hi Mel, Thank you very much for your feedback, my replies below: > A lack of involvement from admins is indeed desirable. For example, > while I might concede on using a disable-everything-switch, I would not > be happy to introduce a switch that specified how much memory per node > to

Re: [PATCH] mm, meminit: Serially initialise deferred memory if trace_buf_size is specified

Hi Mel, Thank you very much for your feedback, my replies below: > A lack of involvement from admins is indeed desirable. For example, > while I might concede on using a disable-everything-switch, I would not > be happy to introduce a switch that specified how much memory per node > to

Re: [BUILD FAILURE] nfs4state.c fails to compile with gcc 4.5.4

On Wed, 29 Nov 2017 19:27:45 -0800 Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 6:58 PM, Steven Rostedt wrote: > > > > Seems it can't handle the initialization of an anonymous struct within > > an anonymous union. > > I think we've seen

Re: [BUILD FAILURE] nfs4state.c fails to compile with gcc 4.5.4

On Wed, 29 Nov 2017 19:27:45 -0800 Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 6:58 PM, Steven Rostedt wrote: > > > > Seems it can't handle the initialization of an anonymous struct within > > an anonymous union. > > I think we've seen this before, and I think there was some trick to >

Re: [RESEND PATCH v3] tracing: Allocate mask_str buffer dynamically

On Wed, Nov 29, 2017 at 10:12:09PM -0500, Steven Rostedt wrote: > On Wed, 29 Nov 2017 12:42:45 +0800 > changbin...@intel.com wrote: > > > From: Changbin Du > > > > The default NR_CPUS can be very large, but actual possible nr_cpu_ids > > usually is very small. For my x86

Re: [RESEND PATCH v3] tracing: Allocate mask_str buffer dynamically

On Wed, Nov 29, 2017 at 10:12:09PM -0500, Steven Rostedt wrote: > On Wed, 29 Nov 2017 12:42:45 +0800 > changbin...@intel.com wrote: > > > From: Changbin Du > > > > The default NR_CPUS can be very large, but actual possible nr_cpu_ids > > usually is very small. For my x86 distribution, the

Re: [BUILD FAILURE] nfs4state.c fails to compile with gcc 4.5.4

On Wed, Nov 29, 2017 at 6:58 PM, Steven Rostedt wrote: > > Seems it can't handle the initialization of an anonymous struct within > an anonymous union. I think we've seen this before, and I think there was some trick to make it work with older gcc versions. Maybe the

Re: [BUILD FAILURE] nfs4state.c fails to compile with gcc 4.5.4

On Wed, Nov 29, 2017 at 6:58 PM, Steven Rostedt wrote: > > Seems it can't handle the initialization of an anonymous struct within > an anonymous union. I think we've seen this before, and I think there was some trick to make it work with older gcc versions. Maybe the unnamed entry that gets

Re: [Ocfs2-devel] [PATCH v2 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock

Hi Changwei, >>> > Hi Gang, > > On 2017/11/30 10:45, Gang He wrote: >> Hello Changwei, >> >> > >>> On 2017/11/29 16:38, Gang He wrote: Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which will be used in non-block IO scenarios. Signed-off-by: Gang He

Re: [Ocfs2-devel] [PATCH v2 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock

Hi Changwei, >>> > Hi Gang, > > On 2017/11/30 10:45, Gang He wrote: >> Hello Changwei, >> >> > >>> On 2017/11/29 16:38, Gang He wrote: Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which will be used in non-block IO scenarios. Signed-off-by: Gang He

Re: Missing version line in System.map file?

On 11/29/2017 06:56 PM, Lee Strobel wrote: > Hi Randy, > > Thank you for replying to my e-mail. That is interesting and it seems to > explain why my map file didn't have that version line. I hadn't realized > that it depends on the CONFIG_KALLSYMS option (which I did indeed have > enabled). I am

Re: Missing version line in System.map file?

On 11/29/2017 06:56 PM, Lee Strobel wrote: > Hi Randy, > > Thank you for replying to my e-mail. That is interesting and it seems to > explain why my map file didn't have that version line. I hadn't realized > that it depends on the CONFIG_KALLSYMS option (which I did indeed have > enabled). I am

Re: [PATCH] mmap.2: document new MAP_FIXED_SAFE flag

On 11/29/2017 06:45 AM, Michal Hocko wrote: > From: Michal Hocko > > 4.16+ kernels offer a new MAP_FIXED_SAFE flag which allows to atomicaly "allows the caller to atomically" , if you care about polishing the commit message...see the real review, below. :) > probe for a given

Re: [PATCH] mmap.2: document new MAP_FIXED_SAFE flag

On 11/29/2017 06:45 AM, Michal Hocko wrote: > From: Michal Hocko > > 4.16+ kernels offer a new MAP_FIXED_SAFE flag which allows to atomicaly "allows the caller to atomically" , if you care about polishing the commit message...see the real review, below. :) > probe for a given address range. >

Re: [RESEND PATCH v3] tracing: Allocate mask_str buffer dynamically

On Wed, 29 Nov 2017 12:42:45 +0800 changbin...@intel.com wrote: > From: Changbin Du > > The default NR_CPUS can be very large, but actual possible nr_cpu_ids > usually is very small. For my x86 distribution, the NR_CPUS is 8192 and > nr_cpu_ids is 4. About 2 pages are

Re: [RESEND PATCH v3] tracing: Allocate mask_str buffer dynamically

On Wed, 29 Nov 2017 12:42:45 +0800 changbin...@intel.com wrote: > From: Changbin Du > > The default NR_CPUS can be very large, but actual possible nr_cpu_ids > usually is very small. For my x86 distribution, the NR_CPUS is 8192 and > nr_cpu_ids is 4. About 2 pages are wasted. > > Most machines

[RFC PATCH 6/6] drm/i915: Implement HDCP for DisplayPort

This patch adds HDCP support for DisplayPort connectors by implementing the intel_hdcp_shim. Most of this is straightforward read/write from/to DPCD registers. One thing worth pointing out is the Aksv output bit. It wasn't easily separable like it's HDMI counterpart, so it's crammed in with the

[RFC PATCH 6/6] drm/i915: Implement HDCP for DisplayPort

This patch adds HDCP support for DisplayPort connectors by implementing the intel_hdcp_shim. Most of this is straightforward read/write from/to DPCD registers. One thing worth pointing out is the Aksv output bit. It wasn't easily separable like it's HDMI counterpart, so it's crammed in with the

[RFC PATCH 1/6] drm: Add Content Protection property

This patch adds a new optional connector property to allow userspace to enable protection over the content it is displaying. This will typically be implemented by the driver using HDCP. The property is a tri-state with the following values: - OFF: Self explanatory, no content protection -

[RFC PATCH 1/6] drm: Add Content Protection property

This patch adds a new optional connector property to allow userspace to enable protection over the content it is displaying. This will typically be implemented by the driver using HDCP. The property is a tri-state with the following values: - OFF: Self explanatory, no content protection -

[RFC PATCH 5/6] drm/i915: Implement HDCP for HDMI

This patch adds HDCP support for HDMI connectors by implementing the intel_hdcp_shim. Nothing too special, just a bunch of DDC reads/writes. Signed-off-by: Sean Paul --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ddi.c | 50

[RFC PATCH 4/6] drm/i915: Add function to output Aksv over GMBUS

Once the Aksv is available in the PCH, we need to get it on the wire to the receiver via DDC. The hardware doesn't allow us to read the value directly, so we need to tell GMBUS to source the Aksv internally and send it to the right offset on the receiver. The way we do this is to initiate an

[RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

This patch adds the framework required to add HDCP support to intel connectors. It implements Aksv loading from fuse, and parts 1/2/3 of the HDCP authentication scheme. Note that without shim implementations, this does not actually implement HDCP. That will come in subsequent patches.

[RFC PATCH 5/6] drm/i915: Implement HDCP for HDMI

This patch adds HDCP support for HDMI connectors by implementing the intel_hdcp_shim. Nothing too special, just a bunch of DDC reads/writes. Signed-off-by: Sean Paul --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ddi.c | 50

[RFC PATCH 4/6] drm/i915: Add function to output Aksv over GMBUS

Once the Aksv is available in the PCH, we need to get it on the wire to the receiver via DDC. The hardware doesn't allow us to read the value directly, so we need to tell GMBUS to source the Aksv internally and send it to the right offset on the receiver. The way we do this is to initiate an

[RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

This patch adds the framework required to add HDCP support to intel connectors. It implements Aksv loading from fuse, and parts 1/2/3 of the HDCP authentication scheme. Note that without shim implementations, this does not actually implement HDCP. That will come in subsequent patches.

[RFC PATCH 2/6] drm: Add some HDCP related #defines

In preparation for implementing HDCP in i915, add some HDCP related register offsets and defines. The dpcd register offsets will go in drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff will get stuffed in drm_hdcp.h, which is new. Signed-off-by: Sean Paul

[RFC PATCH 2/6] drm: Add some HDCP related #defines

In preparation for implementing HDCP in i915, add some HDCP related register offsets and defines. The dpcd register offsets will go in drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff will get stuffed in drm_hdcp.h, which is new. Signed-off-by: Sean Paul ---

Re: [PATCH v6 04/11] x86: define IA32_FEATUE_CONTROL.SGX_LC

On Wed, 2017-11-29 at 17:38 +0200, Jarkko Sakkinen wrote: > On Wed, Nov 29, 2017 at 12:21:41AM +0200, Jarkko Sakkinen wrote: > > On Tue, Nov 28, 2017 at 02:00:03PM -0800, Sean Christopherson > > wrote: > > > What about SGX_LC_ENABLE? The title in the MSR section of the > > > SDM is > > > "SGX

Re: [PATCH v6 04/11] x86: define IA32_FEATUE_CONTROL.SGX_LC

On Wed, 2017-11-29 at 17:38 +0200, Jarkko Sakkinen wrote: > On Wed, Nov 29, 2017 at 12:21:41AM +0200, Jarkko Sakkinen wrote: > > On Tue, Nov 28, 2017 at 02:00:03PM -0800, Sean Christopherson > > wrote: > > > What about SGX_LC_ENABLE? The title in the MSR section of the > > > SDM is > > > "SGX

RE: No check of the size passed to unmap_single in swiotlb

Hi Robin, > -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, November 28, 2017 10:18 PM > To: Eric Yang ; Konrad Rzeszutek Wilk > ; io...@lists.linux-foundation.org > Cc: Daniel Borkmann

RE: No check of the size passed to unmap_single in swiotlb

Hi Robin, > -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, November 28, 2017 10:18 PM > To: Eric Yang ; Konrad Rzeszutek Wilk > ; io...@lists.linux-foundation.org > Cc: Daniel Borkmann ; Kees Cook > ; Geert Uytterhoeven ; > Greg Kroah-Hartman ;

[PATCH] leds: pm8058: Make ledtype pointer sized type

The pointer returned by of_device_get_match_data() doesn't have the same size as u32 on 64-bit architectures, causing issues when compile testing the driver on such platform. Make ledtype unsigned long instead, to solve this problem. Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver") Cc: Linus

[PATCH] leds: pm8058: Make ledtype pointer sized type

The pointer returned by of_device_get_match_data() doesn't have the same size as u32 on 64-bit architectures, causing issues when compile testing the driver on such platform. Make ledtype unsigned long instead, to solve this problem. Fixes: 7f866986e705 ("leds: add PM8058 LEDs driver") Cc: Linus

Re: [Ocfs2-devel] [PATCH v2 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock

Hi Gang, On 2017/11/30 10:45, Gang He wrote: > Hello Changwei, > > >> On 2017/11/29 16:38, Gang He wrote: >>> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which >>> will be used in non-block IO scenarios. >>> >>> Signed-off-by: Gang He >>> --- >>>

Re: [Ocfs2-devel] [PATCH v2 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock

Hi Gang, On 2017/11/30 10:45, Gang He wrote: > Hello Changwei, > > >> On 2017/11/29 16:38, Gang He wrote: >>> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which >>> will be used in non-block IO scenarios. >>> >>> Signed-off-by: Gang He >>> --- >>>fs/ocfs2/dlmglue.c | 21

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

Em Wed, Nov 29, 2017 at 02:31:36PM -0800, Martin KaFai Lau escreveu: > On Wed, Nov 29, 2017 at 06:15:43PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 29, 2017 at 01:07:34PM -0800, Martin KaFai Lau escreveu: > > > On Tue, Nov 28, 2017 at 04:05:19PM -0300, Arnaldo Carvalho de Melo wrote:

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

Em Wed, Nov 29, 2017 at 02:31:36PM -0800, Martin KaFai Lau escreveu: > On Wed, Nov 29, 2017 at 06:15:43PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 29, 2017 at 01:07:34PM -0800, Martin KaFai Lau escreveu: > > > On Tue, Nov 28, 2017 at 04:05:19PM -0300, Arnaldo Carvalho de Melo wrote:

[BUILD FAILURE] nfs4state.c fails to compile with gcc 4.5.4

Just letting you know that this commit: fcd8843c406 ('NFSv4: Replace closed stateids with the "invalid special stateid"') causes gcc 4.5.4 to fail the build with this error: CC [M] fs/nfs/nfs4state.o /work/git/linux-trace.git/fs/nfs/nfs4state.c:75:4: error: field name not in record or union

[BUILD FAILURE] nfs4state.c fails to compile with gcc 4.5.4

Just letting you know that this commit: fcd8843c406 ('NFSv4: Replace closed stateids with the "invalid special stateid"') causes gcc 4.5.4 to fail the build with this error: CC [M] fs/nfs/nfs4state.o /work/git/linux-trace.git/fs/nfs/nfs4state.c:75:4: error: field name not in record or union

Re: Missing version line in System.map file?

Hi Randy, Thank you for replying to my e-mail. That is interesting and it seems to explain why my map file didn't have that version line. I hadn't realized that it depends on the CONFIG_KALLSYMS option (which I did indeed have enabled). I am somewhat new to configuring/building the kernel and,

Re: Missing version line in System.map file?

Hi Randy, Thank you for replying to my e-mail. That is interesting and it seems to explain why my map file didn't have that version line. I hadn't realized that it depends on the CONFIG_KALLSYMS option (which I did indeed have enabled). I am somewhat new to configuring/building the kernel and,

Re: [PATCH v2] rtc: Add tracepoints for RTC system

Hi Alexandre and Ingo, On 16 November 2017 at 13:59, Baolin Wang wrote: > It will be more helpful to add some tracepoints to track RTC actions when > debugging RTC driver. Below sample is that we set/read the RTC time, then > set 2 alarms, so we can see the trace logs: >

Re: [PATCH v2] rtc: Add tracepoints for RTC system

Hi Alexandre and Ingo, On 16 November 2017 at 13:59, Baolin Wang wrote: > It will be more helpful to add some tracepoints to track RTC actions when > debugging RTC driver. Below sample is that we set/read the RTC time, then > set 2 alarms, so we can see the trace logs: > > set/read RTC time: >

[PATCH] staging: xgifb: remove unused macro XGIPART3

Signed-off-by: Joshua Abraham This patch removes the unused macro XGIPART3. --- drivers/staging/xgifb/XGI_main.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/xgifb/XGI_main.h b/drivers/staging/xgifb/XGI_main.h index a3af1cbbf8ee..5f55d0a39bc1

[PATCH] staging: xgifb: remove unused macro XGIPART3

Signed-off-by: Joshua Abraham This patch removes the unused macro XGIPART3. --- drivers/staging/xgifb/XGI_main.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/xgifb/XGI_main.h b/drivers/staging/xgifb/XGI_main.h index a3af1cbbf8ee..5f55d0a39bc1 100644 ---

Re: [PATCH v4 RESEND] f2fs: fix out-of-free problem caused by atomic write

ping... On 2017/11/17 8:54, Yunlong Song wrote: f2fs_balance_fs only actives once in the commit_inmem_pages, but there are more than one page to commit, so all the other pages will miss the check. This will lead to out-of-free problem when commit a very large file. However, we cannot do

Re: [PATCH v4 RESEND] f2fs: fix out-of-free problem caused by atomic write

ping... On 2017/11/17 8:54, Yunlong Song wrote: f2fs_balance_fs only actives once in the commit_inmem_pages, but there are more than one page to commit, so all the other pages will miss the check. This will lead to out-of-free problem when commit a very large file. However, we cannot do

Re: [PATCH net,stable v2] vhost: fix skb leak in handle_rx()

On 2017年11月29日 23:31, Michael S. Tsirkin wrote: On Wed, Nov 29, 2017 at 09:23:24AM -0500,w...@redhat.com wrote: From: Wei Xu Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following

Re: [PATCH net,stable v2] vhost: fix skb leak in handle_rx()

On 2017年11月29日 23:31, Michael S. Tsirkin wrote: On Wed, Nov 29, 2017 at 09:23:24AM -0500,w...@redhat.com wrote: From: Wei Xu Matthew found a roughly 40% tcp throughput regression with commit c67df11f(vhost_net: try batch dequing from skb array) as discussed in the following thread:

Re: [btrfs_mount] general protection fault: 0000 [#1] SMP

On Wed, Nov 29, 2017 at 6:38 PM, Nick Terrell wrote: > > The stack trace looks like the bug fixed by > > Qu Wenruo: > btrfs: Fix wild memory access in compression level parser [1] > > That fix looks to be included in the pull request for 4.15-rc2 [2]. Which got merged

Re: [btrfs_mount] general protection fault: 0000 [#1] SMP

On Wed, Nov 29, 2017 at 6:38 PM, Nick Terrell wrote: > > The stack trace looks like the bug fixed by > > Qu Wenruo: > btrfs: Fix wild memory access in compression level parser [1] > > That fix looks to be included in the pull request for 4.15-rc2 [2]. Which got merged earlier today. So maybe

Re: [Ocfs2-devel] [PATCH v2 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock

Hello Changwei, >>> > On 2017/11/29 16:38, Gang He wrote: >> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which >> will be used in non-block IO scenarios. >> >> Signed-off-by: Gang He >> --- >> fs/ocfs2/dlmglue.c | 21 + >> fs/ocfs2/dlmglue.h

Re: [Ocfs2-devel] [PATCH v2 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock

Hello Changwei, >>> > On 2017/11/29 16:38, Gang He wrote: >> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which >> will be used in non-block IO scenarios. >> >> Signed-off-by: Gang He >> --- >> fs/ocfs2/dlmglue.c | 21 + >> fs/ocfs2/dlmglue.h | 4 >>

Re: [PATCH] f2fs: avoid false positive of free secs check

SSR can make hot/warm/cold nodes written together, so why should we account them different? On 2017/11/29 19:56, Chao Yu wrote: On 2017/11/27 14:54, Yunlong Song wrote: Sometimes f2fs_gc is called with no target victim (e.g. xfstest generic/027, ndirty_node:545 ndiry_dent:1 ndirty_imeta:513

Re: [PATCH] f2fs: avoid false positive of free secs check

SSR can make hot/warm/cold nodes written together, so why should we account them different? On 2017/11/29 19:56, Chao Yu wrote: On 2017/11/27 14:54, Yunlong Song wrote: Sometimes f2fs_gc is called with no target victim (e.g. xfstest generic/027, ndirty_node:545 ndiry_dent:1 ndirty_imeta:513

Re: [btrfs_mount] general protection fault: 0000 [#1] SMP

> On Nov 29, 2017, at 6:21 PM, Fengguang Wu wrote: > > Hello, > > FYI this happens in mainline kernel 4.15.0-rc1. > It looks like a new regression. Bisect is in progress. > > It occurs in 11 out of 11 xfstests run. > > [ 1456.361614] > [ 1456.918942] BTRFS info

Re: [btrfs_mount] general protection fault: 0000 [#1] SMP

> On Nov 29, 2017, at 6:21 PM, Fengguang Wu wrote: > > Hello, > > FYI this happens in mainline kernel 4.15.0-rc1. > It looks like a new regression. Bisect is in progress. > > It occurs in 11 out of 11 xfstests run. > > [ 1456.361614] > [ 1456.918942] BTRFS info (device vdb): disk space

[PATCH v4] mfd: syscon: Add hardware spinlock support

Some system control registers need hardware spinlock to synchronize between the multiple subsystems, so we should add hardware spinlock support for syscon. Signed-off-by: Baolin Wang Acked-by: Rob Herring --- Changes since v3: - Add error handling for

[PATCH v4] mfd: syscon: Add hardware spinlock support

Some system control registers need hardware spinlock to synchronize between the multiple subsystems, so we should add hardware spinlock support for syscon. Signed-off-by: Baolin Wang Acked-by: Rob Herring --- Changes since v3: - Add error handling for of_hwspin_lock_get_id() Changes since v2:

Re: add_wait_queue() (unintentional?) behavior change in v4.13

On Wed, Nov 29, 2017 at 4:58 PM, Omar Sandoval wrote: > > Note the change from __add_wait_queue() to > __add_wait_queue_entry_tail(). I'm assuming this was a typo since the > commit message doesn't mention any functional changes. This patch > restores the old behavior: >

Re: add_wait_queue() (unintentional?) behavior change in v4.13

On Wed, Nov 29, 2017 at 4:58 PM, Omar Sandoval wrote: > > Note the change from __add_wait_queue() to > __add_wait_queue_entry_tail(). I'm assuming this was a typo since the > commit message doesn't mention any functional changes. This patch > restores the old behavior: > [...] > I didn't go

Re: [PATCH 11/12] perf, tools: Print probe warnings for binaries only once per binary

On Mon, 27 Nov 2017 16:23:20 -0800 Andi Kleen wrote: > From: Andi Kleen > > When the perf probe code is called from perf script we may end up > with a flood of bad binary errors with -v. Only print the error message > once in this case. Indeed, but

Re: [PATCH 11/12] perf, tools: Print probe warnings for binaries only once per binary

On Mon, 27 Nov 2017 16:23:20 -0800 Andi Kleen wrote: > From: Andi Kleen > > When the perf probe code is called from perf script we may end up > with a flood of bad binary errors with -v. Only print the error message > once in this case. Indeed, but this looks like a hack. You may need to

[PATCH 1/3] module: use goto errors on check_modinfo() and layout_and_allocate()

Although both routines don't have much complex errors paths we will expand on these routine in the future, setting up error lables now for both will make subsequent changes easier to review. This changes has no functional changes. Signed-off-by: Luis R. Rodriguez ---

Re: [PATCH 06/12] perf, tools, probe: Support a quiet argument for debug info open

On Tue, 28 Nov 2017 19:39:43 -0800 Andi Kleen wrote: > On Wed, Nov 29, 2017 at 12:14:00PM +0900, Masami Hiramatsu wrote: > > On Mon, 27 Nov 2017 16:23:15 -0800 > > Andi Kleen wrote: > > > > > From: Andi Kleen > > > > > > Add a

[PATCH 1/3] module: use goto errors on check_modinfo() and layout_and_allocate()

Although both routines don't have much complex errors paths we will expand on these routine in the future, setting up error lables now for both will make subsequent changes easier to review. This changes has no functional changes. Signed-off-by: Luis R. Rodriguez --- kernel/module.c | 10

Re: [PATCH 06/12] perf, tools, probe: Support a quiet argument for debug info open

On Tue, 28 Nov 2017 19:39:43 -0800 Andi Kleen wrote: > On Wed, Nov 29, 2017 at 12:14:00PM +0900, Masami Hiramatsu wrote: > > On Mon, 27 Nov 2017 16:23:15 -0800 > > Andi Kleen wrote: > > > > > From: Andi Kleen > > > > > > Add a extra quiet argument to the debug info open / probe finder > > >

[PATCH 0/3] module: process aliasing when debugging

Debugging ineractions with userspace can often be a bit of pain, specially when trying to figure out who is at fault for an issue. Having the kernel process aliases when debugging can help us much faster find who is the culprit to an issue. I've been carrying this around privately in my tree

[PATCH 3/3] module: add debugging alias parsing support

Debugging modules can often lead to an alias question. We purposely don't have alias parsing support upstream as this is all dealt with in userpace with the assumption that in-kernel we just process aliases and userspace Does The Right Thing (TM) about aliases. Obviously userspace can be buggy

[PATCH 0/3] module: process aliasing when debugging

Debugging ineractions with userspace can often be a bit of pain, specially when trying to figure out who is at fault for an issue. Having the kernel process aliases when debugging can help us much faster find who is the culprit to an issue. I've been carrying this around privately in my tree

[PATCH 3/3] module: add debugging alias parsing support

Debugging modules can often lead to an alias question. We purposely don't have alias parsing support upstream as this is all dealt with in userpace with the assumption that in-kernel we just process aliases and userspace Does The Right Thing (TM) about aliases. Obviously userspace can be buggy

[PATCH 2/3] module: add helper get_modinfo_idx()

get_modinfo() lets you look for at the modinfo section for a value using a specific tag, this however is limited to only give you the first tag found. In practice you can have multiple entries using the same tag, one example are aliases We have not had a need to support hunting for beyond the

[PATCH 2/3] module: add helper get_modinfo_idx()

get_modinfo() lets you look for at the modinfo section for a value using a specific tag, this however is limited to only give you the first tag found. In practice you can have multiple entries using the same tag, one example are aliases We have not had a need to support hunting for beyond the

[PATCH] clk: rockchip: protect cpu and ddr clks

These clks can never be turned off, so protect them as what we do in the sunxi clock-tree. Signed-off-by: Jeffy Chen --- drivers/clk/rockchip/clk-cpu.c | 5 + drivers/clk/rockchip/clk-ddr.c | 5 + 2 files changed, 10 insertions(+) diff --git

[PATCH] clk: rockchip: protect cpu and ddr clks

These clks can never be turned off, so protect them as what we do in the sunxi clock-tree. Signed-off-by: Jeffy Chen --- drivers/clk/rockchip/clk-cpu.c | 5 + drivers/clk/rockchip/clk-ddr.c | 5 + 2 files changed, 10 insertions(+) diff --git a/drivers/clk/rockchip/clk-cpu.c

Re: [RFC 0/3] Safe, dynamically (un)loadable LSMs

On 11/26/2017 2:15 PM, Sargun Dhillon wrote: > This patchset introduces safe dynamic LSM support. It does this via > SRCU-protected security hooks. It also EXPORT_SYMBOL_GPLs the symbols > required to perform runtime loading, and unloading. The patchset is > meant to introduce as little overhead

Re: [RFC 0/3] Safe, dynamically (un)loadable LSMs

On 11/26/2017 2:15 PM, Sargun Dhillon wrote: > This patchset introduces safe dynamic LSM support. It does this via > SRCU-protected security hooks. It also EXPORT_SYMBOL_GPLs the symbols > required to perform runtime loading, and unloading. The patchset is > meant to introduce as little overhead

Re: [PATCH 0/4] Move DP phy switch to PHY driver

Hi Doug Thank you for mentioning this patch. I think the focus of the discussion is: can we put the grf control bit to dts. The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel" can help to switch these 2 phy. So I think this bit can be considered as a part of

Re: [PATCH 0/4] Move DP phy switch to PHY driver

Hi Doug Thank you for mentioning this patch. I think the focus of the discussion is: can we put the grf control bit to dts. The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel" can help to switch these 2 phy. So I think this bit can be considered as a part of

[ 0.003333] BUG: KASAN: use-after-scope in console_unlock+0x605/0xcc0

Hello, FYI this happens in mainline kernel v4.15-rc1 . It shows up after v4.14 . Bisect is on the way. It occurs in 4 out of 4 boots. [0.00] RCU callback double-/use-after-free debug enabled. [0.00] RCU CPU stall warnings timeout set to 100 (rcu_cpu_stall_timeout). [

[ 0.003333] BUG: KASAN: use-after-scope in console_unlock+0x605/0xcc0

Hello, FYI this happens in mainline kernel v4.15-rc1 . It shows up after v4.14 . Bisect is on the way. It occurs in 4 out of 4 boots. [0.00] RCU callback double-/use-after-free debug enabled. [0.00] RCU CPU stall warnings timeout set to 100 (rcu_cpu_stall_timeout). [

Re: KASAN: use-after-free Read in sock_release

On Wed, Nov 29, 2017 at 11:37:04AM -0800, Cong Wang wrote: > > Allocated by task 31066: > > save_stack+0x43/0xd0 mm/kasan/kasan.c:447 > > set_track mm/kasan/kasan.c:459 [inline] > > kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 > > kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3613 > > kmalloc

Re: KASAN: use-after-free Read in sock_release

On Wed, Nov 29, 2017 at 11:37:04AM -0800, Cong Wang wrote: > > Allocated by task 31066: > > save_stack+0x43/0xd0 mm/kasan/kasan.c:447 > > set_track mm/kasan/kasan.c:459 [inline] > > kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 > > kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3613 > > kmalloc

[PATCH] usbip: Fix USB device hang due to wrong enabling of scatter-gather

The previous USB3 SuperSpeed enabling patches mistakenly enabled URB scatter-gather chaining, which is actually not supported by the VHCI HCD. This patch fixes that. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197867 Fixes: 03cd00d538a6feb ("usbip: vhci-hcd: Set the vhci structure up to

[PATCH] usbip: Fix USB device hang due to wrong enabling of scatter-gather

The previous USB3 SuperSpeed enabling patches mistakenly enabled URB scatter-gather chaining, which is actually not supported by the VHCI HCD. This patch fixes that. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197867 Fixes: 03cd00d538a6feb ("usbip: vhci-hcd: Set the vhci structure up to

Re: [PATCH v2] tpm: return a TPM_RC_COMMAND_CODE response if a command isn't implemented

On 11/29/2017 10:24 AM, Javier Martinez Canillas wrote: > Hello Jarkko, > > On 11/29/2017 06:57 PM, Jarkko Sakkinen wrote: >> On Wed, Nov 29, 2017 at 12:08:46PM +0100, Javier Martinez Canillas >> wrote: >>> +#define TPM2_RC_LAYER_SHIFT16 +#define TPM2_RESMGRTPM_RC_LAYER >>> (11 <<

Re: [PATCH v2] tpm: return a TPM_RC_COMMAND_CODE response if a command isn't implemented

On 11/29/2017 10:24 AM, Javier Martinez Canillas wrote: > Hello Jarkko, > > On 11/29/2017 06:57 PM, Jarkko Sakkinen wrote: >> On Wed, Nov 29, 2017 at 12:08:46PM +0100, Javier Martinez Canillas >> wrote: >>> +#define TPM2_RC_LAYER_SHIFT16 +#define TPM2_RESMGRTPM_RC_LAYER >>> (11 <<

Re: [PATCH 3/7] kbuild: fix LD_DEAD_CODE_DATA_ELIMINATION with GNU gold

On Wed, 29 Nov 2017 15:44:38 -0800 Sami Tolvanen wrote: > Don't remove .head.text or .exitcall.exit when linking with --gc-sections, > and include .init.text.* in .init.text and .init.rodata.* in .init.rodata. > > Signed-off-by: Sami Tolvanen

Re: [PATCH 3/7] kbuild: fix LD_DEAD_CODE_DATA_ELIMINATION with GNU gold

On Wed, 29 Nov 2017 15:44:38 -0800 Sami Tolvanen wrote: > Don't remove .head.text or .exitcall.exit when linking with --gc-sections, > and include .init.text.* in .init.text and .init.rodata.* in .init.rodata. > > Signed-off-by: Sami Tolvanen Fine by me, if you consider my other comments.

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

On Wed, Nov 29, 2017 at 4:44 PM, Kees Cook wrote: > >> That mainly leaves the protocol ones we need to look out for, I suspect. > > This is where a lot of the exposure really comes from. socket() > triggers a bunch of stuff, but doesn't have an obvious privilege >

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

On Wed, Nov 29, 2017 at 4:44 PM, Kees Cook wrote: > >> That mainly leaves the protocol ones we need to look out for, I suspect. > > This is where a lot of the exposure really comes from. socket() > triggers a bunch of stuff, but doesn't have an obvious privilege > associated with it... while it

Re: KASAN: use-after-free Read in sock_release

On Wed, Nov 29, 2017 at 12:24:55PM -0800, Linus Torvalds wrote: > Ugh. The inode freeing really is confusing and fairly involved, but > the last free *should* happen as part of the final dput() that is done > at the end of __fput(). Note that struct socket is coallocated with its inode.

Re: KASAN: use-after-free Read in sock_release

On Wed, Nov 29, 2017 at 12:24:55PM -0800, Linus Torvalds wrote: > Ugh. The inode freeing really is confusing and fairly involved, but > the last free *should* happen as part of the final dput() that is done > at the end of __fput(). Note that struct socket is coallocated with its inode.

Re: [PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check

On Mon, Nov 27, 2017 at 06:18:35PM +0100, Djalal Harouni wrote: > +/* Determine whether a module auto-load operation is permitted. */ > +int may_autoload_module(char *kmod_name, int required_cap, > + const char *kmod_prefix); > + While we are reviewing a general LSM for this,

Re: [PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check

On Mon, Nov 27, 2017 at 06:18:35PM +0100, Djalal Harouni wrote: > +/* Determine whether a module auto-load operation is permitted. */ > +int may_autoload_module(char *kmod_name, int required_cap, > + const char *kmod_prefix); > + While we are reviewing a general LSM for this,

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

Hi Arnd, On 29 November 2017 at 18:07, Arnd Bergmann wrote: > On Mon, Nov 20, 2017 at 7:54 AM, Baolin Wang wrote: >> Some system control registers need hardware spinlock to synchronize >> between the multiple subsystems, so we should add hardware spinlock

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

Hi Arnd, On 29 November 2017 at 18:07, Arnd Bergmann wrote: > On Mon, Nov 20, 2017 at 7:54 AM, Baolin Wang wrote: >> Some system control registers need hardware spinlock to synchronize >> between the multiple subsystems, so we should add hardware spinlock >> support for syscon. >> > >> @@ -87,6

Re: [PATCH resend] trace/xdp: fix compile warning: 'struct bpf_map' declared inside parameter list

On 11/30/2017 02:41 AM, Xie XiuQi wrote: > We meet this compile warning, which caused by missing bpf.h in xdp.h. > > In file included from ./include/trace/events/xdp.h:10:0, > from ./include/linux/bpf_trace.h:6, > from

Re: [PATCH resend] trace/xdp: fix compile warning: 'struct bpf_map' declared inside parameter list

On 11/30/2017 02:41 AM, Xie XiuQi wrote: > We meet this compile warning, which caused by missing bpf.h in xdp.h. > > In file included from ./include/trace/events/xdp.h:10:0, > from ./include/linux/bpf_trace.h:6, > from

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