[PATCH v2] perf annotate/report: Remove hist__account_cycles from callback
The hist__account_cycles is executed when the hist_iter__branch_callback
is called. But it looks it's not necessary. In hist__account_cycles, it
already walks on all branch entries.
This patch moves the hist__account_cycles out of callback, now the data
processing is much faster than before.
Previous code has an issue that the ch[offset].num++
(in __symbol__account_cycles) is executed repeatedly since
hist__account_cycles is called in each hist_iter__branch_callback,
so the counting of ch[offset].num is not correct (too big).
With this patch, the issue is fixed. And we don't need the code of
"ch->reset >= ch->num / 2" to check if there are too many overlaps
(in annotation__count_and_fill), otherwise some data would be
hidden.
Now, we can try, for example:
perf record -b ...
perf annotate or perf report -s symbol
The before/after output should be no change.
v2:
---
1. Cover the similar perf report
2. Remove the checking code "ch->reset >= ch->num / 2"
Signed-off-by: Jin Yao
---
tools/perf/builtin-annotate.c | 4 ++--
tools/perf/builtin-report.c | 9 +++--
tools/perf/util/annotate.c| 2 +-
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 67f9d9f..77deb3a 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -159,8 +159,6 @@ static int hist_iter__branch_callback(struct
hist_entry_iter *iter,
struct perf_evsel *evsel = iter->evsel;
int err;
- hist__account_cycles(sample->branch_stack, al, sample, false);
-
bi = he->branch_info;
err = addr_map_symbol__inc_samples(>from, sample, evsel);
@@ -199,6 +197,8 @@ static int process_branch_callback(struct perf_evsel *evsel,
if (a.map != NULL)
a.map->dso->hit = 1;
+ hist__account_cycles(sample->branch_stack, al, sample, false);
+
ret = hist_entry_iter__add(, , PERF_MAX_STACK_DEPTH, ann);
return ret;
}
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 1921aaa..80874fa 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -136,9 +136,6 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
- hist__account_cycles(sample->branch_stack, al, sample,
-rep->nonany_branch_mode);
-
if (sort__mode == SORT_MODE__BRANCH) {
bi = he->branch_info;
err = addr_map_symbol__inc_samples(>from, sample, evsel);
@@ -181,9 +178,6 @@ static int hist_iter__branch_callback(struct
hist_entry_iter *iter,
if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
- hist__account_cycles(sample->branch_stack, al, sample,
-rep->nonany_branch_mode);
-
bi = he->branch_info;
err = addr_map_symbol__inc_samples(>from, sample, evsel);
if (err)
@@ -282,6 +276,9 @@ static int process_sample_event(struct perf_tool *tool,
if (al.map != NULL)
al.map->dso->hit = 1;
+ hist__account_cycles(sample->branch_stack, , sample,
+rep->nonany_branch_mode);
+
ret = hist_entry_iter__add(, , rep->max_stack, rep);
if (ret < 0)
pr_debug("problem adding hist entry, skipping event\n");
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 5f6dbbf..e8080c0 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1015,7 +1015,7 @@ static void annotation__count_and_fill(struct annotation
*notes, u64 start, u64
float ipc = n_insn / ((double)ch->cycles / (double)ch->num);
/* Hide data when there are too many overlaps. */
- if (ch->reset >= 0x7fff || ch->reset >= ch->num / 2)
+ if (ch->reset >= 0x7fff)
return;
for (offset = start; offset <= end; offset++) {
--
2.7.4
Re: [PATCH] scripts/spelling.txt: add more typos to spelling.txt and sort
On 2019/3/15 11:07, Finn Thain wrote: Does it makes sense to list every typo that is simply a transposition of characters or a character omitted? This file will become very large very quickly if we do that. We are consistent in one thing: typo hurt eyes. Those typos are exactly generated from and still existing in the kernel tree and they're constantly merged out of our carelessness. Such errors can be found algorithmically where the correct spelling is known. E.g. the file contains 'algorithm' so 'algrthm' can easily be obtained programatically. Nice hint on transposition programmability which means effect to me. It looks the mistake line could be removed form scripts/spelling.txt after we add transposition check to scripts/checkpatch.pl. ($0.02) Suggest you restrict this to common misspellings. That's not a NAK and I'm not the relevant maintainer. Just my $0.02. Thanks for your comment.
Re: [PATCH] tty: 8250: fix a missing check for pci_ioremap_bar
On 15. 03. 19, 5:56, Kangjie Lu wrote:
> pci_ioremap_bar could fail. The fix captures the failure and
> pass an error code upstream. This can avoid potential NULL
> pointer dereferences in the future.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/tty/serial/8250/8250_lpss.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_lpss.c
> b/drivers/tty/serial/8250/8250_lpss.c
> index 98dbc796353f..e95332d8b35e 100644
> --- a/drivers/tty/serial/8250/8250_lpss.c
> +++ b/drivers/tty/serial/8250/8250_lpss.c
...
> @@ -203,7 +207,7 @@ static void qrk_serial_exit_dma(struct lpss8250 *lpss)
> dw_dma_remove(>dma_chip);
> }
> #else/* CONFIG_SERIAL_8250_DMA */
> -static void qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port
> *port) {}
> +static int qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port
> *port) {}
So you have to return something here now.
> static void qrk_serial_exit_dma(struct lpss8250 *lpss) {}
> #endif /* !CONFIG_SERIAL_8250_DMA */
>
regards,
--
js
suse labs
Re: [PATCH] greybus: audio_manager: fix a missing check of ida_simple_get
On Thu, Mar 14, 2019 at 12:15 PM Kangjie Lu wrote:
>
> ida_simple_get could fail. The fix inserts a check for its
> return value.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/staging/greybus/audio_manager.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/greybus/audio_manager.c
> b/drivers/staging/greybus/audio_manager.c
> index d44b070d8862..c2a4af4c1d06 100644
> --- a/drivers/staging/greybus/audio_manager.c
> +++ b/drivers/staging/greybus/audio_manager.c
> @@ -45,6 +45,9 @@ int gb_audio_manager_add(struct
> gb_audio_manager_module_descriptor *desc)
> int err;
>
> id = ida_simple_get(_id, 0, 0, GFP_KERNEL);
> + if (id < 0)
> + return id;
> +
> err = gb_audio_manager_module_create(, manager_kset,
> id, desc);
> if (err) {
Reviewed-by: Vaibhav Agarwal
--
./va
Re: [PATCH 5/5] ocxl: Remove some unused exported symbols
On 15/3/19 3:49 pm, Andrew Donnellan wrote:
On 13/3/19 3:07 pm, Alastair D'Silva wrote:
From: Alastair D'Silva
Remove some unused exported symbols.
Signed-off-by: Alastair D'Silva
See comments on v1
Also a couple of sparse warnings at
https://openpower.xyz/job/snowpatch/job/snowpatch-linux-sparse/4474//artifact/linux/actual_sparse_diff.txt
---
drivers/misc/ocxl/config.c | 2 --
drivers/misc/ocxl/ocxl_internal.h | 23 +++
include/misc/ocxl.h | 23 ---
3 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index 026ac2ac4f9c..c90c2e4875bf 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -299,7 +299,6 @@ int ocxl_config_check_afu_index(struct pci_dev *dev,
}
return 1;
}
-EXPORT_SYMBOL_GPL(ocxl_config_check_afu_index);
static int read_afu_name(struct pci_dev *dev, struct ocxl_fn_config
*fn,
struct ocxl_afu_config *afu)
@@ -535,7 +534,6 @@ int ocxl_config_get_pasid_info(struct pci_dev
*dev, int *count)
{
return pnv_ocxl_get_pasid_count(dev, count);
}
-EXPORT_SYMBOL_GPL(ocxl_config_get_pasid_info);
void ocxl_config_set_afu_pasid(struct pci_dev *dev, int pos, int
pasid_base,
u32 pasid_count_log)
diff --git a/drivers/misc/ocxl/ocxl_internal.h
b/drivers/misc/ocxl/ocxl_internal.h
index 321b29e77f45..06fd98c989c8 100644
--- a/drivers/misc/ocxl/ocxl_internal.h
+++ b/drivers/misc/ocxl/ocxl_internal.h
@@ -107,6 +107,29 @@ void ocxl_pasid_afu_free(struct ocxl_fn *fn, u32
start, u32 size);
int ocxl_actag_afu_alloc(struct ocxl_fn *fn, u32 size);
void ocxl_actag_afu_free(struct ocxl_fn *fn, u32 start, u32 size);
+/*
+ * Get the max PASID value that can be used by the function
+ */
+int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
+
+/*
+ * Check if an AFU index is valid for the given function.
+ *
+ * AFU indexes can be sparse, so a driver should check all indexes up
+ * to the maximum found in the function description
+ */
+int ocxl_config_check_afu_index(struct pci_dev *dev,
+ struct ocxl_fn_config *fn, int afu_idx);
+
+/**
+ * Update values within a Process Element
+ *
+ * link_handle: the link handle associated with the process element
+ * pasid: the PASID for the AFU context
+ * tid: the new thread id for the process element
+ */
+int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
+
struct ocxl_context *ocxl_context_alloc(void);
int ocxl_context_init(struct ocxl_context *ctx, struct ocxl_afu *afu,
struct address_space *mapping);
diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
index 4544573cc93c..9530d3be1b30 100644
--- a/include/misc/ocxl.h
+++ b/include/misc/ocxl.h
@@ -56,15 +56,6 @@ struct ocxl_fn_config {
int ocxl_config_read_function(struct pci_dev *dev,
struct ocxl_fn_config *fn);
-/*
- * Check if an AFU index is valid for the given function.
- *
- * AFU indexes can be sparse, so a driver should check all indexes up
- * to the maximum found in the function description
- */
-int ocxl_config_check_afu_index(struct pci_dev *dev,
- struct ocxl_fn_config *fn, int afu_idx);
-
/*
* Read the configuration space of a function for the AFU specified by
* the index 'afu_idx'. Fills in a ocxl_afu_config structure
@@ -74,11 +65,6 @@ int ocxl_config_read_afu(struct pci_dev *dev,
struct ocxl_afu_config *afu,
u8 afu_idx);
-/*
- * Get the max PASID value that can be used by the function
- */
-int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
-
/*
* Tell an AFU, by writing in the configuration space, the PASIDs that
* it can use. Range starts at 'pasid_base' and its size is a multiple
@@ -188,15 +174,6 @@ int ocxl_link_add_pe(void *link_handle, int
pasid, u32 pidr, u32 tidr,
void (*xsl_err_cb)(void *data, u64 addr, u64 dsisr),
void *xsl_err_data);
-/**
- * Update values within a Process Element
- *
- * link_handle: the link handle associated with the process element
- * pasid: the PASID for the AFU context
- * tid: the new thread id for the process element
- */
-int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
-
/*
* Remove a Process Element from the Shared Process Area for a link
*/
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com IBM Australia Limited
[PATCH] pci: endpoint: fix a potential NULL pointer dereference
In case alloc_workqueue, the fix returns -ENOMEM to avoid
potential NULL pointer dereferences.
Signed-off-by: Kangjie Lu
---
drivers/pci/endpoint/functions/pci-epf-test.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 3e86fa3c7da3..dc610eb1543a 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -570,6 +570,10 @@ static int __init pci_epf_test_init(void)
kpcitest_workqueue = alloc_workqueue("kpcitest",
WQ_MEM_RECLAIM | WQ_HIGHPRI, 0);
+ if (unlikely(!kpcitest_workqueue)) {
+ pr_err("Failed to allocate the kpcitest work queue\n");
+ return -ENOMEM;
+ }
ret = pci_epf_register_driver(_driver);
if (ret) {
pr_err("Failed to register pci epf test driver --> %d\n", ret);
--
2.17.1
[PATCH] tty: 8250: fix a missing check for pci_ioremap_bar
pci_ioremap_bar could fail. The fix captures the failure and
pass an error code upstream. This can avoid potential NULL
pointer dereferences in the future.
Signed-off-by: Kangjie Lu
---
drivers/tty/serial/8250/8250_lpss.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_lpss.c
b/drivers/tty/serial/8250/8250_lpss.c
index 98dbc796353f..e95332d8b35e 100644
--- a/drivers/tty/serial/8250/8250_lpss.c
+++ b/drivers/tty/serial/8250/8250_lpss.c
@@ -162,7 +162,7 @@ static const struct dw_dma_platform_data
qrk_serial_dma_pdata = {
.multi_block = {0},
};
-static void qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port *port)
+static int qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port *port)
{
struct uart_8250_dma *dma = >dma;
struct dw_dma_chip *chip = >dma_chip;
@@ -173,12 +173,14 @@ static void qrk_serial_setup_dma(struct lpss8250 *lpss,
struct uart_port *port)
chip->dev = >dev;
chip->irq = pci_irq_vector(pdev, 0);
chip->regs = pci_ioremap_bar(pdev, 1);
+ if (!chip->regs)
+ return -EIO;
chip->pdata = _serial_dma_pdata;
/* Falling back to PIO mode if DMA probing fails */
ret = dw_dma_probe(chip);
if (ret)
- return;
+ return ret;
pci_try_set_mwi(pdev);
@@ -192,6 +194,8 @@ static void qrk_serial_setup_dma(struct lpss8250 *lpss,
struct uart_port *port)
param->hs_polarity = true;
lpss->dma_maxburst = 8;
+
+ return 0;
}
static void qrk_serial_exit_dma(struct lpss8250 *lpss)
@@ -203,7 +207,7 @@ static void qrk_serial_exit_dma(struct lpss8250 *lpss)
dw_dma_remove(>dma_chip);
}
#else /* CONFIG_SERIAL_8250_DMA */
-static void qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port
*port) {}
+static int qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port *port)
{}
static void qrk_serial_exit_dma(struct lpss8250 *lpss) {}
#endif /* !CONFIG_SERIAL_8250_DMA */
@@ -220,8 +224,7 @@ static int qrk_serial_setup(struct lpss8250 *lpss, struct
uart_port *port)
port->irq = pci_irq_vector(pdev, 0);
- qrk_serial_setup_dma(lpss, port);
- return 0;
+ return qrk_serial_setup_dma(lpss, port);
}
static void qrk_serial_exit(struct lpss8250 *lpss)
--
2.17.1
tty: uartlite: GP fault when calling tty_unregister_driver()
This is on v5.0-11053-gebc551f2b8f9 on x86_64. (March 12, 2019) Just load uartlite module and then unload it. [ 75.334373] calling ulite_init+0x0/0x1000 [uartlite] @ 1655 [ 75.334634] initcall ulite_init+0x0/0x1000 [uartlite] returned 0 after 223 usecs [ 80.145544] kasan: CONFIG_KASAN_INLINE enabled [ 80.145578] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 80.145614] general protection fault: [#1] PREEMPT SMP KASAN PTI [ 80.145634] CPU: 3 PID: 1658 Comm: rmmod Not tainted 5.0.0mod #1 [ 80.145651] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version 4.10 01/08/2013 [ 80.145677] RIP: 0010:tty_unregister_driver+0x25/0x1d0 [ 80.145694] Code: 00 00 00 00 90 55 48 b8 00 00 00 00 00 fc ff df 48 89 e5 41 55 41 54 53 48 89 fb 48 83 c7 34 48 89 fa 48 c1 ea 03 48 83 ec 08 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 5e [ 80.145728] RSP: 0018:8880a41ffda0 EFLAGS: 00010286 [ 80.145744] RAX: dc00 RBX: RCX: 183a9a7b [ 80.145761] RDX: 0006 RSI: 0004 RDI: 0034 [ 80.145778] RBP: 8880a41ffdc0 R08: ed101483ff9f R09: ed101483ff9f [ 80.145796] R10: 0001 R11: ed101483ff9f R12: c1d4e040 [ 80.145814] R13: 8880a41ffef0 R14: 0800 R15: c1d4d3a0 [ 80.145832] FS: 7fe6d6029b80() GS:88811f40() knlGS: [ 80.145851] CS: 0010 DS: ES: CR0: 80050033 [ 80.145867] CR2: 55e9112790b8 CR3: a3742006 CR4: 000606e0 [ 80.145884] Call Trace: [ 80.145903] uart_unregister_driver+0x43/0x1b0 [ 80.145924] ulite_exit+0x1c/0x25 [uartlite] [ 80.145941] __x64_sys_delete_module+0x329/0x490 [ 80.145958] ? __ia32_sys_delete_module+0x490/0x490 [ 80.145976] ? blkcg_exit_queue+0x20/0x20 [ 80.145991] ? _raw_spin_unlock_irq+0x22/0x40 [ 80.146014] do_syscall_64+0xaa/0x310 [ 80.146028] ? prepare_exit_to_usermode+0x8b/0x150 [ 80.146046] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 80.146062] RIP: 0033:0x7fe6d5717f77 [ 80.146075] Code: 73 01 c3 48 8b 0d 21 af 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f1 ae 2b 00 f7 d8 64 89 01 48 [ 80.146111] RSP: 002b:7fffdcc101b8 EFLAGS: 0206 ORIG_RAX: 00b0 [ 80.146130] RAX: ffda RBX: 7fffdcc10218 RCX: 7fe6d5717f77 [ 80.146147] RDX: 000a RSI: 0800 RDI: 55e91126e7d8 [ 80.146164] RBP: 55e91126e770 R08: 7fffdcc0f131 R09: [ 80.146181] R10: 7fe6d57871c0 R11: 0206 R12: 7fffdcc103e0 [ 80.146199] R13: 7fffdcc1275b R14: 55e91126e260 R15: 55e91126e770 [ 80.146230] Modules linked in: uartlite(-) ctr ccm af_packet xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables bpfilter btrfs coretemp hwmon msr xor zstd_compress intel_rapl raid6_pq x86_pkg_temp_thermal hid_generic intel_powerclamp libcrc32c uvcvideo kvm_intel zstd_decompress usbmouse iTCO_wdt usbkbd kvm iTCO_vendor_support usbhid videobuf2_vmalloc videobuf2_memops hid videobuf2_v4l2 mei_hdcp videobuf2_common videodev arc4 iwldvm irqbypass media snd_hda_codec_hdmi mac80211 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel iwlwifi snd_hda_codec aesni_intel [ 80.146319] snd_hda_core aes_x86_64 crypto_simd snd_hwdep cryptd snd_pcm glue_helper sdhci_pci cqhci cfg80211 snd_timer intel_cstate intel_uncore uio_pdrv_genirq sdhci uio toshiba_acpi sparse_keymap sr_mod wmi cdrom mmc_core snd joydev pcspkr input_leds soundcore rfkill mousedev e1000e led_class intel_rapl_perf serio_raw industrialio rtc_cmos evdev mei_me mac_hid pcc_cpufreq thermal lpc_ich toshiba_haps mei battery ac sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua autofs4 [ 80.146617] ---[ end trace e7f9f1d70ea2ceb9 ]--- [ 80.146636] RIP: 0010:tty_unregister_driver+0x25/0x1d0 [ 80.146657] Code: 00 00 00 00 90 55 48 b8 00 00 00 00 00 fc ff df 48 89 e5 41 55 41 54 53 48 89 fb 48 83 c7 34 48 89 fa 48 c1 ea 03 48 83 ec 08 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 5e [ 80.146702] RSP: 0018:8880a41ffda0 EFLAGS: 00010286 [ 80.146730] RAX: dc00 RBX: RCX: 183a9a7b [ 80.146750] RDX: 0006 RSI: 0004 RDI: 0034 [ 80.146770] RBP: 8880a41ffdc0 R08: ed101483ff9f R09: ed101483ff9f [ 80.146790]
Re: [PATCH 5/5] ocxl: Remove some unused exported symbols
On 13/3/19 3:07 pm, Alastair D'Silva wrote:
From: Alastair D'Silva
Remove some unused exported symbols.
Signed-off-by: Alastair D'Silva
See comments on v1
---
drivers/misc/ocxl/config.c| 2 --
drivers/misc/ocxl/ocxl_internal.h | 23 +++
include/misc/ocxl.h | 23 ---
3 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index 026ac2ac4f9c..c90c2e4875bf 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -299,7 +299,6 @@ int ocxl_config_check_afu_index(struct pci_dev *dev,
}
return 1;
}
-EXPORT_SYMBOL_GPL(ocxl_config_check_afu_index);
static int read_afu_name(struct pci_dev *dev, struct ocxl_fn_config *fn,
struct ocxl_afu_config *afu)
@@ -535,7 +534,6 @@ int ocxl_config_get_pasid_info(struct pci_dev *dev, int
*count)
{
return pnv_ocxl_get_pasid_count(dev, count);
}
-EXPORT_SYMBOL_GPL(ocxl_config_get_pasid_info);
void ocxl_config_set_afu_pasid(struct pci_dev *dev, int pos, int pasid_base,
u32 pasid_count_log)
diff --git a/drivers/misc/ocxl/ocxl_internal.h
b/drivers/misc/ocxl/ocxl_internal.h
index 321b29e77f45..06fd98c989c8 100644
--- a/drivers/misc/ocxl/ocxl_internal.h
+++ b/drivers/misc/ocxl/ocxl_internal.h
@@ -107,6 +107,29 @@ void ocxl_pasid_afu_free(struct ocxl_fn *fn, u32 start,
u32 size);
int ocxl_actag_afu_alloc(struct ocxl_fn *fn, u32 size);
void ocxl_actag_afu_free(struct ocxl_fn *fn, u32 start, u32 size);
+/*
+ * Get the max PASID value that can be used by the function
+ */
+int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
+
+/*
+ * Check if an AFU index is valid for the given function.
+ *
+ * AFU indexes can be sparse, so a driver should check all indexes up
+ * to the maximum found in the function description
+ */
+int ocxl_config_check_afu_index(struct pci_dev *dev,
+ struct ocxl_fn_config *fn, int afu_idx);
+
+/**
+ * Update values within a Process Element
+ *
+ * link_handle: the link handle associated with the process element
+ * pasid: the PASID for the AFU context
+ * tid: the new thread id for the process element
+ */
+int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
+
struct ocxl_context *ocxl_context_alloc(void);
int ocxl_context_init(struct ocxl_context *ctx, struct ocxl_afu *afu,
struct address_space *mapping);
diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
index 4544573cc93c..9530d3be1b30 100644
--- a/include/misc/ocxl.h
+++ b/include/misc/ocxl.h
@@ -56,15 +56,6 @@ struct ocxl_fn_config {
int ocxl_config_read_function(struct pci_dev *dev,
struct ocxl_fn_config *fn);
-/*
- * Check if an AFU index is valid for the given function.
- *
- * AFU indexes can be sparse, so a driver should check all indexes up
- * to the maximum found in the function description
- */
-int ocxl_config_check_afu_index(struct pci_dev *dev,
- struct ocxl_fn_config *fn, int afu_idx);
-
/*
* Read the configuration space of a function for the AFU specified by
* the index 'afu_idx'. Fills in a ocxl_afu_config structure
@@ -74,11 +65,6 @@ int ocxl_config_read_afu(struct pci_dev *dev,
struct ocxl_afu_config *afu,
u8 afu_idx);
-/*
- * Get the max PASID value that can be used by the function
- */
-int ocxl_config_get_pasid_info(struct pci_dev *dev, int *count);
-
/*
* Tell an AFU, by writing in the configuration space, the PASIDs that
* it can use. Range starts at 'pasid_base' and its size is a multiple
@@ -188,15 +174,6 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32
pidr, u32 tidr,
void (*xsl_err_cb)(void *data, u64 addr, u64 dsisr),
void *xsl_err_data);
-/**
- * Update values within a Process Element
- *
- * link_handle: the link handle associated with the process element
- * pasid: the PASID for the AFU context
- * tid: the new thread id for the process element
- */
-int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid);
-
/*
* Remove a Process Element from the Shared Process Area for a link
*/
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com IBM Australia Limited
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote: > > On Thu, 14 Mar 2019 13:49:11 -0700 > Sultan Alsawaf wrote: > > > Perhaps I'm missing something, but if you want to know when a process has > > died > > after sending a SIGKILL to it, then why not just make the SIGKILL optionally > > block until the process has died completely? It'd be rather trivial to just > > store a pointer to an onstack completion inside the victim process' > > task_struct, > > and then complete it in free_task(). > > How would you implement such a method in userspace? kill() doesn't take > any parameters but the pid of the process you want to send a signal to, > and the signal to send. This would require a new system call, and be > quite a bit of work. That's what the pidfd work is for. Please read the original threads about the motivation and design of that facility. > If you can solve this with an ebpf program, I > strongly suggest you do that instead. Regarding process death notification: I will absolutely not support putting aBPF and perf trace events on the critical path of core system memory management functionality. Tracing and monitoring facilities are great for learning about the system, but they were never intended to be load-bearing. The proposed eBPF process-monitoring approach is just a variant of the netlink proposal we discussed previously on the pidfd threads; it has all of its drawbacks. We really need a core system call --- really, we've needed robust process management since the creation of unix --- and I'm glad that we're finally getting it. Adding new system calls is not expensive; going to great lengths to avoid adding one is like calling a helicopter to avoid crossing the street. I don't think we should present an abuse of the debugging and performance monitoring infrastructure as an alternative to a robust and desperately-needed bit of core functionality that's neither hard to add nor complex to implement nor expensive to use. Regarding the proposal for a new kernel-side lmkd: when possible, the kernel should provide mechanism, not policy. Putting the low memory killer back into the kernel after we've spent significant effort making it possible for userspace to do that job. Compared to kernel code, more easily understood, more easily debuggable, more easily updated, and much safer. If we *can* move something out of the kernel, we should. This patch moves us in exactly the wrong direction. Yes, we need *something* that sits synchronously astride the page allocation path and does *something* to stop a busy beaver allocator that eats all the available memory before lmkd, even mlocked and realtime, can respond. The OOM killer is adequate for this very rare case. With respect to kill timing: Tim is right about the need for two levels of policy: first, a high-level process prioritization and memory-demand balancing scheme (which is what OOM score adjustment code in ActivityManager amounts to); and second, a low-level process-killing methodology that maximizes sustainable memory reclaim and minimizes unwanted side effects while killing those processes that should be dead. Both of these policies belong in userspace --- because they *can* be in userspace --- and userspace needs only a few tools, most of which already exist, to do a perfectly adequate job. We do want killed processes to die promptly. That's why I support boosting a process's priority somehow when lmkd is about to kill it. The precise way in which we do that --- involving not only actual priority, but scheduler knobs, cgroup assignment, core affinity, and so on --- is a complex topic best left to userspace. lmkd already has all the knobs it needs to implement whatever priority boosting policy it wants. Hell, once we add a pidfd_wait --- which I plan to work on, assuming nobody beats me to it, after pidfd_send_signal lands --- you can imagine a general-purpose priority inheritance mechanism expediting process death when a high-priority process waits on a pidfd_wait handle for a condemned process. You know you're on the right track design-wise when you start seeing this kind of elegant constructive interference between seemingly-unrelated features. What we don't need is some kind of blocking SIGKILL alternative or backdoor event delivery system. We definitely don't want to have to wait for a process's parent to reap it. Instead, we want to wait for it to become a zombie. That's why I designed my original exithand patch to fire death notification upon transition to the zombie state, not upon process table removal, and I expect pidfd_wait (or whatever we call it) to act the same way. In any case, there's a clear path forward here --- general-purpose, cheap, and elegant --- and we should just focus on doing that instead of more complex proposals with few advantages.
Re: [PATCH 4/5] lib/list_sort: Simplify and remove MAX_LIST_LENGTH_BITS
On Thu, 14 Mar 2019 at 11:10:41 +0200, Andy Shevchenko wrote:
> On Tue, Mar 05, 2019 at 03:06:44AM +, George Spelvin wrote:
>> +for (bit = 1; count & bit; bit <<= 1) {
>> +cur = merge(priv, (cmp_func)cmp, pending, cur);
>> +pending = pending->prev; /* Untouched by merge() */
>> }
>
> Wouldn't be it the same to
>
> bit = ffz(count);
> while (bit--) {
> ...
> }
> ?
>
> Though I dunno which one is generating better code.
One question I should ask everyone: should "count" be 32 or 64 bits
on 64-bit machines? That would let x86 save a few REX bytes. (815
vs. 813 byte code, if anyone cares.)
Allegedy ARM can save a few pJ by gating the high 32
bits of the ALU.
Most other 64-bit processors would prefer 64-bit operations as
it saves masking operations.
If we never sort a list with more than 2^32 entries, it
makes no difference.
If we use a 32-bit count and we *do* sort a list with more than
2^32 entries, then it still sorts, but the performance degrades to
O((n/2^32)^2).
Just how often do we expect the kernel to face lists that long?
(Note that the old code was O((n/2^20)^2).)
In the code, I could do something like
#ifdef CONFIG_X86_64
/* Comment explaining why */
typedef uint32_t count_t;
#else
typedef size_t count_t;
#endif
...
count_t count = 0;
Re: [PATCH] perf annotate: Remove hist__account_cycles from callback
On 3/14/2019 10:17 PM, Jin, Yao wrote: On 3/14/2019 8:04 PM, Jiri Olsa wrote: On Wed, Mar 13, 2019 at 04:22:54AM +0800, Jin Yao wrote: The hist__account_cycles is executed when the hist_iter__branch_callback is called. But it looks it's not necessary. In hist__account_cycles, it already walks on all branch entries. This patch moves the hist__account_cycles out of callback, now the data processing is much faster than before. For example, perf record -b ... perf annotate The before/after output should be no change. so in the old code it was called multiple times per sample, while after your change it's called just once per sample it increases cycles stats for symbol, so it's strange the behaviour is the same.. could you please exaplin this in more detail? In __symbol__account_cycles, ch[offset].num_aggr++; ch[offset].cycles_aggr += cycles; In annotation__compute_ipc, al = notes->offsets[offset]; al->cycles = ch->cycles_aggr / ch->num_aggr; So the num_aggr and cycles_aggr are both increased n times, then the final result is the same. There might be another potential issue in annotation__count_and_fill. /* Hide data when there are too many overlaps. */ if (ch->reset >= 0x7fff || ch->reset >= ch->num / 2) return; When ch->reset is 0 and ch->num is 1, it returns directly. But for this case, the data doesn't need to be hidden since there is no overlap happening. I will post v2 and add this fix. Thanks Jin Yao Signed-off-by: Jin Yao --- tools/perf/builtin-annotate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c index 67f9d9f..77deb3a 100644 --- a/tools/perf/builtin-annotate.c +++ b/tools/perf/builtin-annotate.c @@ -159,8 +159,6 @@ static int hist_iter__branch_callback(struct hist_entry_iter *iter, struct perf_evsel *evsel = iter->evsel; int err; - hist__account_cycles(sample->branch_stack, al, sample, false); - there's similar code in perf report, could you please cover that as well? Sure, let me have a try. Thanks Jin Yao thanks, jirka bi = he->branch_info; err = addr_map_symbol__inc_samples(>from, sample, evsel); @@ -199,6 +197,8 @@ static int process_branch_callback(struct perf_evsel *evsel, if (a.map != NULL) a.map->dso->hit = 1; + hist__account_cycles(sample->branch_stack, al, sample, false); + ret = hist_entry_iter__add(, , PERF_MAX_STACK_DEPTH, ann); return ret; } -- 2.7.4
[PATCH] security: inode: fix a missing check for securityfs_create_file
securityfs_create_file may fail. The fix checks its status and
returns EFAULT upstream if it fails.
Signed-off-by: Kangjie Lu
---
security/inode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/security/inode.c b/security/inode.c
index b7772a9b315e..11d9a6bc2161 100644
--- a/security/inode.c
+++ b/security/inode.c
@@ -339,6 +339,11 @@ static int __init securityfs_init(void)
#ifdef CONFIG_SECURITY
lsm_dentry = securityfs_create_file("lsm", 0444, NULL, NULL,
_ops);
+ if (IS_ERR(lsm_dentry)) {
+ unregister_filesystem(_type);
+ sysfs_remove_mount_point(kernel_kobj, "security");
+ return -EFAULT;
+ }
#endif
return 0;
}
--
2.17.1
[PATCH] sound: sb8: add a check for request_region
In case request_region fails, the fix returns an error code to
avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu
---
sound/isa/sb/sb8.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/isa/sb/sb8.c b/sound/isa/sb/sb8.c
index aa2a83eb81a9..dc27a480c2d9 100644
--- a/sound/isa/sb/sb8.c
+++ b/sound/isa/sb/sb8.c
@@ -111,6 +111,10 @@ static int snd_sb8_probe(struct device *pdev, unsigned int
dev)
/* block the 0x388 port to avoid PnP conflicts */
acard->fm_res = request_region(0x388, 4, "SoundBlaster FM");
+ if (!acard->fm_res) {
+ err = -EBUSY;
+ goto _err;
+ }
if (port[dev] != SNDRV_AUTO_PORT) {
if ((err = snd_sbdsp_create(card, port[dev], irq[dev],
--
2.17.1
[PATCH] sound: echoaudio: add a check for ioremap_nocache
In case ioremap_nocache fails, the fix releases chip and returns
an error code upstream to avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu
---
sound/pci/echoaudio/echoaudio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/sound/pci/echoaudio/echoaudio.c b/sound/pci/echoaudio/echoaudio.c
index ea876b0b02b9..dc0084dc8550 100644
--- a/sound/pci/echoaudio/echoaudio.c
+++ b/sound/pci/echoaudio/echoaudio.c
@@ -1952,6 +1952,11 @@ static int snd_echo_create(struct snd_card *card,
}
chip->dsp_registers = (volatile u32 __iomem *)
ioremap_nocache(chip->dsp_registers_phys, sz);
+ if (!chip->dsp_registers) {
+ dev_err(chip->card->dev, "ioremap failed\n");
+ snd_echo_free(chip);
+ return -ENOMEM;
+ }
if (request_irq(pci->irq, snd_echo_interrupt, IRQF_SHARED,
KBUILD_MODNAME, chip)) {
--
2.17.1
[PATCH] futex:fix robust futex alignment exception
From: chen jie
trinity test bug fix:
/tmp/trinity --children 4 --quiet -N 1000 --logging=off -X -x
perf_event_open --enable-fds=testfile
[1542.195981] Task track:
trinity-c3(6911)>trinity-main(28313)>sh(839)>bash(824)>sshd(820)>sshd(662)>init(1)
[11542.214694] Alignment trap: not handling instruction e1915f9f at []
[11542.214724] Unhandled fault: alignment exception (0x011) at 0x000265f9
[11542.214749] pgd = edde
[11542.214774] [000265f9] *pgd=84aa9831, *pte=bc10359f, *ppte=bc103e7e
[11542.214851] Internal error: : 11 [#1] SMP ARM
[11542.214857] Modules linked in: rtos_snapshot(O) rsm(O) nfsv3 veth(O)
pthread_lsof(O) higmac(O) comm(O) nand mtdblock mtd_blkdevs nand_ecc nand_ids
pramdisk(O) rtos_kbox_panic(O) double_cluster(O) uart_suspend(O) cache_ops(O)
nfsd nfs_acl exportfs auth_rpcgss nfs lockd sunrpc oid_registry grace physmap
cfi_probe cfi_cmdset_0002 cfi_util mtd gen_probe chipreg ohci_platform
ehci_platform ohci_hcd ehci_hcd usb_device_hisi(O) vfat fat sd_mod
enable_uart_rx(O) [last unloaded: rtos_snapshot]
[11542.215042] CPU: 3 PID: 6911 Comm: trinity-c3 Tainted: GB W O
4.1.12 #1
[11542.215048] Hardware name: Hisilicon A9
[11542.215055] task: c3df8a20 ti: ebb2c000 task.ti: ebb2c000
[11542.215071] PC is at cmpxchg_futex_value_locked+0x44/0x88
[11542.215081] LR is at handle_futex_death+0x78/0xcc
[11542.215090] pc : []lr : []psr: 6213
sp : ebb2dee4 ip : fff2 fp : fff2
[11542.215096] r10: 000238e3 r9 : r8 : 1000
[11542.215103] r7 : c3df8a20 r6 : r5 : 1aff r4 : ebb2def4
[11542.215110] r3 : 4000 r2 : 1aff r1 : 000265f9 r0 : 410265fc
[11542.215119] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[11542.215126] Control: 1ac5387d Table: ae7e004a DAC:
[11542.215133] Process trinity-c3 (pid: 6911, stack limit = 0xebb2c210)
[11542.215140] Stack: (0xebb2dee4 to 0xebb2e000)
[11542.215151] dee0: 000265f9 1aff c017da50 000265f9 c3df8a20
b5ebc000 0800
[11542.215161] df00: c3df8a20 1000 1000 c017dba8 c3df8a20 c399ef40
c3df8a20
[11542.215172] df20: c399ef40 c399ef40 00f8 c0107b84 ebb2c000 0001
0094d810 c011b40c
[11542.215182] df40: c3df8a20 c399ef40 c3df8a20 c399ef40 0094d830 c011f9a4
00f8
[11542.215192] df60: c0107b84 c0197388 2d16 ef1d3520 0094d830
00f8 c0107b84
[11542.215203] df80: ebb2c000 0200 0094d810 c0120250 00097d80 0094d8a4
0094d830 c01202a8
[11542.215213] dfa0: c0107b6c 00097d80 0094d8a4 b6f0f4c0
b63ef000
[11542.215223] dfc0: 00097d80 0094d8a4 0094d830 00f8 0001 0094db88
0094db94 0094d810
[11542.215233] dfe0: 00097d64 be938310 00017a40 b6e1a340 6210
[11542.215247] [] (cmpxchg_futex_value_locked) from []
(handle_futex_death+0x78/0xcc)
[11542.215259] [] (handle_futex_death) from []
(exit_robust_list+0x104/0x160)
[11542.215273] [] (exit_robust_list) from []
(mm_release+0x1c/0x108)
[11542.215287] [] (mm_release) from [] (do_exit+0x218/0x9a4)
[11542.215299] [] (do_exit) from []
(do_group_exit+0xac/0xf4)
[11542.215311] [] (do_group_exit) from []
(__wake_up_parent+0x0/0x18)
[11542.215321] Code: 0dc0e0e3 0a1a 5bf07ff5 00f091f5 (9f5f91e1)
[11542.217918] CPU 1 will stop doing anything useful since another CPU has
crashed
[11542.217924] CPU 0 will stop doing anything useful since another CPU has
crashed
[11542.217930] CPU 2 will stop doing anything useful since another CPU has
crashed
[11542.218626] Loading crashdump kernel...
[11542.218668] Bye!
Signed-off-by: chen jie
---
kernel/futex.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/futex.c b/kernel/futex.c
index a0514e0..70231c4 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3440,6 +3440,9 @@ static int handle_futex_death(u32 __user *uaddr, struct
task_struct *curr, int p
{
u32 uval, uninitialized_var(nval), mval;
+ if (((unsigned long)uaddr & 0x3) > 0)
+ return -1;
+
retry:
if (get_user(uval, uaddr))
return -1;
--
1.8.3.4
[PATCH] sound: cs43130: fix a NULL pointer dereference
In case create_singlethread_workqueue fails, the fix returns
-ENOMEM to avoid potential NULL pointer dereference.
Signed-off-by: Kangjie Lu
---
sound/soc/codecs/cs43130.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/codecs/cs43130.c b/sound/soc/codecs/cs43130.c
index 3f7b255587e6..80d672710eae 100644
--- a/sound/soc/codecs/cs43130.c
+++ b/sound/soc/codecs/cs43130.c
@@ -2322,6 +2322,8 @@ static int cs43130_probe(struct snd_soc_component
*component)
return ret;
cs43130->wq = create_singlethread_workqueue("cs43130_hp");
+ if (!cs43130->wq)
+ return -ENOMEM;
INIT_WORK(>work, cs43130_imp_meas);
}
--
2.17.1
[PATCH] sound: rt5645: fix a NULL pointer dereference
devm_kcalloc() may fail and return NULL. The fix returns ENOMEM in case it fails to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu --- sound/soc/codecs/rt5645.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index 9a0751978090..f842775dbf2c 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -3419,6 +3419,9 @@ static int rt5645_probe(struct snd_soc_component *component) RT5645_HWEQ_NUM, sizeof(struct rt5645_eq_param_s), GFP_KERNEL); + if (!rt5645->eq_param) + return -ENOMEM; + return 0; } -- 2.17.1
[PATCH] sound: soc-pcm: add a check to avoid NULL pointer dereference
In case debugfs_create_u32 fails, the fix frees memory and returns
an error to notify callers.
Signed-off-by: Kangjie Lu
---
sound/soc/soc-pcm.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 0d5ec68a1e50..a7d88ed8ebb5 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -1231,15 +1231,21 @@ static int dpcm_be_connect(struct snd_soc_pcm_runtime
*fe,
list_add(>list_be, >dpcm[stream].be_clients);
list_add(>list_fe, >dpcm[stream].fe_clients);
- dev_dbg(fe->dev, "connected new DPCM %s path %s %s %s\n",
- stream ? "capture" : "playback", fe->dai_link->name,
- stream ? "<-" : "->", be->dai_link->name);
-
#ifdef CONFIG_DEBUG_FS
- if (fe->debugfs_dpcm_root)
+ if (fe->debugfs_dpcm_root) {
dpcm->debugfs_state = debugfs_create_u32(be->dai_link->name,
0644,
fe->debugfs_dpcm_root, >state);
+ if (!dpcm->debugfs_state) {
+ kfree(dpcm);
+ return -ENOMEM;
+ }
+ }
#endif
+
+ dev_dbg(fe->dev, "connected new DPCM %s path %s %s %s\n",
+ stream ? "capture" : "playback", fe->dai_link->name,
+ stream ? "<-" : "->", be->dai_link->name);
+
return 1;
}
--
2.17.1
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Thu, Mar 14, 2019 at 11:16:41PM -0400, Steven Rostedt wrote: > How would you implement such a method in userspace? kill() doesn't take > any parameters but the pid of the process you want to send a signal to, > and the signal to send. This would require a new system call, and be > quite a bit of work. If you can solve this with an ebpf program, I > strongly suggest you do that instead. This can be done by introducing a new signal number that provides SIGKILL functionality while blocking (maybe SIGKILLBLOCK?). Thanks, Sultan
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Thu, Mar 14, 2019 at 10:54:48PM -0400, Joel Fernandes wrote: > I'm not sure if that makes much semantic sense for how the signal handling is > supposed to work. Imagine a parent sends SIGKILL to its child, and then does > a wait(2). Because the SIGKILL blocks in your idea, then the wait cannot > execute, and because the wait cannot execute, the zombie task will not get > reaped and so the SIGKILL senders never gets unblocked and the whole thing > just gets locked up. No? I don't know it just feels incorrect. Block until the victim becomes a zombie instead. > Further, in your idea adding stuff to task_struct will simply bloat it - when > this task can easily be handled using eBPF without making any kernel changes. > Either by probing sched_process_free or sched_process_exit tracepoints. > Scheduler maintainers generally frown on adding stuff to task_struct > pointlessly there's a good reason since bloating it effects the performance > etc, and something like this would probably never be ifdef'd out behind a > CONFIG. Adding something to task_struct is just the easiest way to test things for experimentation. This can be avoided in my suggestion by passing the pointer to a completion via the relevant functions, and then completing it at the time the victim transitions to a zombie state. I understand it's possible to use eBPF for this, but it seems kind of messy since this functionality is something that I think others would want provided by the kernel (i.e., anyone using PSI to implement their own OOM killer daemon similar to LMKD). Thanks, Sultan
Re: [PATCH 1/5] lib/sort: Make swap functions more generic
>> swap_bytes / swap_4byte_words / swap_8byte_words >> swap_bytes / swap_ints / swap_longs >> swap_1 / swap_4 / swap_8 >> Pistols at dawn? On Thu, 14 Mar 2019 at 22:59:55 +0300, Andrey Abramov wrote: > Yes, in my opinion, swap_bytes / swap_ints / swap_longs are the > most readable because we have both swap_ints and swap_longs functions > (in one file near each other), so I don't think that there will be > any confusion about size. Yes, that's what I thought. They're three related but different functions, suffixed _bytes, _ints, and _longs. What could the difference possibly be? And if anyone has any lingering doubts, the functions are right there, with exquisitely clear comments. No to mention where they're used. Is "is_aligned(base, size, 8)" remotely obscure? Especially in context: if (is_aligned(base, size, 8)) swap_func = swap_longs; else if (is_aligned(base, size, 4)) swap_func = swap_ints; else swap_func = swap_bytes; What subtle and mysterious code. > But actually, it doesn't matter which name will you take, because > the meaning of each, in my opinion, is obvious enough, so I don't > mind about any of these options. I'm just amazed that this piece of bikeshedding is the most contentious thing about the patch series. I mean, if I'd named them: llanfairpwllgwyngyll() shravanabelagola() zheleznodorozhny() or peckish() esuriant() hungry() then yes, those would be bad names. I prefer the shorter _ints and _longs names, but this is just not a hill I want to die on.
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Thu, 14 Mar 2019 13:49:11 -0700 Sultan Alsawaf wrote: > Perhaps I'm missing something, but if you want to know when a process has died > after sending a SIGKILL to it, then why not just make the SIGKILL optionally > block until the process has died completely? It'd be rather trivial to just > store a pointer to an onstack completion inside the victim process' > task_struct, > and then complete it in free_task(). How would you implement such a method in userspace? kill() doesn't take any parameters but the pid of the process you want to send a signal to, and the signal to send. This would require a new system call, and be quite a bit of work. If you can solve this with an ebpf program, I strongly suggest you do that instead. -- Steve
Re: [PATCH] scripts/spelling.txt: add more typos to spelling.txt and sort
Does it makes sense to list every typo that is simply a transposition of characters or a character omitted? This file will become very large very quickly if we do that. Such errors can be found algorithmically where the correct spelling is known. E.g. the file contains 'algorithm' so 'algrthm' can easily be obtained programatically. Suggest you restrict this to common misspellings. That's not a NAK and I'm not the relevant maintainer. Just my $0.02. -- On Fri, 15 Mar 2019, Like Xu wrote: > Here are some of the more common spelling mistakes and typos that I've > found while fixing up spelling mistakes in the kernel. > > Signed-off-by: Like Xu > --- > scripts/spelling.txt | 579 > +++ > 1 file changed, 492 insertions(+), 87 deletions(-) > > diff --git a/scripts/spelling.txt b/scripts/spelling.txt > index 86b8733..dcd25a3 100644 > --- a/scripts/spelling.txt > +++ b/scripts/spelling.txt > @@ -21,11 +21,14 @@ absolut||absolute > absoulte||absolute > acccess||access > acceess||access > +accelaration||acceleration > acceleratoin||acceleration > +acceleratrion||acceleration > accelleration||acceleration > accesing||accessing > accesnt||accent > accessable||accessible > +accessiable||accessible > accesss||access > accidentaly||accidentally > accidentually||accidentally > @@ -39,45 +42,58 @@ accout||account > accquire||acquire > accquired||acquired > accross||across > +accss||access > acessable||accessible > acess||access > +acheived||achieved > achitecture||architecture > acient||ancient > acitions||actions > acitve||active > acknowldegement||acknowledgment > acknowledgement||acknowledgment > +acknowleding||acknowledging > ackowledge||acknowledge > ackowledged||acknowledged > +ackowledgement||acknowledgement > +ackowledges||acknowledges > acording||according > -activete||activate > actived||activated > +activete||activate > actualy||actually > acumulating||accumulating > acumulator||accumulator > +acutally||actually > adapater||adapter > +adddress||address > +adderss||address > addional||additional > additionaly||additionally > +additionnally||additionally > +additoinal||additional > additonal||additional > addres||address > -adddress||address > addreses||addresses > addresss||address > addrress||address > aditional||additional > aditionally||additionally > aditionaly||additionally > +adjusment||adjustment > adminstrative||administrative > adress||address > adresses||addresses > adrresses||addresses > advertisment||advertisement > adviced||advised > +advnace||advance > afecting||affecting > +affvecs||affects > againt||against > agaist||against > aggreataon||aggregation > aggreation||aggregation > +agruments||arguments > albumns||albums > alegorical||allegorical > algined||aligned > @@ -87,12 +103,15 @@ algoritm||algorithm > algoritms||algorithms > algorrithm||algorithm > algorritm||algorithm > +algrthm||algorithm > aligment||alignment > alignement||alignment > allign||align > alligned||aligned > alllocate||allocate > alloated||allocated > +allocagtor||allocator > +allocas||allices > allocatote||allocate > allocatrd||allocated > allocte||allocate > @@ -103,23 +122,29 @@ alogrithm||algorithm > alot||a lot > alow||allow > alows||allows > +alreaady||already > altough||although > alue||value > +amacout||mahout > ambigious||ambiguous > +ammount||amount > +ammounts||amounts > amoung||among > amout||amount > amplifer||amplifier > amplifyer||amplifier > -an union||a union > -an user||a user > -an userspace||a userspace > -an one||a one > +analagous||analogous > +analogous||analogous > analysator||analyzer > ang||and > anniversery||anniversary > annoucement||announcement > anomolies||anomalies > anomoly||anomaly > +an one||a one > +an union||a union > +an user||a user > +an userspace||a userspace > anway||anyway > aplication||application > appearence||appearance > @@ -134,48 +159,68 @@ approriate||appropriate > approriately||appropriately > apropriate||appropriate > aquainted||acquainted > +aquaris||Aquarius > +aquire||acquire > aquired||acquired > aquisition||acquisition > arbitary||arbitrary > +arbitralrily||arbitrarily > +arbitray||arbitrary > architechture||architecture > arguement||argument > arguements||arguments > +argumetns||arguments > aritmetic||arithmetic > arne't||aren't > arraival||arrival > artifical||artificial > artillary||artillery > asign||assign > +assebmly||assembly > asser||assert > assertation||assertion > assertting||asserting > +assgined||assigned > assiged||assigned > assigment||assignment > assigments||assignments > assistent||assistant > +assmebly||assembly > +assocaition||association > assocation||association > +assocativity||associativity > associcated||associated > +assoicatied||associated > assotiated||associated > asssert||assert > assum||assume > +assumming||assuming > assumtpion||assumption > +asume||assume >
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Thu, Mar 14, 2019 at 01:49:11PM -0700, Sultan Alsawaf wrote: > On Thu, Mar 14, 2019 at 10:47:17AM -0700, Joel Fernandes wrote: > > About the 100ms latency, I wonder whether it is that high because of > > the way Android's lmkd is observing that a process has died. There is > > a gap between when a process memory is freed and when it disappears > > from the process-table. Once a process is SIGKILLed, it becomes a > > zombie. Its memory is freed instantly during the SIGKILL delivery (I > > traced this so that's how I know), but until it is reaped by its > > parent thread, it will still exist in /proc/ . So if testing the > > existence of /proc/ is how Android is observing that the process > > died, then there can be a large latency where it takes a very long > > time for the parent to actually reap the child way after its memory > > was long freed. A quicker way to know if a process's memory is freed > > before it is reaped could be to read back /proc//maps in > > userspace of the victim , and that file will be empty for zombie > > processes. So then one does not need wait for the parent to reap it. I > > wonder how much of that 100ms you mentioned is actually the "Waiting > > while Parent is reaping the child", than "memory freeing time". So > > yeah for this second problem, the procfds work will help. > > > > By the way another approach that can provide a quick and asynchronous > > notification of when the process memory is freed, is to monitor > > sched_process_exit trace event using eBPF. You can tell eBPF the PID > > that you want to monitor before the SIGKILL. As soon as the process > > dies and its memory is freed, the eBPF program can send a notification > > to user space (using the perf_events polling infra). The > > sched_process_exit fires just after the mmput() happens so it is quite > > close to when the memory is reclaimed. This also doesn't need any > > kernel changes. I could come up with a prototype for this and > > benchmark it on Android, if you want. Just let me know. > > Perhaps I'm missing something, but if you want to know when a process has died > after sending a SIGKILL to it, then why not just make the SIGKILL optionally > block until the process has died completely? It'd be rather trivial to just > store a pointer to an onstack completion inside the victim process' > task_struct, > and then complete it in free_task(). I'm not sure if that makes much semantic sense for how the signal handling is supposed to work. Imagine a parent sends SIGKILL to its child, and then does a wait(2). Because the SIGKILL blocks in your idea, then the wait cannot execute, and because the wait cannot execute, the zombie task will not get reaped and so the SIGKILL senders never gets unblocked and the whole thing just gets locked up. No? I don't know it just feels incorrect. Further, in your idea adding stuff to task_struct will simply bloat it - when this task can easily be handled using eBPF without making any kernel changes. Either by probing sched_process_free or sched_process_exit tracepoints. Scheduler maintainers generally frown on adding stuff to task_struct pointlessly there's a good reason since bloating it effects the performance etc, and something like this would probably never be ifdef'd out behind a CONFIG. thanks, - Joel
RE: [RFC PATCH 0/3] Add support of busfreq
+Jacky and Leonard, Ranjani Hi Alexandre, > From: Alexandre Bailon [mailto:abai...@baylibre.com] > > This series implements busfreq, a framework used in MXP's tree to scale the > interconnect and dram frequencies. > In the vendor tree, device's driver request for a performance level, which is > used to scale the frequencies. > This series implements it using the interconnect framework. > Devices' driver request for bandwidth which is use by busfreq to determine a > performance level, and then scale the frequency. > > Busfreq is quite generic. It could be used for any i.MX SoC. > A busfreq platform driver just have to define a list of interconnect nodes, > and > some OPPs. > It's really great to see this patch series. And it should be the correct direction we're heading to upstream busfreq support. > This series is sent as RFC mostly because the current support of i.MX SoC > won't > benefit of busfreq framework, because the clocks' driver don't support > interconnect / dram frequency scaling. > As exemple, this series implements busfreq for i.MX8MM whose upstreaming > is in progress. Because this relies on ATF to do the frequency scaling, it > won't > be hard make it work. > How can I test this patch series? Any additional patches you can share with us? Or what else we need to do to test it? We can help with it. Regards Dong Aisheng > As exemple, this series implements busfreq for Alexandre Bailon (3): > drivers: interconnect: Add a driver for i.MX SoC > drivers: interconnect: imx: Add support of i.MX8MM > dt-bindings: interconnect: Document fsl,busfreq-imx8mm bindings > > .../bindings/interconnect/imx8mm.txt | 24 + > drivers/interconnect/Kconfig | 1 + > drivers/interconnect/Makefile | 1 + > drivers/interconnect/imx/Kconfig | 17 + > drivers/interconnect/imx/Makefile | 2 + > drivers/interconnect/imx/busfreq-imx8mm.c | 132 > drivers/interconnect/imx/busfreq.c| 570 > ++ > drivers/interconnect/imx/busfreq.h| 123 > include/dt-bindings/interconnect/imx8mm.h | 37 ++ > 9 files changed, 907 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interconnect/imx8mm.txt > create mode 100644 drivers/interconnect/imx/Kconfig create mode > 100644 drivers/interconnect/imx/Makefile create mode 100644 > drivers/interconnect/imx/busfreq-imx8mm.c > create mode 100644 drivers/interconnect/imx/busfreq.c > create mode 100644 drivers/interconnect/imx/busfreq.h > create mode 100644 include/dt-bindings/interconnect/imx8mm.h > > -- > 2.19.2
[PATCH] perf tools: return errcode in cs_etm__process_auxtrace_info
From: YueHaibing
'err' is set in err path, but it's not returned to callers.
Also fix a pass zero to PTR_ERR issue.
Fixes: cd8bfd8c973e ("perf tools: Add processing of coresight metadata")
Signed-off-by: YueHaibing
---
tools/perf/util/cs-etm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 1108049..111f33c 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1908,7 +1908,7 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
/* Something went wrong, no need to continue */
if (!inode) {
- err = PTR_ERR(inode);
+ err = -ENOMEM;
goto err_free_metadata;
}
@@ -2023,5 +2023,5 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err_free_hdr:
zfree();
- return -EINVAL;
+ return err;
}
--
2.7.0
Re: [RFC 1/2] dt-bindings: imx6q-pcie: Add support for i.MX8QM/QXP PCIe
On Wed, Mar 13, 2019 at 2:15 AM Richard Zhu wrote: > > Add codes needed to support i.MX8QM/QXP PCIe. > - HSIO(High Speed IO) subsystem is new defined on i.MX8QM/QXP. > The PCIe and SATA modules are contained in the HSIO subsystem. There > are two PCIe, one SATA controllers and three mixed lane PHYs on > i.MX8QM. There are three use cases of the HSIO subsystem on i.MX8QM. > 1. PCIea 2 lanes and one SATA AHCI port. > 2. PCIea 1 lane, PCIeb 1 lane and one SATA AHCI port. > 3. PCIea 2 lanes, PCIeb 1 lane. > i.MX8QXP only has PCIeb controller and one lane PHY. > Use the hsio-cfg property to specify the different modes. > - The HSIO address map as viewed from system level is as shown below. > address [31:24]Local addressTargetAddress Size > 5F 0HSIO 16MB > 60-6F 40-4FHSIO 256MB > 70-7F 80-8FHSIO 256MB > The property local-addr is required to specify it. > - Both external OSC and internal PLL can be used as PCIe reference > clock, use the ext_osc property to distinguish them. > - clock request GPIO for controlling the PCI reference clock request > signal. And should be configure OD when L1SS maybe enabled later. > - One more power domain HSIO_GPIO and clock PCIE_PER are required by > i.MX8QM/QXP PCIe. > Add these specific properties to enable i.MX8QM/QXP PCIe. > > Signed-off-by: Richard Zhu > --- > .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 21 > + > 1 file changed, 21 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > index a7f5f5a..f7586c9 100644 > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > @@ -10,6 +10,8 @@ Required properties: > - "fsl,imx6qp-pcie" > - "fsl,imx7d-pcie" > - "fsl,imx8mq-pcie" > + - "fsl,imx8qm-pcie" > + - "fsl,imx8qxp-pcie" > - reg: base address and length of the PCIe controller > - interrupts: A list of interrupt outputs of the controller. Must contain an >entry for each entry in the interrupt-names property. > @@ -38,6 +40,10 @@ Optional properties: >The regulator will be enabled when initializing the PCIe host and >disabled either as part of the init process or when shutting down the >host. > +- clkreq-gpio: Should specify the GPIO for controlling the PCI reference > clock > + request signal. > +- ext_osc: External OSC is used as PCIe reference clock or not. 0: Internal > + PLL. 1: External OSC. Forgot to mention one thing in my very first reply, so I'll mention it here. I think figuring out the way to add support for external vs internal reference bus clock (that "ext_osc" binding above) is going to be a whole other discussion. It might be easier/more expedient to focus on just one particular use-case first (say external oscillator only), get it all done and accepted and then return to this particular feature in a separate series/discussion. However, that's just how I'd approach this, so, please don't feel compelled to do it that way just because I suggested it. Thanks, Andrey Smirnov
Re: [RFC 2/2] PCI: imx6: Add support for i.MX8QM/QXP PCIe
On Thu, Mar 14, 2019 at 2:18 AM Richard Zhu wrote:
>
> Hi Andrey:
> Thanks a lot for your review comments.
>
> Best Regards
> Richard Zhu
> Office: 86-21-28937189
> Mobile: 86-13386059786
>
>
> > -Original Message-
> > From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> > Sent: 2019年3月14日 4:20
> > To: Richard Zhu
> > Cc: bhelg...@google.com; lorenzo.pieral...@arm.com;
> > l.st...@pengutronix.de; linux-...@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> > Subject: Re: [RFC 2/2] PCI: imx6: Add support for i.MX8QM/QXP PCIe
> >
> > On Wed, Mar 13, 2019 at 2:15 AM Richard Zhu
> > wrote:
> > >
> > > Add codes needed to support i.MX8QM/QXP PCIe.
> > > - HSIO(High Speed IO) subsystem is new defined on i.MX8QM/QXP.
> > > The PCIe and SATA modules are contained in the HSIO subsystem. There
> > > are two PCIe, one SATA controllers and three mixed lane PHYs on
> > > i.MX8QM. There are three use cases of the HSIO subsystem on
> > i.MX8QM.
> > > 1. PCIea 2 lanes and one SATA AHCI port.
> > > 2. PCIea 1 lane, PCIeb 1 lane and one SATA AHCI port.
> > > 3. PCIea 2 lanes, PCIeb 1 lane.
> > > i.MX8QXP only has PCIeb controller and one lane PHY.
> > > - The HSIO address map as viewed from system level is as shown below.
> > > address [31:24]Local addressTargetAddress Size
> > > 5F 0HSIO 16MB
> > > 60-6F 40-4FHSIO 256MB
> > > 70-7F 80-8FHSIO 256MB
> > > So, the cpu_addr_fixup is required to enable i.MX8QM/QXP PCIe.
> > > - Both external OSC and internal PLL can be used as PCIe reference
> > > clock.
> > > - clock request GPIO for controlling the PCI reference clock request
> > > signal. And should be configure OD when L1SS maybe enabled later.
> > > - One more power domain HSIO_GPIO and clock PCIE_PER are required by
> > > i.MX8QM/QXP PCIe.
> > >
> > > Signed-off-by: Richard Zhu
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 392
> > > +-
> > > 1 file changed, 387 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index aaa9489..aacefb6 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -39,6 +39,7 @@
> > > #define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> > > #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPEGENMASK(11,
> > 8)
> > > #define IMX8MQ_PCIE2_BASE_ADDR 0x33c0
> > > +#define IMX8_HSIO_PCIEB_BASE_ADDR 0x5f01
> > >
> > > #define to_imx6_pcie(x)dev_get_drvdata((x)->dev)
> > >
> > > @@ -48,10 +49,13 @@ enum imx6_pcie_variants {
> > > IMX6QP,
> > > IMX7D,
> > > IMX8MQ,
> > > + IMX8QM,
> > > + IMX8QXP,
> > > };
> > >
> > > #define IMX6_PCIE_FLAG_IMX6_PHYBIT(0)
> > > #define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE BIT(1)
> > > +#define IMX6_PCIE_FLAG_IMX6_CPU_ADDR_FIXUP BIT(2)
> >
> > This is an IMX8Q* specific flag, so it probably should be called something
> > like
> > IMX6_PCIE_FLAG_IMX8Qx_CPU_ADD_FIXUP.
> [Richard Zhu] Okay, would change it later.
> >
> > >
> > > struct imx6_pcie_drvdata {
> > > enum imx6_pcie_variants variant; @@ -60,10 +64,12 @@ struct
> > > imx6_pcie_drvdata {
> > >
> > > struct imx6_pcie {
> > > struct dw_pcie *pci;
> > > + int clkreq_gpio;
> >
> > Is this really necessary? On i.MX8MQ vendor tree for some unknown reason
> > would reconfigure a dedicated CLKREQ_B signal as a GPIO and then use it as
> > CLKREQ signal that way instead of controlling it via dedicated bits in
> > register
> > file, so I am wondering if that is the case with QM and QXP.
> [Richard Zhu] There is a same mechanism of the CLKREQ on iMX8QM/QXP/MQ.
> Up to now, this pin is configured as GPIO, because that this pin would be
> pull up when OD is set
> and the EP device doesn't support the L1SS at all.
> Thus, the external CLK would be turned off in this scenario.
> This pin would be used in OD(Open Drain) mode when L1SS is enabled.
> The L1SS has been verified on iMX8MQ. But I don't have a dynamic method to
> turn the L1SS feature on at RC side yet when the L1SS is supported by EP.
> Configure CLK_REQ as GPIO here currently, and hope to figure out one solution
> in future.
>
Hmm, I am afraid I still don't understand why that pin has to be
controlled via GPIO subsystem. Here are my assumptions:
1. We can configure, say, PCIE0's CLKREQ as
SC_P_PCIE_CTRL0_CLKREQ_B_HSIO_PCIE0_CLKREQ_B on i.MX8QM, which should
be open drain just by CLKREQ's definition, and we can, if need be,
configure internal pull up in the same pinmux entry
2. It is possible to driver that pin open/closed via some bits in
register file. IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE in case of i.MX8MQ,
maybe
[PATCH] scripts/spelling.txt: add more typos to spelling.txt and sort
Here are some of the more common spelling mistakes and typos that I've found while fixing up spelling mistakes in the kernel. Signed-off-by: Like Xu --- scripts/spelling.txt | 579 +++ 1 file changed, 492 insertions(+), 87 deletions(-) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 86b8733..dcd25a3 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -21,11 +21,14 @@ absolut||absolute absoulte||absolute acccess||access acceess||access +accelaration||acceleration acceleratoin||acceleration +acceleratrion||acceleration accelleration||acceleration accesing||accessing accesnt||accent accessable||accessible +accessiable||accessible accesss||access accidentaly||accidentally accidentually||accidentally @@ -39,45 +42,58 @@ accout||account accquire||acquire accquired||acquired accross||across +accss||access acessable||accessible acess||access +acheived||achieved achitecture||architecture acient||ancient acitions||actions acitve||active acknowldegement||acknowledgment acknowledgement||acknowledgment +acknowleding||acknowledging ackowledge||acknowledge ackowledged||acknowledged +ackowledgement||acknowledgement +ackowledges||acknowledges acording||according -activete||activate actived||activated +activete||activate actualy||actually acumulating||accumulating acumulator||accumulator +acutally||actually adapater||adapter +adddress||address +adderss||address addional||additional additionaly||additionally +additionnally||additionally +additoinal||additional additonal||additional addres||address -adddress||address addreses||addresses addresss||address addrress||address aditional||additional aditionally||additionally aditionaly||additionally +adjusment||adjustment adminstrative||administrative adress||address adresses||addresses adrresses||addresses advertisment||advertisement adviced||advised +advnace||advance afecting||affecting +affvecs||affects againt||against agaist||against aggreataon||aggregation aggreation||aggregation +agruments||arguments albumns||albums alegorical||allegorical algined||aligned @@ -87,12 +103,15 @@ algoritm||algorithm algoritms||algorithms algorrithm||algorithm algorritm||algorithm +algrthm||algorithm aligment||alignment alignement||alignment allign||align alligned||aligned alllocate||allocate alloated||allocated +allocagtor||allocator +allocas||allices allocatote||allocate allocatrd||allocated allocte||allocate @@ -103,23 +122,29 @@ alogrithm||algorithm alot||a lot alow||allow alows||allows +alreaady||already altough||although alue||value +amacout||mahout ambigious||ambiguous +ammount||amount +ammounts||amounts amoung||among amout||amount amplifer||amplifier amplifyer||amplifier -an union||a union -an user||a user -an userspace||a userspace -an one||a one +analagous||analogous +analogous||analogous analysator||analyzer ang||and anniversery||anniversary annoucement||announcement anomolies||anomalies anomoly||anomaly +an one||a one +an union||a union +an user||a user +an userspace||a userspace anway||anyway aplication||application appearence||appearance @@ -134,48 +159,68 @@ approriate||appropriate approriately||appropriately apropriate||appropriate aquainted||acquainted +aquaris||Aquarius +aquire||acquire aquired||acquired aquisition||acquisition arbitary||arbitrary +arbitralrily||arbitrarily +arbitray||arbitrary architechture||architecture arguement||argument arguements||arguments +argumetns||arguments aritmetic||arithmetic arne't||aren't arraival||arrival artifical||artificial artillary||artillery asign||assign +assebmly||assembly asser||assert assertation||assertion assertting||asserting +assgined||assigned assiged||assigned assigment||assignment assigments||assignments assistent||assistant +assmebly||assembly +assocaition||association assocation||association +assocativity||associativity associcated||associated +assoicatied||associated assotiated||associated asssert||assert assum||assume +assumming||assuming assumtpion||assumption +asume||assume asuming||assuming asycronous||asynchronous -asynchnous||asynchronous -asynchromous||asynchronous asymetric||asymmetric asymmeric||asymmetric +asynchnous||asynchronous +asynchromous||asynchronous +asynchrounous||asynchronous +atempt||attempt atomatically||automatically atomicly||atomically -atempt||attempt +atribute||attribute attachement||attachment attched||attached -attemps||attempts attemping||attempting +attemppt||attempt +attemps||attempts attepmpt||attempt +attirbutes||attributes attnetion||attention +attribut||attribute attruibutes||attributes authentification||authentication +autherr||author +automagicaly||automatically automaticaly||automatically automaticly||automatically automatize||automate @@ -185,9 +230,11 @@ autonymous||autonomous auxillary||auxiliary auxilliary||auxiliary avaiable||available +avaialable||available
RE: [RFC 1/2] dt-bindings: imx6q-pcie: Add support for i.MX8QM/QXP PCIe
Hi Lucas:
Thanks for your reivew.
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: 2019年3月14日 17:31
> To: Richard Zhu ; bhelg...@google.com;
> lorenzo.pieral...@arm.com; andrew.smir...@gmail.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [RFC 1/2] dt-bindings: imx6q-pcie: Add support for i.MX8QM/QXP
> PCIe
>
> Hi Richard,
>
> Am Mittwoch, den 13.03.2019, 09:15 + schrieb Richard Zhu:
> > Add codes needed to support i.MX8QM/QXP PCIe.
> > - HSIO(High Speed IO) subsystem is new defined on i.MX8QM/QXP.
> > The PCIe and SATA modules are contained in the HSIO subsystem. There
> > are two PCIe, one SATA controllers and three mixed lane PHYs on
> > i.MX8QM. There are three use cases of the HSIO subsystem on
> i.MX8QM.
> > 1. PCIea 2 lanes and one SATA AHCI port.
> > 2. PCIea 1 lane, PCIeb 1 lane and one SATA AHCI port.
> > 3. PCIea 2 lanes, PCIeb 1 lane.
> > i.MX8QXP only has PCIeb controller and one lane PHY.
> > Use the hsio-cfg property to specify the different modes.
> > - The HSIO address map as viewed from system level is as shown below.
> > address [31:24]Local addressTargetAddress Size
> > 5F 0HSIO 16
> MB
> > 60-6F 40-4FHSIO 256MB
> > 70-7F 80-8FHSIO 256MB
> > The property local-addr is required to specify it.
> > - Both external OSC and internal PLL can be used as PCIe reference
> > clock, use the ext_osc property to distinguish them.
> > - clock request GPIO for controlling the PCI reference clock request
> > signal. And should be configure OD when L1SS maybe enabled later.
> > - One more power domain HSIO_GPIO and clock PCIE_PER are required by
> > i.MX8QM/QXP PCIe.
> > Add these specific properties to enable i.MX8QM/QXP PCIe.
>
> All this HSIO handling should move into a separate PHY driver. This has
> nothing to do with the PCIe controller itself. See for example the Tegra XUSB
> PHY driver (drivers/phy/tegra/xusb.c), which is a similar combined
> PCIE/USB3/SATA PHY driver.
>
[Richard Zhu] Very good suggestion, would make reference to it and re-orange
the codes.
Thanks.
> Regards,
> Lucas
>
> > Signed-off-by: Richard Zhu
> > ---
> > .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 21
> > +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > index a7f5f5a..f7586c9 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > @@ -10,6 +10,8 @@ Required properties:
> > > - "fsl,imx6qp-pcie"
> > > - "fsl,imx7d-pcie"
> > > - "fsl,imx8mq-pcie"
> > > + - "fsl,imx8qm-pcie"
> > > + - "fsl,imx8qxp-pcie"
> > - reg: base address and length of the PCIe controller
> > - interrupts: A list of interrupt outputs of the controller. Must
> > contain an
> > entry for each entry in the interrupt-names property.
> > @@ -38,6 +40,10 @@ Optional properties:
> > The regulator will be enabled when initializing the PCIe host and
> > disabled either as part of the init process or when shutting down
> > the
> > host.
> > +- clkreq-gpio: Should specify the GPIO for controlling the PCI
> > +reference clock
> > + request signal.
> > +- ext_osc: External OSC is used as PCIe reference clock or not. 0:
> > +Internal
> > + PLL. 1: External OSC.
> >
> > Additional required properties for imx6sx-pcie:
> > - clock names: Must include the following additional entries:
> > @@ -60,6 +66,21 @@ Additional required properties for imx8mq-pcie:
> > - clock-names: Must include the following additional entries:
> > > - "pcie_aux"
> >
> > +Additional required properties for imx8qm/qxp pcie:
> > +- power-domains: Must be set to a phandle pointing to PCIE, PCIE_PHY
> > +power and
> > + HSIO_GPIO domains
> > +- power-domain-names: Must be "pcie", "pcie_phy", "hsio_gpio"
> > +- clock-names: Must include the following additional entries:
> > > + - "pcie_per"
> > +- hsio-cfg: hsio configration mode when the pcie node is supported.
> > + 1: pciea 2 lanes and one sata ahci port.
> > + 2: pciea 1 lane, pcieb 1 lane and one sata ahci port.
> > + 3: pciea 2 lanes, pcieb 1 lane.
> > +- local-addr: the local address used in hsio module on i.MX8QM/QXP.
> > > + Example:
> > > + hsio-cfg = <2>;
> > > + local-addr = <0x8000>;
> > +
> > Example:
> >
> > > pcie@0100 {
[PATCH] checkpatch: fix camel case seeding when run with --root
checkpatch.pl avoids warning about camel case of some definitions by
seeding a file that tracks all of the currently committed camel case
definitions.
To build this seed file, checkpatch.pl decides between using git or the
--root parameter.
This works as long as you don't run checkpatch.pl from within
a different git tree that is not the Linux kernel.
In this case, the check for ".git" will return true, and checkpatch will
attempt to seed a camel case file using the current directory. This
works fine if --root is not provided, but can result in an incorrect
camel case seed file resulting in false positive warnings.
Fix this by checking for $root/.git instead, so that we use the --root
parameter properly when seeding the camel case list.
Additionally, when generating the list of files to be checked, prefix
the $root path so that the correct file will be found.
These changes allow checkpatch.pl to honor the --root parameter even if
being run from within another git repository.
Signed-off-by: Jacob Keller
---
I sent this a long time ago, https://patchwork.ozlabs.org/patch/663831/ but
it was never noticed or reviewed.
I thought I'd dredge it back up and write a better description of the
problem and the fix.
scripts/checkpatch.pl | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d0001fd1112d..358add495e18 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -903,8 +903,8 @@ sub seed_camelcase_includes {
$camelcase_seeded = 1;
- if (-e ".git") {
- my $git_last_include_commit = `git log --no-merges
--pretty=format:"%h%n" -1 -- include`;
+ if (-e "$root/.git") {
+ my $git_last_include_commit = `cd $root && git log --no-merges
--pretty=format:"%h%n" -1 -- include`;
chomp $git_last_include_commit;
$camelcase_cache =
".checkpatch-camelcase.git.$git_last_include_commit";
} else {
@@ -931,9 +931,10 @@ sub seed_camelcase_includes {
return;
}
- if (-e ".git") {
- $files = `git ls-files "include/*.h"`;
+ if (-e "$root/.git") {
+ $files = `cd $root && git ls-files "include/*.h"`;
@include_files = split('\n', $files);
+ @include_files = map("$root/$_", @include_files);
}
foreach my $file (@include_files) {
--
2.18.0.219.gaf81d287a9da
[PATCH v3 mailbox+firmware 6/6] dt-bindings: firmware: Document cznic,turris-mox-rwtm binding
This adds device tree binding documentation for the driver communicating
with the rWTM firmware on Turris Mox.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../firmware/cznic,turris-mox-rwtm.txt| 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
diff --git
a/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
b/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
new file mode 100644
index ..338169dea7bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
@@ -0,0 +1,19 @@
+Turris Mox rWTM firmware driver
+
+Required properties:
+ - compatible : Should be "cznic,turris-mox-rwtm"
+ - mboxes : Must contain a reference to associated mailbox
+
+This device tree node should be used on Turris Mox, or potentially another
A3700
+compatible device running the Mox's rWTM firmware in the secure processor (for
+example it is possible to flash this firmware into EspressoBin).
+
+Example:
+
+ firmware {
+ turris-mox-rwtm {
+ compatible = "cznic,turris-mox-rwtm";
+ mboxes = < 0>;
+ status = "okay";
+ };
+ };
--
2.19.2
[PATCH v3 mailbox+firmware 2/6] dt-bindings: mailbox: Document armada-3700-rwtm-mailbox binding
This adds device tree binding documentation for the rWTM BIU mailbox
driver on the Armada 37xx SOC (EspressoBin, Turris Mox).
Signed-off-by: Marek Behún
Reviewed-by: Rob Herring
---
.../mailbox/marvell,armada-3700-rwtm-mailbox.txt | 16
1 file changed, 16 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
diff --git
a/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
new file mode 100644
index ..282ab81a4ea6
--- /dev/null
+++
b/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
@@ -0,0 +1,16 @@
+* rWTM BIU Mailbox driver for Armada 37xx
+
+Required properties:
+- compatible: must be "marvell,armada-3700-rwtm-mailbox"
+- reg: physical base address of the mailbox and length of memory mapped
+ region
+- interrupts: the IRQ line for the mailbox
+- #mbox-cells: must be 1
+
+Example:
+ rwtm: mailbox@b {
+ compatible = "marvell,armada-3700-rwtm-mailbox";
+ reg = <0xb 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
--
2.19.2
[PATCH v3 mailbox+firmware 3/6] arm64: dts: marvell: armada-37xx: add mailbox node
This adds the rWTM BIU mailbox node for communication with the secure
processor.
Signed-off-by: Marek Behún
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 87cc84aae6ac..b2e55576b806 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -419,6 +419,13 @@
clocks = <_periph_clk 15>;
};
+ rwtm: mailbox@b {
+ compatible = "marvell,armada-3700-rwtm-mailbox";
+ reg = <0xb 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
sdhci1: sdhci@d {
compatible = "marvell,armada-3700-sdhci",
"marvell,sdhci-xenon";
--
2.19.2
[PATCH v3 mailbox+firmware 1/6] mailbox: Add support for Armada 37xx rWTM mailbox
This adds support for the mailbox via which the kernel can communicate
with the firmware running on the secure processor of the Armada 37xx
SOC.
The rWTM secure processor has access to internal eFuses and
cryptographic circuits, such as the Entropy Bit Generator to generate
true random numbers.
Signed-off-by: Marek Behún
---
drivers/mailbox/Kconfig| 10 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/armada-37xx-rwtm-mailbox.c | 225 +
include/linux/armada-37xx-rwtm-mailbox.h | 23 +++
4 files changed, 260 insertions(+)
create mode 100644 drivers/mailbox/armada-37xx-rwtm-mailbox.c
create mode 100644 include/linux/armada-37xx-rwtm-mailbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 3eeb12e93e98..939927290ac6 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -41,6 +41,16 @@ config PL320_MBOX
Management Engine, primarily for cpufreq. Say Y here if you want
to use the PL320 IPCM support.
+config ARMADA_37XX_RWTM_MBOX
+ tristate "Armada 37xx rWTM BIU Mailbox"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ help
+ Mailbox implementation for communication with the the firmware
+ running on the Cortex-M3 rWTM secure processor of the Armada 37xx
+ SOC. Say Y here if you are building for such a device (for example
+ the Turris Mox router).
+
config OMAP2PLUS_MBOX
tristate "OMAP2+ Mailbox framework support"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c818b5d011ae..792894db6b43 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_ARM_MHU) += arm_mhu.o
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
+obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
+
obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
diff --git a/drivers/mailbox/armada-37xx-rwtm-mailbox.c
b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
new file mode 100644
index ..97f90e97a83c
--- /dev/null
+++ b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rWTM BIU Mailbox driver for Armada 37xx
+ *
+ * Author: Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"armada-37xx-rwtm-mailbox"
+
+/* relative to rWTM BIU Mailbox Registers */
+#define RWTM_MBOX_PARAM(i) (0x0 + ((i) << 2))
+#define RWTM_MBOX_COMMAND 0x40
+#define RWTM_MBOX_RETURN_STATUS0x80
+#define RWTM_MBOX_STATUS(i)(0x84 + ((i) << 2))
+#define RWTM_MBOX_FIFO_STATUS 0xc4
+#define FIFO_STS_RDY 0x100
+#define FIFO_STS_CNTR_MASK 0x7
+#define FIFO_STS_CNTR_MAX 4
+
+#define RWTM_HOST_INT_RESET0xc8
+#define RWTM_HOST_INT_MASK 0xcc
+#define SP_CMD_COMPLETEBIT(0)
+#define SP_CMD_QUEUE_FULL_ACCESS BIT(17)
+#define SP_CMD_QUEUE_FULL BIT(18)
+
+struct a37xx_mbox {
+ struct device *dev;
+ struct mbox_controller controller;
+ void __iomem *base;
+ int irq;
+};
+
+static void a37xx_mbox_receive(struct mbox_chan *chan)
+{
+ struct a37xx_mbox *mbox = chan->con_priv;
+ struct armada_37xx_rwtm_rx_msg rx_msg;
+ int i;
+
+ rx_msg.retval = readl(mbox->base + RWTM_MBOX_RETURN_STATUS);
+ for (i = 0; i < 16; ++i)
+ rx_msg.status[i] = readl(mbox->base + RWTM_MBOX_STATUS(i));
+
+ mbox_chan_received_data(chan, _msg);
+}
+
+static irqreturn_t a37xx_mbox_irq_handler(int irq, void *data)
+{
+ struct mbox_chan *chan = data;
+ struct a37xx_mbox *mbox = chan->con_priv;
+ u32 reg;
+
+ reg = readl(mbox->base + RWTM_HOST_INT_RESET);
+
+ if (reg & SP_CMD_COMPLETE)
+ a37xx_mbox_receive(chan);
+
+ if (reg & (SP_CMD_QUEUE_FULL_ACCESS | SP_CMD_QUEUE_FULL))
+ dev_err(mbox->dev, "Secure processor command queue full\n");
+
+ writel(reg, mbox->base + RWTM_HOST_INT_RESET);
+ if (reg)
+ mbox_chan_txdone(chan, 0);
+
+ return reg ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static int a37xx_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct a37xx_mbox *mbox = chan->con_priv;
+ struct armada_37xx_rwtm_tx_msg *msg = data;
+ int i;
+ u32 reg;
+
+ if (!data)
+ return -EINVAL;
+
+ reg = readl(mbox->base + RWTM_MBOX_FIFO_STATUS);
+ if (!(reg & FIFO_STS_RDY))
+ dev_warn(mbox->dev, "Secure processor not ready\n");
+
+ if ((reg & FIFO_STS_CNTR_MASK) >= FIFO_STS_CNTR_MAX) {
+ dev_err(mbox->dev, "Secure processor command queue full\n");
+ return -EBUSY;
+ }
+
+ for (i = 0;
[PATCH v3 mailbox+firmware 0/6] Armada 37xx mailbox + Turris Mox secure firmware support
Hello, this is the third version of my patches to add support for rWTM mailbox of Marvell A3700 compatible devices, this time also with turris-mox-rwtm firmware driver. I would like to ask you guys for reviews, since I didn't get any review for the first patch (adding mailbox support) yet. What's new in v3: - Three more patches, to add support for communicating with the secure firmware on the Turris Mox board. The driver for this firmware needs the mailbox driver to be able to communicate with the secure processor. Changes since v2: - changed the mailbox driver not to fail when sending a message if the firmware reports that secure processor is not ready. The firmware on EspressoBin does not indicate that it is ready in the designated register, even if it answers to commands. Print only a warning if the ready flag is not set in the FIFO_STATUS register. - added Rob's Reviewed-by tag for the mailbox dt-binding patch Marek Marek Behún (6): mailbox: Add support for Armada 37xx rWTM mailbox dt-bindings: mailbox: Document armada-3700-rwtm-mailbox binding arm64: dts: marvell: armada-37xx: add mailbox node firmware: Add Turris Mox rWTM firmware driver firmware: turris-mox-rwtm: Add sysfs documentation dt-bindings: firmware: Document cznic,turris-mox-rwtm binding .../testing/sysfs-firmware-turris-mox-rwtm| 60 +++ .../firmware/cznic,turris-mox-rwtm.txt| 19 + .../marvell,armada-3700-rwtm-mailbox.txt | 16 + arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 + drivers/firmware/Kconfig | 14 + drivers/firmware/Makefile | 1 + drivers/firmware/turris-mox-rwtm.c| 508 ++ drivers/mailbox/Kconfig | 10 + drivers/mailbox/Makefile | 2 + drivers/mailbox/armada-37xx-rwtm-mailbox.c| 225 include/linux/armada-37xx-rwtm-mailbox.h | 23 + 11 files changed, 885 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm create mode 100644 Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt create mode 100644 Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt create mode 100644 drivers/firmware/turris-mox-rwtm.c create mode 100644 drivers/mailbox/armada-37xx-rwtm-mailbox.c create mode 100644 include/linux/armada-37xx-rwtm-mailbox.h -- 2.19.2
[PATCH v3 mailbox+firmware 4/6] firmware: Add Turris Mox rWTM firmware driver
This adds a driver to communicate with the firmware running on the
secure processor of the Turris Mox router, enabling the kernel to
retrieve true random numbers from the Entropy Bit Generator and to
sign messages with the ECDSA private key burned into each Turris Mox
device when manufacturing.
This also adds support to read other information burned into eFuses:
- serial number
- board version
- MAC addresses
- RAM size
- ECDSA public key (this is not read directly from eFuses, rather it
is computed by the firmware as pair to the burned private key)
The source code of the firmware is open source and can be found at
https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi
Signed-off-by: Marek Behún
---
drivers/firmware/Kconfig | 14 +
drivers/firmware/Makefile | 1 +
drivers/firmware/turris-mox-rwtm.c | 508 +
3 files changed, 523 insertions(+)
create mode 100644 drivers/firmware/turris-mox-rwtm.c
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index f754578414f0..7b665c52e6fd 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -267,6 +267,20 @@ config TI_SCI_PROTOCOL
This protocol library is used by client drivers to use the features
provided by the system controller.
+config TURRIS_MOX_RWTM
+ tristate "Turris Mox rWTM secure firmware driver"
+ depends on HAS_DMA && OF
+ depends on MAILBOX
+ select HW_RANDOM
+ select ARMADA_37XX_RWTM_MBOX
+ help
+ This driver communicates with the firmware on the Cortex-M3 secure
+ processor of the Turris Mox router. Enable if you are building for
+ Turris Mox, and you will be able to read the serial number and
+ other manufacturing data, sign messages with the internal ECDSA-521
+ private key and utilize the Entropy Bit Generator as hardware random
+ number generator.
+
config HAVE_ARM_SMCCC
bool
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 80feb635120f..7300787141f5 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_QCOM_SCM_64) += qcom_scm-64.o
obj-$(CONFIG_QCOM_SCM_32) += qcom_scm-32.o
CFLAGS_qcom_scm-32.o :=$(call as-instr,.arch armv7-a\n.arch_extension
sec,-DREQUIRES_SEC=1) -march=armv7-a
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
+obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o
obj-$(CONFIG_ARM_SCMI_PROTOCOL)+= arm_scmi/
obj-y += broadcom/
diff --git a/drivers/firmware/turris-mox-rwtm.c
b/drivers/firmware/turris-mox-rwtm.c
new file mode 100644
index ..e5d66460f85b
--- /dev/null
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -0,0 +1,508 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox rWTM firmware driver
+ *
+ * Copyright (C) 2019 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"turris-mox-rwtm"
+
+/*
+ * The macros and constants below come from Turris Mox's rWTM firmware code.
+ * This firmware is open source and it's sources can be found at
+ * https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi.
+ */
+
+#define MBOX_STS_SUCCESS (0 << 30)
+#define MBOX_STS_FAIL (1 << 30)
+#define MBOX_STS_BADCMD(2 << 30)
+#define MBOX_STS_ERROR(s) ((s) & (3 << 30))
+#define MBOX_STS_VALUE(s) (((s) >> 10) & 0xf)
+#define MBOX_STS_CMD(s)((s) & 0x3ff)
+
+enum mbox_cmd {
+ MBOX_CMD_GET_RANDOM = 1,
+ MBOX_CMD_BOARD_INFO = 2,
+ MBOX_CMD_ECDSA_PUB_KEY = 3,
+ MBOX_CMD_HASH = 4,
+ MBOX_CMD_SIGN = 5,
+ MBOX_CMD_VERIFY = 6,
+
+ MBOX_CMD_OTP_READ = 7,
+ MBOX_CMD_OTP_WRITE = 8,
+};
+
+struct mox_kobject;
+
+struct mox_rwtm {
+ struct device *dev;
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox;
+ struct mox_kobject *kobj;
+ struct hwrng hwrng;
+
+ struct armada_37xx_rwtm_rx_msg reply;
+
+ void *buf;
+ dma_addr_t buf_phys;
+
+ /*
+* If cmd_done_cb is not null, it is called on rWTM reply event.
+* Otherwise cmd_done completion is completed.
+*/
+ struct mutex busy;
+ struct completion cmd_done;
+ void (*cmd_done_cb)(struct mox_rwtm *rwtm);
+
+ /* board information */
+ int has_board_info;
+ u64 serial_number;
+ int board_version, ram_size;
+ u8 mac_address1[6], mac_address2[6];
+
+ /* public key burned in eFuse */
+ int has_pubkey;
+ u8 pubkey[135];
+
+ /* signature process */
+ struct kernfs_node *do_sign_kn;
+ u32 last_sig[34];
+ int last_sig_result;
+};
+
+struct mox_kobject {
+ struct kobject kobj;
+ struct mox_rwtm *rwtm;
+};
+
+static inline
[PATCH v3 mailbox+firmware 5/6] firmware: turris-mox-rwtm: Add sysfs documentation
Add sysfs ABI documentation for the sysfs files created by the turris-mox-rwtm driver. Signed-off-by: Marek Behún --- .../testing/sysfs-firmware-turris-mox-rwtm| 60 +++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm diff --git a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm new file mode 100644 index ..ff6cd30f0cf2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm @@ -0,0 +1,60 @@ +What: /sys/firmware/turris-mox-rwtm/board_version +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Board version burned into eFuses of this Turris Mox board. + Format: %i + +What: /sys/firmware/turris-mox-rwtm/do_sign +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (RW) Gate for writing requests for signature with the ECDSA + private key burned into eFuses during the manufacturing process, + and also for reading the resulting signature. + + When requesting for signature, a SHA-512 hash of the message to + be signed should be written in binary form to this file. This + means that a write() operation into this file shall write + exactly 64 bytes, buffers of other size are ignored. + + When the signature is done or the rWTM firmware responded with + an error, this file is notified via poll, and the result can + then be read. On error, the read() operation fails with errno + corresponding with the error. On success, 136 bytes are copied + to the buffer - 68 bytes for the R value and 68 for the S value + of the ECDSA signature, in binary form. These are 2 arrays of 17 + 32-bit words, in big-endian form, most significat word first. + + Format: binary + +What: /sys/firmware/turris-mox-rwtm/mac_address* +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) MAC addresses burned into eFuses of this Turris Mox board. + Format: %pM + +What: /sys/firmware/turris-mox-rwtm/pubkey +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) ECDSA public key (in pubkey hex compressed form) computed + as pair to the ECDSA private key burned into eFuses of this + Turris Mox Board. + Format: string + +What: /sys/firmware/turris-mox-rwtm/ram_size +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) RAM size in MiB of this Turris Mox board as was detected + during manufacturing and burned into eFuses. Can be 512 or 1024. + Format: %i + +What: /sys/firmware/turris-mox-rwtm/serial_number +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Serial number burned into eFuses of this Turris Mox device. + Format: %016X -- 2.19.2
[PATCH V4 4/5] ARM: dts: imx7ulp: Add pwm0 support
Add i.MX7ULP EVK board PWM0 support.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm/boot/dts/imx7ulp-evk.dts | 12
arch/arm/boot/dts/imx7ulp.dtsi| 10 ++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp-evk.dts
b/arch/arm/boot/dts/imx7ulp-evk.dts
index a09026a..3f5ea18 100644
--- a/arch/arm/boot/dts/imx7ulp-evk.dts
+++ b/arch/arm/boot/dts/imx7ulp-evk.dts
@@ -40,6 +40,12 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwm0>;
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_usdhc0>;
@@ -57,6 +63,12 @@
bias-pull-up;
};
+ pinctrl_pwm0: pwm0grp {
+ fsl,pins = <
+ IMX7ULP_PAD_PTF2__TPM4_CH1 0x2
+ >;
+ };
+
pinctrl_usdhc0: usdhc0grp {
fsl,pins = <
IMX7ULP_PAD_PTD1__SDHC0_CMD 0x43
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index fca6e50..6361c4e 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -124,6 +124,16 @@
status = "disabled";
};
+ pwm0: pwm@4025 {
+ compatible = "fsl,imx-tpm-pwm";
+ reg = <0x4025 0x1000>;
+ assigned-clocks = < IMX7ULP_CLK_LPTPM4>;
+ assigned-clock-parents = <
IMX7ULP_CLK_SOSC_BUS_CLK>;
+ clocks = < IMX7ULP_CLK_LPTPM4>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
tpm5: tpm@4026 {
compatible = "fsl,imx7ulp-tpm";
reg = <0x4026 0x1000>;
--
2.7.4
[PATCH V4 5/5] ARM: dts: imx7ulp-evk: Add backlight support
This patch adds i.MX7ULP EVK board MIPI-DSI backlight
support.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm/boot/dts/imx7ulp-evk.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp-evk.dts
b/arch/arm/boot/dts/imx7ulp-evk.dts
index 3f5ea18..f90f2f3 100644
--- a/arch/arm/boot/dts/imx7ulp-evk.dts
+++ b/arch/arm/boot/dts/imx7ulp-evk.dts
@@ -22,6 +22,14 @@
reg = <0x6000 0x4000>;
};
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = < 1 5>;
+ brightness-levels = <0 20 25 30 35 40 100>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
reg_vsd_3v3: regulator-vsd-3v3 {
compatible = "regulator-fixed";
regulator-name = "VSD_3V3";
--
2.7.4
[PATCH V4 2/5] pwm: Add i.MX TPM PWM driver support
i.MX7ULP has TPM(Low Power Timer/Pulse Width Modulation Module)
inside, add TPM PWM driver support.
Signed-off-by: Anson Huang
---
Changes since V3:
- use "PWM_IMX_" as macro definition prefix and "pwm_imx_" as function
prefix;
- improve the limitation txt;
- return error for configuring period/prescale fail;
- disable clock when driver probe failed and remove;
- improve module build dependency;
- introduce user_count to determine whether configuing period is
allowed;
- some logic improvement for setting duty/status etc.;
---
drivers/pwm/Kconfig | 12 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-imx-tpm.c | 396 ++
3 files changed, 409 insertions(+)
create mode 100644 drivers/pwm/pwm-imx-tpm.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index a8f47df..6117fe6 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -201,6 +201,18 @@ config PWM_IMX
To compile this driver as a module, choose M here: the module
will be called pwm-imx.
+config PWM_IMX_TPM
+ tristate "i.MX TPM PWM support"
+ depends on ARCH_MXC || COMPILE_TEST
+ depends on HAVE_CLK && HAS_IOMEM
+
+ help
+ Generic PWM framework driver for i.MX7ULP TPM module, TPM's full
+ name is Low Power Timer/Pulse Width Modulation Module.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-imx-tpm.
+
config PWM_JZ4740
tristate "Ingenic JZ47xx PWM support"
depends on MACH_INGENIC
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 9c676a0..64e036c 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_PWM_FSL_FTM) += pwm-fsl-ftm.o
obj-$(CONFIG_PWM_HIBVT)+= pwm-hibvt.o
obj-$(CONFIG_PWM_IMG) += pwm-img.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
+obj-$(CONFIG_PWM_IMX_TPM) += pwm-imx-tpm.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
obj-$(CONFIG_PWM_LPC18XX_SCT) += pwm-lpc18xx-sct.o
diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
new file mode 100644
index 000..f108f75
--- /dev/null
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018-2019 NXP.
+ *
+ * Limitations:
+ * - The TPM counter and period counter are shared between
+ * multiple channels, so all channels should use same period
+ * settings.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PWM_IMX_TPM_GLOBAL 0x8
+#define PWM_IMX_TPM_SC 0x10
+#define PWM_IMX_TPM_CNT0x14
+#define PWM_IMX_TPM_MOD0x18
+#define PWM_IMX_TPM_C0SC 0x20
+#define PWM_IMX_TPM_C0V0x24
+
+#define PWM_IMX_TPM_SC_CMODGENMASK(4, 3)
+#define PWM_IMX_TPM_SC_CMOD_INC_EVERY_CLK BIT(3)
+#define PWM_IMX_TPM_SC_CPWMS BIT(5)
+
+#define PWM_IMX_TPM_CnSC_CHF BIT(7)
+#define PWM_IMX_TPM_CnSC_MSnB BIT(5)
+#define PWM_IMX_TPM_CnSC_MSnA BIT(4)
+#define PWM_IMX_TPM_CnSC_ELSnB BIT(3)
+#define PWM_IMX_TPM_CnSC_ELSnA BIT(2)
+
+#define PWM_IMX_TPM_SC_PS_MASK 0x7
+#define PWM_IMX_TPM_MOD_MOD_MASK 0x
+
+#define PWM_IMX_TPM_MAX_COUNT 0x
+
+#define PWM_IMX_TPM_MAX_CHANNEL_NUM6
+
+#define PWM_IMX_TPM_CnSC(n)(PWM_IMX_TPM_C0SC + n * 0x8)
+#define PWM_IMX_TPM_CnV(n) (PWM_IMX_TPM_C0V + n * 0x8)
+
+struct imx_tpm_pwm_chip {
+ struct pwm_chip chip;
+ struct clk *clk;
+ void __iomem *base;
+ struct mutex lock;
+ u32 user_count;
+ u32 chn_config[PWM_IMX_TPM_MAX_CHANNEL_NUM];
+ bool chn_status[PWM_IMX_TPM_MAX_CHANNEL_NUM];
+};
+
+#define to_imx_tpm_pwm_chip(_chip) \
+ container_of(_chip, struct imx_tpm_pwm_chip, chip)
+
+static int pwm_imx_tpm_config_counter(struct pwm_chip *chip, u32 period)
+{
+ struct imx_tpm_pwm_chip *tpm = to_imx_tpm_pwm_chip(chip);
+ u32 period_cnt, val, div, saved_cmod;
+ u64 tmp;
+
+ tmp = clk_get_rate(tpm->clk);
+ tmp *= period;
+ val = DIV_ROUND_CLOSEST_ULL(tmp, NSEC_PER_SEC);
+ if (val < PWM_IMX_TPM_MAX_COUNT)
+ div = 0;
+ else
+ div = ilog2(roundup_pow_of_two(val /
+ (PWM_IMX_TPM_MAX_COUNT + 1)));
+ if (div > PWM_IMX_TPM_SC_PS_MASK) {
+ dev_err(chip->dev,
+ "failed to find valid prescale value!\n");
+ return -EINVAL;
+ }
+
+ /* make sure counter is disabled for programming prescale */
+ val = readl(tpm->base + PWM_IMX_TPM_SC);
+ saved_cmod = val & PWM_IMX_TPM_SC_CMOD;
+ val &= ~PWM_IMX_TPM_SC_CMOD;
+ writel(val, tpm->base + PWM_IMX_TPM_SC);
+
+ /* set TPM counter
[PATCH V4 1/5] dt-bindings: pwm: Add i.MX TPM PWM binding
Add i.MX TPM(Low Power Timer/Pulse Width Modulation Module) PWM binding.
Signed-off-by: Anson Huang
---
No changes.
---
Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
new file mode 100644
index 000..d47b8fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
@@ -0,0 +1,19 @@
+Freescale i.MX TPM PWM controller
+
+Required properties:
+- compatible : Should be "fsl,imx-tpm-pwm".
+- reg: Physical base address and length of the controller's registers.
+- #pwm-cells: Should be 2. See pwm.txt in this directory for a description of
the cells format.
+- clocks : The clock provided by the SoC to drive the PWM.
+- interrupts: The interrupt for the pwm controller.
+
+Example:
+
+pwm0: tpm@4025 {
+ compatible = "fsl,imx-tpm-pwm";
+ reg = <0x4025 0x1000>;
+ assigned-clocks = < IMX7ULP_CLK_LPTPM4>;
+ assigned-clock-parents = < IMX7ULP_CLK_SOSC_BUS_CLK>;
+ clocks = < IMX7ULP_CLK_LPTPM4>;
+ #pwm-cells = <2>;
+};
--
2.7.4
[PATCH V4 3/5] ARM: imx_v6_v7_defconfig: Add TPM PWM support by default
Select CONFIG_PWM_IMX_TPM by default to support i.MX7ULP TPM PWM. Signed-off-by: Anson Huang --- No changes. --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 5586a50..57862c6 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -399,6 +399,7 @@ CONFIG_MPL3115=y CONFIG_PWM=y CONFIG_PWM_FSL_FTM=y CONFIG_PWM_IMX=y +CONFIG_PWM_IMX_TPM=y CONFIG_NVMEM_IMX_OCOTP=y CONFIG_NVMEM_VF610_OCOTP=y CONFIG_TEE=y -- 2.7.4
[PATCH V4 0/5] Add i.MX7ULP EVK PWM backlight support
i.MX7ULP EVK board has MIPI-DSI display, its backlight is supplied by TPM PWM module, this patch set enables i.MX7ULP TPM PWM driver support and also add backlight support for MIPI-DSI display. Anson Huang (5): dt-bindings: pwm: Add i.MX TPM PWM binding pwm: Add i.MX TPM PWM driver support ARM: imx_v6_v7_defconfig: Add TPM PWM support by default ARM: dts: imx7ulp: Add pwm0 support ARM: dts: imx7ulp-evk: Add backlight support .../devicetree/bindings/pwm/imx-tpm-pwm.txt| 23 ++ arch/arm/boot/dts/imx7ulp-evk.dts | 20 ++ arch/arm/boot/dts/imx7ulp.dtsi | 11 + arch/arm/configs/imx_v6_v7_defconfig | 1 + drivers/pwm/Kconfig| 9 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-imx-tpm.c | 277 + 7 files changed, 342 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt create mode 100644 drivers/pwm/pwm-imx-tpm.c -- 2.7.4
Re: WARN ON at kernel/sched/deadline.c task_non_contending
On 2019/3/13 22:49, luca abeni wrote:
Hi,
After looking at the patch a little bit more and running some tests,
I suspect this solution might be racy:
when the timer is already active, (and hrtimer_start() fails), it
relies on its handler to decrease the running bw (by setting
dl_non_contending to 1)... But inactive_task_timer() might have
already checked dl_non_contending, finding it equal to 0 (so, it
ends up doing nothing and the running bw is not decreased).
So, I would prefer a different solution. I think this patch should work:
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 6a73e41a2016..43901fa3f269 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -252,7 +252,6 @@ static void task_non_contending(struct task_struct *p)
if (dl_entity_is_special(dl_se))
return;
- WARN_ON(hrtimer_active(_se->inactive_timer));
WARN_ON(dl_se->dl_non_contending);
zerolag_time = dl_se->deadline -
@@ -269,7 +268,7 @@ static void task_non_contending(struct task_struct *p)
* If the "0-lag time" already passed, decrease the active
* utilization now, instead of starting a timer
*/
- if (zerolag_time < 0) {
+ if ((zerolag_time < 0) || hrtimer_active(_se->inactive_timer)) {
if (dl_task(p))
sub_running_bw(dl_se, dl_rq);
if (!dl_task(p) || p->state == TASK_DEAD) {
The idea is that if the timer is active, we leave dl_non_contending set to
0 (so that the timer handler does nothing), and we immediately decrease the
running bw.
I think this is OK, because this situation can happen only if the task
blocks, wakes up while the timer handler is running, and then immediately
blocks again - while the timer handler is still running. So, the "zero lag
time" cannot be too much in the future.
Thanks,
Luca
.
Yeah, it looks good.
I can do some experiments with it ,
Do you have some testcases to help me with the test ?
Thanks,
Cheng Jian.
PCI: BUG in pci_epf_remove_cfs() from pci-epf-test
This is Linux v5.0-11053-gebc551f2b8f9 from March 12, on x86_64. Just load and unload the pci-epf-test module. [ 78.942581] calling pci_epf_test_init+0x0/0x1000 [pci_epf_test] @ 1650 [ 78.945926] initcall pci_epf_test_init+0x0/0x1000 [pci_epf_test] returned 0 after 3216 usecs [ 91.293344] == [ 91.293381] BUG: KASAN: use-after-free in pci_epf_remove_cfs+0x1b0/0x1f0 [ 91.293404] Write of size 8 at addr 888111843388 by task rmmod/1672 [ 91.293435] CPU: 3 PID: 1672 Comm: rmmod Not tainted 5.0.0mod #1 [ 91.293454] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version 4.10 01/08/2013 [ 91.293486] Call Trace: [ 91.293501] dump_stack+0x7b/0xb5 [ 91.293520] print_address_description+0x6e/0x360 [ 91.293544] kasan_report+0x11a/0x198 [ 91.293568] ? kasan_slab_free+0xe/0x10 [ 91.293583] ? pci_epf_remove_cfs+0x1b0/0x1f0 [ 91.293602] ? pci_epf_remove_cfs+0x1b0/0x1f0 [ 91.293620] __asan_report_store8_noabort+0x17/0x20 [ 91.293638] pci_epf_remove_cfs+0x1b0/0x1f0 [ 91.293658] pci_epf_unregister_driver+0xd/0x20 [ 91.293678] pci_epf_test_exit+0x10/0x18 [pci_epf_test] [ 91.293697] __x64_sys_delete_module+0x329/0x490 [ 91.293715] ? __ia32_sys_delete_module+0x490/0x490 [ 91.293736] ? blkcg_exit_queue+0x20/0x20 [ 91.293751] ? _raw_spin_unlock_irq+0x22/0x40 [ 91.293778] do_syscall_64+0xaa/0x310 [ 91.293793] ? prepare_exit_to_usermode+0x8b/0x150 [ 91.293812] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 91.293830] RIP: 0033:0x7f7494f5af77 [ 91.293845] Code: 73 01 c3 48 8b 0d 21 af 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f1 ae 2b 00 f7 d8 64 89 01 48 [ 91.293893] RSP: 002b:7fff91ebf118 EFLAGS: 0206 ORIG_RAX: 00b0 [ 91.293917] RAX: ffda RBX: 7fff91ebf178 RCX: 7f7494f5af77 [ 91.293938] RDX: 000a RSI: 0800 RDI: 55b8934a47d8 [ 91.293959] RBP: 55b8934a4770 R08: 7fff91ebe091 R09: [ 91.293980] R10: 7f7494fca1c0 R11: 0206 R12: 7fff91ebf340 [ 91.294001] R13: 7fff91ec173e R14: 55b8934a4260 R15: 55b8934a4770 [ 91.294042] Allocated by task 1650: [ 91.294057] save_stack+0x43/0xd0 [ 91.294071] __kasan_kmalloc.constprop.8+0xa7/0xd0 [ 91.294088] kasan_kmalloc+0x9/0x10 [ 91.294104] configfs_register_default_group+0x63/0xe0 [ 91.294121] pci_ep_cfs_add_epf_group+0x20/0x50 [ 91.294138] __pci_epf_register_driver+0x2b2/0x410 [ 91.294154] 0xc1d18032 [ 91.294168] do_one_initcall+0xab/0x2ad [ 91.294182] do_init_module+0x1c7/0x548 [ 91.294197] load_module+0x46bb/0x5da0 [ 91.294211] __do_sys_finit_module+0x193/0x1b0 [ 91.294227] __x64_sys_finit_module+0x6e/0xb0 [ 91.294243] do_syscall_64+0xaa/0x310 [ 91.294257] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 91.294282] Freed by task 1672: [ 91.294295] save_stack+0x43/0xd0 [ 91.294309] __kasan_slab_free+0x137/0x190 [ 91.294324] kasan_slab_free+0xe/0x10 [ 91.294339] kfree+0xb0/0x1b0 [ 91.294352] configfs_unregister_default_group+0x15/0x20 [ 91.294370] pci_ep_cfs_remove_epf_group+0x17/0x20 [ 91.294387] pci_epf_remove_cfs+0x8e/0x1f0 [ 91.294403] pci_epf_unregister_driver+0xd/0x20 [ 91.294419] pci_epf_test_exit+0x10/0x18 [pci_epf_test] [ 91.294437] __x64_sys_delete_module+0x329/0x490 [ 91.294454] do_syscall_64+0xaa/0x310 [ 91.294475] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 91.294503] The buggy address belongs to the object at 888111843308 which belongs to the cache kmalloc-192 of size 192 [ 91.294547] The buggy address is located 128 bytes inside of 192-byte region [888111843308, 8881118433c8) [ 91.294579] The buggy address belongs to the page: [ 91.294596] page:ea0004461000 count:1 mapcount:0 mapping:888107c10e40 index:0x888111841fe8 compound_mapcount: 0 [ 91.294628] flags: 0x17c0010200(slab|head) [ 91.294646] raw: 0017c0010200 ea0004696208 888107c03690 888107c10e40 [ 91.294670] raw: 888111841fe8 001e0014 0001 [ 91.294692] page dumped because: kasan: bad access detected [ 91.294717] Memory state around the buggy address: [ 91.294734] 888111843280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 91.294756] 888111843300: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 91.294777] >888111843380: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc [ 91.294798] ^ [ 91.294812] 888111843400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 91.294833] 888111843480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 91.294854] == -- ~Randy
Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
On Thu, 2019-03-14 at 19:42 -0400, Theodore Ts'o wrote: > On Thu, Mar 14, 2019 at 04:15:11PM -0700, James Bottomley wrote: > > On Thu, 2019-03-14 at 18:15 +0100, Richard Weinberger wrote: > > > Usually fscrypt allows limited access to encrypted files even > > > if no key is available. > > > Encrypted filenames are shown and based on this names users > > > can unlink and move files. > > > > Shouldn't they be able to read/write and create as well (all with > > the ciphertext name and contents, of course) ... otherwise how does > > backup of encrypted files by admin without the key ever work? > > That's not currently supported. Michael Halcrow and I worked out > some designs on how to do this, and I even had some prototype > patches, but it's really, really, messy, and requires a lot of > complex machinations in userspace on the save *and* restore, since > there's a lot of crypto metadata that has to be saved, and you have > to handle backing up the directory per-file keys, and restoring them > when you recreate the directory on a restore, etc. > > The simpler approach would have allowed backup of encrypted files > without the key, but would require the user's key to do the restore, > and if we ever actually tried to get this feature supported, that's > the approach I'd suggest. Well, as I said above encrypted file backup by an admin who doesn't have the key was what I was thinking of. > The fundamental reason why we never went did anything with this was > that the original use case of fscrypt was for Chrome OS, where the > original design premise was that you don't need to do backups, since > everything is in the cloud. A video from 2010: > > https://www.youtube.com/watch?v=lm-Vnx58UYo > > And with Android, backups happen automatically while you have the > encryption key. Heh, colour me paranoid, but if I backup my sensitive data to any medium (including the cloud) I *want* the backup to be encrypted so that if someone is careless with my backup data at least they don't get the contents. > There was talk about using fscrypt for Ubuntu desktops as an ecryptfs > replacement, and in that case, we would have use case that would have > required backups of a shared desktop where you don't have all of the > encryption keys for all of the users. Maybe someday as a Google > Summer of Code project or maybe if some potential corporate user of > fscrypt would be willing to fund the necessary engineering work? > > But again, I'll repeat this because it's so important: In the vast > majority of cases, including single-user laptops, desktops, etc., the > real right answer is dm-crypt and *not* fscrypt. Especially since > time-sharing systems are *so* 1980's. :-) > > So I don't use fscrypt on my upstream development laptop (except for > testing purposes) because it's simply not the right tool for the job. I was thinking of the container use case again. It's not really backup per se but it is serialization: if you can't do a backup ... i.e. save and restore an encrypted tar image, you can't use the filesystem for container image protection. But it also strikes me that inability to do backup and restore without the key really restricts the use cases for the entire filesystem. James
[PATCH] kbuild: Make NOSTDINC_FLAGS a simply expanded variable
During a simple no-op (nothing changed) build I saw 39 invocations of
the C compiler with the argument "-print-file-name=include". We don't
need to call the C compiler 39 times for this--one time will suffice.
Let's change NOSTDINC_FLAGS to a simply expanded variable to avoid
this since there doesn't appear to be any reason it should be
recursively expanded.
On my build this shaved ~400 ms off my "no-op" build.
Note that the recursive expansion seems to date back to the (really
old) commit e8f5bdb02ce0 ("[PATCH] Makefile include path ordering").
It's a little unclear to me if the point of that patch was to switch
the variable to be recursively expanded (which it did) or to avoid
directly assigning to NOSTDINC_FLAGS (AKA to switch to +=) because
someone else (out of tree?) was setting it. I presume later since if
the only goal was to switch to recursive expansion the patch would
have just removed the ":".
Signed-off-by: Douglas Anderson
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 9ef547fc7ffe..3034ba66ad51 100644
--- a/Makefile
+++ b/Makefile
@@ -402,7 +402,7 @@ CHECK = sparse
CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
-Wbitwise -Wno-return-void -Wno-unknown-attribute $(CF)
-NOSTDINC_FLAGS =
+NOSTDINC_FLAGS :=
CFLAGS_MODULE =
AFLAGS_MODULE =
LDFLAGS_MODULE =
--
2.21.0.360.g471c308f928-goog
Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
On Thu, Mar 14, 2019 at 04:15:11PM -0700, James Bottomley wrote: > On Thu, 2019-03-14 at 18:15 +0100, Richard Weinberger wrote: > > Usually fscrypt allows limited access to encrypted files even > > if no key is available. > > Encrypted filenames are shown and based on this names users > > can unlink and move files. > > Shouldn't they be able to read/write and create as well (all with the > ciphertext name and contents, of course) ... otherwise how does backup > of encrypted files by admin without the key ever work? That's not currently supported. Michael Halcrow and I worked out some designs on how to do this, and I even had some prototype patches, but it's really, really, messy, and requires a lot of complex machinations in userspace on the save *and* restore, since there's a lot of crypto metadata that has to be saved, and you have to handle backing up the directory per-file keys, and restoring them when you recreate the directory on a restore, etc. The simpler approach would have allowed backup of encrypted files without the key, but would require the user's key to do the restore, and if we ever actually tried to get this feature supported, that's the approach I'd suggest. The fundamental reason why we never went did anything with this was that the original use case of fscrypt was for Chrome OS, where the original design premise was that you don't need to do backups, since everything is in the cloud. A video from 2010: https://www.youtube.com/watch?v=lm-Vnx58UYo And with Android, backups happen automatically while you have the encryption key. There was talk about using fscrypt for Ubuntu desktops as an ecryptfs replacement, and in that case, we would have use case that would have required backups of a shared desktop where you don't have all of the encryption keys for all of the users. Maybe someday as a Google Summer of Code project or maybe if some potential corporate user of fscrypt would be willing to fund the necessary engineering work? But again, I'll repeat this because it's so important: In the vast majority of cases, including single-user laptops, desktops, etc., the real right answer is dm-crypt and *not* fscrypt. Especially since time-sharing systems are *so* 1980's. :-) So I don't use fscrypt on my upstream development laptop (except for testing purposes) because it's simply not the right tool for the job. - Ted
Re: [PATCH] tracing: initialize variable in create_dyn_event()
Hi Frank and Steve,
Thank you for pointing it out :)
On Thu, 14 Mar 2019 18:19:08 -0400
Steven Rostedt wrote:
> On Thu, 14 Mar 2019 14:05:02 -0700
> Frank Rowand wrote:
>
> > Hi Steve,
> >
> > Ping.
>
> Thanks, this got buried.
>
> > > static int create_dyn_event(int argc, char **argv)
> > > {
> > > struct dyn_event_operations *ops;
> > > - int ret;
> > > + int ret = 0;
>
> Probably should be ret = -ENODEV;
>
> As if ret doesn't get set, then no dynamic code has been registered,
> and something is truly wrong.
I Agreed to return -ENODEV instead of 0.
Thank you,
>
> -- Steve
>
>
> > >
> > > if (argv[0][0] == '-' || argv[0][0] == '!')
> > > return dyn_event_release(argc, argv, NULL);
> > >
>
--
Masami Hiramatsu
[PATCH] iio: adc: fix indentation issue, remove extra tab
From: Colin Ian King A return statement is indented one level too deeply; clean this up by removing a tab. Signed-off-by: Colin Ian King --- drivers/iio/adc/ad7124.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c index 7d5e5311d8de..659ef37d5fe8 100644 --- a/drivers/iio/adc/ad7124.c +++ b/drivers/iio/adc/ad7124.c @@ -411,7 +411,7 @@ static int ad7124_init_channel_vref(struct ad7124_state *st, dev_err(>sd.spi->dev, "Error, trying to use external voltage reference without a %s regulator.\n", ad7124_ref_names[refsel]); - return PTR_ERR(st->vref[refsel]); + return PTR_ERR(st->vref[refsel]); } st->channel_config[channel_number].vref_mv = regulator_get_voltage(st->vref[refsel]); -- 2.20.1
Re: [PATCH v2 2/9] mfd: mt6397: extract irq related code from core driver
On Mon, Mar 11, 2019 at 11:48 AM Hsin-Hsiung Wang
wrote:
>
> In order to support different types of irq design, we decide to add
> separate irq drivers for different design and keep mt6397 mfd core
> simple and reusable to all generations of PMICs so far.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/mfd/Makefile| 2 +-
> drivers/mfd/mt6397-core.c | 228
> ++--
> drivers/mfd/mt6397-irq.c| 214 +
> include/linux/mfd/mt6397/core.h | 12 +++
> 4 files changed, 259 insertions(+), 197 deletions(-)
> create mode 100644 drivers/mfd/mt6397-irq.c
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 12980a4..088e249 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -230,7 +230,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
> -obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o
Guenter reported the following issue with this
(https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1524423):
"""
Building the mt6397/mt6358 driver as module results in the following errors.
ERROR: "mt6397_irq_init" [drivers/mfd/mt6397-core.ko] undefined!
ERROR: "mt6358_irq_init" [drivers/mfd/mt6397-core.ko] undefined!
This is because the irq code for mt6358 and mt6397_irq is built as
separate modules, but the functions implemented by those modules are
not exported. We could export the functions, but that seems to be
quite pointless since the driver always requires both interrupt
handlers. Modify the Makefile to build a single module instead.
"""
His fix looks like this:
@@ -230,7 +230,9 @@
obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
-obj-$(CONFIG_MFD_MT6397) += mt6397-core.o mt6397-irq.o mt6358-irq.o
+
+mt6397-objs := mt6397-core.o mt6397-irq.o mt6358-irq.o
+obj-$(CONFIG_MFD_MT6397) += mt6397.o
obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index acb9812..53f1edc 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -12,7 +12,6 @@
> * GNU General Public License for more details.
> */
>
> -#include
> #include
> #include
> #include
> @@ -26,10 +25,6 @@
> #define MT6397_RTC_BASE0xe000
> #define MT6397_RTC_SIZE0x3e
>
> -#define MT6323_CHIP_ID 0x23
> -#define MT6391_CHIP_ID 0x91
> -#define MT6397_CHIP_ID 0x97
> -
> static const struct resource mt6397_rtc_resources[] = {
> {
> .start = MT6397_RTC_BASE,
> @@ -94,182 +89,24 @@
> }
> };
>
> -static void mt6397_irq_lock(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> -
> - mutex_lock(>irqlock);
> -}
> -
> -static void mt6397_irq_sync_unlock(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> -
> - regmap_write(mt6397->regmap, mt6397->int_con[0],
> -mt6397->irq_masks_cur[0]);
> - regmap_write(mt6397->regmap, mt6397->int_con[1],
> -mt6397->irq_masks_cur[1]);
> -
> - mutex_unlock(>irqlock);
> -}
> -
> -static void mt6397_irq_disable(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> - int shift = data->hwirq & 0xf;
> - int reg = data->hwirq >> 4;
> -
> - mt6397->irq_masks_cur[reg] &= ~BIT(shift);
> -}
> -
> -static void mt6397_irq_enable(struct irq_data *data)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
> - int shift = data->hwirq & 0xf;
> - int reg = data->hwirq >> 4;
> -
> - mt6397->irq_masks_cur[reg] |= BIT(shift);
> -}
> -
> -#ifdef CONFIG_PM_SLEEP
> -static int mt6397_irq_set_wake(struct irq_data *irq_data, unsigned int on)
> -{
> - struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(irq_data);
> - int shift = irq_data->hwirq & 0xf;
> - int reg = irq_data->hwirq >> 4;
> -
> - if (on)
> - mt6397->wake_mask[reg] |= BIT(shift);
> - else
> - mt6397->wake_mask[reg] &= ~BIT(shift);
> -
> - return 0;
> -}
> -#else
> -#define mt6397_irq_set_wake NULL
> -#endif
> -
> -static struct irq_chip mt6397_irq_chip = {
> - .name = "mt6397-irq",
> - .irq_bus_lock = mt6397_irq_lock,
> -
[PATCH] iio: adc: fix indentation issue, remove extra tab
From: Colin Ian King A return statement is indented one level too deeply; clean this up by removing a tab. Signed-off-by: Colin Ian King --- drivers/iio/adc/ad7124.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c index 7d5e5311d8de..659ef37d5fe8 100644 --- a/drivers/iio/adc/ad7124.c +++ b/drivers/iio/adc/ad7124.c @@ -411,7 +411,7 @@ static int ad7124_init_channel_vref(struct ad7124_state *st, dev_err(>sd.spi->dev, "Error, trying to use external voltage reference without a %s regulator.\n", ad7124_ref_names[refsel]); - return PTR_ERR(st->vref[refsel]); + return PTR_ERR(st->vref[refsel]); } st->channel_config[channel_number].vref_mv = regulator_get_voltage(st->vref[refsel]); -- 2.20.1
Re: [PATCH v5 2/9] clk: mediatek: Add new clkmux register API
On Tue, Mar 5, 2019 at 1:06 PM Weiyi Lu wrote:
>
> From: Owen Chen
>
> On both MT8183 & MT6765, there add "set/clr" register for
> each clkmux setting, and one update register to trigger value change.
> It is designed to prevent read-modify-write racing issue.
> The sw design need to add a new API to handle this hw change with
> a new mtk_clk_mux/mtk_mux struct in new file "clk-mux.c", "clk-mux.h".
>
> Signed-off-by: Owen Chen
> Signed-off-by: Weiyi Lu
> ---
> drivers/clk/mediatek/Makefile | 3 +-
> drivers/clk/mediatek/clk-mux.c | 223 +
> drivers/clk/mediatek/clk-mux.h | 89 +
> 3 files changed, 314 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/mediatek/clk-mux.c
> create mode 100644 drivers/clk/mediatek/clk-mux.h
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index ee4410ff43ab..20cf9eea4171 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o
> clk-apmixed.o clk-cpumux.o reset.o
> +obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o
> clk-apmixed.o clk-cpumux.o reset.o clk-mux.o
> +
> obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
> obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
> obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
> diff --git a/drivers/clk/mediatek/clk-mux.c b/drivers/clk/mediatek/clk-mux.c
> new file mode 100644
> index ..877a883fa616
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mux.c
> @@ -0,0 +1,223 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Owen Chen
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk-mtk.h"
> +#include "clk-mux.h"
> +
> +static inline struct mtk_clk_mux *to_mtk_clk_mux(struct clk_hw *hw)
> +{
> + return container_of(hw, struct mtk_clk_mux, hw);
> +}
> +
> +static int mtk_clk_mux_enable(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = BIT(mux->data->gate_shift);
> +
> + return regmap_update_bits(mux->regmap, mux->data->mux_ofs,
> + mask, ~mask);
> +}
> +
> +static void mtk_clk_mux_disable(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = BIT(mux->data->gate_shift);
> +
> + regmap_update_bits(mux->regmap, mux->data->mux_ofs, mask, mask);
> +}
> +
> +static int mtk_clk_mux_enable_setclr(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> +
> + return regmap_write(mux->regmap, mux->data->clr_ofs,
> + BIT(mux->data->gate_shift));
> +}
> +
> +static void mtk_clk_mux_disable_setclr(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> +
> + regmap_write(mux->regmap, mux->data->set_ofs,
> + BIT(mux->data->gate_shift));
> +}
> +
> +static int mtk_clk_mux_is_enabled(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 val;
> +
> + regmap_read(mux->regmap, mux->data->mux_ofs, );
> +
> + return (val & BIT(mux->data->gate_shift)) == 0;
> +}
> +
> +static u8 mtk_clk_mux_get_parent(struct clk_hw *hw)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = GENMASK(mux->data->mux_width - 1, 0);
> + u32 val;
> +
> + regmap_read(mux->regmap, mux->data->mux_ofs, );
> + val = (val >> mux->data->mux_shift) & mask;
> +
> + return val;
> +}
> +
> +static int mtk_clk_mux_set_parent_lock(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_mux *mux = to_mtk_clk_mux(hw);
> + u32 mask = GENMASK(mux->data->mux_width - 1, 0);
> + unsigned long flags;
Guenter reported the following issue
(https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1524422):
""
The construct conditionally acquiring a spinlock is too complex for
gcc to understand. This results in the following build warning.
drivers/clk/mediatek/clk-mux.c: In function
'mtk_clk_mux_set_parent_lock': ./include/linux/spinlock.h:279:3:
warning: 'flags' may be used uninitialized in this function
Other clock drivers avoid the problem by initializing flags with 0.
Lets do that here as well.
"""
> +
> + if (mux->lock)
> + spin_lock_irqsave(mux->lock, flags);
> + else
> + __acquire(mux->lock);
> +
> + regmap_update_bits(mux->regmap, mux->data->mux_ofs, mask,
> + index << mux->data->mux_shift);
> +
> + if (mux->lock)
> + spin_unlock_irqrestore(mux->lock, flags);
> + else
> + __release(mux->lock);
> +
> + return 0;
> +}
> +
> +static int mtk_clk_mux_set_parent_setclr_lock(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_mux *mux =
[PATCH] pata_serverworks: clean up misaligned indentation
From: Colin Ian King
There are several lines that are indented by one space too
many; clean these up. Also re-work comment block to clean
up cppcheck warnings
Signed-off-by: Colin Ian King
---
drivers/ata/pata_serverworks.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_serverworks.c b/drivers/ata/pata_serverworks.c
index 57de02123c4c..6083c7acfbca 100644
--- a/drivers/ata/pata_serverworks.c
+++ b/drivers/ata/pata_serverworks.c
@@ -432,10 +432,12 @@ static int serverworks_init_one(struct pci_dev *pdev,
const struct pci_device_id
(pdev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE) ||
(pdev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2)) {
-/* If the returned btr is the newer revision then
- select the right info block */
-if (rc == 3)
- ppi[0] = [3];
+ /*
+* If the returned btr is the newer revision then
+* select the right info block
+*/
+ if (rc == 3)
+ ppi[0] = [3];
/* Is this the 3rd channel CSB6 IDE ? */
if (pdev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2)
--
2.20.1
Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
On Thu, 2019-03-14 at 18:15 +0100, Richard Weinberger wrote: > Usually fscrypt allows limited access to encrypted files even > if no key is available. > Encrypted filenames are shown and based on this names users > can unlink and move files. Shouldn't they be able to read/write and create as well (all with the ciphertext name and contents, of course) ... otherwise how does backup of encrypted files by admin without the key ever work? James
[PATCH] x86/lib: fix indentation issue, remove extra tab
From: Colin Ian King The increment of buff is indented one level too deeply, clean this up by removing a tab. Signed-off-by: Colin Ian King --- arch/x86/lib/csum-partial_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/lib/csum-partial_64.c b/arch/x86/lib/csum-partial_64.c index 9baca3e054be..e7925d668b68 100644 --- a/arch/x86/lib/csum-partial_64.c +++ b/arch/x86/lib/csum-partial_64.c @@ -94,7 +94,7 @@ static unsigned do_csum(const unsigned char *buff, unsigned len) : "m" (*(unsigned long *)buff), "r" (zero), "0" (result)); --count; - buff += 8; + buff += 8; } result = add32_with_carry(result>>32, result&0x); -- 2.20.1
Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
Richard --- stepping back for a moment, in your use case, are you assuming that the encryption key is always going to be present while the system is running? Ubifs can't use dm-crypt, since it doesn't have a block device, but if you could, is much more like dm-crypt, in that you have the key *before* the file system is mounted, and you don't really expect the key to ever be expunged from the system while it is mounted? If that's true, maybe the real mismatch is in using fscrypt in the first place --- and in fact, something where you encrypt everything, including the file system metadata (ala dm-crypt), would actually give you much better security properties. - Ted
Re: [PATCH v3 3/3] Drivers: hv: vmbus: Fix race condition with new ring_buffer_info mutex
On Thu, 14 Mar 2019 13:05:15 -0700
"Kimberly Brown" wrote:
> Fix a race condition that can result in a ring buffer pointer being set
> to null while a "_show" function is reading the ring buffer's data. This
> problem was discussed here:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org
> %2Flkml%2F2018%2F10%2F18%2F779data=02%7C01%7Csthemmin%40microsoft.com
> %7C1d7557d667b741bdbb6008d6a8b8620f%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C636881907217609564sdata=1bUbLaxsODANM7lCBR8lxyYajNpufuwUW%2FOl
> vtGu2hU%3Dreserved=0
>
> To fix the race condition, add a new mutex lock to the
> "hv_ring_buffer_info" struct. Add a new function,
> "hv_ringbuffer_pre_init()", where a channel's inbound and outbound
> ring_buffer_info mutex locks are initialized.
>
> Acquire/release the locks in the "hv_ringbuffer_cleanup()" function,
> which is where the ring buffer pointers are set to null.
>
> Acquire/release the locks in the four channel-level "_show" functions
> that access ring buffer data. Remove the "const" qualifier from the
> "vmbus_channel" parameter and the "rbi" variable of the channel-level
> "_show" functions so that the locks can be acquired/released in these
> functions.
>
> Acquire/release the locks in hv_ringbuffer_get_debuginfo(). Remove the
> "const" qualifier from the "hv_ring_buffer_info" parameter so that the
> locks can be acquired/released in this function.
>
> Signed-off-by: Kimberly Brown
> ---
> drivers/hv/channel_mgmt.c | 2 +
> drivers/hv/hyperv_vmbus.h | 1 +
> drivers/hv/ring_buffer.c | 19 -
> drivers/hv/vmbus_drv.c| 82 +--
> include/linux/hyperv.h| 7 +++-
> 5 files changed, 79 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index 9d7f9c1c60c7..14543059cc3e 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -336,6 +336,8 @@ static struct vmbus_channel *alloc_channel(void)
> tasklet_init(>callback_event,
>vmbus_on_event, (unsigned long)channel);
>
> + hv_ringbuffer_pre_init(channel);
> +
> return channel;
> }
>
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index a94aab94e0b5..e5467b821f41 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -193,6 +193,7 @@ extern void hv_synic_clockevents_cleanup(void);
>
> /* Interface */
>
> +void hv_ringbuffer_pre_init(struct vmbus_channel *channel);
>
> int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info,
> struct page *pages, u32 pagecnt);
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index 0386ff48c5ea..121a01c43298 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -166,14 +166,18 @@ hv_get_ringbuffer_availbytes(const struct
> hv_ring_buffer_info *rbi,
> }
>
> /* Get various debug metrics for the specified ring buffer. */
> -int hv_ringbuffer_get_debuginfo(const struct hv_ring_buffer_info
> *ring_info,
> +int hv_ringbuffer_get_debuginfo(struct hv_ring_buffer_info *ring_info,
> struct hv_ring_buffer_debug_info
> *debug_info)
> {
> u32 bytes_avail_towrite;
> u32 bytes_avail_toread;
>
> - if (!ring_info->ring_buffer)
> + mutex_lock(_info->ring_buffer_mutex);
> +
> + if (!ring_info->ring_buffer) {
> + mutex_unlock(_info->ring_buffer_mutex);
> return -EINVAL;
> + }
>
> hv_get_ringbuffer_availbytes(ring_info,
>_avail_toread,
> @@ -184,10 +188,19 @@ int hv_ringbuffer_get_debuginfo(const struct
> hv_ring_buffer_info *ring_info,
> debug_info->current_write_index =
> ring_info->ring_buffer->write_index;
> debug_info->current_interrupt_mask
> = ring_info->ring_buffer->interrupt_mask;
> + mutex_unlock(_info->ring_buffer_mutex);
> +
> return 0;
> }
> EXPORT_SYMBOL_GPL(hv_ringbuffer_get_debuginfo);
>
> +/* Initialize a channel's ring buffer info mutex locks */
> +void hv_ringbuffer_pre_init(struct vmbus_channel *channel)
> +{
> + mutex_init(>inbound.ring_buffer_mutex);
> + mutex_init(>outbound.ring_buffer_mutex);
> +}
> +
> /* Initialize the ring buffer. */
> int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info,
> struct page *pages, u32 page_cnt)
> @@ -240,8 +253,10 @@ int hv_ringbuffer_init(struct hv_ring_buffer_info
> *ring_info,
> /* Cleanup the ring buffer. */
> void hv_ringbuffer_cleanup(struct hv_ring_buffer_info *ring_info)
> {
> + mutex_lock(_info->ring_buffer_mutex);
> vunmap(ring_info->ring_buffer);
> ring_info->ring_buffer = NULL;
> + mutex_unlock(_info->ring_buffer_mutex);
> }
>
> /* Write to the ring buffer. */
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 7f15c41d952e..84f3a510b4c9 100644
> --- a/drivers/hv/vmbus_drv.c
> +++
Re: [PATCH] tracing: initialize variable in create_dyn_event()
On Thu, 14 Mar 2019 14:05:02 -0700
Frank Rowand wrote:
> Hi Steve,
>
> Ping.
Thanks, this got buried.
> > static int create_dyn_event(int argc, char **argv)
> > {
> > struct dyn_event_operations *ops;
> > - int ret;
> > + int ret = 0;
Probably should be ret = -ENODEV;
As if ret doesn't get set, then no dynamic code has been registered,
and something is truly wrong.
-- Steve
> >
> > if (argv[0][0] == '-' || argv[0][0] == '!')
> > return dyn_event_release(argc, argv, NULL);
> >
Re: [PATCH] percpu/module resevation: change resevation size iff X86_VSMP is set
On Thu, Mar 14, 2019 at 10:36:19AM -0700, Tejun Heo wrote:
> On Wed, Mar 13, 2019 at 04:11:55PM -0700, Paul E. McKenney wrote:
> > commit 34f67df09cc0c6bf082a7cfca435373caeeb8d82
> > Author: Paul E. McKenney
> > Date: Wed Mar 13 16:06:22 2019 -0700
> >
> > srcu: Forbid DEFINE{,_STATIC}_SRCU() from modules
> >
> > Adding DEFINE_SRCU() or DEFINE_STATIC_SRCU() to a loadable module
> > requires that the size of the reserved region be increased, which is
> > not something we want to be doing all that often. Instead, loadable
> > modules should define an srcu_struct and invoke init_srcu_struct()
> > from their module_init function and cleanup_srcu_struct() from their
> > module_exit function. Note that modules using call_srcu() will also
> > need to invoke srcu_barrier() from their module_exit function.
> >
> > This commit enforces this advice by refusing to define DEFINE_SRCU()
> > and DEFINE_STATIC_SRCU() within loadable modules.
> >
> > Suggested-by: Barret Rhoden
> > Signed-off-by: Paul E. McKenney
>
> Looks-great-to-me-by: Tejun Heo
Applied. ;-)
Thanx, Paul
> Thanks. :)
>
> --
> tejun
>
Re: [Regression] Re: Linux 5.0.2
Greg KH writes: > On Thu, Mar 14, 2019 at 02:52:50PM -0700, Greg KH wrote: >> On Thu, Mar 14, 2019 at 08:43:14PM +, Alan J. Wylie wrote: >> > >> > (Adding Linus, since his tree is also broken) >> >> Again, can you try running 'git bisect' to find the offending commit? > > Ah, looks like Guenter found it, nevermind... I'd just finished bisecting: $ git bisect good 3ad8e57560d7652a66da12b41c668a593509f3ad is the first bad commit commit 3ad8e57560d7652a66da12b41c668a593509f3ad Author: Peter Zijlstra (Intel) Date: Tue Mar 5 22:23:15 2019 +0100 perf/x86/intel: Make cpuc allocations consistent The cpuc data structure allocation is different between fake and real cpuc's; use the same code to init/free both. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman :04 04 9066c98aa5c85a5783907a8431fe3ab7004c 139f04cab3ddd303ffc595e848d01fac3989ac75 M arch $ git bisect log git bisect start # good: [283506fcd65de1bc10fcc6e2ca633a7b63171ffa] Linux 5.0.1 git bisect good 283506fcd65de1bc10fcc6e2ca633a7b63171ffa # bad: [9e6fdea016e45c5feab60589241e0d3607d39945] Linux 5.0.2 git bisect bad 9e6fdea016e45c5feab60589241e0d3607d39945 # good: [e3f5c3cbe16356cd98518765d891aec90dc34e3d] drm: disable uncached DMA optimization for ARM and arm64 git bisect good e3f5c3cbe16356cd98518765d891aec90dc34e3d # good: [e7b0b71c22e7f9529ae677ba7299efbe6bfbb232] staging: erofs: compressed_pages should not be accessed again after freed git bisect good e7b0b71c22e7f9529ae677ba7299efbe6bfbb232 # bad: [3ad8e57560d7652a66da12b41c668a593509f3ad] perf/x86/intel: Make cpuc allocations consistent git bisect bad 3ad8e57560d7652a66da12b41c668a593509f3ad # good: [3dfe7538f80acf0edf33ae4ae4f639c86e3a3be5] ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom git bisect good 3dfe7538f80acf0edf33ae4ae4f639c86e3a3be5 # first bad commit: [3ad8e57560d7652a66da12b41c668a593509f3ad] perf/x86/intel: Make cpuc allocations consistent $ Regards Alan -- Alan J. Wylie https://www.wylie.me.uk/ Dance like no-one's watching. / Encrypt like everyone is. Security is inversely proportional to convenience
[PATCH v4] x86/boot: clean up headers
The inclusion of was causing issue as the definition of __arch_hweight64 from arch/x86/include/asm/arch_hweight.h eventually gets included. The definition is problematic when compiled with -m16 (all code in arch/x86/boot/ is) as the "D" inline assembly constraint is rejected by both compilers when passed an argument of type long long (regardless of signedness, anything smaller is fine). Because GCC performs inlining before semantic analysis, and __arch_hweight64 is dead in this translation unit, GCC does not report any issues at compile time. Clang does the semantic analysis in the front end, before inlining (run in the middle) can determine the code is dead. I consider this another case of PR33587, which I think we can do more work to solve. It turns out that arch/x86/boot/string.c doesn't actually need linux/kernel.h, simply linux/limits.h and linux/compiler.h. Link: https://bugs.llvm.org/show_bug.cgi?id=33587 Link: https://github.com/ClangBuiltLinux/linux/issues/347 Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Suggested-by: Stephen Rothwell Signed-off-by: Nick Desaulniers --- Changes V3 -> V4: * Drop sentence from commit message about sorting headers. Changes V2 -> V3: * keep linux/types.h Changes V1 -> V2: * Add Reviewed, Tested, Suggested tags. * Drop linux/types.h; it's included in linux/limits.h. arch/x86/boot/string.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c index 315a67b8896b..90154df8f125 100644 --- a/arch/x86/boot/string.c +++ b/arch/x86/boot/string.c @@ -13,8 +13,9 @@ */ #include -#include +#include #include +#include #include #include "ctype.h" #include "string.h" -- 2.21.0.360.g471c308f928-goog
Re: [PATCH] [RESEND] Do not modify perf bias performance setting by default at boot
On Thu, Mar 14, 2019 at 3:42 PM Thomas Renninger wrote: > > This is a revert of mainline git commits: > commit b51ef52df71cb28e9d90cd1d48b79bf19f0bab06 > commit 17edf2d79f1ea6dfdb4c444801d928953b9f98d6 > commit abe48b108247e9b90b4c6739662a2e5c765ed114 I'm not quite convinced that reverting these is the right thing to do here. > It is about this kernel message showing up on quite a lot servers: > [0.072652] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' > [0.076003] ENERGY_PERF_BIAS: View and update with > x86_energy_perf_policy(8) What happens on boot is a matter of convention and the convention by which the EPB is set to "neutral" at that point has been used for quite a while. Changing it now may confuse some users or even worse. It would be fine to change the log level of these messages in my view, though. > The background afaik were some BIOS which "forgot to set a default value". > Certainly some (one?) broken laptop BIOS was meant, because > the value zero (performance) is quite a reasonable default value on server > systems > and this is how a lot CPUs typically come up there. That depends on the expected power/perf profile of the system and the kernel has no information regarding that. Arguably, user space can set the EPB to whatever it wants at the init time according to the information it has. It is not quite realistic to expect that either the BIOS or the kernel will do the right thing on all systems in that respect anyway. > Another sever bug with above patches: > If you really set performance BIAS MSR value to 'performance' > as mentioned in kernel boot log, it is reset on next CPU offline/online cycle > (see below). That is a bug. There is no reason to change the EPB on CPU offline/online and I agree that this needs to be fixed. The reverts would make this problem go away, but that's not the only possible way to fix it. Moreover, what is done during system-wide resume appears to be a bug too. Whatever EPB value is there during suspend should be saved and it should be restored during resume. Reverting the commits above will not fix that particular issue. Thanks, Rafael
Re: [PATCH 1/2] elf: simpler check for -EEXIST
On 2019/03/15 5:42, Alexey Dobriyan wrote:
> PTR_ERR((void *)map_addr) == -EEXIST
>
> is a very complicated way of doing the obvious.
Michal suggested me to explicitly use PTR_ERR() for documentation purpose in
a reply mail to https://lkml.kernel.org/r/20180418115546.gz17...@dhcp22.suse.cz
.
>
> Signed-off-by: Alexey Dobriyan
> ---
>
> fs/binfmt_elf.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -375,8 +375,7 @@ static unsigned long elf_map(struct file *filep, unsigned
> long addr,
> } else
> map_addr = vm_mmap(filep, addr, size, prot, type, off);
>
> - if ((type & MAP_FIXED_NOREPLACE) &&
> - PTR_ERR((void *)map_addr) == -EEXIST)
> + if ((type & MAP_FIXED_NOREPLACE) && map_addr == -EEXIST)
> pr_info("%d (%s): Uhuuh, elf segment at %px requested but the
> memory is mapped already\n",
> task_pid_nr(current), current->comm, (void *)addr);
>
>
Re: [PATCH] EDAC, {skx|i10nm}_edac: Fix randconfig build error
On Thu, Mar 14, 2019 at 12:04:13PM +0100, Borislav Petkov wrote:
> On Thu, Mar 14, 2019 at 08:09:06AM +0100, Arnd Bergmann wrote:
> > > So where should we go. Proposed solutions are piling up:
> > >
> > > 1) Make skx_common a module
> > > [downside: have to EXPORT everything in it]
> > > 2) Move module-ish bits out of skx_common
> > > [downside: perhaps fragile]
> > > 3) #include skx_common.c into {skx,i10nm}_edac.c
> > > [downside: no patch yet, bigger code size]
> >
> > Sorry to add on to the already long list, but one more idea after
> > looking at the two files:
> >
> > 4) Have a single driver module, with the skx_common.c containing
> > the top-level module_init/module_exit functions that call into the
> > hardware specific versions.
> >
> > This is the opposite of the usual recommendation (the driver
> > is already structured nicely otherwise), but it would be cheap
> > way out here.
>
> This is what I think right now: if this is going to become such a pain,
> then we better keep those two drivers completely separate. Who cares if
> there's some code duplication?! Better that than some obscure randconfig
> build breakages and fixes introducing more ugliness. IOW, we should keep
> it simple.
>
> Unless, Tony, you want to be able to make changes to the common code in
> one place and don't want to patch both. Then I'd librarize the common
> functionality, i.e., do something along the lines of 2).
There's a lot of common code. Patching the same thing in two
different files seems like make-work (and a recipe for things
to be forgotten/missed).
I made a patch based on option #3. Rough steps were:
$ cat skx_common.c >> skx_common.h
$ git rm skx_common.c
$ git mv skx_base.c skx_edac.c
$ git mv i10nm_base.c i10nm_edac.c
$ edit Makefile for changes of names
$ edit skx_common.h to add "static" everywhere
$ edit to fix the build issues
Not entirely happy with some of the bits in that last step.
Patch looks like this:
>From b9e9723c95b667d28d81ea53b35447e1ce8f3244 Mon Sep 17 00:00:00 2001
From: Tony Luck
Date: Thu, 14 Mar 2019 10:45:34 -0700
Subject: [PATCH] fix corner cases for randconfig
---
drivers/edac/Makefile | 2 -
drivers/edac/{i10nm_base.c => i10nm_edac.c} | 5 +
drivers/edac/skx_common.c | 691
drivers/edac/skx_common.h | 685 ++-
drivers/edac/{skx_base.c => skx_edac.c} | 9 +-
5 files changed, 676 insertions(+), 716 deletions(-)
rename drivers/edac/{i10nm_base.c => i10nm_edac.c} (98%)
delete mode 100644 drivers/edac/skx_common.c
rename drivers/edac/{skx_base.c => skx_edac.c} (98%)
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 89ad4a84a0f6..5d8d88574d3c 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -57,10 +57,8 @@ obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac_mod.o
layerscape_edac_mod-y := fsl_ddr_edac.o layerscape_edac.o
obj-$(CONFIG_EDAC_LAYERSCAPE) += layerscape_edac_mod.o
-skx_edac-y := skx_common.o skx_base.o
obj-$(CONFIG_EDAC_SKX) += skx_edac.o
-i10nm_edac-y := skx_common.o i10nm_base.o
obj-$(CONFIG_EDAC_I10NM) += i10nm_edac.o
obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o
diff --git a/drivers/edac/i10nm_base.c b/drivers/edac/i10nm_edac.c
similarity index 98%
rename from drivers/edac/i10nm_base.c
rename to drivers/edac/i10nm_edac.c
index c334fb7c63df..45c6497f35c5 100644
--- a/drivers/edac/i10nm_base.c
+++ b/drivers/edac/i10nm_edac.c
@@ -10,6 +10,11 @@
#include
#include
#include "edac_module.h"
+
+struct decoded_addr;
+typedef bool (*skx_decode_f)(struct decoded_addr *res);
+static skx_decode_f skx_decode;
+
#include "skx_common.h"
#define I10NM_REVISION "v0.0.3"
diff --git a/drivers/edac/skx_common.c b/drivers/edac/skx_common.c
deleted file mode 100644
index 0e96e7b5b0a7..
--- a/drivers/edac/skx_common.c
+++ /dev/null
@@ -1,691 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Common codes for both the skx_edac driver and Intel 10nm server EDAC driver.
- * Originally split out from the skx_edac driver.
- *
- * Copyright (c) 2018, Intel Corporation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include "edac_module.h"
-#include "skx_common.h"
-
-static const char * const component_names[] = {
- [INDEX_SOCKET] = "ProcessorSocketId",
- [INDEX_MEMCTRL] = "MemoryControllerId",
- [INDEX_CHANNEL] = "ChannelId",
- [INDEX_DIMM]= "DimmSlotId",
-};
-
-static int component_indices[ARRAY_SIZE(component_names)];
-static int adxl_component_count;
-static const char * const *adxl_component_names;
-static u64 *adxl_values;
-static char *adxl_msg;
-
-static char skx_msg[MSG_SIZE];
-static skx_decode_f skx_decode;
-static u64 skx_tolm, skx_tohm;
-static LIST_HEAD(dev_edac_list);
-
-int __init skx_adxl_get(void)
-{
-
Re: [Regression] Re: Linux 5.0.2
On Thu, Mar 14, 2019 at 02:52:50PM -0700, Greg KH wrote: > On Thu, Mar 14, 2019 at 08:43:14PM +, Alan J. Wylie wrote: > > > > (Adding Linus, since his tree is also broken) > > Again, can you try running 'git bisect' to find the offending commit? Ah, looks like Guenter found it, nevermind...
Re: [Regression] Re: Linux 5.0.2
On Thu, Mar 14, 2019 at 08:43:14PM +, Alan J. Wylie wrote: > > (Adding Linus, since his tree is also broken) Again, can you try running 'git bisect' to find the offending commit? thanks, greg k-h
[PATCH -manpage 2/2] memfd_create.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal
More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t
Signed-off-by: Joel Fernandes (Google)
---
man2/memfd_create.2 | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/man2/memfd_create.2 b/man2/memfd_create.2
index 15b1362f5525..3b7f032407ed 100644
--- a/man2/memfd_create.2
+++ b/man2/memfd_create.2
@@ -280,7 +280,15 @@ in order to restrict further modifications on the file.
(If placing the seal
.BR F_SEAL_WRITE ,
then it will be necessary to first unmap the shared writable mapping
-created in the previous step.)
+created in the previous step. Otherwise, behavior similar to
+.BR F_SEAL_WRITE
+can be achieved, by using
+.BR F_SEAL_FUTURE_WRITE
+which will prevent future writes via
+.BR mmap (2)
+and
+.BR write (2)
+from succeeding, while keeping existing shared writable mappings).
.IP 4.
A second process obtains a file descriptor for the
.BR tmpfs (5)
@@ -425,6 +433,7 @@ main(int argc, char *argv[])
fprintf(stderr, "\et\etg \- F_SEAL_GROW\en");
fprintf(stderr, "\et\ets \- F_SEAL_SHRINK\en");
fprintf(stderr, "\et\etw \- F_SEAL_WRITE\en");
+fprintf(stderr, "\et\etW \- F_SEAL_FUTURE_WRITE\en");
fprintf(stderr, "\et\etS \- F_SEAL_SEAL\en");
exit(EXIT_FAILURE);
}
@@ -463,6 +472,8 @@ main(int argc, char *argv[])
seals |= F_SEAL_SHRINK;
if (strchr(seals_arg, \(aqw\(aq) != NULL)
seals |= F_SEAL_WRITE;
+if (strchr(seals_arg, \(aqW\(aq) != NULL)
+seals |= F_SEAL_FUTURE_WRITE;
if (strchr(seals_arg, \(aqS\(aq) != NULL)
seals |= F_SEAL_SEAL;
@@ -518,6 +529,8 @@ main(int argc, char *argv[])
printf(" GROW");
if (seals & F_SEAL_WRITE)
printf(" WRITE");
+if (seals & F_SEAL_FUTURE_WRITE)
+printf(" FUTURE_WRITE");
if (seals & F_SEAL_SHRINK)
printf(" SHRINK");
printf("\en");
--
2.21.0.360.g471c308f928-goog
[PATCH -manpage 1/2] fcntl.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal
More details of the seal can be found in the LKML patch: https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t Signed-off-by: Joel Fernandes (Google) --- man2/fcntl.2 | 15 +++ 1 file changed, 15 insertions(+) diff --git a/man2/fcntl.2 b/man2/fcntl.2 index fce4f4c2b3bd..e01e2c075b5b 100644 --- a/man2/fcntl.2 +++ b/man2/fcntl.2 @@ -1525,6 +1525,21 @@ Furthermore, if there are any asynchronous I/O operations .RB ( io_submit (2)) pending on the file, all outstanding writes will be discarded. +.TP +.BR F_SEAL_FUTURE_WRITE +If this seal is set, the contents of the file can be modified only from +existing writeable mappings that were created prior to the seal being set. +Any attempt to create a new writeable mapping on the memfd via +.BR mmap (2) +will fail with +.BR EPERM. +Also any attempts to write to the memfd via +.BR write (2) +will fail with +.BR EPERM. +This is useful in situations where existing writable mapped regions need to be +kept intact while preventing any future writes. For example, to share a +read-only memory buffer to other processes that only the sender can write to. .\" .SS File read/write hints Write lifetime hints can be used to inform the kernel about the relative -- 2.21.0.360.g471c308f928-goog
[PATCH -manpage 0/2]
This documentation is for F_SEAL_FUTURE_WRITE patches that are in linux-next. Joel Fernandes (Google) (2): fcntl.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal memfd_create.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal man2/fcntl.2| 15 +++ man2/memfd_create.2 | 15 ++- 2 files changed, 29 insertions(+), 1 deletion(-) -- 2.21.0.360.g471c308f928-goog
Re: [PATCH tip/core/rcu 06/19] rcu: Add warning to detect half-interrupts
On Thu, Mar 14, 2019 at 09:37:46AM -0400, Steven Rostedt wrote: > On Thu, 14 Mar 2019 09:36:57 -0400 > Steven Rostedt wrote: > > > On Thu, 14 Mar 2019 08:31:59 -0400 > > Joel Fernandes wrote: > > > > > Oh thanks for pointing that out. Yes it does work for me. I agree with the > > > lockdep API addition and others could benefit from it too. I will > > > incorporate > > > the lockdep API addition into the RCU patch, but let me know if I should > > > rather split it. > > > > I'd recommend splitting it (adding the lockdep_assert in a patch by > > itself), but make sure that patch Cc's the lockdep maintainers and > > explains the reason for adding it. Might as well Cc the lockdep > > maintainers on the entire series too. > > > > Feel free to add "Suggested-by: Steven Rostedt (VMware) " > on that patch too. Will definitely split it and add your tag. Thanks! - Joel
Re: [PATCH] perf/x86/intel: Make cpuc allocations consistent
Hi, On Tue, Mar 05, 2019 at 10:23:15PM +0100, Peter Zijlstra (Intel) wrote: > The cpuc data structure allocation is different between fake and real > cpuc's; use the same code to init/free both. > > Signed-off-by: Peter Zijlstra (Intel) > Signed-off-by: Thomas Gleixner With allmodconfig-CONFIG_CPU_SUP_INTEL, this patch results in: In file included from arch/x86/events/amd/core.c:8:0: arch/x86/events/amd/../perf_event.h:1036:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu) ^~~~ arch/x86/events/amd/../perf_event.h:1041:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc) ^~~~ With -Werror, this is fatal, and I think it may be buggy (should it be cpu_hw_events) ? The patch has been applied to stable releases. Any idea, anyone, why this is the case ? It doesn't look like a bug fix to me, and reverting it from v4.14.106 didn't seem to have a negative impact. Guenter
Re: [PATCH] tracing: initialize variable in create_dyn_event()
Hi Steve,
Ping.
-Frank
On 1/24/19 6:17 PM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Fix compile warning in create_dyn_event(): 'ret' may be used uninitialized
> in this function [-Wuninitialized].
>
> Fixes: 5448d44c3855 ("tracing: Add unified dynamic event framework")
>
> Signed-off-by: Frank Rowand
> ---
>
> Compile and boot tested only. Please verify the initialization value
> of zero is correct.
>
> There is also a sparse warning you might want to check into (when
> ARCH=arm, so 32 bit):
>
>include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from
> constant value (8000 becomes 0)
>
>
> kernel/trace/trace_dynevent.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace_dynevent.c b/kernel/trace/trace_dynevent.c
> index dd1f43588d70..4f633476c307 100644
> --- a/kernel/trace/trace_dynevent.c
> +++ b/kernel/trace/trace_dynevent.c
> @@ -74,7 +74,7 @@ int dyn_event_release(int argc, char **argv, struct
> dyn_event_operations *type)
> static int create_dyn_event(int argc, char **argv)
> {
> struct dyn_event_operations *ops;
> - int ret;
> + int ret = 0;
>
> if (argv[0][0] == '-' || argv[0][0] == '!')
> return dyn_event_release(argc, argv, NULL);
>
Re: Regression causes a hang on boot with a Comtrol PCI card
> > 1302fcf0d03e (refs/bisect/bad) PCI: Configure *all* devices, not just > > hot-added ones > > 1c3c5eab1715 sched/core: Enable might_sleep() and smp_processor_id() > > checks early > > How did you narrow it down to *two* commits, and do you have to revert > both of them to avoid the hang? Usually a bisection identifies a > single commit, and the two you mention aren't related. Sorry I should have been more verbose in what the bisection process was, I found the problem after attempting to upgrade from linux v3.16 to v4.9. When v4.9 hung I tried the latest kernel, v5.0, which also hanged. I began a git bisect, but found there was more than one bad commit. Here is my current understanding: - [x] v3.18 vanilla, 1302fcf0d03e committed, hangs - [x] v3.18 with revert of 1302fcf0d03e, works . . . - [x] v4.12 vanilla, hangs - [x] v4.12 with revert of 1302fcf0d03e, works - [x] v4.13 vanilla, 1c3c5eab1715 committed, hangs - [x] v4.13 with revert of 1302fcf0d03e, hangs - [x] v4.13 with revert of 1c3c5eab1715, hangs - [x] v4.13 with revert of 1302fcf0d03e & 1c3c5eab1715, works - [x] v5.0 vanilla, hangs - [x] v5.0 with revert of 1302fcf0d03e & 1c3c5eab1715, works > Can you collect a complete dmesg log (with a working kernel) and > output of "sudo lspci -vvxxx"? You can open a bug report at > https://bugzilla.kernel.org, attach the logs there, and respond here > with the URL. Bug submitted along with the requested logs, https://bugzilla.kernel.org/show_bug.cgi?id=202927 > Where does the hang happen? Is it when we configure the Comtrol card? Hang occurs after PCI is initialized, snippet below, I have included the full output in the bug report: [ 10.561971] pci :81:00.0: bridge window [mem 0xc800-0xc80f] [ 10.569661] pci :80:01.0: PCI bridge to [bus 81-82] [ 10.575594] pci :80:01.0: bridge window [mem 0xc800-0xc80f] [ 10.583278] pci :80:03.0: PCI bridge to [bus 83] [ 10.589008] NET: Registered protocol family 2 [ 10.594254] tcp_listen_portaddr_hash hash table entries: 65536 (order: 8, 1048576 bytes) [ 10.603671] TCP established hash table entries: 524288 (order: 10, 4194304 bytes) [ 10.612729] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 10.620446] TCP: Hash tables configured (established 524288 bind 65536) [ 10.628124] UDP hash table entries: 65536 (order: 9, 2097152 bytes) [ 10.635541] UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes) [ 10.643669] NET: Registered protocol family 1 Please let me know if there is anything else I can provide, I am also happy to test any patches, Jesse Hathaway
Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
Eric, Am Donnerstag, 14. März 2019, 18:49:14 CET schrieb Eric Biggers: > Hi Richard, > > On Thu, Mar 14, 2019 at 06:15:59PM +0100, Richard Weinberger wrote: > > Usually fscrypt allows limited access to encrypted files even > > if no key is available. > > Encrypted filenames are shown and based on this names users > > can unlink and move files. > > Actually, fscrypt doesn't allow moving files without the key. It would only > be > possible for cross-renames, i.e. renames with the RENAME_EXCHANGE flag. So > for > consistency with regular renames, fscrypt also forbids cross-renames if the > key > for either the source or destination directory is missing. > > So the main use case for the ciphertext view is *deleting* files. For > example, > deleting a user's home directory after that user has been removed from the > system. Or the system freeing up space by deleting cache files from a user > who > isn't currently logged in. Right, I somehow thought beside of deleting you can do more. > > > > This is not always what people expect. The fscrypt_key_required mount > > option disables this feature. > > If no key is present all access is denied with the -ENOKEY error code. > > The problem with this mount option is that it allows users to create > undeletable > files. So I'm not really convinced yet this is a good change. And though the > fscrypt_key_required semantics are easier to implement, we'd still have to > support the existing semantics too, thus increasing the maintenance cost. The undeletable-file argument is a good point. Thanks for bringing this up. To get rid of such files root needs to mount without the new mount parameter. ;-\ > > > > The side benefit of this is that we don't need ->d_revalidate(). > > Not having ->d_revalidate() makes an encrypted ubifs usable > > as overlayfs upper directory. > > > > It would be preferable if we could get overlayfs to work without providing a > special mount option. Yes, but let's see what Al finds in his review. > > Signed-off-by: Richard Weinberger > > --- > > fs/ubifs/crypto.c | 2 +- > > fs/ubifs/dir.c| 29 ++--- > > fs/ubifs/super.c | 15 +++ > > fs/ubifs/ubifs.h | 1 + > > 4 files changed, 43 insertions(+), 4 deletions(-) > > > > Shouldn't readlink() honor the mount option too? Hmmm, yes. We need to honor it in ->get_link() too. > > + if (c->fscrypt_key_required && !dir->i_crypt_info) > > + return -ENOKEY; > > + > > How about returning -ENOKEY when trying to open the directory in the first > place, rather than allowing getting to readdir()? That would match the > behavior > of regular files. I'm not sure what the best approach is. We could also do it in ->permission(). Thanks, //richard
general protection fault in ebitmap_destroy (2)
Hello,
syzbot found the following crash on:
HEAD commit:ebc551f2 Merge tag 'nfsd-5.1' of git://linux-nfs.org/~bfie..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=105c28d720
kernel config: https://syzkaller.appspot.com/x/.config?x=f05902bca21d8935
dashboard link: https://syzkaller.appspot.com/bug?extid=a57b2aff60832666fc28
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: amd64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1510bd5f20
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1405dd6f20
The crash was bisected to:
commit acdf52d97f824019888422842757013b37441dd1
Author: Kent Overstreet
Date: Tue Mar 12 06:31:10 2019 +
selinux: convert to kvmalloc
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12b2b09320
final crash:https://syzkaller.appspot.com/x/report.txt?x=11b2b09320
console output: https://syzkaller.appspot.com/x/log.txt?x=16b2b09320
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a57b2aff60832666f...@syzkaller.appspotmail.com
Fixes: acdf52d9 ("selinux: convert to kvmalloc")
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8151 Comm: syz-executor646 Not tainted 5.0.0+ #20
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:ebitmap_destroy+0x32/0xf0 security/selinux/ss/ebitmap.c:334
Code: 49 89 fd 41 54 53 e8 6d f6 7f fe 4d 85 ed 0f 84 99 00 00 00 e8 5f f6
7f fe 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
85 98 00 00 00 49 be 00 00 00 00 00 fc ff df 4d 8b
RSP: 0018:8880918478c8 EFLAGS: 00010202
RAX: dc00 RBX: 8880a15c93e8 RCX: 82f1b92c
RDX: 0002 RSI: 82f06dd1 RDI: 0010
RBP: 8880918478e8 R08: 88807c05c080 R09: 88807c05c948
R10: R11: R12: 0002
R13: 0010 R14: ed10142b92b2 R15: 0401
FS: 00f65880() GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2140 CR3: 7e591000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
policydb_destroy+0x62c/0x7f0 security/selinux/ss/policydb.c:832
policydb_read+0xe27/0x52c0 security/selinux/ss/policydb.c:2522
security_load_policy+0x36d/0x1170 security/selinux/ss/services.c:2147
sel_write_load+0x25a/0x470 security/selinux/selinuxfs.c:565
__vfs_write+0x8d/0x110 fs/read_write.c:485
vfs_write+0x20c/0x580 fs/read_write.c:549
ksys_write+0xea/0x1f0 fs/read_write.c:598
__do_sys_write fs/read_write.c:610 [inline]
__se_sys_write fs/read_write.c:607 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:607
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4401f9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff747a42f8 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 004002c8 RCX: 004401f9
RDX: 0050 RSI: 2180 RDI: 0003
RBP: 006ca018 R08: R09: 004002c8
R10: R11: 0246 R12: 00401a80
R13: 00401b10 R14: R15:
Modules linked in:
---[ end trace c9a4ce516f33c859 ]---
RIP: 0010:ebitmap_destroy+0x32/0xf0 security/selinux/ss/ebitmap.c:334
Code: 49 89 fd 41 54 53 e8 6d f6 7f fe 4d 85 ed 0f 84 99 00 00 00 e8 5f f6
7f fe 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
85 98 00 00 00 49 be 00 00 00 00 00 fc ff df 4d 8b
RSP: 0018:8880918478c8 EFLAGS: 00010202
RAX: dc00 RBX: 8880a15c93e8 RCX: 82f1b92c
RDX: 0002 RSI: 82f06dd1 RDI: 0010
RBP: 8880918478e8 R08: 88807c05c080 R09: 88807c05c948
R10: R11: R12: 0002
R13: 0010 R14: ed10142b92b2 R15: 0401
FS: 00f65880() GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2140 CR3: 7e591000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this bug
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On Thu, 2019-03-14 at 15:07 +0100, Jean Delvare wrote: > My principle is that if a script > is present in the kernel tree then it can and should be maintained. If > it is deemed not worth the maintenance effort then it should be > deleted. I've suggested deleting Lindent in the past. https://lkml.org/lkml/2013/2/11/390 Also there is now the clang-format tool that does an OK job of reflowing source to something approximating the typical kernel style. See: Documentation/process/clang-format.rst
[PATCH] elf: delete trailing "return;" in functions returning "void"
Signed-off-by: Alexey Dobriyan --- fs/binfmt_elf.c |4 1 file changed, 4 deletions(-) --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -1456,8 +1456,6 @@ static void fill_elf_header(struct elfhdr *elf, int segs, elf->e_ehsize = sizeof(struct elfhdr); elf->e_phentsize = sizeof(struct elf_phdr); elf->e_phnum = segs; - - return; } static void fill_elf_note_phdr(struct elf_phdr *phdr, int sz, loff_t offset) @@ -1470,7 +1468,6 @@ static void fill_elf_note_phdr(struct elf_phdr *phdr, int sz, loff_t offset) phdr->p_memsz = 0; phdr->p_flags = 0; phdr->p_align = 0; - return; } static void fill_note(struct memelfnote *note, const char *name, int type, @@ -1480,7 +1477,6 @@ static void fill_note(struct memelfnote *note, const char *name, int type, note->type = type; note->datasz = sz; note->data = data; - return; } /*
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Thu, Mar 14, 2019 at 10:47:17AM -0700, Joel Fernandes wrote: > About the 100ms latency, I wonder whether it is that high because of > the way Android's lmkd is observing that a process has died. There is > a gap between when a process memory is freed and when it disappears > from the process-table. Once a process is SIGKILLed, it becomes a > zombie. Its memory is freed instantly during the SIGKILL delivery (I > traced this so that's how I know), but until it is reaped by its > parent thread, it will still exist in /proc/ . So if testing the > existence of /proc/ is how Android is observing that the process > died, then there can be a large latency where it takes a very long > time for the parent to actually reap the child way after its memory > was long freed. A quicker way to know if a process's memory is freed > before it is reaped could be to read back /proc//maps in > userspace of the victim , and that file will be empty for zombie > processes. So then one does not need wait for the parent to reap it. I > wonder how much of that 100ms you mentioned is actually the "Waiting > while Parent is reaping the child", than "memory freeing time". So > yeah for this second problem, the procfds work will help. > > By the way another approach that can provide a quick and asynchronous > notification of when the process memory is freed, is to monitor > sched_process_exit trace event using eBPF. You can tell eBPF the PID > that you want to monitor before the SIGKILL. As soon as the process > dies and its memory is freed, the eBPF program can send a notification > to user space (using the perf_events polling infra). The > sched_process_exit fires just after the mmput() happens so it is quite > close to when the memory is reclaimed. This also doesn't need any > kernel changes. I could come up with a prototype for this and > benchmark it on Android, if you want. Just let me know. Perhaps I'm missing something, but if you want to know when a process has died after sending a SIGKILL to it, then why not just make the SIGKILL optionally block until the process has died completely? It'd be rather trivial to just store a pointer to an onstack completion inside the victim process' task_struct, and then complete it in free_task(). Thanks, Sultan
[PATCH] elf: free PT_INTERP filename ASAP
There is no reason for PT_INTERP filename to linger till the end of
the whole loading process.
Signed-off-by: Alexey Dobriyan
---
fs/binfmt_elf.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -686,7 +686,6 @@ static int load_elf_binary(struct linux_binprm *bprm)
struct file *interpreter = NULL; /* to shut gcc up */
unsigned long load_addr = 0, load_bias = 0;
int load_addr_set = 0;
- char * elf_interpreter = NULL;
unsigned long error;
struct elf_phdr *elf_ppnt, *elf_phdata, *interp_elf_phdata = NULL;
unsigned long elf_bss, elf_brk;
@@ -742,6 +741,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
for (i = 0; i < loc->elf_ex.e_phnum; i++) {
if (elf_ppnt->p_type == PT_INTERP) {
+ char *elf_interpreter;
loff_t pos;
/* This is the program interpreter used for
@@ -773,9 +773,10 @@ static int load_elf_binary(struct linux_binprm *bprm)
goto out_free_interp;
interpreter = open_exec(elf_interpreter);
+ kfree(elf_interpreter);
retval = PTR_ERR(interpreter);
if (IS_ERR(interpreter))
- goto out_free_interp;
+ goto out_free_dentry;
/*
* If the binary is not readable then enforce
@@ -795,6 +796,10 @@ static int load_elf_binary(struct linux_binprm *bprm)
}
break;
+
+out_free_interp:
+ kfree(elf_interpreter);
+ goto out_free_ph;
}
elf_ppnt++;
}
@@ -819,7 +824,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
}
/* Some simple consistency checks for the interpreter */
- if (elf_interpreter) {
+ if (interpreter) {
retval = -ELIBBAD;
/* Not an ELF interpreter */
if (memcmp(loc->interp_elf_ex.e_ident, ELFMAG, SELFMAG) != 0)
@@ -978,7 +983,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
* independently randomized mmap region (0 load_bias
* without MAP_FIXED).
*/
- if (elf_interpreter) {
+ if (interpreter) {
load_bias = ELF_ET_DYN_BASE;
if (current->flags & PF_RANDOMIZE)
load_bias += arch_mmap_rnd();
@@ -1076,7 +1081,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
goto out_free_dentry;
}
- if (elf_interpreter) {
+ if (interpreter) {
unsigned long interp_map_addr = 0;
elf_entry = load_elf_interp(>interp_elf_ex,
@@ -1100,7 +1105,6 @@ static int load_elf_binary(struct linux_binprm *bprm)
allow_write_access(interpreter);
fput(interpreter);
- kfree(elf_interpreter);
} else {
elf_entry = loc->elf_ex.e_entry;
if (BAD_ADDR(elf_entry)) {
@@ -1115,7 +1119,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
set_binfmt(_format);
#ifdef ARCH_HAS_SETUP_ADDITIONAL_PAGES
- retval = arch_setup_additional_pages(bprm, !!elf_interpreter);
+ retval = arch_setup_additional_pages(bprm, !!interpreter);
if (retval < 0)
goto out;
#endif /* ARCH_HAS_SETUP_ADDITIONAL_PAGES */
@@ -1177,8 +1181,6 @@ static int load_elf_binary(struct linux_binprm *bprm)
allow_write_access(interpreter);
if (interpreter)
fput(interpreter);
-out_free_interp:
- kfree(elf_interpreter);
out_free_ph:
kfree(elf_phdata);
goto out;
Re: [PATCH v3 3/7] slob: Use slab_list instead of lru
On Thu, Mar 14, 2019 at 06:52:25PM +, Roman Gushchin wrote:
> On Thu, Mar 14, 2019 at 04:31:31PM +1100, Tobin C. Harding wrote:
> > Currently we use the page->lru list for maintaining lists of slabs. We
> > have a list_head in the page structure (slab_list) that can be used for
> > this purpose. Doing so makes the code cleaner since we are not
> > overloading the lru list.
> >
> > The slab_list is part of a union within the page struct (included here
> > stripped down):
> >
> > union {
> > struct {/* Page cache and anonymous pages */
> > struct list_head lru;
> > ...
> > };
> > struct {
> > dma_addr_t dma_addr;
> > };
> > struct {/* slab, slob and slub */
> > union {
> > struct list_head slab_list;
> > struct {/* Partial pages */
> > struct page *next;
> > int pages; /* Nr of pages left */
> > int pobjects; /* Approximate count */
> > };
> > };
> > ...
> >
> > Here we see that slab_list and lru are the same bits. We can verify
> > that this change is safe to do by examining the object file produced from
> > slob.c before and after this patch is applied.
> >
> > Steps taken to verify:
> >
> > 1. checkout current tip of Linus' tree
> >
> > commit a667cb7a94d4 ("Merge branch 'akpm' (patches from Andrew)")
> >
> > 2. configure and build (select SLOB allocator)
> >
> > CONFIG_SLOB=y
> > CONFIG_SLAB_MERGE_DEFAULT=y
> >
> > 3. dissasemble object file `objdump -dr mm/slub.o > before.s
> > 4. apply patch
> > 5. build
> > 6. dissasemble object file `objdump -dr mm/slub.o > after.s
> > 7. diff before.s after.s
> >
> > Use slab_list list_head instead of the lru list_head for maintaining
> > lists of slabs.
> >
> > Reviewed-by: Roman Gushchin
> > Signed-off-by: Tobin C. Harding
> > ---
> > mm/slob.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/mm/slob.c b/mm/slob.c
> > index 39ad9217ffea..94486c32e0ff 100644
> > --- a/mm/slob.c
> > +++ b/mm/slob.c
> > @@ -112,13 +112,13 @@ static inline int slob_page_free(struct page *sp)
> >
> > static void set_slob_page_free(struct page *sp, struct list_head *list)
> > {
> > - list_add(>lru, list);
> > + list_add(>slab_list, list);
> > __SetPageSlobFree(sp);
> > }
> >
> > static inline void clear_slob_page_free(struct page *sp)
> > {
> > - list_del(>lru);
> > + list_del(>slab_list);
> > __ClearPageSlobFree(sp);
> > }
> >
> > @@ -282,7 +282,7 @@ static void *slob_alloc(size_t size, gfp_t gfp, int
> > align, int node)
> >
> > spin_lock_irqsave(_lock, flags);
> > /* Iterate through each partially free page, try to find room */
> > - list_for_each_entry(sp, slob_list, lru) {
> > + list_for_each_entry(sp, slob_list, slab_list) {
> > #ifdef CONFIG_NUMA
> > /*
> > * If there's a node specification, search for a partial
>
>
> Hi Tobin!
>
> How about list_rotate_to_front(>lru, slob_list) from the previous patch?
> Shouldn't it use slab_list instead of lru too?
I'll let this sit for a day or two in case we get any more comments on
the list.h stuff then do another version ready for US Monday morning.
Thanks again,
Tobin.
[PATCH] elf: make scope of "pos" variable smaller
Signed-off-by: Alexey Dobriyan
---
fs/binfmt_elf.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -703,7 +703,6 @@ static int load_elf_binary(struct linux_binprm *bprm)
struct elfhdr interp_elf_ex;
} *loc;
struct arch_elf_state arch_state = INIT_ARCH_ELF_STATE;
- loff_t pos;
loc = kmalloc(sizeof(*loc), GFP_KERNEL);
if (!loc) {
@@ -743,6 +742,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
for (i = 0; i < loc->elf_ex.e_phnum; i++) {
if (elf_ppnt->p_type == PT_INTERP) {
+ loff_t pos;
+
/* This is the program interpreter used for
* shared libraries - for now assume that this
* is an a.out format binary
[PATCH 1/2] x86/CPU: Use correct macros for Cyrix calls on Geode processors
There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:
setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:
outb(CX86_CCR2, 0x22);
inb(0x23);
>From the comments:
* When using the old macros a line like
* setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
* gets expanded to:
* do {
*outb((CX86_CCR2), 0x22);
*outb((({
*outb((CX86_CCR2), 0x22);
*inb(0x23);
*}) | 0x88), 0x23);
* } while (0);
The new macros fix this problem, so use them instead. Tested on an
actual Geode processor.
Signed-off-by: Matthew Whitehead
---
arch/x86/kernel/cpu/cyrix.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index d12226f..1d9b8aa 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -124,7 +124,7 @@ static void set_cx86_reorder(void)
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
/* Load/Store Serialize to mem access disable (=reorder it) */
- setCx86_old(CX86_PCR0, getCx86_old(CX86_PCR0) & ~0x80);
+ setCx86(CX86_PCR0, getCx86(CX86_PCR0) & ~0x80);
/* set load/store serialize from 1GB to 4GB */
ccr3 |= 0xe0;
setCx86(CX86_CCR3, ccr3);
@@ -135,11 +135,11 @@ static void set_cx86_memwb(void)
pr_info("Enable Memory-Write-back mode on Cyrix/NSC processor.\n");
/* CCR2 bit 2: unlock NW bit */
- setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) & ~0x04);
+ setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x04);
/* set 'Not Write-through' */
write_cr0(read_cr0() | X86_CR0_NW);
/* CCR2 bit 2: lock NW bit and set WT1 */
- setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x14);
+ setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
}
/*
@@ -153,14 +153,14 @@ static void geode_configure(void)
local_irq_save(flags);
/* Suspend on halt power saving and enable #SUSP pin */
- setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x88);
+ setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
/* FPU fast, DTE cache, Mem bypass */
- setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x38);
+ setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x38);
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
set_cx86_memwb();
@@ -296,7 +296,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
/* GXm supports extended cpuid levels 'ala' AMD */
if (c->cpuid_level == 2) {
/* Enable cxMMX extensions (GX1 Datasheet 54) */
- setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7) | 1);
+ setCx86(CX86_CCR7, getCx86(CX86_CCR7) | 1);
/*
* GXm : 0x30 ... 0x5f GXm datasheet 51
@@ -319,7 +319,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
if (dir1 > 7) {
dir0_msn++; /* M II */
/* Enable MMX extensions (App note 108) */
- setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7)|1);
+ setCx86(CX86_CCR7, getCx86(CX86_CCR7)|1);
} else {
/* A 6x86MX - it has the bug. */
set_cpu_bug(c, X86_BUG_COMA);
--
1.8.3.1
[PATCH 2/2] x86/CPU: Remove {get,set}Cx86_old macros used for Cyrix processors
The getCx86_old() and setCx86_old() macros have been replaced with
correctly working getCx86() and setCx86(), so remove these unused macros.
Signed-off-by: Matthew Whitehead
---
arch/x86/include/asm/processor-cyrix.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/arch/x86/include/asm/processor-cyrix.h
b/arch/x86/include/asm/processor-cyrix.h
index aaedd73..df700a6 100644
--- a/arch/x86/include/asm/processor-cyrix.h
+++ b/arch/x86/include/asm/processor-cyrix.h
@@ -3,19 +3,6 @@
* NSC/Cyrix CPU indexed register access. Must be inlined instead of
* macros to ensure correct access ordering
* Access order is always 0x22 (=offset), 0x23 (=value)
- *
- * When using the old macros a line like
- * setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
- * gets expanded to:
- * do {
- *outb((CX86_CCR2), 0x22);
- *outb((({
- *outb((CX86_CCR2), 0x22);
- *inb(0x23);
- *}) | 0x88), 0x23);
- * } while (0);
- *
- * which in fact violates the access order (= 0x22, 0x22, 0x23, 0x23).
*/
static inline u8 getCx86(u8 reg)
@@ -29,11 +16,3 @@ static inline void setCx86(u8 reg, u8 data)
outb(reg, 0x22);
outb(data, 0x23);
}
-
-#define getCx86_old(reg) ({ outb((reg), 0x22); inb(0x23); })
-
-#define setCx86_old(reg, data) do { \
- outb((reg), 0x22); \
- outb((data), 0x23); \
-} while (0)
-
--
1.8.3.1
[PATCH 0/2] x86/CPU: Use correct Cyrix-specific macros
Replace the incorrect Cyrix-specific macro calls with the correct
setCx86() and getCx86() calls. Also remove the unused setCx86_old(),
getCx86_old() and their related comments in the code.
Matthew Whitehead (2):
x86/CPU: Use correct macros for Cyrix calls on Geode processors
x86/CPU: Remove {get,set}Cx86_old macros used for Cyrix processors
arch/x86/include/asm/processor-cyrix.h | 21 -
arch/x86/kernel/cpu/cyrix.c| 14 +++---
2 files changed, 7 insertions(+), 28 deletions(-)
--
1.8.3.1
[PATCH 2/2] elf: print userspace address with %lx
Use %lx, save a cast.
"addr" is userspace address so using (and mangling) pointer was never
necessary.
Signed-off-by: Alexey Dobriyan
---
fs/binfmt_elf.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -376,8 +376,8 @@ static unsigned long elf_map(struct file *filep, unsigned
long addr,
map_addr = vm_mmap(filep, addr, size, prot, type, off);
if ((type & MAP_FIXED_NOREPLACE) && map_addr == -EEXIST)
- pr_info("%d (%s): Uhuuh, elf segment at %px requested but the
memory is mapped already\n",
- task_pid_nr(current), current->comm, (void *)addr);
+ pr_info("%d (%s): Uhuuh, elf segment at %lx requested but the
memory is mapped already\n",
+ task_pid_nr(current), current->comm, addr);
return(map_addr);
}
Re: [PATCH] checkpatch: add %pt as a valid vsprintf extension
On Thu, 2019-03-14 at 21:37 +0100, Alexandre Belloni wrote:
> Commit 4d42c44727a0 ("lib/vsprintf: Print time and date in human readable
> format via %pt") introduced a new extension, %pt. Add it in the list of
> valid extensions.
Thanks.
Andrew, can you please pick this up?
> Signed-off-by: Alexandre Belloni
> ---
> scripts/checkpatch.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index b737ca9d7204..35851755fbda 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5949,7 +5949,7 @@ sub process {
> while ($fmt =~ /(\%[\*\d\.]*p(\w))/g) {
> $specifier = $1;
> $extension = $2;
> - if ($extension !~
> /[SsBKRraEhMmIiUDdgVCbGNOx]/) {
> + if ($extension !~
> /[SsBKRraEhMmIiUDdgVCbGNOxt]/) {
> $bad_specifier = $specifier;
> last;
> }
Re: [Regression] Re: Linux 5.0.2
(Adding Linus, since his tree is also broken) Greg KH writes: > On Thu, Mar 14, 2019 at 07:59:00PM +, Alan J. Wylie wrote: >> Greg KH writes: >> >> > I'm announcing the release of the 5.0.2 kernel. >> >> There is a regression for AMD-only builds. > > Adding the stable list, which people should do... > >> >> See also Alec Ari's report: >> https://lkml.org/lkml/2019/3/13/1113 >> >> > If CONFIG_CPU_SUP_INTEL is disabled with either the 5.0.2 or 4.20.16 >> > kernel, it errors out right away: >> >> $ grep "CONFIG_CPU_SUP_" .config >> # CONFIG_CPU_SUP_INTEL is not set >> CONFIG_CPU_SUP_AMD=y >> # CONFIG_CPU_SUP_HYGON is not set >> # CONFIG_CPU_SUP_CENTAUR is not set >> >> CC arch/x86/events/core.o >> In file included from arch/x86/events/core.c:44: >> arch/x86/events/perf_event.h:1035:45: warning: ‘struct cpu_hw_event’ >> declared inside parameter list will not be visible outside of this >> definition or declaration >> static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu) >> ^~~~ >> arch/x86/events/perf_event.h:1040:45: warning: ‘struct cpu_hw_event’ >> declared inside parameter list will not be visible outside of this >> definition or declaration >> static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc) >> ^~~~ >> arch/x86/events/core.c: In function ‘free_fake_cpuc’: >> arch/x86/events/core.c:1998:20: error: passing argument 1 of >> ‘intel_cpuc_finish’ from incompatible pointer type >> [-Werror=incompatible-pointer-types] >> intel_cpuc_finish(cpuc); >> ^~~~ >> In file included from arch/x86/events/core.c:44: >> arch/x86/events/perf_event.h:1040:59: note: expected ‘struct cpu_hw_event *’ >> but argument is of type ‘struct cpu_hw_events *’ >> static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc) >> ~^~~~ >> arch/x86/events/core.c: In function ‘allocate_fake_cpuc’: >> arch/x86/events/core.c:2012:25: error: passing argument 1 of >> ‘intel_cpuc_prepare’ from incompatible pointer type >> [-Werror=incompatible-pointer-types] if (intel_cpuc_prepare(cpuc, >> cpu)) ^~~~ In file included from arch/x86/events/core.c:44: >> arch/x86/events/perf_event.h:1035:59: note: expected ‘struct >> cpu_hw_event *’ but argument is of type ‘struct cpu_hw_events *’ >> static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int >> cpu) ~^~~~ cc1: some warnings being treated as >> errors > > Is this a regression? 5.0.1 was fine, git pulled, then "make oldconfig" just answering the default "N"s > If so, what commit caused this? It looks as if it's commit 3ad8e57560d7652a66da12b41c668a593509f3ad Author: Peter Zijlstra (Intel) Date: Tue Mar 5 22:23:15 2019 +0100 perf/x86/intel: Make cpuc allocations consistent The cpuc data structure allocation is different between fake and real cpuc's; use the same code to init/free both. which is the commit which introduces the function: +static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu) > Is this also an issue in Linus's tree right now? Yes, as of 3b319ee220a8795406852a897299dbdfc1b09911 CC arch/x86/entry/common.o arch/x86/events/core.c: In function ‘free_fake_cpuc’: arch/x86/events/core.c:1998:20: error: passing argument 1 of ‘intel_cpuc_finish’ from incompatible pointer type [-Werror=incompatible-pointer-types] intel_cpuc_finish(cpuc); ^~~~ Thanks Alan -- Alan J. Wylie https://www.wylie.me.uk/ Dance like no-one's watching. / Encrypt like everyone is. Security is inversely proportional to convenience
Re: [PATCH v3 3/7] slob: Use slab_list instead of lru
On Fri, Mar 15, 2019 at 07:38:09AM +1100, Tobin C. Harding wrote:
> On Thu, Mar 14, 2019 at 06:52:25PM +, Roman Gushchin wrote:
> > On Thu, Mar 14, 2019 at 04:31:31PM +1100, Tobin C. Harding wrote:
> > > Currently we use the page->lru list for maintaining lists of slabs. We
> > > have a list_head in the page structure (slab_list) that can be used for
> > > this purpose. Doing so makes the code cleaner since we are not
> > > overloading the lru list.
> > >
> > > The slab_list is part of a union within the page struct (included here
> > > stripped down):
> > >
> > > union {
> > > struct {/* Page cache and anonymous pages */
> > > struct list_head lru;
> > > ...
> > > };
> > > struct {
> > > dma_addr_t dma_addr;
> > > };
> > > struct {/* slab, slob and slub */
> > > union {
> > > struct list_head slab_list;
> > > struct {/* Partial pages */
> > > struct page *next;
> > > int pages; /* Nr of pages left */
> > > int pobjects; /* Approximate count */
> > > };
> > > };
> > > ...
> > >
> > > Here we see that slab_list and lru are the same bits. We can verify
> > > that this change is safe to do by examining the object file produced from
> > > slob.c before and after this patch is applied.
> > >
> > > Steps taken to verify:
> > >
> > > 1. checkout current tip of Linus' tree
> > >
> > > commit a667cb7a94d4 ("Merge branch 'akpm' (patches from Andrew)")
> > >
> > > 2. configure and build (select SLOB allocator)
> > >
> > > CONFIG_SLOB=y
> > > CONFIG_SLAB_MERGE_DEFAULT=y
> > >
> > > 3. dissasemble object file `objdump -dr mm/slub.o > before.s
> > > 4. apply patch
> > > 5. build
> > > 6. dissasemble object file `objdump -dr mm/slub.o > after.s
> > > 7. diff before.s after.s
> > >
> > > Use slab_list list_head instead of the lru list_head for maintaining
> > > lists of slabs.
> > >
> > > Reviewed-by: Roman Gushchin
> > > Signed-off-by: Tobin C. Harding
> > > ---
> > > mm/slob.c | 8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/mm/slob.c b/mm/slob.c
> > > index 39ad9217ffea..94486c32e0ff 100644
> > > --- a/mm/slob.c
> > > +++ b/mm/slob.c
> > > @@ -112,13 +112,13 @@ static inline int slob_page_free(struct page *sp)
> > >
> > > static void set_slob_page_free(struct page *sp, struct list_head *list)
> > > {
> > > - list_add(>lru, list);
> > > + list_add(>slab_list, list);
> > > __SetPageSlobFree(sp);
> > > }
> > >
> > > static inline void clear_slob_page_free(struct page *sp)
> > > {
> > > - list_del(>lru);
> > > + list_del(>slab_list);
> > > __ClearPageSlobFree(sp);
> > > }
> > >
> > > @@ -282,7 +282,7 @@ static void *slob_alloc(size_t size, gfp_t gfp, int
> > > align, int node)
> > >
> > > spin_lock_irqsave(_lock, flags);
> > > /* Iterate through each partially free page, try to find room */
> > > - list_for_each_entry(sp, slob_list, lru) {
> > > + list_for_each_entry(sp, slob_list, slab_list) {
> > > #ifdef CONFIG_NUMA
> > > /*
> > >* If there's a node specification, search for a partial
> >
> >
> > Hi Tobin!
> >
> > How about list_rotate_to_front(>lru, slob_list) from the previous
> > patch?
> > Shouldn't it use slab_list instead of lru too?
>
> Thanks Roman, my mistake - one too many rebases. I hate when I drop the
> ball like this.
Oh that's right, its a union so it still builds and boots - I was
thinking that I had rebased and not built. I guess that's just a fumble
instead of a complete ball drop.
Thanks for the careful review all the same.
Tobin
[PATCH 1/2] elf: simpler check for -EEXIST
PTR_ERR((void *)map_addr) == -EEXIST
is a very complicated way of doing the obvious.
Signed-off-by: Alexey Dobriyan
---
fs/binfmt_elf.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -375,8 +375,7 @@ static unsigned long elf_map(struct file *filep, unsigned
long addr,
} else
map_addr = vm_mmap(filep, addr, size, prot, type, off);
- if ((type & MAP_FIXED_NOREPLACE) &&
- PTR_ERR((void *)map_addr) == -EEXIST)
+ if ((type & MAP_FIXED_NOREPLACE) && map_addr == -EEXIST)
pr_info("%d (%s): Uhuuh, elf segment at %px requested but the
memory is mapped already\n",
task_pid_nr(current), current->comm, (void *)addr);
Re: [PATCH v3 3/7] slob: Use slab_list instead of lru
On Thu, Mar 14, 2019 at 06:52:25PM +, Roman Gushchin wrote:
> On Thu, Mar 14, 2019 at 04:31:31PM +1100, Tobin C. Harding wrote:
> > Currently we use the page->lru list for maintaining lists of slabs. We
> > have a list_head in the page structure (slab_list) that can be used for
> > this purpose. Doing so makes the code cleaner since we are not
> > overloading the lru list.
> >
> > The slab_list is part of a union within the page struct (included here
> > stripped down):
> >
> > union {
> > struct {/* Page cache and anonymous pages */
> > struct list_head lru;
> > ...
> > };
> > struct {
> > dma_addr_t dma_addr;
> > };
> > struct {/* slab, slob and slub */
> > union {
> > struct list_head slab_list;
> > struct {/* Partial pages */
> > struct page *next;
> > int pages; /* Nr of pages left */
> > int pobjects; /* Approximate count */
> > };
> > };
> > ...
> >
> > Here we see that slab_list and lru are the same bits. We can verify
> > that this change is safe to do by examining the object file produced from
> > slob.c before and after this patch is applied.
> >
> > Steps taken to verify:
> >
> > 1. checkout current tip of Linus' tree
> >
> > commit a667cb7a94d4 ("Merge branch 'akpm' (patches from Andrew)")
> >
> > 2. configure and build (select SLOB allocator)
> >
> > CONFIG_SLOB=y
> > CONFIG_SLAB_MERGE_DEFAULT=y
> >
> > 3. dissasemble object file `objdump -dr mm/slub.o > before.s
> > 4. apply patch
> > 5. build
> > 6. dissasemble object file `objdump -dr mm/slub.o > after.s
> > 7. diff before.s after.s
> >
> > Use slab_list list_head instead of the lru list_head for maintaining
> > lists of slabs.
> >
> > Reviewed-by: Roman Gushchin
> > Signed-off-by: Tobin C. Harding
> > ---
> > mm/slob.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/mm/slob.c b/mm/slob.c
> > index 39ad9217ffea..94486c32e0ff 100644
> > --- a/mm/slob.c
> > +++ b/mm/slob.c
> > @@ -112,13 +112,13 @@ static inline int slob_page_free(struct page *sp)
> >
> > static void set_slob_page_free(struct page *sp, struct list_head *list)
> > {
> > - list_add(>lru, list);
> > + list_add(>slab_list, list);
> > __SetPageSlobFree(sp);
> > }
> >
> > static inline void clear_slob_page_free(struct page *sp)
> > {
> > - list_del(>lru);
> > + list_del(>slab_list);
> > __ClearPageSlobFree(sp);
> > }
> >
> > @@ -282,7 +282,7 @@ static void *slob_alloc(size_t size, gfp_t gfp, int
> > align, int node)
> >
> > spin_lock_irqsave(_lock, flags);
> > /* Iterate through each partially free page, try to find room */
> > - list_for_each_entry(sp, slob_list, lru) {
> > + list_for_each_entry(sp, slob_list, slab_list) {
> > #ifdef CONFIG_NUMA
> > /*
> > * If there's a node specification, search for a partial
>
>
> Hi Tobin!
>
> How about list_rotate_to_front(>lru, slob_list) from the previous patch?
> Shouldn't it use slab_list instead of lru too?
Thanks Roman, my mistake - one too many rebases. I hate when I drop the
ball like this.
Tobin.
[PATCH] checkpatch: add %pt as a valid vsprintf extension
Commit 4d42c44727a0 ("lib/vsprintf: Print time and date in human readable
format via %pt") introduced a new extension, %pt. Add it in the list of
valid extensions.
Signed-off-by: Alexandre Belloni
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b737ca9d7204..35851755fbda 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5949,7 +5949,7 @@ sub process {
while ($fmt =~ /(\%[\*\d\.]*p(\w))/g) {
$specifier = $1;
$extension = $2;
- if ($extension !~
/[SsBKRraEhMmIiUDdgVCbGNOx]/) {
+ if ($extension !~
/[SsBKRraEhMmIiUDdgVCbGNOxt]/) {
$bad_specifier = $specifier;
last;
}
--
2.20.1
Re: [PATCH v3 0/1] mm: introduce put_user_page*(), placeholder versions
On 3/14/19 1:25 PM, William Kucharski wrote: On Mar 14, 2019, at 7:30 AM, Jan Kara wrote: Well I have some crash reports couple years old and they are not from QA departments. So I'm pretty confident there are real users that use this in production... and just reboot their machine in case it crashes. Do you know what the use case in those crashes actually was? I'm curious to know they were actually cases of say DMA from a video capture card or if the uses posited to date are simply theoretical. It's not merely theoretical. In addition to Jan's bug reports, I've personally investigated a bug that involved an GPU (acting basically as an AI accelerator in this case) that was doing DMA to memory that turned out to be file backed. The backtrace for that is in the commit description. As others have mentioned, this works well enough to lure people into using it, but then fails when you load down a powerful system (and put it under memory pressure). I think that as systems get larger, and more highly threaded, we might see more such failures--maybe even in the Direct IO case someday, although so far that race window is so small that that one truly is still theoretical (or, we just haven't been in communication with anyone who hit it). thanks, -- John Hubbard NVIDIA It's always good to know who might be doing this and why if for no other reason than as something to keep in mind when designing future interfaces.
Re: [PATCH v3 0/1] mm: introduce put_user_page*(), placeholder versions
> On Mar 14, 2019, at 7:30 AM, Jan Kara wrote: > > Well I have some crash reports couple years old and they are not from QA > departments. So I'm pretty confident there are real users that use this in > production... and just reboot their machine in case it crashes. Do you know what the use case in those crashes actually was? I'm curious to know they were actually cases of say DMA from a video capture card or if the uses posited to date are simply theoretical. It's always good to know who might be doing this and why if for no other reason than as something to keep in mind when designing future interfaces.
Re: [Regression] Re: Linux 5.0.2
On Thu, Mar 14, 2019 at 07:59:00PM +, Alan J. Wylie wrote: > Greg KH writes: > > > I'm announcing the release of the 5.0.2 kernel. > > There is a regression for AMD-only builds. Adding the stable list, which people should do... > > See also Alec Ari's report: > https://lkml.org/lkml/2019/3/13/1113 > > > If CONFIG_CPU_SUP_INTEL is disabled with either the 5.0.2 or 4.20.16 > > kernel, it errors out right away: > > $ grep "CONFIG_CPU_SUP_" .config > # CONFIG_CPU_SUP_INTEL is not set > CONFIG_CPU_SUP_AMD=y > # CONFIG_CPU_SUP_HYGON is not set > # CONFIG_CPU_SUP_CENTAUR is not set > > CC arch/x86/events/core.o > In file included from arch/x86/events/core.c:44: > arch/x86/events/perf_event.h:1035:45: warning: ‘struct cpu_hw_event’ declared > inside parameter list will not be visible outside of this definition or > declaration > static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu) > ^~~~ > arch/x86/events/perf_event.h:1040:45: warning: ‘struct cpu_hw_event’ declared > inside parameter list will not be visible outside of this definition or > declaration > static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc) > ^~~~ > arch/x86/events/core.c: In function ‘free_fake_cpuc’: > arch/x86/events/core.c:1998:20: error: passing argument 1 of > ‘intel_cpuc_finish’ from incompatible pointer type > [-Werror=incompatible-pointer-types] > intel_cpuc_finish(cpuc); > ^~~~ > In file included from arch/x86/events/core.c:44: > arch/x86/events/perf_event.h:1040:59: note: expected ‘struct cpu_hw_event *’ > but argument is of type ‘struct cpu_hw_events *’ > static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc) > ~^~~~ > arch/x86/events/core.c: In function ‘allocate_fake_cpuc’: > arch/x86/events/core.c:2012:25: error: passing argument 1 of > ‘intel_cpuc_prepare’ from incompatible pointer type > [-Werror=incompatible-pointer-types] > if (intel_cpuc_prepare(cpuc, cpu)) > ^~~~ > In file included from arch/x86/events/core.c:44: > arch/x86/events/perf_event.h:1035:59: note: expected ‘struct cpu_hw_event *’ > but argument is of type ‘struct cpu_hw_events *’ > static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu) > ~^~~~ > cc1: some warnings being treated as errors Is this a regression? If so, what commit caused this? Is this also an issue in Linus's tree right now? thanks, greg k-h
Re: [PATCH 1/5] lib/sort: Make swap functions more generic
> Pistols at dawn? > swap_bytes > swap_4byte_words > swap_8byte_words or > swap_bytes / swap_ints / swap_longs > swap_1 / swap_4 / swap_8 Yes, in my opinion, swap_bytes / swap_ints / swap_longs are the most readable because we have both swap_ints and swap_longs functions (in one file near each other), so I don't think that there will be any confusion about size. But actually, it doesn't matter which name will you take, because the meaning of each, in my opinion, is obvious enough, so I don't mind about any of these options. -- With Best Regards, Andrey Abramov
[PATCH v3 2/3] Drivers: hv: vmbus: Set ring_info field to 0 and remove memset
Set "ring_info->priv_read_index" to 0. Now, all of ring_info's fields are explicitly set in this function. The memset() call is no longer necessary, so remove it. Signed-off-by: Kimberly Brown --- drivers/hv/ring_buffer.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index 9e8b31ccc142..0386ff48c5ea 100644 --- a/drivers/hv/ring_buffer.c +++ b/drivers/hv/ring_buffer.c @@ -197,8 +197,6 @@ int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info, BUILD_BUG_ON((sizeof(struct hv_ring_buffer) != PAGE_SIZE)); - memset(ring_info, 0, sizeof(struct hv_ring_buffer_info)); - /* * First page holds struct hv_ring_buffer, do wraparound mapping for * the rest. @@ -232,6 +230,7 @@ int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info, reciprocal_value(ring_info->ring_size / 10); ring_info->ring_datasize = ring_info->ring_size - sizeof(struct hv_ring_buffer); + ring_info->priv_read_index = 0; spin_lock_init(_info->ring_lock); -- 2.17.1
[PATCH v3 0/3] Drivers: hv: vmbus: Fix a race condition in "_show" functions
This patchset fixes a race condition in the "_show" functions that access the channel ring buffers. Changes in v3: Patch 1: Drivers: hv: vmbus: Refactor chan->state if statement - Added the “reviewed-by” line from v2. Patch 2: Drivers: hv: vmbus: Set ring_info field to 0 and remove memset - This patch is new. This change allows the new mutex locks in patch 3 to be initialized when the channel is initialized. Patch 3: Drivers: hv: vmbus: Fix race condition with new ring_buffer_info mutex - Added two ring buffer info mutex locks instead of the single channel mutex lock that was proposed in v2. - Changed the mutex acquire/release calls as needed for the new ring buffer info mutex locks. - Updated the commit message. Changes in v2: - In v1, I proposed using “vmbus_connection.channel_mutex” in the “_show” functions to prevent the race condition. However, using this mutex could result in a deadlock, so a new approach is proposed in this patchset. - Patch 1 is new and consists of refactoring an if statement. - Patch 2 introduces a new mutex lock in the “vmbus_channel” struct, which is used to eliminate the race condition. Kimberly Brown (3): Drivers: hv: vmbus: Refactor chan->state if statement Drivers: hv: vmbus: Set ring_info field to 0 and remove memset Drivers: hv: vmbus: Fix race condition with new ring_buffer_info mutex drivers/hv/channel_mgmt.c | 2 + drivers/hv/hyperv_vmbus.h | 1 + drivers/hv/ring_buffer.c | 22 -- drivers/hv/vmbus_drv.c| 89 +++ include/linux/hyperv.h| 7 ++- 5 files changed, 88 insertions(+), 33 deletions(-) -- 2.17.1
