HELLO.
Assalamu alaikum, I have a business Proposal for you and I need mutual respect, trust, honesty, transparency, adequate support and assistance, Hope to hear from you for more details. Warmest regards Mrs Aisha Gaddafi السلام عليكم، لدي اقتراح عمل لك وأنا بحاجة إلى الاحترام المتبادل والثقة والأمانة والشفافية والدعم الكافي والمساعدة ، ونأمل أن نسمع منك لمزيد من التفاصيل. أحر التحيات السيدة عائشة القذافي
HELLO.
Assalamu alaikum, I have a business Proposal for you and I need mutual respect, trust, honesty, transparency, adequate support and assistance, Hope to hear from you for more details. Warmest regards Mrs Aisha Gaddafi السلام عليكم، لدي اقتراح عمل لك وأنا بحاجة إلى الاحترام المتبادل والثقة والأمانة والشفافية والدعم الكافي والمساعدة ، ونأمل أن نسمع منك لمزيد من التفاصيل. أحر التحيات السيدة عائشة القذافي
Re: Re: [PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
On Sun, Nov 25, 2018 at 05:10:59AM +0300, Dmitry V. Levin wrote: > Given that without this patch the value returned by PTRACE_GETEVENTMSG > during syscall stop is undefined, we need two different ptrace_message > values that cannot be set by other ptrace events to enable reliable > identification of syscall-enter-stop and syscall-exit-stop in userspace: > if we make PTRACE_GETEVENTMSG return 0 or any other value routinely set by > other ptrace events, it would be hard for userspace to find out whether > the kernel implements new semantics or not. Ah, I see, I agree that definitely makes sense. -- Cheers, Joey Pabalinas signature.asc Description: PGP signature
NFSd: NULL-dereference when writing to v4_end_grace when server is not yet started
Hello, When manually exploring the kernel NFSd feature, I have stumbled upon a NULL-dereference when writing to v4_end_grace when server is not yet started. How to reproduce with kvm-xfstests: 1) Checkout fresh master Linux branch (tested with commit e195ca6cb) 2) Copy x84_64-config-4.14 to .config, then enable NFS server v4 and build 3) From `kvm-xfstests shell`: root@kvm-xfstests:~# mount none /proc/fs/nfsd -t nfsd root@kvm-xfstests:~# echo Y > /proc/fs/nfsd/v4_end_grace [ 11.986359] BUG: unable to handle kernel NULL pointer dereference at [ 11.987187] PGD 80007af97067 P4D 80007af97067 PUD 78e9d067 PMD 0 [ 11.987774] Oops: [#1] SMP PTI [ 11.988087] CPU: 0 PID: 281 Comm: bash Not tainted 4.20.0-rc3-xfstests-00306-ge195ca6cb6f #1 [ 11.988808] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 11.989575] RIP: 0010:__list_del_entry_valid+0x25/0x90 [ 11.990019] Code: c3 0f 1f 40 00 48 b9 00 01 00 00 00 00 ad de 48 8b 07 48 8b 57 08 48 39 c8 74 26 48 b9 00 02 00 00 00 00 ad de 48 39 ca 74 2e <48> 8b 32 48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00 [ 11.991610] RSP: 0018:a7d8c088fde8 EFLAGS: 00010207 [ 11.992066] RAX: RBX: 9ac7bc10ec28 RCX: dead0200 [ 11.992678] RDX: RSI: RDI: 9ac7bc10ec28 [ 11.993291] RBP: a7d8c088fe20 R08: R09: 0001 [ 11.993902] R10: 0001 R11: R12: 0002 [ 11.994583] R13: 9ac7bd8a9e00 R14: 9ac7ba56d008 R15: [ 11.995226] FS: () GS:9ac7bfc0(0063) knlGS:f7d76700 [ 11.996018] CS: 0010 DS: 002b ES: 002b CR0: 80050033 [ 11.996514] CR2: CR3: 78c94005 CR4: 00360ef0 [ 11.997126] Call Trace: [ 11.997346] locks_end_grace+0x1d/0x50 [ 11.997675] write_v4_end_grace+0xe7/0x1b0 [ 11.998033] ? nfsctl_transaction_write+0x80/0x80 [ 11.998440] nfsctl_transaction_write+0x45/0x80 [ 11.998835] __vfs_write+0x36/0x1a0 [ 11.999141] ? rcu_read_lock_sched_held+0x6c/0x80 [ 11.999550] ? rcu_sync_lockdep_assert+0x2e/0x60 [ 11.55] ? __sb_start_write+0x147/0x1b0 [ 12.000320] ? vfs_write+0x161/0x1a0 [ 12.000634] vfs_write+0xba/0x1a0 [ 12.000927] ksys_write+0x52/0xc0 [ 12.001220] do_fast_syscall_32+0x97/0x2d0 [ 12.001578] entry_SYSENTER_compat+0x81/0x93 [ 12.001951] CR2: [ 12.002243] ---[ end trace 4137b5fb8d67f6b5 ]--- [ 12.002645] RIP: 0010:__list_del_entry_valid+0x25/0x90 [ 12.003089] Code: c3 0f 1f 40 00 48 b9 00 01 00 00 00 00 ad de 48 8b 07 48 8b 57 08 48 39 c8 74 26 48 b9 00 02 00 00 00 00 ad de 48 39 ca 74 2e <48> 8b 32 48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00 [ 12.004682] RSP: 0018:a7d8c088fde8 EFLAGS: 00010207 [ 12.005133] RAX: RBX: 9ac7bc10ec28 RCX: dead0200 [ 12.005746] RDX: RSI: RDI: 9ac7bc10ec28 [ 12.006360] RBP: a7d8c088fe20 R08: R09: 0001 [ 12.006974] R10: 0001 R11: R12: 0002 [ 12.007587] R13: 9ac7bd8a9e00 R14: 9ac7ba56d008 R15: [ 12.008206] FS: () GS:9ac7bfc0(0063) knlGS:f7d76700 [ 12.008898] CS: 0010 DS: 002b ES: 002b CR0: 80050033 [ 12.009394] CR2: CR3: 78c94005 CR4: 00360ef0 [ 12.010004] BUG: sleeping function called from invalid context at include/linux/percpu-rwsem.h:34 [ 12.010765] in_atomic(): 1, irqs_disabled(): 1, pid: 281, name: bash [ 12.011311] INFO: lockdep is turned off. [ 12.011652] irq event stamp: 19366 [ 12.012025] hardirqs last enabled at (19365): [] get_page_from_freelist+0x2c6/0x1660 [ 12.012862] hardirqs last disabled at (19366): [] trace_hardirqs_off_thunk+0x1a/0x1c [ 12.013658] softirqs last enabled at (18228): [] __do_softirq+0x32f/0x440 [ 12.014413] softirqs last disabled at (18221): [] irq_exit+0xa6/0xe0 [ 12.015091] CPU: 0 PID: 281 Comm: bash Tainted: G D 4.20.0-rc3-xfstests-00306-ge195ca6cb6f #1 [ 12.015934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 12.016751] Call Trace: [ 12.017056] dump_stack+0x67/0x90 [ 12.017348] ___might_sleep.cold.14+0x9f/0xaf [ 12.017728] exit_signals+0x1c/0x200 [ 12.018041] do_exit+0xac/0xb00 [ 12.018319] ? ksys_write+0x52/0xc0 [ 12.018626] rewind_stack_do_exit+0x17/0x20 [ 12.019006] note: bash[281] exited with preempt_count 1 Best regards Anatoly
Re: Re: [PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
On Sun, Nov 25, 2018 at 05:10:59AM +0300, Dmitry V. Levin wrote: > Given that without this patch the value returned by PTRACE_GETEVENTMSG > during syscall stop is undefined, we need two different ptrace_message > values that cannot be set by other ptrace events to enable reliable > identification of syscall-enter-stop and syscall-exit-stop in userspace: > if we make PTRACE_GETEVENTMSG return 0 or any other value routinely set by > other ptrace events, it would be hard for userspace to find out whether > the kernel implements new semantics or not. Ah, I see, I agree that definitely makes sense. -- Cheers, Joey Pabalinas signature.asc Description: PGP signature
NFSd: NULL-dereference when writing to v4_end_grace when server is not yet started
Hello, When manually exploring the kernel NFSd feature, I have stumbled upon a NULL-dereference when writing to v4_end_grace when server is not yet started. How to reproduce with kvm-xfstests: 1) Checkout fresh master Linux branch (tested with commit e195ca6cb) 2) Copy x84_64-config-4.14 to .config, then enable NFS server v4 and build 3) From `kvm-xfstests shell`: root@kvm-xfstests:~# mount none /proc/fs/nfsd -t nfsd root@kvm-xfstests:~# echo Y > /proc/fs/nfsd/v4_end_grace [ 11.986359] BUG: unable to handle kernel NULL pointer dereference at [ 11.987187] PGD 80007af97067 P4D 80007af97067 PUD 78e9d067 PMD 0 [ 11.987774] Oops: [#1] SMP PTI [ 11.988087] CPU: 0 PID: 281 Comm: bash Not tainted 4.20.0-rc3-xfstests-00306-ge195ca6cb6f #1 [ 11.988808] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 11.989575] RIP: 0010:__list_del_entry_valid+0x25/0x90 [ 11.990019] Code: c3 0f 1f 40 00 48 b9 00 01 00 00 00 00 ad de 48 8b 07 48 8b 57 08 48 39 c8 74 26 48 b9 00 02 00 00 00 00 ad de 48 39 ca 74 2e <48> 8b 32 48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00 [ 11.991610] RSP: 0018:a7d8c088fde8 EFLAGS: 00010207 [ 11.992066] RAX: RBX: 9ac7bc10ec28 RCX: dead0200 [ 11.992678] RDX: RSI: RDI: 9ac7bc10ec28 [ 11.993291] RBP: a7d8c088fe20 R08: R09: 0001 [ 11.993902] R10: 0001 R11: R12: 0002 [ 11.994583] R13: 9ac7bd8a9e00 R14: 9ac7ba56d008 R15: [ 11.995226] FS: () GS:9ac7bfc0(0063) knlGS:f7d76700 [ 11.996018] CS: 0010 DS: 002b ES: 002b CR0: 80050033 [ 11.996514] CR2: CR3: 78c94005 CR4: 00360ef0 [ 11.997126] Call Trace: [ 11.997346] locks_end_grace+0x1d/0x50 [ 11.997675] write_v4_end_grace+0xe7/0x1b0 [ 11.998033] ? nfsctl_transaction_write+0x80/0x80 [ 11.998440] nfsctl_transaction_write+0x45/0x80 [ 11.998835] __vfs_write+0x36/0x1a0 [ 11.999141] ? rcu_read_lock_sched_held+0x6c/0x80 [ 11.999550] ? rcu_sync_lockdep_assert+0x2e/0x60 [ 11.55] ? __sb_start_write+0x147/0x1b0 [ 12.000320] ? vfs_write+0x161/0x1a0 [ 12.000634] vfs_write+0xba/0x1a0 [ 12.000927] ksys_write+0x52/0xc0 [ 12.001220] do_fast_syscall_32+0x97/0x2d0 [ 12.001578] entry_SYSENTER_compat+0x81/0x93 [ 12.001951] CR2: [ 12.002243] ---[ end trace 4137b5fb8d67f6b5 ]--- [ 12.002645] RIP: 0010:__list_del_entry_valid+0x25/0x90 [ 12.003089] Code: c3 0f 1f 40 00 48 b9 00 01 00 00 00 00 ad de 48 8b 07 48 8b 57 08 48 39 c8 74 26 48 b9 00 02 00 00 00 00 ad de 48 39 ca 74 2e <48> 8b 32 48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00 [ 12.004682] RSP: 0018:a7d8c088fde8 EFLAGS: 00010207 [ 12.005133] RAX: RBX: 9ac7bc10ec28 RCX: dead0200 [ 12.005746] RDX: RSI: RDI: 9ac7bc10ec28 [ 12.006360] RBP: a7d8c088fe20 R08: R09: 0001 [ 12.006974] R10: 0001 R11: R12: 0002 [ 12.007587] R13: 9ac7bd8a9e00 R14: 9ac7ba56d008 R15: [ 12.008206] FS: () GS:9ac7bfc0(0063) knlGS:f7d76700 [ 12.008898] CS: 0010 DS: 002b ES: 002b CR0: 80050033 [ 12.009394] CR2: CR3: 78c94005 CR4: 00360ef0 [ 12.010004] BUG: sleeping function called from invalid context at include/linux/percpu-rwsem.h:34 [ 12.010765] in_atomic(): 1, irqs_disabled(): 1, pid: 281, name: bash [ 12.011311] INFO: lockdep is turned off. [ 12.011652] irq event stamp: 19366 [ 12.012025] hardirqs last enabled at (19365): [] get_page_from_freelist+0x2c6/0x1660 [ 12.012862] hardirqs last disabled at (19366): [] trace_hardirqs_off_thunk+0x1a/0x1c [ 12.013658] softirqs last enabled at (18228): [] __do_softirq+0x32f/0x440 [ 12.014413] softirqs last disabled at (18221): [] irq_exit+0xa6/0xe0 [ 12.015091] CPU: 0 PID: 281 Comm: bash Tainted: G D 4.20.0-rc3-xfstests-00306-ge195ca6cb6f #1 [ 12.015934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 12.016751] Call Trace: [ 12.017056] dump_stack+0x67/0x90 [ 12.017348] ___might_sleep.cold.14+0x9f/0xaf [ 12.017728] exit_signals+0x1c/0x200 [ 12.018041] do_exit+0xac/0xb00 [ 12.018319] ? ksys_write+0x52/0xc0 [ 12.018626] rewind_stack_do_exit+0x17/0x20 [ 12.019006] note: bash[281] exited with preempt_count 1 Best regards Anatoly
[PATCH v2] clocksource/drivers/integrator-ap: add missing of_node_put()
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
integrator_ap_timer_init_of() doesn't do that.The pri_node and the
sec_node are used as an identifier to compare against the current node,
we can directly drop the refcount after getting the node from path as
it is not used aspointer. In addition, a single variable is needed,
so fix it.
Signed-off-by: Yangtao Li
---
Changes in v2:
-update changeelog
-simplify fix
-change two variable to one
---
drivers/clocksource/timer-integrator-ap.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/clocksource/timer-integrator-ap.c
b/drivers/clocksource/timer-integrator-ap.c
index 76e526f58620..bbd0977d579a 100644
--- a/drivers/clocksource/timer-integrator-ap.c
+++ b/drivers/clocksource/timer-integrator-ap.c
@@ -181,8 +181,7 @@ static int __init integrator_ap_timer_init_of(struct
device_node *node)
int irq;
struct clk *clk;
unsigned long rate;
- struct device_node *pri_node;
- struct device_node *sec_node;
+ struct device_node *alias_node;
base = of_io_request_and_map(node, 0, "integrator-timer");
if (IS_ERR(base))
@@ -204,7 +203,14 @@ static int __init integrator_ap_timer_init_of(struct
device_node *node)
return err;
}
- pri_node = of_find_node_by_path(path);
+ alias_node = of_find_node_by_path(path);
+
+ /* Drop the refcount of node */
+ of_node_put(alias_node);
+
+ if (node == alias_node)
+ /* The primary timer lacks IRQ, use as clocksource */
+ return integrator_clocksource_init(rate, base);
err = of_property_read_string(of_aliases,
"arm,timer-secondary", );
@@ -213,14 +219,12 @@ static int __init integrator_ap_timer_init_of(struct
device_node *node)
return err;
}
+ alias_node = of_find_node_by_path(path);
- sec_node = of_find_node_by_path(path);
-
- if (node == pri_node)
- /* The primary timer lacks IRQ, use as clocksource */
- return integrator_clocksource_init(rate, base);
+ /* Drop the refcount of node */
+ of_node_put(alias_node);
- if (node == sec_node) {
+ if (node == alias_node) {
/* The secondary timer will drive the clock event */
irq = irq_of_parse_and_map(node, 0);
return integrator_clockevent_init(rate, base, irq);
--
2.17.0
[PATCH v2] clocksource/drivers/integrator-ap: add missing of_node_put()
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
integrator_ap_timer_init_of() doesn't do that.The pri_node and the
sec_node are used as an identifier to compare against the current node,
we can directly drop the refcount after getting the node from path as
it is not used aspointer. In addition, a single variable is needed,
so fix it.
Signed-off-by: Yangtao Li
---
Changes in v2:
-update changeelog
-simplify fix
-change two variable to one
---
drivers/clocksource/timer-integrator-ap.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/clocksource/timer-integrator-ap.c
b/drivers/clocksource/timer-integrator-ap.c
index 76e526f58620..bbd0977d579a 100644
--- a/drivers/clocksource/timer-integrator-ap.c
+++ b/drivers/clocksource/timer-integrator-ap.c
@@ -181,8 +181,7 @@ static int __init integrator_ap_timer_init_of(struct
device_node *node)
int irq;
struct clk *clk;
unsigned long rate;
- struct device_node *pri_node;
- struct device_node *sec_node;
+ struct device_node *alias_node;
base = of_io_request_and_map(node, 0, "integrator-timer");
if (IS_ERR(base))
@@ -204,7 +203,14 @@ static int __init integrator_ap_timer_init_of(struct
device_node *node)
return err;
}
- pri_node = of_find_node_by_path(path);
+ alias_node = of_find_node_by_path(path);
+
+ /* Drop the refcount of node */
+ of_node_put(alias_node);
+
+ if (node == alias_node)
+ /* The primary timer lacks IRQ, use as clocksource */
+ return integrator_clocksource_init(rate, base);
err = of_property_read_string(of_aliases,
"arm,timer-secondary", );
@@ -213,14 +219,12 @@ static int __init integrator_ap_timer_init_of(struct
device_node *node)
return err;
}
+ alias_node = of_find_node_by_path(path);
- sec_node = of_find_node_by_path(path);
-
- if (node == pri_node)
- /* The primary timer lacks IRQ, use as clocksource */
- return integrator_clocksource_init(rate, base);
+ /* Drop the refcount of node */
+ of_node_put(alias_node);
- if (node == sec_node) {
+ if (node == alias_node) {
/* The secondary timer will drive the clock event */
irq = irq_of_parse_and_map(node, 0);
return integrator_clockevent_init(rate, base, irq);
--
2.17.0
[PATCH v4 2/2] clk: qcom: Add graphics clock controller driver for SDM845
From: Amit Nischal
Add support for the graphics clock controller found on SDM845
based devices. This would allow graphics drivers to probe and
control their clocks.
Signed-off-by: Amit Nischal
Signed-off-by: Taniya Das
---
drivers/clk/qcom/Kconfig| 9 ++
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/gpucc-sdm845.c | 231
3 files changed, 241 insertions(+)
create mode 100644 drivers/clk/qcom/gpucc-sdm845.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index a611531..6f3e466 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -273,6 +273,15 @@ config SDM_GCC_845
Say Y if you want to use peripheral devices such as UART, SPI,
i2C, USB, UFS, SDDC, PCIe, etc.
+config SDM_GPUCC_845
+ tristate "SDM845 Graphics Clock Controller"
+ depends on COMMON_CLK_QCOM
+ select SDM_GCC_845
+ help
+ Support for the graphics clock controller on SDM845 devices.
+ Say Y if you want to support graphics controller devices and
+ functionality such as 3D graphics.
+
config SDM_VIDEOCC_845
tristate "SDM845 Video Clock Controller"
depends on COMMON_CLK_QCOM
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 981882e..6ed2827 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SDM_CAMCC_845) += camcc-sdm845.o
obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o
obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
+obj-$(CONFIG_SDM_GPUCC_845) += gpucc-sdm845.o
obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
diff --git a/drivers/clk/qcom/gpucc-sdm845.c b/drivers/clk/qcom/gpucc-sdm845.c
new file mode 100644
index 000..11222f4
--- /dev/null
+++ b/drivers/clk/qcom/gpucc-sdm845.c
@@ -0,0 +1,231 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "common.h"
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "gdsc.h"
+
+#define CX_GMU_CBCR_SLEEP_MASK 0xf
+#define CX_GMU_CBCR_SLEEP_SHIFT4
+#define CX_GMU_CBCR_WAKE_MASK 0xf
+#define CX_GMU_CBCR_WAKE_SHIFT 8
+#define CLK_DIS_WAIT_SHIFT 12
+#define CLK_DIS_WAIT_MASK (0xf << CLK_DIS_WAIT_SHIFT)
+
+enum {
+ P_BI_TCXO,
+ P_CORE_BI_PLL_TEST_SE,
+ P_GPLL0_OUT_MAIN,
+ P_GPLL0_OUT_MAIN_DIV,
+ P_GPU_CC_PLL1_OUT_EVEN,
+ P_GPU_CC_PLL1_OUT_MAIN,
+ P_GPU_CC_PLL1_OUT_ODD,
+};
+
+static const struct parent_map gpu_cc_parent_map_0[] = {
+ { P_BI_TCXO, 0 },
+ { P_GPU_CC_PLL1_OUT_MAIN, 3 },
+ { P_GPLL0_OUT_MAIN, 5 },
+ { P_GPLL0_OUT_MAIN_DIV, 6 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gpu_cc_parent_names_0[] = {
+ "bi_tcxo",
+ "gpu_cc_pll1",
+ "gcc_gpu_gpll0_clk_src",
+ "gcc_gpu_gpll0_div_clk_src",
+ "core_bi_pll_test_se",
+};
+
+static const struct alpha_pll_config gpu_cc_pll1_config = {
+ .l = 0x1a,
+ .alpha = 0xaab,
+};
+
+static struct clk_alpha_pll gpu_cc_pll1 = {
+ .offset = 0x100,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "gpu_cc_pll1",
+ .parent_names = (const char *[]){ "bi_tcxo" },
+ .num_parents = 1,
+ .ops = _alpha_pll_fabia_ops,
+ },
+ },
+};
+
+static const struct freq_tbl ftbl_gpu_cc_gmu_clk_src[] = {
+ F(1920, P_BI_TCXO, 1, 0, 0),
+ F(2, P_GPLL0_OUT_MAIN_DIV, 1.5, 0, 0),
+ F(5, P_GPU_CC_PLL1_OUT_MAIN, 1, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 gpu_cc_gmu_clk_src = {
+ .cmd_rcgr = 0x1120,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = gpu_cc_parent_map_0,
+ .freq_tbl = ftbl_gpu_cc_gmu_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gpu_cc_gmu_clk_src",
+ .parent_names = gpu_cc_parent_names_0,
+ .num_parents = 6,
+ .ops = _rcg2_shared_ops,
+ },
+};
+
+static struct clk_branch gpu_cc_cx_gmu_clk = {
+ .halt_reg = 0x1098,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1098,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpu_cc_cx_gmu_clk",
+ .parent_names = (const char *[]){
+ "gpu_cc_gmu_clk_src",
+ },
+
[PATCH v4 2/2] clk: qcom: Add graphics clock controller driver for SDM845
From: Amit Nischal
Add support for the graphics clock controller found on SDM845
based devices. This would allow graphics drivers to probe and
control their clocks.
Signed-off-by: Amit Nischal
Signed-off-by: Taniya Das
---
drivers/clk/qcom/Kconfig| 9 ++
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/gpucc-sdm845.c | 231
3 files changed, 241 insertions(+)
create mode 100644 drivers/clk/qcom/gpucc-sdm845.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index a611531..6f3e466 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -273,6 +273,15 @@ config SDM_GCC_845
Say Y if you want to use peripheral devices such as UART, SPI,
i2C, USB, UFS, SDDC, PCIe, etc.
+config SDM_GPUCC_845
+ tristate "SDM845 Graphics Clock Controller"
+ depends on COMMON_CLK_QCOM
+ select SDM_GCC_845
+ help
+ Support for the graphics clock controller on SDM845 devices.
+ Say Y if you want to support graphics controller devices and
+ functionality such as 3D graphics.
+
config SDM_VIDEOCC_845
tristate "SDM845 Video Clock Controller"
depends on COMMON_CLK_QCOM
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 981882e..6ed2827 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SDM_CAMCC_845) += camcc-sdm845.o
obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o
obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
+obj-$(CONFIG_SDM_GPUCC_845) += gpucc-sdm845.o
obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
diff --git a/drivers/clk/qcom/gpucc-sdm845.c b/drivers/clk/qcom/gpucc-sdm845.c
new file mode 100644
index 000..11222f4
--- /dev/null
+++ b/drivers/clk/qcom/gpucc-sdm845.c
@@ -0,0 +1,231 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "common.h"
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "gdsc.h"
+
+#define CX_GMU_CBCR_SLEEP_MASK 0xf
+#define CX_GMU_CBCR_SLEEP_SHIFT4
+#define CX_GMU_CBCR_WAKE_MASK 0xf
+#define CX_GMU_CBCR_WAKE_SHIFT 8
+#define CLK_DIS_WAIT_SHIFT 12
+#define CLK_DIS_WAIT_MASK (0xf << CLK_DIS_WAIT_SHIFT)
+
+enum {
+ P_BI_TCXO,
+ P_CORE_BI_PLL_TEST_SE,
+ P_GPLL0_OUT_MAIN,
+ P_GPLL0_OUT_MAIN_DIV,
+ P_GPU_CC_PLL1_OUT_EVEN,
+ P_GPU_CC_PLL1_OUT_MAIN,
+ P_GPU_CC_PLL1_OUT_ODD,
+};
+
+static const struct parent_map gpu_cc_parent_map_0[] = {
+ { P_BI_TCXO, 0 },
+ { P_GPU_CC_PLL1_OUT_MAIN, 3 },
+ { P_GPLL0_OUT_MAIN, 5 },
+ { P_GPLL0_OUT_MAIN_DIV, 6 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gpu_cc_parent_names_0[] = {
+ "bi_tcxo",
+ "gpu_cc_pll1",
+ "gcc_gpu_gpll0_clk_src",
+ "gcc_gpu_gpll0_div_clk_src",
+ "core_bi_pll_test_se",
+};
+
+static const struct alpha_pll_config gpu_cc_pll1_config = {
+ .l = 0x1a,
+ .alpha = 0xaab,
+};
+
+static struct clk_alpha_pll gpu_cc_pll1 = {
+ .offset = 0x100,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "gpu_cc_pll1",
+ .parent_names = (const char *[]){ "bi_tcxo" },
+ .num_parents = 1,
+ .ops = _alpha_pll_fabia_ops,
+ },
+ },
+};
+
+static const struct freq_tbl ftbl_gpu_cc_gmu_clk_src[] = {
+ F(1920, P_BI_TCXO, 1, 0, 0),
+ F(2, P_GPLL0_OUT_MAIN_DIV, 1.5, 0, 0),
+ F(5, P_GPU_CC_PLL1_OUT_MAIN, 1, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 gpu_cc_gmu_clk_src = {
+ .cmd_rcgr = 0x1120,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = gpu_cc_parent_map_0,
+ .freq_tbl = ftbl_gpu_cc_gmu_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gpu_cc_gmu_clk_src",
+ .parent_names = gpu_cc_parent_names_0,
+ .num_parents = 6,
+ .ops = _rcg2_shared_ops,
+ },
+};
+
+static struct clk_branch gpu_cc_cx_gmu_clk = {
+ .halt_reg = 0x1098,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1098,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpu_cc_cx_gmu_clk",
+ .parent_names = (const char *[]){
+ "gpu_cc_gmu_clk_src",
+ },
+
[PATCH v4 1/2] dt-bindings: clock: Introduce QCOM Graphics clock bindings
From: Amit Nischal
Add device tree bindings for graphics clock controller for
Qualcomm Technology Inc's SDM845 SoCs.
Signed-off-by: Amit Nischal
---
.../devicetree/bindings/clock/qcom,gpucc.txt | 18
include/dt-bindings/clock/qcom,gpucc-sdm845.h | 24 ++
2 files changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,gpucc.txt
create mode 100644 include/dt-bindings/clock/qcom,gpucc-sdm845.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.txt
b/Documentation/devicetree/bindings/clock/qcom,gpucc.txt
new file mode 100644
index 000..93752db
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.txt
@@ -0,0 +1,18 @@
+Qualcomm Graphics Clock & Reset Controller Binding
+--
+
+Required properties :
+- compatible : shall contain "qcom,sdm845-gpucc".
+- reg : shall contain base register location and length.
+- #clock-cells : from common clock binding, shall contain 1.
+- #reset-cells : from common reset binding, shall contain 1.
+- #power-domain-cells : from generic power domain binding, shall contain 1.
+
+Example:
+ gpucc: clock-controller@509 {
+ compatible = "qcom,sdm845-gpucc";
+ reg = <0x509 0x9000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
diff --git a/include/dt-bindings/clock/qcom,gpucc-sdm845.h
b/include/dt-bindings/clock/qcom,gpucc-sdm845.h
new file mode 100644
index 000..9690d90
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gpucc-sdm845.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_SDM_GPU_CC_SDM845_H
+#define _DT_BINDINGS_CLK_SDM_GPU_CC_SDM845_H
+
+/* GPU_CC clock registers */
+#define GPU_CC_CX_GMU_CLK 0
+#define GPU_CC_CXO_CLK 1
+#define GPU_CC_GMU_CLK_SRC 2
+#define GPU_CC_PLL13
+
+/* GPU_CC Resets */
+#define GPUCC_GPU_CC_CX_BCR0
+#define GPUCC_GPU_CC_GMU_BCR 1
+#define GPUCC_GPU_CC_XO_BCR2
+
+/* GPU_CC GDSCRs */
+#define GPU_CX_GDSC0
+#define GPU_GX_GDSC1
+
+#endif
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
[PATCH v4 0/2] Add QCOM graphics clock controller driver for SDM845
Changes in v4: * Cleanup the GPUCC code to keep only the clocks which would be requested from the GPU client SW. * Clean up of code as well as header file clock IDs. * Due to the above cleanup the patches to enable/disable clocks for GPU GDSC requirement is not supported : https://patchwork.kernel.org/patch/10563889/ * The GPU_GX RCG support is also removed from the main driver, so the corresponding RCG ops are removed : https://patchwork.kernel.org/patch/10563891/ Changes in v3: * Modified the determine_rate() op to use the min/max rate range to round the requested rate within the set_rate range. With this, requested set rate will always stay within the limits. Changes in v2: Addressed review comments given by Stephen: https://lkml.org/lkml/2018/6/6/294 * Introduce clk_rcg2_gfx3d_determine_rate ops to return the best parent as 'gpucc_pll0_even' and best parent rate as twice of the requested rate always. This will eliminate the need of frequency table as source and div-2 are fixed for gfx3d_clk_src. Also modified the clk_rcg2_set_rate ops to configure the fixed source and div. * Add support to check if requested rate falls within allowed set_rate range. This will not let the source gpucc_pll0 to go out of the supported range and also client can request the rate within the range. * Fixed comment text in probe function and added module description for GPUCC driver. The graphics clock driver depends upon the below change. https://lkml.org/lkml/2018/6/23/108 Changes in v1: This patch series adds support for graphics clock controller for SDM845. Below is the brief description for each change: 1. For some of the GDSCs, there is requirement to enable/disable the few clocks before turning on/off the gdsc power domain. This patch will add support to enable/disable the clock associated with the gdsc along with power domain on/off callbacks. 2. To turn on the gpu_gx_gdsc, there is a hardware requirement to turn on the root clock (GFX3D RCG) first which would be the turn on signal for the gdsc along with the SW_COLLAPSE. As per the current implementation of clk_rcg2_shared_ops, it clears the root_enable bit in the enable() clock ops. But due to the above said requirement for GFX3D shared RCG, root_enable bit would be already set by gdsc driver and rcg2_shared_ops should not clear the root unless the disable() is called. This patch add support for the same by reusing the existing clk_rcg2_shared_ops and deriving "clk_rcg2_gfx3d_ops" clk_ops for GFX3D clock to take care of the root set/clear requirement. 3. Add device tree bindings for graphics clock controller for SDM845. 4. Add graphics clock controller (GPUCC) driver for SDM845. [v1] : https://lore.kernel.org/patchwork/project/lkml/list/?series=348697 [v2] : https://lore.kernel.org/patchwork/project/lkml/list/?series=359012 Amit Nischal (2): dt-bindings: clock: Introduce QCOM Graphics clock bindings clk: qcom: Add graphics clock controller driver for SDM845 .../devicetree/bindings/clock/qcom,gpucc.txt | 18 ++ drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/gpucc-sdm845.c| 231 + include/dt-bindings/clock/qcom,gpucc-sdm845.h | 24 +++ 5 files changed, 283 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,gpucc.txt create mode 100644 drivers/clk/qcom/gpucc-sdm845.c create mode 100644 include/dt-bindings/clock/qcom,gpucc-sdm845.h -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member of the Code Aurora Forum, hosted by the Linux Foundation.
[PATCH v4 0/2] Add QCOM graphics clock controller driver for SDM845
Changes in v4: * Cleanup the GPUCC code to keep only the clocks which would be requested from the GPU client SW. * Clean up of code as well as header file clock IDs. * Due to the above cleanup the patches to enable/disable clocks for GPU GDSC requirement is not supported : https://patchwork.kernel.org/patch/10563889/ * The GPU_GX RCG support is also removed from the main driver, so the corresponding RCG ops are removed : https://patchwork.kernel.org/patch/10563891/ Changes in v3: * Modified the determine_rate() op to use the min/max rate range to round the requested rate within the set_rate range. With this, requested set rate will always stay within the limits. Changes in v2: Addressed review comments given by Stephen: https://lkml.org/lkml/2018/6/6/294 * Introduce clk_rcg2_gfx3d_determine_rate ops to return the best parent as 'gpucc_pll0_even' and best parent rate as twice of the requested rate always. This will eliminate the need of frequency table as source and div-2 are fixed for gfx3d_clk_src. Also modified the clk_rcg2_set_rate ops to configure the fixed source and div. * Add support to check if requested rate falls within allowed set_rate range. This will not let the source gpucc_pll0 to go out of the supported range and also client can request the rate within the range. * Fixed comment text in probe function and added module description for GPUCC driver. The graphics clock driver depends upon the below change. https://lkml.org/lkml/2018/6/23/108 Changes in v1: This patch series adds support for graphics clock controller for SDM845. Below is the brief description for each change: 1. For some of the GDSCs, there is requirement to enable/disable the few clocks before turning on/off the gdsc power domain. This patch will add support to enable/disable the clock associated with the gdsc along with power domain on/off callbacks. 2. To turn on the gpu_gx_gdsc, there is a hardware requirement to turn on the root clock (GFX3D RCG) first which would be the turn on signal for the gdsc along with the SW_COLLAPSE. As per the current implementation of clk_rcg2_shared_ops, it clears the root_enable bit in the enable() clock ops. But due to the above said requirement for GFX3D shared RCG, root_enable bit would be already set by gdsc driver and rcg2_shared_ops should not clear the root unless the disable() is called. This patch add support for the same by reusing the existing clk_rcg2_shared_ops and deriving "clk_rcg2_gfx3d_ops" clk_ops for GFX3D clock to take care of the root set/clear requirement. 3. Add device tree bindings for graphics clock controller for SDM845. 4. Add graphics clock controller (GPUCC) driver for SDM845. [v1] : https://lore.kernel.org/patchwork/project/lkml/list/?series=348697 [v2] : https://lore.kernel.org/patchwork/project/lkml/list/?series=359012 Amit Nischal (2): dt-bindings: clock: Introduce QCOM Graphics clock bindings clk: qcom: Add graphics clock controller driver for SDM845 .../devicetree/bindings/clock/qcom,gpucc.txt | 18 ++ drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/gpucc-sdm845.c| 231 + include/dt-bindings/clock/qcom,gpucc-sdm845.h | 24 +++ 5 files changed, 283 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,gpucc.txt create mode 100644 drivers/clk/qcom/gpucc-sdm845.c create mode 100644 include/dt-bindings/clock/qcom,gpucc-sdm845.h -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member of the Code Aurora Forum, hosted by the Linux Foundation.
[PATCH v4 1/2] dt-bindings: clock: Introduce QCOM Graphics clock bindings
From: Amit Nischal
Add device tree bindings for graphics clock controller for
Qualcomm Technology Inc's SDM845 SoCs.
Signed-off-by: Amit Nischal
---
.../devicetree/bindings/clock/qcom,gpucc.txt | 18
include/dt-bindings/clock/qcom,gpucc-sdm845.h | 24 ++
2 files changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,gpucc.txt
create mode 100644 include/dt-bindings/clock/qcom,gpucc-sdm845.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.txt
b/Documentation/devicetree/bindings/clock/qcom,gpucc.txt
new file mode 100644
index 000..93752db
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.txt
@@ -0,0 +1,18 @@
+Qualcomm Graphics Clock & Reset Controller Binding
+--
+
+Required properties :
+- compatible : shall contain "qcom,sdm845-gpucc".
+- reg : shall contain base register location and length.
+- #clock-cells : from common clock binding, shall contain 1.
+- #reset-cells : from common reset binding, shall contain 1.
+- #power-domain-cells : from generic power domain binding, shall contain 1.
+
+Example:
+ gpucc: clock-controller@509 {
+ compatible = "qcom,sdm845-gpucc";
+ reg = <0x509 0x9000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
diff --git a/include/dt-bindings/clock/qcom,gpucc-sdm845.h
b/include/dt-bindings/clock/qcom,gpucc-sdm845.h
new file mode 100644
index 000..9690d90
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gpucc-sdm845.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_SDM_GPU_CC_SDM845_H
+#define _DT_BINDINGS_CLK_SDM_GPU_CC_SDM845_H
+
+/* GPU_CC clock registers */
+#define GPU_CC_CX_GMU_CLK 0
+#define GPU_CC_CXO_CLK 1
+#define GPU_CC_GMU_CLK_SRC 2
+#define GPU_CC_PLL13
+
+/* GPU_CC Resets */
+#define GPUCC_GPU_CC_CX_BCR0
+#define GPUCC_GPU_CC_GMU_BCR 1
+#define GPUCC_GPU_CC_XO_BCR2
+
+/* GPU_CC GDSCRs */
+#define GPU_CX_GDSC0
+#define GPU_GX_GDSC1
+
+#endif
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
Re: [PATCH] clocksource/drivers/integrator-ap: add missing of_node_put()
On Sun, Nov 25, 2018 at 3:49 AM Daniel Lezcano
wrote:
>
> On 24/11/2018 15:58, Frank Lee wrote:
> > On Thu, Nov 22, 2018 at 11:23 PM Yangtao Li wrote:
> >>
> >> of_find_node_by_path() acquires a reference to the node
> >> returned by it and that reference needs to be dropped by its caller.
> >> integrator_ap_timer_init_of() doesn't do that, so fix it.
> >>
> >> Signed-off-by: Yangtao Li
> >> ---
> >> drivers/clocksource/timer-integrator-ap.c | 20 ++--
> >> 1 file changed, 14 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/clocksource/timer-integrator-ap.c
> >> b/drivers/clocksource/timer-integrator-ap.c
> >> index 76e526f58620..1f04069470bb 100644
> >> --- a/drivers/clocksource/timer-integrator-ap.c
> >> +++ b/drivers/clocksource/timer-integrator-ap.c
> >> @@ -177,7 +177,7 @@ static int __init integrator_ap_timer_init_of(struct
> >> device_node *node)
> >> {
> >> const char *path;
> >> void __iomem *base;
> >> - int err;
> >> + int err,rc = 0;
> >> int irq;
> >> struct clk *clk;
> >> unsigned long rate;
> >> @@ -210,26 +210,34 @@ static int __init integrator_ap_timer_init_of(struct
> >> device_node *node)
> >> "arm,timer-secondary", );
> >> if (err) {
> >> pr_warn("Failed to read property\n");
> >> - return err;
> >> + rc = err;
> >> + goto out_put_pri_node;
> >> }
> >>
> >>
> >> sec_node = of_find_node_by_path(path);
> >>
> >> - if (node == pri_node)
> >> + if (node == pri_node){
> >> /* The primary timer lacks IRQ, use as clocksource */
> >> - return integrator_clocksource_init(rate, base);
> >> + rc = integrator_clocksource_init(rate, base);
> >> + goto out;
> >> + }
> >>
> >> if (node == sec_node) {
> >> /* The secondary timer will drive the clock event */
> >> irq = irq_of_parse_and_map(node, 0);
> >> - return integrator_clockevent_init(rate, base, irq);
> >> + rc = integrator_clockevent_init(rate, base, irq);
> >> + goto out;
> >> }
> >>
> >> pr_info("Timer @%p unused\n", base);
> >> clk_disable_unprepare(clk);
> >> +out:
> >> + of_node_put(sec_node);
> >> +out_put_pri_node:
> >> + of_node_put(pri_node);
> >>
> >> - return 0;
> >> + return rc;
> >> }
> >>
> >> TIMER_OF_DECLARE(integrator_ap_timer, "arm,integrator-timer",
> >> --
> >> 2.17.0
> >>
> > Hi Daniel：
> >
> > How about this?
>
> Hi,
>
> I think there is a simpler fix. The pri_node and the sec_node are used
> as an identifier to compare against the current node, we can directly
> drop the refcount after getting the node from path as it is not used as
> pointer. In addition, a single variable is needed, so we end up with a
> fix like that.
>
> alias_node = of_find_node_by_path(path);
> of_node_put(alias_node);
> if (node == alias_node)
> return integrator_clocksource_init(rate, base);
Daniel,
OK,I will simplify it like you said.Although I think of_node_put
should be called
after we don't use node.
MBR，
Yangtao
>
>
>
> >
> > Thanks，
> > Yangtao
> >
>
>
> --
> Facebook |
> Twitter |
>
Re: [PATCH] clocksource/drivers/integrator-ap: add missing of_node_put()
On Sun, Nov 25, 2018 at 3:49 AM Daniel Lezcano
wrote:
>
> On 24/11/2018 15:58, Frank Lee wrote:
> > On Thu, Nov 22, 2018 at 11:23 PM Yangtao Li wrote:
> >>
> >> of_find_node_by_path() acquires a reference to the node
> >> returned by it and that reference needs to be dropped by its caller.
> >> integrator_ap_timer_init_of() doesn't do that, so fix it.
> >>
> >> Signed-off-by: Yangtao Li
> >> ---
> >> drivers/clocksource/timer-integrator-ap.c | 20 ++--
> >> 1 file changed, 14 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/clocksource/timer-integrator-ap.c
> >> b/drivers/clocksource/timer-integrator-ap.c
> >> index 76e526f58620..1f04069470bb 100644
> >> --- a/drivers/clocksource/timer-integrator-ap.c
> >> +++ b/drivers/clocksource/timer-integrator-ap.c
> >> @@ -177,7 +177,7 @@ static int __init integrator_ap_timer_init_of(struct
> >> device_node *node)
> >> {
> >> const char *path;
> >> void __iomem *base;
> >> - int err;
> >> + int err,rc = 0;
> >> int irq;
> >> struct clk *clk;
> >> unsigned long rate;
> >> @@ -210,26 +210,34 @@ static int __init integrator_ap_timer_init_of(struct
> >> device_node *node)
> >> "arm,timer-secondary", );
> >> if (err) {
> >> pr_warn("Failed to read property\n");
> >> - return err;
> >> + rc = err;
> >> + goto out_put_pri_node;
> >> }
> >>
> >>
> >> sec_node = of_find_node_by_path(path);
> >>
> >> - if (node == pri_node)
> >> + if (node == pri_node){
> >> /* The primary timer lacks IRQ, use as clocksource */
> >> - return integrator_clocksource_init(rate, base);
> >> + rc = integrator_clocksource_init(rate, base);
> >> + goto out;
> >> + }
> >>
> >> if (node == sec_node) {
> >> /* The secondary timer will drive the clock event */
> >> irq = irq_of_parse_and_map(node, 0);
> >> - return integrator_clockevent_init(rate, base, irq);
> >> + rc = integrator_clockevent_init(rate, base, irq);
> >> + goto out;
> >> }
> >>
> >> pr_info("Timer @%p unused\n", base);
> >> clk_disable_unprepare(clk);
> >> +out:
> >> + of_node_put(sec_node);
> >> +out_put_pri_node:
> >> + of_node_put(pri_node);
> >>
> >> - return 0;
> >> + return rc;
> >> }
> >>
> >> TIMER_OF_DECLARE(integrator_ap_timer, "arm,integrator-timer",
> >> --
> >> 2.17.0
> >>
> > Hi Daniel：
> >
> > How about this?
>
> Hi,
>
> I think there is a simpler fix. The pri_node and the sec_node are used
> as an identifier to compare against the current node, we can directly
> drop the refcount after getting the node from path as it is not used as
> pointer. In addition, a single variable is needed, so we end up with a
> fix like that.
>
> alias_node = of_find_node_by_path(path);
> of_node_put(alias_node);
> if (node == alias_node)
> return integrator_clocksource_init(rate, base);
Daniel,
OK,I will simplify it like you said.Although I think of_node_put
should be called
after we don't use node.
MBR，
Yangtao
>
>
>
> >
> > Thanks，
> > Yangtao
> >
>
>
> --
> Facebook |
> Twitter |
>
Re: [RFC PATCH v2] ptrace: add PTRACE_GET_SYSCALL_INFO request
On Fri, Nov 23, 2018 at 07:01:39AM +0300, Dmitry V. Levin wrote:
> On Thu, Nov 22, 2018 at 04:19:10PM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 22, 2018 at 11:15 AM Dmitry V. Levin wrote:
> > > On Thu, Nov 22, 2018 at 06:55:29AM -0800, Andy Lutomirski wrote:
> > > > On Wed, Nov 21, 2018 at 3:56 PM Dmitry V. Levin wrote:
> > > > > On Wed, Nov 21, 2018 at 02:56:57PM -0800, Andy Lutomirski wrote:
> > > > > > Please cc linux-...@vger.kernel.org for future versions.
> > > > > >
> > > > > > On Wed, Nov 21, 2018 at 7:58 AM Elvira Khabirova wrote:
> > > > > > >
> > > > > > > struct ptrace_syscall_info {
> > > > > > > __u8 op; /* 0 for entry, 1 for exit */
> > > > > >
> > > > > > Can you add proper defines, like:
> > > > > >
> > > > > > #define PTRACE_SYSCALL_ENTRY 0
> > > > > > #define PTRACE_SYSCALL_EXIT 1
> > > > > > #define PTRACE_SYSCALL_SECCOMP 2
> > > > > >
> > > > > > and make seccomp work from the start? I'd rather we don't merge an
> > > > > > implementation that doesn't work for seccomp and then have to rework
> > > > > > it later.
> > > > >
> > > > > What's the difference between PTRACE_EVENT_SECCOMP and
> > > > > syscall-entry-stop
> > > > > with regards to PTRACE_GET_SYSCALL_INFO request? At least they have
> > > > > the
> > > > > same entry_info to return.
> > > >
> > > > I'm not sure there's any material difference.
> > >
> > > In that case we don't really need PTRACE_SYSCALL_SECCOMP: op field
> > > describes the structure inside the union to use, not the ptrace stop.
> >
> > Unless we think the structures might diverge in the future.
>
> If these structures ever diverge, then a seccomp structure will be added
> to the union, and a portable userspace code will likely look this way:
>
> #include
> ...
> struct ptrace_syscall_info info;
> long rc = ptrace(PTRACE_GET_SYSCALL_INFO, pid, (void *) sizeof(info), );
> ...
> switch (info.op) {
> case PTRACE_SYSCALL_INFO_ENTRY:
> /* handle info.entry */
> case PTRACE_SYSCALL_INFO_EXIT:
> /* handle info.exit */
> #ifdef PTRACE_SYSCALL_INFO_SECCOMP
> case PTRACE_SYSCALL_INFO_SECCOMP:
> /* handle info.seccomp */
> #endif
> default:
> /* handle unknown info.op */
> }
>
> In other words, it would be better if PTRACE_SYSCALL_INFO_* selector
> constants were introduced along with corresponding structures in the
> union.
However, the approach I suggested doesn't provide forward compatibility:
if userspace is compiled with kernel headers that don't define
PTRACE_SYSCALL_INFO_SECCOMP, it will break when the kernel
starts to use PTRACE_SYSCALL_INFO_SECCOMP instead of
PTRACE_SYSCALL_INFO_ENTRY for PTRACE_EVENT_SECCOMP support
in PTRACE_GET_SYSCALL_INFO.
The solution is to introduce PTRACE_SYSCALL_INFO_SECCOMP and struct
ptrace_syscall_info.seccomp along with PTRACE_EVENT_SECCOMP support
in PTRACE_GET_SYSCALL_INFO. The initial revision of the seccomp
structure could be made the same as the entry structure, or it can
diverge from the beginning, e.g., by adding ret_data field containing
SECCOMP_RET_DATA return value stored in ptrace_message, this would save
ptracers an extra PTRACE_GETEVENTMSG call currently required to obtain it.
--
ldv
signature.asc
Description: PGP signature
Re: [RFC PATCH v2] ptrace: add PTRACE_GET_SYSCALL_INFO request
On Fri, Nov 23, 2018 at 07:01:39AM +0300, Dmitry V. Levin wrote:
> On Thu, Nov 22, 2018 at 04:19:10PM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 22, 2018 at 11:15 AM Dmitry V. Levin wrote:
> > > On Thu, Nov 22, 2018 at 06:55:29AM -0800, Andy Lutomirski wrote:
> > > > On Wed, Nov 21, 2018 at 3:56 PM Dmitry V. Levin wrote:
> > > > > On Wed, Nov 21, 2018 at 02:56:57PM -0800, Andy Lutomirski wrote:
> > > > > > Please cc linux-...@vger.kernel.org for future versions.
> > > > > >
> > > > > > On Wed, Nov 21, 2018 at 7:58 AM Elvira Khabirova wrote:
> > > > > > >
> > > > > > > struct ptrace_syscall_info {
> > > > > > > __u8 op; /* 0 for entry, 1 for exit */
> > > > > >
> > > > > > Can you add proper defines, like:
> > > > > >
> > > > > > #define PTRACE_SYSCALL_ENTRY 0
> > > > > > #define PTRACE_SYSCALL_EXIT 1
> > > > > > #define PTRACE_SYSCALL_SECCOMP 2
> > > > > >
> > > > > > and make seccomp work from the start? I'd rather we don't merge an
> > > > > > implementation that doesn't work for seccomp and then have to rework
> > > > > > it later.
> > > > >
> > > > > What's the difference between PTRACE_EVENT_SECCOMP and
> > > > > syscall-entry-stop
> > > > > with regards to PTRACE_GET_SYSCALL_INFO request? At least they have
> > > > > the
> > > > > same entry_info to return.
> > > >
> > > > I'm not sure there's any material difference.
> > >
> > > In that case we don't really need PTRACE_SYSCALL_SECCOMP: op field
> > > describes the structure inside the union to use, not the ptrace stop.
> >
> > Unless we think the structures might diverge in the future.
>
> If these structures ever diverge, then a seccomp structure will be added
> to the union, and a portable userspace code will likely look this way:
>
> #include
> ...
> struct ptrace_syscall_info info;
> long rc = ptrace(PTRACE_GET_SYSCALL_INFO, pid, (void *) sizeof(info), );
> ...
> switch (info.op) {
> case PTRACE_SYSCALL_INFO_ENTRY:
> /* handle info.entry */
> case PTRACE_SYSCALL_INFO_EXIT:
> /* handle info.exit */
> #ifdef PTRACE_SYSCALL_INFO_SECCOMP
> case PTRACE_SYSCALL_INFO_SECCOMP:
> /* handle info.seccomp */
> #endif
> default:
> /* handle unknown info.op */
> }
>
> In other words, it would be better if PTRACE_SYSCALL_INFO_* selector
> constants were introduced along with corresponding structures in the
> union.
However, the approach I suggested doesn't provide forward compatibility:
if userspace is compiled with kernel headers that don't define
PTRACE_SYSCALL_INFO_SECCOMP, it will break when the kernel
starts to use PTRACE_SYSCALL_INFO_SECCOMP instead of
PTRACE_SYSCALL_INFO_ENTRY for PTRACE_EVENT_SECCOMP support
in PTRACE_GET_SYSCALL_INFO.
The solution is to introduce PTRACE_SYSCALL_INFO_SECCOMP and struct
ptrace_syscall_info.seccomp along with PTRACE_EVENT_SECCOMP support
in PTRACE_GET_SYSCALL_INFO. The initial revision of the seccomp
structure could be made the same as the entry structure, or it can
diverge from the beginning, e.g., by adding ret_data field containing
SECCOMP_RET_DATA return value stored in ptrace_message, this would save
ptracers an extra PTRACE_GETEVENTMSG call currently required to obtain it.
--
ldv
signature.asc
Description: PGP signature
Re: [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
On Sat, Nov 24, 2018 at 07:21:07PM -0800, Hugh Dickins wrote:
> Waiting on a page migration entry has used wait_on_page_locked() all
> along since 2006: but you cannot safely wait_on_page_locked() without
> holding a reference to the page, and that extra reference is enough to
> make migrate_page_move_mapping() fail with -EAGAIN, when a racing task
> faults on the entry before migrate_page_move_mapping() gets there.
>
> And that failure is retried nine times, amplifying the pain when
> trying to migrate a popular page. With a single persistent faulter,
> migration sometimes succeeds; with two or three concurrent faulters,
> success becomes much less likely (and the more the page was mapped,
> the worse the overhead of unmapping and remapping it on each try).
>
> This is especially a problem for memory offlining, where the outer
> level retries forever (or until terminated from userspace), because
> a heavy refault workload can trigger an endless loop of migration
> failures. wait_on_page_locked() is the wrong tool for the job.
>
> David Herrmann (but was he the first?) noticed this issue in 2014:
> https://marc.info/?l=linux-mm=140110465608116=2
>
> Tim Chen started a thread in August 2017 which appears relevant:
> https://marc.info/?l=linux-mm=150275941014915=2
> where Kan Liang went on to implicate __migration_entry_wait():
> https://marc.info/?l=linux-mm=150300268411980=2
> and the thread ended up with the v4.14 commits:
> 2554db916586 ("sched/wait: Break up long wake list walk")
> 11a19c7b099f ("sched/wait: Introduce wakeup boomark in wake_up_page_bit")
>
> Baoquan He reported "Memory hotplug softlock issue" 14 November 2018:
> https://marc.info/?l=linux-mm=154217936431300=2
>
> We have all assumed that it is essential to hold a page reference while
> waiting on a page lock: partly to guarantee that there is still a struct
> page when MEMORY_HOTREMOVE is configured, but also to protect against
> reuse of the struct page going to someone who then holds the page locked
> indefinitely, when the waiter can reasonably expect timely unlocking.
>
> But in fact, so long as wait_on_page_bit_common() does the put_page(),
> and is careful not to rely on struct page contents thereafter, there is
> no need to hold a reference to the page while waiting on it. That does
> mean that this case cannot go back through the loop: but that's fine for
> the page migration case, and even if used more widely, is limited by the
> "Stop walking if it's locked" optimization in wake_page_function().
>
> Add interface put_and_wait_on_page_locked() to do this, using negative
> value of the lock arg to wait_on_page_bit_common() to implement it.
> No interruptible or killable variant needed yet, but they might follow:
> I have a vague notion that reporting -EINTR should take precedence over
> return from wait_on_page_bit_common() without knowing the page state,
> so arrange it accordingly - but that may be nothing but pedantic.
>
> __migration_entry_wait() still has to take a brief reference to the
> page, prior to calling put_and_wait_on_page_locked(): but now that it
> is dropped before waiting, the chance of impeding page migration is
> very much reduced. Should we perhaps disable preemption across this?
>
> shrink_page_list()'s __ClearPageLocked(): that was a surprise! This
> survived a lot of testing before that showed up. PageWaiters may have
> been set by wait_on_page_bit_common(), and the reference dropped, just
> before shrink_page_list() succeeds in freezing its last page reference:
> in such a case, unlock_page() must be used. Follow the suggestion from
> Michal Hocko, just revert a978d6f52106 ("mm: unlockless reclaim") now:
> that optimization predates PageWaiters, and won't buy much these days;
> but we can reinstate it for the !PageWaiters case if anyone notices.
>
> It does raise the question: should vmscan.c's is_page_cache_freeable()
> and __remove_mapping() now treat a PageWaiters page as if an extra
> reference were held? Perhaps, but I don't think it matters much, since
> shrink_page_list() already had to win its trylock_page(), so waiters are
> not very common there: I noticed no difference when trying the bigger
> change, and it's surely not needed while put_and_wait_on_page_locked()
> is only used for page migration.
>
> Reported-and-tested-by: Baoquan He
> Signed-off-by: Hugh Dickins
> Acked-by: Michal Hocko
Reviewed-by: Andrea Arcangeli
Re: [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
On Sat, Nov 24, 2018 at 07:21:07PM -0800, Hugh Dickins wrote:
> Waiting on a page migration entry has used wait_on_page_locked() all
> along since 2006: but you cannot safely wait_on_page_locked() without
> holding a reference to the page, and that extra reference is enough to
> make migrate_page_move_mapping() fail with -EAGAIN, when a racing task
> faults on the entry before migrate_page_move_mapping() gets there.
>
> And that failure is retried nine times, amplifying the pain when
> trying to migrate a popular page. With a single persistent faulter,
> migration sometimes succeeds; with two or three concurrent faulters,
> success becomes much less likely (and the more the page was mapped,
> the worse the overhead of unmapping and remapping it on each try).
>
> This is especially a problem for memory offlining, where the outer
> level retries forever (or until terminated from userspace), because
> a heavy refault workload can trigger an endless loop of migration
> failures. wait_on_page_locked() is the wrong tool for the job.
>
> David Herrmann (but was he the first?) noticed this issue in 2014:
> https://marc.info/?l=linux-mm=140110465608116=2
>
> Tim Chen started a thread in August 2017 which appears relevant:
> https://marc.info/?l=linux-mm=150275941014915=2
> where Kan Liang went on to implicate __migration_entry_wait():
> https://marc.info/?l=linux-mm=150300268411980=2
> and the thread ended up with the v4.14 commits:
> 2554db916586 ("sched/wait: Break up long wake list walk")
> 11a19c7b099f ("sched/wait: Introduce wakeup boomark in wake_up_page_bit")
>
> Baoquan He reported "Memory hotplug softlock issue" 14 November 2018:
> https://marc.info/?l=linux-mm=154217936431300=2
>
> We have all assumed that it is essential to hold a page reference while
> waiting on a page lock: partly to guarantee that there is still a struct
> page when MEMORY_HOTREMOVE is configured, but also to protect against
> reuse of the struct page going to someone who then holds the page locked
> indefinitely, when the waiter can reasonably expect timely unlocking.
>
> But in fact, so long as wait_on_page_bit_common() does the put_page(),
> and is careful not to rely on struct page contents thereafter, there is
> no need to hold a reference to the page while waiting on it. That does
> mean that this case cannot go back through the loop: but that's fine for
> the page migration case, and even if used more widely, is limited by the
> "Stop walking if it's locked" optimization in wake_page_function().
>
> Add interface put_and_wait_on_page_locked() to do this, using negative
> value of the lock arg to wait_on_page_bit_common() to implement it.
> No interruptible or killable variant needed yet, but they might follow:
> I have a vague notion that reporting -EINTR should take precedence over
> return from wait_on_page_bit_common() without knowing the page state,
> so arrange it accordingly - but that may be nothing but pedantic.
>
> __migration_entry_wait() still has to take a brief reference to the
> page, prior to calling put_and_wait_on_page_locked(): but now that it
> is dropped before waiting, the chance of impeding page migration is
> very much reduced. Should we perhaps disable preemption across this?
>
> shrink_page_list()'s __ClearPageLocked(): that was a surprise! This
> survived a lot of testing before that showed up. PageWaiters may have
> been set by wait_on_page_bit_common(), and the reference dropped, just
> before shrink_page_list() succeeds in freezing its last page reference:
> in such a case, unlock_page() must be used. Follow the suggestion from
> Michal Hocko, just revert a978d6f52106 ("mm: unlockless reclaim") now:
> that optimization predates PageWaiters, and won't buy much these days;
> but we can reinstate it for the !PageWaiters case if anyone notices.
>
> It does raise the question: should vmscan.c's is_page_cache_freeable()
> and __remove_mapping() now treat a PageWaiters page as if an extra
> reference were held? Perhaps, but I don't think it matters much, since
> shrink_page_list() already had to win its trylock_page(), so waiters are
> not very common there: I noticed no difference when trying the bigger
> change, and it's surely not needed while put_and_wait_on_page_locked()
> is only used for page migration.
>
> Reported-and-tested-by: Baoquan He
> Signed-off-by: Hugh Dickins
> Acked-by: Michal Hocko
Reviewed-by: Andrea Arcangeli
Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()
On Sun, 25 Nov 2018, Michael Schmitz wrote: > > We can benchmark gettimeofday syscalls on elgar but is that hardware > > representative of other relevant models? > > I suppose the CIA is on the main board, so running with the slower clock > speed that you'd see with a vanilla Amiga without 060 accelerator board. > Ought to be representative enough? > Not really. An accelerated CPU clock exaggerates the slowdown factor, given the fixed 0.7 MHz CIA clock. The "(ticks > jiffy_ticks / 2)" conditional won't make anything worse even if interrupt latency is already too high, so I'm inclined towards the more prudent option. This patch series is already complicated enough. In anycase, I'd prefer not to speculate about interrupt priorities or latencies when the list probably has people who know the answers. --
Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()
On Sun, 25 Nov 2018, Michael Schmitz wrote: > > We can benchmark gettimeofday syscalls on elgar but is that hardware > > representative of other relevant models? > > I suppose the CIA is on the main board, so running with the slower clock > speed that you'd see with a vanilla Amiga without 060 accelerator board. > Ought to be representative enough? > Not really. An accelerated CPU clock exaggerates the slowdown factor, given the fixed 0.7 MHz CIA clock. The "(ticks > jiffy_ticks / 2)" conditional won't make anything worse even if interrupt latency is already too high, so I'm inclined towards the more prudent option. This patch series is already complicated enough. In anycase, I'd prefer not to speculate about interrupt priorities or latencies when the list probably has people who know the answers. --
[PATCH] mm: put_and_wait_on_page_locked() while page is migrated
Waiting on a page migration entry has used wait_on_page_locked() all
along since 2006: but you cannot safely wait_on_page_locked() without
holding a reference to the page, and that extra reference is enough to
make migrate_page_move_mapping() fail with -EAGAIN, when a racing task
faults on the entry before migrate_page_move_mapping() gets there.
And that failure is retried nine times, amplifying the pain when
trying to migrate a popular page. With a single persistent faulter,
migration sometimes succeeds; with two or three concurrent faulters,
success becomes much less likely (and the more the page was mapped,
the worse the overhead of unmapping and remapping it on each try).
This is especially a problem for memory offlining, where the outer
level retries forever (or until terminated from userspace), because
a heavy refault workload can trigger an endless loop of migration
failures. wait_on_page_locked() is the wrong tool for the job.
David Herrmann (but was he the first?) noticed this issue in 2014:
https://marc.info/?l=linux-mm=140110465608116=2
Tim Chen started a thread in August 2017 which appears relevant:
https://marc.info/?l=linux-mm=150275941014915=2
where Kan Liang went on to implicate __migration_entry_wait():
https://marc.info/?l=linux-mm=150300268411980=2
and the thread ended up with the v4.14 commits:
2554db916586 ("sched/wait: Break up long wake list walk")
11a19c7b099f ("sched/wait: Introduce wakeup boomark in wake_up_page_bit")
Baoquan He reported "Memory hotplug softlock issue" 14 November 2018:
https://marc.info/?l=linux-mm=154217936431300=2
We have all assumed that it is essential to hold a page reference while
waiting on a page lock: partly to guarantee that there is still a struct
page when MEMORY_HOTREMOVE is configured, but also to protect against
reuse of the struct page going to someone who then holds the page locked
indefinitely, when the waiter can reasonably expect timely unlocking.
But in fact, so long as wait_on_page_bit_common() does the put_page(),
and is careful not to rely on struct page contents thereafter, there is
no need to hold a reference to the page while waiting on it. That does
mean that this case cannot go back through the loop: but that's fine for
the page migration case, and even if used more widely, is limited by the
"Stop walking if it's locked" optimization in wake_page_function().
Add interface put_and_wait_on_page_locked() to do this, using negative
value of the lock arg to wait_on_page_bit_common() to implement it.
No interruptible or killable variant needed yet, but they might follow:
I have a vague notion that reporting -EINTR should take precedence over
return from wait_on_page_bit_common() without knowing the page state,
so arrange it accordingly - but that may be nothing but pedantic.
__migration_entry_wait() still has to take a brief reference to the
page, prior to calling put_and_wait_on_page_locked(): but now that it
is dropped before waiting, the chance of impeding page migration is
very much reduced. Should we perhaps disable preemption across this?
shrink_page_list()'s __ClearPageLocked(): that was a surprise! This
survived a lot of testing before that showed up. PageWaiters may have
been set by wait_on_page_bit_common(), and the reference dropped, just
before shrink_page_list() succeeds in freezing its last page reference:
in such a case, unlock_page() must be used. Follow the suggestion from
Michal Hocko, just revert a978d6f52106 ("mm: unlockless reclaim") now:
that optimization predates PageWaiters, and won't buy much these days;
but we can reinstate it for the !PageWaiters case if anyone notices.
It does raise the question: should vmscan.c's is_page_cache_freeable()
and __remove_mapping() now treat a PageWaiters page as if an extra
reference were held? Perhaps, but I don't think it matters much, since
shrink_page_list() already had to win its trylock_page(), so waiters are
not very common there: I noticed no difference when trying the bigger
change, and it's surely not needed while put_and_wait_on_page_locked()
is only used for page migration.
Reported-and-tested-by: Baoquan He
Signed-off-by: Hugh Dickins
Acked-by: Michal Hocko
---
Linus, I'm addressing this patch to you because I see from Tim Chen's
thread that it would interest you, and you were disappointed not to
root cause the issue back then. I'm not pushing for you to fast-track
this into 4.20-rc, but I expect Andrew will pick it up for mmotm, and
thence linux-next. Or you may spot a terrible defect, but I hope not.
Hugh
include/linux/pagemap.h | 2 ++
mm/filemap.c| 60 -
mm/huge_memory.c| 6 ++---
mm/migrate.c| 12 +++--
mm/vmscan.c | 10 ++-
5 files changed, 57 insertions(+), 33 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 226f96f0dee0..e2d7039af6a3 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@
[PATCH] mm: put_and_wait_on_page_locked() while page is migrated
Waiting on a page migration entry has used wait_on_page_locked() all
along since 2006: but you cannot safely wait_on_page_locked() without
holding a reference to the page, and that extra reference is enough to
make migrate_page_move_mapping() fail with -EAGAIN, when a racing task
faults on the entry before migrate_page_move_mapping() gets there.
And that failure is retried nine times, amplifying the pain when
trying to migrate a popular page. With a single persistent faulter,
migration sometimes succeeds; with two or three concurrent faulters,
success becomes much less likely (and the more the page was mapped,
the worse the overhead of unmapping and remapping it on each try).
This is especially a problem for memory offlining, where the outer
level retries forever (or until terminated from userspace), because
a heavy refault workload can trigger an endless loop of migration
failures. wait_on_page_locked() is the wrong tool for the job.
David Herrmann (but was he the first?) noticed this issue in 2014:
https://marc.info/?l=linux-mm=140110465608116=2
Tim Chen started a thread in August 2017 which appears relevant:
https://marc.info/?l=linux-mm=150275941014915=2
where Kan Liang went on to implicate __migration_entry_wait():
https://marc.info/?l=linux-mm=150300268411980=2
and the thread ended up with the v4.14 commits:
2554db916586 ("sched/wait: Break up long wake list walk")
11a19c7b099f ("sched/wait: Introduce wakeup boomark in wake_up_page_bit")
Baoquan He reported "Memory hotplug softlock issue" 14 November 2018:
https://marc.info/?l=linux-mm=154217936431300=2
We have all assumed that it is essential to hold a page reference while
waiting on a page lock: partly to guarantee that there is still a struct
page when MEMORY_HOTREMOVE is configured, but also to protect against
reuse of the struct page going to someone who then holds the page locked
indefinitely, when the waiter can reasonably expect timely unlocking.
But in fact, so long as wait_on_page_bit_common() does the put_page(),
and is careful not to rely on struct page contents thereafter, there is
no need to hold a reference to the page while waiting on it. That does
mean that this case cannot go back through the loop: but that's fine for
the page migration case, and even if used more widely, is limited by the
"Stop walking if it's locked" optimization in wake_page_function().
Add interface put_and_wait_on_page_locked() to do this, using negative
value of the lock arg to wait_on_page_bit_common() to implement it.
No interruptible or killable variant needed yet, but they might follow:
I have a vague notion that reporting -EINTR should take precedence over
return from wait_on_page_bit_common() without knowing the page state,
so arrange it accordingly - but that may be nothing but pedantic.
__migration_entry_wait() still has to take a brief reference to the
page, prior to calling put_and_wait_on_page_locked(): but now that it
is dropped before waiting, the chance of impeding page migration is
very much reduced. Should we perhaps disable preemption across this?
shrink_page_list()'s __ClearPageLocked(): that was a surprise! This
survived a lot of testing before that showed up. PageWaiters may have
been set by wait_on_page_bit_common(), and the reference dropped, just
before shrink_page_list() succeeds in freezing its last page reference:
in such a case, unlock_page() must be used. Follow the suggestion from
Michal Hocko, just revert a978d6f52106 ("mm: unlockless reclaim") now:
that optimization predates PageWaiters, and won't buy much these days;
but we can reinstate it for the !PageWaiters case if anyone notices.
It does raise the question: should vmscan.c's is_page_cache_freeable()
and __remove_mapping() now treat a PageWaiters page as if an extra
reference were held? Perhaps, but I don't think it matters much, since
shrink_page_list() already had to win its trylock_page(), so waiters are
not very common there: I noticed no difference when trying the bigger
change, and it's surely not needed while put_and_wait_on_page_locked()
is only used for page migration.
Reported-and-tested-by: Baoquan He
Signed-off-by: Hugh Dickins
Acked-by: Michal Hocko
---
Linus, I'm addressing this patch to you because I see from Tim Chen's
thread that it would interest you, and you were disappointed not to
root cause the issue back then. I'm not pushing for you to fast-track
this into 4.20-rc, but I expect Andrew will pick it up for mmotm, and
thence linux-next. Or you may spot a terrible defect, but I hope not.
Hugh
include/linux/pagemap.h | 2 ++
mm/filemap.c| 60 -
mm/huge_memory.c| 6 ++---
mm/migrate.c| 12 +++--
mm/vmscan.c | 10 ++-
5 files changed, 57 insertions(+), 33 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 226f96f0dee0..e2d7039af6a3 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@
Re: [GIT PULL] XArray updates
On Sat, Nov 24, 2018 at 7:00 PM Matthew Wilcox wrote: > > I pushed it out to hkps://hkps.pool.sks-keyservers.net ... as I recall, > pgp.mit.edu is frequently not synchronised well with the other keyservers, > but I'm surprised that one of the sks-keyservers didn't have it. I got it now, so it was just some propagation delay or somethinig. Thanks, Linus
Re: [GIT PULL] XArray updates
On Sat, Nov 24, 2018 at 7:00 PM Matthew Wilcox wrote: > > I pushed it out to hkps://hkps.pool.sks-keyservers.net ... as I recall, > pgp.mit.edu is frequently not synchronised well with the other keyservers, > but I'm surprised that one of the sks-keyservers didn't have it. I got it now, so it was just some propagation delay or somethinig. Thanks, Linus
[GIT PULL] Please pull NFS client changes
Hi Linus, The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6: Linux 4.20-rc3 (2018-11-18 13:33:44 -0800) are available in the Git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.20-4 for you to fetch changes up to bb21ce0ad227b69ec0f83279297ee44232105d96: flexfiles: use per-mirror specified stateid for IO (2018-11-22 14:04:55 -0500) NFS client bugfixes for Linux 4.20 Highlights include: Bugfixes: - Fix a NFSv4 state manager deadlock when returning a delegation - NFSv4.2 copy do not allocate memory under the lock - flexfiles: Use the correct stateid for IO in the tightly coupled case Olga Kornievskaia (1): NFSv4.2 copy do not allocate memory under the lock Tigran Mkrtchyan (1): flexfiles: use per-mirror specified stateid for IO Trond Myklebust (1): NFSv4: Fix a NFSv4 state manager deadlock fs/nfs/callback_proc.c| 22 +++--- fs/nfs/flexfilelayout/flexfilelayout.c| 21 + fs/nfs/flexfilelayout/flexfilelayout.h| 4 fs/nfs/flexfilelayout/flexfilelayoutdev.c | 19 +++ fs/nfs/nfs42proc.c| 19 ++- fs/nfs/nfs4_fs.h | 2 ++ fs/nfs/nfs4state.c| 16 +++- 7 files changed, 66 insertions(+), 37 deletions(-) -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.mykleb...@hammerspace.com
[GIT PULL] Please pull NFS client changes
Hi Linus, The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6: Linux 4.20-rc3 (2018-11-18 13:33:44 -0800) are available in the Git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.20-4 for you to fetch changes up to bb21ce0ad227b69ec0f83279297ee44232105d96: flexfiles: use per-mirror specified stateid for IO (2018-11-22 14:04:55 -0500) NFS client bugfixes for Linux 4.20 Highlights include: Bugfixes: - Fix a NFSv4 state manager deadlock when returning a delegation - NFSv4.2 copy do not allocate memory under the lock - flexfiles: Use the correct stateid for IO in the tightly coupled case Olga Kornievskaia (1): NFSv4.2 copy do not allocate memory under the lock Tigran Mkrtchyan (1): flexfiles: use per-mirror specified stateid for IO Trond Myklebust (1): NFSv4: Fix a NFSv4 state manager deadlock fs/nfs/callback_proc.c| 22 +++--- fs/nfs/flexfilelayout/flexfilelayout.c| 21 + fs/nfs/flexfilelayout/flexfilelayout.h| 4 fs/nfs/flexfilelayout/flexfilelayoutdev.c | 19 +++ fs/nfs/nfs42proc.c| 19 ++- fs/nfs/nfs4_fs.h | 2 ++ fs/nfs/nfs4state.c| 16 +++- 7 files changed, 66 insertions(+), 37 deletions(-) -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.mykleb...@hammerspace.com
Re: [GIT PULL] XArray updates
On Sat, Nov 24, 2018 at 06:49:30PM -0800, Linus Torvalds wrote: > On Sat, Nov 24, 2018 at 6:38 PM Matthew Wilcox wrote: > > > > I generated a new key 5EC42E41545C1F5E and signed a new tag > > xarray-4.20-rc4 > > Hmm. Did you publicize it on any keyservers? I'm not finding the key > on pgp.mit.edu or on the sks-keyservers.net pool.. I pushed it out to hkps://hkps.pool.sks-keyservers.net ... as I recall, pgp.mit.edu is frequently not synchronised well with the other keyservers, but I'm surprised that one of the sks-keyservers didn't have it. http://pgpkeys.uk:11371/pks/lookup?search=0x5EC42E41545C1F5E=on=index sees it just fine. > > I've signed that key with my old DSA key 2218C81E8E7C03FF which has > > about 400 signatures on it, but I understand is not terribly trustable > > these days. > > .. but at least I can find that one. I think a 1024-bit DSA key may > be borderline in theory, but it's a lot better than no key at all. > >Linus
Re: [GIT PULL] XArray updates
On Sat, Nov 24, 2018 at 06:49:30PM -0800, Linus Torvalds wrote: > On Sat, Nov 24, 2018 at 6:38 PM Matthew Wilcox wrote: > > > > I generated a new key 5EC42E41545C1F5E and signed a new tag > > xarray-4.20-rc4 > > Hmm. Did you publicize it on any keyservers? I'm not finding the key > on pgp.mit.edu or on the sks-keyservers.net pool.. I pushed it out to hkps://hkps.pool.sks-keyservers.net ... as I recall, pgp.mit.edu is frequently not synchronised well with the other keyservers, but I'm surprised that one of the sks-keyservers didn't have it. http://pgpkeys.uk:11371/pks/lookup?search=0x5EC42E41545C1F5E=on=index sees it just fine. > > I've signed that key with my old DSA key 2218C81E8E7C03FF which has > > about 400 signatures on it, but I understand is not terribly trustable > > these days. > > .. but at least I can find that one. I think a 1024-bit DSA key may > be borderline in theory, but it's a lot better than no key at all. > >Linus
Re: [GIT PULL] XArray updates
On Sat, Nov 24, 2018 at 6:38 PM Matthew Wilcox wrote: > > I generated a new key 5EC42E41545C1F5E and signed a new tag > xarray-4.20-rc4 Hmm. Did you publicize it on any keyservers? I'm not finding the key on pgp.mit.edu or on the sks-keyservers.net pool.. > I've signed that key with my old DSA key 2218C81E8E7C03FF which has > about 400 signatures on it, but I understand is not terribly trustable > these days. .. but at least I can find that one. I think a 1024-bit DSA key may be borderline in theory, but it's a lot better than no key at all. Linus
Re: [GIT PULL] XArray updates
On Sat, Nov 24, 2018 at 6:38 PM Matthew Wilcox wrote: > > I generated a new key 5EC42E41545C1F5E and signed a new tag > xarray-4.20-rc4 Hmm. Did you publicize it on any keyservers? I'm not finding the key on pgp.mit.edu or on the sks-keyservers.net pool.. > I've signed that key with my old DSA key 2218C81E8E7C03FF which has > about 400 signatures on it, but I understand is not terribly trustable > these days. .. but at least I can find that one. I think a 1024-bit DSA key may be borderline in theory, but it's a lot better than no key at all. Linus
Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()
Hi Finn, Am 25.11.2018 um 14:15 schrieb Finn Thain: Maybe the timer interrupt has a sufficiently high priority and latency is low? Maybe cia_set_irq() is really expensive? I don't know the platform well enough so I'm inclined to revert. We can benchmark gettimeofday syscalls on elgar but is that hardware representative of other relevant models? I suppose the CIA is on the main board, so running with the slower clock speed that you'd see with a vanilla Amiga without 060 accelerator board. Ought to be representative enough? Adrian has a few other Amigas with different hardware base, so we might be able to get test coverage on more than one model. Cheers, Michael [1] https://github.com/mamedev/mame/commit/e2ed0490520f538c346c8bdaa9084bcbc43427cb [2] http://vice-emu.sourceforge.net/vice_9.html [3] https://www.commodore.ca/manuals/funet/cbm/documents/chipdata/cia6526.zip
Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()
Hi Finn, Am 25.11.2018 um 14:15 schrieb Finn Thain: Maybe the timer interrupt has a sufficiently high priority and latency is low? Maybe cia_set_irq() is really expensive? I don't know the platform well enough so I'm inclined to revert. We can benchmark gettimeofday syscalls on elgar but is that hardware representative of other relevant models? I suppose the CIA is on the main board, so running with the slower clock speed that you'd see with a vanilla Amiga without 060 accelerator board. Ought to be representative enough? Adrian has a few other Amigas with different hardware base, so we might be able to get test coverage on more than one model. Cheers, Michael [1] https://github.com/mamedev/mame/commit/e2ed0490520f538c346c8bdaa9084bcbc43427cb [2] http://vice-emu.sourceforge.net/vice_9.html [3] https://www.commodore.ca/manuals/funet/cbm/documents/chipdata/cia6526.zip
GET BACK TO ME URGENTLY
Dear Sir/Madam RE;$15,200,000.00 (FIFTEEN MILLION, TWO HUNDRED THOUSAND U.S DOLLARS) INVESTMENT PROJECT. I wish this proposal will not embarrass you as I had know previous correspondence with you. I am Mr. Ali Sabyani, a Syrian national. My objective is to establish a liable business relationship with you. I am Personal Assistant to Late General Daoud Rajha (Former Syria Defence Minister) who was killed in a mounted bomb explosion on Wednesday, 18th July, 2012 inside the Syrian National Security headquarters in Damascus which targeted Ministers of President Bashar Assad's regime who were meeting with Defense Officials. Whilst I am in a hideout since Wednesday, 18th July, 2012 trying to find my way out of Syria territory, from there I got a Muslim Africa brother who helped me. In the process of the ongoing war I lost my father and mother. In other to proof to you about the genuineity of my business, Please contact me on this email address:- aliss...@gmail.com Thanks. Yours Sincerely Mr. Ali Sabyani.
GET BACK TO ME URGENTLY
Dear Sir/Madam RE;$15,200,000.00 (FIFTEEN MILLION, TWO HUNDRED THOUSAND U.S DOLLARS) INVESTMENT PROJECT. I wish this proposal will not embarrass you as I had know previous correspondence with you. I am Mr. Ali Sabyani, a Syrian national. My objective is to establish a liable business relationship with you. I am Personal Assistant to Late General Daoud Rajha (Former Syria Defence Minister) who was killed in a mounted bomb explosion on Wednesday, 18th July, 2012 inside the Syrian National Security headquarters in Damascus which targeted Ministers of President Bashar Assad's regime who were meeting with Defense Officials. Whilst I am in a hideout since Wednesday, 18th July, 2012 trying to find my way out of Syria territory, from there I got a Muslim Africa brother who helped me. In the process of the ongoing war I lost my father and mother. In other to proof to you about the genuineity of my business, Please contact me on this email address:- aliss...@gmail.com Thanks. Yours Sincerely Mr. Ali Sabyani.
Re: [GIT PULL] XArray updates
On Sat, Nov 24, 2018 at 10:04:30AM -0800, Linus Torvalds wrote: > On Sat, Nov 24, 2018 at 9:32 AM Matthew Wilcox wrote: > > > > git://git.infradead.org/users/willy/linux-dax.git xarray > > Can you *please* make that a signed tag. Sure! I hadn't been paying attention to the signed tag side of things, so I hope I've done everything OK. I generated a new key 5EC42E41545C1F5E and signed a new tag xarray-4.20-rc4 I've signed that key with my old DSA key 2218C81E8E7C03FF which has about 400 signatures on it, but I understand is not terribly trustable these days.
Re: [GIT PULL] XArray updates
On Sat, Nov 24, 2018 at 10:04:30AM -0800, Linus Torvalds wrote: > On Sat, Nov 24, 2018 at 9:32 AM Matthew Wilcox wrote: > > > > git://git.infradead.org/users/willy/linux-dax.git xarray > > Can you *please* make that a signed tag. Sure! I hadn't been paying attention to the signed tag side of things, so I hope I've done everything OK. I generated a new key 5EC42E41545C1F5E and signed a new tag xarray-4.20-rc4 I've signed that key with my old DSA key 2218C81E8E7C03FF which has about 400 signatures on it, but I understand is not terribly trustable these days.
Re: [PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
On Sat, Nov 24, 2018 at 03:54:02PM -1000, Joey Pabalinas wrote: > On Sun, Nov 25, 2018 at 02:22:27AM +0100, Elvira Khabirova wrote: > > Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and > > PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message > > for the duration of syscall-stops. > > This way ptracers can distinguish syscall-enter-stops > > from syscall-exit-stops using PTRACE_GETEVENTMSG request. > > Is there an advantage to using two constants instead of a single > sys_exit bit (set/unset for syscall-exit-stop/syscall-enter-stop)? Given that without this patch the value returned by PTRACE_GETEVENTMSG during syscall stop is undefined, we need two different ptrace_message values that cannot be set by other ptrace events to enable reliable identification of syscall-enter-stop and syscall-exit-stop in userspace: if we make PTRACE_GETEVENTMSG return 0 or any other value routinely set by other ptrace events, it would be hard for userspace to find out whether the kernel implements new semantics or not. -- ldv signature.asc Description: PGP signature
Re: [PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
On Sat, Nov 24, 2018 at 03:54:02PM -1000, Joey Pabalinas wrote: > On Sun, Nov 25, 2018 at 02:22:27AM +0100, Elvira Khabirova wrote: > > Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and > > PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message > > for the duration of syscall-stops. > > This way ptracers can distinguish syscall-enter-stops > > from syscall-exit-stops using PTRACE_GETEVENTMSG request. > > Is there an advantage to using two constants instead of a single > sys_exit bit (set/unset for syscall-exit-stop/syscall-enter-stop)? Given that without this patch the value returned by PTRACE_GETEVENTMSG during syscall stop is undefined, we need two different ptrace_message values that cannot be set by other ptrace events to enable reliable identification of syscall-enter-stop and syscall-exit-stop in userspace: if we make PTRACE_GETEVENTMSG return 0 or any other value routinely set by other ptrace events, it would be hard for userspace to find out whether the kernel implements new semantics or not. -- ldv signature.asc Description: PGP signature
Re: [PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
On Sun, Nov 25, 2018 at 02:22:27AM +0100, Elvira Khabirova wrote: > Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and > PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message > for the duration of syscall-stops. > This way ptracers can distinguish syscall-enter-stops > from syscall-exit-stops using PTRACE_GETEVENTMSG request. Is there an advantage to using two constants instead of a single sys_exit bit (set/unset for syscall-exit-stop/syscall-enter-stop)? -- Cheers, Joey Pabalinas signature.asc Description: PGP signature
Re: [PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
On Sun, Nov 25, 2018 at 02:22:27AM +0100, Elvira Khabirova wrote: > Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and > PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message > for the duration of syscall-stops. > This way ptracers can distinguish syscall-enter-stops > from syscall-exit-stops using PTRACE_GETEVENTMSG request. Is there an advantage to using two constants instead of a single sys_exit bit (set/unset for syscall-exit-stop/syscall-enter-stop)? -- Cheers, Joey Pabalinas signature.asc Description: PGP signature
[PATCH] freevxfs: set bp to NULL after dropping its reference in loop
The function vxfs_bmap_indir calls brelse(bh) in the loop and tries to
start the next iteration. However, if it happens to break the loop,
brelse(bp) will be called again. Resulting in a potential double free
bug. This patch assigns NULL to bh after dropping its reference in the
loop body.
Signed-off-by: Pan Bian
---
fs/freevxfs/vxfs_bmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/freevxfs/vxfs_bmap.c b/fs/freevxfs/vxfs_bmap.c
index 1fd41cf..136e5d1 100644
--- a/fs/freevxfs/vxfs_bmap.c
+++ b/fs/freevxfs/vxfs_bmap.c
@@ -150,6 +150,7 @@ vxfs_bmap_indir(struct inode *ip, long indir, int size,
long block)
if (block < off) {
brelse(bp);
+ bp = NULL;
continue;
}
@@ -186,6 +187,7 @@ vxfs_bmap_indir(struct inode *ip, long indir, int size,
long block)
BUG();
}
brelse(bp);
+ bp = NULL;
}
fail:
--
2.7.4
[PATCH] freevxfs: set bp to NULL after dropping its reference in loop
The function vxfs_bmap_indir calls brelse(bh) in the loop and tries to
start the next iteration. However, if it happens to break the loop,
brelse(bp) will be called again. Resulting in a potential double free
bug. This patch assigns NULL to bh after dropping its reference in the
loop body.
Signed-off-by: Pan Bian
---
fs/freevxfs/vxfs_bmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/freevxfs/vxfs_bmap.c b/fs/freevxfs/vxfs_bmap.c
index 1fd41cf..136e5d1 100644
--- a/fs/freevxfs/vxfs_bmap.c
+++ b/fs/freevxfs/vxfs_bmap.c
@@ -150,6 +150,7 @@ vxfs_bmap_indir(struct inode *ip, long indir, int size,
long block)
if (block < off) {
brelse(bp);
+ bp = NULL;
continue;
}
@@ -186,6 +187,7 @@ vxfs_bmap_indir(struct inode *ip, long indir, int size,
long block)
BUG();
}
brelse(bp);
+ bp = NULL;
}
fail:
--
2.7.4
Re: Mrs.Amelia George
-- Dear Sir, My name is Mrs.Amelia George I am 72 years old, I am a dying woman who have decided to donate what I have to you/churches/ motherless babies/less privileged/widows. I have been touched by God to donate from what I have inherited from my late husband to you for good work of God. Please kindly let me know if you can assist me receive my funds and distribute to charity of your choice the sum of $25million United state Dollars. I am willing to give you 20% for your time and effort. Your sister in Christ, Mrs.Amelia George Email:dr.amelia.geor...@yandex.ru
Re: Mrs.Amelia George
-- Dear Sir, My name is Mrs.Amelia George I am 72 years old, I am a dying woman who have decided to donate what I have to you/churches/ motherless babies/less privileged/widows. I have been touched by God to donate from what I have inherited from my late husband to you for good work of God. Please kindly let me know if you can assist me receive my funds and distribute to charity of your choice the sum of $25million United state Dollars. I am willing to give you 20% for your time and effort. Your sister in Christ, Mrs.Amelia George Email:dr.amelia.geor...@yandex.ru
[RFC PATCH RESEND v3 3/3] ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
Extend PTRACE_GET_SYSCALL_INFO to support PTRACE_EVENT_SECCOMP stops.
The information returned is the same as for syscall-enter-stops.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/linux/ptrace.h| 1 +
include/linux/sched.h | 1 +
include/linux/tracehook.h | 1 +
kernel/ptrace.c | 7 +--
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 6c2ffed907f5..a993d0fde865 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -166,6 +166,7 @@ static inline void ptrace_event(int event, unsigned long
message)
{
if (unlikely(ptrace_event_enabled(current, event))) {
current->ptrace_message = message;
+ current->ptrace_event = event;
ptrace_notify((event << 8) | SIGTRAP);
} else if (event == PTRACE_EVENT_EXEC) {
/* legacy EXEC report via SIGTRAP */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a51c13c2b1a0..86215fb654d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -964,6 +964,7 @@ struct task_struct {
/* Ptrace state: */
unsigned long ptrace_message;
+ int ptrace_event;
kernel_siginfo_t*last_siginfo;
struct task_io_accounting ioac;
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 633a83fe7051..5d2e5aa07a5c 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -66,6 +66,7 @@ static inline int ptrace_report_syscall(struct pt_regs *regs,
return 0;
current->ptrace_message = message;
+ current->ptrace_event = 0;
ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
/*
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 92c47cd5ad84..74a37e74c7f1 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -904,7 +904,9 @@ static int ptrace_get_syscall(struct task_struct *child,
unsigned long actual_size;
unsigned long write_size;
- if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) {
+ if ((child->ptrace_event == 0 &&
+child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) ||
+ child->ptrace_event == PTRACE_EVENT_SECCOMP) {
int i;
info.op = PTRACE_SYSCALL_INFO_ENTRY;
@@ -917,7 +919,8 @@ static int ptrace_get_syscall(struct task_struct *child,
for (i = 0; i < ARRAY_SIZE(args); i++)
info.entry.args[i] = args[i];
actual_size = offsetofend(struct ptrace_syscall_info, entry);
- } else if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
+ } else if (child->ptrace_event == 0 &&
+ child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
info.op = PTRACE_SYSCALL_INFO_EXIT;
info.arch = syscall_get_arch(child);
info.exit.rval = syscall_get_error(child, regs);
--
2.19.1
[RFC PATCH RESEND v3 3/3] ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
Extend PTRACE_GET_SYSCALL_INFO to support PTRACE_EVENT_SECCOMP stops.
The information returned is the same as for syscall-enter-stops.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/linux/ptrace.h| 1 +
include/linux/sched.h | 1 +
include/linux/tracehook.h | 1 +
kernel/ptrace.c | 7 +--
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 6c2ffed907f5..a993d0fde865 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -166,6 +166,7 @@ static inline void ptrace_event(int event, unsigned long
message)
{
if (unlikely(ptrace_event_enabled(current, event))) {
current->ptrace_message = message;
+ current->ptrace_event = event;
ptrace_notify((event << 8) | SIGTRAP);
} else if (event == PTRACE_EVENT_EXEC) {
/* legacy EXEC report via SIGTRAP */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a51c13c2b1a0..86215fb654d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -964,6 +964,7 @@ struct task_struct {
/* Ptrace state: */
unsigned long ptrace_message;
+ int ptrace_event;
kernel_siginfo_t*last_siginfo;
struct task_io_accounting ioac;
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 633a83fe7051..5d2e5aa07a5c 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -66,6 +66,7 @@ static inline int ptrace_report_syscall(struct pt_regs *regs,
return 0;
current->ptrace_message = message;
+ current->ptrace_event = 0;
ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
/*
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 92c47cd5ad84..74a37e74c7f1 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -904,7 +904,9 @@ static int ptrace_get_syscall(struct task_struct *child,
unsigned long actual_size;
unsigned long write_size;
- if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) {
+ if ((child->ptrace_event == 0 &&
+child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) ||
+ child->ptrace_event == PTRACE_EVENT_SECCOMP) {
int i;
info.op = PTRACE_SYSCALL_INFO_ENTRY;
@@ -917,7 +919,8 @@ static int ptrace_get_syscall(struct task_struct *child,
for (i = 0; i < ARRAY_SIZE(args); i++)
info.entry.args[i] = args[i];
actual_size = offsetofend(struct ptrace_syscall_info, entry);
- } else if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
+ } else if (child->ptrace_event == 0 &&
+ child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
info.op = PTRACE_SYSCALL_INFO_EXIT;
info.arch = syscall_get_arch(child);
info.exit.rval = syscall_get_error(child, regs);
--
2.19.1
[PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and
PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message
for the duration of syscall-stops.
This way ptracers can distinguish syscall-enter-stops
from syscall-exit-stops using PTRACE_GETEVENTMSG request.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/linux/tracehook.h | 9 ++---
include/uapi/linux/ptrace.h | 10 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 40b0b4c1bf7b..633a83fe7051 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -57,13 +57,15 @@ struct linux_binprm;
/*
* ptrace report for syscall entry and exit looks identical.
*/
-static inline int ptrace_report_syscall(struct pt_regs *regs)
+static inline int ptrace_report_syscall(struct pt_regs *regs,
+ unsigned long message)
{
int ptrace = current->ptrace;
if (!(ptrace & PT_PTRACED))
return 0;
+ current->ptrace_message = message;
ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
/*
@@ -76,6 +78,7 @@ static inline int ptrace_report_syscall(struct pt_regs *regs)
current->exit_code = 0;
}
+ current->ptrace_message = 0;
return fatal_signal_pending(current);
}
@@ -101,7 +104,7 @@ static inline int ptrace_report_syscall(struct pt_regs
*regs)
static inline __must_check int tracehook_report_syscall_entry(
struct pt_regs *regs)
{
- return ptrace_report_syscall(regs);
+ return ptrace_report_syscall(regs, PTRACE_EVENTMSG_SYSCALL_ENTRY);
}
/**
@@ -126,7 +129,7 @@ static inline void tracehook_report_syscall_exit(struct
pt_regs *regs, int step)
if (step)
user_single_step_report(regs);
else
- ptrace_report_syscall(regs);
+ ptrace_report_syscall(regs, PTRACE_EVENTMSG_SYSCALL_EXIT);
}
/**
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index d5a1b8a492b9..cb138902d042 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -104,6 +104,16 @@ struct seccomp_metadata {
#define PTRACE_O_MASK (\
0x00ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
+/*
+ * These values are stored in task->ptrace_message by
tracehook_report_syscall_*
+ * to describe current syscall-stop.
+ *
+ * Values for these constants are chosen so that they do not appear
+ * in task->ptrace_message by other means.
+ */
+#define PTRACE_EVENTMSG_SYSCALL_ENTRY 0x8000U
+#define PTRACE_EVENTMSG_SYSCALL_EXIT 0x9000U
+
#include
--
2.19.1
[PATCH RESEND v3 2/3] ptrace: add PTRACE_GET_SYSCALL_INFO request
PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
the tracee is blocked in. The request succeeds when the tracee is in a
syscall-enter-stop or syscall-exit-stop, and fails with -EINVAL otherwise.
A subsequent change may extend PTRACE_GET_SYSCALL_INFO for the case
of PTRACE_EVENT_SECCOMP stop.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls. Some examples include:
* The notorious int-0x80-from-64-bit-task issue. See [1] for details.
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has no reliable means to find out that the syscall was, in fact,
a compat syscall, and misidentifies it.
* Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
Common practice is to keep track of the sequence of ptrace-stops in order
not to mix the two syscall-stops up. But it is not as simple as it looks;
for example, strace had a (just recently fixed) long-standing bug where
attaching strace to a tracee that is performing the execve system call
led to the tracer identifying the following syscall-exit-stop as
syscall-enter-stop, which messed up all the state tracking.
* Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
and process_vm_readv become unavailable when the process dumpable flag
is cleared. On such architectures as ia64 this results in all syscall
arguments being unavailable.
Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee. For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.
ptrace(2) man page:
long ptrace(enum __ptrace_request request, pid_t pid,
void *addr, void *data);
...
PTRACE_GET_SYSCALL_INFO
Retrieve information about the syscall that caused the stop.
The information is placed into the buffer pointed by "data"
argument, which should be a pointer to a buffer of type
"struct ptrace_syscall_info".
The "addr" argument contains the size of the buffer pointed to
by "data" (i.e., sizeof(struct ptrace_syscall_info)).
The return value contains the number of bytes available
to be written by the kernel.
If the size of data to be written by the kernel exceeds the size
specified by "addr" argument, the output is truncated.
This operation fails with EINVAL if the tracee is not
in a syscall-enter-stop, a syscall-exit-stop, or
a PTRACE_EVENT_SECCOMP stop.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/uapi/linux/ptrace.h | 24 ++
kernel/ptrace.c | 50 +
2 files changed, 74 insertions(+)
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index cb138902d042..49b0b1b41943 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -73,6 +73,30 @@ struct seccomp_metadata {
__u64 flags;/* Output: filter's flags */
};
+#define PTRACE_GET_SYSCALL_INFO0x420f
+#define PTRACE_SYSCALL_INFO_ENTRY 0
+#define PTRACE_SYSCALL_INFO_EXIT 1
+
+struct ptrace_syscall_info {
+ __u8 op;/* PTRACE_SYSCALL_INFO_* */
+ __u8 __pad0[3];
+ __u32 arch;
+ union {
+ struct {
+ __u64 nr;
+ __u64 instruction_pointer;
+ __u64 stack_pointer;
+ __u64 frame_pointer;
+ __u64 args[6];
+ } entry;
+ struct {
+ __s64 rval;
+ __u8 is_error;
+ __u8 __pad1[7];
+ } exit;
+ };
+};
+
/* Read signals from a shared (process wide) queue */
#define PTRACE_PEEKSIGINFO_SHARED (1 << 0)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 80b34dffdfb9..92c47cd5ad84 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -30,6 +30,10 @@
#include
#include
+#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
+#include/* For syscall_get_* */
+#endif
+
/*
* Access another process' address space via ptrace.
* Source/target buffer must be kernel space,
@@ -890,6 +894,46 @@ static int ptrace_regset(struct task_struct *task, int
req, unsigned int type,
EXPORT_SYMBOL_GPL(task_user_regset_view);
#endif
+#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
+static int ptrace_get_syscall(struct task_struct *child,
+ unsigned long user_size, void __user *datavp)
+{
+ struct ptrace_syscall_info info;
+ struct pt_regs *regs = task_pt_regs(child);
+ unsigned long args[ARRAY_SIZE(info.entry.args)];
+ unsigned long actual_size;
+ unsigned long write_size;
+
+ if
[PATCH RESEND v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and
PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message
for the duration of syscall-stops.
This way ptracers can distinguish syscall-enter-stops
from syscall-exit-stops using PTRACE_GETEVENTMSG request.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/linux/tracehook.h | 9 ++---
include/uapi/linux/ptrace.h | 10 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 40b0b4c1bf7b..633a83fe7051 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -57,13 +57,15 @@ struct linux_binprm;
/*
* ptrace report for syscall entry and exit looks identical.
*/
-static inline int ptrace_report_syscall(struct pt_regs *regs)
+static inline int ptrace_report_syscall(struct pt_regs *regs,
+ unsigned long message)
{
int ptrace = current->ptrace;
if (!(ptrace & PT_PTRACED))
return 0;
+ current->ptrace_message = message;
ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
/*
@@ -76,6 +78,7 @@ static inline int ptrace_report_syscall(struct pt_regs *regs)
current->exit_code = 0;
}
+ current->ptrace_message = 0;
return fatal_signal_pending(current);
}
@@ -101,7 +104,7 @@ static inline int ptrace_report_syscall(struct pt_regs
*regs)
static inline __must_check int tracehook_report_syscall_entry(
struct pt_regs *regs)
{
- return ptrace_report_syscall(regs);
+ return ptrace_report_syscall(regs, PTRACE_EVENTMSG_SYSCALL_ENTRY);
}
/**
@@ -126,7 +129,7 @@ static inline void tracehook_report_syscall_exit(struct
pt_regs *regs, int step)
if (step)
user_single_step_report(regs);
else
- ptrace_report_syscall(regs);
+ ptrace_report_syscall(regs, PTRACE_EVENTMSG_SYSCALL_EXIT);
}
/**
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index d5a1b8a492b9..cb138902d042 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -104,6 +104,16 @@ struct seccomp_metadata {
#define PTRACE_O_MASK (\
0x00ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
+/*
+ * These values are stored in task->ptrace_message by
tracehook_report_syscall_*
+ * to describe current syscall-stop.
+ *
+ * Values for these constants are chosen so that they do not appear
+ * in task->ptrace_message by other means.
+ */
+#define PTRACE_EVENTMSG_SYSCALL_ENTRY 0x8000U
+#define PTRACE_EVENTMSG_SYSCALL_EXIT 0x9000U
+
#include
--
2.19.1
[PATCH RESEND v3 2/3] ptrace: add PTRACE_GET_SYSCALL_INFO request
PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
the tracee is blocked in. The request succeeds when the tracee is in a
syscall-enter-stop or syscall-exit-stop, and fails with -EINVAL otherwise.
A subsequent change may extend PTRACE_GET_SYSCALL_INFO for the case
of PTRACE_EVENT_SECCOMP stop.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls. Some examples include:
* The notorious int-0x80-from-64-bit-task issue. See [1] for details.
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has no reliable means to find out that the syscall was, in fact,
a compat syscall, and misidentifies it.
* Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
Common practice is to keep track of the sequence of ptrace-stops in order
not to mix the two syscall-stops up. But it is not as simple as it looks;
for example, strace had a (just recently fixed) long-standing bug where
attaching strace to a tracee that is performing the execve system call
led to the tracer identifying the following syscall-exit-stop as
syscall-enter-stop, which messed up all the state tracking.
* Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
and process_vm_readv become unavailable when the process dumpable flag
is cleared. On such architectures as ia64 this results in all syscall
arguments being unavailable.
Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee. For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.
ptrace(2) man page:
long ptrace(enum __ptrace_request request, pid_t pid,
void *addr, void *data);
...
PTRACE_GET_SYSCALL_INFO
Retrieve information about the syscall that caused the stop.
The information is placed into the buffer pointed by "data"
argument, which should be a pointer to a buffer of type
"struct ptrace_syscall_info".
The "addr" argument contains the size of the buffer pointed to
by "data" (i.e., sizeof(struct ptrace_syscall_info)).
The return value contains the number of bytes available
to be written by the kernel.
If the size of data to be written by the kernel exceeds the size
specified by "addr" argument, the output is truncated.
This operation fails with EINVAL if the tracee is not
in a syscall-enter-stop, a syscall-exit-stop, or
a PTRACE_EVENT_SECCOMP stop.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/uapi/linux/ptrace.h | 24 ++
kernel/ptrace.c | 50 +
2 files changed, 74 insertions(+)
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index cb138902d042..49b0b1b41943 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -73,6 +73,30 @@ struct seccomp_metadata {
__u64 flags;/* Output: filter's flags */
};
+#define PTRACE_GET_SYSCALL_INFO0x420f
+#define PTRACE_SYSCALL_INFO_ENTRY 0
+#define PTRACE_SYSCALL_INFO_EXIT 1
+
+struct ptrace_syscall_info {
+ __u8 op;/* PTRACE_SYSCALL_INFO_* */
+ __u8 __pad0[3];
+ __u32 arch;
+ union {
+ struct {
+ __u64 nr;
+ __u64 instruction_pointer;
+ __u64 stack_pointer;
+ __u64 frame_pointer;
+ __u64 args[6];
+ } entry;
+ struct {
+ __s64 rval;
+ __u8 is_error;
+ __u8 __pad1[7];
+ } exit;
+ };
+};
+
/* Read signals from a shared (process wide) queue */
#define PTRACE_PEEKSIGINFO_SHARED (1 << 0)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 80b34dffdfb9..92c47cd5ad84 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -30,6 +30,10 @@
#include
#include
+#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
+#include/* For syscall_get_* */
+#endif
+
/*
* Access another process' address space via ptrace.
* Source/target buffer must be kernel space,
@@ -890,6 +894,46 @@ static int ptrace_regset(struct task_struct *task, int
req, unsigned int type,
EXPORT_SYMBOL_GPL(task_user_regset_view);
#endif
+#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
+static int ptrace_get_syscall(struct task_struct *child,
+ unsigned long user_size, void __user *datavp)
+{
+ struct ptrace_syscall_info info;
+ struct pt_regs *regs = task_pt_regs(child);
+ unsigned long args[ARRAY_SIZE(info.entry.args)];
+ unsigned long actual_size;
+ unsigned long write_size;
+
+ if
[PATCH RESEND v3 0/3] ptrace: add PTRACE_GET_SYSCALL_INFO request
Resent with linux-api@ Cc'ed.
PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
the tracee is blocked in. The request succeeds when the tracee is in a
syscall-enter-stop, syscall-exit-stop or PTRACE_EVENT_SECCOMP stop,
and fails with -EINVAL otherwise.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls. Some examples include:
* The notorious int-0x80-from-64-bit-task issue. See [1] for details.
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has no reliable means to find out that the syscall was, in fact,
a compat syscall, and misidentifies it.
* Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
Common practice is to keep track of the sequence of ptrace-stops in order
not to mix the two syscall-stops up. But it is not as simple as it looks;
for example, strace had a (just recently fixed) long-standing bug where
attaching strace to a tracee that is performing the execve system call
led to the tracer identifying the following syscall-exit-stop as
syscall-enter-stop, which messed up all the state tracking.
* Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
and process_vm_readv become unavailable when the process dumpable flag
is cleared. On such architectures as ia64 this results in all syscall
arguments being unavailable.
Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee. For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.
PTRACE_GET_SYSCALL_INFO returns the following structure:
struct ptrace_syscall_info {
__u8 op;/* PTRACE_SYSCALL_INFO_* */
__u8 __pad0[3];
__u32 arch;
union {
struct {
__u64 nr;
__u64 instruction_pointer;
__u64 stack_pointer;
__u64 frame_pointer;
__u64 args[6];
} entry;
struct {
__s64 rval;
__u8 is_error;
__u8 __pad1[7];
} exit;
};
};
The structure was chosen according to [2], except for the following
changes:
* arch is returned unconditionally to aid with tracing system calls such as
execve();
* the type of nr field was changed from int to __u64 because syscall
numbers are, as a practical matter, 64 bits;
* stack_pointer and frame_pointer fields were added along with
instruction_pointer field since they are readily available and can save
the tracer from extra PTRACE_GETREGSET calls;
* a boolean is_error field was added along with rval field, this way
the tracer can more reliably distinguish a return value
from an error value.
This changeset should be applied on top of [3] and [4].
[1]
https://lore.kernel.org/lkml/ca+55afzcsvmddj9lh_gdbz1ozhyem6zrgpbdajnywm2lf_e...@mail.gmail.com/
[2]
https://lore.kernel.org/lkml/caobl_7gm0n80n7j_dfw_eqyflyzq+sf4y2avsccv88tb3aw...@mail.gmail.com/
[3] https://lore.kernel.org/lkml/20181119210139.ga8...@altlinux.org/
[4] https://lore.kernel.org/lkml/20181120001128.ga11...@altlinux.org/
v3: Split into three changes.
Change struct ptrace_syscall_info.
Support PTRACE_EVENT_SECCOMP by adding ptrace_event to task_struct.
Add proper defines for ptrace_syscall_info.op values.
Rename PT_SYSCALL_IS_ENTERING and PT_SYSCALL_IS_EXITING to
PTRACE_EVENTMSG_SYSCALL_ENTRY and PTRACE_EVENTMSG_SYSCALL_EXIT and move
them to uapi.
Elvira Khabirova (3):
ptrace: pass type of a syscall-stop in ptrace_message
ptrace: add PTRACE_GET_SYSCALL_INFO request
ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
include/linux/ptrace.h | 1 +
include/linux/sched.h | 1 +
include/linux/tracehook.h | 10 ---
include/uapi/linux/ptrace.h | 34
kernel/ptrace.c | 53 +
5 files changed, 96 insertions(+), 3 deletions(-)
--
2.19.1
[PATCH RESEND v3 0/3] ptrace: add PTRACE_GET_SYSCALL_INFO request
Resent with linux-api@ Cc'ed.
PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
the tracee is blocked in. The request succeeds when the tracee is in a
syscall-enter-stop, syscall-exit-stop or PTRACE_EVENT_SECCOMP stop,
and fails with -EINVAL otherwise.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls. Some examples include:
* The notorious int-0x80-from-64-bit-task issue. See [1] for details.
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has no reliable means to find out that the syscall was, in fact,
a compat syscall, and misidentifies it.
* Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
Common practice is to keep track of the sequence of ptrace-stops in order
not to mix the two syscall-stops up. But it is not as simple as it looks;
for example, strace had a (just recently fixed) long-standing bug where
attaching strace to a tracee that is performing the execve system call
led to the tracer identifying the following syscall-exit-stop as
syscall-enter-stop, which messed up all the state tracking.
* Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
and process_vm_readv become unavailable when the process dumpable flag
is cleared. On such architectures as ia64 this results in all syscall
arguments being unavailable.
Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee. For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.
PTRACE_GET_SYSCALL_INFO returns the following structure:
struct ptrace_syscall_info {
__u8 op;/* PTRACE_SYSCALL_INFO_* */
__u8 __pad0[3];
__u32 arch;
union {
struct {
__u64 nr;
__u64 instruction_pointer;
__u64 stack_pointer;
__u64 frame_pointer;
__u64 args[6];
} entry;
struct {
__s64 rval;
__u8 is_error;
__u8 __pad1[7];
} exit;
};
};
The structure was chosen according to [2], except for the following
changes:
* arch is returned unconditionally to aid with tracing system calls such as
execve();
* the type of nr field was changed from int to __u64 because syscall
numbers are, as a practical matter, 64 bits;
* stack_pointer and frame_pointer fields were added along with
instruction_pointer field since they are readily available and can save
the tracer from extra PTRACE_GETREGSET calls;
* a boolean is_error field was added along with rval field, this way
the tracer can more reliably distinguish a return value
from an error value.
This changeset should be applied on top of [3] and [4].
[1]
https://lore.kernel.org/lkml/ca+55afzcsvmddj9lh_gdbz1ozhyem6zrgpbdajnywm2lf_e...@mail.gmail.com/
[2]
https://lore.kernel.org/lkml/caobl_7gm0n80n7j_dfw_eqyflyzq+sf4y2avsccv88tb3aw...@mail.gmail.com/
[3] https://lore.kernel.org/lkml/20181119210139.ga8...@altlinux.org/
[4] https://lore.kernel.org/lkml/20181120001128.ga11...@altlinux.org/
v3: Split into three changes.
Change struct ptrace_syscall_info.
Support PTRACE_EVENT_SECCOMP by adding ptrace_event to task_struct.
Add proper defines for ptrace_syscall_info.op values.
Rename PT_SYSCALL_IS_ENTERING and PT_SYSCALL_IS_EXITING to
PTRACE_EVENTMSG_SYSCALL_ENTRY and PTRACE_EVENTMSG_SYSCALL_EXIT and move
them to uapi.
Elvira Khabirova (3):
ptrace: pass type of a syscall-stop in ptrace_message
ptrace: add PTRACE_GET_SYSCALL_INFO request
ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
include/linux/ptrace.h | 1 +
include/linux/sched.h | 1 +
include/linux/tracehook.h | 10 ---
include/uapi/linux/ptrace.h | 34
kernel/ptrace.c | 53 +
5 files changed, 96 insertions(+), 3 deletions(-)
--
2.19.1
Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()
On Wed, 21 Nov 2018, I wrote: > On Wed, 21 Nov 2018, Geert Uytterhoeven wrote: > > > > This suggests that either 0 or N (the latched value) would result > > > from a read from the counter immediately following an interrupt. Who > > > can say which? Just have to try it. The answer should allow us to > > > avoid the risk of a clocksource that jumps forwards and backwards. > > > > The code in amiga_gettimeoffset() does: > > > > ticks = hi << 8 | lo; > > > > if (ticks > jiffy_ticks / 2) > > /* check for pending interrupt */ > > if (cia_set_irq(_base, 0) & CIA_ICR_TA) > > offset = 1; > > > > That _suggests_ that there's no interrupt when ticks == 0. > > But look what happens next: > > > ticks = jiffy_ticks - ticks; > > > > ticks = (1 * ticks) / jiffy_ticks; > > > > return (ticks + offset) * 1000; > > If (hi << 8 | lo) == 0, and you set offset = 1, then the return > value would be maximal. > > Let's immediately call this function again. This time (hi << 8 | lo) == > N. Let's add the offset again. I'm afraid the clock just jumped > backwards. > > So the logic you quoted has a rationale which is unrelated to the > question. > I've learned that emulators like MAME [1] and VICE [2] have used a reverse-engineered description of the CIA called "A Software Model of the CIA6526" by Wolfgang Lorenz and an accompanying test suite [3]. That document says, "When the counter has reached zero, it is reloaded from the latch as soon as there is another clock waiting in the pipeline. In phase 2 mode, this is always the case. This explains why you are reading zeros in cascaded mode only (2-2-2-1-1-1-0-0-2) but not in phase 2 mode (2-1-2)." I think this is a good argument that a zero count will never be observed by reading the counter register. Hence, it seems that this conditional in the v3 patch, if (msb > 0) is redundant and should be removed. It could be reverted to, if (ticks > jiffy_ticks / 2) which is intended to reduce the number of calls to cia_set_irq() but assumes low interrupt latency (below 5 ms). Maybe the timer interrupt has a sufficiently high priority and latency is low? Maybe cia_set_irq() is really expensive? I don't know the platform well enough so I'm inclined to revert. We can benchmark gettimeofday syscalls on elgar but is that hardware representative of other relevant models? [1] https://github.com/mamedev/mame/commit/e2ed0490520f538c346c8bdaa9084bcbc43427cb [2] http://vice-emu.sourceforge.net/vice_9.html [3] https://www.commodore.ca/manuals/funet/cbm/documents/chipdata/cia6526.zip --
Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()
On Wed, 21 Nov 2018, I wrote: > On Wed, 21 Nov 2018, Geert Uytterhoeven wrote: > > > > This suggests that either 0 or N (the latched value) would result > > > from a read from the counter immediately following an interrupt. Who > > > can say which? Just have to try it. The answer should allow us to > > > avoid the risk of a clocksource that jumps forwards and backwards. > > > > The code in amiga_gettimeoffset() does: > > > > ticks = hi << 8 | lo; > > > > if (ticks > jiffy_ticks / 2) > > /* check for pending interrupt */ > > if (cia_set_irq(_base, 0) & CIA_ICR_TA) > > offset = 1; > > > > That _suggests_ that there's no interrupt when ticks == 0. > > But look what happens next: > > > ticks = jiffy_ticks - ticks; > > > > ticks = (1 * ticks) / jiffy_ticks; > > > > return (ticks + offset) * 1000; > > If (hi << 8 | lo) == 0, and you set offset = 1, then the return > value would be maximal. > > Let's immediately call this function again. This time (hi << 8 | lo) == > N. Let's add the offset again. I'm afraid the clock just jumped > backwards. > > So the logic you quoted has a rationale which is unrelated to the > question. > I've learned that emulators like MAME [1] and VICE [2] have used a reverse-engineered description of the CIA called "A Software Model of the CIA6526" by Wolfgang Lorenz and an accompanying test suite [3]. That document says, "When the counter has reached zero, it is reloaded from the latch as soon as there is another clock waiting in the pipeline. In phase 2 mode, this is always the case. This explains why you are reading zeros in cascaded mode only (2-2-2-1-1-1-0-0-2) but not in phase 2 mode (2-1-2)." I think this is a good argument that a zero count will never be observed by reading the counter register. Hence, it seems that this conditional in the v3 patch, if (msb > 0) is redundant and should be removed. It could be reverted to, if (ticks > jiffy_ticks / 2) which is intended to reduce the number of calls to cia_set_irq() but assumes low interrupt latency (below 5 ms). Maybe the timer interrupt has a sufficiently high priority and latency is low? Maybe cia_set_irq() is really expensive? I don't know the platform well enough so I'm inclined to revert. We can benchmark gettimeofday syscalls on elgar but is that hardware representative of other relevant models? [1] https://github.com/mamedev/mame/commit/e2ed0490520f538c346c8bdaa9084bcbc43427cb [2] http://vice-emu.sourceforge.net/vice_9.html [3] https://www.commodore.ca/manuals/funet/cbm/documents/chipdata/cia6526.zip --
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
* Tony Lindgren [181125 01:07]: > * Russell King - ARM Linux [181124 20:10]: > > On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote: > > > Hi, > > > > > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote: > > > > On 22/11/2018 17.12, Russell King - ARM Linux wrote: > > > > > I'm also not sure about this: > > > > > > > > > > if (cpu_is_omap15xx()) > > > > > end++; > > > > > > > > > > in dma_dest_len() - is that missing from the omap-dma driver? It > > > > > looks > > > > > like a work-around for some problem on OMAP15xx, but I can't make > > > > > sense > > > > > about why it's in the UDC driver rather than the legacy DMA driver. > > > > > > > > afaik no other legacy drivers were doing similar thing, this must be > > > > something which is needed for the omap_udc driver to fix up something? > > > > > > Here's the patch that added it: > > > https://marc.info/?l=linux-omap=119634396324221=2 > > > > > > "Make DMA-OUT behave on the 1510 ... the 1510 CPC register was just > > > off-by-one with respect to the 1611 CDAC" > > > > ... which suggests that's a problem with the CPC register itself, and > > we should fix that in the DMAengine driver rather than the USB gadget > > driver. > > > > Tony, any input on this? > > Yeah that sounds like some hardware work-around for 15xx as described > in the DMA_DEST_LAST macro reading CSAC on 15xx instead of CDAC. Seems > like it should be done in the dmaengine driver.. My guess is that other > dma users never needed to read CSAC register? And it looks like for 15xx we have CPC and CSAC both at offset 0x18 in arch/arm/mach-omap1/dma.c, seems like the dma driver is missing handling for the CPC register that's there only for 15xx. Regards, Tony
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
* Tony Lindgren [181125 01:07]: > * Russell King - ARM Linux [181124 20:10]: > > On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote: > > > Hi, > > > > > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote: > > > > On 22/11/2018 17.12, Russell King - ARM Linux wrote: > > > > > I'm also not sure about this: > > > > > > > > > > if (cpu_is_omap15xx()) > > > > > end++; > > > > > > > > > > in dma_dest_len() - is that missing from the omap-dma driver? It > > > > > looks > > > > > like a work-around for some problem on OMAP15xx, but I can't make > > > > > sense > > > > > about why it's in the UDC driver rather than the legacy DMA driver. > > > > > > > > afaik no other legacy drivers were doing similar thing, this must be > > > > something which is needed for the omap_udc driver to fix up something? > > > > > > Here's the patch that added it: > > > https://marc.info/?l=linux-omap=119634396324221=2 > > > > > > "Make DMA-OUT behave on the 1510 ... the 1510 CPC register was just > > > off-by-one with respect to the 1611 CDAC" > > > > ... which suggests that's a problem with the CPC register itself, and > > we should fix that in the DMAengine driver rather than the USB gadget > > driver. > > > > Tony, any input on this? > > Yeah that sounds like some hardware work-around for 15xx as described > in the DMA_DEST_LAST macro reading CSAC on 15xx instead of CDAC. Seems > like it should be done in the dmaengine driver.. My guess is that other > dma users never needed to read CSAC register? And it looks like for 15xx we have CPC and CSAC both at offset 0x18 in arch/arm/mach-omap1/dma.c, seems like the dma driver is missing handling for the CPC register that's there only for 15xx. Regards, Tony
[RFC PATCH v3 3/3] ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
Extend PTRACE_GET_SYSCALL_INFO to support PTRACE_EVENT_SECCOMP stops.
The information returned is the same as for syscall-enter-stops.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/linux/ptrace.h| 1 +
include/linux/sched.h | 1 +
include/linux/tracehook.h | 1 +
kernel/ptrace.c | 7 +--
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 6c2ffed907f5..a993d0fde865 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -166,6 +166,7 @@ static inline void ptrace_event(int event, unsigned long
message)
{
if (unlikely(ptrace_event_enabled(current, event))) {
current->ptrace_message = message;
+ current->ptrace_event = event;
ptrace_notify((event << 8) | SIGTRAP);
} else if (event == PTRACE_EVENT_EXEC) {
/* legacy EXEC report via SIGTRAP */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a51c13c2b1a0..86215fb654d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -964,6 +964,7 @@ struct task_struct {
/* Ptrace state: */
unsigned long ptrace_message;
+ int ptrace_event;
kernel_siginfo_t*last_siginfo;
struct task_io_accounting ioac;
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 633a83fe7051..5d2e5aa07a5c 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -66,6 +66,7 @@ static inline int ptrace_report_syscall(struct pt_regs *regs,
return 0;
current->ptrace_message = message;
+ current->ptrace_event = 0;
ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
/*
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 92c47cd5ad84..74a37e74c7f1 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -904,7 +904,9 @@ static int ptrace_get_syscall(struct task_struct *child,
unsigned long actual_size;
unsigned long write_size;
- if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) {
+ if ((child->ptrace_event == 0 &&
+child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) ||
+ child->ptrace_event == PTRACE_EVENT_SECCOMP) {
int i;
info.op = PTRACE_SYSCALL_INFO_ENTRY;
@@ -917,7 +919,8 @@ static int ptrace_get_syscall(struct task_struct *child,
for (i = 0; i < ARRAY_SIZE(args); i++)
info.entry.args[i] = args[i];
actual_size = offsetofend(struct ptrace_syscall_info, entry);
- } else if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
+ } else if (child->ptrace_event == 0 &&
+ child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
info.op = PTRACE_SYSCALL_INFO_EXIT;
info.arch = syscall_get_arch(child);
info.exit.rval = syscall_get_error(child, regs);
--
2.19.1
[RFC PATCH v3 3/3] ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
Extend PTRACE_GET_SYSCALL_INFO to support PTRACE_EVENT_SECCOMP stops.
The information returned is the same as for syscall-enter-stops.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/linux/ptrace.h| 1 +
include/linux/sched.h | 1 +
include/linux/tracehook.h | 1 +
kernel/ptrace.c | 7 +--
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 6c2ffed907f5..a993d0fde865 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -166,6 +166,7 @@ static inline void ptrace_event(int event, unsigned long
message)
{
if (unlikely(ptrace_event_enabled(current, event))) {
current->ptrace_message = message;
+ current->ptrace_event = event;
ptrace_notify((event << 8) | SIGTRAP);
} else if (event == PTRACE_EVENT_EXEC) {
/* legacy EXEC report via SIGTRAP */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a51c13c2b1a0..86215fb654d6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -964,6 +964,7 @@ struct task_struct {
/* Ptrace state: */
unsigned long ptrace_message;
+ int ptrace_event;
kernel_siginfo_t*last_siginfo;
struct task_io_accounting ioac;
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 633a83fe7051..5d2e5aa07a5c 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -66,6 +66,7 @@ static inline int ptrace_report_syscall(struct pt_regs *regs,
return 0;
current->ptrace_message = message;
+ current->ptrace_event = 0;
ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
/*
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 92c47cd5ad84..74a37e74c7f1 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -904,7 +904,9 @@ static int ptrace_get_syscall(struct task_struct *child,
unsigned long actual_size;
unsigned long write_size;
- if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) {
+ if ((child->ptrace_event == 0 &&
+child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_ENTRY) ||
+ child->ptrace_event == PTRACE_EVENT_SECCOMP) {
int i;
info.op = PTRACE_SYSCALL_INFO_ENTRY;
@@ -917,7 +919,8 @@ static int ptrace_get_syscall(struct task_struct *child,
for (i = 0; i < ARRAY_SIZE(args); i++)
info.entry.args[i] = args[i];
actual_size = offsetofend(struct ptrace_syscall_info, entry);
- } else if (child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
+ } else if (child->ptrace_event == 0 &&
+ child->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
info.op = PTRACE_SYSCALL_INFO_EXIT;
info.arch = syscall_get_arch(child);
info.exit.rval = syscall_get_error(child, regs);
--
2.19.1
[PATCH v3 2/3] ptrace: add PTRACE_GET_SYSCALL_INFO request
PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
the tracee is blocked in. The request succeeds when the tracee is in a
syscall-enter-stop or syscall-exit-stop, and fails with -EINVAL otherwise.
A subsequent change may extend PTRACE_GET_SYSCALL_INFO for the case
of PTRACE_EVENT_SECCOMP stop.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls. Some examples include:
* The notorious int-0x80-from-64-bit-task issue. See [1] for details.
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has no reliable means to find out that the syscall was, in fact,
a compat syscall, and misidentifies it.
* Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
Common practice is to keep track of the sequence of ptrace-stops in order
not to mix the two syscall-stops up. But it is not as simple as it looks;
for example, strace had a (just recently fixed) long-standing bug where
attaching strace to a tracee that is performing the execve system call
led to the tracer identifying the following syscall-exit-stop as
syscall-enter-stop, which messed up all the state tracking.
* Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
and process_vm_readv become unavailable when the process dumpable flag
is cleared. On such architectures as ia64 this results in all syscall
arguments being unavailable.
Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee. For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.
ptrace(2) man page:
long ptrace(enum __ptrace_request request, pid_t pid,
void *addr, void *data);
...
PTRACE_GET_SYSCALL_INFO
Retrieve information about the syscall that caused the stop.
The information is placed into the buffer pointed by "data"
argument, which should be a pointer to a buffer of type
"struct ptrace_syscall_info".
The "addr" argument contains the size of the buffer pointed to
by "data" (i.e., sizeof(struct ptrace_syscall_info)).
The return value contains the number of bytes available
to be written by the kernel.
If the size of data to be written by the kernel exceeds the size
specified by "addr" argument, the output is truncated.
This operation fails with EINVAL if the tracee is not
in a syscall-enter-stop, a syscall-exit-stop, or
a PTRACE_EVENT_SECCOMP stop.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/uapi/linux/ptrace.h | 24 ++
kernel/ptrace.c | 50 +
2 files changed, 74 insertions(+)
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index cb138902d042..49b0b1b41943 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -73,6 +73,30 @@ struct seccomp_metadata {
__u64 flags;/* Output: filter's flags */
};
+#define PTRACE_GET_SYSCALL_INFO0x420f
+#define PTRACE_SYSCALL_INFO_ENTRY 0
+#define PTRACE_SYSCALL_INFO_EXIT 1
+
+struct ptrace_syscall_info {
+ __u8 op;/* PTRACE_SYSCALL_INFO_* */
+ __u8 __pad0[3];
+ __u32 arch;
+ union {
+ struct {
+ __u64 nr;
+ __u64 instruction_pointer;
+ __u64 stack_pointer;
+ __u64 frame_pointer;
+ __u64 args[6];
+ } entry;
+ struct {
+ __s64 rval;
+ __u8 is_error;
+ __u8 __pad1[7];
+ } exit;
+ };
+};
+
/* Read signals from a shared (process wide) queue */
#define PTRACE_PEEKSIGINFO_SHARED (1 << 0)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 80b34dffdfb9..92c47cd5ad84 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -30,6 +30,10 @@
#include
#include
+#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
+#include/* For syscall_get_* */
+#endif
+
/*
* Access another process' address space via ptrace.
* Source/target buffer must be kernel space,
@@ -890,6 +894,46 @@ static int ptrace_regset(struct task_struct *task, int
req, unsigned int type,
EXPORT_SYMBOL_GPL(task_user_regset_view);
#endif
+#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
+static int ptrace_get_syscall(struct task_struct *child,
+ unsigned long user_size, void __user *datavp)
+{
+ struct ptrace_syscall_info info;
+ struct pt_regs *regs = task_pt_regs(child);
+ unsigned long args[ARRAY_SIZE(info.entry.args)];
+ unsigned long actual_size;
+ unsigned long write_size;
+
+ if
[PATCH v3 2/3] ptrace: add PTRACE_GET_SYSCALL_INFO request
PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
the tracee is blocked in. The request succeeds when the tracee is in a
syscall-enter-stop or syscall-exit-stop, and fails with -EINVAL otherwise.
A subsequent change may extend PTRACE_GET_SYSCALL_INFO for the case
of PTRACE_EVENT_SECCOMP stop.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls. Some examples include:
* The notorious int-0x80-from-64-bit-task issue. See [1] for details.
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has no reliable means to find out that the syscall was, in fact,
a compat syscall, and misidentifies it.
* Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
Common practice is to keep track of the sequence of ptrace-stops in order
not to mix the two syscall-stops up. But it is not as simple as it looks;
for example, strace had a (just recently fixed) long-standing bug where
attaching strace to a tracee that is performing the execve system call
led to the tracer identifying the following syscall-exit-stop as
syscall-enter-stop, which messed up all the state tracking.
* Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
and process_vm_readv become unavailable when the process dumpable flag
is cleared. On such architectures as ia64 this results in all syscall
arguments being unavailable.
Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee. For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.
ptrace(2) man page:
long ptrace(enum __ptrace_request request, pid_t pid,
void *addr, void *data);
...
PTRACE_GET_SYSCALL_INFO
Retrieve information about the syscall that caused the stop.
The information is placed into the buffer pointed by "data"
argument, which should be a pointer to a buffer of type
"struct ptrace_syscall_info".
The "addr" argument contains the size of the buffer pointed to
by "data" (i.e., sizeof(struct ptrace_syscall_info)).
The return value contains the number of bytes available
to be written by the kernel.
If the size of data to be written by the kernel exceeds the size
specified by "addr" argument, the output is truncated.
This operation fails with EINVAL if the tracee is not
in a syscall-enter-stop, a syscall-exit-stop, or
a PTRACE_EVENT_SECCOMP stop.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/uapi/linux/ptrace.h | 24 ++
kernel/ptrace.c | 50 +
2 files changed, 74 insertions(+)
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index cb138902d042..49b0b1b41943 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -73,6 +73,30 @@ struct seccomp_metadata {
__u64 flags;/* Output: filter's flags */
};
+#define PTRACE_GET_SYSCALL_INFO0x420f
+#define PTRACE_SYSCALL_INFO_ENTRY 0
+#define PTRACE_SYSCALL_INFO_EXIT 1
+
+struct ptrace_syscall_info {
+ __u8 op;/* PTRACE_SYSCALL_INFO_* */
+ __u8 __pad0[3];
+ __u32 arch;
+ union {
+ struct {
+ __u64 nr;
+ __u64 instruction_pointer;
+ __u64 stack_pointer;
+ __u64 frame_pointer;
+ __u64 args[6];
+ } entry;
+ struct {
+ __s64 rval;
+ __u8 is_error;
+ __u8 __pad1[7];
+ } exit;
+ };
+};
+
/* Read signals from a shared (process wide) queue */
#define PTRACE_PEEKSIGINFO_SHARED (1 << 0)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 80b34dffdfb9..92c47cd5ad84 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -30,6 +30,10 @@
#include
#include
+#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
+#include/* For syscall_get_* */
+#endif
+
/*
* Access another process' address space via ptrace.
* Source/target buffer must be kernel space,
@@ -890,6 +894,46 @@ static int ptrace_regset(struct task_struct *task, int
req, unsigned int type,
EXPORT_SYMBOL_GPL(task_user_regset_view);
#endif
+#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
+static int ptrace_get_syscall(struct task_struct *child,
+ unsigned long user_size, void __user *datavp)
+{
+ struct ptrace_syscall_info info;
+ struct pt_regs *regs = task_pt_regs(child);
+ unsigned long args[ARRAY_SIZE(info.entry.args)];
+ unsigned long actual_size;
+ unsigned long write_size;
+
+ if
[PATCH v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and
PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message
for the duration of syscall-stops.
This way ptracers can distinguish syscall-enter-stops
from syscall-exit-stops using PTRACE_GETEVENTMSG request.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/linux/tracehook.h | 9 ++---
include/uapi/linux/ptrace.h | 10 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 40b0b4c1bf7b..633a83fe7051 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -57,13 +57,15 @@ struct linux_binprm;
/*
* ptrace report for syscall entry and exit looks identical.
*/
-static inline int ptrace_report_syscall(struct pt_regs *regs)
+static inline int ptrace_report_syscall(struct pt_regs *regs,
+ unsigned long message)
{
int ptrace = current->ptrace;
if (!(ptrace & PT_PTRACED))
return 0;
+ current->ptrace_message = message;
ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
/*
@@ -76,6 +78,7 @@ static inline int ptrace_report_syscall(struct pt_regs *regs)
current->exit_code = 0;
}
+ current->ptrace_message = 0;
return fatal_signal_pending(current);
}
@@ -101,7 +104,7 @@ static inline int ptrace_report_syscall(struct pt_regs
*regs)
static inline __must_check int tracehook_report_syscall_entry(
struct pt_regs *regs)
{
- return ptrace_report_syscall(regs);
+ return ptrace_report_syscall(regs, PTRACE_EVENTMSG_SYSCALL_ENTRY);
}
/**
@@ -126,7 +129,7 @@ static inline void tracehook_report_syscall_exit(struct
pt_regs *regs, int step)
if (step)
user_single_step_report(regs);
else
- ptrace_report_syscall(regs);
+ ptrace_report_syscall(regs, PTRACE_EVENTMSG_SYSCALL_EXIT);
}
/**
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index d5a1b8a492b9..cb138902d042 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -104,6 +104,16 @@ struct seccomp_metadata {
#define PTRACE_O_MASK (\
0x00ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
+/*
+ * These values are stored in task->ptrace_message by
tracehook_report_syscall_*
+ * to describe current syscall-stop.
+ *
+ * Values for these constants are chosen so that they do not appear
+ * in task->ptrace_message by other means.
+ */
+#define PTRACE_EVENTMSG_SYSCALL_ENTRY 0x8000U
+#define PTRACE_EVENTMSG_SYSCALL_EXIT 0x9000U
+
#include
--
2.19.1
[PATCH v3 1/3] ptrace: pass type of a syscall-stop in ptrace_message
Define two constants, PTRACE_EVENTMSG_SYSCALL_ENTRY and
PTRACE_EVENTMSG_SYSCALL_EXIT, and place them in ptrace_message
for the duration of syscall-stops.
This way ptracers can distinguish syscall-enter-stops
from syscall-exit-stops using PTRACE_GETEVENTMSG request.
Signed-off-by: Elvira Khabirova
Signed-off-by: Dmitry V. Levin
---
include/linux/tracehook.h | 9 ++---
include/uapi/linux/ptrace.h | 10 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 40b0b4c1bf7b..633a83fe7051 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -57,13 +57,15 @@ struct linux_binprm;
/*
* ptrace report for syscall entry and exit looks identical.
*/
-static inline int ptrace_report_syscall(struct pt_regs *regs)
+static inline int ptrace_report_syscall(struct pt_regs *regs,
+ unsigned long message)
{
int ptrace = current->ptrace;
if (!(ptrace & PT_PTRACED))
return 0;
+ current->ptrace_message = message;
ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0));
/*
@@ -76,6 +78,7 @@ static inline int ptrace_report_syscall(struct pt_regs *regs)
current->exit_code = 0;
}
+ current->ptrace_message = 0;
return fatal_signal_pending(current);
}
@@ -101,7 +104,7 @@ static inline int ptrace_report_syscall(struct pt_regs
*regs)
static inline __must_check int tracehook_report_syscall_entry(
struct pt_regs *regs)
{
- return ptrace_report_syscall(regs);
+ return ptrace_report_syscall(regs, PTRACE_EVENTMSG_SYSCALL_ENTRY);
}
/**
@@ -126,7 +129,7 @@ static inline void tracehook_report_syscall_exit(struct
pt_regs *regs, int step)
if (step)
user_single_step_report(regs);
else
- ptrace_report_syscall(regs);
+ ptrace_report_syscall(regs, PTRACE_EVENTMSG_SYSCALL_EXIT);
}
/**
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index d5a1b8a492b9..cb138902d042 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -104,6 +104,16 @@ struct seccomp_metadata {
#define PTRACE_O_MASK (\
0x00ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
+/*
+ * These values are stored in task->ptrace_message by
tracehook_report_syscall_*
+ * to describe current syscall-stop.
+ *
+ * Values for these constants are chosen so that they do not appear
+ * in task->ptrace_message by other means.
+ */
+#define PTRACE_EVENTMSG_SYSCALL_ENTRY 0x8000U
+#define PTRACE_EVENTMSG_SYSCALL_EXIT 0x9000U
+
#include
--
2.19.1
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
* Russell King - ARM Linux [181124 20:10]: > On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote: > > Hi, > > > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote: > > > On 22/11/2018 17.12, Russell King - ARM Linux wrote: > > > > I'm also not sure about this: > > > > > > > > if (cpu_is_omap15xx()) > > > > end++; > > > > > > > > in dma_dest_len() - is that missing from the omap-dma driver? It looks > > > > like a work-around for some problem on OMAP15xx, but I can't make sense > > > > about why it's in the UDC driver rather than the legacy DMA driver. > > > > > > afaik no other legacy drivers were doing similar thing, this must be > > > something which is needed for the omap_udc driver to fix up something? > > > > Here's the patch that added it: > > https://marc.info/?l=linux-omap=119634396324221=2 > > > > "Make DMA-OUT behave on the 1510 ... the 1510 CPC register was just > > off-by-one with respect to the 1611 CDAC" > > ... which suggests that's a problem with the CPC register itself, and > we should fix that in the DMAengine driver rather than the USB gadget > driver. > > Tony, any input on this? Yeah that sounds like some hardware work-around for 15xx as described in the DMA_DEST_LAST macro reading CSAC on 15xx instead of CDAC. Seems like it should be done in the dmaengine driver.. My guess is that other dma users never needed to read CSAC register? Regards, Tony
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
* Russell King - ARM Linux [181124 20:10]: > On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote: > > Hi, > > > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote: > > > On 22/11/2018 17.12, Russell King - ARM Linux wrote: > > > > I'm also not sure about this: > > > > > > > > if (cpu_is_omap15xx()) > > > > end++; > > > > > > > > in dma_dest_len() - is that missing from the omap-dma driver? It looks > > > > like a work-around for some problem on OMAP15xx, but I can't make sense > > > > about why it's in the UDC driver rather than the legacy DMA driver. > > > > > > afaik no other legacy drivers were doing similar thing, this must be > > > something which is needed for the omap_udc driver to fix up something? > > > > Here's the patch that added it: > > https://marc.info/?l=linux-omap=119634396324221=2 > > > > "Make DMA-OUT behave on the 1510 ... the 1510 CPC register was just > > off-by-one with respect to the 1611 CDAC" > > ... which suggests that's a problem with the CPC register itself, and > we should fix that in the DMAengine driver rather than the USB gadget > driver. > > Tony, any input on this? Yeah that sounds like some hardware work-around for 15xx as described in the DMA_DEST_LAST macro reading CSAC on 15xx instead of CDAC. Seems like it should be done in the dmaengine driver.. My guess is that other dma users never needed to read CSAC register? Regards, Tony
[PATCH v3 0/3] ptrace: add PTRACE_GET_SYSCALL_INFO request
PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
the tracee is blocked in. The request succeeds when the tracee is in a
syscall-enter-stop, syscall-exit-stop or PTRACE_EVENT_SECCOMP stop,
and fails with -EINVAL otherwise.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls. Some examples include:
* The notorious int-0x80-from-64-bit-task issue. See [1] for details.
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has no reliable means to find out that the syscall was, in fact,
a compat syscall, and misidentifies it.
* Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
Common practice is to keep track of the sequence of ptrace-stops in order
not to mix the two syscall-stops up. But it is not as simple as it looks;
for example, strace had a (just recently fixed) long-standing bug where
attaching strace to a tracee that is performing the execve system call
led to the tracer identifying the following syscall-exit-stop as
syscall-enter-stop, which messed up all the state tracking.
* Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
and process_vm_readv become unavailable when the process dumpable flag
is cleared. On such architectures as ia64 this results in all syscall
arguments being unavailable.
Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee. For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.
PTRACE_GET_SYSCALL_INFO returns the following structure:
struct ptrace_syscall_info {
__u8 op;/* PTRACE_SYSCALL_INFO_* */
__u8 __pad0[3];
__u32 arch;
union {
struct {
__u64 nr;
__u64 instruction_pointer;
__u64 stack_pointer;
__u64 frame_pointer;
__u64 args[6];
} entry;
struct {
__s64 rval;
__u8 is_error;
__u8 __pad1[7];
} exit;
};
};
The structure was chosen according to [2], except for the following
changes:
* arch is returned unconditionally to aid with tracing system calls such as
execve();
* the type of nr field was changed from int to __u64 because syscall
numbers are, as a practical matter, 64 bits;
* stack_pointer and frame_pointer fields were added along with
instruction_pointer field since they are readily available and can save
the tracer from extra PTRACE_GETREGSET calls;
* a boolean is_error field was added along with rval field, this way
the tracer can more reliably distinguish a return value
from an error value.
This changeset should be applied on top of [3] and [4].
[1]
https://lore.kernel.org/lkml/ca+55afzcsvmddj9lh_gdbz1ozhyem6zrgpbdajnywm2lf_e...@mail.gmail.com/
[2]
https://lore.kernel.org/lkml/caobl_7gm0n80n7j_dfw_eqyflyzq+sf4y2avsccv88tb3aw...@mail.gmail.com/
[3] https://lore.kernel.org/lkml/20181119210139.ga8...@altlinux.org/
[4] https://lore.kernel.org/lkml/20181120001128.ga11...@altlinux.org/
v3: Split into three changes.
Change struct ptrace_syscall_info.
Support PTRACE_EVENT_SECCOMP by adding ptrace_event to task_struct.
Add proper defines for ptrace_syscall_info.op values.
Rename PT_SYSCALL_IS_ENTERING and PT_SYSCALL_IS_EXITING to
PTRACE_EVENTMSG_SYSCALL_ENTRY and PTRACE_EVENTMSG_SYSCALL_EXIT and move
them to uapi.
Elvira Khabirova (3):
ptrace: pass type of a syscall-stop in ptrace_message
ptrace: add PTRACE_GET_SYSCALL_INFO request
ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
include/linux/ptrace.h | 1 +
include/linux/sched.h | 1 +
include/linux/tracehook.h | 10 ---
include/uapi/linux/ptrace.h | 34
kernel/ptrace.c | 53 +
5 files changed, 96 insertions(+), 3 deletions(-)
--
2.19.1
[PATCH v3 0/3] ptrace: add PTRACE_GET_SYSCALL_INFO request
PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
the tracee is blocked in. The request succeeds when the tracee is in a
syscall-enter-stop, syscall-exit-stop or PTRACE_EVENT_SECCOMP stop,
and fails with -EINVAL otherwise.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information about syscalls. Some examples include:
* The notorious int-0x80-from-64-bit-task issue. See [1] for details.
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has no reliable means to find out that the syscall was, in fact,
a compat syscall, and misidentifies it.
* Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
Common practice is to keep track of the sequence of ptrace-stops in order
not to mix the two syscall-stops up. But it is not as simple as it looks;
for example, strace had a (just recently fixed) long-standing bug where
attaching strace to a tracee that is performing the execve system call
led to the tracer identifying the following syscall-exit-stop as
syscall-enter-stop, which messed up all the state tracking.
* Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
and process_vm_readv become unavailable when the process dumpable flag
is cleared. On such architectures as ia64 this results in all syscall
arguments being unavailable.
Secondly, ptracers also have to support a lot of arch-specific code for
obtaining information about the tracee. For some architectures, this
requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
argument and return value.
PTRACE_GET_SYSCALL_INFO returns the following structure:
struct ptrace_syscall_info {
__u8 op;/* PTRACE_SYSCALL_INFO_* */
__u8 __pad0[3];
__u32 arch;
union {
struct {
__u64 nr;
__u64 instruction_pointer;
__u64 stack_pointer;
__u64 frame_pointer;
__u64 args[6];
} entry;
struct {
__s64 rval;
__u8 is_error;
__u8 __pad1[7];
} exit;
};
};
The structure was chosen according to [2], except for the following
changes:
* arch is returned unconditionally to aid with tracing system calls such as
execve();
* the type of nr field was changed from int to __u64 because syscall
numbers are, as a practical matter, 64 bits;
* stack_pointer and frame_pointer fields were added along with
instruction_pointer field since they are readily available and can save
the tracer from extra PTRACE_GETREGSET calls;
* a boolean is_error field was added along with rval field, this way
the tracer can more reliably distinguish a return value
from an error value.
This changeset should be applied on top of [3] and [4].
[1]
https://lore.kernel.org/lkml/ca+55afzcsvmddj9lh_gdbz1ozhyem6zrgpbdajnywm2lf_e...@mail.gmail.com/
[2]
https://lore.kernel.org/lkml/caobl_7gm0n80n7j_dfw_eqyflyzq+sf4y2avsccv88tb3aw...@mail.gmail.com/
[3] https://lore.kernel.org/lkml/20181119210139.ga8...@altlinux.org/
[4] https://lore.kernel.org/lkml/20181120001128.ga11...@altlinux.org/
v3: Split into three changes.
Change struct ptrace_syscall_info.
Support PTRACE_EVENT_SECCOMP by adding ptrace_event to task_struct.
Add proper defines for ptrace_syscall_info.op values.
Rename PT_SYSCALL_IS_ENTERING and PT_SYSCALL_IS_EXITING to
PTRACE_EVENTMSG_SYSCALL_ENTRY and PTRACE_EVENTMSG_SYSCALL_EXIT and move
them to uapi.
Elvira Khabirova (3):
ptrace: pass type of a syscall-stop in ptrace_message
ptrace: add PTRACE_GET_SYSCALL_INFO request
ptrace: add PTRACE_EVENT_SECCOMP support to PTRACE_GET_SYSCALL_INFO
include/linux/ptrace.h | 1 +
include/linux/sched.h | 1 +
include/linux/tracehook.h | 10 ---
include/uapi/linux/ptrace.h | 34
kernel/ptrace.c | 53 +
5 files changed, 96 insertions(+), 3 deletions(-)
--
2.19.1
[PATCH] ext2: fix potential use after free
The function ext2_xattr_set calls brelse(bh) to drop the reference count of bh. After that, bh may be freed. However, following brelse(bh), it reads bh->b_data via macro HDR(bh). This may result in a use-after-free bug. This patch moves brelse(bh) after reading field. Signed-off-by: Pan Bian --- fs/ext2/xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext2/xattr.c b/fs/ext2/xattr.c index 62d9a659a..dd8f10d 100644 --- a/fs/ext2/xattr.c +++ b/fs/ext2/xattr.c @@ -612,9 +612,9 @@ bad_block: ext2_error(sb, "ext2_xattr_set", } cleanup: - brelse(bh); if (!(bh && header == HDR(bh))) kfree(header); + brelse(bh); up_write(_I(inode)->xattr_sem); return error; -- 2.7.4
[PATCH] ext2: fix potential use after free
The function ext2_xattr_set calls brelse(bh) to drop the reference count of bh. After that, bh may be freed. However, following brelse(bh), it reads bh->b_data via macro HDR(bh). This may result in a use-after-free bug. This patch moves brelse(bh) after reading field. Signed-off-by: Pan Bian --- fs/ext2/xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext2/xattr.c b/fs/ext2/xattr.c index 62d9a659a..dd8f10d 100644 --- a/fs/ext2/xattr.c +++ b/fs/ext2/xattr.c @@ -612,9 +612,9 @@ bad_block: ext2_error(sb, "ext2_xattr_set", } cleanup: - brelse(bh); if (!(bh && header == HDR(bh))) kfree(header); + brelse(bh); up_write(_I(inode)->xattr_sem); return error; -- 2.7.4
Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
On Sat, Nov 24, 2018 at 04:42:29PM -0800, Andrew Morton wrote: > This changelog doesn't have the nifty test case code which was in > earlier versions? Why do we put regression tests in the changelogs anyway? We have tools/testing/selftests/vm/ already, perhaps they should go there?
Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
On Sat, Nov 24, 2018 at 04:42:29PM -0800, Andrew Morton wrote: > This changelog doesn't have the nifty test case code which was in > earlier versions? Why do we put regression tests in the changelogs anyway? We have tools/testing/selftests/vm/ already, perhaps they should go there?
Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
On Thu, 22 Nov 2018 15:09:06 -0800 Joel Fernandes wrote: > Android uses ashmem for sharing memory regions. We are looking forward to > migrating all usecases of ashmem to memfd so that we can possibly remove > the ashmem driver in the future from staging while also benefiting from > using memfd and contributing to it. Note staging drivers are also not ABI > and generally can be removed at anytime. > > One of the main usecases Android has is the ability to create a region and > mmap it as writeable, then add protection against making any "future" > writes while keeping the existing already mmap'ed writeable-region active. > This allows us to implement a usecase where receivers of the shared > memory buffer can get a read-only view, while the sender continues to > write to the buffer. See CursorWindow documentation in Android for more > details: > https://developer.android.com/reference/android/database/CursorWindow > > This usecase cannot be implemented with the existing F_SEAL_WRITE seal. > To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal > which prevents any future mmap and write syscalls from succeeding while > keeping the existing mmap active. > > A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week > where we don't need to modify core VFS structures to get the same > behavior of the seal. This solves several side-effects pointed by Andy. > self-tests are provided in later patch to verify the expected semantics. > > [1] https://lore.kernel.org/lkml/2018173650.ga256...@google.com/ This changelog doesn't have the nifty test case code which was in earlier versions?
Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust
On Thu, 22 Nov 2018 15:09:06 -0800 Joel Fernandes wrote: > Android uses ashmem for sharing memory regions. We are looking forward to > migrating all usecases of ashmem to memfd so that we can possibly remove > the ashmem driver in the future from staging while also benefiting from > using memfd and contributing to it. Note staging drivers are also not ABI > and generally can be removed at anytime. > > One of the main usecases Android has is the ability to create a region and > mmap it as writeable, then add protection against making any "future" > writes while keeping the existing already mmap'ed writeable-region active. > This allows us to implement a usecase where receivers of the shared > memory buffer can get a read-only view, while the sender continues to > write to the buffer. See CursorWindow documentation in Android for more > details: > https://developer.android.com/reference/android/database/CursorWindow > > This usecase cannot be implemented with the existing F_SEAL_WRITE seal. > To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal > which prevents any future mmap and write syscalls from succeeding while > keeping the existing mmap active. > > A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week > where we don't need to modify core VFS structures to get the same > behavior of the seal. This solves several side-effects pointed by Andy. > self-tests are provided in later patch to verify the expected semantics. > > [1] https://lore.kernel.org/lkml/2018173650.ga256...@google.com/ This changelog doesn't have the nifty test case code which was in earlier versions?
[PATCH V2] namei: free new_dentry late
After calling dput(new_dentry), new_dentry is passed to fsnotify_move.
This may result in a use-after-free bug. This patch moves the put
operation late.
Fixes: da1ce0670c14("vfs: add cross-rename")
Signed-off-by: Pan Bian
---
V2: correct the fixes commit information
---
fs/namei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namei.c b/fs/namei.c
index 0cab649..8b104d9 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -4498,7 +4498,6 @@ int vfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
unlock_two_nondirectories(source, target);
else if (target)
inode_unlock(target);
- dput(new_dentry);
if (!error) {
fsnotify_move(old_dir, new_dir, old_name.name, is_dir,
!(flags & RENAME_EXCHANGE) ? target : NULL,
old_dentry);
@@ -4507,6 +4506,7 @@ int vfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
new_is_dir, NULL, new_dentry);
}
}
+ dput(new_dentry);
release_dentry_name_snapshot(_name);
return error;
--
2.7.4
[PATCH V2] namei: free new_dentry late
After calling dput(new_dentry), new_dentry is passed to fsnotify_move.
This may result in a use-after-free bug. This patch moves the put
operation late.
Fixes: da1ce0670c14("vfs: add cross-rename")
Signed-off-by: Pan Bian
---
V2: correct the fixes commit information
---
fs/namei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namei.c b/fs/namei.c
index 0cab649..8b104d9 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -4498,7 +4498,6 @@ int vfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
unlock_two_nondirectories(source, target);
else if (target)
inode_unlock(target);
- dput(new_dentry);
if (!error) {
fsnotify_move(old_dir, new_dir, old_name.name, is_dir,
!(flags & RENAME_EXCHANGE) ? target : NULL,
old_dentry);
@@ -4507,6 +4506,7 @@ int vfs_rename(struct inode *old_dir, struct dentry
*old_dentry,
new_is_dir, NULL, new_dentry);
}
}
+ dput(new_dentry);
release_dentry_name_snapshot(_name);
return error;
--
2.7.4
Re: [GIT PULL] HID fixes
The pull request you sent on Sat, 24 Nov 2018 21:19:35 +0100 (CET): > git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e195ca6cb6f21633e56322d5aa11ed59cdb22fb2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] HID fixes
The pull request you sent on Sat, 24 Nov 2018 21:19:35 +0100 (CET): > git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e195ca6cb6f21633e56322d5aa11ed59cdb22fb2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH 2/3] iio: chemical: add support for Sensirion SPS30 sensor
Add support for Sensirion SPS30 particulate matter sensor.
Signed-off-by: Tomasz Duszynski
---
drivers/iio/chemical/Kconfig | 11 ++
drivers/iio/chemical/Makefile | 1 +
drivers/iio/chemical/sps30.c | 359 ++
3 files changed, 371 insertions(+)
create mode 100644 drivers/iio/chemical/sps30.c
diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
index b8e005be4f87..40057ecf8130 100644
--- a/drivers/iio/chemical/Kconfig
+++ b/drivers/iio/chemical/Kconfig
@@ -61,6 +61,17 @@ config IAQCORE
iAQ-Core Continuous/Pulsed VOC (Volatile Organic Compounds)
sensors
+config SPS30
+ tristate "SPS30 Particulate Matter sensor"
+ depends on I2C
+ select CRC8
+ help
+ Say Y here to build support for the Sensirion SPS30 Particulate
+ Matter sensor.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sps30.
+
config VZ89X
tristate "SGX Sensortech MiCS VZ89X VOC sensor"
depends on I2C
diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
index 2f4c4ba4d781..9f42f4252151 100644
--- a/drivers/iio/chemical/Makefile
+++ b/drivers/iio/chemical/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_BME680_I2C) += bme680_i2c.o
obj-$(CONFIG_BME680_SPI) += bme680_spi.o
obj-$(CONFIG_CCS811) += ccs811.o
obj-$(CONFIG_IAQCORE) += ams-iaq-core.o
+obj-$(CONFIG_SPS30) += sps30.o
obj-$(CONFIG_VZ89X)+= vz89x.o
diff --git a/drivers/iio/chemical/sps30.c b/drivers/iio/chemical/sps30.c
new file mode 100644
index ..bf802621ae7f
--- /dev/null
+++ b/drivers/iio/chemical/sps30.c
@@ -0,0 +1,359 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sensirion SPS30 Particulate Matter sensor driver
+ *
+ * Copyright (c) Tomasz Duszynski
+ *
+ * I2C slave address: 0x69
+ *
+ * TODO:
+ * - support for turning on fan cleaning
+ * - support for reading/setting auto cleaning interval
+ */
+
+#define pr_fmt(fmt) "sps30: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SPS30_CRC8_POLYNOMIAL 0x31
+
+/* SPS30 commands */
+#define SPS30_START_MEAS 0x0010
+#define SPS30_STOP_MEAS 0x0104
+#define SPS30_RESET 0xd304
+#define SPS30_READ_DATA_READY_FLAG 0x0202
+#define SPS30_READ_DATA 0x0300
+#define SPS30_READ_SERIAL 0xD033
+
+#define SPS30_CHAN(_index, _mod) { \
+ .type = IIO_MASSCONCENTRATION, \
+ .modified = 1, \
+ .channel2 = IIO_MOD_ ## _mod, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
+ .scan_index = _index, \
+ .scan_type = { \
+ .sign = 'u', \
+ .realbits = 12, \
+ .storagebits = 32, \
+ .endianness = IIO_CPU, \
+ }, \
+}
+
+enum {
+ PM1p0, /* just a placeholder */
+ PM2p5,
+ PM4p0, /* just a placeholder */
+ PM10,
+};
+
+struct sps30_state {
+ struct i2c_client *client;
+ /* guards against concurrent access to sensor registers */
+ struct mutex lock;
+};
+
+DECLARE_CRC8_TABLE(sps30_crc8_table);
+
+static int sps30_write_then_read(struct sps30_state *state, u8 *buf,
+int buf_size, u8 *data, int data_size)
+{
+ /* every two received data bytes are checksummed */
+ u8 tmp[data_size + data_size / 2];
+ int ret, i;
+
+ /*
+* Sensor does not support repeated start so instead of
+* sending two i2c messages in a row we just send one by one.
+*/
+ ret = i2c_master_send(state->client, buf, buf_size);
+ if (ret != buf_size)
+ return ret < 0 ? ret : -EIO;
+
+ if (!data)
+ return 0;
+
+ ret = i2c_master_recv(state->client, tmp, sizeof(tmp));
+ if (ret != sizeof(tmp))
+ return ret < 0 ? ret : -EIO;
+
+ for (i = 0; i < sizeof(tmp); i += 3) {
+ u8 crc = crc8(sps30_crc8_table, [i], 2, CRC8_INIT_VALUE);
+
+ if (crc != tmp[i + 2]) {
+ dev_err(>client->dev,
+ "data integrity check failed\n");
+ return -EIO;
+ }
+
+ *data++ = tmp[i];
+ *data++ = tmp[i + 1];
+ }
+
+ return 0;
+}
+
+static int sps30_do_cmd(struct sps30_state *state, u16 cmd, u8 *data, int size)
+{
+ /* depending on the command up to 3 bytes may be needed for argument */
+ u8 buf[sizeof(cmd) + 3] = { cmd >> 8, cmd };
+
+ switch (cmd) {
+ case SPS30_START_MEAS:
+ buf[2] = 0x03;
+ buf[3] = 0x00;
+ buf[4] = 0xac; /* precomputed crc */
+ return sps30_write_then_read(state, buf, 5, NULL, 0);
+ case SPS30_STOP_MEAS:
+ case SPS30_RESET:
+ return sps30_write_then_read(state, buf, 2, NULL, 0);
+ case SPS30_READ_DATA_READY_FLAG:
+ case SPS30_READ_DATA:
+
[PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
is de facto standard. Existing air quality sensors usually follow
this convention and are capable of returning measurements using
this unit.
IIO currently does not offer suitable channel type for this
type of measurements hence this patch adds this.
In addition, two modifiers are introduced used for distinguishing
between coarse (PM10) and fine particles (PM2p5) measurements, i.e
IIO_MOD_PM10 and IIO_MOD_PM2p5.
Signed-off-by: Tomasz Duszynski
---
Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
drivers/iio/industrialio-core.c | 3 +++
include/uapi/linux/iio/types.h | 3 +++
tools/iio/iio_event_monitor.c | 6 ++
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index 8127a08e366d..ce0ed140660d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1684,4 +1684,13 @@ KernelVersion: 4.18
Contact: linux-...@vger.kernel.org
Description:
Raw (unscaled) phase difference reading from channel Y
- that can be processed to radians.
\ No newline at end of file
+ that can be processed to radians.
+
+What:
/sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
+What:
/sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
+What: /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
+What:
/sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
+KernelVersion: 4.21
+Contact: linux-...@vger.kernel.org
+Description:
+ Mass concentration reading of particulate matter in ug / m3.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index a062cfddc5af..2a9ef600c1fb 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_GRAVITY] = "gravity",
[IIO_POSITIONRELATIVE] = "positionrelative",
[IIO_PHASE] = "phase",
+ [IIO_MASSCONCENTRATION] = "massconcentration",
};
static const char * const iio_modifier_names[] = {
@@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_Q] = "q",
[IIO_MOD_CO2] = "co2",
[IIO_MOD_VOC] = "voc",
+ [IIO_MOD_PM2p5] = "pm2p5",
+ [IIO_MOD_PM10] = "pm10",
};
/* relies on pairs of these shared then separate */
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 92baabc103ac..465044b42af5 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -46,6 +46,7 @@ enum iio_chan_type {
IIO_GRAVITY,
IIO_POSITIONRELATIVE,
IIO_PHASE,
+ IIO_MASSCONCENTRATION,
};
enum iio_modifier {
@@ -87,6 +88,8 @@ enum iio_modifier {
IIO_MOD_VOC,
IIO_MOD_LIGHT_UV,
IIO_MOD_LIGHT_DUV,
+ IIO_MOD_PM2p5,
+ IIO_MOD_PM10,
};
enum iio_event_type {
diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
index ac2de6b7e89f..f0fcfeddba2b 100644
--- a/tools/iio/iio_event_monitor.c
+++ b/tools/iio/iio_event_monitor.c
@@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_GRAVITY] = "gravity",
[IIO_POSITIONRELATIVE] = "positionrelative",
[IIO_PHASE] = "phase",
+ [IIO_MASSCONCENTRATION] = "massconcentration",
};
static const char * const iio_ev_type_text[] = {
@@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_Q] = "q",
[IIO_MOD_CO2] = "co2",
[IIO_MOD_VOC] = "voc",
+ [IIO_MOD_PM2p5] = "pm2p5",
+ [IIO_MOD_PM10] = "pm10",
};
static bool event_is_known(struct iio_event_data *event)
@@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
case IIO_GRAVITY:
case IIO_POSITIONRELATIVE:
case IIO_PHASE:
+ case IIO_MASSCONCENTRATION:
break;
default:
return false;
@@ -200,6 +204,8 @@ static bool event_is_known(struct iio_event_data *event)
case IIO_MOD_Q:
case IIO_MOD_CO2:
case IIO_MOD_VOC:
+ case IIO_MOD_PM2p5:
+ case IIO_MOD_PM10:
break;
default:
return false;
--
2.19.2
[PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
is de facto standard. Existing air quality sensors usually follow
this convention and are capable of returning measurements using
this unit.
IIO currently does not offer suitable channel type for this
type of measurements hence this patch adds this.
In addition, two modifiers are introduced used for distinguishing
between coarse (PM10) and fine particles (PM2p5) measurements, i.e
IIO_MOD_PM10 and IIO_MOD_PM2p5.
Signed-off-by: Tomasz Duszynski
---
Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
drivers/iio/industrialio-core.c | 3 +++
include/uapi/linux/iio/types.h | 3 +++
tools/iio/iio_event_monitor.c | 6 ++
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index 8127a08e366d..ce0ed140660d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1684,4 +1684,13 @@ KernelVersion: 4.18
Contact: linux-...@vger.kernel.org
Description:
Raw (unscaled) phase difference reading from channel Y
- that can be processed to radians.
\ No newline at end of file
+ that can be processed to radians.
+
+What:
/sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
+What:
/sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
+What: /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
+What:
/sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
+KernelVersion: 4.21
+Contact: linux-...@vger.kernel.org
+Description:
+ Mass concentration reading of particulate matter in ug / m3.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index a062cfddc5af..2a9ef600c1fb 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_GRAVITY] = "gravity",
[IIO_POSITIONRELATIVE] = "positionrelative",
[IIO_PHASE] = "phase",
+ [IIO_MASSCONCENTRATION] = "massconcentration",
};
static const char * const iio_modifier_names[] = {
@@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_Q] = "q",
[IIO_MOD_CO2] = "co2",
[IIO_MOD_VOC] = "voc",
+ [IIO_MOD_PM2p5] = "pm2p5",
+ [IIO_MOD_PM10] = "pm10",
};
/* relies on pairs of these shared then separate */
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 92baabc103ac..465044b42af5 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -46,6 +46,7 @@ enum iio_chan_type {
IIO_GRAVITY,
IIO_POSITIONRELATIVE,
IIO_PHASE,
+ IIO_MASSCONCENTRATION,
};
enum iio_modifier {
@@ -87,6 +88,8 @@ enum iio_modifier {
IIO_MOD_VOC,
IIO_MOD_LIGHT_UV,
IIO_MOD_LIGHT_DUV,
+ IIO_MOD_PM2p5,
+ IIO_MOD_PM10,
};
enum iio_event_type {
diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
index ac2de6b7e89f..f0fcfeddba2b 100644
--- a/tools/iio/iio_event_monitor.c
+++ b/tools/iio/iio_event_monitor.c
@@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_GRAVITY] = "gravity",
[IIO_POSITIONRELATIVE] = "positionrelative",
[IIO_PHASE] = "phase",
+ [IIO_MASSCONCENTRATION] = "massconcentration",
};
static const char * const iio_ev_type_text[] = {
@@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_Q] = "q",
[IIO_MOD_CO2] = "co2",
[IIO_MOD_VOC] = "voc",
+ [IIO_MOD_PM2p5] = "pm2p5",
+ [IIO_MOD_PM10] = "pm10",
};
static bool event_is_known(struct iio_event_data *event)
@@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
case IIO_GRAVITY:
case IIO_POSITIONRELATIVE:
case IIO_PHASE:
+ case IIO_MASSCONCENTRATION:
break;
default:
return false;
@@ -200,6 +204,8 @@ static bool event_is_known(struct iio_event_data *event)
case IIO_MOD_Q:
case IIO_MOD_CO2:
case IIO_MOD_VOC:
+ case IIO_MOD_PM2p5:
+ case IIO_MOD_PM10:
break;
default:
return false;
--
2.19.2
[PATCH 2/3] iio: chemical: add support for Sensirion SPS30 sensor
Add support for Sensirion SPS30 particulate matter sensor.
Signed-off-by: Tomasz Duszynski
---
drivers/iio/chemical/Kconfig | 11 ++
drivers/iio/chemical/Makefile | 1 +
drivers/iio/chemical/sps30.c | 359 ++
3 files changed, 371 insertions(+)
create mode 100644 drivers/iio/chemical/sps30.c
diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
index b8e005be4f87..40057ecf8130 100644
--- a/drivers/iio/chemical/Kconfig
+++ b/drivers/iio/chemical/Kconfig
@@ -61,6 +61,17 @@ config IAQCORE
iAQ-Core Continuous/Pulsed VOC (Volatile Organic Compounds)
sensors
+config SPS30
+ tristate "SPS30 Particulate Matter sensor"
+ depends on I2C
+ select CRC8
+ help
+ Say Y here to build support for the Sensirion SPS30 Particulate
+ Matter sensor.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sps30.
+
config VZ89X
tristate "SGX Sensortech MiCS VZ89X VOC sensor"
depends on I2C
diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
index 2f4c4ba4d781..9f42f4252151 100644
--- a/drivers/iio/chemical/Makefile
+++ b/drivers/iio/chemical/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_BME680_I2C) += bme680_i2c.o
obj-$(CONFIG_BME680_SPI) += bme680_spi.o
obj-$(CONFIG_CCS811) += ccs811.o
obj-$(CONFIG_IAQCORE) += ams-iaq-core.o
+obj-$(CONFIG_SPS30) += sps30.o
obj-$(CONFIG_VZ89X)+= vz89x.o
diff --git a/drivers/iio/chemical/sps30.c b/drivers/iio/chemical/sps30.c
new file mode 100644
index ..bf802621ae7f
--- /dev/null
+++ b/drivers/iio/chemical/sps30.c
@@ -0,0 +1,359 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sensirion SPS30 Particulate Matter sensor driver
+ *
+ * Copyright (c) Tomasz Duszynski
+ *
+ * I2C slave address: 0x69
+ *
+ * TODO:
+ * - support for turning on fan cleaning
+ * - support for reading/setting auto cleaning interval
+ */
+
+#define pr_fmt(fmt) "sps30: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SPS30_CRC8_POLYNOMIAL 0x31
+
+/* SPS30 commands */
+#define SPS30_START_MEAS 0x0010
+#define SPS30_STOP_MEAS 0x0104
+#define SPS30_RESET 0xd304
+#define SPS30_READ_DATA_READY_FLAG 0x0202
+#define SPS30_READ_DATA 0x0300
+#define SPS30_READ_SERIAL 0xD033
+
+#define SPS30_CHAN(_index, _mod) { \
+ .type = IIO_MASSCONCENTRATION, \
+ .modified = 1, \
+ .channel2 = IIO_MOD_ ## _mod, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
+ .scan_index = _index, \
+ .scan_type = { \
+ .sign = 'u', \
+ .realbits = 12, \
+ .storagebits = 32, \
+ .endianness = IIO_CPU, \
+ }, \
+}
+
+enum {
+ PM1p0, /* just a placeholder */
+ PM2p5,
+ PM4p0, /* just a placeholder */
+ PM10,
+};
+
+struct sps30_state {
+ struct i2c_client *client;
+ /* guards against concurrent access to sensor registers */
+ struct mutex lock;
+};
+
+DECLARE_CRC8_TABLE(sps30_crc8_table);
+
+static int sps30_write_then_read(struct sps30_state *state, u8 *buf,
+int buf_size, u8 *data, int data_size)
+{
+ /* every two received data bytes are checksummed */
+ u8 tmp[data_size + data_size / 2];
+ int ret, i;
+
+ /*
+* Sensor does not support repeated start so instead of
+* sending two i2c messages in a row we just send one by one.
+*/
+ ret = i2c_master_send(state->client, buf, buf_size);
+ if (ret != buf_size)
+ return ret < 0 ? ret : -EIO;
+
+ if (!data)
+ return 0;
+
+ ret = i2c_master_recv(state->client, tmp, sizeof(tmp));
+ if (ret != sizeof(tmp))
+ return ret < 0 ? ret : -EIO;
+
+ for (i = 0; i < sizeof(tmp); i += 3) {
+ u8 crc = crc8(sps30_crc8_table, [i], 2, CRC8_INIT_VALUE);
+
+ if (crc != tmp[i + 2]) {
+ dev_err(>client->dev,
+ "data integrity check failed\n");
+ return -EIO;
+ }
+
+ *data++ = tmp[i];
+ *data++ = tmp[i + 1];
+ }
+
+ return 0;
+}
+
+static int sps30_do_cmd(struct sps30_state *state, u16 cmd, u8 *data, int size)
+{
+ /* depending on the command up to 3 bytes may be needed for argument */
+ u8 buf[sizeof(cmd) + 3] = { cmd >> 8, cmd };
+
+ switch (cmd) {
+ case SPS30_START_MEAS:
+ buf[2] = 0x03;
+ buf[3] = 0x00;
+ buf[4] = 0xac; /* precomputed crc */
+ return sps30_write_then_read(state, buf, 5, NULL, 0);
+ case SPS30_STOP_MEAS:
+ case SPS30_RESET:
+ return sps30_write_then_read(state, buf, 2, NULL, 0);
+ case SPS30_READ_DATA_READY_FLAG:
+ case SPS30_READ_DATA:
+
[PATCH 3/3] iio: chemical: sps30: add device tree support
Add device tree support for Sensirion SPS30 particulate
matter sensor.
Signed-off-by: Tomasz Duszynski
---
.../bindings/iio/chemical/sensirion,sps30.txt| 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
diff --git a/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
new file mode 100644
index ..6eee2709b5b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
@@ -0,0 +1,12 @@
+* Sensirion SPS30 particulate matter sensor
+
+Required properties:
+- compatible: must be "sensirion,sps30"
+- reg: the I2C address of the sensor
+
+Example:
+
+sps30@69 {
+ compatible = "sensirion,sps30";
+ reg = <0x69>;
+};
--
2.19.2
[PATCH 3/3] iio: chemical: sps30: add device tree support
Add device tree support for Sensirion SPS30 particulate
matter sensor.
Signed-off-by: Tomasz Duszynski
---
.../bindings/iio/chemical/sensirion,sps30.txt| 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
diff --git a/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
new file mode 100644
index ..6eee2709b5b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
@@ -0,0 +1,12 @@
+* Sensirion SPS30 particulate matter sensor
+
+Required properties:
+- compatible: must be "sensirion,sps30"
+- reg: the I2C address of the sensor
+
+Example:
+
+sps30@69 {
+ compatible = "sensirion,sps30";
+ reg = <0x69>;
+};
--
2.19.2
[PATCH 0/3] add support for Sensirion SPS30 PM sensor
This patch series adds support for Sensirion SPS30 particulate matter sensor. Along with a driver itself, new channel type and two modifiers for distinguishing between coarse and fine particles measurements are introduced. Sensor datasheet can be downloaded from https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/0_Datasheets/Particulate_Matter/Sensirion_PM_Sensors_SPS30_Datasheet.pdf Tomasz Duszynski (3): iio: add IIO_MASSCONCENTRATION channel type iio: chemical: add support for Sensirion SPS30 sensor iio: chemical: sps30: add device tree support Documentation/ABI/testing/sysfs-bus-iio | 11 +- .../bindings/iio/chemical/sensirion,sps30.txt | 12 + drivers/iio/chemical/Kconfig | 11 + drivers/iio/chemical/Makefile | 1 + drivers/iio/chemical/sps30.c | 359 ++ drivers/iio/industrialio-core.c | 3 + include/uapi/linux/iio/types.h| 3 + tools/iio/iio_event_monitor.c | 6 + 8 files changed, 405 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt create mode 100644 drivers/iio/chemical/sps30.c -- 2.19.2
[PATCH 0/3] add support for Sensirion SPS30 PM sensor
This patch series adds support for Sensirion SPS30 particulate matter sensor. Along with a driver itself, new channel type and two modifiers for distinguishing between coarse and fine particles measurements are introduced. Sensor datasheet can be downloaded from https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/0_Datasheets/Particulate_Matter/Sensirion_PM_Sensors_SPS30_Datasheet.pdf Tomasz Duszynski (3): iio: add IIO_MASSCONCENTRATION channel type iio: chemical: add support for Sensirion SPS30 sensor iio: chemical: sps30: add device tree support Documentation/ABI/testing/sysfs-bus-iio | 11 +- .../bindings/iio/chemical/sensirion,sps30.txt | 12 + drivers/iio/chemical/Kconfig | 11 + drivers/iio/chemical/Makefile | 1 + drivers/iio/chemical/sps30.c | 359 ++ drivers/iio/industrialio-core.c | 3 + include/uapi/linux/iio/types.h| 3 + tools/iio/iio_event_monitor.c | 6 + 8 files changed, 405 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt create mode 100644 drivers/iio/chemical/sps30.c -- 2.19.2
[PATCH] fat: Replaced 11 magic to MSDOS_NAME for volume label
The FAT file system volume label file stored in the root directory should
match the volume label field in the FAT boot sector. As consequence, the
max length of these fields ought to be the same. This patch replaces the
magic '11' usef in the struct fat_boot_sector with MSDOS_NAME,
which is used in struct msdos_dir_entry.
Please check the following references:
1. Microsoft FAT specification 2005
(http://read.pudn.com/downloads77/ebook/294884/FAT32%20Spec%20%28SDA%20Contribution%29.pdf).
Search for 'volume label'.
2. Microsoft Extensible Firmware Initiative, FAT32 File System Specification
(https://staff.washington.edu/dittrich/misc/fatgen103.pdf).
Search for 'volume label'.
3. User space code that creates FAT filesystem
sometimes uses MSDOS_NAME for the label, sometimes not.
Search for 'if (memcmp(label, NO_NAME, MSDOS_NAME))'.
I consider to make the same patch there as well.
https://github.com/dosfstools/dosfstools/blob/master/src/mkfs.fat.c
Signed-off-by: Carmeli Tamir
---
include/uapi/linux/msdos_fs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/msdos_fs.h b/include/uapi/linux/msdos_fs.h
index fde7537..1216e6c 100644
--- a/include/uapi/linux/msdos_fs.h
+++ b/include/uapi/linux/msdos_fs.h
@@ -135,7 +135,7 @@ struct fat_boot_sector {
for mount state. */
__u8signature; /* extended boot signature */
__u8vol_id[4]; /* volume ID */
- __u8vol_label[11]; /* volume label */
+ __u8vol_label[MSDOS_NAME]; /* volume label */
__u8fs_type[8]; /* file system type */
/* other fields are not added here */
} fat16;
@@ -158,7 +158,7 @@ struct fat_boot_sector {
for mount state. */
__u8signature; /* extended boot signature */
__u8vol_id[4]; /* volume ID */
- __u8vol_label[11]; /* volume label */
+ __u8vol_label[MSDOS_NAME]; /* volume label */
__u8fs_type[8]; /* file system type */
/* other fields are not added here */
} fat32;
--
2.7.4
[PATCH] fat: Replaced 11 magic to MSDOS_NAME for volume label
The FAT file system volume label file stored in the root directory should
match the volume label field in the FAT boot sector. As consequence, the
max length of these fields ought to be the same. This patch replaces the
magic '11' usef in the struct fat_boot_sector with MSDOS_NAME,
which is used in struct msdos_dir_entry.
Please check the following references:
1. Microsoft FAT specification 2005
(http://read.pudn.com/downloads77/ebook/294884/FAT32%20Spec%20%28SDA%20Contribution%29.pdf).
Search for 'volume label'.
2. Microsoft Extensible Firmware Initiative, FAT32 File System Specification
(https://staff.washington.edu/dittrich/misc/fatgen103.pdf).
Search for 'volume label'.
3. User space code that creates FAT filesystem
sometimes uses MSDOS_NAME for the label, sometimes not.
Search for 'if (memcmp(label, NO_NAME, MSDOS_NAME))'.
I consider to make the same patch there as well.
https://github.com/dosfstools/dosfstools/blob/master/src/mkfs.fat.c
Signed-off-by: Carmeli Tamir
---
include/uapi/linux/msdos_fs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/msdos_fs.h b/include/uapi/linux/msdos_fs.h
index fde7537..1216e6c 100644
--- a/include/uapi/linux/msdos_fs.h
+++ b/include/uapi/linux/msdos_fs.h
@@ -135,7 +135,7 @@ struct fat_boot_sector {
for mount state. */
__u8signature; /* extended boot signature */
__u8vol_id[4]; /* volume ID */
- __u8vol_label[11]; /* volume label */
+ __u8vol_label[MSDOS_NAME]; /* volume label */
__u8fs_type[8]; /* file system type */
/* other fields are not added here */
} fat16;
@@ -158,7 +158,7 @@ struct fat_boot_sector {
for mount state. */
__u8signature; /* extended boot signature */
__u8vol_id[4]; /* volume ID */
- __u8vol_label[11]; /* volume label */
+ __u8vol_label[MSDOS_NAME]; /* volume label */
__u8fs_type[8]; /* file system type */
/* other fields are not added here */
} fat32;
--
2.7.4
Re: [RFC PATCH] of: make MAX_RESERVED_REGIONS configurable
On Wed, Nov 21, 2018 at 8:51 PM Miles Chen wrote:
>
> On Wed, 2018-11-21 at 10:39 -0600, Rob Herring wrote:
> > On Wed, Nov 21, 2018 at 2:11 AM wrote:
> > >
> > > From: Miles Chen
> > >
> > > When we use more than 32 entries in /resered-memory,
> > > there will be an error message: "not enough space all defined regions.".
> > > We can increase MAX_RESERVED_REGIONS to fix this.
> > >
> > > commit 22f8cc6e3373 ("drivers: of: increase MAX_RESERVED_REGIONS to 32")
> > > increased MAX_RESERVED_REGIONS to 32 but I'm not sure if increasing
> > > MAX_RESERVED_REGIONS to 64 is suitable for everyone.
> > >
> > > In this RFC patch, CONFIG_MAX_OF_RESERVED_REGIONS is added and used as
> > > MAX_RESERVED_REGIONS. Add a sanity test to make sure that
> > > MAX_RESERVED_REGIONS is less than INIT_MEMBLOCK_REGIONS.
> > > Users can configure CONFIG_MAX_OF_RESERVED_REGIONS according to their
> > > need.
> >
> > I don't want a kconfig option for this. I think it should be dynamic
> > instead.
> >
> > The current flow is like this:
> >
> > for each reserved node:
> > - call memblock_reserve
> > - Add info to reserved_mem array
> >
> > I think we should change it to:
> >
> > for each reserved node:
> > - call memblock_reserve
> > - count number of nodes
> >
> > Alloc array using memblock_alloc
> >
> > for each reserved node:
> >- Add info to reserved_mem array
> >
>
> thanks for your comment.
>
> I reviewed the flow and it might be easier to count the
> nodes and setup array first:
>
> for each reserved node:
> - count number of nodes
>
> Alloc array using memblock_alloc
>
>
> for each reserved node:
>- call memblock_reserve
The order here is wrong. It is important that you reserve the memory
blocks before doing any allocations.
>- Add info to reserved_mem array
>
> What do you think?
>
> > Rob
>
>
Re: [RFC PATCH] of: make MAX_RESERVED_REGIONS configurable
On Wed, Nov 21, 2018 at 8:51 PM Miles Chen wrote:
>
> On Wed, 2018-11-21 at 10:39 -0600, Rob Herring wrote:
> > On Wed, Nov 21, 2018 at 2:11 AM wrote:
> > >
> > > From: Miles Chen
> > >
> > > When we use more than 32 entries in /resered-memory,
> > > there will be an error message: "not enough space all defined regions.".
> > > We can increase MAX_RESERVED_REGIONS to fix this.
> > >
> > > commit 22f8cc6e3373 ("drivers: of: increase MAX_RESERVED_REGIONS to 32")
> > > increased MAX_RESERVED_REGIONS to 32 but I'm not sure if increasing
> > > MAX_RESERVED_REGIONS to 64 is suitable for everyone.
> > >
> > > In this RFC patch, CONFIG_MAX_OF_RESERVED_REGIONS is added and used as
> > > MAX_RESERVED_REGIONS. Add a sanity test to make sure that
> > > MAX_RESERVED_REGIONS is less than INIT_MEMBLOCK_REGIONS.
> > > Users can configure CONFIG_MAX_OF_RESERVED_REGIONS according to their
> > > need.
> >
> > I don't want a kconfig option for this. I think it should be dynamic
> > instead.
> >
> > The current flow is like this:
> >
> > for each reserved node:
> > - call memblock_reserve
> > - Add info to reserved_mem array
> >
> > I think we should change it to:
> >
> > for each reserved node:
> > - call memblock_reserve
> > - count number of nodes
> >
> > Alloc array using memblock_alloc
> >
> > for each reserved node:
> >- Add info to reserved_mem array
> >
>
> thanks for your comment.
>
> I reviewed the flow and it might be easier to count the
> nodes and setup array first:
>
> for each reserved node:
> - count number of nodes
>
> Alloc array using memblock_alloc
>
>
> for each reserved node:
>- call memblock_reserve
The order here is wrong. It is important that you reserve the memory
blocks before doing any allocations.
>- Add info to reserved_mem array
>
> What do you think?
>
> > Rob
>
>
Re: [PING 2] [PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage
On Sat, Nov 24, 2018 at 4:32 PM Daniel Santos wrote:
>
> Ping 2!
>
> On 11/05/2018 03:38 PM, Daniel Santos wrote:
> > Ping.
> >
> > Daniel
> >
> > On 10/21/2018 07:32 PM, Hou Tao wrote:
> >> On 2018/10/19 16:30, Daniel Santos wrote:
> >>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
> >>> is defined then a write buffer is available and has been initialized.
> >>> However, this does is not the case when the mtd device has no
> >>> out-of-band buffer:
> >>>
> >>> int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
> >>> {
> >>> if (!c->mtd->oobsize)
> >>> return 0;
> >>> ...
> >>>
> >>> The resulting call to cancel_delayed_work_sync passing a uninitialized
> >>> (but zeroed) delayed_work struct forces lockdep to become disabled.
> >>>
> >>> [ 90.050639] overlayfs: upper fs does not support tmpfile.
> >>> [ 90.652264] INFO: trying to register non-static key.
> >>> [ 90.662171] the code is fine but needs lockdep annotation.
> >>> [ 90.673090] turning off the locking correctness validator.
> >>> [ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
> >>> [ 90.696672] Stack : 80d8f6a2 0038 805f
> >>> 80444600 8fe364f4 805dfbe7
> >>> [ 90.713349] 80563a30 06e2 8068370c 0001
> >>> 0001 8e2fdc48
> >>> [ 90.730020] 80d9 0106
> >>> 6465746e 312e3420
> >>> [ 90.746690] 6b636f6c 03bf f800 20676e69
> >>> 8000 8e2c2a90
> >>> [ 90.763362] 80d9 0001 8e2c2a90 0003
> >>> 80260dc0 08052098 8068
> >>> [ 90.780033] ...
> >>> [ 90.784902] Call Trace:
> >>> [ 90.789793] [<8000f0d8>] show_stack+0xb8/0x148
> >>> [ 90.798659] [<8005a000>] register_lock_class+0x270/0x55c
> >>> [ 90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
> >>> [ 90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
> >>> [ 90.828345] [<8003f27c>] flush_work+0x200/0x24c
> >>> [ 90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
> >>> [ 90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
> >>> [ 90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
> >>> [ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
> >>> [ 90.875067] [<80014424>] syscall_common+0x34/0x58
> >>>
> >>> Signed-off-by: Daniel Santos
> >>> ---
> >>> fs/jffs2/super.c | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> >>> index 793ad30970ff..cae4ecda3c50 100644
> >>> --- a/fs/jffs2/super.c
> >>> +++ b/fs/jffs2/super.c
> >>> @@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int
> >>> wait)
> >>> struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
> >>>
> >>> #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
> >>> - cancel_delayed_work_sync(>wbuf_dwork);
> >>> + if (jffs2_is_writebuffered(c))
> >>> + cancel_delayed_work_sync(>wbuf_dwork);
> >>> #endif
> >>>
> >>> mutex_lock(>alloc_sem);
> >>>
> >> Reviewed-by: Hou Tao
Boris, can you please queue up this patch?
--
Thanks,
//richard
Re: [PING 2] [PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage
On Sat, Nov 24, 2018 at 4:32 PM Daniel Santos wrote:
>
> Ping 2!
>
> On 11/05/2018 03:38 PM, Daniel Santos wrote:
> > Ping.
> >
> > Daniel
> >
> > On 10/21/2018 07:32 PM, Hou Tao wrote:
> >> On 2018/10/19 16:30, Daniel Santos wrote:
> >>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
> >>> is defined then a write buffer is available and has been initialized.
> >>> However, this does is not the case when the mtd device has no
> >>> out-of-band buffer:
> >>>
> >>> int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
> >>> {
> >>> if (!c->mtd->oobsize)
> >>> return 0;
> >>> ...
> >>>
> >>> The resulting call to cancel_delayed_work_sync passing a uninitialized
> >>> (but zeroed) delayed_work struct forces lockdep to become disabled.
> >>>
> >>> [ 90.050639] overlayfs: upper fs does not support tmpfile.
> >>> [ 90.652264] INFO: trying to register non-static key.
> >>> [ 90.662171] the code is fine but needs lockdep annotation.
> >>> [ 90.673090] turning off the locking correctness validator.
> >>> [ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
> >>> [ 90.696672] Stack : 80d8f6a2 0038 805f
> >>> 80444600 8fe364f4 805dfbe7
> >>> [ 90.713349] 80563a30 06e2 8068370c 0001
> >>> 0001 8e2fdc48
> >>> [ 90.730020] 80d9 0106
> >>> 6465746e 312e3420
> >>> [ 90.746690] 6b636f6c 03bf f800 20676e69
> >>> 8000 8e2c2a90
> >>> [ 90.763362] 80d9 0001 8e2c2a90 0003
> >>> 80260dc0 08052098 8068
> >>> [ 90.780033] ...
> >>> [ 90.784902] Call Trace:
> >>> [ 90.789793] [<8000f0d8>] show_stack+0xb8/0x148
> >>> [ 90.798659] [<8005a000>] register_lock_class+0x270/0x55c
> >>> [ 90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
> >>> [ 90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
> >>> [ 90.828345] [<8003f27c>] flush_work+0x200/0x24c
> >>> [ 90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
> >>> [ 90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
> >>> [ 90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
> >>> [ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
> >>> [ 90.875067] [<80014424>] syscall_common+0x34/0x58
> >>>
> >>> Signed-off-by: Daniel Santos
> >>> ---
> >>> fs/jffs2/super.c | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> >>> index 793ad30970ff..cae4ecda3c50 100644
> >>> --- a/fs/jffs2/super.c
> >>> +++ b/fs/jffs2/super.c
> >>> @@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int
> >>> wait)
> >>> struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
> >>>
> >>> #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
> >>> - cancel_delayed_work_sync(>wbuf_dwork);
> >>> + if (jffs2_is_writebuffered(c))
> >>> + cancel_delayed_work_sync(>wbuf_dwork);
> >>> #endif
> >>>
> >>> mutex_lock(>alloc_sem);
> >>>
> >> Reviewed-by: Hou Tao
Boris, can you please queue up this patch?
--
Thanks,
//richard
[GIT PULL] HID fixes
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus to receive HID subsystem fixes = - revert of the high-resolution scrolling feature, as it breaks certain hardware due to incompatibilities between Logitech and Microsoft worlds. Peter Hutterer is working on a fixed implementation. Until that is finished, revert by Benjamin Tissoires. - revert of incorrect strncpy->strlcpy conversion in uhid, from David Herrmann - fix for buggy sendfile() implementation on uhid device node, from Eric Biggers - a few assorted device-ID specific quirks = Thanks. Benjamin Tissoires (7): Revert "HID: input: simplify/fix high-res scroll event handling" Revert "HID: logitech: fix a used uninitialized GCC warning" Revert "HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice" Revert "HID: logitech: Enable high-resolution scrolling on Logitech mice" Revert "HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration"" Revert "HID: input: Create a utility class for counting scroll events" Revert "Input: Add the `REL_WHEEL_HI_RES` event code" Benson Leung (1): HID: input: Ignore battery reported by Symbol DS4308 David Herrmann (1): Revert "HID: uhid: use strlcpy() instead of strncpy()" Eric Biggers (1): HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges Kai-Heng Feng (2): HID: multitouch: Add pointstick support for Cirque Touchpad HID: i2c-hid: Disable runtime PM for LG touchscreen Rodrigo Rivas Costa (1): HID: steam: remove input device when a hid client is running. Sebastian Parschauer (2): HID: Add quirk for Microsoft PIXART OEM mouse HID: Add quirk for Primax PIXART OEM mice Documentation/input/event-codes.rst| 11 +- drivers/hid/hid-ids.h | 8 + drivers/hid/hid-input.c| 47 + drivers/hid/hid-logitech-hidpp.c | 309 +++-- drivers/hid/hid-multitouch.c | 6 + drivers/hid/hid-quirks.c | 3 + drivers/hid/hid-steam.c| 154 +--- drivers/hid/i2c-hid/i2c-hid-core.c | 2 + drivers/hid/uhid.c | 25 ++- include/linux/hid.h| 28 --- include/uapi/linux/input-event-codes.h | 10 -- 11 files changed, 159 insertions(+), 444 deletions(-) -- Jiri Kosina SUSE Labs
[GIT PULL] HID fixes
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus to receive HID subsystem fixes = - revert of the high-resolution scrolling feature, as it breaks certain hardware due to incompatibilities between Logitech and Microsoft worlds. Peter Hutterer is working on a fixed implementation. Until that is finished, revert by Benjamin Tissoires. - revert of incorrect strncpy->strlcpy conversion in uhid, from David Herrmann - fix for buggy sendfile() implementation on uhid device node, from Eric Biggers - a few assorted device-ID specific quirks = Thanks. Benjamin Tissoires (7): Revert "HID: input: simplify/fix high-res scroll event handling" Revert "HID: logitech: fix a used uninitialized GCC warning" Revert "HID: logitech: Use LDJ_DEVICE macro for existing Logitech mice" Revert "HID: logitech: Enable high-resolution scrolling on Logitech mice" Revert "HID: logitech: Add function to enable HID++ 1.0 "scrolling acceleration"" Revert "HID: input: Create a utility class for counting scroll events" Revert "Input: Add the `REL_WHEEL_HI_RES` event code" Benson Leung (1): HID: input: Ignore battery reported by Symbol DS4308 David Herrmann (1): Revert "HID: uhid: use strlcpy() instead of strncpy()" Eric Biggers (1): HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges Kai-Heng Feng (2): HID: multitouch: Add pointstick support for Cirque Touchpad HID: i2c-hid: Disable runtime PM for LG touchscreen Rodrigo Rivas Costa (1): HID: steam: remove input device when a hid client is running. Sebastian Parschauer (2): HID: Add quirk for Microsoft PIXART OEM mouse HID: Add quirk for Primax PIXART OEM mice Documentation/input/event-codes.rst| 11 +- drivers/hid/hid-ids.h | 8 + drivers/hid/hid-input.c| 47 + drivers/hid/hid-logitech-hidpp.c | 309 +++-- drivers/hid/hid-multitouch.c | 6 + drivers/hid/hid-quirks.c | 3 + drivers/hid/hid-steam.c| 154 +--- drivers/hid/i2c-hid/i2c-hid-core.c | 2 + drivers/hid/uhid.c | 25 ++- include/linux/hid.h| 28 --- include/uapi/linux/input-event-codes.h | 10 -- 11 files changed, 159 insertions(+), 444 deletions(-) -- Jiri Kosina SUSE Labs
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: > On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > > > At a high level, addressing these issues is straight forward. First, > > > the driver needs to support authorization equivalent to that which is > > > implemented in the current Intel Launch Enclave, ie. control over the > > > SGX_FLAGS_PROVISION_KEY attribute. > > > > I agree, hence my email :) > Started to scratch my head that is it really an issue that any > enclave can provision in the end? > > Direct quote from your first response: > > "In particular, the ability to run enclaves with the provisioning > bit set is somewhat sensitive, since it effectively allows access to > a stable fingerprint of the system." > > As can be seen from the key derivation table this does not exactly > hold so you should refine your original argument before we can > consider any type of change. > > I just don't see what it is so wrong for any enclave to be able to > tell that it really is an enclave. This isn't about an enclave being able to tell that it is really an enclave. As I noted in my previous reply, access to the provisioning bit allows an enclave author to create a perpetual hardware identifier for a platform based on a signing key of their choosing, along with a few other incidentals, all of which are completely under the control of the enclave author. The Intel SGX architects, at least originally, felt strongly enough about this issue to use the Launch Enclave to implement cryptographically secure policy control over access to the SGX_FLAGS_PROVISION_KEY attribute. See the 'if' clause that begins on line 219 of psw/ae/le/launch_enclave.cpp in the current HEAD of the Linux SGX SDK which is currently bf22963411. Let me describe an entirely contrived example but one which is representative of the threat. I'm a web-site that wants to consistently and reliably track platforms that visit a site. Without cryptographically secure policy enforcement in the SGX eco-system I push an enclave to the platform which only computes the MRSIGNER specific derived provisioning key and returns it to the web-site. >From that point onward I will always be able to identify the platform, as long as the enclave can be executed on the platform. Unlike cookies, there is nothing to delete since the aggressor enclave only needs to exist long enough to be run and generate the derived provisioning key, no trace of the fingerprinting remains thereafter. If the proposed driver is to be a functional replacement for the existing SGX eco-system it needs to offer privacy and platform security guarantees at least comparable to what is available on a non-FLC system. That means at least some semblance of cryptographically secure policy management on at least two fronts. We can propose a general architecture that we believe satisfies these needs without compromising the upstream integrity of the kernel with respect to free and open systems. A solution that could arguably protect user's investment in current non-FLC hardware as well. We would be happy to articulate the outline of that but I don't want to waste anyone's time, including ours, if everyone's mind has been made up as to what the driver should and should not do. We are clearly capable of making the proposed driver do whatever we want it to do. Our concern is that Linux security architects that choose to use this technology have the best tools available to them, within the constraints of upstream sensibility, without whacking on the kernel. As it stands now the driver has both privacy and potential system security issues which translate into useability and desirability implications for SGX on Linux moving forward. > /Jarkko Have a good remainder of the weekend. I need to get back to my MIG welder out in the shop. Dr. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "Attendants at a service station in Eunice, Louisiana, handed more than $100 to a naked man who claimed to have a gun in his pocket." -- Unknown
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: > On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > > > At a high level, addressing these issues is straight forward. First, > > > the driver needs to support authorization equivalent to that which is > > > implemented in the current Intel Launch Enclave, ie. control over the > > > SGX_FLAGS_PROVISION_KEY attribute. > > > > I agree, hence my email :) > Started to scratch my head that is it really an issue that any > enclave can provision in the end? > > Direct quote from your first response: > > "In particular, the ability to run enclaves with the provisioning > bit set is somewhat sensitive, since it effectively allows access to > a stable fingerprint of the system." > > As can be seen from the key derivation table this does not exactly > hold so you should refine your original argument before we can > consider any type of change. > > I just don't see what it is so wrong for any enclave to be able to > tell that it really is an enclave. This isn't about an enclave being able to tell that it is really an enclave. As I noted in my previous reply, access to the provisioning bit allows an enclave author to create a perpetual hardware identifier for a platform based on a signing key of their choosing, along with a few other incidentals, all of which are completely under the control of the enclave author. The Intel SGX architects, at least originally, felt strongly enough about this issue to use the Launch Enclave to implement cryptographically secure policy control over access to the SGX_FLAGS_PROVISION_KEY attribute. See the 'if' clause that begins on line 219 of psw/ae/le/launch_enclave.cpp in the current HEAD of the Linux SGX SDK which is currently bf22963411. Let me describe an entirely contrived example but one which is representative of the threat. I'm a web-site that wants to consistently and reliably track platforms that visit a site. Without cryptographically secure policy enforcement in the SGX eco-system I push an enclave to the platform which only computes the MRSIGNER specific derived provisioning key and returns it to the web-site. >From that point onward I will always be able to identify the platform, as long as the enclave can be executed on the platform. Unlike cookies, there is nothing to delete since the aggressor enclave only needs to exist long enough to be run and generate the derived provisioning key, no trace of the fingerprinting remains thereafter. If the proposed driver is to be a functional replacement for the existing SGX eco-system it needs to offer privacy and platform security guarantees at least comparable to what is available on a non-FLC system. That means at least some semblance of cryptographically secure policy management on at least two fronts. We can propose a general architecture that we believe satisfies these needs without compromising the upstream integrity of the kernel with respect to free and open systems. A solution that could arguably protect user's investment in current non-FLC hardware as well. We would be happy to articulate the outline of that but I don't want to waste anyone's time, including ours, if everyone's mind has been made up as to what the driver should and should not do. We are clearly capable of making the proposed driver do whatever we want it to do. Our concern is that Linux security architects that choose to use this technology have the best tools available to them, within the constraints of upstream sensibility, without whacking on the kernel. As it stands now the driver has both privacy and potential system security issues which translate into useability and desirability implications for SGX on Linux moving forward. > /Jarkko Have a good remainder of the weekend. I need to get back to my MIG welder out in the shop. Dr. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "Attendants at a service station in Eunice, Louisiana, handed more than $100 to a naked man who claimed to have a gun in his pocket." -- Unknown
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote: > Hi, > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote: > > On 22/11/2018 17.12, Russell King - ARM Linux wrote: > > > I'm also not sure about this: > > > > > > if (cpu_is_omap15xx()) > > > end++; > > > > > > in dma_dest_len() - is that missing from the omap-dma driver? It looks > > > like a work-around for some problem on OMAP15xx, but I can't make sense > > > about why it's in the UDC driver rather than the legacy DMA driver. > > > > afaik no other legacy drivers were doing similar thing, this must be > > something which is needed for the omap_udc driver to fix up something? > > Here's the patch that added it: > https://marc.info/?l=linux-omap=119634396324221=2 > > "Make DMA-OUT behave on the 1510 ... the 1510 CPC register was just > off-by-one with respect to the 1611 CDAC" ... which suggests that's a problem with the CPC register itself, and we should fix that in the DMAengine driver rather than the USB gadget driver. Tony, any input on this? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote: > Hi, > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote: > > On 22/11/2018 17.12, Russell King - ARM Linux wrote: > > > I'm also not sure about this: > > > > > > if (cpu_is_omap15xx()) > > > end++; > > > > > > in dma_dest_len() - is that missing from the omap-dma driver? It looks > > > like a work-around for some problem on OMAP15xx, but I can't make sense > > > about why it's in the UDC driver rather than the legacy DMA driver. > > > > afaik no other legacy drivers were doing similar thing, this must be > > something which is needed for the omap_udc driver to fix up something? > > Here's the patch that added it: > https://marc.info/?l=linux-omap=119634396324221=2 > > "Make DMA-OUT behave on the 1510 ... the 1510 CPC register was just > off-by-one with respect to the 1611 CDAC" ... which suggests that's a problem with the CPC register itself, and we should fix that in the DMAengine driver rather than the USB gadget driver. Tony, any input on this? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH V2] hfs: do not free node before using
On Sat, 2018-11-24 at 10:10 +0800, Pan Bian wrote:
> The function hfs_bmap_free frees node via hfs_bnode_put(node).
> However,
> it then reads node->this when dumping error message on an error path,
> which may result in a use-after-free bug. This patch frees node only
> when it is never used.
>
> Fixes: a1185ffa2fc("HFS rewrite")
>
> Signed-off-by: Pan Bian
>
> ---
> V2: correct the commit information in Fixes
By the way, HFS+ has the same issue [1].
>
> ---
> fs/hfs/btree.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/hfs/btree.c b/fs/hfs/btree.c
> index 98b96ff..19017d2 100644
> --- a/fs/hfs/btree.c
> +++ b/fs/hfs/btree.c
> @@ -338,13 +338,14 @@ void hfs_bmap_free(struct hfs_bnode *node)
>
> nidx -= len * 8;
> i = node->next;
> - hfs_bnode_put(node);
> if (!i) {
> /* panic */;
> pr_crit("unable to free bnode %u. bmap not
> found!\n",
> node->this);
> + hfs_bnode_put(node);
> return;
> }
> + hfs_bnode_put(node);
First of all, it looks weird to have two calls of hfs_bnode_put(node).
Secondly, you will add only one line of code instead of two if you
simply save the node->this in the local variable.
> node = hfs_bnode_find(tree, i);
> if (IS_ERR(node))
> return;
Thanks,
Vyacheslav Dubeyko.
[1] https://elixir.bootlin.com/linux/latest/source/fs/hfsplus/btree.c#L457
Re: [PATCH V2] hfs: do not free node before using
On Sat, 2018-11-24 at 10:10 +0800, Pan Bian wrote:
> The function hfs_bmap_free frees node via hfs_bnode_put(node).
> However,
> it then reads node->this when dumping error message on an error path,
> which may result in a use-after-free bug. This patch frees node only
> when it is never used.
>
> Fixes: a1185ffa2fc("HFS rewrite")
>
> Signed-off-by: Pan Bian
>
> ---
> V2: correct the commit information in Fixes
By the way, HFS+ has the same issue [1].
>
> ---
> fs/hfs/btree.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/hfs/btree.c b/fs/hfs/btree.c
> index 98b96ff..19017d2 100644
> --- a/fs/hfs/btree.c
> +++ b/fs/hfs/btree.c
> @@ -338,13 +338,14 @@ void hfs_bmap_free(struct hfs_bnode *node)
>
> nidx -= len * 8;
> i = node->next;
> - hfs_bnode_put(node);
> if (!i) {
> /* panic */;
> pr_crit("unable to free bnode %u. bmap not
> found!\n",
> node->this);
> + hfs_bnode_put(node);
> return;
> }
> + hfs_bnode_put(node);
First of all, it looks weird to have two calls of hfs_bnode_put(node).
Secondly, you will add only one line of code instead of two if you
simply save the node->this in the local variable.
> node = hfs_bnode_find(tree, i);
> if (IS_ERR(node))
> return;
Thanks,
Vyacheslav Dubeyko.
[1] https://elixir.bootlin.com/linux/latest/source/fs/hfsplus/btree.c#L457
